draft-ietf-mmusic-sdp-source-attributes-02.txt   rfc5576.txt 
MMUSIC J. Lennox Network Working Group J. Lennox
Internet-Draft Vidyo Request for Comments: 5576 Vidyo
Intended status: Standards Track J. Ott Category: Standards Track J. Ott
Expires: May 4, 2009 Helsinki University of Technology Helsinki University of Technology
T. Schierl T. Schierl
Fraunhofer HHI Fraunhofer HHI
October 31, 2008 Source-Specific Media Attributes in the
Session Description Protocol (SDP)
Source-Specific Media Attributes in the Session Description Protocol
(SDP)
draft-ietf-mmusic-sdp-source-attributes-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any Status of This Memo
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 This document specifies an Internet standards track protocol for the
Task Force (IETF), its areas, and its working groups. Note that Internet community, and requests discussion and suggestions for
other groups may also distribute working documents as Internet- improvements. Please refer to the current edition of the "Internet
Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
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 Copyright (c) 2009 IETF Trust and the persons identified as the
http://www.ietf.org/ietf/1id-abstracts.txt. document authors. All rights reserved.
The list of Internet-Draft Shadow Directories can be accessed at This document is subject to BCP 78 and the IETF Trust's Legal
http://www.ietf.org/shadow.html. 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 Internet-Draft will expire on May 4, 2009. 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.
Abstract Abstract
The Session Description Protocol provides mechanisms to describe The Session Description Protocol (SDP) provides mechanisms to
attributes of multimedia sessions and of individual media streams describe attributes of multimedia sessions and of individual media
(e.g., Real-time Transport Protocol (RTP) sessions) within a streams (e.g., Real-time Transport Protocol (RTP) sessions) within a
multimedia session, but does not provide any mechanism to describe multimedia session, but does not provide any mechanism to describe
individual media sources within a media stream. This document individual media sources within a media stream. This document
defines a mechanism to describe RTP media sources, identified by defines a mechanism to describe RTP media sources, which are
their Synchronization Source Identifiers (SSRCs), in SDP, associate identified by their synchronization source (SSRC) identifiers, in
attributes with these sources, and express relationships among SDP, to associate attributes with these sources, and to express
sources. It also defines several source-level attributes which can relationships among sources. It also defines several source-level
be used to describe properties of media sources. attributes that can be used to describe properties of media sources.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology .....................................................3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview ........................................................3
4. Media Attributes . . . . . . . . . . . . . . . . . . . . . . . 5 4. Media Attributes ................................................4
4.1. The "ssrc" Media Attribute . . . . . . . . . . . . . . . . 5 4.1. The "ssrc" Media Attribute .................................5
4.2. The "ssrc-group" Media Attribute . . . . . . . . . . . . . 6 4.2. The "ssrc-group" Media Attribute ...........................6
5. Usage of Identified Source Identifiers in RTP . . . . . . . . 7 5. Usage of Identified Source Identifiers in RTP ...................7
6. Source Attributes . . . . . . . . . . . . . . . . . . . . . . 8 6. Source Attributes ...............................................8
6.1. The "cname" Source Attribute . . . . . . . . . . . . . . . 9 6.1. The "cname" Source Attribute ...............................8
6.2. The "previous-ssrc" Source Attribute . . . . . . . . . . . 9 6.2. The "previous-ssrc" Source Attribute .......................9
6.3. The "fmtp" Source Attribute . . . . . . . . . . . . . . . 10 6.3. The "fmtp" Source Attribute ................................9
6.4. Other Source Attributes . . . . . . . . . . . . . . . . . 10 6.4. Other Source Attributes ...................................10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Examples .......................................................10
8. Usage With the Offer/Answer Model . . . . . . . . . . . . . . 11 8. Usage With the Offer/Answer Model ..............................11
9. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12 9. Backward Compatibility .........................................11
10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Formal Grammar ................................................12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations .......................................13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations ...........................................14
12.1. New SDP Media-Level Attributes . . . . . . . . . . . . . . 13 12.1. New SDP Media-Level Attributes ...........................14
12.2. Registry for Source-Level Attributes . . . . . . . . . . . 14 12.2. Registry for Source-Level Attributes .....................14
12.3. Registry for Source Grouping Semantics . . . . . . . . . . 15 12.3. Registry for Source Grouping Semantics ...................15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. References ....................................................16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 13.1. Normative References .....................................16
13.2. Informative References . . . . . . . . . . . . . . . . . . 16 13.2. Informative References ...................................16
Appendix A. Changes From Earlier Versions . . . . . . . . . . . . 17
A.1. Changes From Working Group Draft -01 . . . . . . . . . . . 17
A.2. Changes From Working Group Draft -00 . . . . . . . . . . . 17
A.3. Changes From Individual Submission Draft -01 . . . . . . . 17
A.4. Changes From Individual Submission Draft -00 . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
The Session Description Protocol (SDP) [RFC4566] provides mechanisms The Session Description Protocol (SDP) [RFC4566] provides mechanisms
to describe attributes of multimedia sessions and of media streams to describe attributes of multimedia sessions and of media streams
(e.g., Real-time Transport Protocol (RTP) [RFC3550] sessions) within (e.g., Real-time Transport Protocol (RTP) [RFC3550] sessions) within
a multimedia session, but does not provide any mechanism to describe a multimedia session, but does not provide any mechanism to describe
individual media sources within a media stream. individual media sources within a media stream.
Several recently-proposed protocols, notably RTP Single-Source Several recently proposed protocols, notably RTP single-source
Multicast [I-D.ietf-avt-rtcpssm] have found it useful to describe multicast [EXT-SSM], have found it useful to describe specific media
specific media sources in SDP messages. Single-source multicast, in sources in SDP messages. Single-source multicast, in particular,
particular, needs to ensure that receivers' RTP Synchronization needs to ensure that receivers' RTP synchronization source (SSRC)
Source Identifiers (SSRCs) do not collide with those of media identifiers do not collide with those of media senders, as the RTP
senders, as the RTP specification [RFC3550] requires that colliding specification [RFC3550] requires that colliding sources change their
sources change their SSRC values after a collision has been detected. SSRC values after a collision has been detected. Earlier work has
Earlier work has used mechanisms specific to each protocol to used mechanisms specific to each protocol to describe the individual
describe the individual sources of an RTP session. sources of an RTP session.
Moreover, whereas the Real-Time Transport Protocol (RTP) [RFC3550] is Moreover, whereas the Real-time Transport Protocol (RTP) [RFC3550] is
defined as allowing multiple sources in an RTP session (for example, defined as allowing multiple sources in an RTP session (for example,
if a user has more than one camera), SDP has no existing mechanism 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, for an endpoint to indicate that it will be using multiple sources or
or to describe their characteristics individually. to describe their characteristics individually.
To address all these problems, this document defines a mechanism to To address all these problems, this document defines a mechanism to
describe RTP sources, identified by their Synchronization Sources describe RTP sources, identified by their synchronization source
Identifiers (SSRCs), in SDP, associate attributes with these sources, (SSRC) identifier, in SDP, to associate attributes with these
and express relationships among individual sources. It also defines sources, and to express relationships among individual sources. It
a number of new SDP attributes that apply to individual sources also defines a number of new SDP attributes that apply to individual
("source-level" attributes); describes how a number of existing media sources ("source-level" attributes), describes how a number of
stream ("media-level") attributes can also be applied at the source existing media stream ("media-level") attributes can also be applied
level; and establishes IANA registries for source-level attributes at the source level, and establishes IANA registries for source-level
and source grouping semantics. attributes and source grouping semantics.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] and document are to be interpreted as described in RFC 2119 [RFC2119] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3. Overview 3. Overview
In the Real-Time Transport Protocol (RTP) [RFC3550], an association In the Real-time Transport Protocol (RTP) [RFC3550], an association
among a group of communicating participants is known as an RTP among a group of communicating participants is known as an RTP
Session. An RTP session is typically associated with a single Session. An RTP session is typically associated with a single
transport address (in the case of multicast) or communication flow transport address (in the case of multicast) or communication flow
(in the case of unicast), though RTP translators and single-source (in the case of unicast), though RTP translators and single-source
multicast [I-D.ietf-avt-rtcpssm] can make the situation more complex. multicast [EXT-SSM] can make the situation more complex. RTP
RTP topologies are discussed in more detail in [RFC5117]. topologies are discussed in more detail in [RFC5117].
Within an RTP session, the source of a single stream of RTP packets Within an RTP session, the source of a single stream of RTP packets
is known as a synchronization source (SSRC). Every synchronization is known as a synchronization source (SSRC). Every synchronization
source is identified by a 32-bit numeric identifier. In addition, source is identified by a 32-bit numeric identifier. In addition,
receivers (who may never send RTP packets) also have source receivers (who may never send RTP packets) also have source
identifiers, which are used to identify their RTP Control Protocol identifiers, which are used to identify their RTP Control Protocol
(RTCP) receiver reports and other feedback messages. (RTCP) receiver reports and other feedback messages.
Messages of the Session Description Protocol (SDP) [RFC4566], known Messages of the Session Description Protocol (SDP) [RFC4566], known
as Session Descriptions, describe Multimedia Sessions. A multimedia as session descriptions, describe multimedia sessions. A multimedia
session is a set of multimedia senders and receivers, and the data session is a set of multimedia senders and receivers as well as the
streams flowing from senders to receivers. A multimedia session data streams flowing from senders to receivers. A multimedia session
contains a number of Media Streams, which are the individual RTP contains a number of media streams, which are the individual RTP
sessions or other media paths over which one type of multimedia data sessions or other media paths over which one type of multimedia data
is carried. Information that applies to an entire multimedia session is carried. Information that applies to an entire multimedia session
is called Session-Level information, while information pertaining to is called session-level information, while information pertaining to
one media stream is called Media-Level information. The collection one media stream is called media-level information. The collection
of all the information describing a media stream is known as a Media of all the information describing a media stream is known as a media
Description. (Media descriptions are also sometimes known informally description. (Media descriptions are also sometimes known informally
as SDP "m"-lines, after the SDP syntax that begins a media as SDP "m"-lines, after the SDP syntax that begins a media
description.) Several standard information elements are defined at description.) Several standard information elements are defined at
both the session level and the media level. Extended information can both the session level and the media level. Extended information can
be included at both levels through the use of attributes. be included at both levels through the use of attributes.
(The term "Media Stream" does not appear in the SDP specification (The term "media stream" does not appear in the SDP specification
itself, but is used by a number of SDP extensions, for instance itself, but is used by a number of SDP extensions, for instance,
Interactive Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice], Interactive Connectivity Establishment (ICE) [ICE], to denote the
to denote the object described by an SDP media description. This object described by an SDP media description. This term is
term is unfortunately rather confusing, as the RTP specification unfortunately rather confusing, as the RTP specification [RFC3550]
[RFC3550] uses the term "media stream" to refer to an individual uses the term "media stream" to refer to an individual media source
media source or RTP packet stream, identified by an SSRC, whereas an or RTP packet stream, identified by an SSRC, whereas an SDP media
SDP media stream describes an entire RTP session, which can contain stream describes an entire RTP session, which can contain any number
any number of RTP sources. In this document, the term "media stream" of RTP sources. In this document, the term "media stream" means an
means an SDP media stream, i.e. the thing described by an SDP media SDP media stream, i.e., the thing described by an SDP media
description, whereas "media source" is used for a single source of description, whereas "media source" is used for a single source of
media packets, i.e. an RTP media stream.) media packets, i.e., an RTP media stream.)
The core SDP specification does not have any way of describing The core SDP specification does not have any way of describing
individual media sources, in particular RTP synchronization sources, individual media sources, particularly RTP synchronization sources,
within a media stream. To address this problem, in this document we within a media stream. To address this problem, in this document we
introduce a third level of information, called Source-Level introduce a third level of information, called source-level
information. Syntactically, source-level information is described by information. Syntactically, source-level information is described by
a new SDP media-level attribute "ssrc", which identifies specific a new SDP media-level attribute, "ssrc", which identifies specific
synchronization sources within an RTP session, and acts as a meta- synchronization sources within an RTP session and acts as a meta-
attribute mapping source-level attribute information to these attribute mapping source-level attribute information to these
sources. sources.
This document also defines an SDP media-level attribute "ssrc-group", This document also defines an SDP media-level attribute, "ssrc-
which can represent relationships among media sources within an RTP group", which can represent relationships among media sources within
session, in much the same way as the "group" attribute [RFC3388] an RTP session in much the same way as the "group" attribute
represents relationships among media streams within a multimedia [RFC3388] represents relationships among media streams within a
session. multimedia session.
4. Media Attributes 4. Media Attributes
This section defines two media-level attributes, "ssrc" and "ssrc- This section defines two media-level attributes, "ssrc" and "ssrc-
group". group".
4.1. The "ssrc" Media Attribute 4.1. The "ssrc" Media Attribute
a=ssrc:<ssrc-id> <attribute> a=ssrc:<ssrc-id> <attribute>
a=ssrc:<ssrc-id> <attribute>:<value> a=ssrc:<ssrc-id> <attribute>:<value>
The SDP media attribute "ssrc" indicates a property (known as a The SDP media attribute "ssrc" indicates a property (known as a
"source-level attribute") of a media source (RTP stream) within an "source-level attribute") of a media source (RTP stream) within an
RTP session. <ssrc-id> is the synchronizaton source ID (SSRC) of the RTP session. <ssrc-id> is the synchronization source (SSRC) ID of the
source being described, interpreted as a 32-bit unsigned integer in source being described, interpreted as a 32-bit unsigned integer in
network byte order and represented in decimal. <attribute> or network byte order and represented in decimal. <attribute> or
<attribute>:<value> represent the source-level attribute specific to <attribute>:<value> represents the source-level attribute specific to
the given media source. The source-level attribute follows the the given media source. The source-level attribute follows the
syntax of the SDP "a=" line. It thus consists either of a single 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. attribute name (a flag) or an attribute name and value, e.g.,
"cname:user@example.com". No attributes of the former type are "cname:user@example.com". No attributes of the former type are
defined by this document. defined by this document.
Within a media stream, ssrc attributes with the same value of Within a media stream, "ssrc" attributes with the same value of
<ssrc-id> describe different attributes of the same media sources. <ssrc-id> describe different attributes of the same media sources.
Across media streams, <ssrc-id> values are not correlated (unless Across media streams, <ssrc-id> values are not correlated (unless
correlation is indicated by media-stream grouping or some other correlation is indicated by media-stream grouping or some other
mechanism) and MAY be repeated. mechanism) and MAY be repeated.
Each "ssrc" media attribute specifies a single source-level attribute Each "ssrc" media attribute specifies a single source-level attribute
for the given <ssrc-id>. For each source mentioned in SDP, the for the given <ssrc-id>. For each source mentioned in SDP, the
source-level attribute "cname", defined in Section 6.1, MUST be source-level attribute "cname", defined in Section 6.1, MUST be
provided. Any number of other source-level attributes for the source provided. Any number of other source-level attributes for the source
MAY also be provided. MAY also be provided.
The "ssrc" media attribute MAY be used for any RTP-based media The "ssrc" media attribute MAY be used for any RTP-based media
transport. It is not defined for other transports. transport. It is not defined for other transports.
If any other SDP attributes also mention RTP SSRC values (for If any other SDP attributes also mention RTP SSRC values (for
example, MIKEY [RFC3830][RFC4567]), the values used MUST be example, Multimedia Internet KEYing (MIKEY) [RFC3830] [RFC4567]), the
consistent. (These attributes MAY provide additional information values used MUST be consistent. (These attributes MAY provide
about a source described by an "ssrc" attribute, or MAY describe additional information about a source described by an "ssrc"
additional sources.) attribute or MAY describe additional sources.)
Though the source-level attributes specified by the ssrc property Though the source-level attributes specified by the ssrc property
follow the same syntax as session-level and media-level attributes, follow the same syntax as session-level and media-level attributes,
they are defined independently. All source-level attributes MUST be they are defined independently. All source-level attributes MUST be
registered with IANA, using the registry defined in Section 12.2. registered with IANA, using the registry defined in Section 12.2.
Figure 4 in Section 10 gives a formal Augmented Backus-Naur Form Figure 4 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC5234] grammar for the ssrc attribute. (ABNF) [RFC5234] grammar for the "ssrc" attribute.
The "ssrc" media attribute is not dependent on charset. The "ssrc" media attribute is not dependent on charset.
4.2. The "ssrc-group" Media Attribute 4.2. The "ssrc-group" Media Attribute
a=ssrc-group:<semantics> <ssrc-id> ... a=ssrc-group:<semantics> <ssrc-id> ...
The SDP media attribute "ssrc-group" expresses a relationship among The SDP media attribute "ssrc-group" expresses a relationship among
several sources of an RTP session. It is analogous to the "group" several sources of an RTP session. It is analogous to the "group"
session-level attribute [RFC3388], which expresses a relationship session-level attribute [RFC3388], which expresses a relationship
among media streams in an SDP multimedia session (i.e., a among media streams in an SDP multimedia session (i.e., a
relationship among several logically related RTP sessions). As relationship among several logically related RTP sessions). As
sources are already identified by their SSRC IDs, no analogous sources are already identified by their SSRC IDs, no analogous
property to the "mid" attribute is necessary; groups of sources are property to the "mid" attribute is necessary; groups of sources are
identified by their SSRC IDs directly. identified by their SSRC IDs directly.
The <semantics> parameter is taken from the specification of the The <semantics> parameter is taken from the specification of the
"group" attribute [RFC3388]. The initial semantics values defined "group" attribute [RFC3388]. The initial semantic values defined for
for the ssrc-group attribute are FID (Flow Identification) [RFC3388] the "ssrc-group" attribute are FID (Flow Identification) [RFC3388]
and FEC (Forward Error Correction) [RFC4756]. In each case, the and FEC (Forward Error Correction) [RFC4756]. In each case, the
relationship among the grouped sources is the same as the relationship among the grouped sources is the same as the
relationship among corresponding sources in media streams grouped relationship among corresponding sources in media streams grouped
using the SDP "group" attribute. using the SDP "group" attribute.
Though the "ssrc-group" semantics values follow the same syntax as Though the "ssrc-group" semantic values follow the same syntax as
"group" semantics values, they are defined independently. All "ssrc- "group" semantic values, they are defined independently. All "ssrc-
group" semantics values MUST be registered with IANA, using the group" semantic values MUST be registered with IANA, using the
registry defined in Section 12.3. registry defined in Section 12.3.
(The other "group" semantics registered with IANA as of this writing (The other "group" semantics registered with IANA as of this writing
are not useful for source grouping. LS (Lip Synchronization) are not useful for source grouping. LS (Lip Synchronization)
[RFC3388] is redundant for sources within a media stream, as RTP [RFC3388] is redundant for sources within a media stream as RTP
sources with the same CNAME are implicitly synchronized in RTP. SRF sources with the same CNAME are implicitly synchronized in RTP. SRF
(Single Reservation Flow) [RFC3524] and ANAT (Alternative Network (Single Reservation Flow) [RFC3524] and ANAT (Alternative Network
Address Types) [RFC4091] refer specifically to the media stream's Address Types) [RFC4091] refer specifically to the media stream's
transport characteristics. CS (Composite Session) transport characteristics. CS (Composite Session) [FLUTE] is used to
[I-D.mehta-rmt-flute-sdp] is used to group FLUTE sessions, and so is group FLUTE sessions, and so is not applicable to RTP.)
not applicable to RTP.)
The ssrc-group attribute indicates the sources in a group by listing The "ssrc-group" attribute indicates the sources in a group by
the <ssrc-id>s of the sources in the group. It MUST list at least listing the <ssrc-id>s of the sources in the group. It MUST list at
one <ssrc-id> for a group, and MAY list any number of additional 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 ones. Every <ssrc-id> listed in an "ssrc-group" attribute MUST be
defined by a corresponding "ssrc:" line in the same media defined by a corresponding "ssrc:" line in the same media
description. description.
The "ssrc-group" media attribute is not dependent on charset. The "ssrc-group" media attribute is not dependent on charset.
Figure 5 in Section 10 gives a formal Augmented Backus-Naur Form Figure 5 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC5234] grammar for the ssrc-group attribute. (ABNF) [RFC5234] grammar for the "ssrc-group" attribute.
5. Usage of Identified Source Identifiers in RTP 5. Usage of Identified Source Identifiers in RTP
The synchronization source identifiers used in an RTP session are The synchronization source identifiers used in an RTP session are
chosen randomly and independently by endpoints. As such, it is chosen randomly and independently by endpoints. As such, it is
possible for two RTP endpoints to choose the same SSRC identifier. possible for two RTP endpoints to choose the same SSRC identifier.
Though the probability of this is low, the RTP specification Though the probability of this is low, the RTP specification
[RFC3550] requires that all RTP endpoints MUST be prepared to detect [RFC3550] requires that all RTP endpoints MUST be prepared to detect
and resolve collisions. and resolve collisions.
skipping to change at page 7, line 43 skipping to change at page 7, line 29
be out of date. The actual binding between SSRCs and source CNAMEs be out of date. The actual binding between SSRCs and source CNAMEs
can only be identified by the source description (SDES) RTCP packets can only be identified by the source description (SDES) RTCP packets
transmitted on the RTP session. transmitted on the RTP session.
When endpoints are choosing their own local SSRC values for media When endpoints are choosing their own local SSRC values for media
streams for which source-level attributes have been specified, they streams for which source-level attributes have been specified, they
MUST NOT use for themselves any SSRC identifiers mentioned in media MUST NOT use for themselves any SSRC identifiers mentioned in media
descriptions they have received for the media stream. descriptions they have received for the media stream.
However, sources identified by SDP source-level attributes do not However, sources identified by SDP source-level attributes do not
otherwise affect RTP transport logic. Specifically, sources which otherwise affect RTP transport logic. Specifically, sources that are
are only known through SDP, for which neither RTP nor RTCP packets only known through SDP, for which neither RTP nor RTCP packets have
have been received, MUST NOT be counted for RTP group size been received, MUST NOT be counted for RTP group size estimation, and
estimation, and report blocks MUST NOT be sent for them in SR or RR report blocks MUST NOT be sent for them in SR or RR RTCP messages.
RTCP messages.
Endpoints MUST NOT assume that only the sources mentioned in SDP will Endpoints MUST NOT assume that only the sources mentioned in SDP will
be present in an RTP session; additional sources, with previously be present in an RTP session; additional sources, with previously
unmentioned SSRC IDs, can be added at any time, and endpoints MUST be unmentioned SSRC IDs, can be added at any time, and endpoints MUST be
prepared to receive packets from these sources. (How endpoints prepared to receive packets from these sources. (How endpoints
handle such packets is not specified here; they SHOULD be handled in handle such packets is not specified here; they SHOULD be handled in
the same manner as packets from additional sources would be handled the same manner as packets from additional sources would be handled
had the endpoint not received any a=ssrc: attributes at all.) had the endpoint not received any a=ssrc: attributes at all.)
An endpoint that observes an SSRC collision between its explicitly- An endpoint that observes an SSRC collision between its explicitly
signaled source and another entity that has not explicitly signaled signaled source and another entity that has not explicitly signaled
an SSRC MAY delay its RTP collision-resolution actions [RFC3550] by an SSRC MAY delay its RTP collision-resolution actions [RFC3550] by
5*1.5*Td, where Td is the deterministic calculated reporting interval 5*1.5*Td, where Td is the deterministic, calculated, reporting
for receivers defined in Section 6.3.1 of the RTP specification interval for receivers defined in Section 6.3.1 of the RTP
[RFC3550], to see whether the conflict still exists. (This gives specification [RFC3550], to see whether the conflict still exists.
precedence to explicitly-signaled sources, and places the burden of (This gives precedence to explicitly signaled sources and places the
collision resolution on non-signaled sources.) SSRC collisions burden of collision resolution on non-signaled sources.) SSRC
between multiple explicitly-signaled sources, however, MUST be acted collisions between multiple explicitly-signaled sources, however,
upon immediately. MUST be acted upon immediately.
If, following RTP's collision-resolution procedures [RFC3550], a If, following RTP's collision-resolution procedures [RFC3550], a
source identified by source-level attributes has been forced to source identified by source-level attributes has been forced to
change its SSRC identifier, the author of the SDP containing the change its SSRC identifier, the author of the SDP containing the
source-level attributes for these sources SHOULD send out an updated source-level attributes for these sources SHOULD send out an updated
SDP session description with the new SSRC, if the mechanism by which SDP session description with the new SSRC if the mechanism by which
SDP is being distributed for the multimedia session has a mechanism SDP is being distributed for the multimedia session has a mechanism
to distribute updated SDP. This updated SDP MUST include a previous- to distribute updated SDP. This updated SDP MUST include a
ssrc source-level attribute, described in Section 6.2, listing the "previous-ssrc" source-level attribute, described in Section 6.2,
source's previous SSRC ID. (If only a single source with a given listing the source's previous SSRC ID. (If only a single source with
CNAME has collided, the other RTP session members can infer a a given CNAME has collided, the other RTP session members can infer a
correspondence between the source's old and new SSRC IDs, without correspondence between the source's old and new SSRC IDs without
requiring an updated session description. However, if more than one requiring an updated session description. However, if more than one
source collides at once, or if sources are leaving and re-joining, source collides at once, or if sources are leaving and re-joining,
this inference is not possible. To avoid confusion, therefore, this inference is not possible. To avoid confusion, therefore,
sending updated SDP messages is always RECOMMENDED.) sending updated SDP messages is always RECOMMENDED.)
Endpoints MUST NOT reuse the same SSRC ID for identified sources with 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 the same CNAME for at least the duration of the RTP session's
timeout interval (see Section 6.3.5 of [RFC3550]). They SHOULD NOT participant timeout interval (see Section 6.3.5 of [RFC3550]). They
reuse any SSRC ID ever mentioned in SDP (either by themselves or by SHOULD NOT reuse any SSRC ID ever mentioned in SDP (either by
other endpoints) for the entire lifetime of the RTP session. themselves or by other endpoints) for the entire lifetime of the RTP
session.
Endpoints MUST be prepared for the possibility that other parties in Endpoints MUST be prepared for the possibility that other parties in
the session do not understand SDP source-level attributes, unless the session do not understand SDP source-level attributes, unless
some higher-level mechanism normatively requires them. See Section 9 some higher-level mechanism normatively requires them. See Section 9
for more discussion of this. for more discussion of this.
6. Source Attributes 6. Source Attributes
This section describes specific source attributes that can be applied This section describes specific source attributes that can be applied
to RTP sources. to RTP sources.
skipping to change at page 9, line 17 skipping to change at page 8, line 49
a=ssrc:<ssrc-id> cname:<cname> a=ssrc:<ssrc-id> cname:<cname>
The "cname" source attribute associates a media source with its The "cname" source attribute associates a media source with its
Canonical End-Point Identifier (CNAME) source description (SDES) Canonical End-Point Identifier (CNAME) source description (SDES)
item. This MUST be the CNAME value that the media sender will place item. This MUST be the CNAME value that the media sender will place
in its RTCP SDES packets; it therefore MUST follow the syntax in its RTCP SDES packets; it therefore MUST follow the syntax
conventions of CNAME defined in the RTP specification [RFC3550]. If conventions of CNAME defined in the RTP specification [RFC3550]. If
a session participant receives an RTCP SDES packet associating this a session participant receives an RTCP SDES packet associating this
SSRC with a different CNAME, it SHOULD assume there has been an SSRC 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 collision and that the description of the source that was carried in
the SDP description is not applicable to the actual source being the SDP description is not applicable to the actual source being
received. This source attribute is REQUIRED to be present if any received. This source attribute is REQUIRED to be present if any
source attributes are present for a source. The cname attribute MUST source attributes are present for a source. The "cname" attribute
NOT occur more than once for the same ssrc-id within a given media MUST NOT occur more than once for the same ssrc-id within a given
stream. media stream.
The "cname" source attribute is not dependent on charset. The "cname" source attribute is not dependent on charset.
Figure 6 in Section 10 gives a formal Augmented Backus-Naur Form Figure 6 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC5234] grammar for the cname attribute. (ABNF) [RFC5234] grammar for the "cname" attribute.
6.2. The "previous-ssrc" Source Attribute 6.2. The "previous-ssrc" Source Attribute
a=ssrc:<ssrc-id> previous-ssrc:<ssrc-id> ... a=ssrc:<ssrc-id> previous-ssrc:<ssrc-id> ...
The "previous-ssrc" source attribute associates a media source with The "previous-ssrc" source attribute associates a media source with
previous source identifiers used for the same media source. previous source identifiers used for the same media source.
Following an SSRC change due to an SSRC collision involving a media Following an SSRC change due to an SSRC collision involving a media
source described in SDP, the updated session description describing source described in SDP, the updated session description describing
the source's new SSRC (described in Section 5) MUST include the the source's new SSRC (described in Section 5) MUST include the
previous-ssrc attribute associating the new SSRC with the old one. "previous-ssrc" attribute associating the new SSRC with the old one.
If further updated SDP descriptions are published describing the If further updated SDP descriptions are published describing the
media source, the previous-ssrc attribute SHOULD be included if the media source, the "previous-ssrc" attribute SHOULD be included if the
session description was generated before the participant timeout of session description was generated before the participant timeout of
the old SSRC, and MAY be included after that point. This attribute, 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 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 number of additional SSRCs for the source if the source has collided
more than once. This attribute MUST be present only once for each more than once. This attribute MUST be present only once for each
source. source.
The "previous-ssrc" source attribute is not dependent on charset. The "previous-ssrc" source attribute is not dependent on charset.
Figure 7 in Section 10 gives a formal Augmented Backus-Naur Form Figure 7 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC5234] grammar for the previous-ssrc attribute. (ABNF) [RFC5234] grammar for the previous-ssrc attribute.
6.3. The "fmtp" Source Attribute 6.3. The "fmtp" Source Attribute
skipping to change at page 10, line 27 skipping to change at page 10, line 7
stream. The meaning of the <format specific parameters> is unique stream. The meaning of the <format specific parameters> is unique
for each media type. This parameter MUST only be used for media for each media type. This parameter MUST only be used for media
types for which source-level format parameters have explicitly been types for which source-level format parameters have explicitly been
specified; media-level format parameters MUST NOT be carried over specified; media-level format parameters MUST NOT be carried over
blindly. blindly.
The "fmtp" source attribute is not dependent on charset. The "fmtp" source attribute is not dependent on charset.
6.4. Other Source Attributes 6.4. Other Source Attributes
This document only defines source attributes which are necessary or This document only defines source attributes that are necessary or
useful for an endpoint to decode and render the sources in a media useful for an endpoint to decode and render the sources in a media
stream. It does include any attributes which would contribute to an stream. It does not include any attributes that would contribute to
endpoint's decision to accept or reject a stream, e.g. in an offer/ an endpoint's decision to accept or reject a stream, e.g., in an
answer exchange. Such attributes are for future consideration. offer/answer exchange. Such attributes are for future consideration.
7. Examples 7. Examples
This section gives several examples of SDP descriptions of media This section gives several examples of SDP descriptions of media
sessions containing source attributes. For brevity, only the media sessions containing source attributes. For brevity, only the media
sections of the descriptions are given. sections of the descriptions are given.
m=audio 49168 RTP/AVP 0 m=audio 49168 RTP/AVP 0
a=ssrc:314159 cname:user@example.com a=ssrc:314159 cname:user@example.com
Figure 1: Example: declaration of a single synchronization source Figure 1: Example of a declaration of a single synchronization source
The example in Figure 1 shows an audio stream advertising a single The example in Figure 1 shows an audio stream advertising a single
source. source.
m=video 49170 RTP/AVP 96 m=video 49170 RTP/AVP 96
a=rtpmap:96 H264/90000 a=rtpmap:96 H264/90000
a=ssrc:12345 cname:another-user@example.com a=ssrc:12345 cname:another-user@example.com
a=ssrc:67890 cname:another-user@example.com a=ssrc:67890 cname:another-user@example.com
Figure 2: Example: a media stream containing several independent Figure 2: Example of a media stream containing several independent
sources from a single session member. sources from a single session member
The example in Figure 2 shows a video stream where one participant The example in Figure 2 shows a video stream where one participant
(identified by a single CNAME) has several cameras. The sources (identified by a single CNAME) has several cameras. The sources
could be further distinguished by RTCP Source Description (SDES) could be further distinguished by RTCP Source Description (SDES)
information. information.
m=video 49174 RTP/AVPF 96 98 m=video 49174 RTP/AVPF 96 98
a=rtpmap:96 H.264/90000 a=rtpmap:96 H.264/90000
a=rtpmap:98 rtx/90000 a=rtpmap:98 rtx/90000
a=fmtp:98 apt=96;rtx-time=3000 a=fmtp:98 apt=96;rtx-time=3000
a=ssrc-group:FID 11111 22222 a=ssrc-group:FID 11111 22222
a=ssrc:11111 cname:user3@example.com a=ssrc:11111 cname:user3@example.com
a=ssrc:22222 cname:user3@example.com a=ssrc:22222 cname:user3@example.com
a=ssrc-group:FID 33333 44444 a=ssrc-group:FID 33333 44444
a=ssrc:33333 cname:user3@example.com a=ssrc:33333 cname:user3@example.com
a=ssrc:44444 cname:user3@example.com a=ssrc:44444 cname:user3@example.com
Figure 3: Example: relationship among several sources: retransmission Figure 3: Example of the relationships among
sources several retransmission sources
The example in Figure 3 shows how the relationships among sources The example in Figure 3 shows how the relationships among sources
used for RTP Retransmission [RFC4588] can be explicitly signaled. used for RTP retransmission [RFC4588] can be explicitly signaled.
This prevents the complexity of associating original sources with This prevents the complexity of associating original sources with
retransmission sources when SSRC multiplexing is used for RTP retransmission sources when SSRC multiplexing is used for RTP
retransmission, as is described in Section 5.3 of [RFC4588]. retransmission, as is described in Section 5.3 of [RFC4588].
8. Usage With the Offer/Answer Model 8. Usage With the Offer/Answer Model
When used with the SDP Offer/Answer Model [RFC3264], SDP source- When used with the SDP Offer/Answer Model [RFC3264], SDP source-
specific attributes describe only the sources with which each party specific attributes describe only the sources that each party is
is willing to send (whether it is sending RTP data or RTCP report willing to send (whether it is sending RTP data or RTCP report
blocks). No mechanism is provided by which an answer can accept or blocks). No mechanism is provided by which an answer can accept or
reject individual sources within a media stream; if the set of reject individual sources within a media stream; if the set of
sources in a media stream is unacceptable, the answerer's only option sources in a media stream is unacceptable, the answerer's only option
is to reject the media stream or the entire multimedia session. is to reject the media stream or the entire multimedia session.
The SSRC IDs for sources described by an SDP answer MUST be distinct 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. 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 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/ SSRC IDs for that media stream established in the most recent offer/
answer exchange for the session, and SHOULD be distinct from any SSRC answer exchange for the session and SHOULD be distinct from any SSRC
ID ever used by either party within the multimedia session (whether ID ever used by either party within the multimedia session (whether
or not it is still being used). or not it is still being used).
9. Backward Compatibility 9. Backward Compatibility
According to the defintion of SDP, interpreters of SDP session According to the definition of SDP, interpreters of SDP session
descriptions ignore unknown attributes. Thus, endpoints MUST be descriptions ignore unknown attributes. Thus, endpoints MUST be
prepared that recipients of their RTP media session may not prepared that recipients of their RTP media session may not
understand their explicit source descriptions, unless some external understand their explicit source descriptions, unless some external
mechanism indicates that they were understood. In some cases (such mechanism indicates that they were understood. In some cases (such
as RTP Retransmission [RFC4588]) this may constrain some choices as RTP Retransmission [RFC4588]), this may constrain some choices
about the bitstreams that are transmitted. about the bitstreams that are transmitted.
Source descriptions are specified in this document such that RTP Source descriptions are specified in this document such that RTP
endpoints that are compliant with the RTP specification [RFC3550] endpoints that are compliant with the RTP specification [RFC3550]
will be able to decode the media streams they describe whether or not will be able to decode the media streams they describe whether or not
they support explicit source descriptions. However, some deployed they support explicit source descriptions. However, some deployed
RTP implementations may not actually support multiple media sources RTP implementations may not actually support multiple media sources
in a media stream. Media senders MAY wish to restrict themselves to 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 a single source at a time unless they have some means of concluding
that the receivers of the media stream support source multiplexing. that the receivers of the media stream support source multiplexing.
10. Formal Grammar 10. Formal Grammar
This section gives a formal Augmented Backus-Naur Form (ABNF) This section gives a formal Augmented Backus-Naur Form (ABNF)
[RFC5234] grammar for each of the new media and source attributes [RFC5234] grammar for each of the new media and source attributes
defined in this document. Grammars for existing session or media defined in this document. Grammars for existing session or media
attributes which have been extended to be source attributes are not attributes that have been extended to be source attributes are not
included. 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.
ssrc-attr = "ssrc:" ssrc-id SP attribute ssrc-attr = "ssrc:" ssrc-id SP attribute
; The base definition of "attribute" is in RFC 4566. ; The base definition of "attribute" is in RFC 4566.
; (It is the content of "a=" lines.) ; (It is the content of "a=" lines.)
ssrc-id = integer ; 0 - 2**32 - 1
ssrc-id = integer ; 0 .. 2**32 - 1
attribute =/ ssrc-attr attribute =/ ssrc-attr
Figure 4: Syntax of the ssrc media attribute Figure 4: Syntax of the "ssrc" media attribute
ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id) 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.) 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 attribute =/ ssrc-group-attr
Figure 5: Syntax of the ssrc-group media attribute Figure 5: Syntax of the "ssrc-group" media attribute
cname-attr = "cname:" cname cname-attr = "cname:" cname
cname = byte-string cname = byte-string
; Following the syntax conventions for CNAME as defined in RFC 3550. ; Following the syntax conventions for CNAME as defined in RFC 3550.
; The definition of "byte-string" is in RFC 4566. ; The definition of "byte-string" is in RFC 4566.
attribute =/ cname-attr attribute =/ cname-attr
Figure 6: Syntax of the cname source attribute Figure 6: Syntax of the "cname" source attribute
previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id) previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id)
attribute =/ previous-ssrc-attr attribute =/ previous-ssrc-attr
Figure 7: Syntax of the previous-ssrc source attribute Figure 7: Syntax of the "previous-ssrc" source attribute
11. Security Considerations 11. Security Considerations
All the security implications of RTP [RFC3550] and of SDP [RFC4566] All the security implications of RTP [RFC3550] and of SDP [RFC4566]
apply. Explicitly describing the multiplexed sources of an RTP media apply. Explicitly describing the multiplexed sources of an RTP media
stream does not appear to add any further security issues. stream does not appear to add any further security issues.
12. IANA Considerations 12. IANA Considerations
12.1. New SDP Media-Level Attributes 12.1. New SDP Media-Level Attributes
This document defines two SDP media-level attributes: "ssrc" and This document defines two SDP media-level attributes: "ssrc" and
"ssrc-group". These attributes should be registered by IANA under "ssrc-group". These attributes have been registered by IANA under
"Session Description Protocol (SDP) Parameters" under "att-field "Session Description Protocol (SDP) Parameters" under "att-field
(media level only)". (media level only)".
The "ssrc" attribute is used to identify characteristics of media The "ssrc" attribute is used to identify characteristics of media
sources within a media stream. Its format is defined in Section 4.1. sources within a media stream. Its format is defined in Section 4.1.
The "ssrc-group" attribute is used to identify relationships among The "ssrc-group" attribute is used to identify relationships among
media sources within a media stream. Its format is defined in media sources within a media stream. Its format is defined in
Section 4.2. Section 4.2.
12.2. Registry for Source-Level Attributes 12.2. Registry for Source-Level Attributes
This specification creates a new IANA registry named "att-field This specification creates a new IANA registry named "att-field
(source level)" within the SDP parameters registry. Source (source level)" within the SDP parameters registry. Source
attributes MUST be registered with IANA and documented, under the attributes MUST be registered with IANA and documented under the same
same rules as for SDP session-level and media-level attributes as rules as for SDP session-level and media-level attributes as
specified in [RFC4566]: specified in [RFC4566].
New attribute registrations are accepted according to the New attribute registrations are accepted according to the
"Specification Required" policy of [RFC5226], provided that the "Specification Required" policy of [RFC5226], provided that the
specification includes the following information: specification includes the following information:
o contact name, email address, and telephone number o contact name, email address, and telephone number
o attribute name (as it will appear in SDP) o attribute name (as it will appear in SDP)
o long-form attribute name in English o long-form attribute name in English
o whether the attribute value is subject to the charset attribute o whether the attribute value is subject to the charset attribute
o a one-paragraph explanation of the purpose of the attribute o a one-paragraph explanation of the purpose of the attribute
o a specification of appropriate attribute values for this attribute o a specification of appropriate attribute values for this attribute
The above is the minimum that IANA will accept. Attributes that are The above is the minimum that IANA will accept. The Expert Reviewer
expected to see widespread use and interoperability SHOULD be will determine if the proposed attributes are expected to see
documented with a standards-track RFC that specifies the attribute widespread use and interoperability; in that case, the attributes
more precisely. MUST be specified in a Standards Track RFC.
Submitters of registrations should ensure that the specification is Submitters of registrations should ensure that the specification is
in the spirit of SDP attributes, most notably that the attribute is in the spirit of SDP attributes, most notably that the attribute is
platform independent in the sense that it makes no implicit platform independent in the sense that it makes no implicit
assumptions about operating systems and does not name specific pieces assumptions about operating systems and does not name specific pieces
of software in a manner that might inhibit interoperability. of software in a manner that might inhibit interoperability.
Source-level attributes which are substantially similar in semantics Source-level attributes that are substantially similar in semantics
to existing session-level or media-level attributes SHOULD re-use the to existing session-level or media-level attributes SHOULD reuse the
same attribute name as those session-level or media-level attributes. same attribute name as those session-level or media-level attributes.
Source-level attributes SHOULD NOT re-use attribute names of session- Source-level attributes SHOULD NOT reuse attribute names of session-
level or media-level attributes that are unrelated or substantially level or media-level attributes that are unrelated or substantially
different. different.
The initial set of source attribute names, with definitions in The initial set of source attribute names, with definitions in
Section 6 of this document, is in Figure 8. Section 6 of this document, is in Figure 8.
Type SDP Name Reference Type SDP Name Reference
---- ------------------ --------- ---- ------------------ ---------
att-field (source level) att-field (source level)
cname [RFCXXXX] cname [RFC5576]
previous-ssrc [RFCXXXX] previous-ssrc [RFC5576]
fmtp [RFCXXXX] fmtp [RFC5576]
Figure 8: Initial Contents of IANA Source Attribute Registry Figure 8: Initial contents of the IANA Source Attribute Registry
(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 12.3. Registry for Source Grouping Semantics
This specification creates a new IANA registry named "Semantics for This specification creates a new IANA registry named 'Semantics for
the "ssrc-group" SDP Attribute" within the SDP parameters registry. the "ssrc-group" SDP Attribute' within the SDP parameters registry.
Source group semantics MUST be defined in standards-track RFCs, under Source group semantics MUST be defined in Standards Track RFCs, under
the same rules as [RFC3388]: the same rules as [RFC3388].
The IANA Considerations section of the RFC MUST include the following The IANA Considerations section of the RFC MUST include the following
information, which appears in the IANA registry along with the RFC information, which appears in the IANA registry along with the RFC
number of the publication. number of the publication:
o A brief description of the semantics. o A brief description of the semantics.
o Token to be used within the group attribute. This token may be of 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. any length, but SHOULD be no more than four characters long.
o Reference to an standards track RFC.
Source grouping semantics values which are substantially similar to o Reference to a Standards Track RFC.
existing media grouping semantics values SHOULD re-use the same
semantics name as that media gropuing semantics. Source grouping Source grouping semantic values that are substantially similar to
semantics SHOULD NOT re-use source grouping semantics names that are 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. unrelated or substantially different.
The initial set of source grouping semantics values, for the The initial set of source grouping semantic values, for the semantics
semantics specified in Section 4.2 of this document, is in Figure 9. specified in Section 4.2 of this document, is in Figure 9.
Semantics Token Reference Semantics Token Reference
------------------- ----- --------- ------------------- ----- ---------
Flow Identification FID [RFCXXXX] Flow Identification FID [RFC5576]
Forward Error Correction FEC [RFCXXXX] Forward Error Correction FEC [RFC5576]
Figure 9: Initial Contents of IANA Source Group Semantics Registry Figure 9: Initial Contents of IANA Source Group Semantics Registry
(Note to the RFC-Editor: please replace "XXXX" with the number of
this document prior to publication as an RFC.)
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
skipping to change at page 16, line 29 skipping to change at page 16, line 49
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
13.2. Informative References 13.2. Informative References
[I-D.ietf-avt-rtcpssm] [EXT-SSM] Schooler, E., Ott, J., and J. Chesterfield, "RTCP
Ott, J., "RTCP Extensions for Single-Source Multicast Extensions for Single-Source Multicast Sessions with
Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17 Unicast Feedback", Work in Progress, March 2009.
(work in progress), January 2008.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.mehta-rmt-flute-sdp] [FLUTE] Mehta, H., "SDP Descriptors for FLUTE", Work in Progress,
Mehta, H., "SDP Descriptors for FLUTE",
draft-mehta-rmt-flute-sdp-05 (work in progress),
January 2006. 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 [RFC3524] Camarillo, G. and A. Monrad, "Mapping of Media Streams to
Resource Reservation Flows", RFC 3524, April 2003. Resource Reservation Flows", RFC 3524, April 2003.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network
Address Types (ANAT) Semantics for the Session Description Address Types (ANAT) Semantics for the Session Description
Protocol (SDP) Grouping Framework", RFC 4091, June 2005. Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
skipping to change at page 17, line 21 skipping to change at page 18, line 5
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008. January 2008.
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 -01
o Updated reference to RFC 2434 to [RFC5226].
A.2. Changes From Working Group Draft -00
o Removed discussion of ssrc-multiplexing for layered codecs.
o Clarified that each "ssrc" attribute specifies only a single
source-level attribute.
o Clarified that "ssrc-group" semantics are defined separately from
"group" semantics.
o Clarified reference for the Td parameter.
o Updated references.
o Corrected typographical errors.
A.3. Changes From Individual Submission Draft -01
o Added definitions of the new IANA registries and registrations
needed.
o Clarified that none of the attributes defined in the document are
dependent on the charset attribute.
o Clarified that ssrc attributes must be consistent with other SDP
mechanisms (such as MIKEY) that also specify SSRCs.
o Removed open issues section.
A.4. Changes From Individual Submission Draft -00
o Clarified that this document is expressly defining declarative
source descriptions, not source offer/answer or other information.
o 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.
o Added text to the Backward Compatibility and Security
Considerations sections.
Authors' Addresses Authors' Addresses
Jonathan Lennox Jonathan Lennox
Vidyo, Inc. Vidyo, Inc.
433 Hackensack Avenue 433 Hackensack Avenue
Sixth Floor Sixth Floor
Hackensack, NJ 07601 Hackensack, NJ 07601
US US
Email: jonathan@vidyo.com EMail: jonathan@vidyo.com
Joerg Ott Joerg Ott
Helsinki University of Technology (TKK) Helsinki University of Technology (TKK)
Networking Laboratory Department of Communications and Networking
PO Box 3000 PO Box 3000
FIN-02015 TKK FIN-02015 TKK
Finland Finland
Email: jo@acm.org EMail: jo@acm.org
Thomas Schierl Thomas Schierl
Fraunhofer HHI Fraunhofer HHI
Einsteinufer 37 Einsteinufer 37
D-10587 Berlin D-10587 Berlin
Germany Germany
Phone: +49-30-31002-227 Phone: +49-30-31002-227
Email: schierl@hhi.fhg.de EMail: ts@thomas-schierl.de
Full Copyright Statement
Copyright (C) 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.
 End of changes. 96 change blocks. 
293 lines changed or deleted 280 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/