Source-Specific Media Attributes in the Session Description Protocol (SDP)
draft-ietf-mmusic-sdp-source-attributes-01

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

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 August 28, 2008.

Abstract

The Session Description Protocol 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, identified by their Synchronization Source Identifiers (SSRCs), in SDP, associate attributes with these sources, and express relationships among sources. It also defines several source-level attributes which can be used to describe properties of media sources.

Table of Contents

1.  Introduction
2.  Terminology
3.  Overview
4.  Media Attributes
    4.1.  The "ssrc" Media Attribute
    4.2.  The "ssrc-group" Media Attribute
5.  Usage of Identified Source Identifiers in RTP
6.  Source Attributes
    6.1.  The "cname" Source Attribute
    6.2.  The "previous-ssrc" Source Attribute
    6.3.  The "fmtp" Source Attribute
    6.4.  Other Source Attributes
7.  Examples
8.  Usage With the Offer/Answer Model
9.  Backward Compatibility
10.  Formal Grammar
11.  Security Considerations
12.  IANA Considerations
    12.1.  New SDP Media-Level Attributes
    12.2.  Registry for Source-Level Attributes
    12.3.  Registry for Source Grouping Semantics
13.  References
    13.1.  Normative References
    13.2.  Informative References
Appendix A.  Changes From Earlier Versions
    A.1.  Changes From Working Group Draft -00
    A.2.  Changes From Individual Submission Draft -01
    A.3.  Changes From Individual Submission Draft -00
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

