MMUSIC                                                         J. Lennox
Internet-Draft                                                     Vidyo
Intended status: Standards Track                          H. Schulzrinne
Expires: April 25, 2013                                      Columbia U.
                                                        October 22, 2012


    Mechanisms for Media Source Selection in the Session Description
                             Protocol (SDP)
              draft-lennox-mmusic-sdp-source-selection-05

Abstract

   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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 25, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Lennox & Schulzrinne     Expires April 25, 2013                 [Page 1]


Internet-Draft        Media Source Selection in SDP         October 2012


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  The "remote-ssrc" Media Attribute  . . . . . . . . . . . . . .  5
   6.  Remote Source Attributes . . . . . . . . . . . . . . . . . . .  6
     6.1.  The "recv" Remote Source-Level Attribute . . . . . . . . .  6
     6.2.  The "framerate" Remote Source Attribute  . . . . . . . . .  7
     6.3.  The "imageattr" Remote Source Attribute  . . . . . . . . .  8
     6.4.  The "priority" Remote Source Attribute . . . . . . . . . .  8
   7.  Source Attributes  . . . . . . . . . . . . . . . . . . . . . .  9
     7.1.  The "information" Source Attribute . . . . . . . . . . . .  9
     7.2.  The "sending" Source-Level Attribute . . . . . . . . . . .  9
   8.  Usage With the Offer/Answer Model  . . . . . . . . . . . . . . 10
   9.  Backward Compatibility . . . . . . . . . . . . . . . . . . . . 11
   10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 12
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
     12.1. New SDP Media-Level Attributes . . . . . . . . . . . . . . 13
     12.2. New SDP Source-Level Attributes  . . . . . . . . . . . . . 13
     12.3. Registry for Remote Source-Level Attributes  . . . . . . . 14
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     13.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Appendix A.  Open issues . . . . . . . . . . . . . . . . . . . . . 16
   Appendix B.  Changes From Earlier Versions . . . . . . . . . . . . 16
     B.1.  Changes From Individual Submission Draft -04 . . . . . . . 16
     B.2.  Changes From Individual Submission Draft -03 . . . . . . . 16
     B.3.  Changes From Individual Submission Draft -02 . . . . . . . 16
     B.4.  Changes From Individual Submission Draft -01 . . . . . . . 17
     B.5.  Changes From Individual Submission Draft -00 . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17













Lennox & Schulzrinne     Expires April 25, 2013                 [Page 2]


Internet-Draft        Media Source Selection in SDP         October 2012


