doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc5576.txt b/doc/rfc/rfc5576.txt
new file mode 100644
index 0000000..1727522
--- /dev/null
+++ b/doc/rfc/rfc5576.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                          J. Lennox
+Request for Comments: 5576                                         Vidyo
+Category: Standards Track                                         J. Ott
+                                       Helsinki University of Technology
+                                                              T. Schierl
+                                                          Fraunhofer HHI
+                                                               June 2009
+
+
+                Source-Specific Media Attributes in the
+                   Session Description Protocol (SDP)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 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 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.
+
+   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.
+
+
+
+
+
+
+
+
+
+Lennox, et al.              Standards Track                     [Page 1]
+
+RFC 5576             Source-Specific SDP Attributes            June 2009
+
+
+Abstract
+
+   The Session Description Protocol (SDP) provides mechanisms to
+   describe attributes of multimedia sessions and of individual media
+   streams (e.g., Real-time Transport Protocol (RTP) sessions) within a
+   multimedia session, but does not provide any mechanism to describe
+   individual media sources within a media stream.  This document
+   defines a mechanism to describe RTP media sources, which are
+   identified by their synchronization source (SSRC) identifiers, in
+   SDP, to associate attributes with these sources, and to express
+   relationships among sources.  It also defines several source-level
+   attributes that can be used to describe properties of media sources.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................3
+   3. Overview ........................................................3
+   4. Media Attributes ................................................4
+      4.1. The "ssrc" Media Attribute .................................5
+      4.2. The "ssrc-group" Media Attribute ...........................6
+   5. Usage of Identified Source Identifiers in RTP ...................7
+   6. Source Attributes ...............................................8
+      6.1. The "cname" Source Attribute ...............................8
+      6.2. The "previous-ssrc" Source Attribute .......................9
+      6.3. The "fmtp" Source Attribute ................................9
+      6.4. Other Source Attributes ...................................10
+   7. Examples .......................................................10
+   8. Usage With the Offer/Answer Model ..............................11
+   9. Backward Compatibility .........................................11
+   10. Formal Grammar ................................................12
+   11. Security Considerations .......................................13
+   12. IANA Considerations ...........................................14
+      12.1. New SDP Media-Level Attributes ...........................14
+      12.2. Registry for Source-Level Attributes .....................14
+      12.3. Registry for Source Grouping Semantics ...................15
+   13. References ....................................................16
+      13.1. Normative References .....................................16
+      13.2. Informative References ...................................16
+
+1.  Introduction
+
+   The Session Description Protocol (SDP) [RFC4566] provides mechanisms
+   to describe attributes of multimedia sessions and of media streams
+   (e.g., Real-time Transport Protocol (RTP) [RFC3550] sessions) within
+   a multimedia session, but does not provide any mechanism to describe
+   individual media sources within a media stream.
+
+
+
+
+Lennox, et al.              Standards Track                     [Page 2]
+
+RFC 5576             Source-Specific SDP Attributes            June 2009
+
+
+   Several recently proposed protocols, notably RTP single-source
+   multicast [EXT-SSM], have found it useful to describe specific media
+   sources in SDP messages.  Single-source multicast, in particular,
+   needs to ensure that receivers' RTP synchronization source (SSRC)
+   identifiers do not collide with those of media senders, as the RTP
+   specification [RFC3550] requires that colliding sources change their
+   SSRC values after a collision has been detected.  Earlier work has
+   used mechanisms specific to each protocol to describe the individual
+   sources of an RTP session.
+
+   Moreover, whereas the Real-time Transport Protocol (RTP) [RFC3550] is
+   defined as allowing multiple sources in an RTP session (for example,
+   if a user has more than one camera), SDP has no existing mechanism
+   for an endpoint to indicate that it will be using multiple sources or
+   to describe their characteristics individually.
+
+   To address all these problems, this document defines a mechanism to
+   describe RTP sources, identified by their synchronization source
+   (SSRC) identifier, in SDP, to associate attributes with these
+   sources, and to express relationships among individual sources.  It
+   also defines a number of new SDP attributes that apply to individual
+   sources ("source-level" attributes), describes how a number of
+   existing media stream ("media-level") attributes can also be applied
+   at the source level, and establishes IANA registries for source-level
+   attributes and source grouping semantics.
+
+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.  Overview
+
+   In the Real-time Transport Protocol (RTP) [RFC3550], an association
+   among a group of communicating participants is known as an RTP
+   Session.  An RTP session is typically associated with a single
+   transport address (in the case of multicast) or communication flow
+   (in the case of unicast), though RTP translators and single-source
+   multicast [EXT-SSM] can make the situation more complex.  RTP
+   topologies are discussed in more detail in [RFC5117].
+
+   Within an RTP session, the source of a single stream of RTP packets
+   is known as a synchronization source (SSRC).  Every synchronization
+   source is identified by a 32-bit numeric identifier.  In addition,
+   receivers (who may never send RTP packets) also have source
+
+
+
+
+Lennox, et al.              Standards Track                     [Page 3]
+
+RFC 5576             Source-Specific SDP Attributes            June 2009
+
+
+   identifiers, which are used to identify their RTP Control Protocol
+   (RTCP) receiver reports and other feedback messages.
+
+   Messages of the Session Description Protocol (SDP) [RFC4566], known
+   as session descriptions, describe multimedia sessions.  A multimedia
+   session is a set of multimedia senders and receivers as well as the
+   data streams flowing from senders to receivers.  A multimedia session
+   contains a number of media streams, which are the individual RTP
+   sessions or other media paths over which one type of multimedia data
+   is carried.  Information that applies to an entire multimedia session
+   is called session-level information, while information pertaining to
+   one media stream is called media-level information.  The collection
+   of all the information describing a media stream is known as a media
+   description.  (Media descriptions are also sometimes known informally
+   as SDP "m"-lines, after the SDP syntax that begins a media
+   description.)  Several standard information elements are defined at
+   both the session level and the media level.  Extended information can
+   be included at both levels through the use of attributes.
+
+   (The term "media stream" does not appear in the SDP specification
+   itself, but is used by a number of SDP extensions, for instance,
+   Interactive Connectivity Establishment (ICE) [ICE], to denote the
+   object described by an SDP media description.  This term is
+   unfortunately rather confusing, as the RTP specification [RFC3550]
+   uses the term "media stream" to refer to an individual media source
+   or RTP packet stream, identified by an SSRC, whereas an SDP media
+   stream describes an entire RTP session, which can contain any number
+   of RTP sources.  In this document, the term "media stream" means an
+   SDP media stream, i.e., the thing described by an SDP media
+   description, whereas "media source" is used for a single source of
+   media packets, i.e., an RTP media stream.)
+
+   The core SDP specification does not have any way of describing
+   individual media sources, particularly RTP synchronization sources,
+   within a media stream.  To address this problem, in this document we
+   introduce a third level of information, called source-level
+   information.  Syntactically, source-level information is described by
+   a new SDP media-level attribute, "ssrc", which identifies specific
+   synchronization sources within an RTP session and acts as a meta-
+   attribute mapping source-level attribute information to these
+   sources.
+
+   This document also defines an SDP media-level attribute, "ssrc-
+   group", which can represent relationships among media sources within
+   an RTP session in much the same way as the "group" attribute
+   [RFC3388] represents relationships among media streams within a
+   multimedia session.
+
+
+
+
+Lennox, et al.              Standards Track                     [Page 4]
+
+RFC 5576             Source-Specific SDP Attributes            June 2009
+
+
+4.  Media Attributes
+
+   This section defines two media-level attributes, "ssrc" and "ssrc-
+   group".
+
+4.1.  The "ssrc" Media Attribute
+
+   a=ssrc:<ssrc-id> <attribute>
+   a=ssrc:<ssrc-id> <attribute>:<value>
+
+   The SDP media attribute "ssrc" indicates a property (known as a
+   "source-level attribute") of a media source (RTP stream) within an
+   RTP session. <ssrc-id> is the synchronization source (SSRC) ID of the
+   source being described, interpreted as a 32-bit unsigned integer in
+   network byte order and represented in decimal. <attribute> or
+   <attribute>:<value> represents the source-level attribute specific to
+   the given media source.  The source-level attribute follows the
+   syntax of the SDP "a=" line.  It thus consists of either a single
+   attribute name (a flag) or an attribute name and value, e.g.,
+   "cname:user@example.com".  No attributes of the former type are
+   defined by this document.
+
+   Within a media stream, "ssrc" attributes with the same value of
+   <ssrc-id> describe different attributes of the same media sources.
+   Across media streams, <ssrc-id> values are not correlated (unless
+   correlation is indicated by media-stream grouping or some other
+   mechanism) and MAY be repeated.
+
+   Each "ssrc" media attribute specifies a single source-level attribute
+   for the given <ssrc-id>.  For each source mentioned in SDP, the
+   source-level attribute "cname", defined in Section 6.1, MUST be
+   provided.  Any number of other source-level attributes for the source
+   MAY also be provided.
+
+   The "ssrc" media attribute MAY be used for any RTP-based media
+   transport.  It is not defined for other transports.
+
+   If any other SDP attributes also mention RTP SSRC values (for
+   example, Multimedia Internet KEYing (MIKEY) [RFC3830] [RFC4567]), the
+   values used MUST be consistent.  (These attributes MAY provide
+   additional information about a source described by an "ssrc"
+   attribute or MAY describe additional sources.)
+
+   Though the source-level attributes specified by the ssrc property
+   follow the same syntax as session-level and media-level attributes,
+   they are defined independently.  All source-level attributes MUST be
+   registered with IANA, using the registry defined in Section 12.2.
+
+
+
+
+Lennox, et al.              Standards Track                     [Page 5]
+
+RFC 5576             Source-Specific SDP Attributes            June 2009
+
+
+   Figure 4 in Section 10 gives a formal Augmented Backus-Naur Form
+   (ABNF) [RFC5234] grammar for the "ssrc" attribute.
+
+   The "ssrc" media attribute is not dependent on charset.
+
+4.2.  The "ssrc-group" Media Attribute
+
+   a=ssrc-group:<semantics> <ssrc-id> ...
+
+   The SDP media attribute "ssrc-group" expresses a relationship among
+   several sources of an RTP session.  It is analogous to the "group"
+   session-level attribute [RFC3388], which expresses a relationship
+   among media streams in an SDP multimedia session (i.e., a
+   relationship among several logically related RTP sessions).  As
+   sources are already identified by their SSRC IDs, no analogous
+   property to the "mid" attribute is necessary; groups of sources are
+   identified by their SSRC IDs directly.
+
+   The <semantics> parameter is taken from the specification of the
+   "group" attribute [RFC3388].  The initial semantic values defined for
+   the "ssrc-group" attribute are FID (Flow Identification) [RFC3388]
+   and FEC (Forward Error Correction) [RFC4756].  In each case, the
+   relationship among the grouped sources is the same as the
+   relationship among corresponding sources in media streams grouped
+   using the SDP "group" attribute.
+
+   Though the "ssrc-group" semantic values follow the same syntax as
+   "group" semantic values, they are defined independently.  All "ssrc-
+   group" semantic values MUST be registered with IANA, using the
+   registry defined in Section 12.3.
+
+   (The other "group" semantics registered with IANA as of this writing
+   are not useful for source grouping.  LS (Lip Synchronization)
+   [RFC3388] is redundant for sources within a media stream as RTP
+   sources with the same CNAME are implicitly synchronized in RTP.  SRF
+   (Single Reservation Flow) [RFC3524] and ANAT (Alternative Network
+   Address Types) [RFC4091] refer specifically to the media stream's
+   transport characteristics.  CS (Composite Session) [FLUTE] is used to
+   group FLUTE sessions, and so is not applicable to RTP.)
+
+   The "ssrc-group" attribute indicates the sources in a group by
+   listing the <ssrc-id>s of the sources in the group.  It MUST list at
+   least one <ssrc-id> for a group and MAY list any number of additional
+   ones.  Every <ssrc-id> listed in an "ssrc-group" attribute MUST be
+   defined by a corresponding "ssrc:" line in the same media
+   description.
+
+   The "ssrc-group" media attribute is not dependent on charset.
+
+
+
+Lennox, et al.              Standards Track                     [Page 6]
+
+RFC 5576             Source-Specific SDP Attributes            June 2009
+
+
+   Figure 5 in Section 10 gives a formal Augmented Backus-Naur Form
+   (ABNF) [RFC5234] grammar for the "ssrc-group" attribute.
+
+5.  Usage of Identified Source Identifiers in RTP
+
+   The synchronization source identifiers used in an RTP session are
+   chosen randomly and independently by endpoints.  As such, it is
+   possible for two RTP endpoints to choose the same SSRC identifier.
+   Though the probability of this is low, the RTP specification
+   [RFC3550] requires that all RTP endpoints MUST be prepared to detect
+   and resolve collisions.
+
+   As a result, all endpoints MUST be prepared for the fact that
+   information about specific sources identified in a media stream might
+   be out of date.  The actual binding between SSRCs and source CNAMEs
+   can only be identified by the source description (SDES) RTCP packets
+   transmitted on the RTP session.
+
+   When endpoints are choosing their own local SSRC values for media
+   streams for which source-level attributes have been specified, they
+   MUST NOT use for themselves any SSRC identifiers mentioned in media
+   descriptions they have received for the media stream.
+
+   However, sources identified by SDP source-level attributes do not
+   otherwise affect RTP transport logic.  Specifically, sources that are
+   only known through SDP, for which neither RTP nor RTCP packets have
+   been received, MUST NOT be counted for RTP group size estimation, and
+   report blocks MUST NOT be sent for them in SR or RR RTCP messages.
+
+   Endpoints MUST NOT assume that only the sources mentioned in SDP will
+   be present in an RTP session; additional sources, with previously
+   unmentioned SSRC IDs, can be added at any time, and endpoints MUST be
+   prepared to receive packets from these sources.  (How endpoints
+   handle such packets is not specified here; they SHOULD be handled in
+   the same manner as packets from additional sources would be handled
+   had the endpoint not received any a=ssrc: attributes at all.)
+
+   An endpoint that observes an SSRC collision between its explicitly
+   signaled source and another entity that has not explicitly signaled
+   an SSRC MAY delay its RTP collision-resolution actions [RFC3550] by
+   5*1.5*Td, where Td is the deterministic, calculated, reporting
+   interval for receivers defined in Section 6.3.1 of the RTP
+   specification [RFC3550], to see whether the conflict still exists.
+   (This gives precedence to explicitly signaled sources and places the
+   burden of collision resolution on non-signaled sources.)  SSRC
+   collisions between multiple explicitly-signaled sources, however,
+   MUST be acted upon immediately.
+
+
+
+
+Lennox, et al.              Standards Track                     [Page 7]
+
+RFC 5576             Source-Specific SDP Attributes            June 2009
+
+
+   If, following RTP's collision-resolution procedures [RFC3550], a
+   source identified by source-level attributes has been forced to
+   change its SSRC identifier, the author of the SDP containing the
+   source-level attributes for these sources SHOULD send out an updated
+   SDP session description with the new SSRC if the mechanism by which
+   SDP is being distributed for the multimedia session has a mechanism
+   to distribute updated SDP.  This updated SDP MUST include a
+   "previous-ssrc" source-level attribute, described in Section 6.2,
+   listing the source's previous SSRC ID.  (If only a single source with
+   a given CNAME has collided, the other RTP session members can infer a
+   correspondence between the source's old and new SSRC IDs without
+   requiring an updated session description.  However, if more than one
+   source collides at once, or if sources are leaving and re-joining,
+   this inference is not possible.  To avoid confusion, therefore,
+   sending updated SDP messages is always RECOMMENDED.)
+
+   Endpoints MUST NOT reuse the same SSRC ID for identified sources with
+   the same CNAME for at least the duration of the RTP session's
+   participant timeout interval (see Section 6.3.5 of [RFC3550]).  They
+   SHOULD NOT reuse any SSRC ID ever mentioned in SDP (either by
+   themselves or by other endpoints) for the entire lifetime of the RTP
+   session.
+
+   Endpoints MUST be prepared for the possibility that other parties in
+   the session do not understand SDP source-level attributes, unless
+   some higher-level mechanism normatively requires them.  See Section 9
+   for more discussion of this.
+
+6.  Source Attributes
+
+   This section describes specific source attributes that can be applied
+   to RTP sources.
+
+6.1.  The "cname" Source Attribute
+
+   a=ssrc:<ssrc-id> cname:<cname>
+
+   The "cname" source attribute associates a media source with its
+   Canonical End-Point Identifier (CNAME) source description (SDES)
+   item.  This MUST be the CNAME value that the media sender will place
+   in its RTCP SDES packets; it therefore MUST follow the syntax
+   conventions of CNAME defined in the RTP specification [RFC3550].  If
+   a session participant receives an RTCP SDES packet associating this
+   SSRC with a different CNAME, it SHOULD assume there has been an SSRC
+   collision and that the description of the source that was carried in
+   the SDP description is not applicable to the actual source being
+   received.  This source attribute is REQUIRED to be present if any
+   source attributes are present for a source.  The "cname" attribute
+
+
+
+Lennox, et al.              Standards Track                     [Page 8]
+
+RFC 5576             Source-Specific SDP Attributes            June 2009
+
+
+   MUST NOT occur more than once for the same ssrc-id within a given
+   media stream.
+
+   The "cname" source attribute is not dependent on charset.
+
+   Figure 6 in Section 10 gives a formal Augmented Backus-Naur Form
+   (ABNF) [RFC5234] grammar for the "cname" attribute.
+
+6.2.  The "previous-ssrc" Source Attribute
+
+   a=ssrc:<ssrc-id> previous-ssrc:<ssrc-id> ...
+
+   The "previous-ssrc" source attribute associates a media source with
+   previous source identifiers used for the same media source.
+   Following an SSRC change due to an SSRC collision involving a media
+   source described in SDP, the updated session description describing
+   the source's new SSRC (described in Section 5) MUST include the
+   "previous-ssrc" attribute associating the new SSRC with the old one.
+   If further updated SDP descriptions are published describing the
+   media source, the "previous-ssrc" attribute SHOULD be included if the
+   session description was generated before the participant timeout of
+   the old SSRC, and MAY be included after that point.  This attribute,
+   if present, MUST list at least one previous SSRC and MAY list any
+   number of additional SSRCs for the source if the source has collided
+   more than once.  This attribute MUST be present only once for each
+   source.
+
+   The "previous-ssrc" source attribute is not dependent on charset.
+
+   Figure 7 in Section 10 gives a formal Augmented Backus-Naur Form
+   (ABNF) [RFC5234] grammar for the previous-ssrc attribute.
+
+6.3.  The "fmtp" Source Attribute
+
+   a=ssrc:<ssrc> fmtp:<format> <format specific parameters>
+
+   The "fmtp" source attribute allows format-specific parameters to be
+   conveyed about a given source.  The <format> parameter MUST be one of
+   the media formats (i.e., RTP payload types) specified for the media
+   stream.  The meaning of the <format specific parameters> is unique
+   for each media type.  This parameter MUST only be used for media
+   types for which source-level format parameters have explicitly been
+   specified; media-level format parameters MUST NOT be carried over
+   blindly.
+
+   The "fmtp" source attribute is not dependent on charset.
+
+
+
+
+
+Lennox, et al.              Standards Track                     [Page 9]
+
+RFC 5576             Source-Specific SDP Attributes            June 2009
+
+
+6.4.  Other Source Attributes
+
+   This document only defines source attributes that are necessary or
+   useful for an endpoint to decode and render the sources in a media
+   stream.  It does not include any attributes that would contribute to
+   an endpoint's decision to accept or reject a stream, e.g., in an
+   offer/answer exchange.  Such attributes are for future consideration.
+
+7.  Examples
+
+   This section gives several examples of SDP descriptions of media
+   sessions containing source attributes.  For brevity, only the media
+   sections of the descriptions are given.
+
+   m=audio 49168 RTP/AVP 0
+   a=ssrc:314159 cname:user@example.com
+
+   Figure 1: Example of a declaration of a single synchronization source
+
+   The example in Figure 1 shows an audio stream advertising a single
+   source.
+
+   m=video 49170 RTP/AVP 96
+   a=rtpmap:96 H264/90000
+   a=ssrc:12345 cname:another-user@example.com
+   a=ssrc:67890 cname:another-user@example.com
+
+    Figure 2: Example of a media stream containing several independent
+                   sources from a single session member
+
+   The example in Figure 2 shows a video stream where one participant
+   (identified by a single CNAME) has several cameras.  The sources
+   could be further distinguished by RTCP Source Description (SDES)
+   information.
+
+   m=video 49174 RTP/AVPF 96 98
+   a=rtpmap:96 H.264/90000
+   a=rtpmap:98 rtx/90000
+   a=fmtp:98 apt=96;rtx-time=3000
+   a=ssrc-group:FID 11111 22222
+   a=ssrc:11111 cname:user3@example.com
+   a=ssrc:22222 cname:user3@example.com
+   a=ssrc-group:FID 33333 44444
+   a=ssrc:33333 cname:user3@example.com
+   a=ssrc:44444 cname:user3@example.com
+
+               Figure 3: Example of the relationships among
+                      several retransmission sources
+
+
+
+Lennox, et al.              Standards Track                    [Page 10]
+
+RFC 5576             Source-Specific SDP Attributes            June 2009
+
+
+   The example in Figure 3 shows how the relationships among sources
+   used for RTP retransmission [RFC4588] can be explicitly signaled.
+   This prevents the complexity of associating original sources with
+   retransmission sources when SSRC multiplexing is used for RTP
+   retransmission, as is described in Section 5.3 of [RFC4588].
+
+8.  Usage With the Offer/Answer Model
+
+   When used with the SDP Offer/Answer Model [RFC3264], SDP source-
+   specific attributes describe only the sources that each party is
+   willing to send (whether it is sending RTP data or RTCP report
+   blocks).  No mechanism is provided by which an answer can accept or
+   reject individual sources within a media stream; if the set of
+   sources in a media stream is unacceptable, the answerer's only option
+   is to reject the media stream or the entire multimedia session.
+
+   The SSRC IDs for sources described by an SDP answer MUST be distinct
+   from the SSRC IDs for sources of that media stream in the offer.
+   Similarly, new SSRC IDs in an updated offer MUST be distinct from the
+   SSRC IDs for that media stream established in the most recent offer/
+   answer exchange for the session and SHOULD be distinct from any SSRC
+   ID ever used by either party within the multimedia session (whether
+   or not it is still being used).
+
+9.  Backward Compatibility
+
+   According to the definition of SDP, interpreters of SDP session
+   descriptions ignore unknown attributes.  Thus, endpoints MUST be
+   prepared that recipients of their RTP media session may not
+   understand their explicit source descriptions, unless some external
+   mechanism indicates that they were understood.  In some cases (such
+   as RTP Retransmission [RFC4588]), this may constrain some choices
+   about the bitstreams that are transmitted.
+
+   Source descriptions are specified in this document such that RTP
+   endpoints that are compliant with the RTP specification [RFC3550]
+   will be able to decode the media streams they describe whether or not
+   they support explicit source descriptions.  However, some deployed
+   RTP implementations may not actually support multiple media sources
+   in a media stream.  Media senders MAY wish to restrict themselves to
+   a single source at a time unless they have some means of concluding
+   that the receivers of the media stream support source multiplexing.
+
+
+
+
+
+
+
+
+
+Lennox, et al.              Standards Track                    [Page 11]
+
+RFC 5576             Source-Specific SDP Attributes            June 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 that have been extended to be source attributes are not
+   included.
+
+   Copyright (c) 2009 IETF Trust and the persons identified as authors
+   of the code.  All rights reserved.
+
+   Redistribution and use in source and binary forms, with or without
+   modification, are permitted provided that the following conditions
+   are met:
+
+   o  Redistributions of source code must retain the above copyright
+      notice, this list of conditions and the following disclaimer.
+
+   o  Redistributions in binary form must reproduce the above copyright
+      notice, this list of conditions and the following disclaimer in
+      the documentation and/or other materials provided with the
+      distribution.
+
+   o  Neither the name of Internet Society, IETF or IETF Trust, nor the
+      names of specific contributors, may be used to endorse or promote
+      products derived from this software without specific prior written
+      permission.
+
+   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+   'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+   A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT
+   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+
+
+
+
+
+
+
+
+
+
+
+Lennox, et al.              Standards Track                    [Page 12]
+
+RFC 5576             Source-Specific SDP Attributes            June 2009
+
+
+   ssrc-attr = "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 =/ ssrc-attr
+
+              Figure 4: Syntax of the "ssrc" media attribute
+
+
+   ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id)
+
+   semantics       = "FEC" / "FID" / token
+                    ; Matches RFC 3388 definition and
+                    ; IANA registration rules in this doc.
+
+   token           = <as defined in RFC 4566>
+
+   attribute       =/ ssrc-group-attr
+
+           Figure 5: Syntax of the "ssrc-group" media attribute
+
+
+   cname-attr = "cname:" cname
+
+   cname = byte-string
+   ; Following the syntax conventions for CNAME as defined in RFC 3550.
+   ; The definition of "byte-string" is in RFC 4566.
+
+   attribute =/ cname-attr
+
+             Figure 6: Syntax of the "cname" source attribute
+
+
+   previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id)
+
+   attribute =/ previous-ssrc-attr
+
+         Figure 7: Syntax of the "previous-ssrc" source attribute
+
+11.  Security Considerations
+
+   All the security implications of RTP [RFC3550] and of SDP [RFC4566]
+   apply.  Explicitly describing the multiplexed sources of an RTP media
+   stream does not appear to add any further security issues.
+
+
+
+
+
+Lennox, et al.              Standards Track                    [Page 13]
+
+RFC 5576             Source-Specific SDP Attributes            June 2009
+
+
+12.  IANA Considerations
+
+12.1.  New SDP Media-Level Attributes
+
+   This document defines two SDP media-level attributes: "ssrc" and
+   "ssrc-group".  These attributes have been registered by IANA under
+   "Session Description Protocol (SDP) Parameters" under "att-field
+   (media level only)".
+
+   The "ssrc" attribute is used to identify characteristics of media
+   sources within a media stream.  Its format is defined in Section 4.1.
+
+   The "ssrc-group" attribute is used to identify relationships among
+   media sources within a media stream.  Its format is defined in
+   Section 4.2.
+
+12.2.  Registry for Source-Level Attributes
+
+   This specification creates a new IANA registry named "att-field
+   (source level)" within the SDP parameters registry.  Source
+   attributes MUST be registered with IANA and documented under the same
+   rules as for SDP session-level and media-level attributes as
+   specified in [RFC4566].
+
+   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.  The Expert Reviewer
+   will determine if the proposed attributes are expected to see
+   widespread use and interoperability; in that case, the attributes
+   MUST be specified in a Standards Track RFC.
+
+
+
+
+
+
+
+Lennox, et al.              Standards Track                    [Page 14]
+
+RFC 5576             Source-Specific SDP Attributes            June 2009
+
+
+   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.
+
+   Source-level attributes that are substantially similar in semantics
+   to existing session-level or media-level attributes SHOULD reuse the
+   same attribute name as those session-level or media-level attributes.
+   Source-level attributes SHOULD NOT reuse attribute names of session-
+   level or media-level attributes that are unrelated or substantially
+   different.
+
+   The initial set of source attribute names, with definitions in
+   Section 6 of this document, is in Figure 8.
+
+   Type            SDP Name                     Reference
+   ----            ------------------           ---------
+   att-field (source level)
+                   cname                        [RFC5576]
+                   previous-ssrc                [RFC5576]
+                   fmtp                         [RFC5576]
+
+     Figure 8: Initial contents of the IANA Source Attribute Registry
+
+12.3.  Registry for Source Grouping Semantics
+
+   This specification creates a new IANA registry named 'Semantics for
+   the "ssrc-group" SDP Attribute' within the SDP parameters registry.
+   Source group semantics MUST be defined in Standards Track RFCs, under
+   the same rules as [RFC3388].
+
+   The IANA Considerations section of the RFC MUST include the following
+   information, which appears in the IANA registry along with the RFC
+   number of the publication:
+
+   o  A brief description of the semantics.
+
+   o  Token to be used within the group attribute.  This token may be of
+      any length, but SHOULD be no more than four characters long.
+
+   o  Reference to a Standards Track RFC.
+
+   Source grouping semantic values that are substantially similar to
+   existing media grouping semantic values SHOULD reuse the same
+   semantics name as those media grouping semantics.  Source grouping
+   semantics SHOULD NOT reuse source grouping semantic names that are
+   unrelated or substantially different.
+
+
+
+Lennox, et al.              Standards Track                    [Page 15]
+
+RFC 5576             Source-Specific SDP Attributes            June 2009
+
+
+   The initial set of source grouping semantic values, for the semantics
+   specified in Section 4.2 of this document, is in Figure 9.
+
+   Semantics                           Token     Reference
+   -------------------                 -----     ---------
+   Flow Identification                 FID       [RFC5576]
+   Forward Error Correction            FEC       [RFC5576]
+
+    Figure 9: Initial Contents of IANA Source Group Semantics Registry
+
+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.
+
+   [RFC3388]  Camarillo, G., Eriksson, G., Holler, J., and H.
+              Schulzrinne, "Grouping of Media Lines in the Session
+              Description Protocol (SDP)", RFC 3388, December 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.
+
+   [RFC4756]  Li, A., "Forward Error Correction Grouping Semantics in
+              Session Description Protocol", RFC 4756, November 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.
+
+13.2.  Informative References
+
+   [EXT-SSM]  Schooler, E., Ott, J., and J. Chesterfield, "RTCP
+              Extensions for Single-Source Multicast Sessions with
+              Unicast Feedback", Work in Progress, March 2009.
+
+
+
+
+Lennox, et al.              Standards Track                    [Page 16]
+
+RFC 5576             Source-Specific SDP Attributes            June 2009
+
+
+   [FLUTE]    Mehta, H., "SDP Descriptors for FLUTE", Work in Progress,
+              January 2006.
+
+   [ICE]      Rosenberg, J., "Interactive Connectivity Establishment
+              (ICE): A Protocol for Network Address Translator (NAT)
+              Traversal for Offer/Answer Protocols", Work in Progress,
+              October 2007.
+
+   [RFC3524]  Camarillo, G. and A. Monrad, "Mapping of Media Streams to
+              Resource Reservation Flows", RFC 3524, April 2003.
+
+   [RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
+              Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
+              August 2004.
+
+   [RFC4091]  Camarillo, G. and J. Rosenberg, "The Alternative Network
+              Address Types (ANAT) Semantics for the Session Description
+              Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
+
+   [RFC4567]  Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
+              Carrara, "Key Management Extensions for Session
+              Description Protocol (SDP) and Real Time Streaming
+              Protocol (RTSP)", RFC 4567, July 2006.
+
+   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
+              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
+              July 2006.
+
+   [RFC5117]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
+              January 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lennox, et al.              Standards Track                    [Page 17]
+
+RFC 5576             Source-Specific SDP Attributes            June 2009
+
+
+Authors' Addresses
+
+   Jonathan Lennox
+   Vidyo, Inc.
+   433 Hackensack Avenue
+   Sixth Floor
+   Hackensack, NJ  07601
+   US
+
+   EMail: jonathan@vidyo.com
+
+
+   Joerg Ott
+   Helsinki University of Technology (TKK)
+   Department of Communications and Networking
+   PO Box 3000
+   FIN-02015 TKK
+   Finland
+
+   EMail: jo@acm.org
+
+
+   Thomas Schierl
+   Fraunhofer HHI
+   Einsteinufer 37
+   D-10587 Berlin
+   Germany
+
+   Phone: +49-30-31002-227
+   EMail: ts@thomas-schierl.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lennox, et al.              Standards Track                    [Page 18]
+