[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05

MMUSIC                                                         J. Lennox
Internet-Draft                                                     Vidyo
Intended status: Standards Track                            July 6, 2009
Expires: January 7, 2010


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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 7, 2010.

Copyright Notice

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




Lennox                   Expires January 7, 2010                [Page 1]


Internet-Draft        Media Source Selection in SDP            July 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   Source-Specific Media Attributes in the Session Description Protocol
   (SDP) provide a declarative mechanism by which endpoints can describe
   Real-Time Transport Protocol (RTP) sources within a media stream.
   This document extends that mechanism by defining mechanisms by which
   participants in a multimedia session can request specific sources
   from a remote party.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Motivating Architecture  . . . . . . . . . . . . . . . . . . .  3
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  The "remote-ssrc" Media Attribute  . . . . . . . . . . . . . .  5
   6.  Remote Source Attributes . . . . . . . . . . . . . . . . . . .  6
     6.1.  The "recv" and "inactive" Remote Source-Level
           Attributes . . . . . . . . . . . . . . . . . . . . . . . .  6
     6.2.  The "framerate" Remote Source Attribute  . . . . . . . . .  7
     6.3.  The "imageattr" Remote Source Attribute  . . . . . . . . .  7
     6.4.  The "priority" Remote Source Attribute . . . . . . . . . .  8
   7.  Source Attributes  . . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  The "information" Source Attribute . . . . . . . . . . . .  8
     7.2.  The "send" and "inactive" Source-Level Attributes  . . . .  9
   8.  Usage With the Offer/Answer Model  . . . . . . . . . . . . . . 10
   9.  Backward Compatibility . . . . . . . . . . . . . . . . . . . . 10
   10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 11
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
     12.1. New SDP Media-Level Attributes . . . . . . . . . . . . . . 12
     12.2. New SDP Source-Level Attributes  . . . . . . . . . . . . . 12
     12.3. Registry for Remote Source-Level Attributes  . . . . . . . 12
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     13.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Open issues . . . . . . . . . . . . . . . . . . . . . 15
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15






Lennox                   Expires January 7, 2010                [Page 2]


Internet-Draft        Media Source Selection in SDP            July 2009


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, it is useful to provide the capability for
   endpoints to request specific sources of a remote SDP party, to
   selectively enable and disable them.

   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", "inactive", "imageattr", "framerate", and
   "preference".

   Additionally, several new (local) source attributes are defined:
   "information", providing human-readable information about a local
   source, and "send", and "inactive", which are complementary to the
   "recv" and "inactive" remote source attributtes.


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.  Motivating Architecture

   The primary use envisioned for this mechanisms is for multimedia
   conferences controlled by a central system.  This is similar to the
   topolgies 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 a locally-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
   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



Lennox                   Expires January 7, 2010                [Page 3]


Internet-Draft        Media Source Selection in SDP            July 2009


   which participants explicitly request some sources while allowing the
   server to choose others.

   Receivers can specify parameters for how they will view certain
   sources or server-selected 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 route them all.

   When the first receiver starts viewing a source, the 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.

   At scale, 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                   Expires January 7, 2010                [Page 4]


Internet-Draft        Media Source Selection in SDP            July 2009


   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
   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, along with properties with which the
   receiver of the source would like to receive it.


5.  The "remote-ssrc" Media Attribute

   This section defines a new SDP media-level attribute, "remote-ssrc",
   which provides the mechanism by which a remote source can be
   requested.


   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),
   such as "recv" or "inactive", or an attribute name and value, e.g.
   "framerate:30".

   These remote source IDs correspond to sources in the RTP session that
   may be sent by other session members.  The author of the SDP may have
   been learned about these sources by observing them in the RTP session
   (either by receiving RTP packets or seeing RTCP reports from 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
   [I-D.ietf-xcon-event-package].

   The "remote-ssrc" media attribute MAY be used for any RTP-based media



Lennox                   Expires January 7, 2010                [Page 5]


Internet-Draft        Media Source Selection in SDP            July 2009


   transport.  It is not defined for other transports.

   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 is not (itself) dependent on
   charset, though specific remote source attributes MAY 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" and "inactive" Remote Source-Level Attributes


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


   The "recv" remote source attribute indicates a source that the author
   of an SDP message is interested in receiving.  Similarly, the
   "inactive" remote source attribute indicates a source that the author
   of an SDP message is not interested in receiving.  There MUST be at
   most one of the "recv" and "inactive" remote source-level attributes
   per remote media source.

   If the media stream containing the source has the media attributes
   "sendonly" or "inactive", the stream MUST NOT list any remote sources
   with the "recv" attribute.

   If "remote-ssrc" attributes are given for a particular remote source,
   but neither "recv" nor "inactive" is specified for it, "recv" is the
   default if the media stream is "sendrecv" or "recvonly".

   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
   "ssrc-group" [RFC5576], any unlisted sources of a group SHOULD be
   treated the same as any listed ones if the requests are consistent.

   Figure 4 in Section 10 gives a formal Augmented Backus-Naur Form



Lennox                   Expires January 7, 2010                [Page 6]


Internet-Draft        Media Source Selection in SDP            July 2009


   (ABNF) [RFC5234] grammar for the "recv" and "inactive" attributes.

   Section 8 describes how the "recv" and "inactive" remote source
   attributes are used with SDP offer/answer [RFC3264].

   The "recv" and "inactive" remote source attributes are not dependent
   on 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 which the receiver of a video source would like receive for the
   video.  Higher framerates are likely not to be useful.  It is
   analogous to the SDP "framerate" media attribute [RFC4566].  Decimal
   representations of fractional values using the notation
   "<integer>.<fraction>" are allowed.

   The "framerate" attribute is defined only for video media.  There
   MUST be at most one "framerate" remote source attribute per remote
   media source.

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

   The "framerate" remote source attribute is not dependent on charset.

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.  It is analogous to the "recv" portion of the SDP
   "imageattr" media attribute [I-D.ietf-mmusic-image-attributes].

   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.




Lennox                   Expires January 7, 2010                [Page 7]


Internet-Draft        Media Source Selection in SDP            July 2009


   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 [I-D.ietf-mmusic-image-attributes].

   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.

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

   The "imageattr" remote source attribute is not dependent on charset.

6.4.  The "priority" Remote Source Attribute


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


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


7.  Source Attributes

   This section describes specific (sending) source attributes that can
   be applied to RTP sources.

7.1.  The "information" Source Attribute


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


   The "information" source attribute provides textual information about



Lennox                   Expires January 7, 2010                [Page 8]


Internet-Draft        Media Source Selection in SDP            July 2009


   a source.  It is analogous 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 "send" and "inactive" Source-Level Attributes


   a=ssrc:<ssrc> send
   a=ssrc:<ssrc> inactive


   The "send" source attribute 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" remote source attribute in
   an SDP offer/answer exchange.  Similarly, the "inactive" source
   attribute indicates a source that has been rejected with the
   "inactive" remote source attribute.  There MUST be at most one of the
   "send" and "inactive" source-level attributes per media source.
   Sources which were not listed with "recv-ssrc" in the previous offer
   or answer SHOULD NOT have either "send" or "inactive" listed.

   The "send" and "inactive" attributes are not defined for declarative
   SDP.

   If the media stream containing the source has the media attributes
   "recvonly" or "inactive", the stream MUST NOT list any sources with
   the "send" attribute.

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

   Further description of how the "send" and "inactive" source
   attributes are used with SDP offer/answer [RFC3264] is given in
   Section 8.

   The "send" and "inactive" source attributes are not dependent on
   charset.



Lennox                   Expires January 7, 2010                [Page 9]


Internet-Draft        Media Source Selection in SDP            July 2009


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) SHOULD include all the remotely-requested
   active sources in "ssrc" attributes in its answer.  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 have
   subsequently been removed.  In both cases, remote sources with the
   "recv" remote source attribute included (implicitly or explicitly)
   SHOULD be listed in the next response with the "send" local source
   attribute, while remote sources with the "inactive" remote source
   attribute SHOULD have the "inactive" local source attribute.
   However, if the send/recv mode of the media stream has changed to
   "recvonly" or "inactive", sources MUST NOT be listed with the "send"
   attribute, and thus all remotely-requested sources SHOULD be listed
   as "inactive" instead.

   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 [I-D.ietf-xcon-event-package].  (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, "inactive" sources, and sources
   that have never been explicitly requested, MAY be omitted.


9.  Backward Compatibility

   TODO: It is not clear if the absence of any "recv-ssrc" attributes,
   which following this draft would semantically indicate "I don't want
   to request any specific sources right now" needs to be distinguished
   from the backward-compatibility case "I don't know anything about the
   'recv-ssrc' attribute".  Similarly, it's not clear whether "I don't
   have any sources to list" needs to be distingushed from "I don't know
   about the 'ssrc' attribute."







Lennox                   Expires January 7, 2010               [Page 10]


Internet-Draft        Media Source Selection in SDP            July 2009


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" / "inactive"

   attribute =/ recv-attr

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


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

   attribute =/ framerate-attr

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


   imageattr-attr = "imageattr:" PT 1*WSP attr_list
   ; The definition of PT and attr_list are in
   ; [I-D.ietf-mmusic-image-attributes]

   attribute =/ imageattr-attr

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


   priority-attr = "priority:" 1*DIGIT

   attribute =/ priority-attr

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




Lennox                   Expires January 7, 2010               [Page 11]


Internet-Draft        Media Source Selection in SDP            July 2009


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

   attribute =/ information-attr

          Figure 8: Syntax of the "imformation" source attribute


   send-attr = "send" / "inactive"

   attribute =/ send-attr

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


11.  Security Considerations

   All the security implications 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 three new SDP source-level attributes,
   "information", "send", and "inactive".  These attributes should be
   registered 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



Lennox                   Expires January 7, 2010               [Page 12]


Internet-Draft        Media Source Selection in SDP            July 2009


   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.

   Type            SDP Name                     Reference
   ----            ------------------           ---------
   att-field (remote source level)
                   recv                        [RFCXXXX]
                   inactive                    [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.)




Lennox                   Expires January 7, 2010               [Page 13]


Internet-Draft        Media Source Selection in SDP            July 2009


13.  References

13.1.  Normative References

   [I-D.ietf-mmusic-image-attributes]
              Johansson, I. and K. Jung, "Negotiation of Generic Image
              Attributes in SDP", draft-ietf-mmusic-image-attributes-02
              (work in progress), April 2009.

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

13.2.  Informative References

   [I-D.ietf-xcon-event-package]
              Camarillo, G., Srinivasan, S., Even, R., and J.
              Urpalainen, "Conference Event Package Data Format
              Extension for Centralized Conferencing  (XCON)",
              draft-ietf-xcon-event-package-01 (work in progress),
              September 2008.

   [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,



Lennox                   Expires January 7, 2010               [Page 14]


Internet-Draft        Media Source Selection in SDP            July 2009


              January 2008.


Appendix A.  Open issues

   o  The "recv-ssrc" attribute does not currently list a CNAME.  This
      could be problematic if a SSRC collision occurs.  However, several
      mechanisms for discovering sources (the conference event packages,
      or in-media-path if RTCP is delayed) might mean that you don't
      know the CNAME for a requested source, so you can't simply require
      that it be listed.  Does the SSRC collision case need to be
      addressed, and if so, how?
   o  The backward compatibility issues need to be considered.


Author's Address

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

   Email: jonathan@vidyo.com


























Lennox                   Expires January 7, 2010               [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/