diff options
Diffstat (limited to 'doc/rfc/rfc5576.txt')
| -rw-r--r-- | doc/rfc/rfc5576.txt | 1011 |
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] + |