The Session Description Protocol (SDP) (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] provides mechanisms to describe attributes of multimedia sessions and of media streams (e.g., Real-time Transport Protocol (RTP) (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [RFC3550] sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream.

Several recently-proposed protocols, notably RTP Single-Source Multicast (Ott, J. and J. Chesterfield, “RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback,” November 2009.) [I‑D.ietf‑avt‑rtcpssm] 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 Identifiers (SSRCs) do not collide with those of media senders, as the RTP specification (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [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) (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [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 Sources Identifiers (SSRCs), in SDP, associate attributes with these sources, and 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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119] and indicate requirement levels for compliant implementations.

3.  Overview

In the Real-Time Transport Protocol (RTP) (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [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 (Ott, J. and J. Chesterfield, “RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback,” November 2009.) [I‑D.ietf‑avt‑rtcpssm] can make the situation more complex. RTP topologies are discussed in more detail in [RFC5117] (Westerlund, M. and S. Wenger, “RTP Topologies,” January 2008.).

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 identifiers, which are used to identify their RTP Control Protocol (RTCP) receiver reports and other feedback messages.

Messages of the Session Description Protocol (SDP) (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566], known as Session Descriptions, describe Multimedia Sessions. A multimedia session is a set of multimedia senders and receivers, and 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) (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.) [I‑D.ietf‑mmusic‑ice], to denote the object described by an SDP media description. This term is unfortunately rather confusing, as the RTP specification (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [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, in particular 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 (Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, “Grouping of Media Lines in the Session Description Protocol (SDP),” December 2002.) [RFC3388] represents relationships among media streams within a multimedia session.

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 synchronizaton source ID (SSRC) of the 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 attribute specific to the given media source. The source-level 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. "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 (The "cname" Source Attribute), 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, MIKEY (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.) [RFC3830][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),” July 2006.)), 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 (Registry for Source-Level Attributes).

Figure 4 (Syntax of the ssrc media attribute) in Section 10 (Formal Grammar) gives a formal Augmented Backus-Naur Form (ABNF) (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [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 (Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, “Grouping of Media Lines in the Session Description Protocol (SDP),” December 2002.) [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 (Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, “Grouping of Media Lines in the Session Description Protocol (SDP),” December 2002.) [RFC3388]. The initial semantics values defined for the ssrc-group attribute are FID (Flow Identification) (Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, “Grouping of Media Lines in the Session Description Protocol (SDP),” December 2002.) [RFC3388] and FEC (Forward Error Correction) (Li, A., “Forward Error Correction Grouping Semantics in Session Description Protocol,” November 2006.) [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" semantics values follow the same syntax as "group" semantics values, they are defined independently. All "ssrc-group" semantics values MUST be registered with IANA, using the registry defined in Section 12.3 (Registry for Source Grouping Semantics).

(The other "group" semantics registered with IANA as of this writing are not useful for source grouping. LS (Lip Synchronization) (Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, “Grouping of Media Lines in the Session Description Protocol (SDP),” December 2002.) [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) (Camarillo, G. and A. Monrad, “Mapping of Media Streams to Resource Reservation Flows,” April 2003.) [RFC3524] and ANAT (Alternative Network Address Types) (Camarillo, G. and J. Rosenberg, “The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework,” June 2005.) [RFC4091] refer specifically to the media stream's transport characteristics. CS (Composite Session) (Mehta, H., “SDP Descriptors for FLUTE,” January 2006.) [I‑D.mehta‑rmt‑flute‑sdp] 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.

Figure 5 (Syntax of the ssrc-group media attribute) in Section 10 (Formal Grammar) gives a formal Augmented Backus-Naur Form (ABNF) (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [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 (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [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 which 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 (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [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 (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [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.

If, following RTP's collision-resolution procedures (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [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 (The "previous-ssrc" Source Attribute), 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 same CNAME for at least the duration of the RTP session's participant timeout interval (see Section 6.3.5 of [RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.)). 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 (Backward Compatibility) 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 (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [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 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 (Syntax of the cname source attribute) in Section 10 (Formal Grammar) gives a formal Augmented Backus-Naur Form (ABNF) (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [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 (Usage of Identified Source Identifiers in RTP)) 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 (Syntax of the previous-ssrc source attribute) in Section 10 (Formal Grammar) gives a formal Augmented Backus-Naur Form (ABNF) (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [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.

6.4.  Other Source Attributes

This document only defines source attributes which are necessary or useful for an endpoint to decode and render the sources in a media stream. It does include any attributes which 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

The example in Figure 1 (Example: declaration of a single synchronization source) 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

The example in Figure 2 (Example: a media stream containing several independent sources from a single session member.) 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

The example in Figure 3 (Example: relationship among several sources: retransmission sources) shows how the relationships among sources used for RTP Retransmission (Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, “RTP Retransmission Payload Format,” July 2006.) [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] (Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, “RTP Retransmission Payload Format,” July 2006.).

8.  Usage With the Offer/Answer Model

When used with the SDP Offer/Answer Model (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.) [RFC3264], SDP source-specific attributes describe only the sources with which 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 defintion 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 (Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, “RTP Retransmission Payload Format,” July 2006.) [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 (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [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.

10.  Formal Grammar

This section gives a formal Augmented Backus-Naur Form (ABNF) (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [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.

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

ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id)
; The definition of "semantics" is in RFC 3388.
; (It is the type of grouping being done.)

attribute =/ ssrc-group-attr

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

previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id)

attribute =/ previous-ssrc-attr

11.  Security Considerations

All the security implications of RTP (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [RFC3550] and of SDP (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] apply. Explicitly describing the multiplexed sources of an RTP media stream does not appear to add any further security issues.

12.  IANA Considerations

12.1.  New SDP Media-Level Attributes

This document defines two SDP media-level attributes: "ssrc" and "ssrc-group". These attributes should be 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" Media Attribute).

The "ssrc-group" attribute is used to identify relationships among media sources within a media stream. Its format is defined in Section 4.2 (The "ssrc-group" Media Attribute).

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] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.):

New attribute registrations are accepted according to the "Specification Required" policy of [RFC2434] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” October 1998.), provided that the specification includes the following information:

• contact name, email address, and telephone number
• attribute name (as it will appear in SDP)
• long-form attribute name in English
• whether the attribute value is subject to the charset attribute
• a one-paragraph explanation of the purpose of the attribute
• 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.

Source-level attributes which are substantially similar in semantics to existing session-level or media-level attributes SHOULD re-use the same attribute name as those session-level or media-level attributes. Source-level attributes SHOULD NOT re-use 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 (Source Attributes) of this document, is in Figure 8 (Initial Contents of IANA Source Attribute Registry).

Type            SDP Name                     Reference
----            ------------------           ---------
att-field (source level)
                cname                        [RFCXXXX]
                previous-ssrc                [RFCXXXX]
                fmtp                         [RFCXXXX]

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

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] (Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, “Grouping of Media Lines in the Session Description Protocol (SDP),” December 2002.):

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.

• A brief description of the semantics.
• Token to be used within the group attribute. This token may be of any length, but SHOULD be no more than four characters long.
• Reference to an standards track RFC.

Source grouping semantics values which are substantially similar to existing media grouping semantics values SHOULD re-use the same semantics name as that media gropuing semantics. Source grouping semantics SHOULD NOT re-use source grouping semantics names that are unrelated or substantially different.

The initial set of source grouping semantics values, for the semantics specified in Section 4.2 (The "ssrc-group" Media Attribute) of this document, is in Figure 9 (Initial Contents of IANA Source Group Semantics Registry).

Semantics                           Token     Reference
-------------------                 -----     ---------
Flow Identification                 FID       [RFCXXXX]
Forward Error Correction            FEC       [RFCXXXX]

(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

13.2. Informative References

Appendix A.  Changes From Earlier Versions

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

A.1.  Changes From Working Group Draft -00

• Removed discussion of ssrc-multiplexing for layered codecs.
• Clarified that each "ssrc" attribute specifies only a single source-level attribute.
• Clarified that "ssrc-group" semantics are defined separately from "group" semantics.
• Clarified reference for the Td parameter.
• Updated references.
• Corrected typographical errors.

A.2.  Changes From Individual Submission Draft -01

• Added definitions of the new IANA registries and registrations needed.
• Clarified that none of the attributes defined in the document are dependent on the charset attribute.
• Clarified that ssrc attributes must be consistent with other SDP mechanisms (such as MIKEY) that also specify SSRCs.
• Removed open issues section.

A.3.  Changes From Individual Submission Draft -00

• Clarified that this document is expressly defining declarative source descriptions, not source offer/answer or other information.
• Removed the definitions of the "information", "bandwidth", "sendrecv", "sendonly", "recvonly", "inactive", "charset", "sdplang", "lang", "framerate", and "quality" source attributes. They are all unnecessary for source decodability, and to the extent they are otherwise useful they are probably better handled by RTCP Source Description (SDES) packets or feedback (AVPF) messages.
• Added text to the Backward Compatibility and Security Considerations sections.

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.