--- 1/draft-ietf-mmusic-fid-04.txt 2006-02-05 00:26:06.000000000 +0100 +++ 2/draft-ietf-mmusic-fid-05.txt 2006-02-05 00:26:06.000000000 +0100 @@ -1,22 +1,22 @@ Internet Engineering Task Force Gonzalo Camarillo Internet draft Jan Holler Goran AP Eriksson Ericsson Henning Schulzrinne Columbia University - August 2001 - Expires February 2002 - + September 2001 + Expires March 2002 + Grouping of media lines in SDP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -47,42 +47,42 @@ 1 Introduction...............................................2 2 Terminology................................................3 3 Media stream identification attribute......................3 4 Group attribute............................................3 5 Use of "group" and "mid"...................................3 6 Lip Synchronization (LS)...................................4 6.1 Example of LS..............................................4 7 Flow Identification (FID)..................................5 7.1 SIP and cellular access....................................5 - 7.2 DTMF tones.................................................5 + 7.2 DTMF tones.................................................6 7.3 Media flow definition......................................6 7.4 FID semantics..............................................6 7.4.1 Examples of FID............................................6 - 8 Scenarios that FID does not cover..........................9 - 8.1 Parallel encoding using different codecs...................9 - 8.2 Layered encoding..........................................10 - 8.3 Same IP address and port number...........................10 - 9 Usage of the "group" attribute in SIP.....................11 - 9.1 Mid value in responses....................................11 - 9.1.1 Example...................................................11 - 9.2 Group value in responses..................................12 - 9.2.1 Example...................................................13 - 9.3 Capability negotiation....................................14 - 9.3.1 Example...................................................14 - 9.4 Backward compatibility....................................14 - 9.4.1 Client does not support "group"...........................15 - 9.4.2 Server does not support "group"...........................15 - 10 IANA considerations.......................................15 - 11 Acknowledgements..........................................15 - 12 References................................................15 - 13 Authors³ Addresses........................................16 + 7.5 Scenarios that FID does not cover..........................9 + 7.5.1 Parallel encoding using different codecs...................9 + 7.5.2 Layered encoding..........................................10 + 7.5.3 Same IP address and port number...........................10 + 8 Usage of the "group" attribute in SIP.....................11 + 8.1 Mid value in responses....................................11 + 8.1.1 Example...................................................12 + 8.2 Group value in responses..................................12 + 8.2.1 Example...................................................13 + 8.3 Capability negotiation....................................14 + 8.3.1 Example...................................................14 + 8.4 Backward compatibility....................................14 + 8.4.1 Client does not support "group"...........................15 + 8.4.2 Server does not support "group"...........................15 + 9 IANA considerations.......................................15 + 10 Acknowledgements..........................................16 + 11 References................................................16 + 12 Authors³ Addresses........................................16 1 Introduction An SDP session description typically contains a number (one or more) of media lines - they are commonly known as "m" lines. When a session description contains more than one "m" line, SDP does not provide any means to express a particular relationship between two or more of 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 them. SDP does not carry any information about @@ -124,55 +124,61 @@ group-attribute = "a=group:" semantics *(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 [3]. + SDPng. 5. Use of "group" and "mid" All the "m" lines of a session description that uses "group" MUST be - identified with an "mid" attribute regardless of whether they appear - or not in the group line(s). If a session description contains at - least one "m" line that has no "mid" identification the application - MUST NOT perform any grouping of media lines. + identified with an "mid" attribute whether they appear in the group + line(s) or not. If a session description contains at least one "m" + line that has no "mid" identification the application MUST NOT + perform any grouping of media lines. "a=group" lines are used to group together several "m" lines that are identified by their "mid" attribute. "a=group" lines that contain identification-tags that do not correspond to any "m" line within the session description MUST be simply ignored. The application acts as if the "a=group" line did not exist. The behavior of an application receiving an SDP with grouped "m" lines is defined by the semantics field in the "a=group" line. Camarillo/Holler/Eriksson/Schulzrinne 3 Grouping of media lines in SDP - There MAY be several "a=group" lines in a session description. + There MAY be several "a=group" lines in a session description. All + the "a=group" lines of a session description MAY or MAY NOT use the + same semantics. An "m" line identified by its "mid" attribute MAY + appear in more than one "a=group" line as long as the "a=group" + lines use different semantics. An "m" line identified by its "mid" + attribute MUST NOT appear in more than one "a=group" line using the + same semantics. An application that wants to be compliant to this specification MUST support both "group" and "mid". An application that supported just one of them would not be compliant. 6. Lip Synchronization (LS) An application that receives a session description that contains "m" lines that are grouped together using LS semantics MUST synchronize the play out of the corresponding media streams. Note that LS semantics not only apply to a video stream that has to be - synchronized with an audio stream. The play out of two streams of - the same type can perfectly be synchronized as well. + synchronized with an audio stream. The playout of two streams of the + same type can perfectly be synchronized as well. For RTP streams synchronization is typically performed using RTCP, which provides enough information to map time stamps from the different streams into a wall clock. However, the concept of media stream synchronization MAY also apply to media streams that do not make use of RTP. If this is the case, the application MUST recover the original timing relationship between the streams using whatever available mechanism. 6.1 Example of LS @@ -190,94 +196,90 @@ c=IN IP4 224.2.17.12/127 a=group:LS 1 2 m=audio 30000 RTP/AVP 0 a=mid:1 m=video 30002 RTP/AVP 31 a=mid:2 m=audio 30004 RTP/AVP 0 i=This media stream contains the Spanish translation a=mid:3 +Camarillo/Holler/Eriksson/Schulzrinne 4 + Grouping of media lines in SDP + Note that although the third media stream is not present in the group line it still MUST contain an mid attribute (mid:3), as stated before. -Camarillo/Holler/Eriksson/Schulzrinne 4 - Grouping of media lines in SDP - 7. Flow Identification (FID) An "m" line in an SDP session description defines a media stream. - However, SDP does not define what a media stream is. To find the - definition of a media stream we have to go to the RTSP - specification. The RTSP RFC [4] defines a media stream as "a single - media instance, e.g., an audio stream or a video stream as well as a - single whiteboard or shared application group. When using RTP, a - stream consists of all RTP and RTCP packets created by a source - within an RTP session". + However, SDP does not define what a media stream is. This definition + can be found in the RTSP specification. The RTSP RFC [3] defines a + media stream as "a single media instance, e.g., an audio stream or a + video stream as well as a single whiteboard or shared application + group. When using RTP, a stream consists of all RTP and RTCP packets + created by a source within an RTP session". This definition assumes that a single audio (or video) stream maps - into an RTP session. To find the definition of an RTP session we go - to the RTP specification. The RTP RFC [5] defines an RTP session as + into an RTP session. The RTP RFC [4] defines an RTP session as follows: "For each participant, the session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP)". While the previous definitions cover the most common cases, there are situations where a single media instance, (e.g., 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 are cellular - systems using SIP [6] and systems receiving DTMF tones on a + systems using SIP [5] and systems receiving DTMF tones on a different host than the voice. 7.1 SIP and cellular access Systems using a cellular access and SIP as a signalling protocol need to receive media over the air. During a session the media can be encoded using different codecs. The encoded media has to traverse the radio interface. The radio interface is generally characterized by being bit error prone and associated with relatively high packet transfer delays. In addition, radio interface resources in a cellular environment are scarce and thus expensive, which calls for - special measures in providing a highly efficient transport [7]. In - order to get an appropriate speech quality in combination with an + special measures in providing a highly efficient transport. In order + to get an appropriate speech quality in combination with an efficient transport, precise knowledge of codec properties are required so that a proper radio bearer for the RTP session can be configured before transferring the media. These radio bearers are dedicated bearers per media type, i.e. codec. Cellular systems typically configure different radio bearers on different port numbers. Therefore, incoming media has to have different destination port numbers for the different possible codecs 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 single media instance (the encoded speech from the sender). -7.2 DTMF tones - - Some voice sessions include DTMF tones. Sometimes the voice handling - is performed by a different host than the DTMF handling. [8] - contains several examples of how application servers in the network - Camarillo/Holler/Eriksson/Schulzrinne 5 Grouping of media lines in SDP - gather DTMF tones for the user while the user receives the encoded - 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 - DTMF tones. Both RTP sessions are logically part of the same media - instance. +7.2 DTMF tones + + Some voice sessions include DTMF tones. Sometimes the voice handling + is performed by a different host than the DTMF handling. It is + common to have an application server in the network gathering DTMF + tones for the user while the user receives the encoded 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 DTMF tones. Both + RTP sessions are logically part of the same media instance. 7.3 Media flow definition The previous examples show that the definition of a media stream in - [4] do not cover some scenarios. It cannot be assumed that a single + [3] do not cover some scenarios. It cannot be assumed that a single media instance maps into a single RTP session. Therefore, we introduce the definition of a media flow: 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 application group. When using RTP, a media flow comprises one or more RTP sessions. 7.4 FID semantics @@ -303,27 +305,27 @@ The application typically ends up sending media to different destinations (IP address/port number) depending on the codec used at any moment. 7.4.1 Examples of FID The session description below would be the SDP sent by a SIP user agent using a cellular access. The user agent supports GSM on port 30000 and AMR on port 30002. When the remote party sends GSM it will send RTP packets to port number 30000. When AMR is the codec chosen, - packets will be sent to port 30002. Note that the remote party can - switch between both codecs dynamically in the middle of the session. - However, in this example, only one media stream at a time carries Camarillo/Holler/Eriksson/Schulzrinne 6 Grouping of media lines in SDP + packets will be sent to port 30002. Note that the remote party can + switch between both codecs dynamically in the middle of the session. + However, in this example, only one media stream at a time carries voice. The other remains "muted" while its corresponding codec is not in use. v=0 o=Laura 289083124 289083124 IN IP4 two.example.com t=0 0 c=IN IP4 131.160.1.112 a=group:FID 1 2 m=audio 30000 RTP/AVP 3 a=rtpmap:3 GSM/8000 @@ -388,21 +390,21 @@ the other end will only send PCM u-law (payload 0). The following example shows a session description with different "m" lines grouped together using FID semantics that contain the same codec. v=0 o=Laura 289083124 289083124 IN IP4 five.example.com t=0 0 c=IN IP4 131.160.1.112 - a=groupe:FID 1 2 3 + a=group:FID 1 2 3 m=audio 30000 RTP/AVP 0 a=mid:1 m=audio 30002 RTP/AVP 8 a=mid:2 m=audio 20000 RTP/AVP 0 8 c=IN IP4 131.160.1.111 a=recvonly a=mid:3 At a particular point of time, if the media agent is sending PCM u- @@ -413,31 +415,31 @@ (second and third "m" lines). The system that generated the SDP above supports PCM u-law on port 30000 and PCM A-law on port 30002. Besides, it uses an application server whose IP address is 131.160.1.111 that records all the conversation. That is why the application server always receives a copy of the audio stream regardless of the codec being used at any given moment (it actually performs an RTP dump, so it can effectively receive any codec). +Camarillo/Holler/Eriksson/Schulzrinne 8 + Grouping of media lines in SDP + Remember that if several "m" lines grouped together using FID semantics contain the same codec the media agent MUST send media over several RTP sessions at the same time. -Camarillo/Holler/Eriksson/Schulzrinne 8 - Grouping of media lines in SDP - The last example of this section deals with DTMF tones. DTMF tones can be transmitted using a regular voice codec or can be transmitted as telephony events. The RTP payload for DTMF tones treated as - telephone events is described in RFC 2833 [9]. Below there is an + telephone events is described in RFC 2833 [6]. Below there is an example of an SDP session description using FID semantics and this payload type. v=0 o=Laura 289083124 289083124 IN IP4 six.example.com t=0 0 c=IN IP4 131.160.1.112 a=group:FID 1 2 m=audio 30000 RTP/AVP 0 a=mid:1 @@ -447,71 +449,73 @@ a=mid:2 The remote party would send PCM encoded voice (payload 0) to 131.160.1.112 and DTMF tones encoded as telephony events to 131.160.1.111. Note that only voice or DTMF is sent at a particular point of time. 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 stream. FID semantics provide different destinations for alternative codecs. -8 Scenarios that FID does not cover +7.5 Scenarios that FID does not cover It is worthwhile mentioning some scenarios where the "group" attribute using existing semantics (particularly FID) might seem to be applicable but it is not. This section has been included because we have observed some confusion within the community regarding the three scenarios described below. This section helps clarify them. -8.1 Parallel encoding using different codecs +7.5.1 Parallel encoding using different codecs FID semantics are useful when the application only uses one codec at - a time. When a particular application encodes the same media using - different codecs FID MUST NOT be used. Some systems that handle DTMF - tones are a typical example of parallel encoding using different - codecs. + a time. An application that encodes the same media using different + codecs simultaneously MUST NOT use FID to group those media lines. + Some systems that handle DTMF tones are a typical example of + parallel encoding using different codecs. Some systems implement the RTP payload defined in RFC 2833, but when they send DTMF tones they do not mute the voice channel. Therefore, effectively they are sending two copies of the same DTMF tone: encoded as voice and encoded as a telephony event. When the receiver gets both copies it typically uses the telephony event rather than the tone encoded as voice. FID semantics MUST NOT be used in this - context to group both media streams since such a system is not using - alternative codecs but rather different parallel encodings for the - same information. Camarillo/Holler/Eriksson/Schulzrinne 9 Grouping of media lines in SDP -8.2 Layered encoding + context to group both media streams since such a system is not using + alternative codecs but rather different parallel encodings for the + same information. + +7.5.2 Layered encoding Layered encoding schemes encode media in different layers. Quality at the receiver varies depending on the number of layers received. SDP provides a means to group together contiguous multicast addresses that transport different layers. The "c" line below: c=IN IP4 224.2.1.1/127/3 is equivalent to the following three "c" lines: c=IN IP4 224.2.1.1/127 c=IN IP4 224.2.1.2/127 c=IN IP4 224.2.1.3/127 - FID MUST NOT be used to group "m" lines that contain the different - layers of layered encoding scheme. Besides, we do not define new - group semantics to provide a more flexible way of grouping different - layers because the already existing SDP mechanism covers the most - useful scenarios. + 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 + that contain the different layers of layered encoding scheme. + Besides, we do not define new group semantics to provide a more + flexible way of grouping different layers because the already + existing SDP mechanism covers the most useful scenarios. -8.3 Same IP address and port number +7.5.3 Same IP address and port number If several codecs have to be sent to the same IP address and port, the traditional SDP syntax of listing several codecs in the same "m" line MUST be used. FID MUST NOT be used to group "m" lines with the same IP address/port. Therefore, an SDP like the one below MUST NOT be generated. v=0 o=Laura 289083124 289083124 IN IP4 six.example.com t=0 0 @@ -523,162 +527,164 @@ a=mid:2 The correct SDP for the session above would be the following one: v=0 o=Laura 289083124 289083124 IN IP4 six.example.com t=0 0 c=IN IP4 131.160.1.112 m=audio 30000 RTP/AVP 0 8 -9. Usage of the "group" attribute in SIP +Camarillo/Holler/Eriksson/Schulzrinne 10 + Grouping of media lines in SDP + + If two "m" lines are grouped using FID they MUST differ in their + transport addresses (i.e., IP address plus port). + +8. Usage of the "group" attribute in SIP SDP descriptions are used by several different protocols, SIP among them. We include a section about SIP because the "group" attribute will most likely be used mainly by SIP systems. -Camarillo/Holler/Eriksson/Schulzrinne 10 - Grouping of media lines in SDP - - SIP [6] is an application layer protocol for establishing, + SIP [5] is an application layer protocol for establishing, terminating and modifying multimedia sessions. SIP carries session descriptions in the bodies of the SIP messages but is independent from the protocol used for describing sessions. SDP [2] is one of the protocols that can be used for this purpose. At session establishment SIP provides a three-way handshake (INVITE- 200 OK-ACK) between end systems. However, just two of these three messages carry SDP. SDPs MAY be present in INVITE and 200 OK or in 200 OK and ACK. The following sections assume that INVITE and 200 OK - are the ones carrying SDP for the shake of clarity, but everything - is also applicable to the other possible scenario (200 OK and ACK). + are the ones carrying SDP for the sake of clarity, but everything is + also applicable to the other possible scenario (200 OK and ACK). -9.1 Mid value in responses +8.1 Mid value in responses The "mid" attribute is an identifier for a particular media stream. Therefore, the "mid" value in the response MUST be the same as the "mid" value in the request. Besides, subsequent requests such as re- INVITEs SHOULD use the same "mid" value for the already existing media streams. - Appendix B of [6] describes the usage of SDP in relation to SIP. It + Appendix B of [5] describes the usage of SDP in relation to SIP. It states: "The caller and callee align their media description so that the nth media stream ("m=" line) in the caller³s session description corresponds to the nth media stream in the callee³s description." The presence of the "group" attribute in an SDP session description does not modify this behavior. Since the "mid" attribute provides a means to label "m" lines it would be possible to perform media alignment using "mid" labels rather than matching nth "m" lines. However this would not bring any gain and would add complexity to implementations. Therefore SIP systems MUST perform media alignment matching nth lines regardless of the presence of the "group" or "mid" attributes. If a media stream that contained a particular "mid" identifier in the request contains a different identifier in the response the application ignores all the "mid" and "group" lines that might appear in the session description. The following example illustrates this scenario: -9.1.1 Example +Camarillo/Holler/Eriksson/Schulzrinne 11 + Grouping of media lines in SDP + +8.1.1 Example Two SIP entities exchange SDPs during session establishment. The INVITE contained the SDP below: v=0 o=Laura 289083124 289083124 IN IP4 seven.example.com t=0 0 c=IN IP4 131.160.1.112 - a=groupe:FID 1 2 - -Camarillo/Holler/Eriksson/Schulzrinne 11 - Grouping of media lines in SDP - + a=group:FID 1 2 m=audio 30000 RTP/AVP 0 8 a=mid:1 m=audio 30002 RTP/AVP 0 8 a=mid:2 The 200 OK response contains the following SDP: v=0 o=Bob 289083122 289083122 IN IP4 eigth.example.com t=0 0 c=IN IP4 131.160.1.113 - a=groupe:FID 1 2 + a=group:FID 1 2 m=audio 25000 RTP/AVP 0 8 a=mid:2 m=audio 25002 RTP/AVP 0 8 a=mid:1 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 200 OK. Therefore, the application MUST ignore every "mid" and "group" lines contained in the SDP. A well-behaved SIP user agent would have returned the SDP below in the 200 OK: v=0 o=Bob 289083122 289083122 IN IP4 nine.example.com t=0 0 c=IN IP4 131.160.1.113 - a=groupe:FID 1 2 + a=group:FID 1 2 m=audio 25002 RTP/AVP 0 8 a=mid:1 m=audio 25000 RTP/AVP 0 8 a=mid:2 -9.2 Group value in responses +8.2 Group value in responses A SIP entity that receives a request that contains an "a=group" line with semantics that it does not understand MUST return a response without the "group" line. Note that, as it was described in the previous section, the "mid" lines MUST still be present in the response. +Camarillo/Holler/Eriksson/Schulzrinne 12 + Grouping of media lines in SDP + A SIP entity that receives a request that contains an "a=group" line which semantics that are understood MUST return a response that contains an "a=group" line with the same semantics. The identification-tags contained in this "a=group" lines MUST be the same that were received in the request or a subset of them (zero identification-tags is a valid subset). When the identification-tags in the response are a subset the "group" value to be used in the session MUST be the one present in the response. -Camarillo/Holler/Eriksson/Schulzrinne 12 - Grouping of media lines in SDP - SIP entities refuse media streams by setting the port to zero in the - corresponding "m" line. "a=group" lines MUST no contain + corresponding "m" line. "a=group" lines MUST NOT contain identification-tags that correspond to "m" lines with port zero. Note that grouping of m lines MUST always be requested by the issuer of the request (the client), never by the issuer of the response (the server). Since SIP provides a two-way SDP exchange, a server that requested grouping in a response would not know whether the "group" attribute was accepted by the client or not. A server that wants to group media lines SHOULD issue another request after having responded to the first one (a re-INVITE for instance). Note that, as we mentioned previously, in this section we are assuming that the SDPs are present in the INVITE and in the 200 OK. Applying the statement above to the scenario where SDPs are present in the 200 OK and in the ACK, the entity requesting grouping would be the server. -9.2.1 Example +8.2.1 Example The example below shows how the callee refuses a media stream - offered by the caller setting its port number to zero. The "mid" + offered by the caller by setting its port number to zero. The "mid" value corresponding to that media stream is removed from the "group" value in the response. SDP in the INVITE from caller to callee: v=0 o=Laura 289083124 289083124 IN IP4 ten.example.com t=0 0 c=IN IP4 131.160.1.112 a=group:FID 1 2 3 @@ -686,46 +692,47 @@ a=mid:1 m=audio 30002 RTP/AVP 8 a=mid:2 m=audio 30004 RTP/AVP 3 a=mid:3 SDP in the INVITE from callee to caller: v=0 o=Bob 289083125 289083125 IN IP4 eleven.example.com + +Camarillo/Holler/Eriksson/Schulzrinne 13 + Grouping of media lines in SDP + t=0 0 c=IN IP4 131.160.1.113 a=group:FID 1 3 m=audio 20000 RTP/AVP 0 a=mid:1 m=audio 0 RTP/AVP 8 a=mid:2 m=audio 20002 RTP/AVP 3 a=mid:3 -Camarillo/Holler/Eriksson/Schulzrinne 13 - Grouping of media lines in SDP - -9.3 Capability negotiation +8.3 Capability negotiation A client that understands "group" and "mid" but does not want to make use of them in a particular session MAY want indicate that it supports them. If a client decides to do that, it SHOULD add an "a=group" line with zero identification-tags for every semantics it understands. If a server receives a request that contains empty "a=group" lines it SHOULD add its capabilities also in the form of empty "a=group" lines to its response. -9.3.1 Example +8.3.1 Example A system that supports both LS and FID semantics but does not want to group any media stream for this particular session generates the following SDP: v=0 o=Bob 289083125 289083125 IN IP4 twelve.example.com t=0 0 c=IN IP4 131.160.1.113 a=group:LS @@ -735,39 +742,39 @@ The server that receives that request supports FID but not LS. It responds with the SDP below: v=0 o=Laura 289083124 289083124 IN IP4 thirteen.example.com t=0 0 c=IN IP4 131.160.1.112 a=group:FID m=audio 30000 RTP/AVP 0 -9.4 Backward compatibility +8.4 Backward compatibility This document does not define any SIP "Require" header. Therefore, if one of the SIP user agents does not understand the "group" + +Camarillo/Holler/Eriksson/Schulzrinne 14 + Grouping of media lines in SDP + attribute the standard SDP fall back mechanism MUST be used (attributes that are not understood are simply ignored). -9.4.1 Client does not support "group" +8.4.1 Client does not support "group" This situation does not represent a problem because grouping requests is always performed by clients, not by servers. If the - -Camarillo/Holler/Eriksson/Schulzrinne 14 - Grouping of media lines in SDP - client does not support "group" this attribute will just not be used. -9.4.2 Server does not support "group" +8.4.2 Server does not support "group" The server will ignore the "group" attribute, since it does not understand it (it will also ignore the "mid" attribute). For LS semantics, the server might decide to perform or to not perform synchronization between media streams. For FID semantics, the server will consider that the session comprises several media streams. Different implementations would behave in different ways. @@ -777,70 +784,65 @@ incoming RTP sessions, which is the correct behavior. An implementation might also decide to refuse the request (e.g. 488 Not acceptable here or 606 Not Acceptable) because it contains several "m" lines. In this case, the server does not support the type of session that the caller wanted to establish. In case the client is willing to establish a simpler session anyway, he SHOULD re-try the request without "group" attribute and only one "m" line per flow. -10. IANA considerations +9. IANA considerations - As previously stated in section 4, this document defines two - standard semantics related to the "group" attribute: 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. + This document defines two SDP attributes: "mid" and "group". -11. Acknowledgments + The "mid" attribute is used to identify media streams within a + session description and its format is defined in Section 3. + + The "group" attribute is used for grouping together different media + streams and its format is defined in Section 4. + + Section 4 also defines two standard semantics related to the "group" + attribute: 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. + +Camarillo/Holler/Eriksson/Schulzrinne 15 + Grouping of media lines in SDP + +10. Acknowledgments The authors would like to thank Jonathan Rosenberg, Adam Roach, Orit Levin and Joerg Ott for their feedback on this document. -12. References +11. References [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, IETF; March 1997. [2] M. Handley/V. Jacobson, "SDP: Session Description Protocol", RFC 2327, IETF; April 1998. - [3] D. Kutscher/J. Ott/C. Bormann, "Session Description and - Capability Negotiation", draft-ietf-mmusic-sdpng-00.txt, IETF; April - 2001. Work in progress. - -Camarillo/Holler/Eriksson/Schulzrinne 15 - Grouping of media lines in SDP - - [4] H. Schulzrinne/A. Rao/R. Lanphier, "Real Time Streaming Protocol + [3] H. Schulzrinne/A. Rao/R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, IETF; April 1998. - [5] H. Schulzrinne/S. Casner/R. Frederick/V. Jacobson, "RTP: A + [4] H. Schulzrinne/S. Casner/R. Frederick/V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, IETF; January 1996. - [6] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: + [5] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, IETF; Mach 1999. - [7] L. Westberg/M. Lindqvist, "Realtime Traffic over Cellular Access - Networks", draft-westberg-realtime-cellular-04.txt, IETF; June 2001. - Work in progress. - - [8] J. Rosenberg/P.Mataga/H.Schulzrinne, "An Application Server - Component Architecture for SIP", draft-rosenberg-sip-app-components- - 00.txt, IETF; November 2000. Work in progress. - - [9] H. Schulzrinne/S. Petrack, "RTP Payload for DTMF Digits, + [6] H. Schulzrinne/S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, IETF; May 2000. -13. Authors³ Addresses +12. Authors³ Addresses Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland Phone: +358 9 299 3371 Fax: +358 9 299 3052 Email: Gonzalo.Camarillo@ericsson.com @@ -853,23 +855,22 @@ Email: Jan.Holler@era.ericsson.se Goran AP Eriksson Ericsson Research S-16480 Stockholm Sweden Phone: +46 8 58531762 Fax: +46 8 4047020 Email: Goran.AP.Eriksson@era.ericsson.se +Camarillo/Holler/Eriksson/Schulzrinne 16 + Grouping of media lines in SDP + Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue - -Camarillo/Holler/Eriksson/Schulzrinne 16 - Grouping of media lines in SDP - New York, NY 10027 USA Email: schulzrinne@cs.columbia.edu Camarillo/Holler/Eriksson/Schulzrinne 17