<?xml version='1.0'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY abnf SYSTEM 
      'reference.RFC.5234.xml'>
    <!ENTITY offeranswer SYSTEM 
      'reference.RFC.3264.xml'>
    <!ENTITY rfc2119 SYSTEM 
      'reference.RFC.2119.xml'>
    <!ENTITY rfc5226 SYSTEM 
      'reference.RFC.5226.xml'>
    <!ENTITY rtp SYSTEM 
      'reference.RFC.3550.xml'>
    <!ENTITY rtptopo SYSTEM 
      'reference.RFC.5117.xml'>
    <!ENTITY sdp SYSTEM 
      'reference.RFC.4566.xml'>
    <!ENTITY sipconfpkg SYSTEM 
      'reference.RFC.4575.xml'>
    <!ENTITY sourceattr SYSTEM 
      'reference.RFC.5576.xml'>
    <!ENTITY imageattr SYSTEM 
      'reference.RFC.6236.xml'>
    <!ENTITY xconconfpkg SYSTEM 
      'reference.RFC.6502.xml'>
]>

<?rfc toc="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc symrefs="yes" ?>

<rfc category='std' ipr='trust200902' docName='draft-lennox-mmusic-sdp-source-selection-05'>
    <front>
        <title abbrev='Media Source Selection in SDP'>
		Mechanisms for Media
		Source Selection in the Session Description Protocol (SDP)
        </title>

        <author initials='J.' surname='Lennox'
                fullname='Jonathan Lennox'>
            <organization abbrev='Vidyo'>
               Vidyo, Inc.
            </organization>
            <address>
               <postal>
                   <street>433 Hackensack Avenue</street>
                   <street>Seventh Floor</street>
                   <city>Hackensack</city> <region>NJ</region>
                   <code>07601</code>
                   <country>US</country>
               </postal>
               <email>jonathan@vidyo.com</email>
            </address>
        </author>

		<author initials='H.' surname='Schulzrinne'
				fullname='Henning Schulzrinne'>
		  <organization abbrev='Columbia U.'>
			Columbia University Department of Computer Science
		  </organization>
		  <address>
			<postal>
			  <street>450 Computer Science</street>
			  <street>1214 Amsterdam Ave., Mailcode: 0401</street>
			  <city>New York</city> <region>NY</region>
			  <code>10027</code>
			  <country>US</country>
			</postal>
			<email>hgs@cs.columbia.edu</email>
			<uri>http://www.cs.columbia.edu/~hgs/</uri>
		  </address>
		</author>


        <date />
        <area>RAI</area>
        <workgroup>MMUSIC</workgroup>

		<keyword>real-time transport protocol</keyword>
		<keyword>rtp</keyword>
		<keyword>synchronization source</keyword>
		<keyword>ssrc</keyword>
		<keyword>offer/answer</keyword>

        <abstract>
		<t>Source-specific media attributes in the Session Description
		  Protocol (SDP) allow endpoints to 
		  describe Real-Time Transport Protocol (RTP)
		  sources within a media stream.  This document extends that
		  mechanism by defining how
		  participants in a multimedia session can request specific
		  sources from a remote party.</t>
        </abstract>

    </front>

<middle>

<section title='Introduction' anchor='introduction'>

<t>The <xref target='RFC5576'>source-attribute
	specification</xref> provides declarative definitions
	for <xref target='RFC3550'>Real-Time Protocol (RTP)</xref> media
	sources in the <xref target='RFC4566'>Session Description Protocol
	(SDP)</xref>.</t>

<t>In some architectures (such as those described in
  <xref target='architecture' />), it is useful to provide the capability for
  endpoints to request specific sources of a remote party, asking the sender
  to selectively
  enable or disable them, and to specify characteristics of the sources
  requested.  To accomplish this, this document defines a new media attribute,
  "remote-ssrc", which allows a receiver to indicate that it wishes to
  receive a remote
  source, and also allows it to specify attributes of the remote source.
  This document defines several such remote source attributes: "recv"
  and "preference" which are applicable to any media type,
  and "framerate" and "imageattr" which are specific to video
  sources.  Currently no attributes are defined that are specific to
  audio or other media types.</t>

