MMUSIC J. Lennox
Internet-Draft Layered Media
Intended status: Standards Track J. Ott
Expires: January 7, 2008 Helsinki University of Technology
T. Schierl
Fraunhofer HHI
July 6, 2007
Source-Specific Media Attributes in the Session Description Protocol
(SDP)
draft-lennox-mmusic-sdp-source-attributes-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The Session Description Protocol provides mechanisms to describe
attributes of multimedia sessions and of individual media streams
(e.g., Real-time Transport Protocol (RTP) sessions) within a
multimedia session, but does not provide any mechanism to describe
Lennox, et al. Expires January 7, 2008 [Page 1]
Internet-Draft Source-Specific SDP Attributes July 2007
individual media sources within a media stream. This document
defines a mechanism to describe RTP media sources, identified by
their Synchronization Source Identifiers (SSRCs), in SDP, associate
attributes with these sources, and express relationships among
sources. It also defines several source-level attributes which can
be used to describe properties of media sources.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Media Attributes . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . 9
6.1. The "cname" Source Attribute . . . . . . . . . . . . . . . 9
6.2. The "previous-ssrc" Source Attribute . . . . . . . . . . . 9
6.3. The "fmtp" Source Attribute . . . . . . . . . . . . . . . 10
6.4. Other Attributes . . . . . . . . . . . . . . . . . . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Usage With the Offer/Answer Model . . . . . . . . . . . . . . 11
9. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12
10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . . 15
Appendix B. Changes From Earlier Versions . . . . . . . . . . . . 15
B.1. Changes From Draft -00 . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Lennox, et al. Expires January 7, 2008 [Page 2]
Internet-Draft Source-Specific SDP Attributes July 2007
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.
Several recently-proposed protocols, notably RTP Single-Source
Multicast [I-D.ietf-avt-rtcpssm] have found it useful to describe
specific media sources in SDP messages. Single-source multicast, in
particular, needs to ensure that receivers' RTP Syncronization Source
Identifiers (SSRCs) 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 Sources
Identifiers (SSRCs), in SDP, associate attributes with these sources,
and express relationships among individual sources. It also defines
a number of new SDP attributes that apply to individual sources
("source-level" attributes); describes how a number of existing media
stream ("media-level") attributes can also be applied at the source
level; and establishes an IANA repository for source-level
attributes.
During the still-ongoing discussion in the AVT and MMUSIC working
groups on the transport [I-D.ietf-avt-rtp-svc] and signaling
[I-D.schierl-mmusic-layered-codec] of the Scalable Video Coding (SVC)
Extensions of H.264, SSRC multiplexing of layered video was
considered as an appropriate multiplexing technique, if the use case
strongly requires this. It was considered that a compelling use case
exists for identifying RTP packet streams carrying different layers
of a single SVC media stream. One use case was pointed out, which is
the adaptation of an SRTP encrypted SVC stream by a middle-box not
being in the security context. Since the authentication and
integrity mechanism of SRTP still requires the middle-boy being in
the security context, the authors of [I-D.ietf-avt-rtp-svc] and
[I-D.schierl-mmusic-layered-codec] currently do not consider SSRC
multiplexing. Since the process for both memos is still going on,
Lennox, et al. Expires January 7, 2008 [Page 3]
Internet-Draft Source-Specific SDP Attributes July 2007
however, a requirement for SSRC multiplexing for SVC may come up
again. SSRC multiplexing would anyway make an easy identification of
layers of a scalable media stream in a middle-box possible, without
the need of parsing into RTP payload headers. A potential use case
is shown in Section 7, the examples section.
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 [I-D.ietf-avt-rtcpssm] can make the situation more complex.
RTP topologies are discussed in more detail in
[I-D.ietf-avt-topologies].
Within an RTP session, the source of a single stream of RTP packets
is known as a synchronization source (SSRC). Every synchronization
source is identified by a 32-bit numeric identifier. In addition,
receivers (who may never send RTP packets) also have source
identifiers, which are used to identify their RTP Control Protocol
(RTCP) receiver reports and other feedback messages.
Messages of the Session Description Protocol (SDP) [RFC4566], known
as Session Descriptions, describe Multimedia Sessions. A multimedia
session is a set of multimedia senders and receivers, and the data
streams flowing from senders to receivers. A multimedia session
contains a number of Media Streams, which are the individual RTP
sessions or other media paths over which one type of multimedia data
is carried. Information that applies to an entire multimedia session
is called Session-Level information, while information pertaining to
one media stream is called Media-Level information. The collection
of all the information describing a media stream is known as a Media
Description. (Media descriptions are also sometimes known informally
as SDP "m"-lines, after the SDP syntax that begins a media
description.) Several standard information elements are defined at
both the session level and the media level. Extended information can
be included at both levels through the use of attributes.
Lennox, et al. Expires January 7, 2008 [Page 4]
Internet-Draft Source-Specific SDP Attributes July 2007
(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) [I-D.ietf-mmusic-ice],
to denote the object described by an SDP media description. This
term is unfortunately rather confusing, as the RTP specification
[RFC3550] uses the term "media stream" to refer to an individual
media source or RTP packet stream, identified by an SSRC, whereas an
SDP media stream describes an entire RTP session, which can contain
any number of RTP sources. In this document, the term "media stream"
means an SDP media stream, i.e. the thing described by an SDP media
description, whereas "media source" is used for a single source of
media packets, i.e. an RTP media stream.)
The core SDP specification does not have any way of describing
individual media sources, in particular RTP synchronization sources,
within a media stream. To address this problem, in this document we
introduce a third level of information, called Source-Level
information. Syntactically, source-level information is described by
a new SDP media-level attribute "ssrc", which identifies specific
synchronization sources within an RTP session, and acts as a meta-
attribute mapping source-level attribute information to these
sources.
This document also defines an SDP media-level attribute "ssrc-group",
which can represent relationships among media sources within an RTP
session, in much the same way as the "group" attribute [RFC3388]
represents relationships among media streams within a multimedia
session.
4. Media Attributes
This section defines two media-level attributes, "ssrc" and "ssrc-
group".
4.1. The "ssrc" Media Attribute
a=ssrc:<ssrc-id> <attribute>
a=ssrc:<ssrc-id> <attribute>:<value>
The SDP media attribute "ssrc" indicates a property (known as a
"source-level attribute") of a media source (RTP stream) within an
RTP session. <ssrc-id> is the synchronizaton source ID (SSRC) of the
source being described, interpreted as a 32-bit unsigned integer in
network byte order and represented in decimal. <attribute> or
<attribute>:<value> represent the source-level attribute specific to
Lennox, et al. Expires January 7, 2008 [Page 5]
Internet-Draft Source-Specific SDP Attributes July 2007
the given media source. The source-level attribute follows the
syntax of the SDP "a=" line. It thus consists either of a single
attribute name (a flag), or an attribute name and value, e.g.
"cname:user@example.com". No attributes of the former type are
defined by this document.
Within a media stream, ssrc attributes with the same value of
<ssrc-id> describe different attributes of the same media sources.
Across media streams, <ssrc-id> values are not correlated (unless
correlation is indicated by media-stream grouping or some other
mechanism) and MAY be repeated.
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.
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.
Figure 10 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC4234] grammar for the ssrc attribute.
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]. Its potential parameters are defined by
IANA in "Semantics for the 'group' SDP Attribute" under "SDP
Parameters". The semantics defined for the ssrc-group attribute are
FID (Flow Identification) [RFC3388] and FEC (Forward Error
Correction) [RFC4756]. In each case, the relationship among the
Lennox, et al. Expires January 7, 2008 [Page 6]
Internet-Draft Source-Specific SDP Attributes July 2007
grouped sources is the same as the relationship among corresponding
sources in media streams grouped using the SDP "group" attribute.
(None of the other "group" semantics registered with IANA as of this
writing are 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)
[I-D.mehta-rmt-flute-sdp] is used to group FLUTE sessions, and so is
not applicable to RTP.)
The ssrc-group attribute indicates the sources in a group by listing
the <ssrc-id>s of the sources in the group. It MUST list at least
one <ssrc-id> for a group, and MAY list any number of additional
ones. Every <ssrc-id> listed in an ssrc-group attribute MUST be
defined by a corresponding "ssrc:" line in the same media
description.
Figure 11 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC4234] 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 which
are only known through SDP, for which neither RTP nor RTCP packets
have been received, MUST NOT be counted for RTP group size
Lennox, et al. Expires January 7, 2008 [Page 7]
Internet-Draft Source-Specific SDP Attributes July 2007
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, with Td being the deterministic calculated reporting
interval for receivers, to see whether the conflict still exists.
(This gives precedence to explicitly-signaled sources, and places the
burden of collision resolution on non-signaled sources.) SSRC
collisions between multiple explicitly-signaled sources, however,
MUST be acted upon immediately.
If, following RTP's collision-resolution procedures [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
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.
Lennox, et al. Expires January 7, 2008 [Page 8]
Internet-Draft Source-Specific SDP Attributes July 2007
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 MUST
NOT occur more than once for the same ssrc-id within a given media
stream.
Figure 12 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC4234] 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.
Lennox, et al. Expires January 7, 2008 [Page 9]
Internet-Draft Source-Specific SDP Attributes July 2007
Figure 13 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC4234] 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.
6.4. Other Attributes
This document only defines source attributes which are necessary or
useful for an endpoint to decode and render the sources in a media
stream. It does include any attributes which would contribute to an
endpoint's decision to accept or reject a stream, e.g. in an offer/
answer exchange. Such attributes are for future consideration.
7. Examples
This section gives several examples of SDP descriptions of media
sessions containing source attributes. For brevity, only the media
sections of the descriptions are given.
m=audio 49168 RTP/AVP 0
a=ssrc:314159 cname:user@example.com
Figure 6: Example: declaration of a single synchronization source
The example in Figure 6 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 7: Example: a media stream containing several independent
sources from a single session member.
Lennox, et al. Expires January 7, 2008 [Page 10]
Internet-Draft Source-Specific SDP Attributes July 2007
The example in Figure 7 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 49172 RTP/AVP 97
a=rtpmap:97 SVC/90000
a=ssrc-group:DDP 271828 14142135
a=ssrc:271828 cname:layered-codec@example.com
a=ssrc:14142135 cname:layered-codec@example.com
a=ssrc:14142135 depend:lay 271828
Figure 8: Example: relationship among several sources: layered coding
The example in Figure 8 shows a relationship among several sources,
grouped by the "DDP" grouping semantics defined in Signaling of
Layered and Multi-Description Media
[I-D.schierl-mmusic-layered-codec]. (Note that this is only an
example; multiplexing of layered codecs among several sources in an
RTP session is currently not specified or encouraged.)
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 9: Example: relationship among several sources: retransmission
sources
The example in Figure 9 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 with which each party
is willing to send (whether it is sending RTP data or RTCP report
blocks). No mechanism is provided by which an answer can accept or
Lennox, et al. Expires January 7, 2008 [Page 11]
Internet-Draft Source-Specific SDP Attributes July 2007
reject individual sources within a media stream; if the set of
sources in a media stream is unacceptable, the answerer's only option
is to reject the media stream or the entire multimedia session.
The SSRC IDs for sources described by an SDP answer MUST be distinct
from the SSRC IDs for sources of that media stream in the offer.
Similarly, new SSRC IDs in an updated offer MUST be distinct from the
ssrc IDs for that media stream established in the most recent offer/
answer exchange for the session, and SHOULD be distinct from any SSRC
ID ever used by either party within the multimedia session (whether
or not it is still being used).
9. Backward Compatibility
According to the defintion of SDP, interpreters of SDP session
descriptions ignore unknown attributes. Thus, endpoints MUST be
prepared that recipients of their RTP media session may not
understand their explicit source descriptions, unless some external
mechanism indicates that they were understood. In some cases (such
as RTP Retransmission [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.
10. Formal Grammar
This section gives a formal Augmented Backus-Naur Form (ABNF)
[RFC4234] grammar for each of the new media and source attributes
defined in this document. Grammars for existing session or media
attributes which have been extended to be source attributes are not
included.
ssrc-attr = "ssrc:" ssrc-id SP attribute
; The base definition of "attribute" is in RFC 4566.
; (It is the content of "a=" lines.)
ssrc-id = integer ; 0 - 2**32 - 1
attribute /= ssrc-attr
Lennox, et al. Expires January 7, 2008 [Page 12]
Internet-Draft Source-Specific SDP Attributes July 2007
Figure 10: Syntax of the ssrc media attribute
ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id)
; The definition of "semantics" is in RFC 3388.
; (It is the type of grouping being done.)
attribute /= ssrc-group-attr
Figure 11: 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 12: Syntax of the cname source attribute
previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id)
attribute /= previous-ssrc-attr
Figure 13: 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.
12. IANA Considerations
Add ssrc and ssrc-group in Section 4 as media-level attributes.
Define source-level IANA registry and populate it with source
attributes from Section 6.
13. References
Lennox, et al. Expires January 7, 2008 [Page 13]
Internet-Draft Source-Specific SDP Attributes July 2007
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.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[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.
13.2. Informative References
[I-D.ietf-avt-rtcpssm]
Chesterfield, J., "RTCP Extensions for Single-Source
Multicast Sessions with Unicast Feedback",
draft-ietf-avt-rtcpssm-13 (work in progress), March 2007.
[I-D.ietf-avt-rtp-svc]
Wenger, S., "RTP Payload Format for SVC Video",
draft-ietf-avt-rtp-svc-01 (work in progress), March 2007.
[I-D.ietf-avt-topologies]
Westerlund, M. and S. Wenger, "RTP Topologies",
draft-ietf-avt-topologies-04 (work in progress),
February 2007.
[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-16 (work in progress), June 2007.
Lennox, et al. Expires January 7, 2008 [Page 14]
Internet-Draft Source-Specific SDP Attributes July 2007
[I-D.mehta-rmt-flute-sdp]
Mehta, H., "SDP Descriptors for FLUTE",
draft-mehta-rmt-flute-sdp-05 (work in progress),
January 2006.
[I-D.schierl-mmusic-layered-codec]
Wenger, S. and T. Schierl, "Signaling media decoding
dependency in Session Description Protocol (SDP)",
draft-schierl-mmusic-layered-codec-04 (work in progress),
June 2007.
[RFC3524] Camarillo, G. and A. Monrad, "Mapping of Media Streams to
Resource Reservation Flows", RFC 3524, April 2003.
[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.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
Appendix A. Open issues
o Does a separate IANA registry need to be defined for "ssrc-group"
semantics, distinct from "group" semantics?
o What additional SDP media-level attributes should be defined, in
this or other documents?
o Does there need to be some way of saying in SDP "I understand that
RTP media streams can contain multiple sources, and I'm prepared
to accept them"?
Appendix B. Changes From Earlier Versions
Note to the RFC-Editor: please remove this section prior to
publication as an RFC.
B.1. Changes From 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
Lennox, et al. Expires January 7, 2008 [Page 15]
Internet-Draft Source-Specific SDP Attributes July 2007
by RTCP Source Description (SDES) packets or feedback (AVPF)
messages.
o Added text to the Backward Compatibility and Security
Considerations sections.
Authors' Addresses
Jonathan Lennox
Layered Media, Inc.
433 Hackensack Avenue
Sixth Floor
Hackensack, NJ 07601
US
Email: jonathan@layeredmedia.com
Joerg Ott
Helsinki University of Technology (TKK)
Networking Laboratory
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: schierl@hhi.fhg.de
Lennox, et al. Expires January 7, 2008 [Page 16]
Internet-Draft Source-Specific SDP Attributes July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Lennox, et al. Expires January 7, 2008 [Page 17]