idnits 2.17.1 draft-ietf-mmusic-rfc3388bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (November 11, 2009) is 5274 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) == Missing Reference: 'RFCxxxx' is mentioned on line 854, but not defined == Missing Reference: 'RFC3524' is mentioned on line 855, but not defined == Missing Reference: 'RFC4091' is mentioned on line 856, but not defined ** Obsolete undefined reference: RFC 4091 (Obsoleted by RFC 5245) == Missing Reference: 'RFC4756' is mentioned on line 857, but not defined ** Obsolete undefined reference: RFC 4756 (Obsoleted by RFC 5956) == Missing Reference: 'RFC5583' is mentioned on line 858, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 3850 (Obsoleted by RFC 5750) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 1889 (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Obsoletes: 3388 (if approved) H. Schulzrinne 5 Intended status: Standards Track Columbia University 6 Expires: May 15, 2010 November 11, 2009 8 The SDP (Session Description Protocol) Grouping Framework 9 draft-ietf-mmusic-rfc3388bis-04.txt 11 Abstract 13 In this specification, we define a framework to group "m" lines in 14 SDP (Session Description Protocol) for different purposes. This 15 framework uses the "group" and "mid" SDP attributes, both of which 16 are defined in this specification. Additionally, we specify how to 17 use the framework for two different purposes: for lip synchronization 18 and for receiving a media flow consisting of several media streams on 19 different transport addresses. This document obsoletes RFC 3388. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on May 15, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 64 4. Media Stream Identification Attribute . . . . . . . . . . . . 4 65 5. Group Attribute . . . . . . . . . . . . . . . . . . . . . . . 4 66 6. Use of "group" and "mid" . . . . . . . . . . . . . . . . . . . 4 67 7. Lip Synchronization (LS) . . . . . . . . . . . . . . . . . . . 5 68 7.1. Example of LS . . . . . . . . . . . . . . . . . . . . . . 5 69 8. Flow Identification (FID) . . . . . . . . . . . . . . . . . . 6 70 8.1. SIP and Cellular Access . . . . . . . . . . . . . . . . . 6 71 8.2. DTMF Tones . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8.3. Media Flow Definition . . . . . . . . . . . . . . . . . . 7 73 8.4. FID Semantics . . . . . . . . . . . . . . . . . . . . . . 7 74 8.4.1. Examples of FID . . . . . . . . . . . . . . . . . . . 8 75 8.5. Scenarios that FID does not Cover . . . . . . . . . . . . 11 76 8.5.1. Parallel Encoding Using Different Codecs . . . . . . . 11 77 8.5.2. Layered Encoding . . . . . . . . . . . . . . . . . . . 12 78 8.5.3. Same IP Address and Port Number . . . . . . . . . . . 12 79 9. Usage of the "group" Attribute in SIP . . . . . . . . . . . . 13 80 9.1. Mid Value in Answers . . . . . . . . . . . . . . . . . . . 13 81 9.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 14 82 9.2. Group Value in Answers . . . . . . . . . . . . . . . . . . 15 83 9.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 15 84 9.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 16 85 9.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 16 86 9.4. Backward Compatibility . . . . . . . . . . . . . . . . . . 17 87 9.4.1. Offerer does not Support "group" . . . . . . . . . . . 17 88 9.4.2. Answerer does not Support "group" . . . . . . . . . . 17 89 10. Changes from RFC 3388 . . . . . . . . . . . . . . . . . . . . 18 90 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 91 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 93 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 14.1. Normative References . . . . . . . . . . . . . . . . . . . 20 95 14.2. Informational References . . . . . . . . . . . . . . . . . 20 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 99 1. Introduction 101 RFC 3388 [RFC3388] specified a media-line grouping framework for SDP 102 (Session Description Protocol) [RFC4566]. This specification 103 obsoletes RFC 3388 [RFC3388]. 105 An SDP [RFC4566] session description typically contains one or more 106 media lines, which are commonly known as "m" lines. When a session 107 description contains more than one "m" line, SDP does not provide any 108 means to express a particular relationship between two or more of 109 them. When an application receives an SDP session description with 110 more than one "m" line, it is up to the application what to do with 111 them. SDP does not carry any information about grouping media 112 streams. 114 While in some environments this information can be carried out of 115 band, it is necessary to have a mechanism in SDP to express how 116 different media streams within a session description relate to each 117 other. The framework defined in this specification is such a 118 mechanism. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 3. Overview of Operation 128 This section provides a non-normative description on how the SDP 129 Grouping Framework defined in this document works. In a given 130 session description, each "m" line is identified by a token, which is 131 carried in an "mid" attribute below the "m" line. The session 132 description carries session-level "group" attributes that group 133 different "m" lines (identified by their tokens) using different 134 group semantics. The semantics of a group describe the purpose for 135 which the "m" lines are grouped. For example, the "group" line in 136 the session description below indicates that the "m" lines identified 137 by tokens 1 and 2 (the audio and the video "m" lines respectively) 138 and group for the purpose of lip synchronization (LS). 140 v=0 141 o=Laura 289083124 289083124 IN IP4 one.example.com 142 t=0 0 143 c=IN IP4 192.0.2.1 144 a=group:LS 1 2 145 m=audio 30000 RTP/AVP 0 146 a=mid:1 147 m=video 30002 RTP/AVP 31 148 a=mid:2 150 4. Media Stream Identification Attribute 152 This document defines the "media stream identification" media 153 attribute, which is used for identifying media streams within a 154 session description. Its formatting in SDP [RFC4566] is described by 155 the following Augmented BNF (Backus-Naur Form) [RFC5234]: 157 mid-attribute = "a=mid:" identification-tag 158 identification-tag = token 159 ; token is defined in RFC 4566 161 The identification tag MUST be unique within an SDP session 162 description. 164 5. Group Attribute 166 This document defines the "group" session-level attribute, which is 167 used for grouping together different media streams. Its formatting 168 in SDP is described by the following Augmented BNF [RFC5234]: 170 group-attribute = "a=group:" semantics 171 *(SP identification-tag) 172 semantics = "LS" / "FID" / semantics-extension 173 semantics-extension = token 174 ; token is defined in RFC 4566 176 This document defines two standard semantics: LS (Lip 177 Synchronization) and FID (Flow Identification). Semantics extensions 178 follow the Standards Action policy [RFC5226]. 180 6. Use of "group" and "mid" 182 All the "m" lines of a session description that uses "group" MUST be 183 identified with a "mid" attribute whether they appear in the group 184 line(s) or not. If a session description contains at least one "m" 185 line that has no "mid" identification the application MUST NOT 186 perform any grouping of media lines. 188 "a=group" lines are used to group together several "m" lines that are 189 identified by their "mid" attribute. "a=group" lines that contain 190 identification-tags that do not correspond to any "m" line within the 191 session description MUST be ignored. The application acts as if the 192 "a=group" line did not exist. The behavior of an application 193 receiving an SDP with grouped "m" lines is defined by the semantics 194 field in the "a=group" line. 196 There MAY be several "a=group" lines in a session description. The 197 "a=group" lines of a session description can use the same or 198 different semantics. An "m" line identified by its "mid" attribute 199 MAY appear in more than one "a=group" line. 201 7. Lip Synchronization (LS) 203 An application that receives a session description that contains "m" 204 lines that are grouped together using LS semantics MUST synchronize 205 the playout of the corresponding media streams. Note that LS 206 semantics not only apply to a video stream that has to be 207 synchronized with an audio stream. The playout of two streams of the 208 same type can be synchronized as well. 210 For RTP streams, synchronization is typically performed using RTCP, 211 which provides enough information to map time stamps from the 212 different streams into a local absolute time value. However, the 213 concept of media stream synchronization MAY also apply to media 214 streams that do not make use of RTP. If this is the case, the 215 application MUST recover the original timing relationship between the 216 streams using whatever available mechanism. 218 7.1. Example of LS 220 The following example shows a session description of a conference 221 that is being multicast. The first media stream (mid:1) contains the 222 voice of the speaker who speaks in English. The second media stream 223 (mid:2) contains the video component and the third (mid:3) media 224 stream carries the translation to Spanish of what he is saying. The 225 first and the second media streams have to be synchronized. 227 v=0 228 o=Laura 289083124 289083124 IN IP4 one.example.com 229 t=0 0 230 c=IN IP4 233.252.0.1/127 231 a=group:LS 1 2 232 m=audio 30000 RTP/AVP 0 233 a=mid:1 234 m=video 30002 RTP/AVP 31 235 a=mid:2 236 m=audio 30004 RTP/AVP 0 237 i=This media stream contains the Spanish translation 238 a=mid:3 240 Note that although the third media stream is not present in the group 241 line, it still has to contain a mid attribute (mid:3), as stated 242 before. 244 8. Flow Identification (FID) 246 An "m" line in an SDP session description defines a media stream. 247 However, SDP does not define what a media stream is. This definition 248 can be found in the RTSP specification. The RTSP RFC [RFC2326] 249 defines a media stream as "a single media instance, e.g., an audio 250 stream or a video stream as well as a single whiteboard or shared 251 application group. When using RTP, a stream consists of all RTP and 252 RTCP packets created by a source within an RTP session". 254 This definition assumes that a single audio (or video) stream maps 255 into an RTP session. The RTP RFC [RFC1889] (at present obsoleted by 256 [RFC3550]) used to define an RTP session as follows: "For each 257 participant, the session is defined by a particular pair of 258 destination transport addresses (one network address plus a port pair 259 for RTP and RTCP)". 261 While the previous definitions cover the most common cases, there are 262 situations where a single media instance, (e.g., an audio stream or a 263 video stream) is sent using more than one RTP session. Two examples 264 (among many others) of this kind of situation are cellular systems 265 using SIP (Session Initiation Protocol; [RFC3261]) and systems 266 receiving DTMF (Dual-Tone Multi-Frequency) tones on a different host 267 than the voice. 269 8.1. SIP and Cellular Access 271 Systems using a cellular access and SIP as a signalling protocol need 272 to receive media over the air. During a session the media can be 273 encoded using different codecs. The encoded media has to traverse 274 the radio interface. The radio interface is generally characterized 275 by being bit error prone and associated with relatively high packet 276 transfer delays. In addition, radio interface resources in a 277 cellular environment are scarce and thus expensive, which calls for 278 special measures in providing a highly efficient transport. In order 279 to get an appropriate speech quality in combination with an efficient 280 transport, precise knowledge of codec properties are required so that 281 a proper radio bearer for the RTP session can be configured before 282 transferring the media. These radio bearers are dedicated bearers 283 per media type (i.e., codec). 285 Cellular systems typically configure different radio bearers on 286 different port numbers. Therefore, incoming media has to have 287 different destination port numbers for the different possible codecs 288 in order to be routed properly to the correct radio bearer. Thus, 289 this is an example in which several RTP sessions are used to carry a 290 single media instance (the encoded speech from the sender). 292 8.2. DTMF Tones 294 Some voice sessions include DTMF tones. Sometimes the voice handling 295 is performed by a different host than the DTMF handling. It is 296 common to have an application server in the network gathering DTMF 297 tones for the user while the user receives the encoded speech on his 298 user agent. In this situations it is necessary to establish two RTP 299 sessions: one for the voice and the other for the DTMF tones. Both 300 RTP sessions are logically part of the same media instance. 302 8.3. Media Flow Definition 304 The previous examples show that the definition of a media stream in 305 [RFC2326] do not cover some scenarios. It cannot be assumed that a 306 single media instance maps into a single RTP session. Therefore, we 307 introduce the definition of a media flow: 309 Media flow consists of a single media instance, e.g., an audio stream 310 or a video stream as well as a single whiteboard or shared 311 application group. When using RTP, a media flow comprises one or 312 more RTP sessions. 314 8.4. FID Semantics 316 Several "m" lines grouped together using FID semantics form a media 317 flow. A media agent handling a media flow that comprises several "m" 318 lines MUST send a copy of the media to every "m" line part of the 319 flow as long as the codecs and the direction attribute present in a 320 particular "m" line allow it. 322 It is assumed that the application uses only one codec at a time to 323 encode the media produced. This codec MAY change dynamically during 324 the session, but at any particular moment only one codec is in use. 326 The application encodes the media using the current codec and checks 327 one by one all the "m" lines that are part of the flow. If a 328 particular "m" line contains the codec being used and the direction 329 attribute is "sendonly" or "sendrecv", a copy of the encoded media is 330 sent to the address/port specified in that particular media stream. 331 If either the "m" line does not contain the codec being used or the 332 direction attribute is neither "sendonly" nor "sendrecv", nothing is 333 sent over this media stream. 335 The application typically ends up sending media to different 336 destinations (IP address/port number) depending on the codec used at 337 any moment. 339 8.4.1. Examples of FID 341 The session description below might be sent by a SIP user agent using 342 a cellular access. The user agent supports GSM (Global System for 343 Mobile communications) on port 30000 and AMR (Adaptive Multi-Rate) on 344 port 30002. When the remote party sends GSM, it will send RTP 345 packets to port number 30000. When AMR is the codec chosen, packets 346 will be sent to port 30002. Note that the remote party can switch 347 between both codecs dynamically in the middle of the session. 348 However, in this example, only one media stream at a time carries 349 voice. The other remains "muted" while its corresponding codec is 350 not in use. 352 v=0 353 o=Laura 289083124 289083124 IN IP4 two.example.com 354 t=0 0 355 c=IN IP4 192.0.2.1 356 a=group:FID 1 2 357 m=audio 30000 RTP/AVP 3 358 a=rtpmap:3 GSM/8000 359 a=mid:1 360 m=audio 30002 RTP/AVP 97 361 a=rtpmap:97 AMR/8000 362 a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; 363 mode-change-neighbor; maxframes=1 364 a=mid:2 366 (The linebreak in the fmtp line accommodates RFC formatting 367 restrictions; SDP does not have continuation lines.) 368 In the previous example, a system receives media on the same IP 369 address on different port numbers. The following example shows how a 370 system can receive different codecs on different IP addresses. 372 v=0 373 o=Laura 289083124 289083124 IN IP4 three.example.com 374 t=0 0 375 c=IN IP4 192.0.2.1 376 a=group:FID 1 2 377 m=audio 20000 RTP/AVP 0 378 c=IN IP4 192.0.2.2 379 a=rtpmap:0 PCMU/8000 380 a=mid:1 381 m=audio 30002 RTP/AVP 97 382 a=rtpmap:97 AMR/8000 383 a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; 384 mode-change-neighbor; maxframes=1 385 a=mid:2 387 (The linebreak in the fmtp line accomodates RFC formatting 388 restrictions; SDP does not have continuation lines.) 390 The cellular terminal of this example only supports the AMR codec. 391 However, many current IP phones only support PCM (Pulse-Code 392 Modulation; payload 0). In order to be able to interoperate with 393 them, the cellular terminal uses a transcoder whose IP address is 394 192.0.2.2. The cellular terminal includes in its SDP support for PCM 395 at that IP address. Remote systems will send AMR directly to the 396 terminal but PCM will be sent to the transcoder. The transcoder will 397 be configured (using whatever method) to convert the incoming PCM 398 audio to AMR and send it to the terminal. 400 The next example shows how the "group" attribute used with FID 401 semantics can indicate the use of two different codecs in the two 402 directions of a bidirectional media stream. 404 v=0 405 o=Laura 289083124 289083124 IN IP4 four.example.com 406 t=0 0 407 c=IN IP4 192.0.2.1 408 a=group:FID 1 2 409 m=audio 30000 RTP/AVP 0 410 a=mid:1 411 m=audio 30002 RTP/AVP 8 412 a=recvonly 413 a=mid:2 415 A user agent that receives the SDP above knows that at a certain 416 moment it can send either PCM u-law to port number 30000 or PCM A-law 417 to port number 30002. However, the media agent also knows that the 418 other end will only send PCM u-law (payload 0). 420 The following example shows a session description with different "m" 421 lines grouped together using FID semantics that contain the same 422 codec. 424 v=0 425 o=Laura 289083124 289083124 IN IP4 five.example.com 426 t=0 0 427 c=IN IP4 192.0.2.1 428 a=group:FID 1 2 3 429 m=audio 30000 RTP/AVP 0 430 a=mid:1 431 m=audio 30002 RTP/AVP 8 432 a=mid:2 433 m=audio 20000 RTP/AVP 0 8 434 c=IN IP4 192.0.2.2 435 a=recvonly 436 a=mid:3 438 At a particular point in time, if the media agent is sending PCM u- 439 law (payload 0), it sends RTP packets to 192.0.2.1 on port 30000 and 440 to 192.0.2.2 on port 20000 (first and third "m" lines). If it is 441 sending PCM A-law (payload 8), it sends RTP packets to 192.0.2.1 on 442 port 30002 and to 192.0.2.2 on port 20000 (second and third "m" 443 lines). 445 The system that generated the SDP above supports PCM u-law on port 446 30000 and PCM A-law on port 30002. Besides, it uses an application 447 server whose IP address is 192.0.2.2 that records the conversation. 448 That is why the application server always receives a copy of the 449 audio stream regardless of the codec being used at any given moment 450 (it actually performs an RTP dump, so it can effectively receive any 451 codec). 453 Remember that if several "m" lines grouped together using FID 454 semantics contain the same codec the media agent MUST send media over 455 several RTP sessions at the same time. 457 The last example of this section deals with DTMF tones. DTMF tones 458 can be transmitted using a regular voice codec or can be transmitted 459 as telephony events. The RTP payload for DTMF tones treated as 460 telephone events is described in [RFC4733]. Below, there is an 461 example of an SDP session description using FID semantics and this 462 payload type. 464 v=0 465 o=Laura 289083124 289083124 IN IP4 six.example.com 466 t=0 0 467 c=IN IP4 192.0.2.1 468 a=group:FID 1 2 469 m=audio 30000 RTP/AVP 0 470 a=mid:1 471 m=audio 20000 RTP/AVP 97 472 c=IN IP4 192.0.2.2 473 a=rtpmap:97 telephone-events 474 a=mid:2 476 The remote party would send PCM encoded voice (payload 0) to 477 192.0.2.1 and DTMF tones encoded as telephony events to 192.0.2.2. 478 Note that only voice or DTMF is sent at a particular point in time. 479 When DTMF tones are sent, the first media stream does not carry any 480 data and, when voice is sent, there is no data in the second media 481 stream. FID semantics provide different destinations for alternative 482 codecs. 484 8.5. Scenarios that FID does not Cover 486 It is worthwhile mentioning some scenarios where the "group" 487 attribute using existing semantics (particularly FID) might seem to 488 be applicable but is not. 490 8.5.1. Parallel Encoding Using Different Codecs 492 FID semantics are useful when the application only uses one codec at 493 a time. An application that encodes the same media using different 494 codecs simultaneously MUST NOT use FID to group those media lines. 495 Some systems that handle DTMF tones are a typical example of parallel 496 encoding using different codecs. 498 Some systems implement the RTP payload defined in RFC 4733 [RFC4733], 499 but when they send DTMF tones they do not mute the voice channel. 500 Therefore, in effect they are sending two copies of the same DTMF 501 tone: encoded as voice and encoded as a telephony event. When the 502 receiver gets both copies, it typically uses the telephony event 503 rather than the tone encoded as voice. FID semantics MUST NOT be 504 used in this context to group both media streams since such a system 505 is not using alternative codecs but rather different parallel 506 encodings for the same information. 508 8.5.2. Layered Encoding 510 Layered encoding schemes encode media in different layers. Quality 511 at the receiver varies depending on the number of layers received. 512 SDP provides a means to group together contiguous multicast addresses 513 that transport different layers. The "c" line below: 515 c=IN IP4 233.252.0.1/127/3 517 is equivalent to the following three "c" lines: 519 c=IN IP4 233.252.0.1/127 520 c=IN IP4 233.252.0.2/127 521 c=IN IP4 233.252.0.3/127 523 FID MUST NOT be used to group "m" lines that do not represent the 524 same information. Therefore, FID MUST NOT be used to group "m" lines 525 that contain the different layers of layered encoding scheme. 526 Besides, we do not define new group semantics to provide a more 527 flexible way of grouping different layers because the already 528 existing SDP mechanism covers the most useful scenarios. 530 8.5.3. Same IP Address and Port Number 532 If several codecs have to be sent to the same IP address and port, 533 the traditional SDP syntax of listing several codecs in the same "m" 534 line MUST be used. FID MUST NOT be used to group "m" lines with the 535 same IP address/port. Therefore, an SDP like the one below MUST NOT 536 be generated. 538 v=0 539 o=Laura 289083124 289083124 IN IP4 six.example.com 540 t=0 0 541 c=IN IP4 192.0.2.1 542 a=group:FID 1 2 543 m=audio 30000 RTP/AVP 0 544 a=mid:1 545 m=audio 30000 RTP/AVP 8 546 a=mid:2 548 The correct SDP for the session above would be the following one: 550 v=0 551 o=Laura 289083124 289083124 IN IP4 six.example.com 552 t=0 0 553 c=IN IP4 192.0.2.1 554 m=audio 30000 RTP/AVP 0 8 556 If two "m" lines are grouped using FID they MUST differ in their 557 transport addresses (i.e., IP address plus port). 559 9. Usage of the "group" Attribute in SIP 561 SDP descriptions are used by several different protocols, SIP among 562 them. We include a section about SIP because the "group" attribute 563 will most likely be used mainly by SIP systems. 565 SIP [RFC3261] is an application layer protocol for establishing, 566 terminating and modifying multimedia sessions. SIP carries session 567 descriptions in the bodies of the SIP messages but is independent 568 from the protocol used for describing sessions. SDP [RFC4566] is one 569 of the protocols that can be used for this purpose. 571 At session establishment SIP provides a three-way handshake (INVITE- 572 200 OK-ACK) between end systems. However, just two of these three 573 messages carry SDP, as described in [RFC3264]. 575 9.1. Mid Value in Answers 577 The "mid" attribute is an identifier for a particular media stream. 578 Therefore, the "mid" value in the offer MUST be the same as the "mid" 579 value in the answer. Besides, subsequent offers (e.g., in a re- 580 INVITE) SHOULD use the same "mid" value for the already existing 581 media streams. 583 [RFC3264] describes the usage of SDP in relation to SIP. The offerer 584 and the answerer align their media description so that the nth media 585 stream ("m=" line) in the offerer's session description corresponds 586 to the nth media stream in the answerer's description. 588 The presence of the "group" attribute in an SDP session description 589 does not modify this behavior. 591 Since the "mid" attribute provides a means to label "m" lines, it 592 would be possible to perform media alignment using "mid" labels 593 rather than matching nth "m" lines. However this would not bring any 594 gain and would add complexity to implementations. Therefore SIP 595 systems MUST perform media alignment matching nth lines regardless of 596 the presence of the "group" or "mid" attributes. 598 If a media stream that contained a particular "mid" identifier in the 599 offer contains a different identifier in the answer the application 600 ignores all the "mid" and "group" lines that might appear in the 601 session description. The following example illustrates this 602 scenario. 604 9.1.1. Example 606 Two SIP entities exchange SDPs during session establishment. The 607 INVITE contains the SDP below: 609 v=0 610 o=Laura 289083124 289083124 IN IP4 seven.example.com 611 t=0 0 612 c=IN IP4 192.0.2.1 613 a=group:FID 1 2 614 m=audio 30000 RTP/AVP 0 8 615 a=mid:1 616 m=audio 30002 RTP/AVP 0 8 617 a=mid:2 619 The 200 OK response contains the following SDP: 621 v=0 622 o=Bob 289083122 289083122 IN IP4 eigth.example.com 623 t=0 0 624 c=IN IP4 192.0.2.3 625 a=group:FID 1 2 626 m=audio 25000 RTP/AVP 0 8 627 a=mid:2 628 m=audio 25002 RTP/AVP 0 8 629 a=mid:1 631 Since alignment of "m" lines is performed based on matching of nth 632 lines, the first stream had "mid:1" in the INVITE and "mid:2" in the 633 200 OK. Therefore, the application ignores every "mid" and "group" 634 line contained in the SDP. 636 A well-behaved SIP user agent would have returned the SDP below in 637 the 200 OK: 639 v=0 640 o=Bob 289083122 289083122 IN IP4 nine.example.com 641 t=0 0 642 c=IN IP4 192.0.2.3 643 a=group:FID 1 2 644 m=audio 25002 RTP/AVP 0 8 645 a=mid:1 646 m=audio 25000 RTP/AVP 0 8 647 a=mid:2 649 9.2. Group Value in Answers 651 A SIP entity that receives an offer that contains an "a=group" line 652 with semantics that it does not understand MUST return an answer 653 without the "group" line. Note that, as it was described in the 654 previous section, the "mid" lines MUST still be present in the 655 answer. 657 A SIP entity that receives an offer that contains an "a=group" line 658 with semantics that are understood MUST return an answer that 659 contains an "a=group" line with the same semantics. The 660 identification-tags contained in this "a=group" lines MUST be the 661 same that were received in the offer or a subset of them (zero 662 identification-tags is a valid subset). When the identification-tags 663 in the answer are a subset, the "group" value to be used in the 664 session MUST be the one present in the answer. 666 SIP entities refuse media streams by setting the port to zero in the 667 corresponding "m" line. "a=group" lines MUST NOT contain 668 identification-tags that correspond to "m" lines with port zero. 670 Note that grouping of m lines MUST always be requested by the 671 offerer, never by the answerer. Since SIP provides a two-way SDP 672 exchange, an answerer that requested grouping would not know whether 673 the "group" attribute was accepted by the offerer or not. An 674 answerer that wants to group media lines SHOULD issue another offer 675 after having responded to the first one (in a re-INVITE for 676 instance). 678 9.2.1. Example 680 The example below shows how the callee refuses a media stream offered 681 by the caller by setting its port number to zero. The "mid" value 682 corresponding to that media stream is removed from the "group" value 683 in the answer. 685 SDP in the INVITE from caller to callee: 687 v=0 688 o=Laura 289083124 289083124 IN IP4 ten.example.com 689 t=0 0 690 c=IN IP4 192.0.2.1 691 a=group:FID 1 2 3 692 m=audio 30000 RTP/AVP 0 693 a=mid:1 694 m=audio 30002 RTP/AVP 8 695 a=mid:2 696 m=audio 30004 RTP/AVP 3 697 a=mid:3 699 SDP in the INVITE from callee to caller: 701 v=0 702 o=Bob 289083125 289083125 IN IP4 eleven.example.com 703 t=0 0 704 c=IN IP4 192.0.2.3 705 a=group:FID 1 3 706 m=audio 20000 RTP/AVP 0 707 a=mid:1 708 m=audio 0 RTP/AVP 8 709 a=mid:2 710 m=audio 20002 RTP/AVP 3 711 a=mid:3 713 9.3. Capability Negotiation 715 A client that understands "group" and "mid" but does not want to make 716 use of them in a particular session MAY want to indicate that it 717 supports them. If a client decides to do that, it SHOULD add an 718 "a=group" line with no identification-tags for every semantics value 719 it understands. 721 If a server receives an offer that contains empty "a=group" lines, it 722 SHOULD add its capabilities also in the form of empty "a=group" lines 723 to its answer. 725 9.3.1. Example 727 A system that supports both LS and FID semantics but does not want to 728 group any media stream for this particular session generates the 729 following SDP: 731 v=0 732 o=Bob 289083125 289083125 IN IP4 twelve.example.com 733 t=0 0 734 c=IN IP4 192.0.2.3 735 a=group:LS 736 a=group:FID 737 m=audio 20000 RTP/AVP 0 8 739 The server that receives that offer supports FID but not LS. It 740 responds with the SDP below: 742 v=0 743 o=Laura 289083124 289083124 IN IP4 thirteen.example.com 744 t=0 0 745 c=IN IP4 192.0.2.1 746 a=group:FID 747 m=audio 30000 RTP/AVP 0 749 9.4. Backward Compatibility 751 This document does not define any SIP "Require" header. Therefore, 752 if one of the SIP user agents does not understand the "group" 753 attribute the standard SDP fall back mechanism MUST be used 754 (attributes that are not understood are simply ignored). 756 9.4.1. Offerer does not Support "group" 758 This situation does not represent a problem because grouping requests 759 are always performed by offerers, not by answerers. If the offerer 760 does not support "group" this attribute will just not be used. 762 9.4.2. Answerer does not Support "group" 764 The answerer will ignore the "group" attribute, since it does not 765 understand it (it will also ignore the "mid" attribute). For LS 766 semantics, the answerer might decide to perform or to not perform 767 synchronization between media streams. 769 For FID semantics, the answerer will consider that the session 770 comprises several media streams. 772 Different implementations would behave in different ways. 774 In the case of audio and different "m" lines for different codecs an 775 implementation might decide to act as a mixer with the different 776 incoming RTP sessions, which is the correct behavior. 778 An implementation might also decide to refuse the request (e.g., 488 779 Not acceptable here or 606 Not Acceptable) because it contains 780 several "m" lines. In this case, the server does not support the 781 type of session that the caller wanted to establish. In case the 782 client is willing to establish a simpler session anyway, he SHOULD 783 re-try the request without "group" attribute and only one "m" line 784 per flow. 786 10. Changes from RFC 3388 788 Section 3 (Overview of Operation) has been added for clarity. The 789 AMR and GSM acronyms are now expanded on their first use. The 790 examples now use IP addresses in the range suitable for examples. 792 The grouping mechanism is now defined as an extendible framework. 793 Earlier, RFC 3388 [RFC3388] used to discourage extensions to this 794 mechanism in favor of using new session description protocols. 796 Given a semantics value, RFC 3388 [RFC3388] used to restrict "m" line 797 identifiers to only appear in a single group using that semantics. 798 That restriction has been lifted in this specification. From 799 conversations with implementers, existing (i.e., legacy) 800 implementations enforce this restriction on a per semantics basis. 801 That is, they only enforce this restriction for supported semantics. 802 Because of the nature of existing semantics, implementations will 803 only use a single "m" line identifier across groups using a given 804 semantics even after the restriction has been lifted by this 805 specification. Consequently, the lifting of this restriction will 806 not cause backwards compatibility problems because implementations 807 supporting new semantics will be updated not to enforce this 808 restriction at the same time as they are updated to support the new 809 semantics. 811 11. Security Considerations 813 Using the "group" parameter with FID semantics, an entity that 814 managed to modify the session descriptions exchanged between the 815 participants to establish a multimedia session could force the 816 participants to send a copy of the media to any particular 817 destination. 819 Integrity mechanism provided by protocols used to exchange session 820 descriptions and media encryption can be used to prevent this attack. 821 In SIP, S/MIME [RFC3850] and TLS [RFC5246] can be used to protect 822 session description exchanges in an end-to-end and a hop-by-hop 823 fashion respectively. 825 12. IANA Considerations 827 This document defines two SDP attributes: "mid" and "group". 829 The "mid" attribute is used to identify media streams within a 830 session description and its format is defined in Section 4. 832 The "group" attribute is used for grouping together different media 833 streams and its format is defined in Section 5. 835 This document defines a framework to group media lines in SDP using 836 different semantics. Semantics values to be used with this framework 837 are registered by the IANA following the Standards Action policy 838 [RFC5226]. 840 The IANA Considerations section of the RFC MUST include the following 841 information, which appears in the IANA registry along with the RFC 842 number of the publication. 844 o A brief description of the semantics. 845 o Token to be used within the group attribute. This token may be of 846 any length, but SHOULD be no more than four characters long. 847 o Reference to an standards track RFC. 849 The following are the current entries in the registry: 851 Semantics Token Reference 852 --------------------------------- ----- ----------- 853 Lip Synchronization LS [RFCxxxx] 854 Flow Identification FID [RFCxxxx] 855 Single Reservation flow SRF [RFC3524] 856 Alternative Network Address Types ANAT [RFC4091] 857 Forward Error Correction FEC [RFC4756] 858 Decoding Dependency DDP [RFC5583] 860 [Note to the RFC Editor: please replace RFCxxxx above with the number 861 of this RFC.] 863 13. Acknowledgments 865 Goran Eriksson and Jan Holler were coauthors of RFC 3388 [RFC3388]. 867 14. References 868 14.1. Normative References 870 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 871 Requirement Levels", BCP 14, RFC 2119, March 1997. 873 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 874 Description Protocol", RFC 4566, July 2006. 876 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 877 A., Peterson, J., Sparks, R., Handley, M., and E. 878 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 879 June 2002. 881 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 882 with Session Description Protocol (SDP)", RFC 3264, 883 June 2002. 885 [RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail 886 Extensions (S/MIME) Version 3.1 Certificate Handling", 887 RFC 3850, July 2004. 889 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 890 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 891 May 2008. 893 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 894 Specifications: ABNF", STD 68, RFC 5234, January 2008. 896 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 897 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 899 14.2. Informational References 901 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. 902 Jacobson, "RTP: A Transport Protocol for Real-Time 903 Applications", RFC 1889, January 1996. 905 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 906 Streaming Protocol (RTSP)", RFC 2326, April 1998. 908 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 909 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 910 December 2006. 912 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 913 Schulzrinne, "Grouping of Media Lines in the Session 914 Description Protocol (SDP)", RFC 3388, December 2002. 916 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 917 Jacobson, "RTP: A Transport Protocol for Real-Time 918 Applications", STD 64, RFC 3550, July 2003. 920 Authors' Addresses 922 Gonzalo Camarillo 923 Ericsson 924 Hirsalantie 11 925 Jorvas 02420 926 Finland 928 Email: Gonzalo.Camarillo@ericsson.com 930 Henning Schulzrinne 931 Columbia University 932 1214 Amsterdam Avenue 933 New York, NY 10027 934 USA 936 Email: schulzrinne@cs.columbia.edu