<t>Additionally, several new declarative (<xref target='RFC5576' />)
  source attributes are defined:
  "information", providing human-readable information about a local
  source, and "sending", which is complementary to the
  "recv" remote source attribute.</t>

</section>

<section title='Terminology'>

<t>The key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
and "OPTIONAL" in this document
are to be interpreted as described in <xref
target='RFC2119'>RFC 2119</xref> and indicate requirement levels for
compliant implementations.</t>

</section>

<section title='Architecture' anchor='architecture'>

<t>The primary use envisioned for this mechanism is for multimedia
  conferences controlled by a central system.  This is similar to the
  topologies described by <xref target='RFC5117'>RTP Topologies</xref>
  as Topo-Mixer, Topo-Video-switch-MCU, or Topo-RTCP-terminating-MCU
  (depending on the treatment of RTCP), with one crucial difference:
  rather than only forwarding either a single media source, or an
  MCU-mixed media source, to receivers, the central mixer can
  instead simultaneously forward multiple media sources independently
  to each receiver, as constrained by available
  bandwidth.</t>

<t>In this architecture, the conference server can notify each
  participant as sources become available in the conference.
  Participants can then either explicitly request sources from the
  server, or allow the server to choose which sources to forward based
  on its own criteria and policy. A hybrid mode is also possible, in
  which participants explicitly request some sources while allowing
  the server to choose others.</t>

<t>Receivers can specify parameters for how they wish to view 
  sources, e.g., the image size or frame
  rate in which they will display video sources.  They can also
  specify priority among sources in case
  the server has insufficient bandwidth to send them all.</t>

<t>When the first receiver starts viewing a source, the conference server tells
  the sender to start sending it; prior to this, the sender does not
  send it.  Similarly, when the last receiver stops viewing a source,
  the server tells the sender to stop sending it.</t>

<t>For large conferences, sending each conference source over a separate RTP
  session, each with its own m= line, would not be practical, due to
  issues such as server port consumption, NAT binding exhaustion, and
  ICE setup time.  Thus, sources of the same media type are instead
  sent over a single RTP session, distinguished by their SSRC.  This
  document defines the source negotiation mechanisms needed in SDP to
  enable the mechanisms defined in this architecture.</t>

</section>

<section title='Overview' anchor='overview'>

<t>This mechanism builds upon the declarative source definitions
  defined in <xref target='RFC5576' />.  That document defines how
  to describe individual RTP sources within an RTP session in
  SDP.  Each source is identified by its Synchronization Source
  (SSRC) identifier, and is associated with its CNAME
  (canonical-name) SDP attribute.</t>

<t>To enable the architecture defined in <xref target='architecture' />,
  this document defines a complementary SDP media attribute which
  allows the receiver of some RTP sources to let the the sources'
  sender know which sources the receiver would like to receive.  This
  attribute, "remote-ssrc", is defined in
  <xref target='remote_ssrc_attribute' />.</t>

<t>A simple example SDP exchange using this mechanism is shown in
  <xref target='example_sender' /> and <xref target='example_receiver'
  />.  For brevity, only the relevant portions of the media sections
  of the SDP descriptions are given.</t>

<figure anchor="example_sender" title="Notification of media sources">
<artwork>
m=video 49168 RTP/AVP 96
a=rtpmap:96 H264/90000
a=ssrc:12345 cname:user1@host1.example.com
a=ssrc:67890 cname:user2@host2.example.com
</artwork>
</figure>

<t>In <xref target='example_sender' /> an SDP description indicates, using
  the mechanisms of <xref target='RFC5576' />, two sources that are
  available in an RTP session.</t>

<figure anchor="example_receiver" title="Request for a media source.">
<artwork>
m=video 49170 RTP/AVP 96
a=rtpmap:96 H264/90000
a=remote-ssrc:12345 recv:on
a=remote-ssrc:12345 imageattr:* [x=720,y=576]
a=remote-ssrc:12345 framerate:15
</artwork>
</figure>

