idnits 2.17.1 draft-ietf-mmusic-fid-05.txt: -(572): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 24 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 5 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2002) is 8079 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2327 (ref. '2') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2326 (ref. '3') (Obsoleted by RFC 7826) ** Obsolete normative reference: RFC 1889 (ref. '4') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2543 (ref. '5') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 2833 (ref. '6') (Obsoleted by RFC 4733, RFC 4734) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Gonzalo Camarillo 3 Internet draft Jan Holler 4 Goran AP Eriksson 5 Ericsson 7 Henning Schulzrinne 8 Columbia University 10 September 2001 11 Expires March 2002 12 14 Grouping of media lines in SDP 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. Internet-Drafts are draft documents valid for a maximum of 25 six months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document defines two SDP attributes: "group" and "mid". They 38 allow to group together several "m" lines for two different 39 purposes: for lip synchronization and for receiving media from a 40 single flow (several media streams), encoded in different formats 41 during a particular session, in different ports and host interfaces. 43 Camarillo/Holler/Eriksson/Schulzrinne 1 44 Grouping of media lines in SDP 46 TABLE OF CONTENTS 48 1 Introduction...............................................2 49 2 Terminology................................................3 50 3 Media stream identification attribute......................3 51 4 Group attribute............................................3 52 5 Use of "group" and "mid"...................................3 53 6 Lip Synchronization (LS)...................................4 54 6.1 Example of LS..............................................4 55 7 Flow Identification (FID)..................................5 56 7.1 SIP and cellular access....................................5 57 7.2 DTMF tones.................................................6 58 7.3 Media flow definition......................................6 59 7.4 FID semantics..............................................6 60 7.4.1 Examples of FID............................................6 61 7.5 Scenarios that FID does not cover..........................9 62 7.5.1 Parallel encoding using different codecs...................9 63 7.5.2 Layered encoding..........................................10 64 7.5.3 Same IP address and port number...........................10 65 8 Usage of the "group" attribute in SIP.....................11 66 8.1 Mid value in responses....................................11 67 8.1.1 Example...................................................12 68 8.2 Group value in responses..................................12 69 8.2.1 Example...................................................13 70 8.3 Capability negotiation....................................14 71 8.3.1 Example...................................................14 72 8.4 Backward compatibility....................................14 73 8.4.1 Client does not support "group"...........................15 74 8.4.2 Server does not support "group"...........................15 75 9 IANA considerations.......................................15 76 10 Acknowledgements..........................................16 77 11 References................................................16 78 12 Authors� Addresses........................................16 80 1 Introduction 82 An SDP session description typically contains a number (one or more) 83 of media lines - they are commonly known as "m" lines. When a 84 session description contains more than one "m" line, SDP does not 85 provide any means to express a particular relationship between two 86 or more of them. When an application receives an SDP session 87 description with more than one "m" line it is up to the application 88 what to do with them. SDP does not carry any information about 89 grouping media streams. 91 While in some environments this information can be carried out of 92 band, it would be desirable to have extensions to SDP that allowed 93 to express how different media streams within a session description 94 relate to each other. This document defines such extensions. 96 Camarillo/Holler/Eriksson/Schulzrinne 2 97 Grouping of media lines in SDP 99 2 Terminology 101 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 102 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 103 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] 104 and indicate requirement levels for compliant implementations. 106 3. Media stream identification attribute 108 A new "media stream identification" media attribute is defined. It 109 is used for identifying media streams within a session description. 110 Its formatting in SDP [2] is described by the following BNF: 112 mid-attribute = "a=mid:" identification-tag 113 identification-tag = token 115 The identification tag MUST be unique within an SDP session 116 description. 118 4. Group attribute 120 A new "group" session level attribute is defined. It is used for 121 grouping together different media streams. Its formatting in SDP is 122 described by the following BNF: 124 group-attribute = "a=group:" semantics 125 *(space identification-tag) 126 semantics = "LS" | "FID" 128 This document defines two standard semantics: LS (Lip 129 Synchronization) and FID (Flow Identification). If in the future it 130 was needed to standardize further semantics they would need to be 131 defined in a standards track document. However, defining new 132 semantics apart from LS and FID is discouraged. Instead, it is 133 RECOMMENDED to use other session description mechanisms such as 134 SDPng. 136 5. Use of "group" and "mid" 138 All the "m" lines of a session description that uses "group" MUST be 139 identified with an "mid" attribute whether they appear in the group 140 line(s) or not. If a session description contains at least one "m" 141 line that has no "mid" identification the application MUST NOT 142 perform any grouping of media lines. 144 "a=group" lines are used to group together several "m" lines that 145 are identified by their "mid" attribute. "a=group" lines that 146 contain identification-tags that do not correspond to any "m" line 147 within the session description MUST be simply ignored. The 148 application acts as if the "a=group" line did not exist. The 149 behavior of an application receiving an SDP with grouped "m" lines 150 is defined by the semantics field in the "a=group" line. 152 Camarillo/Holler/Eriksson/Schulzrinne 3 153 Grouping of media lines in SDP 155 There MAY be several "a=group" lines in a session description. All 156 the "a=group" lines of a session description MAY or MAY NOT use the 157 same semantics. An "m" line identified by its "mid" attribute MAY 158 appear in more than one "a=group" line as long as the "a=group" 159 lines use different semantics. An "m" line identified by its "mid" 160 attribute MUST NOT appear in more than one "a=group" line using the 161 same semantics. 163 An application that wants to be compliant to this specification MUST 164 support both "group" and "mid". An application that supported just 165 one of them would not be compliant. 167 6. Lip Synchronization (LS) 169 An application that receives a session description that contains "m" 170 lines that are grouped together using LS semantics MUST synchronize 171 the playout of the corresponding media streams. Note that LS 172 semantics not only apply to a video stream that has to be 173 synchronized with an audio stream. The playout of two streams of the 174 same type can perfectly be synchronized as well. 176 For RTP streams synchronization is typically performed using RTCP, 177 which provides enough information to map time stamps from the 178 different streams into a wall clock. However, the concept of media 179 stream synchronization MAY also apply to media streams that do not 180 make use of RTP. If this is the case, the application MUST recover 181 the original timing relationship between the streams using whatever 182 available mechanism. 184 6.1 Example of LS 186 The following example shows a session description of a conference 187 that is being multicast. The first media stream (mid:1) contains the 188 voice of the speaker, who speaks in English. The second media stream 189 (mid:2) contains the video component and the third (mid:3) media 190 stream carries the translation to Spanish of what he is saying. The 191 first and the second media streams MUST be synchronized. 193 v=0 194 o=Laura 289083124 289083124 IN IP4 one.example.com 195 t=0 0 196 c=IN IP4 224.2.17.12/127 197 a=group:LS 1 2 198 m=audio 30000 RTP/AVP 0 199 a=mid:1 200 m=video 30002 RTP/AVP 31 201 a=mid:2 202 m=audio 30004 RTP/AVP 0 203 i=This media stream contains the Spanish translation 204 a=mid:3 206 Camarillo/Holler/Eriksson/Schulzrinne 4 207 Grouping of media lines in SDP 209 Note that although the third media stream is not present in the 210 group line it still MUST contain an mid attribute (mid:3), as stated 211 before. 213 7. Flow Identification (FID) 215 An "m" line in an SDP session description defines a media stream. 216 However, SDP does not define what a media stream is. This definition 217 can be found in the RTSP specification. The RTSP RFC [3] defines a 218 media stream as "a single media instance, e.g., an audio stream or a 219 video stream as well as a single whiteboard or shared application 220 group. When using RTP, a stream consists of all RTP and RTCP packets 221 created by a source within an RTP session". 223 This definition assumes that a single audio (or video) stream maps 224 into an RTP session. The RTP RFC [4] defines an RTP session as 225 follows: "For each participant, the session is defined by a 226 particular pair of destination transport addresses (one network 227 address plus a port pair for RTP and RTCP)". 229 While the previous definitions cover the most common cases, there 230 are situations where a single media instance, (e.g., an audio stream 231 or a video stream) is sent using more than one RTP session. Two 232 examples (among many others) of this kind of situation are cellular 233 systems using SIP [5] and systems receiving DTMF tones on a 234 different host than the voice. 236 7.1 SIP and cellular access 238 Systems using a cellular access and SIP as a signalling protocol 239 need to receive media over the air. During a session the media can 240 be encoded using different codecs. The encoded media has to traverse 241 the radio interface. The radio interface is generally characterized 242 by being bit error prone and associated with relatively high packet 243 transfer delays. In addition, radio interface resources in a 244 cellular environment are scarce and thus expensive, which calls for 245 special measures in providing a highly efficient transport. In order 246 to get an appropriate speech quality in combination with an 247 efficient transport, precise knowledge of codec properties are 248 required so that a proper radio bearer for the RTP session can be 249 configured before transferring the media. These radio bearers are 250 dedicated bearers per media type, i.e. codec. 252 Cellular systems typically configure different radio bearers on 253 different port numbers. Therefore, incoming media has to have 254 different destination port numbers for the different possible codecs 255 in order to be routed properly to the correct radio bearer. Thus, 256 this is an example in which several RTP sessions are used to carry a 257 single media instance (the encoded speech from the sender). 259 Camarillo/Holler/Eriksson/Schulzrinne 5 260 Grouping of media lines in SDP 262 7.2 DTMF tones 264 Some voice sessions include DTMF tones. Sometimes the voice handling 265 is performed by a different host than the DTMF handling. It is 266 common to have an application server in the network gathering DTMF 267 tones for the user while the user receives the encoded speech on his 268 user agent. In this situations it is necessary to establish two RTP 269 sessions: one for the voice and the other for the DTMF tones. Both 270 RTP sessions are logically part of the same media instance. 272 7.3 Media flow definition 274 The previous examples show that the definition of a media stream in 275 [3] do not cover some scenarios. It cannot be assumed that a single 276 media instance maps into a single RTP session. Therefore, we 277 introduce the definition of a media flow: 279 Media flow consists of a single media instance, e.g., an audio 280 stream or a video stream as well as a single whiteboard or shared 281 application group. When using RTP, a media flow comprises one or 282 more RTP sessions. 284 7.4 FID semantics 286 Several "m" lines grouped together using FID semantics form a media 287 flow. A media agent handling a media flow that comprises several "m" 288 lines MUST send a copy of the media to every "m" line part of the 289 flow as long as the codecs and the direction attribute present in a 290 particular "m" line allow it. 292 It is assumed that the application uses only one codec at a time to 293 encode the media produced. This codec MAY change dynamically during 294 the session, but at any certain moment only one codec is in use. 296 The application encodes the media using the current codec and checks 297 one by one all the "m" lines that are part of the flow. If a 298 particular "m" line contains the codec being used and the direction 299 attribute is "sendonly" or "sendrecv" a copy of the encoded media is 300 sent to the address/port specified in that particular media stream. 301 If either the "m" line does not contain the codec being used or the 302 direction attribute is neither "sendonly" nor "sendrecv" nothing is 303 sent over this media stream. 305 The application typically ends up sending media to different 306 destinations (IP address/port number) depending on the codec used at 307 any moment. 309 7.4.1 Examples of FID 311 The session description below would be the SDP sent by a SIP user 312 agent using a cellular access. The user agent supports GSM on port 313 30000 and AMR on port 30002. When the remote party sends GSM it will 314 send RTP packets to port number 30000. When AMR is the codec chosen, 316 Camarillo/Holler/Eriksson/Schulzrinne 6 317 Grouping of media lines in SDP 319 packets will be sent to port 30002. Note that the remote party can 320 switch between both codecs dynamically in the middle of the session. 321 However, in this example, only one media stream at a time carries 322 voice. The other remains "muted" while its corresponding codec is 323 not in use. 325 v=0 326 o=Laura 289083124 289083124 IN IP4 two.example.com 327 t=0 0 328 c=IN IP4 131.160.1.112 329 a=group:FID 1 2 330 m=audio 30000 RTP/AVP 3 331 a=rtpmap:3 GSM/8000 332 a=mid:1 333 m=audio 30002 RTP/AVP 97 334 a=rtpmap:97 AMR/8000 335 a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; mode-change- 336 neighbor; maxframes=1 337 a=mid:2 339 In the previous example a system receives media on the same IP 340 address on different port numbers. The following example shows how a 341 system can receive different codecs on different IP addresses. 343 v=0 344 o=Laura 289083124 289083124 IN IP4 three.example.com 345 t=0 0 346 c=IN IP4 131.160.1.112 347 a=group:FID 1 2 348 m=audio 20000 RTP/AVP 0 349 c=IN IP4 131.160.1.111 350 a=rtpmap:0 PCMU/8000 351 a=mid:1 352 m=audio 30002 RTP/AVP 97 353 a=rtpmap:97 AMR/8000 354 a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; mode-change- 355 neighbor; maxframes=1 356 a=mid:2 358 The cellular terminal of this example only supports the AMR codec. 359 However, many current IP phones only support PCM (payload 0). In 360 order to be able to interoperate with them, the cellular terminal 361 uses a transcoder whose IP address is 131.160.1.111. The cellular 362 terminal includes in its SDP support for PCM at that IP address. 363 Remote systems will send AMR directly to the terminal but PCM will 364 be sent to the transcoder. The transcoder will be configured (using 365 whatever method) to convert the incoming PCM audio to AMR and send 366 it to the terminal. 368 The next example shows that the "group" attribute used with FID 369 semantics allows to express uni-directional codecs for a bi- 370 directional media flow. That is, a codec that is only used in one 371 direction within a sendrecv media stream. 373 Camarillo/Holler/Eriksson/Schulzrinne 7 374 Grouping of media lines in SDP 376 v=0 377 o=Laura 289083124 289083124 IN IP4 four.example.com 378 t=0 0 379 c=IN IP4 131.160.1.112 380 a=group:FID 1 2 381 m=audio 30000 RTP/AVP 0 382 a=mid:1 383 m=audio 30002 RTP/AVP 8 384 a=recvonly 385 a=mid:2 387 A user agent that receives the SDP above knows that at a certain 388 moment it can send either PCM u-law to port number 30000 or PCM A- 389 law to port number 30002. However, the media agent also knows that 390 the other end will only send PCM u-law (payload 0). 392 The following example shows a session description with different "m" 393 lines grouped together using FID semantics that contain the same 394 codec. 396 v=0 397 o=Laura 289083124 289083124 IN IP4 five.example.com 398 t=0 0 399 c=IN IP4 131.160.1.112 400 a=group:FID 1 2 3 401 m=audio 30000 RTP/AVP 0 402 a=mid:1 403 m=audio 30002 RTP/AVP 8 404 a=mid:2 405 m=audio 20000 RTP/AVP 0 8 406 c=IN IP4 131.160.1.111 407 a=recvonly 408 a=mid:3 410 At a particular point of time, if the media agent is sending PCM u- 411 law (payload 0) it sends RTP packets to 131.160.1.112 on port 30000 412 and to 131.160.1.111 on port 20000 (first and third "m" lines). If 413 it is sending PCM A-law (payload 8) it sends RTP packets to 414 131.160.1.112 on port 30002 and to 131.160.1.111 on port 20000 415 (second and third "m" lines). 417 The system that generated the SDP above supports PCM u-law on port 418 30000 and PCM A-law on port 30002. Besides, it uses an application 419 server whose IP address is 131.160.1.111 that records all the 420 conversation. That is why the application server always receives a 421 copy of the audio stream regardless of the codec being used at any 422 given moment (it actually performs an RTP dump, so it can 423 effectively receive any codec). 425 Camarillo/Holler/Eriksson/Schulzrinne 8 426 Grouping of media lines in SDP 428 Remember that if several "m" lines grouped together using FID 429 semantics contain the same codec the media agent MUST send media 430 over several RTP sessions at the same time. 432 The last example of this section deals with DTMF tones. DTMF tones 433 can be transmitted using a regular voice codec or can be transmitted 434 as telephony events. The RTP payload for DTMF tones treated as 435 telephone events is described in RFC 2833 [6]. Below there is an 436 example of an SDP session description using FID semantics and this 437 payload type. 439 v=0 440 o=Laura 289083124 289083124 IN IP4 six.example.com 441 t=0 0 442 c=IN IP4 131.160.1.112 443 a=group:FID 1 2 444 m=audio 30000 RTP/AVP 0 445 a=mid:1 446 m=audio 20000 RTP/AVP 97 447 c=IN IP4 131.160.1.111 448 a=rtpmap:97 telephone-events 449 a=mid:2 451 The remote party would send PCM encoded voice (payload 0) to 452 131.160.1.112 and DTMF tones encoded as telephony events to 453 131.160.1.111. Note that only voice or DTMF is sent at a particular 454 point of time. When DTMF tones are sent the first media stream does 455 not carry any data and when voice is sent there is no data in the 456 second media stream. FID semantics provide different destinations 457 for alternative codecs. 459 7.5 Scenarios that FID does not cover 461 It is worthwhile mentioning some scenarios where the "group" 462 attribute using existing semantics (particularly FID) might seem to 463 be applicable but it is not. This section has been included because 464 we have observed some confusion within the community regarding the 465 three scenarios described below. This section helps clarify them. 467 7.5.1 Parallel encoding using different codecs 469 FID semantics are useful when the application only uses one codec at 470 a time. An application that encodes the same media using different 471 codecs simultaneously MUST NOT use FID to group those media lines. 472 Some systems that handle DTMF tones are a typical example of 473 parallel encoding using different codecs. 475 Some systems implement the RTP payload defined in RFC 2833, but when 476 they send DTMF tones they do not mute the voice channel. Therefore, 477 effectively they are sending two copies of the same DTMF tone: 478 encoded as voice and encoded as a telephony event. When the receiver 479 gets both copies it typically uses the telephony event rather than 480 the tone encoded as voice. FID semantics MUST NOT be used in this 482 Camarillo/Holler/Eriksson/Schulzrinne 9 483 Grouping of media lines in SDP 485 context to group both media streams since such a system is not using 486 alternative codecs but rather different parallel encodings for the 487 same information. 489 7.5.2 Layered encoding 491 Layered encoding schemes encode media in different layers. Quality 492 at the receiver varies depending on the number of layers received. 493 SDP provides a means to group together contiguous multicast 494 addresses that transport different layers. The "c" line below: 496 c=IN IP4 224.2.1.1/127/3 498 is equivalent to the following three "c" lines: 500 c=IN IP4 224.2.1.1/127 501 c=IN IP4 224.2.1.2/127 502 c=IN IP4 224.2.1.3/127 504 FID MUST NOT be used to group "m" lines that do not represent the 505 same information. Therefore, FID MUST NOT be used to group "m" lines 506 that contain the different layers of layered encoding scheme. 507 Besides, we do not define new group semantics to provide a more 508 flexible way of grouping different layers because the already 509 existing SDP mechanism covers the most useful scenarios. 511 7.5.3 Same IP address and port number 513 If several codecs have to be sent to the same IP address and port, 514 the traditional SDP syntax of listing several codecs in the same "m" 515 line MUST be used. FID MUST NOT be used to group "m" lines with the 516 same IP address/port. Therefore, an SDP like the one below MUST NOT 517 be generated. 519 v=0 520 o=Laura 289083124 289083124 IN IP4 six.example.com 521 t=0 0 522 c=IN IP4 131.160.1.112 523 a=group:FID 1 2 524 m=audio 30000 RTP/AVP 0 525 a=mid:1 526 m=audio 30000 RTP/AVP 8 527 a=mid:2 529 The correct SDP for the session above would be the following one: 531 v=0 532 o=Laura 289083124 289083124 IN IP4 six.example.com 533 t=0 0 534 c=IN IP4 131.160.1.112 535 m=audio 30000 RTP/AVP 0 8 537 Camarillo/Holler/Eriksson/Schulzrinne 10 538 Grouping of media lines in SDP 540 If two "m" lines are grouped using FID they MUST differ in their 541 transport addresses (i.e., IP address plus port). 543 8. Usage of the "group" attribute in SIP 545 SDP descriptions are used by several different protocols, SIP among 546 them. We include a section about SIP because the "group" attribute 547 will most likely be used mainly by SIP systems. 549 SIP [5] is an application layer protocol for establishing, 550 terminating and modifying multimedia sessions. SIP carries session 551 descriptions in the bodies of the SIP messages but is independent 552 from the protocol used for describing sessions. SDP [2] is one of 553 the protocols that can be used for this purpose. 555 At session establishment SIP provides a three-way handshake (INVITE- 556 200 OK-ACK) between end systems. However, just two of these three 557 messages carry SDP. SDPs MAY be present in INVITE and 200 OK or in 558 200 OK and ACK. The following sections assume that INVITE and 200 OK 559 are the ones carrying SDP for the sake of clarity, but everything is 560 also applicable to the other possible scenario (200 OK and ACK). 562 8.1 Mid value in responses 564 The "mid" attribute is an identifier for a particular media stream. 565 Therefore, the "mid" value in the response MUST be the same as the 566 "mid" value in the request. Besides, subsequent requests such as re- 567 INVITEs SHOULD use the same "mid" value for the already existing 568 media streams. 570 Appendix B of [5] describes the usage of SDP in relation to SIP. It 571 states: "The caller and callee align their media description so that 572 the nth media stream ("m=" line) in the caller�s session description 573 corresponds to the nth media stream in the callee�s description." 575 The presence of the "group" attribute in an SDP session description 576 does not modify this behavior. 578 Since the "mid" attribute provides a means to label "m" lines it 579 would be possible to perform media alignment using "mid" labels 580 rather than matching nth "m" lines. However this would not bring any 581 gain and would add complexity to implementations. Therefore SIP 582 systems MUST perform media alignment matching nth lines regardless 583 of the presence of the "group" or "mid" attributes. 585 If a media stream that contained a particular "mid" identifier in 586 the request contains a different identifier in the response the 587 application ignores all the "mid" and "group" lines that might 588 appear in the session description. The following example illustrates 589 this scenario: 591 Camarillo/Holler/Eriksson/Schulzrinne 11 592 Grouping of media lines in SDP 594 8.1.1 Example 596 Two SIP entities exchange SDPs during session establishment. The 597 INVITE contained the SDP below: 599 v=0 600 o=Laura 289083124 289083124 IN IP4 seven.example.com 601 t=0 0 602 c=IN IP4 131.160.1.112 603 a=group:FID 1 2 604 m=audio 30000 RTP/AVP 0 8 605 a=mid:1 606 m=audio 30002 RTP/AVP 0 8 607 a=mid:2 609 The 200 OK response contains the following SDP: 611 v=0 612 o=Bob 289083122 289083122 IN IP4 eigth.example.com 613 t=0 0 614 c=IN IP4 131.160.1.113 615 a=group:FID 1 2 616 m=audio 25000 RTP/AVP 0 8 617 a=mid:2 618 m=audio 25002 RTP/AVP 0 8 619 a=mid:1 621 Since alignment of "m" lines is performed based on matching of nth 622 lines, the first stream had "mid:1" in the INVITE and "mid:2" in the 623 200 OK. Therefore, the application MUST ignore every "mid" and 624 "group" lines contained in the SDP. 626 A well-behaved SIP user agent would have returned the SDP below in 627 the 200 OK: 629 v=0 630 o=Bob 289083122 289083122 IN IP4 nine.example.com 631 t=0 0 632 c=IN IP4 131.160.1.113 633 a=group:FID 1 2 634 m=audio 25002 RTP/AVP 0 8 635 a=mid:1 636 m=audio 25000 RTP/AVP 0 8 637 a=mid:2 639 8.2 Group value in responses 641 A SIP entity that receives a request that contains an "a=group" line 642 with semantics that it does not understand MUST return a response 643 without the "group" line. Note that, as it was described in the 644 previous section, the "mid" lines MUST still be present in the 645 response. 647 Camarillo/Holler/Eriksson/Schulzrinne 12 648 Grouping of media lines in SDP 650 A SIP entity that receives a request that contains an "a=group" line 651 which semantics that are understood MUST return a response that 652 contains an "a=group" line with the same semantics. The 653 identification-tags contained in this "a=group" lines MUST be the 654 same that were received in the request or a subset of them (zero 655 identification-tags is a valid subset). When the identification-tags 656 in the response are a subset the "group" value to be used in the 657 session MUST be the one present in the response. 659 SIP entities refuse media streams by setting the port to zero in the 660 corresponding "m" line. "a=group" lines MUST NOT contain 661 identification-tags that correspond to "m" lines with port zero. 663 Note that grouping of m lines MUST always be requested by the issuer 664 of the request (the client), never by the issuer of the response 665 (the server). Since SIP provides a two-way SDP exchange, a server 666 that requested grouping in a response would not know whether the 667 "group" attribute was accepted by the client or not. A server that 668 wants to group media lines SHOULD issue another request after having 669 responded to the first one (a re-INVITE for instance). 671 Note that, as we mentioned previously, in this section we are 672 assuming that the SDPs are present in the INVITE and in the 200 673 OK. Applying the statement above to the scenario where SDPs are 674 present in the 200 OK and in the ACK, the entity requesting 675 grouping would be the server. 677 8.2.1 Example 679 The example below shows how the callee refuses a media stream 680 offered by the caller by setting its port number to zero. The "mid" 681 value corresponding to that media stream is removed from the "group" 682 value in the response. 684 SDP in the INVITE from caller to callee: 686 v=0 687 o=Laura 289083124 289083124 IN IP4 ten.example.com 688 t=0 0 689 c=IN IP4 131.160.1.112 690 a=group:FID 1 2 3 691 m=audio 30000 RTP/AVP 0 692 a=mid:1 693 m=audio 30002 RTP/AVP 8 694 a=mid:2 695 m=audio 30004 RTP/AVP 3 696 a=mid:3 698 SDP in the INVITE from callee to caller: 700 v=0 701 o=Bob 289083125 289083125 IN IP4 eleven.example.com 703 Camarillo/Holler/Eriksson/Schulzrinne 13 704 Grouping of media lines in SDP 706 t=0 0 707 c=IN IP4 131.160.1.113 708 a=group:FID 1 3 709 m=audio 20000 RTP/AVP 0 710 a=mid:1 711 m=audio 0 RTP/AVP 8 712 a=mid:2 713 m=audio 20002 RTP/AVP 3 714 a=mid:3 716 8.3 Capability negotiation 718 A client that understands "group" and "mid" but does not want to 719 make use of them in a particular session MAY want indicate that it 720 supports them. If a client decides to do that, it SHOULD add an 721 "a=group" line with zero identification-tags for every semantics it 722 understands. 724 If a server receives a request that contains empty "a=group" lines 725 it SHOULD add its capabilities also in the form of empty "a=group" 726 lines to its response. 728 8.3.1 Example 730 A system that supports both LS and FID semantics but does not want 731 to group any media stream for this particular session generates the 732 following SDP: 734 v=0 735 o=Bob 289083125 289083125 IN IP4 twelve.example.com 736 t=0 0 737 c=IN IP4 131.160.1.113 738 a=group:LS 739 a=group:FID 740 m=audio 20000 RTP/AVP 0 8 742 The server that receives that request supports FID but not LS. It 743 responds with the SDP below: 745 v=0 746 o=Laura 289083124 289083124 IN IP4 thirteen.example.com 747 t=0 0 748 c=IN IP4 131.160.1.112 749 a=group:FID 750 m=audio 30000 RTP/AVP 0 752 8.4 Backward compatibility 754 This document does not define any SIP "Require" header. Therefore, 755 if one of the SIP user agents does not understand the "group" 757 Camarillo/Holler/Eriksson/Schulzrinne 14 758 Grouping of media lines in SDP 760 attribute the standard SDP fall back mechanism MUST be used 761 (attributes that are not understood are simply ignored). 763 8.4.1 Client does not support "group" 765 This situation does not represent a problem because grouping 766 requests is always performed by clients, not by servers. If the 767 client does not support "group" this attribute will just not be 768 used. 770 8.4.2 Server does not support "group" 772 The server will ignore the "group" attribute, since it does not 773 understand it (it will also ignore the "mid" attribute). For LS 774 semantics, the server might decide to perform or to not perform 775 synchronization between media streams. 777 For FID semantics, the server will consider that the session 778 comprises several media streams. 780 Different implementations would behave in different ways. 782 In the case of audio and different "m" lines for different codecs an 783 implementation might decide to act as a mixer with the different 784 incoming RTP sessions, which is the correct behavior. 786 An implementation might also decide to refuse the request (e.g. 488 787 Not acceptable here or 606 Not Acceptable) because it contains 788 several "m" lines. In this case, the server does not support the 789 type of session that the caller wanted to establish. In case the 790 client is willing to establish a simpler session anyway, he SHOULD 791 re-try the request without "group" attribute and only one "m" line 792 per flow. 794 9. IANA considerations 796 This document defines two SDP attributes: "mid" and "group". 798 The "mid" attribute is used to identify media streams within a 799 session description and its format is defined in Section 3. 801 The "group" attribute is used for grouping together different media 802 streams and its format is defined in Section 4. 804 Section 4 also defines two standard semantics related to the "group" 805 attribute: LS (Lip Synchronization) and FID (Flow Identification). 806 If in the future it was needed to standardize further semantics they 807 would need to be defined in a standards track document. 809 Camarillo/Holler/Eriksson/Schulzrinne 15 810 Grouping of media lines in SDP 812 10. Acknowledgments 814 The authors would like to thank Jonathan Rosenberg, Adam Roach, Orit 815 Levin and Joerg Ott for their feedback on this document. 817 11. References 819 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 820 Levels", RFC 2119, IETF; March 1997. 822 [2] M. Handley/V. Jacobson, "SDP: Session Description Protocol", RFC 823 2327, IETF; April 1998. 825 [3] H. Schulzrinne/A. Rao/R. Lanphier, "Real Time Streaming Protocol 826 (RTSP)", RFC 2326, IETF; April 1998. 828 [4] H. Schulzrinne/S. Casner/R. Frederick/V. Jacobson, "RTP: A 829 Transport Protocol for Real-Time Applications", RFC 1889, IETF; 830 January 1996. 832 [5] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: 833 Session Initiation Protocol", RFC 2543, IETF; Mach 1999. 835 [6] H. Schulzrinne/S. Petrack, "RTP Payload for DTMF Digits, 836 Telephony Tones and Telephony Signals", RFC 2833, IETF; May 2000. 838 12. Authors� Addresses 840 Gonzalo Camarillo 841 Ericsson 842 Advanced Signalling Research Lab. 843 FIN-02420 Jorvas 844 Finland 845 Phone: +358 9 299 3371 846 Fax: +358 9 299 3052 847 Email: Gonzalo.Camarillo@ericsson.com 849 Jan Holler 850 Ericsson Research 851 S-16480 Stockholm 852 Sweden 853 Phone: +46 8 58532845 854 Fax: +46 8 4047020 855 Email: Jan.Holler@era.ericsson.se 857 Goran AP Eriksson 858 Ericsson Research 859 S-16480 Stockholm 860 Sweden 861 Phone: +46 8 58531762 862 Fax: +46 8 4047020 863 Email: Goran.AP.Eriksson@era.ericsson.se 865 Camarillo/Holler/Eriksson/Schulzrinne 16 866 Grouping of media lines in SDP 868 Henning Schulzrinne 869 Dept. of Computer Science 870 Columbia University 871 1214 Amsterdam Avenue 872 New York, NY 10027 873 USA 874 Email: schulzrinne@cs.columbia.edu 876 Camarillo/Holler/Eriksson/Schulzrinne 17