idnits 2.17.1 draft-ietf-mmusic-rfc3388bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- == 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 -- 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? -- The draft header indicates that this document obsoletes RFC3388, but the abstract doesn't seem to mention this, which it should. 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 (July 13, 2009) is 5400 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 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 3850 (Obsoleted by RFC 5750) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) -- 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 2833 (Obsoleted by RFC 4733, RFC 4734) -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 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) July 13, 2009 5 Intended status: Standards Track 6 Expires: January 14, 2010 8 The SDP (Session Description Protocol) Grouping Framework 9 draft-ietf-mmusic-rfc3388bis-03.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 14, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 In this specification, we define a framework to group "m" lines in 48 SDP (Session Description Protocol) for different purposes. This 49 framework uses the "group" and "mid" SDP attributes, both of which 50 are defined in this specification. Additionally, we specify how to 51 use the framework for two different purposes: for lip synchronization 52 and for receiving a media flow consisting of several media streams on 53 different transport addresses. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 60 4. Media Stream Identification Attribute . . . . . . . . . . . . 4 61 5. Group Attribute . . . . . . . . . . . . . . . . . . . . . . . 4 62 6. Use of "group" and "mid" . . . . . . . . . . . . . . . . . . . 4 63 7. Lip Synchronization (LS) . . . . . . . . . . . . . . . . . . . 5 64 7.1. Example of LS . . . . . . . . . . . . . . . . . . . . . . 5 65 8. Flow Identification (FID) . . . . . . . . . . . . . . . . . . 6 66 8.1. SIP and Cellular Access . . . . . . . . . . . . . . . . . 6 67 8.2. DTMF Tones . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8.3. Media Flow Definition . . . . . . . . . . . . . . . . . . 7 69 8.4. FID Semantics . . . . . . . . . . . . . . . . . . . . . . 7 70 8.4.1. Examples of FID . . . . . . . . . . . . . . . . . . . 8 71 8.5. Scenarios that FID does not Cover . . . . . . . . . . . . 11 72 8.5.1. Parallel Encoding Using Different Codecs . . . . . . . 11 73 8.5.2. Layered Encoding . . . . . . . . . . . . . . . . . . . 11 74 8.5.3. Same IP Address and Port Number . . . . . . . . . . . 12 75 9. Usage of the "group" Attribute in SIP . . . . . . . . . . . . 13 76 9.1. Mid Value in Answers . . . . . . . . . . . . . . . . . . . 13 77 9.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 14 78 9.2. Group Value in Answers . . . . . . . . . . . . . . . . . . 15 79 9.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 15 80 9.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 16 81 9.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 16 82 9.4. Backward Compatibility . . . . . . . . . . . . . . . . . . 17 83 9.4.1. Offerer does not Support "group" . . . . . . . . . . . 17 84 9.4.2. Answerer does not Support "group" . . . . . . . . . . 17 85 10. Changes from RFC 3388 . . . . . . . . . . . . . . . . . . . . 18 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 90 13.2. Informational References . . . . . . . . . . . . . . . . . 19 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 1. Introduction 95 An SDP [RFC4566] session description typically contains one or more 96 media lines, which are commonly known as "m" lines. When a session 97 description contains more than one "m" line, SDP does not provide any 98 means to express a particular relationship between two or more of 99 them. When an application receives an SDP session description with 100 more than one "m" line, it is up to the application what to do with 101 them. SDP does not carry any information about grouping media 102 streams. 104 While in some environments this information can be carried out of 105 band, it is necessary to have a mechanism in SDP to express how 106 different media streams within a session description relate to each 107 other. The framework defined in this specification is such a 108 mechanism. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Overview of Operation 118 This section provides a non-normative description on how the SDP 119 Grouping Framework defined in this document works. In a given 120 session description, each "m" line is identified by a token, which is 121 carried in an "mid" attribute below the "m" line. The session 122 description carries session-level "group" attributes that group 123 different "m" lines (identified by their tokens) using different 124 group semantics. The semantics of a group describe the purpose for 125 which the "m" lines are grouped. For example, the "group" line in 126 the session description below indicates that the "m" lines identified 127 by tokens 1 and 2 (the audio and the video "m" lines respectively) 128 and group for the purpose of lip synchronization (LS). 130 v=0 131 o=Laura 289083124 289083124 IN IP4 one.example.com 132 t=0 0 133 c=IN IP4 192.0.2.1 134 a=group:LS 1 2 135 m=audio 30000 RTP/AVP 0 136 a=mid:1 137 m=video 30002 RTP/AVP 31 138 a=mid:2 140 4. Media Stream Identification Attribute 142 A new "media stream identification" media attribute is defined. It 143 is used for identifying media streams within a session description. 144 Its formatting in SDP [RFC4566] is described by the following BNF 145 (Backus-Naur Form): 147 mid-attribute = "a=mid:" identification-tag 148 identification-tag = token 150 The identification tag MUST be unique within an SDP session 151 description. 153 5. Group Attribute 155 A new "group" session-level attribute is defined. It is used for 156 grouping together different media streams. Its formatting in SDP is 157 described by the following BNF: 159 group-attribute = "a=group:" semantics 160 *(space identification-tag) 161 semantics = "LS" / "FID" / semantics-extension 162 semantics-extension = token 164 This document defines two standard semantics: LS (Lip 165 Synchronization) and FID (Flow Identification). Further semantics 166 MUST be defined in a standards-track document. 168 6. Use of "group" and "mid" 170 All the "m" lines of a session description that uses "group" MUST be 171 identified with a "mid" attribute whether they appear in the group 172 line(s) or not. If a session description contains at least one "m" 173 line that has no "mid" identification the application MUST NOT 174 perform any grouping of media lines. 176 "a=group" lines are used to group together several "m" lines that are 177 identified by their "mid" attribute. "a=group" lines that contain 178 identification-tags that do not correspond to any "m" line within the 179 session description MUST be ignored. The application acts as if the 180 "a=group" line did not exist. The behavior of an application 181 receiving an SDP with grouped "m" lines is defined by the semantics 182 field in the "a=group" line. 184 There MAY be several "a=group" lines in a session description. The 185 "a=group" lines of a session description can use the same or 186 different semantics. An "m" line identified by its "mid" attribute 187 MAY appear in more than one "a=group" line. 189 7. Lip Synchronization (LS) 191 An application that receives a session description that contains "m" 192 lines that are grouped together using LS semantics MUST synchronize 193 the playout of the corresponding media streams. Note that LS 194 semantics not only apply to a video stream that has to be 195 synchronized with an audio stream. The playout of two streams of the 196 same type can be synchronized as well. 198 For RTP streams, synchronization is typically performed using RTCP, 199 which provides enough information to map time stamps from the 200 different streams into a wall clock. However, the concept of media 201 stream synchronization MAY also apply to media streams that do not 202 make use of RTP. If this is the case, the application MUST recover 203 the original timing relationship between the streams using whatever 204 available mechanism. 206 7.1. Example of LS 208 The following example shows a session description of a conference 209 that is being multicast. The first media stream (mid:1) contains the 210 voice of the speaker who speaks in English. The second media stream 211 (mid:2) contains the video component and the third (mid:3) media 212 stream carries the translation to Spanish of what he is saying. The 213 first and the second media streams have to be synchronized. 215 v=0 216 o=Laura 289083124 289083124 IN IP4 one.example.com 217 t=0 0 218 c=IN IP4 224.2.17.12/127 219 a=group:LS 1 2 220 m=audio 30000 RTP/AVP 0 221 a=mid:1 222 m=video 30002 RTP/AVP 31 223 a=mid:2 224 m=audio 30004 RTP/AVP 0 225 i=This media stream contains the Spanish translation 226 a=mid:3 228 Note that although the third media stream is not present in the group 229 line, it still has to contain a mid attribute (mid:3), as stated 230 before. 232 8. Flow Identification (FID) 234 An "m" line in an SDP session description defines a media stream. 235 However, SDP does not define what a media stream is. This definition 236 can be found in the RTSP specification. The RTSP RFC [RFC2326] 237 defines a media stream as "a single media instance, e.g., an audio 238 stream or a video stream as well as a single whiteboard or shared 239 application group. When using RTP, a stream consists of all RTP and 240 RTCP packets created by a source within an RTP session". 242 This definition assumes that a single audio (or video) stream maps 243 into an RTP session. The RTP RFC [RFC1889] (at present obsoleted by 244 [RFC3550]) used to define an RTP session as follows: "For each 245 participant, the session is defined by a particular pair of 246 destination transport addresses (one network address plus a port pair 247 for RTP and RTCP)". 249 While the previous definitions cover the most common cases, there are 250 situations where a single media instance, (e.g., an audio stream or a 251 video stream) is sent using more than one RTP session. Two examples 252 (among many others) of this kind of situation are cellular systems 253 using SIP (Session Initiation Protocol; [RFC3261]) and systems 254 receiving DTMF (Dual-Tone Multi-Frequency) tones on a different host 255 than the voice. 257 8.1. SIP and Cellular Access 259 Systems using a cellular access and SIP as a signalling protocol need 260 to receive media over the air. During a session the media can be 261 encoded using different codecs. The encoded media has to traverse 262 the radio interface. The radio interface is generally characterized 263 by being bit error prone and associated with relatively high packet 264 transfer delays. In addition, radio interface resources in a 265 cellular environment are scarce and thus expensive, which calls for 266 special measures in providing a highly efficient transport. In order 267 to get an appropriate speech quality in combination with an efficient 268 transport, precise knowledge of codec properties are required so that 269 a proper radio bearer for the RTP session can be configured before 270 transferring the media. These radio bearers are dedicated bearers 271 per media type (i.e., codec). 273 Cellular systems typically configure different radio bearers on 274 different port numbers. Therefore, incoming media has to have 275 different destination port numbers for the different possible codecs 276 in order to be routed properly to the correct radio bearer. Thus, 277 this is an example in which several RTP sessions are used to carry a 278 single media instance (the encoded speech from the sender). 280 8.2. DTMF Tones 282 Some voice sessions include DTMF tones. Sometimes the voice handling 283 is performed by a different host than the DTMF handling. It is 284 common to have an application server in the network gathering DTMF 285 tones for the user while the user receives the encoded speech on his 286 user agent. In this situations it is necessary to establish two RTP 287 sessions: one for the voice and the other for the DTMF tones. Both 288 RTP sessions are logically part of the same media instance. 290 8.3. Media Flow Definition 292 The previous examples show that the definition of a media stream in 293 [RFC2326] do not cover some scenarios. It cannot be assumed that a 294 single media instance maps into a single RTP session. Therefore, we 295 introduce the definition of a media flow: 297 Media flow consists of a single media instance, e.g., an audio stream 298 or a video stream as well as a single whiteboard or shared 299 application group. When using RTP, a media flow comprises one or 300 more RTP sessions. 302 8.4. FID Semantics 304 Several "m" lines grouped together using FID semantics form a media 305 flow. A media agent handling a media flow that comprises several "m" 306 lines MUST send a copy of the media to every "m" line part of the 307 flow as long as the codecs and the direction attribute present in a 308 particular "m" line allow it. 310 It is assumed that the application uses only one codec at a time to 311 encode the media produced. This codec MAY change dynamically during 312 the session, but at any particular moment only one codec is in use. 314 The application encodes the media using the current codec and checks 315 one by one all the "m" lines that are part of the flow. If a 316 particular "m" line contains the codec being used and the direction 317 attribute is "sendonly" or "sendrecv", a copy of the encoded media is 318 sent to the address/port specified in that particular media stream. 319 If either the "m" line does not contain the codec being used or the 320 direction attribute is neither "sendonly" nor "sendrecv", nothing is 321 sent over this media stream. 323 The application typically ends up sending media to different 324 destinations (IP address/port number) depending on the codec used at 325 any moment. 327 8.4.1. Examples of FID 329 The session description below might be sent by a SIP user agent using 330 a cellular access. The user agent supports GSM (Global System for 331 Mobile communications) on port 30000 and AMR (Adaptive Multi-Rate) on 332 port 30002. When the remote party sends GSM, it will send RTP 333 packets to port number 30000. When AMR is the codec chosen, packets 334 will be sent to port 30002. Note that the remote party can switch 335 between both codecs dynamically in the middle of the session. 336 However, in this example, only one media stream at a time carries 337 voice. The other remains "muted" while its corresponding codec is 338 not in use. 340 v=0 341 o=Laura 289083124 289083124 IN IP4 two.example.com 342 t=0 0 343 c=IN IP4 192.0.2.1 344 a=group:FID 1 2 345 m=audio 30000 RTP/AVP 3 346 a=rtpmap:3 GSM/8000 347 a=mid:1 348 m=audio 30002 RTP/AVP 97 349 a=rtpmap:97 AMR/8000 350 a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; 351 mode-change-neighbor; maxframes=1 352 a=mid:2 354 (The linebreak in the fmtp line accommodates RFC formatting 355 restrictions; SDP does not have continuation lines.) 357 In the previous example, a system receives media on the same IP 358 address on different port numbers. The following example shows how a 359 system can receive different codecs on different IP addresses. 361 v=0 362 o=Laura 289083124 289083124 IN IP4 three.example.com 363 t=0 0 364 c=IN IP4 192.0.2.1 365 a=group:FID 1 2 366 m=audio 20000 RTP/AVP 0 367 c=IN IP4 192.0.2.2 368 a=rtpmap:0 PCMU/8000 369 a=mid:1 370 m=audio 30002 RTP/AVP 97 371 a=rtpmap:97 AMR/8000 372 a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; 373 mode-change-neighbor; maxframes=1 374 a=mid:2 376 (The linebreak in the fmtp line accomodates RFC formatting 377 restrictions; SDP does not have continuation lines.) 379 The cellular terminal of this example only supports the AMR codec. 380 However, many current IP phones only support PCM (Pulse-Code 381 Modulation; payload 0). In order to be able to interoperate with 382 them, the cellular terminal uses a transcoder whose IP address is 383 192.0.2.2. The cellular terminal includes in its SDP support for PCM 384 at that IP address. Remote systems will send AMR directly to the 385 terminal but PCM will be sent to the transcoder. The transcoder will 386 be configured (using whatever method) to convert the incoming PCM 387 audio to AMR and send it to the terminal. 389 The next example shows how the "group" attribute used with FID 390 semantics can indicate the use of two different codecs in the two 391 directions of a bidirectional media stream. 393 v=0 394 o=Laura 289083124 289083124 IN IP4 four.example.com 395 t=0 0 396 c=IN IP4 192.0.2.1 397 a=group:FID 1 2 398 m=audio 30000 RTP/AVP 0 399 a=mid:1 400 m=audio 30002 RTP/AVP 8 401 a=recvonly 402 a=mid:2 404 A user agent that receives the SDP above knows that at a certain 405 moment it can send either PCM u-law to port number 30000 or PCM A-law 406 to port number 30002. However, the media agent also knows that the 407 other end will only send PCM u-law (payload 0). 409 The following example shows a session description with different "m" 410 lines grouped together using FID semantics that contain the same 411 codec. 413 v=0 414 o=Laura 289083124 289083124 IN IP4 five.example.com 415 t=0 0 416 c=IN IP4 192.0.2.1 417 a=group:FID 1 2 3 418 m=audio 30000 RTP/AVP 0 419 a=mid:1 420 m=audio 30002 RTP/AVP 8 421 a=mid:2 422 m=audio 20000 RTP/AVP 0 8 423 c=IN IP4 192.0.2.2 424 a=recvonly 425 a=mid:3 427 At a particular point in time, if the media agent is sending PCM u- 428 law (payload 0), it sends RTP packets to 192.0.2.1 on port 30000 and 429 to 192.0.2.2 on port 20000 (first and third "m" lines). If it is 430 sending PCM A-law (payload 8), it sends RTP packets to 192.0.2.1 on 431 port 30002 and to 192.0.2.2 on port 20000 (second and third "m" 432 lines). 434 The system that generated the SDP above supports PCM u-law on port 435 30000 and PCM A-law on port 30002. Besides, it uses an application 436 server whose IP address is 192.0.2.2 that records the conversation. 437 That is why the application server always receives a copy of the 438 audio stream regardless of the codec being used at any given moment 439 (it actually performs an RTP dump, so it can effectively receive any 440 codec). 442 Remember that if several "m" lines grouped together using FID 443 semantics contain the same codec the media agent MUST send media over 444 several RTP sessions at the same time. 446 The last example of this section deals with DTMF tones. DTMF tones 447 can be transmitted using a regular voice codec or can be transmitted 448 as telephony events. The RTP payload for DTMF tones treated as 449 telephone events is described in [RFC2833]. Below, there is an 450 example of an SDP session description using FID semantics and this 451 payload type. 453 v=0 454 o=Laura 289083124 289083124 IN IP4 six.example.com 455 t=0 0 456 c=IN IP4 192.0.2.1 457 a=group:FID 1 2 458 m=audio 30000 RTP/AVP 0 459 a=mid:1 460 m=audio 20000 RTP/AVP 97 461 c=IN IP4 192.0.2.2 462 a=rtpmap:97 telephone-events 463 a=mid:2 465 The remote party would send PCM encoded voice (payload 0) to 466 192.0.2.1 and DTMF tones encoded as telephony events to 192.0.2.2. 467 Note that only voice or DTMF is sent at a particular point of time. 468 When DTMF tones are sent, the first media stream does not carry any 469 data and, when voice is sent, there is no data in the second media 470 stream. FID semantics provide different destinations for alternative 471 codecs. 473 8.5. Scenarios that FID does not Cover 475 It is worthwhile mentioning some scenarios where the "group" 476 attribute using existing semantics (particularly FID) might seem to 477 be applicable but is not. 479 8.5.1. Parallel Encoding Using Different Codecs 481 FID semantics are useful when the application only uses one codec at 482 a time. An application that encodes the same media using different 483 codecs simultaneously MUST NOT use FID to group those media lines. 484 Some systems that handle DTMF tones are a typical example of parallel 485 encoding using different codecs. 487 Some systems implement the RTP payload defined in RFC 2833, but when 488 they send DTMF tones they do not mute the voice channel. Therefore, 489 in effect they are sending two copies of the same DTMF tone: encoded 490 as voice and encoded as a telephony event. When the receiver gets 491 both copies, it typically uses the telephony event rather than the 492 tone encoded as voice. FID semantics MUST NOT be used in this 493 context to group both media streams since such a system is not using 494 alternative codecs but rather different parallel encodings for the 495 same information. 497 8.5.2. Layered Encoding 499 Layered encoding schemes encode media in different layers. Quality 500 at the receiver varies depending on the number of layers received. 502 SDP provides a means to group together contiguous multicast addresses 503 that transport different layers. The "c" line below: 505 c=IN IP4 224.2.1.1/127/3 507 is equivalent to the following three "c" lines: 509 c=IN IP4 224.2.1.1/127 510 c=IN IP4 224.2.1.2/127 511 c=IN IP4 224.2.1.3/127 513 FID MUST NOT be used to group "m" lines that do not represent the 514 same information. Therefore, FID MUST NOT be used to group "m" lines 515 that contain the different layers of layered encoding scheme. 516 Besides, we do not define new group semantics to provide a more 517 flexible way of grouping different layers because the already 518 existing SDP mechanism covers the most useful scenarios. 520 8.5.3. Same IP Address and Port Number 522 If several codecs have to be sent to the same IP address and port, 523 the traditional SDP syntax of listing several codecs in the same "m" 524 line MUST be used. FID MUST NOT be used to group "m" lines with the 525 same IP address/port. Therefore, an SDP like the one below MUST NOT 526 be generated. 528 v=0 529 o=Laura 289083124 289083124 IN IP4 six.example.com 530 t=0 0 531 c=IN IP4 192.0.2.1 532 a=group:FID 1 2 533 m=audio 30000 RTP/AVP 0 534 a=mid:1 535 m=audio 30000 RTP/AVP 8 536 a=mid:2 538 The correct SDP for the session above would be the following one: 540 v=0 541 o=Laura 289083124 289083124 IN IP4 six.example.com 542 t=0 0 543 c=IN IP4 192.0.2.1 544 m=audio 30000 RTP/AVP 0 8 546 If two "m" lines are grouped using FID they MUST differ in their 547 transport addresses (i.e., IP address plus port). 549 9. Usage of the "group" Attribute in SIP 551 SDP descriptions are used by several different protocols, SIP among 552 them. We include a section about SIP because the "group" attribute 553 will most likely be used mainly by SIP systems. 555 SIP [RFC3261] is an application layer protocol for establishing, 556 terminating and modifying multimedia sessions. SIP carries session 557 descriptions in the bodies of the SIP messages but is independent 558 from the protocol used for describing sessions. SDP [RFC4566] is one 559 of the protocols that can be used for this purpose. 561 At session establishment SIP provides a three-way handshake (INVITE- 562 200 OK-ACK) between end systems. However, just two of these three 563 messages carry SDP, as described in [RFC3264]. 565 9.1. Mid Value in Answers 567 The "mid" attribute is an identifier for a particular media stream. 568 Therefore, the "mid" value in the offer MUST be the same as the "mid" 569 value in the answer. Besides, subsequent offers (e.g., in a re- 570 INVITE) SHOULD use the same "mid" value for the already existing 571 media streams. 573 [RFC3264] describes the usage of SDP in relation to SIP. The offerer 574 and the answerer align their media description so that the nth media 575 stream ("m=" line) in the offerer's session description corresponds 576 to the nth media stream in the answerer's description. 578 The presence of the "group" attribute in an SDP session description 579 does not modify this behavior. 581 Since the "mid" attribute provides a means to label "m" lines, it 582 would be possible to perform media alignment using "mid" labels 583 rather than matching nth "m" lines. However this would not bring any 584 gain and would add complexity to implementations. Therefore SIP 585 systems MUST perform media alignment matching nth lines regardless of 586 the presence of the "group" or "mid" attributes. 588 If a media stream that contained a particular "mid" identifier in the 589 offer contains a different identifier in the answer the application 590 ignores all the "mid" and "group" lines that might appear in the 591 session description. The following example illustrates this 592 scenario. 594 9.1.1. Example 596 Two SIP entities exchange SDPs during session establishment. The 597 INVITE contains the SDP below: 599 v=0 600 o=Laura 289083124 289083124 IN IP4 seven.example.com 601 t=0 0 602 c=IN IP4 192.0.2.1 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 192.0.2.3 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 192.0.2.3 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 9.2. Group Value in Answers 641 A SIP entity that receives an offer that contains an "a=group" line 642 with semantics that it does not understand MUST return an answer 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 answer. 647 A SIP entity that receives an offer that contains an "a=group" line 648 with semantics that are understood MUST return an answer that 649 contains an "a=group" line with the same semantics. The 650 identification-tags contained in this "a=group" lines MUST be the 651 same that were received in the offer or a subset of them (zero 652 identification-tags is a valid subset). When the identification-tags 653 in the answer are a subset, the "group" value to be used in the 654 session MUST be the one present in the answer. 656 SIP entities refuse media streams by setting the port to zero in the 657 corresponding "m" line. "a=group" lines MUST NOT contain 658 identification-tags that correspond to "m" lines with port zero. 660 Note that grouping of m lines MUST always be requested by the 661 offerer, never by the answerer. Since SIP provides a two-way SDP 662 exchange, an answerer that requested grouping would not know whether 663 the "group" attribute was accepted by the offerer or not. An 664 answerer that wants to group media lines SHOULD issue another offer 665 after having responded to the first one (in a re-INVITE for 666 instance). 668 9.2.1. Example 670 The example below shows how the callee refuses a media stream offered 671 by the caller by setting its port number to zero. The "mid" value 672 corresponding to that media stream is removed from the "group" value 673 in the answer. 675 SDP in the INVITE from caller to callee: 677 v=0 678 o=Laura 289083124 289083124 IN IP4 ten.example.com 679 t=0 0 680 c=IN IP4 192.0.2.1 681 a=group:FID 1 2 3 682 m=audio 30000 RTP/AVP 0 683 a=mid:1 684 m=audio 30002 RTP/AVP 8 685 a=mid:2 686 m=audio 30004 RTP/AVP 3 687 a=mid:3 689 SDP in the INVITE from callee to caller: 691 v=0 692 o=Bob 289083125 289083125 IN IP4 eleven.example.com 693 t=0 0 694 c=IN IP4 192.0.2.3 695 a=group:FID 1 3 696 m=audio 20000 RTP/AVP 0 697 a=mid:1 698 m=audio 0 RTP/AVP 8 699 a=mid:2 700 m=audio 20002 RTP/AVP 3 701 a=mid:3 703 9.3. Capability Negotiation 705 A client that understands "group" and "mid" but does not want to make 706 use of them in a particular session MAY want to indicate that it 707 supports them. If a client decides to do that, it SHOULD add an 708 "a=group" line with no identification-tags for every semantics it 709 understands. 711 If a server receives an offer that contains empty "a=group" lines, it 712 SHOULD add its capabilities also in the form of empty "a=group" lines 713 to its answer. 715 9.3.1. Example 717 A system that supports both LS and FID semantics but does not want to 718 group any media stream for this particular session generates the 719 following SDP: 721 v=0 722 o=Bob 289083125 289083125 IN IP4 twelve.example.com 723 t=0 0 724 c=IN IP4 192.0.2.3 725 a=group:LS 726 a=group:FID 727 m=audio 20000 RTP/AVP 0 8 729 The server that receives that offer supports FID but not LS. It 730 responds with the SDP below: 732 v=0 733 o=Laura 289083124 289083124 IN IP4 thirteen.example.com 734 t=0 0 735 c=IN IP4 192.0.2.1 736 a=group:FID 737 m=audio 30000 RTP/AVP 0 739 9.4. Backward Compatibility 741 This document does not define any SIP "Require" header. Therefore, 742 if one of the SIP user agents does not understand the "group" 743 attribute the standard SDP fall back mechanism MUST be used 744 (attributes that are not understood are simply ignored). 746 9.4.1. Offerer does not Support "group" 748 This situation does not represent a problem because grouping requests 749 are always performed by offerers, not by answerers. If the offerer 750 does not support "group" this attribute will just not be used. 752 9.4.2. Answerer does not Support "group" 754 The answerer will ignore the "group" attribute, since it does not 755 understand it (it will also ignore the "mid" attribute). For LS 756 semantics, the answerer might decide to perform or to not perform 757 synchronization between media streams. 759 For FID semantics, the answerer will consider that the session 760 comprises several media streams. 762 Different implementations would behave in different ways. 764 In the case of audio and different "m" lines for different codecs an 765 implementation might decide to act as a mixer with the different 766 incoming RTP sessions, which is the correct behavior. 768 An implementation might also decide to refuse the request (e.g., 488 769 Not acceptable here or 606 Not Acceptable) because it contains 770 several "m" lines. In this case, the server does not support the 771 type of session that the caller wanted to establish. In case the 772 client is willing to establish a simpler session anyway, he SHOULD 773 re-try the request without "group" attribute and only one "m" line 774 per flow. 776 10. Changes from RFC 3388 778 The grouping mechanism is now defined as an extendible framework. 779 Earlier, [RFC3388] used to discourage extensions to this mechanism in 780 favor of using new session description protocols. 782 Given a semantics value, [RFC3388] used to restrict "m" line 783 identifiers to only appear in a single group using that semantics. 784 That restriction has been lifted. From conversations with 785 implementers, it seems that the lifting of this restriction is 786 unlikely to cause backwards compatibility problems. 788 11. Security Considerations 790 Using the "group" parameter with FID semantics, an entity that 791 managed to modify the session descriptions exchanged between the 792 participants to establish a multimedia session could force the 793 participants to send a copy of the media to any particular 794 destination. 796 Integrity mechanism provided by protocols used to exchange session 797 descriptions and media encryption can be used to prevent this attack. 798 In SIP, S/MIME [RFC3850] and TLS [RFC4346] can be used to protect 799 session description exchanges in an end-to-end and a hop-by-hop 800 fashion respectively. 802 12. IANA Considerations 804 [RFC3388] already registered the "mid" and "group" SDP attributes 805 with the IANA and created a registry for semantics. This document 806 does not contain any additional actions for the IANA. 808 13. References 809 13.1. Normative References 811 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 812 Requirement Levels", BCP 14, RFC 2119, March 1997. 814 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 815 Description Protocol", RFC 4566, July 2006. 817 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 818 A., Peterson, J., Sparks, R., Handley, M., and E. 819 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 820 June 2002. 822 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 823 with Session Description Protocol (SDP)", RFC 3264, 824 June 2002. 826 [RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail 827 Extensions (S/MIME) Version 3.1 Certificate Handling", 828 RFC 3850, July 2004. 830 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 831 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 833 13.2. Informational References 835 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. 836 Jacobson, "RTP: A Transport Protocol for Real-Time 837 Applications", RFC 1889, January 1996. 839 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 840 Streaming Protocol (RTSP)", RFC 2326, April 1998. 842 [RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF 843 Digits, Telephony Tones and Telephony Signals", RFC 2833, 844 May 2000. 846 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 847 Schulzrinne, "Grouping of Media Lines in the Session 848 Description Protocol (SDP)", RFC 3388, December 2002. 850 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 851 Jacobson, "RTP: A Transport Protocol for Real-Time 852 Applications", STD 64, RFC 3550, July 2003. 854 Author's Address 856 Gonzalo Camarillo 857 Ericsson 858 Hirsalantie 11 859 Jorvas 02420 860 Finland 862 Email: Gonzalo.Camarillo@ericsson.com