<t>In <xref target='example_receiver' /> an SDP description sent in response
  requests that a specific source be sent, with resolution 720 by 576
  and a framerate of 15 frames per second.</t>

</section>

<section title='The "remote-ssrc" Media Attribute' anchor='remote_ssrc_attribute'>

<t>The "remote-ssrc" SDP media-level attribute allows a receiver to
  requested a specific a remote source.</t>

<figure>
<artwork>
<![CDATA[
a=remote-ssrc:<ssrc-id> <attribute>
a=remote-ssrc:<ssrc-id> <attribute>:<value>
]]>
</artwork>
</figure>

<t>The SDP media attribute "remote-ssrc" indicates a property, known as a
"remote source-level attribute", of a
remote media source (RTP stream) within an RTP session.  <![CDATA[<ssrc-id>]]>
is the synchronization source ID (SSRC) of the remote source being described,
interpreted as a 32-bit unsigned integer in network byte order and
represented in decimal.
<![CDATA[<attribute>]]> or <![CDATA[<attribute>:<value>]]> represent
the source-level receive attribute specific to the given remote media source.
The source-level receive attribute follows the
syntax of the SDP "a=" line.  It thus
consists either of a single attribute name (a flag), or an attribute
name and value, e.g., "framerate:30".  No
attributes of the former type are defined by this document.
The order of multiple "remote-ssrc" media attributes within an SDP
message is not significant.</t>

<t>These remote source IDs correspond to sources
in the RTP session that may be sent by other session members.  The
  author of the SDP message may have learned about these sources by
  observing them in the RTP session (either by receiving RTP packets
  or seeing RTCP reports about them), from earlier SDP messages
  containing "ssrc" attributes describing the sources, or from other
  means such as the <xref target='RFC4575'>SIP conference event
	package</xref> or the <xref target='RFC6502'>XCON
	conference event package</xref>.</t>

<t>The "remote-ssrc" media attribute may be used for any RTP-based media
transport.  It is not defined for other transport protocols.</t>

<t>Though the remote source attributes specified by the "remote-ssrc" property
follow the same syntax as (local) source attributes,
they are defined independently.  All remote source attributes MUST be
registered with IANA, using the registry defined in <xref
target='iana_remote_source_attributes' />.</t>

<t><xref target='remote_ssrc_grammar' /> in <xref target='grammar' /> gives a
formal <xref target='RFC5234'>Augmented Backus-Naur Form (ABNF)</xref>
grammar for the ssrc attribute.</t>

<t>The "remote-ssrc" media attribute does not (itself) depend on
  the SDP charset, though specific remote source attributes may be
  defined to be.</t>

</section>

<section title="Remote Source Attributes" anchor='remote_source_attributes'>

<t>This section defines several specific remote source-level
  attributes that can be applied to RTP sources.</t>

<section title='The "recv" Remote Source-Level Attribute'
anchor='recv_attribute'>

<figure>
<artwork>
<![CDATA[
a=remote-ssrc:<ssrc> recv:<state>
]]>
</artwork>
</figure>

<t>The "recv" remote source attribute indicates whether the author of
  an SDP message is interested in receiving a source.  A "recv" remote
  source attribute with a <![CDATA[<state>]]> value of "on" indicates a
  source that the author of an SDP message is interested in receiving.
  Similarly, a "recv" remote source attribute with a <![CDATA[<state>]]> value
  of "off" indicates a
  source that the author of an SDP message is not interested in receiving.
  There MUST be at most one
  "recv" remote source-level attribute per remote
  media source.    A
  "recv" attribute with a <![CDATA[<state>]]> value other than
  "on" or "off" MUST be ignored (for future extensibility).</t>

<t>If the media stream containing the source has the media attributes
  "sendonly" or "inactive", the SDP message MUST NOT list any remote sources
  with a "recv" attribute with the <![CDATA[<state>]]> "on" for that
  media stream.</t>

<t>If "remote-ssrc" attributes are given for a particular remote
  source, but "recv" is not specified for it,
  "recv:on" is the default if the media stream is "sendrecv" or
  "recvonly".</t>

