GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5576

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5576.txt · Last modified: 2009/06/30 23:08 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki