draft-ietf-mmusic-rfc3388bis-03.txt   draft-ietf-mmusic-rfc3388bis-04.txt 
MMUSIC Working Group G. Camarillo MMUSIC Working Group G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Obsoletes: 3388 (if approved) July 13, 2009 Obsoletes: 3388 (if approved) H. Schulzrinne
Intended status: Standards Track Intended status: Standards Track Columbia University
Expires: January 14, 2010 Expires: May 15, 2010 November 11, 2009
The SDP (Session Description Protocol) Grouping Framework The SDP (Session Description Protocol) Grouping Framework
draft-ietf-mmusic-rfc3388bis-03.txt draft-ietf-mmusic-rfc3388bis-04.txt
Abstract
In this specification, we define a framework to group "m" lines in
SDP (Session Description Protocol) for different purposes. This
framework uses the "group" and "mid" SDP attributes, both of which
are defined in this specification. Additionally, we specify how to
use the framework for two different purposes: for lip synchronization
and for receiving a media flow consisting of several media streams on
different transport addresses. This document obsoletes RFC 3388.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 43
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010. This Internet-Draft will expire on May 15, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
In this specification, we define a framework to group "m" lines in described in the BSD License.
SDP (Session Description Protocol) for different purposes. This
framework uses the "group" and "mid" SDP attributes, both of which
are defined in this specification. Additionally, we specify how to
use the framework for two different purposes: for lip synchronization
and for receiving a media flow consisting of several media streams on
different transport addresses.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. Media Stream Identification Attribute . . . . . . . . . . . . 4 4. Media Stream Identification Attribute . . . . . . . . . . . . 4
5. Group Attribute . . . . . . . . . . . . . . . . . . . . . . . 4 5. Group Attribute . . . . . . . . . . . . . . . . . . . . . . . 4
6. Use of "group" and "mid" . . . . . . . . . . . . . . . . . . . 4 6. Use of "group" and "mid" . . . . . . . . . . . . . . . . . . . 4
7. Lip Synchronization (LS) . . . . . . . . . . . . . . . . . . . 5 7. Lip Synchronization (LS) . . . . . . . . . . . . . . . . . . . 5
7.1. Example of LS . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Example of LS . . . . . . . . . . . . . . . . . . . . . . 5
8. Flow Identification (FID) . . . . . . . . . . . . . . . . . . 6 8. Flow Identification (FID) . . . . . . . . . . . . . . . . . . 6
8.1. SIP and Cellular Access . . . . . . . . . . . . . . . . . 6 8.1. SIP and Cellular Access . . . . . . . . . . . . . . . . . 6
8.2. DTMF Tones . . . . . . . . . . . . . . . . . . . . . . . . 7 8.2. DTMF Tones . . . . . . . . . . . . . . . . . . . . . . . . 7
8.3. Media Flow Definition . . . . . . . . . . . . . . . . . . 7 8.3. Media Flow Definition . . . . . . . . . . . . . . . . . . 7
8.4. FID Semantics . . . . . . . . . . . . . . . . . . . . . . 7 8.4. FID Semantics . . . . . . . . . . . . . . . . . . . . . . 7
8.4.1. Examples of FID . . . . . . . . . . . . . . . . . . . 8 8.4.1. Examples of FID . . . . . . . . . . . . . . . . . . . 8
8.5. Scenarios that FID does not Cover . . . . . . . . . . . . 11 8.5. Scenarios that FID does not Cover . . . . . . . . . . . . 11
8.5.1. Parallel Encoding Using Different Codecs . . . . . . . 11 8.5.1. Parallel Encoding Using Different Codecs . . . . . . . 11
8.5.2. Layered Encoding . . . . . . . . . . . . . . . . . . . 11 8.5.2. Layered Encoding . . . . . . . . . . . . . . . . . . . 12
8.5.3. Same IP Address and Port Number . . . . . . . . . . . 12 8.5.3. Same IP Address and Port Number . . . . . . . . . . . 12
9. Usage of the "group" Attribute in SIP . . . . . . . . . . . . 13 9. Usage of the "group" Attribute in SIP . . . . . . . . . . . . 13
9.1. Mid Value in Answers . . . . . . . . . . . . . . . . . . . 13 9.1. Mid Value in Answers . . . . . . . . . . . . . . . . . . . 13
9.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 14 9.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Group Value in Answers . . . . . . . . . . . . . . . . . . 15 9.2. Group Value in Answers . . . . . . . . . . . . . . . . . . 15
9.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 15 9.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 15
9.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 16 9.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 16
9.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 16 9.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 16
9.4. Backward Compatibility . . . . . . . . . . . . . . . . . . 17 9.4. Backward Compatibility . . . . . . . . . . . . . . . . . . 17
9.4.1. Offerer does not Support "group" . . . . . . . . . . . 17 9.4.1. Offerer does not Support "group" . . . . . . . . . . . 17
9.4.2. Answerer does not Support "group" . . . . . . . . . . 17 9.4.2. Answerer does not Support "group" . . . . . . . . . . 17
10. Changes from RFC 3388 . . . . . . . . . . . . . . . . . . . . 18 10. Changes from RFC 3388 . . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.2. Informational References . . . . . . . . . . . . . . . . . 19 14.1. Normative References . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 14.2. Informational References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
RFC 3388 [RFC3388] specified a media-line grouping framework for SDP
(Session Description Protocol) [RFC4566]. This specification
obsoletes RFC 3388 [RFC3388].
An SDP [RFC4566] session description typically contains one or more An SDP [RFC4566] session description typically contains one or more
media lines, which are commonly known as "m" lines. When a session media lines, which are commonly known as "m" lines. When a session
description contains more than one "m" line, SDP does not provide any description contains more than one "m" line, SDP does not provide any
means to express a particular relationship between two or more of means to express a particular relationship between two or more of
them. When an application receives an SDP session description with them. When an application receives an SDP session description with
more than one "m" line, it is up to the application what to do with more than one "m" line, it is up to the application what to do with
them. SDP does not carry any information about grouping media them. SDP does not carry any information about grouping media
streams. streams.
While in some environments this information can be carried out of While in some environments this information can be carried out of
skipping to change at page 4, line 8 skipping to change at page 5, line 17
t=0 0 t=0 0
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=group:LS 1 2 a=group:LS 1 2
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
a=mid:1 a=mid:1
m=video 30002 RTP/AVP 31 m=video 30002 RTP/AVP 31
a=mid:2 a=mid:2
4. Media Stream Identification Attribute 4. Media Stream Identification Attribute
A new "media stream identification" media attribute is defined. It This document defines the "media stream identification" media
is used for identifying media streams within a session description. attribute, which is used for identifying media streams within a
Its formatting in SDP [RFC4566] is described by the following BNF session description. Its formatting in SDP [RFC4566] is described by
(Backus-Naur Form): the following Augmented BNF (Backus-Naur Form) [RFC5234]:
mid-attribute = "a=mid:" identification-tag mid-attribute = "a=mid:" identification-tag
identification-tag = token identification-tag = token
; token is defined in RFC 4566
The identification tag MUST be unique within an SDP session The identification tag MUST be unique within an SDP session
description. description.
5. Group Attribute 5. Group Attribute
A new "group" session-level attribute is defined. It is used for This document defines the "group" session-level attribute, which is
grouping together different media streams. Its formatting in SDP is used for grouping together different media streams. Its formatting
described by the following BNF: in SDP is described by the following Augmented BNF [RFC5234]:
group-attribute = "a=group:" semantics group-attribute = "a=group:" semantics
*(space identification-tag) *(SP identification-tag)
semantics = "LS" / "FID" / semantics-extension semantics = "LS" / "FID" / semantics-extension
semantics-extension = token semantics-extension = token
; token is defined in RFC 4566
This document defines two standard semantics: LS (Lip This document defines two standard semantics: LS (Lip
Synchronization) and FID (Flow Identification). Further semantics Synchronization) and FID (Flow Identification). Semantics extensions
MUST be defined in a standards-track document. follow the Standards Action policy [RFC5226].
6. Use of "group" and "mid" 6. Use of "group" and "mid"
All the "m" lines of a session description that uses "group" MUST be All the "m" lines of a session description that uses "group" MUST be
identified with a "mid" attribute whether they appear in the group identified with a "mid" attribute whether they appear in the group
line(s) or not. If a session description contains at least one "m" line(s) or not. If a session description contains at least one "m"
line that has no "mid" identification the application MUST NOT line that has no "mid" identification the application MUST NOT
perform any grouping of media lines. perform any grouping of media lines.
"a=group" lines are used to group together several "m" lines that are "a=group" lines are used to group together several "m" lines that are
skipping to change at page 5, line 23 skipping to change at page 6, line 33
An application that receives a session description that contains "m" An application that receives a session description that contains "m"
lines that are grouped together using LS semantics MUST synchronize lines that are grouped together using LS semantics MUST synchronize
the playout of the corresponding media streams. Note that LS the playout of the corresponding media streams. Note that LS
semantics not only apply to a video stream that has to be semantics not only apply to a video stream that has to be
synchronized with an audio stream. The playout of two streams of the synchronized with an audio stream. The playout of two streams of the
same type can be synchronized as well. same type can be synchronized as well.
For RTP streams, synchronization is typically performed using RTCP, For RTP streams, synchronization is typically performed using RTCP,
which provides enough information to map time stamps from the which provides enough information to map time stamps from the
different streams into a wall clock. However, the concept of media different streams into a local absolute time value. However, the
stream synchronization MAY also apply to media streams that do not concept of media stream synchronization MAY also apply to media
make use of RTP. If this is the case, the application MUST recover streams that do not make use of RTP. If this is the case, the
the original timing relationship between the streams using whatever application MUST recover the original timing relationship between the
available mechanism. streams using whatever available mechanism.
7.1. Example of LS 7.1. Example of LS
The following example shows a session description of a conference The following example shows a session description of a conference
that is being multicast. The first media stream (mid:1) contains the that is being multicast. The first media stream (mid:1) contains the
voice of the speaker who speaks in English. The second media stream voice of the speaker who speaks in English. The second media stream
(mid:2) contains the video component and the third (mid:3) media (mid:2) contains the video component and the third (mid:3) media
stream carries the translation to Spanish of what he is saying. The stream carries the translation to Spanish of what he is saying. The
first and the second media streams have to be synchronized. first and the second media streams have to be synchronized.
v=0 v=0
o=Laura 289083124 289083124 IN IP4 one.example.com o=Laura 289083124 289083124 IN IP4 one.example.com
t=0 0 t=0 0
c=IN IP4 224.2.17.12/127 c=IN IP4 233.252.0.1/127
a=group:LS 1 2 a=group:LS 1 2
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
a=mid:1 a=mid:1
m=video 30002 RTP/AVP 31 m=video 30002 RTP/AVP 31
a=mid:2 a=mid:2
m=audio 30004 RTP/AVP 0 m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation i=This media stream contains the Spanish translation
a=mid:3 a=mid:3
Note that although the third media stream is not present in the group Note that although the third media stream is not present in the group
skipping to change at page 10, line 45 skipping to change at page 11, line 50
(it actually performs an RTP dump, so it can effectively receive any (it actually performs an RTP dump, so it can effectively receive any
codec). codec).
Remember that if several "m" lines grouped together using FID Remember that if several "m" lines grouped together using FID
semantics contain the same codec the media agent MUST send media over semantics contain the same codec the media agent MUST send media over
several RTP sessions at the same time. several RTP sessions at the same time.
The last example of this section deals with DTMF tones. DTMF tones The last example of this section deals with DTMF tones. DTMF tones
can be transmitted using a regular voice codec or can be transmitted can be transmitted using a regular voice codec or can be transmitted
as telephony events. The RTP payload for DTMF tones treated as as telephony events. The RTP payload for DTMF tones treated as
telephone events is described in [RFC2833]. Below, there is an telephone events is described in [RFC4733]. Below, there is an
example of an SDP session description using FID semantics and this example of an SDP session description using FID semantics and this
payload type. payload type.
v=0 v=0
o=Laura 289083124 289083124 IN IP4 six.example.com o=Laura 289083124 289083124 IN IP4 six.example.com
t=0 0 t=0 0
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=group:FID 1 2 a=group:FID 1 2
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
a=mid:1 a=mid:1
m=audio 20000 RTP/AVP 97 m=audio 20000 RTP/AVP 97
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
a=rtpmap:97 telephone-events a=rtpmap:97 telephone-events
a=mid:2 a=mid:2
The remote party would send PCM encoded voice (payload 0) to The remote party would send PCM encoded voice (payload 0) to
192.0.2.1 and DTMF tones encoded as telephony events to 192.0.2.2. 192.0.2.1 and DTMF tones encoded as telephony events to 192.0.2.2.
Note that only voice or DTMF is sent at a particular point of time. Note that only voice or DTMF is sent at a particular point in time.
When DTMF tones are sent, the first media stream does not carry any When DTMF tones are sent, the first media stream does not carry any
data and, when voice is sent, there is no data in the second media data and, when voice is sent, there is no data in the second media
stream. FID semantics provide different destinations for alternative stream. FID semantics provide different destinations for alternative
codecs. codecs.
8.5. Scenarios that FID does not Cover 8.5. Scenarios that FID does not Cover
It is worthwhile mentioning some scenarios where the "group" It is worthwhile mentioning some scenarios where the "group"
attribute using existing semantics (particularly FID) might seem to attribute using existing semantics (particularly FID) might seem to
be applicable but is not. be applicable but is not.
8.5.1. Parallel Encoding Using Different Codecs 8.5.1. Parallel Encoding Using Different Codecs
FID semantics are useful when the application only uses one codec at FID semantics are useful when the application only uses one codec at
a time. An application that encodes the same media using different a time. An application that encodes the same media using different
codecs simultaneously MUST NOT use FID to group those media lines. codecs simultaneously MUST NOT use FID to group those media lines.
Some systems that handle DTMF tones are a typical example of parallel Some systems that handle DTMF tones are a typical example of parallel
encoding using different codecs. encoding using different codecs.
Some systems implement the RTP payload defined in RFC 2833, but when Some systems implement the RTP payload defined in RFC 4733 [RFC4733],
they send DTMF tones they do not mute the voice channel. Therefore, but when they send DTMF tones they do not mute the voice channel.
in effect they are sending two copies of the same DTMF tone: encoded Therefore, in effect they are sending two copies of the same DTMF
as voice and encoded as a telephony event. When the receiver gets tone: encoded as voice and encoded as a telephony event. When the
both copies, it typically uses the telephony event rather than the receiver gets both copies, it typically uses the telephony event
tone encoded as voice. FID semantics MUST NOT be used in this rather than the tone encoded as voice. FID semantics MUST NOT be
context to group both media streams since such a system is not using used in this context to group both media streams since such a system
alternative codecs but rather different parallel encodings for the is not using alternative codecs but rather different parallel
same information. encodings for the same information.
8.5.2. Layered Encoding 8.5.2. Layered Encoding
Layered encoding schemes encode media in different layers. Quality Layered encoding schemes encode media in different layers. Quality
at the receiver varies depending on the number of layers received. at the receiver varies depending on the number of layers received.
SDP provides a means to group together contiguous multicast addresses SDP provides a means to group together contiguous multicast addresses
that transport different layers. The "c" line below: that transport different layers. The "c" line below:
c=IN IP4 224.2.1.1/127/3 c=IN IP4 233.252.0.1/127/3
is equivalent to the following three "c" lines: is equivalent to the following three "c" lines:
c=IN IP4 224.2.1.1/127 c=IN IP4 233.252.0.1/127
c=IN IP4 224.2.1.2/127 c=IN IP4 233.252.0.2/127
c=IN IP4 224.2.1.3/127 c=IN IP4 233.252.0.3/127
FID MUST NOT be used to group "m" lines that do not represent the FID MUST NOT be used to group "m" lines that do not represent the
same information. Therefore, FID MUST NOT be used to group "m" lines same information. Therefore, FID MUST NOT be used to group "m" lines
that contain the different layers of layered encoding scheme. that contain the different layers of layered encoding scheme.
Besides, we do not define new group semantics to provide a more Besides, we do not define new group semantics to provide a more
flexible way of grouping different layers because the already flexible way of grouping different layers because the already
existing SDP mechanism covers the most useful scenarios. existing SDP mechanism covers the most useful scenarios.
8.5.3. Same IP Address and Port Number 8.5.3. Same IP Address and Port Number
skipping to change at page 14, line 34 skipping to change at page 15, line 40
t=0 0 t=0 0
c=IN IP4 192.0.2.3 c=IN IP4 192.0.2.3
a=group:FID 1 2 a=group:FID 1 2
m=audio 25000 RTP/AVP 0 8 m=audio 25000 RTP/AVP 0 8
a=mid:2 a=mid:2
m=audio 25002 RTP/AVP 0 8 m=audio 25002 RTP/AVP 0 8
a=mid:1 a=mid:1
Since alignment of "m" lines is performed based on matching of nth Since alignment of "m" lines is performed based on matching of nth
lines, the first stream had "mid:1" in the INVITE and "mid:2" in the lines, the first stream had "mid:1" in the INVITE and "mid:2" in the
200 OK. Therefore, the application MUST ignore every "mid" and 200 OK. Therefore, the application ignores every "mid" and "group"
"group" lines contained in the SDP. line contained in the SDP.
A well-behaved SIP user agent would have returned the SDP below in A well-behaved SIP user agent would have returned the SDP below in
the 200 OK: the 200 OK:
v=0 v=0
o=Bob 289083122 289083122 IN IP4 nine.example.com o=Bob 289083122 289083122 IN IP4 nine.example.com
t=0 0 t=0 0
c=IN IP4 192.0.2.3 c=IN IP4 192.0.2.3
a=group:FID 1 2 a=group:FID 1 2
m=audio 25002 RTP/AVP 0 8 m=audio 25002 RTP/AVP 0 8
skipping to change at page 16, line 36 skipping to change at page 17, line 36
m=audio 0 RTP/AVP 8 m=audio 0 RTP/AVP 8
a=mid:2 a=mid:2
m=audio 20002 RTP/AVP 3 m=audio 20002 RTP/AVP 3
a=mid:3 a=mid:3
9.3. Capability Negotiation 9.3. Capability Negotiation
A client that understands "group" and "mid" but does not want to make A client that understands "group" and "mid" but does not want to make
use of them in a particular session MAY want to indicate that it use of them in a particular session MAY want to indicate that it
supports them. If a client decides to do that, it SHOULD add an supports them. If a client decides to do that, it SHOULD add an
"a=group" line with no identification-tags for every semantics it "a=group" line with no identification-tags for every semantics value
understands. it understands.
If a server receives an offer that contains empty "a=group" lines, it If a server receives an offer that contains empty "a=group" lines, it
SHOULD add its capabilities also in the form of empty "a=group" lines SHOULD add its capabilities also in the form of empty "a=group" lines
to its answer. to its answer.
9.3.1. Example 9.3.1. Example
A system that supports both LS and FID semantics but does not want to A system that supports both LS and FID semantics but does not want to
group any media stream for this particular session generates the group any media stream for this particular session generates the
following SDP: following SDP:
skipping to change at page 18, line 15 skipping to change at page 19, line 15
An implementation might also decide to refuse the request (e.g., 488 An implementation might also decide to refuse the request (e.g., 488
Not acceptable here or 606 Not Acceptable) because it contains Not acceptable here or 606 Not Acceptable) because it contains
several "m" lines. In this case, the server does not support the several "m" lines. In this case, the server does not support the
type of session that the caller wanted to establish. In case the type of session that the caller wanted to establish. In case the
client is willing to establish a simpler session anyway, he SHOULD client is willing to establish a simpler session anyway, he SHOULD
re-try the request without "group" attribute and only one "m" line re-try the request without "group" attribute and only one "m" line
per flow. per flow.
10. Changes from RFC 3388 10. Changes from RFC 3388
Section 3 (Overview of Operation) has been added for clarity. The
AMR and GSM acronyms are now expanded on their first use. The
examples now use IP addresses in the range suitable for examples.
The grouping mechanism is now defined as an extendible framework. The grouping mechanism is now defined as an extendible framework.
Earlier, [RFC3388] used to discourage extensions to this mechanism in Earlier, RFC 3388 [RFC3388] used to discourage extensions to this
favor of using new session description protocols. mechanism in favor of using new session description protocols.
Given a semantics value, [RFC3388] used to restrict "m" line Given a semantics value, RFC 3388 [RFC3388] used to restrict "m" line
identifiers to only appear in a single group using that semantics. identifiers to only appear in a single group using that semantics.
That restriction has been lifted. From conversations with That restriction has been lifted in this specification. From
implementers, it seems that the lifting of this restriction is conversations with implementers, existing (i.e., legacy)
unlikely to cause backwards compatibility problems. implementations enforce this restriction on a per semantics basis.
That is, they only enforce this restriction for supported semantics.
Because of the nature of existing semantics, implementations will
only use a single "m" line identifier across groups using a given
semantics even after the restriction has been lifted by this
specification. Consequently, the lifting of this restriction will
not cause backwards compatibility problems because implementations
supporting new semantics will be updated not to enforce this
restriction at the same time as they are updated to support the new
semantics.
11. Security Considerations 11. Security Considerations
Using the "group" parameter with FID semantics, an entity that Using the "group" parameter with FID semantics, an entity that
managed to modify the session descriptions exchanged between the managed to modify the session descriptions exchanged between the
participants to establish a multimedia session could force the participants to establish a multimedia session could force the
participants to send a copy of the media to any particular participants to send a copy of the media to any particular
destination. destination.
Integrity mechanism provided by protocols used to exchange session Integrity mechanism provided by protocols used to exchange session
descriptions and media encryption can be used to prevent this attack. descriptions and media encryption can be used to prevent this attack.
In SIP, S/MIME [RFC3850] and TLS [RFC4346] can be used to protect In SIP, S/MIME [RFC3850] and TLS [RFC5246] can be used to protect
session description exchanges in an end-to-end and a hop-by-hop session description exchanges in an end-to-end and a hop-by-hop
fashion respectively. fashion respectively.
12. IANA Considerations 12. IANA Considerations
[RFC3388] already registered the "mid" and "group" SDP attributes This document defines two SDP attributes: "mid" and "group".
with the IANA and created a registry for semantics. This document
does not contain any additional actions for the IANA.
13. References The "mid" attribute is used to identify media streams within a
13.1. Normative References session description and its format is defined in Section 4.
The "group" attribute is used for grouping together different media
streams and its format is defined in Section 5.
This document defines a framework to group media lines in SDP using
different semantics. Semantics values to be used with this framework
are registered by the IANA following the Standards Action policy
[RFC5226].
The IANA Considerations section of the RFC MUST include the following
information, which appears in the IANA registry along with the RFC
number of the publication.
o A brief description of the semantics.
o Token to be used within the group attribute. This token may be of
any length, but SHOULD be no more than four characters long.
o Reference to an standards track RFC.
The following are the current entries in the registry:
Semantics Token Reference
--------------------------------- ----- -----------
Lip Synchronization LS [RFCxxxx]
Flow Identification FID [RFCxxxx]
Single Reservation flow SRF [RFC3524]
Alternative Network Address Types ANAT [RFC4091]
Forward Error Correction FEC [RFC4756]
Decoding Dependency DDP [RFC5583]
[Note to the RFC Editor: please replace RFCxxxx above with the number
of this RFC.]
13. Acknowledgments
Goran Eriksson and Jan Holler were coauthors of RFC 3388 [RFC3388].
14. References
14.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.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[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.
[RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Certificate Handling", Extensions (S/MIME) Version 3.1 Certificate Handling",
RFC 3850, July 2004. RFC 3850, July 2004.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
(TLS) Protocol Version 1.1", RFC 4346, April 2006. IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
13.2. Informational References [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
14.2. Informational References
[RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996. Applications", RFC 1889, January 1996.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones and Telephony Signals", RFC 2833, Digits, Telephony Tones, and Telephony Signals", RFC 4733,
May 2000. December 2006.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002. Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
Author's Address Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Henning Schulzrinne
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
Email: schulzrinne@cs.columbia.edu
 End of changes. 35 change blocks. 
80 lines changed or deleted 147 lines changed or added

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