<t>If no remote-ssrc attributes at all are listed for a particular
  remote source, the choice of whether to send it is left at the
  sender's discretion.  However, for sources associated in
  with an <xref target='RFC5576'>"ssrc-group"</xref>, any unlisted
  sources of a group SHOULD be treated the same as any listed ones if
  the requests are consistent, unless the semantics specified for the
  "ssrc-group" dictates otherwise.</t>

<t><xref target='recv_grammar' /> in <xref target='grammar'
/> gives a formal <xref target='RFC5234'>Augmented Backus-Naur Form
(ABNF)</xref> grammar for the "recv" attribute.</t>

<t><xref target='offer-answer' /> describes how the "recv" remote
  source attribute is used with <xref target='RFC3264'>SDP offer/answer</xref>.</t>

<t>The "recv" remote source attribute does not
  depend on the SDP charset.</t>

</section>

<section title='The "framerate" Remote Source Attribute'
anchor='framerate_attribute'>

<figure>
<artwork>
<![CDATA[
a=remote-ssrc:<ssrc> framerate:<frame rate>
]]>
</artwork>
</figure>

<t>The "framerate" remote source-level attribute gives the maximum frame
  rate, in frames per second, which the receiver of a video source
  would like receive for the
  video.  Higher framerates are likely not to be useful to the
  receiver.  This attribute is
  analogous in function and syntax to the <xref target="RFC4566">SDP
  "framerate" media
  attribute</xref>. Decimal representations of fractional values using
  the notation "&lt;integer>.&lt;fraction>" are allowed.  The frame
  rate specified MUST be greater than zero.</t>

<t>The "framerate" attribute is advisory; a sender MAY send a
  framerate other than that requested by the receiver if it is not
  able to send the framerate required. The sender SHOULD attempt to
  come as close as it can to the requested framerate, subject to
  other constraints of the system.</t>

<t>The "framerate" attribute is defined only for video media. There
  MUST be at most one "framerate" remote source attribute per remote
  media source.  The "framerate" requested MUST NOT be inconsistent
  with any fmtp parameters specified for the media stream's payload
  types.</t>

<t><xref target='framerate_grammar' /> in <xref target='grammar' />
  gives a formal <xref target='RFC5234'>Augmented Backus-Naur Form 
(ABNF)</xref> grammar for the "framerate" attribute.</t>

<t>The "framerate" remote source attribute does not depend on the SDP
  charset.</t>

</section>

<section title='The "imageattr" Remote Source Attribute'
anchor='imageattr_attribute'>

<figure>
<artwork>
<![CDATA[
a=remote-ssrc:<ssrc> imageattr:<PT> <attr_list>
]]>
</artwork>
</figure>

<t>The "imageattr" remote source-level attribute describes the
  image resolution and other image characteristics with which a video
  source would like receive the video.  Larger resolutions are likely
  not to be useful to the receiver.  It is
  analogous in function and syntax to the "recv" portion of
  the <xref target="RFC6236">SDP "imageattr"
  media attribute</xref>.</t>

<t>The "imageattr" attribute is advisory; a sender MAY send a
  resolution other than that requested by the receiver if it is not
  able to send the resolution required.  The sender SHOULD attempt to
  come as close as it can to the requested resolution, subject to
  other constraints of the system.</t>

<t>Different image attributes MAY be defined per payload type defined
  in the media stream.  The <![CDATA[<PT>]]> parameter MAY either
  be one of the media formats (RTP payload types) specified for
  the media stream, or the character "*" indicating that the
  "imageattr" attribute applies to all payload types of the
  session.</t>

<t>The <![CDATA[<attr_list>]]> parameter gives a list of resolutions
  and image aspect ratios with which the receiver wishes to display
  the source.  It is described in detail
  in <xref target="RFC6236" />.</t>

<t>The "imageattr" attribute is defined only for video media. There
  MUST be at most one "imageattr" remote source attribute per payload
  type per remote media source.  If an "imageattr" attribute is
  present with a PT value of "*", it MUST be the only "imageattr"
  attribute defined for that remote media source. The "imageattr"
  requested MUST NOT be inconsistent with any fmtp parameters
  specified for the media stream's payload types.</t>