1.  Introduction

   The source-attribute specification [RFC5576] provides declarative
   definitions for Real-Time Protocol (RTP) [RFC3550] media sources in
   the Session Description Protocol (SDP) [RFC4566].

   In some architectures (such as those described in Section 3), 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.

   Additionally, several new declarative ([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.


2.  Terminology

   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 RFC 2119 [RFC2119] and
   indicate requirement levels for compliant implementations.


3.  Architecture

   The primary use envisioned for this mechanism is for multimedia
   conferences controlled by a central system.  This is similar to the
   topologies described by RTP Topologies [RFC5117] 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.

   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



Lennox & Schulzrinne     Expires April 25, 2013                 [Page 3]


Internet-Draft        Media Source Selection in SDP         October 2012


   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.

   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.

   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.

   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.


4.  Overview

   This mechanism builds upon the declarative source definitions defined
   in [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.

   To enable the architecture defined in Section 3, 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 Section 5.

   A simple example SDP exchange using this mechanism is shown in
   Figure 1 and Figure 2.  For brevity, only the relevant portions of
   the media sections of the SDP descriptions are given.

   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

                  Figure 1: Notification of media sources



Lennox & Schulzrinne     Expires April 25, 2013                 [Page 4]


Internet-Draft        Media Source Selection in SDP         October 2012


   In Figure 1 an SDP description indicates, using the mechanisms of
   [RFC5576], two sources that are available in an RTP session.

   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

                   Figure 2: Request for a media source.

   In Figure 2 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.


5.  The "remote-ssrc" Media Attribute

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


   a=remote-ssrc:<ssrc-id> <attribute>
   a=remote-ssrc:<ssrc-id> <attribute>:<value>


   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. <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. <attribute> or <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.

   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 SIP
   conference event package [RFC4575] or the XCON conference event
   package [RFC6502].



Lennox & Schulzrinne     Expires April 25, 2013                 [Page 5]


Internet-Draft        Media Source Selection in SDP         October 2012


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

   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 Section 12.3.

   Figure 3 in Section 10 gives a formal Augmented Backus-Naur Form
   (ABNF) [RFC5234] grammar for the ssrc attribute.

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


6.  Remote Source Attributes

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

6.1.  The "recv" Remote Source-Level Attribute


   a=remote-ssrc:<ssrc> recv:<state>


   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 <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 <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 <state> value other than "on" or "off" MUST be ignored (for
   future extensibility).

   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 <state> "on" for that media
   stream.

   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".

   If no remote-ssrc attributes at all are listed for a particular



Lennox & Schulzrinne     Expires April 25, 2013                 [Page 6]


Internet-Draft        Media Source Selection in SDP         October 2012


   remote source, the choice of whether to send it is left at the
   sender's discretion.  However, for sources associated in with an
   "ssrc-group" [RFC5576], 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.

   Figure 4 in Section 10 gives a formal Augmented Backus-Naur Form
   (ABNF) [RFC5234] grammar for the "recv" attribute.

   Section 8 describes how the "recv" remote source attribute is used
   with SDP offer/answer [RFC3264].

   The "recv" remote source attribute does not depend on the SDP
   charset.

6.2.  The "framerate" Remote Source Attribute


   a=remote-ssrc:<ssrc> framerate:<frame rate>


   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 SDP "framerate" media attribute [RFC4566].
   Decimal representations of fractional values using the notation
   "<integer>.<fraction>" are allowed.  The frame rate specified MUST be
   greater than zero.

   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.

   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.

   Figure 5 in Section 10 gives a formal Augmented Backus-Naur Form
   (ABNF) [RFC5234] grammar for the "framerate" attribute.

   The "framerate" remote source attribute does not depend on the SDP
   charset.



Lennox & Schulzrinne     Expires April 25, 2013                 [Page 7]


Internet-Draft        Media Source Selection in SDP         October 2012


6.3.  The "imageattr" Remote Source Attribute


   a=remote-ssrc:<ssrc> imageattr:<PT> <attr_list>


   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 SDP "imageattr" media attribute [RFC6236].

   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.

   Different image attributes MAY be defined per payload type defined in
   the media stream.  The <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.

   The <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 [RFC6236].

   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.

   Figure 6 in Section 10 gives a formal Augmented Backus-Naur Form
   (ABNF) [RFC5234] grammar for the "imageattr" attribute.

   The "imageattr" remote source attribute does not depend on the SDP
   charset.

6.4.  The "priority" Remote Source Attribute


   a=remote-ssrc:<ssrc> priority:<priority>





Lennox & Schulzrinne     Expires April 25, 2013                 [Page 8]


Internet-Draft        Media Source Selection in SDP         October 2012


   The "priority" remote source-level attribute gives the relative
   priority among the remote sources requested by a receiver.  The
   <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.

   Figure 7 in Section 10 gives a formal Augmented Backus-Naur Form
   (ABNF) [RFC5234] grammar for the "priority" attribute.

   The "priority" remote source attribute does not depend on the SDP
   charset.


7.  Source Attributes

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

7.1.  The "information" Source Attribute


   a=ssrc:<ssrc> information:<source description>


   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.

   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.

   Figure 8 in Section 10 gives a formal Augmented Backus-Naur Form
   (ABNF) [RFC5234] grammar for the "information" attribute.

7.2.  The "sending" Source-Level Attribute


   a=ssrc:<ssrc> sending:<state>



Lennox & Schulzrinne     Expires April 25, 2013                 [Page 9]


Internet-Draft        Media Source Selection in SDP         October 2012


   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 <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
   <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
   SDP offer/answer [RFC3264].  A "sending" attribute with a <state>
   value other than "on" or "off" MUST be ignored (for future
   extensibility).

   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 <state> on.

   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.

   Figure 9 in Section 10 gives a formal Augmented Backus-Naur Form
   (ABNF) [RFC5234] grammar for the "sending" attribute.

   Further description of how the "sending" source attribute is used
   with SDP offer/answer [RFC3264] is given in Section 8.

   The "sending" source attribute is not dependent on charset.


8.  Usage With the Offer/Answer Model

   When used with the SDP Offer/Answer Model [RFC3264], 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.

   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



Lennox & Schulzrinne     Expires April 25, 2013                [Page 10]


Internet-Draft        Media Source Selection in SDP         October 2012


   "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.

   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).

   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
   SIP conference event package [RFC4575] or the XCON conference event
   package [RFC6502].  (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.


9.  Backward Compatibility

   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.

   Because offer/answer exchanges are required to include "sending"



Lennox & Schulzrinne     Expires April 25, 2013                [Page 11]


Internet-Draft        Media Source Selection in SDP         October 2012


   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.


10.  Formal Grammar

   This section gives a formal Augmented Backus-Naur Form (ABNF)
   [RFC5234] 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.

   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

           Figure 3: Syntax of the "remote-ssrc" media attribute


   recv-attr = "recv:" recv-state

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

   attribute =/ recv-attr

       Figure 4: Syntax of the "recv" and "inactive" receive source
                                attributes


   framerate-attr = "framerate:" integer [ "." 1*DIGIT ]

   attribute =/ framerate-attr

       Figure 5: Syntax of the "framerate" receive source attribute


   imageattr-attr = "imageattr:" PT WSP attr_list
   ; The definition of PT and attr_list are in
   ; [RFC6236]

   attribute =/ imageattr-attr

       Figure 6: Syntax of the "imageattr" receive source attribute



Lennox & Schulzrinne     Expires April 25, 2013                [Page 12]


Internet-Draft        Media Source Selection in SDP         October 2012


   priority-attr = "priority:" integer

   attribute =/ priority-attr

        Figure 7: Syntax of the "priority" receive source attribute


   information-attr = "information:" text
   ; The definition of text is in [RFC4566]

   attribute =/ information-attr

          Figure 8: Syntax of the "information" source attribute


   sending-attr = "sending:" sending-state

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

   attribute =/ sending-attr

    Figure 9: Syntax of the "sending" and "inactive" source attributes


11.  Security Considerations

   All the security considerations of RTP [RFC3550] and of SDP [RFC4566]
   apply.  Explicitly requesting sources of an RTP media stream does not
   appear to add further security issues.


12.  IANA Considerations

12.1.  New SDP Media-Level Attributes

   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)".

   The "remote-ssrc" attribute is used to identify characteristics of
   remote media sources within a media stream.  Its format is defined in
   Section 5.

12.2.  New SDP Source-Level Attributes

   This document defines two new SDP source-level attributes,
   "information" and "sending".  These attributes should be registered



Lennox & Schulzrinne     Expires April 25, 2013                [Page 13]


Internet-Draft        Media Source Selection in SDP         October 2012


   by IANA under "Session Description Protocol (SDP) Parameters" under
   "att-field (source level)".  Their format is defined in Section 7.

12.3.  Registry for Remote Source-Level Attributes

   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
   [RFC5576]:

   New attribute registrations are accepted according to the
   "Specification Required" policy of [RFC5226], provided that the
   specification includes the following information:

   o  contact name, email address, and telephone number
   o  attribute name (as it will appear in SDP)
   o  long-form attribute name in English
   o  whether the attribute value is subject to the charset attribute
   o  a one-paragraph explanation of the purpose of the attribute
   o  a specification of appropriate attribute values for this attribute

   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.

   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.

   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.

   The initial set of remote source attribute names, with definitions in
   Section 6 of this document, is in Figure 10.










Lennox & Schulzrinne     Expires April 25, 2013                [Page 14]


Internet-Draft        Media Source Selection in SDP         October 2012


   Type            SDP Name                     Reference
   ----            ------------------           ---------
   att-field (remote source level)
                   recv                        [RFCXXXX]
                   framerate                   [RFCXXXX]
                   imageattr                   [RFCXXXX]
                   priority                    [RFCXXXX]

   Figure 10: Initial Contents of IANA Remote Source Attribute Registry

   (Note to the RFC-Editor: please replace "XXXX" with the number of
   this document prior to publication as an RFC.)


13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
              Media Attributes in the Session Description Protocol
              (SDP)", RFC 5576, June 2009.

   [RFC6236]  Johansson, I. and K. Jung, "Negotiation of Generic Image
              Attributes in the Session Description Protocol (SDP)",
              RFC 6236, May 2011.





Lennox & Schulzrinne     Expires April 25, 2013                [Page 15]


Internet-Draft        Media Source Selection in SDP         October 2012


13.2.  Informative References

   [RFC4575]  Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
              Initiation Protocol (SIP) Event Package for Conference
              State", RFC 4575, August 2006.

   [RFC5117]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
              January 2008.

   [RFC6502]  Camarillo, G., Srinivasan, S., Even, R., and J.
              Urpalainen, "Conference Event Package Data Format
              Extension for Centralized Conferencing (XCON)", RFC 6502,
              March 2012.


Appendix A.  Open issues

   o  Does the model described in Section 8, 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?


Appendix B.  Changes From Earlier Versions

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

B.1.  Changes From Individual Submission Draft -04

   Document refresh; reference updates only.

B.2.  Changes From Individual Submission Draft -03

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

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

B.3.  Changes From Individual Submission Draft -02

   Document refresh; reference updates only.







Lennox & Schulzrinne     Expires April 25, 2013                [Page 16]


Internet-Draft        Media Source Selection in SDP         October 2012


B.4.  Changes From Individual Submission Draft -01

   o  Clarified backward compatibility discussion.
   o  Minor editorial improvements.

B.5.  Changes From Individual Submission Draft -00

   o  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".
   o  Clarified that "imageattr" and "framerate" parameters are
      advisory, and MUST NOT be inconsistent with payload type
      parameters.
   o  Tightened some SHOULD requirements to be MUST, and clarified when
      others apply.
   o  Tightened up ABNF grammar (e.g., to eliminate leading 0 values
      from integers).
   o  Added Henning Schulzrinne as co-author.
   o  Numerous editorial improvements.


Authors' Addresses

   Jonathan Lennox
   Vidyo, Inc.
   433 Hackensack Avenue
   Seventh Floor
   Hackensack, NJ  07601
   US

   Email: jonathan@vidyo.com


   Henning Schulzrinne
   Columbia University Department of Computer Science
   450 Computer Science
   1214 Amsterdam Ave., Mailcode: 0401
   New York, NY  10027
   US

   Email: hgs@cs.columbia.edu
   URI:   http://www.cs.columbia.edu/~hgs/








Lennox & Schulzrinne     Expires April 25, 2013                [Page 17]