draft-ietf-mmusic-fid-01.txt   draft-ietf-mmusic-fid-02.txt 
Internet Engineering Task Force Gonzalo Camarillo Internet Engineering Task Force Gonzalo Camarillo
Internet draft Jan Holler Internet draft Jan Holler
Goran AP Eriksson Goran AP Eriksson
Ericsson Ericsson
April 2001 June 2001
Expires October 2001 Expires December 2001
<draft-ietf-mmusic-fid-01.txt> <draft-ietf-mmusic-fid-02.txt>
The SDP fid attribute Grouping of m lines in SDP
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
skipping to change at line 33 skipping to change at line 33
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." 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.
Abstract Abstract
This document defines an SDP media attribute. The use of this This document defines two SDP attributes: "groupe" and "mid". They
attribute allows receiving media from a single flow (several media allow to group together several "m" lines for two different
streams), encoded in different formats during a particular session, purposes: for lip synchronization and for receiving media from a
in different ports and host interfaces. single flow (several media streams), encoded in different formats
during a particular session, in different ports and host interfaces.
Camarillo/Holler/Eriksson 1 Camarillo/Holler/Eriksson 1
The SDP fid attribute Grouping of m lines in SDP
TABLE OF CONTENTS TABLE OF CONTENTS
1 Motivation...................................................2 1 Media stream identification attribute........................2
1.1 SIP and cellular access......................................2 2 Groupe attribute.............................................2
1.2 DTMF tones...................................................3 3 Lip Synchronization (LS).....................................3
2 Media flow definition........................................3 4 Flow Identification (FID)....................................3
3 Flow identification attribute................................3 4.1 SIP and cellular access......................................3
4 Semantics of the fid attribute...............................4 4.2 DTMF tones...................................................4
4.1 Interactions with other media level attributes...............4 5 Media flow definition........................................4
5 Usage of the fid attribute in SIP............................5 6 FID semantics................................................4
5.1 Backward compatibility.......................................5 7 Interactions of "groupe" with other media level attributes...5
5.2 Caller does not support fid..................................5 8 Usage of the "groupe" attribute in SIP.......................6
5.3 Callee does not support fid..................................5 8.1 Backward compatibility.......................................6
6 Acknoledgements..............................................6 8.2 Caller does not support fid..................................6
7 References...................................................6 8.3 Callee does not support fid..................................6
8 Authors³ Addresses...........................................6 9 Acknoledgements..............................................7
10 References..................................................7
11 Authors³ Addresses..........................................7
1. Motivation 1. Media stream identification attribute
The RTSP RFC [1] defines a media stream as "a single media instance, A new "media stream identification" media attribute is defined. It
is used for identifying media streams within a session description.
Its formatting in SDP is described by the following BNF:
mid-attribute = "a=mid:" identification-tag
identification-tag = token
The identification tag is unique within the SDP session description.
2. Group attribute
A new "group" session level attribute is defined. It is used for
grouping together different media streams. Its formatting in SDP is
described by the following BNF:
groupe-attribute = "a=groupe:" semantics space
2*(space identification-tag)
semantics = "LS" | "FID"
This document defines two standard semantics: LS (Lip
Synchronization) and FID (Flow Identification). If in the future it
was needed to standardize further semantics they would need to be
defined in a standards track document. However, defining new
semantics apart from LS and FID is discouraged. Instead, it is
RECOMMENDED to use other session description mechanisms such as
SDPng [1].
Camarillo/Holler/Eriksson 2
Grouping of m lines in SDP
There might be several "a=groupe" lines in a session description.
"a=groupe" lines that contain identification-tags that are not
present in the session description are simply ignored. The
application acts as if the "a=groupe" line did not exist.
3. Lip Synchronization (LS)
The play out of media streams that are grouped together using LS
semantics have to be synchronized. Synchronization is typically
performed using RTCP, which provides enough information to map time
stamps from the different streams into a wall clock.
The following example shows a session description where the audio
and the video stream have to be synchronized.
v=0
o=Laura 289083124 289083124 IN IP4 first.example.com
t=0 0
c=IN IP4 131.160.1.112
a=groupe:LS 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=video 30002 RTP/AVP 31
a=mid:2
4. Flow Identification (FID)
The RTSP RFC [2] defines a media stream as "a single media instance,
e.g., an audio stream or a video stream as well as a single e.g., an audio stream or a video stream as well as a single
whiteboard or shared application group. When using RTP, a stream whiteboard or shared application group. When using RTP, a stream
consists of all RTP and RTCP packets created by a source within an consists of all RTP and RTCP packets created by a source within an
RTP session". RTP session".
This definition assumes that a single audio (or video) stream maps This definition assumes that a single audio (or video) stream maps
into an RTP session. The RTP RFC [2] defines an RTP session as into an RTP session. The RTP RFC [3] defines an RTP session as
follows: "For each participant, the session is defined by a follows: "For each participant, the session is defined by a
particular pair of destination transport addresses (one network particular pair of destination transport addresses (one network
address plus a port pair for RTP and RTCP)". address plus a port pair for RTP and RTCP)".
However, there are situations where a single media instance, (e.g., However, there are situations where a single media instance, (e.g.,
an audio stream or a video stream) is sent using more than one RTP an audio stream or a video stream) is sent using more than one RTP
session. Two examples (among many others) of this kind of situation session. Two examples (among many others) of this kind of situation
are cellular systems using SIP [3] and systems receiving DTMF tones are cellular systems using SIP [4] and systems receiving DTMF tones
on a different host than the voice. on a different host than the voice.
1.1 SIP and cellular access 4.1 SIP and cellular access
Systems using a cellular access and SIP as a signalling protocol Systems using a cellular access and SIP as a signalling protocol
need to receive media over the air. During a session the media can need to receive media over the air. During a session the media can
be encoded using different codecs. The encoded media has to traverse be encoded using different codecs. The encoded media has to traverse
the radio interface. The radio interface is generally characterized the radio interface. The radio interface is generally characterized
by being bit error prone and associated with relatively high packet by being bit error prone and associated with relatively high packet
Camarillo/Holler/Eriksson 3
Grouping of m lines in SDP
transfer delays. In addition, radio interface resources in a transfer delays. In addition, radio interface resources in a
cellular environment are scarce and thus expensive, which calls for cellular environment are scarce and thus expensive, which calls for
special measures in providing a highly efficient transport [4]. In special measures in providing a highly efficient transport [5]. In
order to get an appropriate speech quality in combination with an order to get an appropriate speech quality in combination with an
efficient transport, precise knowledge of codec properties are efficient transport, precise knowledge of codec properties are
required so that a proper radio bearer for the RTP session can be required so that a proper radio bearer for the RTP session can be
Camarillo/Holler/Eriksson 2
The SDP fid attribute
configured before transferring the media. These radio bearers are configured before transferring the media. These radio bearers are
dedicated bearers per media type, i.e. codec. dedicated bearers per media type, i.e. codec.
Cellular systems typically configure different radio bearers on Cellular systems typically configure different radio bearers on
different port numbers. Therefore, incoming media has to have different port numbers. Therefore, incoming media has to have
different destination port numbers for the different possible codecs different destination port numbers for the different possible codecs
in order to be routed properly to the correct radio bearer. Thus, in order to be routed properly to the correct radio bearer. Thus,
this is an example in which several RTP sessions are used to carry a this is an example in which several RTP sessions are used to carry a
single media instance (the encoded speech from the sender). single media instance (the encoded speech from the sender).
1.2 DTMF tones 4.2 DTMF tones
Some voice sessions include DTMF tones. Sometimes the voice handling Some voice sessions include DTMF tones. Sometimes the voice handling
is performed by a different host than the DTMF handling. [5] is performed by a different host than the DTMF handling. [6]
contains several examples of how application servers in the network contains several examples of how application servers in the network
gather DTMF tones for the user while the user receives the encoded gather DTMF tones for the user while the user receives the encoded
speech on his user agent. In this situations it is necessary to speech on his user agent. In this situations it is necessary to
establish two RTP sessions: one for the voice and the other for the establish two RTP sessions: one for the voice and the other for the
DTMF tones. Both RTP sessions are logically part of the same media DTMF tones. Both RTP sessions are logically part of the same media
instance. instance.
2. Media flow definition 5. Media flow definition
The previous examples show that the definition of a media stream in The previous examples show that the definition of a media stream in
[1] has to be updated. It cannot be assumed that a single media [2] has to be updated. It cannot be assumed that a single media
instance maps into a single RTP session. Therefore, we introduce the instance maps into a single RTP session. Therefore, we introduce the
definition of a media flow: definition of a media flow:
Media flow consists of a single media instance, e.g., an audio Media flow consists of a single media instance, e.g., an audio
stream or a video stream as well as a single whiteboard or shared stream or a video stream as well as a single whiteboard or shared
application group. When using RTP, a media flow comprises one or application group. When using RTP, a media flow comprises one or
more RTP sessions. more RTP sessions.
For instance, in a two party call where the voice exchanged can be For instance, in a two party call where the voice exchanged can be
encoded using GSM or PCM, the receiver wants to receive GSM on a encoded using GSM or PCM, the receiver wants to receive GSM on a
port number and PCM on a different port number. Two RTP sessions port number and PCM on a different port number. Two RTP sessions
will be established, one carrying GSM and the other carrying PCM. will be established, one carrying GSM and the other carrying PCM.
At any particular moment just one codec is in use. Therefore, at any At any particular moment just one codec is in use. Therefore, at any
moment one of the RTP sessions will not transport any voice. Here moment one of the RTP sessions will not transport any voice. Here
the systems are dealing with a single media flow, but two RTP the systems are dealing with a single media flow, but two RTP
sessions. sessions.
3. Flow identification attribute 6. FID semantics
An RTP session is described in SDP [6] using an "m" line. When a
media flow comprises more than one RTP session, we need a way to
associate several "m" lines together into a media flow.
A new "flow identification" media attribute is defined. It is used
for identifying media flows within a session. Its formatting in SDP
is described by the following BNF:
Camarillo/Holler/Eriksson 3
The SDP fid attribute
fid-attribute = "a=fid:" identification-tag
identification-tag = token
The identification tag is unique within the SDP session description.
Syntactically fid is a media-level attribute. It provides Several "m" lines grouped together using FID semantics form a media
information about a media stream defined by an "m" line. flow. A media agent handling a media flow that comprises several "m"
Semantically fid would be defined as a session-level attribute since
it provides flow hierarchy inside a session description.
4. Semantics of the fid attribute Camarillo/Holler/Eriksson 4
Grouping of m lines in SDP
A media agent handling a media flow that comprises several "m" lines lines sends media to different destinations (IP address/port number)
sends media to different destinations (IP address/port number)
depending on the codec used at any moment. If several "m" lines depending on the codec used at any moment. If several "m" lines
contain the codec used media is sent to different destinations in contain the codec used media is sent to different destinations in
parallel. parallel.
For instance, a SIP user agent receives an INVITE with the following For instance, a SIP user agent receives an INVITE with the following
body: body:
v=0 v=0
o=Laura 289083124 289083124 IN IP4 second.example.com o=Laura 289083124 289083124 IN IP4 second.example.com
t=0 0 t=0 0
c=IN IP4 131.160.1.112 c=IN IP4 131.160.1.112
a=groupe:FID 1 2 3
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
a=fid:1 a=mid:1
m=audio 30002 RTP/AVP 8 m=audio 30002 RTP/AVP 8
a=fid:1 a=mid:2
m=audio 30004 RTP/AVP 0 8 m=audio 30004 RTP/AVP 0 8
a=fid:1 a=mid:3
At a particular point of time, if the media agent is sending PCM u- At a particular point of time, if the media agent is sending PCM u-
law (payload 0) it sends RTP packets to ports 30000 and 30004 (first law (payload 0) it sends RTP packets to ports 30000 and 30004 (first
and third "m" lines). If it is sending PCM A-law (payload 8) it and third "m" lines). If it is sending PCM A-law (payload 8) it
sends RTP packets to ports 30002 and 30004 (second and third "m" sends RTP packets to ports 30002 and 30004 (second and third "m"
lines). lines).
Note that if several "m" lines with the same fid value contain the Note that if several "m" lines with the same fid value contain the
same codec the media agent MUST send media over several RTP sessions same codec the media agent MUST send media over several RTP sessions
at the same time. at the same time.
4.1 Interactions with other media level attributes 7 Interactions of "groupe" with other media level attributes
Media level attributes affect a media stream defined by an "m" line. Media level attributes affect a media stream defined by an "m" line.
The presence of fid does not modify this behavior. The presence of "groupe" does not modify this behavior.
For instance, a SIP user agent receives an INVITE with the following For instance, a SIP user agent receives an INVITE with the following
body: body:
v=0 v=0
o=Laura 289083124 289083124 IN IP4 second.example.com o=Laura 289083124 289083124 IN IP4 third.example.com
t=0 0 t=0 0
Camarillo/Holler/Eriksson 4
The SDP fid attribute
c=IN IP4 131.160.1.112 c=IN IP4 131.160.1.112
a=groupe:FID 1 2
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
a=fid:1 a=mid:1
m=audio 30002 RTP/AVP 8 m=audio 30002 RTP/AVP 8
a=recvonly a=recvonly
a=fid:1 a=mid:2
The media agent knows that at a certain moment it can send either The media agent knows that at a certain moment it can send either
PCM u-law to port number 30000 or PCM A-law to port number 30002. PCM u-law to port number 30000 or PCM A-law to port number 30002.
However, the media agent also knows that the other end will only However, the media agent also knows that the other end will only
send PCM u-law (payload 0). send PCM u-law (payload 0).
Note that the fid attribute allows to express uni-directional codecs Camarillo/Holler/Eriksson 5
for a bi-directional media flow, as it is shown in the example Grouping of m lines in SDP
above.
5. Usage of the fid attribute in SIP Note that the "groupe" attribute used with FID semantics allows to
express uni-directional codecs for a bi-directional media flow, as
it is shown in the example above.
SIP [3] is an application layer protocol for establishing, 8. Usage of the "groupe" attribute in SIP
SIP [4] is an application layer protocol for establishing,
terminating and modifying multimedia sessions. SIP carries session terminating and modifying multimedia sessions. SIP carries session
descriptions in the bodies of the SIP messages but is independent descriptions in the bodies of the SIP messages but is independent
from the protocol used for describing sessions. SDP [6] is one of from the protocol used for describing sessions. SDP [7] is one of
the protocols that can be used for this purpose. the protocols that can be used for this purpose.
Appendix B of [3] describes the usage of SDP in relation to SIP. It Appendix B of [4] describes the usage of SDP in relation to SIP. It
states: "The caller and callee align their media description so that states: "The caller and callee align their media description so that
the nth media stream ("m=" line) in the caller³s session description the nth media stream ("m=" line) in the caller³s session description
corresponds to the nth media stream in the callee³s description." corresponds to the nth media stream in the callee³s description."
The presence of the fid attribute in an SDP session description does The presence of the "groupe" attribute in an SDP session description
not modify this behavior. does not modify this behavior.
5.1 Backward compatibility 8.1 Backward compatibility
This document does not define any SIP "Require" header. Therefore, This document does not define any SIP "Require" header. Therefore,
if one of the SIP user agents does not understand the fid attribute if one of the SIP user agents does not understand the "groupe"
the standard SDP fall back mechanism is used. attribute the standard SDP fall back mechanism is used.
A system that understands the fid attribute MUST add it to any SDP A system that understands the "groupe" attribute MUST add an "mid"
session description that it generates. attribute to every "m" line in any SDP session description that it
generates.
5.2 Caller does not support fid 8.2 Caller does not support "groupe"
This situation does not represent a problem. The SDP in the INVITE This situation does not represent a problem. The SDP in the INVITE
will not contain any fid attribute. The callee knows that the caller will not contain any "mid" attribute. The callee knows that the
does not support fid. caller does not support "groupe".
5.3 Callee does not support fid 8.3 Callee does not support "groupe"
The callee will ignore the fid attribute, since it does not The callee will ignore the "groupe" attribute, since it does not
understand it. It will consider that the session comprises several understand it. For LS semantics, the callee might decide to perform
media streams. or to not perform synchronization between media streams.
Camarillo/Holler/Eriksson 5 For FID semantics, the callee will consider that the session
The SDP fid attribute comprises several media streams.
Different implementations would behave in different ways. Different implementations would behave in different ways.
In the case of audio and different "m" lines for different codecs an In the case of audio and different "m" lines for different codecs an
implementation might decide to act as a mixer with the different implementation might decide to act as a mixer with the different
incoming RTP sessions, which is the correct behavior. incoming RTP sessions, which is the correct behavior.
Camarillo/Holler/Eriksson 6
Grouping of m lines in SDP
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 callee does not support the several "m" lines. In this case, the callee 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
caller is willing to establish a simpler session anyway, he should caller is willing to establish a simpler session anyway, he should
re-try the request without the fid attribute and only one "m" line re-try the request without "groupe" attribute and only one "m" line
per flow. per flow.
6. Acknowledgments 9. Acknowledgments
The authors would like to thank Jonathan Rosenberg and Adam Roach The authors would like to thank Jonathan Rosenberg, Adam Roach and
for their feedback on this document. Orit Levin for their feedback on this document.
7. References 10. References
[1] H. Schulzrinne/A. Rao/R. Lanphier, "Real Time Streaming Protocol [1] D. Kutscher/J. Ott/C. Bormann, "Session Description and
Capability Negotiation", draft-ietf-mmusic-sdpng-00.txt, IETF; April
2001. Work in progress.
[2] H. Schulzrinne/A. Rao/R. Lanphier, "Real Time Streaming Protocol
(RTSP)", RFC 2326, IETF; April 1998. (RTSP)", RFC 2326, IETF; April 1998.
[2] H. Schulzrinne/S. Casner/R. Frederick/V. Jacobson, "RTP: A [3] H. Schulzrinne/S. Casner/R. Frederick/V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", RFC 1889, IETF; Transport Protocol for Real-Time Applications", RFC 1889, IETF;
January 1996. January 1996.
[3] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: [4] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP:
Session Initiation Protocol", RFC 2543, IETF; Mach 1999. Session Initiation Protocol", RFC 2543, IETF; Mach 1999.
[4] L. Westberg/M. Lindqvist, "Realtime Traffic over Cellular Access [5] L. Westberg/M. Lindqvist, "Realtime Traffic over Cellular Access
Networks", draft-westberg-realtime-cellular-03.txt, IETF; November Networks", draft-westberg-realtime-cellular-03.txt, IETF; November
2000. Work in progress. 2000. Work in progress.
[5] J. Rosemberg/P.Mataga/H.Schulzrinne, "An Applcation Server [6] J. Rosemberg/P.Mataga/H.Schulzrinne, "An Applcation Server
Component Architecture for SIP", draft-rosenberg-sip-app-components- Component Architecture for SIP", draft-rosenberg-sip-app-components-
00.txt, IETF; November 2000. Work in progress. 00.txt, IETF; November 2000. Work in progress.
[6] M. Handley/V. Jacobson, "SDP: Session Description Protocol", RFC [7] M. Handley/V. Jacobson, "SDP: Session Description Protocol", RFC
2327, IETF; April 1998. 2327, IETF; April 1998.
8. Authors³ Addresses 11. Authors³ Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Advanced Signalling Research Lab. Advanced Signalling Research Lab.
FIN-02420 Jorvas FIN-02420 Jorvas
Finland Finland
Phone: +358 9 299 3371 Phone: +358 9 299 3371
Fax: +358 9 299 3052 Fax: +358 9 299 3052
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Camarillo/Holler/Eriksson 6
The SDP fid attribute
Jan Holler Jan Holler
Ericsson Research Ericsson Research
Camarillo/Holler/Eriksson 7
Grouping of m lines in SDP
S-16480 Stockholm S-16480 Stockholm
Sweden Sweden
Phone: +46 8 58532845 Phone: +46 8 58532845
Fax: +46 8 4047020 Fax: +46 8 4047020
Email: Jan.Holler@era.ericsson.se Email: Jan.Holler@era.ericsson.se
Goran AP Eriksson Goran AP Eriksson
Ericsson Research Ericsson Research
S-16480 Stockholm S-16480 Stockholm
Sweden Sweden
Phone: +46 8 58531762 Phone: +46 8 58531762
Fax: +46 8 4047020 Fax: +46 8 4047020
Email: Goran.AP.Eriksson@era.ericsson.se Email: Goran.AP.Eriksson@era.ericsson.se
Camarillo/Holler/Eriksson 7 Camarillo/Holler/Eriksson 8
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/