<t><xref target='imageattr_grammar' /> in <xref target='grammar' />
  gives a formal <xref target='RFC5234'>Augmented Backus-Naur Form
(ABNF)</xref> grammar for the "imageattr" attribute.</t>

<t>The "imageattr" remote source attribute does not depend on the SDP
  charset.</t>

</section>

<section title='The "priority" Remote Source Attribute'
anchor='priority_attribute'>

<figure>
<artwork>
<![CDATA[
a=remote-ssrc:<ssrc> priority:<priority>
]]>
</artwork>
</figure>

<t>The "priority" remote source-level attribute gives the relative
  priority among the remote sources requested by a receiver.  The
  <![CDATA[<priority>]]> parameter is a non-negative decimal integer indicating
  which streams should be given higher preference if the sender
  determines that there is insufficient bandwidth (or other resource)
  available to transmit all the requested streams.  Larger numbers
  indicate a greater priority.  Priority values MUST be less than
  2**31 - 1, but otherwise their specific values have no semantic
  significance.</t>

<t><xref target='priority_grammar' /> in <xref target='grammar' />
  gives a formal <xref target='RFC5234'>Augmented Backus-Naur Form 
(ABNF)</xref> grammar for the "priority" attribute.</t>

<t>The "priority" remote source attribute does not depend on the SDP
  charset.</t>

</section>

</section>

<section title="Source Attributes" anchor='source_attributes'>

<t>This section describes sending source attributes that a sender can
  use to describe RTP sources.</t>

<section title='The "information" Source Attribute'
anchor='information_attribute'>

<figure>
<artwork>
<![CDATA[
a=ssrc:<ssrc> information:<source description>
]]>
</artwork>
</figure>

<t>The "information" source attribute provides textual information
about a source.  It is analogous in function and syntax to the SDP
  "i=" field for session and
media information.  There MUST be at most one "information" source
attribute per media source.  If the "charset" attribute is present at
the session or media level, it specifies the character set
used in the source description.  If the "charset" attribute is not
present, the "information" attribute MUST contain ISO 10646 characters
in UTF-8 encoding.</t>

<t>The "information" attribute is intended to provide a free-form
human-readable description of a media source.  It is not suitable for
parsing by automata.</t>

<t><xref target='information_grammar' /> in <xref target='grammar'
/> gives a formal <xref target='RFC5234'>Augmented Backus-Naur Form
(ABNF)</xref> grammar for the "information" attribute.</t>

</section>

<section title='The "sending" Source-Level Attribute'
anchor='sending_attribute'>

<figure>
<artwork>
<![CDATA[
a=ssrc:<ssrc> sending:<state>
]]>
</artwork>
</figure>

<t>The "sending" remote source attribute indicates whether the author of
  an SDP message is interested in currently actively sending a source,
  due to it having been requested by the other party with a "recv"
  remote source attribute in an SDP offer/answer exchange.
  A "sending" source attribute with a <![CDATA[<state>]]> value of
  "on" indicates a
  source that the author of an SDP message is currently actively
  sending, due to it having been requested by the other party with a
  "recv:on" remote source attribute.
  Similarly, the "sending" source attribute with a
  <![CDATA[<state>]]> value of "off" indicates a source
  that the other party has rejected with a previous the "recv:off"
  remote source attribute, or that the author of the SDP message is no longer interested in sending.
  There MUST be at most one
  "sending" source-level attribute per media source.
  Sources which were not listed with "recv-ssrc" in the previous offer
  or answer SHOULD NOT have a "sending" attribute included.  The "sending"
  attribute is only defined in
  the context of <xref target='RFC3264'>SDP offer/answer</xref>.  A
  "sending" attribute with a <![CDATA[<state>]]> value other than
  "on" or "off" MUST be ignored (for future extensibility).</t>

<t>If the media stream containing the source has the media attributes
  "recvonly" or "inactive", the stream MUST NOT list any sources
  with the "sending" attribute with the <![CDATA[<state>]]> on.</t>

<t>A source that is indicated in an offer or answer with "sending:off"
  SHOULD still be considered a member of the RTP session, and thus
  RTCP SHOULD be sent for it, unless it has left the RTP session (with
  an RTCP BYE message) subsequent to the sending of the offer or
  answer.</t>

<t><xref target='sending_grammar' /> in <xref target='grammar'
/> gives a formal <xref target='RFC5234'>Augmented Backus-Naur Form
(ABNF)</xref> grammar for the "sending" attribute.</t>

<t>Further description of how the "sending" source
  attribute is used with <xref target='RFC3264'>SDP
  offer/answer</xref> is given in <xref target='offer-answer' />.</t>

<t>The "sending" source attribute is not
  dependent on charset.</t>

</section>

</section>


<section title='Usage With the Offer/Answer Model'
anchor='offer-answer'>

<t>When used with <xref target='RFC3264'>the SDP Offer/Answer
  Model</xref>, the "remote-ssrc" attribute MAY be included either in an
  SDP offer or answer.  Both offers and answers MAY contain both
  "ssrc" and "remote-ssrc" media attributes.</t>

<t>If "remote-ssrc" attributes are present in an SDP offer, the
  answerer (if it accepts the offer) MUST include all the
  remotely-requested active sources in "ssrc" attributes in its
  answer, except for any sources which are no longer available when
  the answer is sent.  If "remote-ssrc" attributes are present in an answer, no
  immediate update to SDP is necessary; however, if the endpoint
  subsequently sends a new SDP offer, it SHOULD include all
  the remotely-requested sources from the previous offer/answer
  exchange, unless those sources are no longer available.
  In both cases, remote sources with the "recv:on" remote source
  attribute included (implicitly or explicitly) MUST be listed in
  the next response -- with the "sending:on" local source attribute if
  the sender accepted the request to send the source, or "sending:off"
  if the sender does not wish to send the source.  Remote
  sources with the "recv:off" remote source attribute MUST have the
  "sending:off" local source attribute.  If the send/recv mode
  of the media stream has changed to "recvonly" or "inactive",
  sources MUST NOT be listed with the "sending:on" attribute, and thus all
  remotely-requested sources MUST be listed as "sending:off" instead.</t>

<t>If a sender receives a "recv:on" in an answer and does not wish to
  send the source, it SHOULD send a updated offer with "sending:off"
  as soon as is practical.  If a sender wishes to stop sending a
  source for which its previous offer or answer had included
  "sending:on", it SHOULD send an updated offer with "sending:off" as
  soon as practical, and MUST include "sending:off" for the source in
  its next offer or answer (assuming the source is still in the
  session, and it still wishes not to send the source by the time of
  the offer or answer).</t>

<t>In general, all participants in an offer/answer exchange SHOULD
  list all currently available sources,
  unless information about available sources is being provided through some
  other mechanism, such as the <xref target='RFC4575'>SIP conference
  event package</xref> or the
  <xref target='RFC6502'>XCON conference event
  package</xref>.  (Because these event packages support partial
  updates, whereas SDP does not, source notification through event
  packages can be more efficient, where applicable, than SDP can
  be.)  In the latter case sources that were
  not explicitly requested in the most recent SDP offer or answer MAY
  be omitted.</t>

</section>

<section title='Backward Compatibility' anchor='backward'>

<t>The default behavior, for remote sources which are listed neither
 as "recv:on" nor "recv:off", is that whether sources are to be sent
 is left to the sender's discretion.  This is also the implicit
 behavior for standard RTP; thus, a device does not need to know, upon
 receiving an SDP message containing no "remote-ssrc" attributes,
 whether its peer does not understand the "remote-ssrc" attribute at
 all, or is simply choosing to leave source selection up to the
 sender's discretion.</t>

<t>Because offer/answer exchanges are required to include "sending"
  source attributes in response to previous "recv" remote source
  attributes, it is possible to determine based on an SDP answer, or
  on a subsequent offer/answer exchange, whether the peer understands
  the "remote-ssrc" attribute.</t>

</section>

<section title='Formal Grammar' anchor='grammar'>

<t>This section gives a formal <xref target='RFC5234'>Augmented
Backus-Naur Form (ABNF)</xref> grammar for each of the new media and
source attributes defined in this document.  Grammars for existing
session or media attributes which have been extended to be source
attributes are not included.</t>

<figure anchor="remote_ssrc_grammar" title="Syntax of the &quot;remote-ssrc&quot; media attribute">
<artwork>
remote-ssrc-attr = "remote-ssrc:" ssrc-id SP attribute
; The base definition of "attribute" is in RFC 4566.
; (It is the content of "a=" lines.)
ssrc-id = integer ; 0 .. 2**32 - 1

attribute =/ remote-ssrc-attr
</artwork>
</figure>

<figure anchor="recv_grammar" title="Syntax of the &quot;recv&quot;
and &quot;inactive&quot; receive source attributes">
<artwork>
recv-attr = "recv:" recv-state

recv-state = "on" / "off" / token

attribute =/ recv-attr
</artwork>
</figure>

<figure anchor="framerate_grammar" title="Syntax of the &quot;framerate&quot;
receive source attribute">
<artwork>
framerate-attr = "framerate:" integer [ "." 1*DIGIT ]

attribute =/ framerate-attr
</artwork>
</figure>

<figure anchor="imageattr_grammar" title="Syntax of the &quot;imageattr&quot;
receive source attribute">
<artwork>
imageattr-attr = "imageattr:" PT WSP attr_list
; The definition of PT and attr_list are in
; [RFC6236]

attribute =/ imageattr-attr
</artwork>
</figure>

<figure anchor="priority_grammar" title="Syntax of the &quot;priority&quot;
receive source attribute">
<artwork>
priority-attr = "priority:" integer

attribute =/ priority-attr
</artwork>
</figure>

<figure anchor="information_grammar" title="Syntax of the &quot;information&quot;
source attribute">
<artwork>
information-attr = "information:" text
; The definition of text is in [RFC4566]

attribute =/ information-attr
</artwork>
</figure>

<figure anchor="sending_grammar" title="Syntax of the &quot;sending&quot;
and &quot;inactive&quot; source attributes">
<artwork>
sending-attr = "sending:" sending-state

sending-state = "on" / "off" / token

attribute =/ sending-attr
</artwork>
</figure>

</section>

<section title='Security Considerations' anchor='security'>

<t>All the security considerations of <xref target='RFC3550'>RTP</xref>
and of <xref target='RFC4566'>SDP</xref> apply.  Explicitly requesting
sources of an RTP media stream does not appear to add further security
issues.</t>

</section>

<section title='IANA Considerations' anchor='iana'>

<section title='New SDP Media-Level Attributes'>

<t>This document defines a new SDP media-level attribute,
  "remote-ssrc". This attribute should be registered by IANA under
  "Session Description Protocol (SDP) Parameters" under "att-field
  (media level only)".</t>

<t>The "remote-ssrc" attribute is used to identify characteristics of
  remote media sources within a media stream.  Its format is defined in
  <xref target='remote_ssrc_attribute' />.</t>

</section>

<section title='New SDP Source-Level Attributes'>

<t>This document defines two new SDP source-level attributes,
  "information" and "sending".  These attributes should be
  registered by IANA under "Session Description Protocol (SDP)
  Parameters" under "att-field (source level)".  Their format is defined
  in <xref target='source_attributes' />.</t>

</section>

<section title='Registry for Remote Source-Level Attributes' anchor='iana_remote_source_attributes'>

<t>This specification creates a new IANA registry named "att-field
  (remote source level)" within the SDP parameters registry.  Remote source
  attributes MUST be registered with IANA and documented, under the
  same rules as for SDP source-level attributes as
  specified in <xref target='RFC5576' />:</t>

<t>New attribute registrations are accepted according to the
   "Specification Required" policy of <xref target='RFC5226' />,
   provided that the specification includes the following information:</t>

<t><list style='symbols'>
  <t>contact name, email address, and telephone number</t>
  <t>attribute name (as it will appear in SDP)</t>
  <t>long-form attribute name in English</t>
  <t>whether the attribute value is subject to the charset attribute</t>
  <t>a one-paragraph explanation of the purpose of the attribute</t>
  <t>a specification of appropriate attribute values for this attribute</t>
</list></t>

  <t>The above is the minimum that IANA will accept.  Attributes that are
   expected to see widespread use and interoperability SHOULD be
   documented with a standards-track RFC that specifies the attribute
   more precisely.</t>

   <t>Submitters of registrations should ensure that the specification is
   in the spirit of SDP attributes, most notably that the attribute is
   platform independent in the sense that it makes no implicit
   assumptions about operating systems and does not name specific pieces
   of software in a manner that might inhibit interoperability.</t>

   <t>Remote source-level attributes which are substantially similar in
   semantics to existing source-level, session-level or media-level attributes
   SHOULD re-use the same attribute name as those attributes.
   Remote source-level attributes SHOULD NOT re-use
   attribute names of other level attributes that are
   unrelated or substantially different.</t>

<t>The initial set of remote source attribute names, with definitions in
  <xref target='remote_source_attributes' /> of this document, is in
  <xref target='remote_source_attributes_initial' />.</t>

<figure anchor='remote_source_attributes_initial' title='Initial Contents of IANA Remote Source Attribute Registry'>
<artwork>
Type            SDP Name                     Reference
----            ------------------           ---------
att-field (remote source level)
                recv                        [RFC&rfc.number;]
                framerate                   [RFC&rfc.number;]
                imageattr                   [RFC&rfc.number;]
                priority                    [RFC&rfc.number;]
</artwork>
</figure>

<t>(Note to the RFC-Editor: please replace "&rfc.number;" with the
number of this document prior to publication as an RFC.)</t>

</section>

</section>

</middle>

<back>

<references title='Normative References'>

&abnf;

&offeranswer;

&rfc2119;

&rfc5226;

&rtp;

&sdp;

&sourceattr;

&imageattr;

</references>

<references title='Informative References'>

&rtptopo;

&sipconfpkg;

&xconconfpkg;

</references>

<section title='Open issues'>

<t><list style='symbols'>

<t>Does the model described in <xref target='offer-answer' />, where
  sources can be requested in an an answer and responded to in a
  subsequent offer or answer, actually work for all failure cases?  Or
  do we need a full bi-directional offer/answer exchange?</t>

</list></t>

</section>

<section title='Changes From Earlier Versions'>

<t>Note to the RFC-Editor: please remove this section prior to publication
as an RFC.</t>

<section title='Changes From Individual Submission Draft -04'>

<t>Document refresh; reference updates only.</t>

</section>

<section title='Changes From Individual Submission Draft -03'>

<t>Changed logic to indicate that it is valid to reject a "recv:on"
  request with "sending:off", either immediately or at a subsequent time.</t>

<t>Clarified that sources with "sending:off" are still members of the
  RTP session, and so still have RTCP sent for them.</t>

</section>

<section title='Changes From Individual Submission Draft -02'>

<t>Document refresh; reference updates only.</t>

</section>

<section title='Changes From Individual Submission Draft -01'>

<t><list style='symbols'>

<t>Clarified backward compatibility discussion.</t>

<t>Minor editorial improvements.</t>

</list></t>

</section>

<section title='Changes From Individual Submission Draft -00'>

<t><list style='symbols'>

<t>The "recv" and "inactive" remote source attributes have been
  changed to "recv:on" and "recv:off" respectively.  Similarly,
  the "send" and "inactive" source attributes have been changed to
  "sending:on" and "sending:off".</t>

<t>Clarified that "imageattr" and "framerate" parameters are
  advisory, and MUST NOT be inconsistent with payload type parameters.</t>

<t>Tightened some SHOULD requirements to be MUST, and clarified when others
apply.</t>

<t>Tightened up ABNF grammar (e.g., to eliminate leading 0 values from
  integers).</t>

<t>Added Henning Schulzrinne as co-author.</t>

<t>Numerous editorial improvements.</t>

</list></t>

</section>

</section>

</back>

</rfc>
