idnits 2.17.1 draft-holmberg-mmusic-sdp-bundle-negotiation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 10 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2011) is 4567 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 informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track H. Alvestrand 5 Expires: April 21, 2012 Google 6 October 19, 2011 8 Multiplexing Negotiation Using Session Description Protocol (SDP) Port 9 Numbers 10 draft-holmberg-mmusic-sdp-bundle-negotiation-00.txt 12 Abstract 14 This specification defines a new SDP Grouping Framework SDP grouping 15 framework extension, "BUNDLE", that can be used with the Session 16 Description Protocol (SDP) Offer/Answer mechanism to negotiate the 17 usage of bundled media, which refers to the usage of a single 5-tuple 18 for media associated with multiple SDP media descriptions ("m=" 19 lines). 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). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 21, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 59 5. SDP Grouping Framework BUNDLE Extension Semantics . . . . . . 4 60 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 61 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 6.2. SDP Offerer Procedures . . . . . . . . . . . . . . . . . . 5 63 6.3. SDP Answerer Procedures . . . . . . . . . . . . . . . . . 6 64 6.4. Bundled SDP Information . . . . . . . . . . . . . . . . . 6 65 6.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.4.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . 6 67 7. Single vs Multiple RTP Sessions . . . . . . . . . . . . . . . 6 68 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 7.2. Single RTP Session . . . . . . . . . . . . . . . . . . . . 6 70 8. Usage With ICE . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8.2. Candidates . . . . . . . . . . . . . . . . . . . . . . . . 7 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 77 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 14.1. Normative References . . . . . . . . . . . . . . . . . . . 10 80 14.2. Informative References . . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 In the IETF RTCWEB WG, a need to use a single 5-tuple for sending and 86 receiving media associated with multiple SDP media descriptions ("m=" 87 lines) has been identified. This would e.g. allow the usage of a 88 single set of Interactive Connectivity Establishment (ICE) [RFC5245] 89 candidates for multiple media descriptions. Normally different media 90 types (audio, video etc) will be described using different media 91 descriptions. 93 This specification defines a new SDP Grouping Framework SDP grouping 94 framework [RFC5888] extension, "BUNDLE", that can be used with the 95 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 96 to negotiate the usage of bundled media, which refers to the usage of 97 a single 5-tuple for media associated with multiple SDP media 98 descriptions ("m=" lines). 100 When an endpoint generates an SDP Offer or SDP Answer [RFC3264], 101 which includes a "BUNDLE" group, each "m=" line associated with the 102 group will share a single port number value. 104 As defined in RFC 4566 [RFC4566], the semantics of multiple "m=" 105 lines using the same port number value are undefined, and there is no 106 grouping defined by such means. Instead, an explicit grouping 107 mechanism needs to be used to express the intended semantics. This 108 specification provides such extension. 110 When media is transported using the Real-Time Protocol (RTP) 111 [RFC3550], the default assumption of the mechanism is that all media 112 associated with a "BUNDLE" group will form a single RTP Session 113 [RFC3550]. However, future specifications can extend the mechanism, 114 in order to negotiate RTP Session multiplexing, i.e. "BUNDLE" groups 115 where media associated with a group form multiple RTP Sessions. 117 The mechanism is backward compatible. Entities that do not support 118 the "BUNDLE" grouping extension, or do not want to enable the 119 mechanism for a given session, are expected to generate a "normal" 120 SDP Answer, using different port number values for each "m=" line, to 121 the SDP Offer. The SDP Offerer [RFC3264] will still use a single 122 port number value for each media, but as the SDP Answerer [RFC3264] 123 will use separate ports a single 5-tuple will not be used for media 124 associated with multiple "m=" lines between the endpoints. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 5-tuple: A collection of the following values: source address, source 133 port, destination address, destination port and protocol. 135 Bundled media: Two or more RTP streams using a single 5-tuple. The 136 RTCP streams associated with the RTP streams also use a single 137 5-tuple, which might be the same, but can also be different, as the 138 one used by the RTP streams. 140 3. Conventions 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in BCP 14, RFC 2119 145 [RFC2119]. 147 4. Applicability Statement 149 The mechanism in this specification only applies to the Session 150 Description Protocol (SDP) [RFC4566], when used together with the SDP 151 Offer/Answer mechanism [RFC3264]. 153 5. SDP Grouping Framework BUNDLE Extension Semantics 155 This section defines a new SDP Grouping Framework extension, 156 "BUNDLE". 158 The "BUNDLE" extension can be indicated using an SDP session-level 159 'group' attribute. Each SDP media description ("m=" line) that is 160 grouped together, using an SDP media-level 'mid' attribute, is part 161 of a specific "BUNDLE" group. 163 6. SDP Offer/Answer Procedures 165 6.1. General 167 When an SDP Offerer or SDP Answerer generates an SDP Offer or SDP 168 Answer, that describes bundled media, it MUST insert an SDP session- 169 level 'group' attribute, with a "BUNDLE" value, and assign SDP media- 170 level 'mid' attribute values to each "m=" line associated with the 171 "BUNDLE" group. 173 In addition, the entity that generates the SDP Offer or SDP Answer 174 MUST, for each "m=" line that is part of the "BUNDLE" group: 176 o 1. Use the same port number value. 177 o 2. Use the same connection data ("c=" line) value. 178 o 3. Use the same SDP 'rtcp' attribute value, when used. 179 o 4. Use the same ICE candidate values, when used. 180 o 5. Insert an SDP 'rtpc-mux' attribute. 182 NOTE: If an entity wants to disable specific media ("m=" line) 183 associated with a "BUNDLE" group, it will use a zero port number 184 value for the "m=" line associated with the media. 186 6.2. SDP Offerer Procedures 188 When an SDP Offerer creates an SDP Offer, that offers bundled media, 189 it MUST create the SDP Offer according to the procedures in 190 Section 6.1. 192 If the associated SDP Answer contains an SDP session-level 'group' 193 attribute, with a "BUNDLE" value, and the SDP Answer is created 194 according to the proceudres in Section 6.1 (the same port number 195 value is used for each "m=" line associated with the "BUNDLE" group, 196 etc), the SDP Offerer can start using the same 5-tuple for sending 197 and receiving media, associated with the group, between the entities. 199 If the SDP Answer does not include a session-level SDP 'group' 200 attribute, with a "BUNDLE" value, the SDP Offerer cannot use the same 201 5-tuple for media associated with multiple "m=" lines. 203 If the SDP Answererer indicates that it will not use bundled media, 204 the SDP Offerer will still use the single port number value for each 205 "m= line" associated with the offered "BUNDLE" group, and it will 206 normally be able to separate each individual media. The default 207 mechanism for separating media received on a single IP address and 208 port doing this is by using a 5-tuple based mapping for each 209 individual media. If the SDP Offerer is aware of the Synchronization 210 Source (SSRC) [RFC3550] values that the SDP Answerer will use in the 211 media it sends, and the SSRC values will be unique for each media, 212 the SDP Offerer can separate media based on the SSRC values. 214 NOTE: Assuming symmetric media is used, the SDP Offerer can use the 215 port information from the SDP Answer in order to create the 5-tuple 216 mapping for each media. 218 If the SDP Offerer is not able to separate multiple media received on 219 a single port, it MUST send a new SDP Offer, without offering bundled 220 media, where a separate port number value is provide for each "m=" 221 line of the SDP Offer. 223 If an SDP Offer, offering a "BUNDLE" group, and the SDP Offerer has 224 reasons to believe that the rejection is due to the usage of a single 225 port number value for multiple "m=" lines, the SDP Offerer SHOULD 226 send a new SDP Offer, without a "BUNDLE" group, where a separate port 227 number value is provide for each "m=" line of the SDP offer. 229 6.3. SDP Answerer Procedures 231 When an SDP Answerer receives an SDP Offer, which offers bundled 232 media, and the SDP Answerer accepts the offered bundle group, the SDP 233 Answerer MUST create an SDP Answer according to the procedures in 234 Section 6.1. 236 If the SDP Answerer does not accept the "BUNDLE" group in the SDP 237 Offer, it MUST NOT include a session-evel 'group' attribute, with a 238 "BUNDLE" value, in the associated SDP Answer. In addition, the SDP 239 Answerer MUST provide separate port number values for each "m=" line 240 of the SDP Answer. 242 6.4. Bundled SDP Information 244 6.4.1. General 246 This section describes how SDP information, given for each media 247 description, is calculated into a single value for a "BUNDLE" group. 249 6.4.2. Bandwidth (b=) 251 The total proposed bandwidth is the sum of the proposed bandwidth for 252 each "m=" line associated with a negotiated BUNDLE group. 254 7. Single vs Multiple RTP Sessions 256 7.1. General 258 When entities negotiate the usage of bundled media, the default 259 assumption is that all media associated with the bundled media will 260 form a single RTP session. 262 The usage of multiple RTP Sessions within a "BUNDLE" group is outside 263 the scope of this specification. Other specification needs to extend 264 the mechanism in order to allow negotiation of such bundle groups. 266 7.2. Single RTP Session 268 When a single RTP Session is used, media associated with all "m=" 269 lines part of a bundle group share a single SSRC [RFC3550] numbering 270 space. 272 In addition, the following rules and restrictions apply for a single 273 RTP Session: 275 o - The dynamic payload type values used in the "m=" lines MUST NOT 276 overlap. 277 o - The "proto" value in each "m=" line MUST be identical (e.g. 278 RTP/AVPF). 279 o - A given SSRC SHOULD NOT transmit RTP packets using payload types 280 that originates from different "m=" lines. 282 NOTE: The last bullet above is to avoid sending multiple media types 283 from the same SSRC. If transmission of multiple media types are done 284 with time overlap RTP and RTCP fails to function. Even if done in 285 proper sequence this causes RTP Timestamp rate switching issues [ref 286 to draft-ietf-avtext-multiple-clock-rates]. 288 8. Usage With ICE 290 8.1. General 292 This section describes how to use the "BUNDLE" grouping mechanism 293 together with the Interactive Connectivity Establishment (ICE) 294 mechanism [RFC5245]. 296 8.2. Candidates 298 When an ICE-enabled SDP Offerer sends an SDP offer, it MUST include 299 ICE candidates for each "m=" line associated with a "BUNDLE" group. 300 The candidate values MUST be identical for each "m=" line associated 301 with the group. This rule applies also to subsequent SDP Offers, 302 when the usage of bundled media has already been negotiated. 304 When an ICE-enabled SDP Answerer receives an SDP Offer, offering a 305 "BUNDLE" group and ICE, if the SDP Answerer enables ICE, MUST include 306 ICE candidates for each "m=" line of the SDP Answer. This also 307 applies for "m=" lines that are part of a "BUNDLE" group, in which 308 case the candidate values MUST be identical for each "m=" line 309 associated with the group. This rule applies also to subsequent SDP 310 Answers, when the usage of bundled media has already been negotiated. 312 Once the usage of bundled media has been negotiated, ICE connectivity 313 checks and keep-alives only needs to be performed for the whole 314 "BUNDLE" group, instead of for each individual m= line associated 315 with the group. 317 9. Security Considerations 319 TBA 321 10. Example 323 The example below shows an SDP Offer, where bundled media is offered. 324 The example also shows two SDP Answer alternatives: one where bundled 325 media is accepted, and one where bundled media is rejected (or, not 326 even supported) by the SDP Answerer. 328 SDP Offer (Bundled media offered) 330 v=0 331 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com 332 s= 333 c=IN IP4 host.atlanta.com 334 t=0 0 335 a=group:BUNDLE foo bar 336 m=audio 10000 RTP/AVP 0 8 97 337 a=mid:foo 338 b=AS:200 339 a=rtpmap:0 PCMU/8000 340 a=rtpmap:8 PCMA/8000 341 a=rtpmap:97 iLBC/8000 342 m=video 10000 RTP/AVP 31 32 343 a=mid:bar 344 b=AS:1000 345 a=rtpmap:31 H261/90000 346 a=rtpmap:32 MPV/90000 348 SDP Answer (Bundled media accepted) 350 v=0 351 o=bob 2808844564 2808844564 IN IP4 host.biloxi.com 352 s= 353 c=IN IP4 host.biloxi.com 354 t=0 0 355 a=group:BUNDLE foo bar 356 m=audio 20000 RTP/AVP 0 357 a=mid:foo 358 b=AS:200 359 a=rtpmap:0 PCMU/8000 360 m=video 20000 RTP/AVP 32 361 a=mid:bar 362 b=AS:1000 363 a=rtpmap:32 MPV/90000 365 SDP Answer (Bundled media not accepted) 367 v=0 368 o=bob 2808844564 2808844564 IN IP4 host.biloxi.com 369 s= 370 c=IN IP4 host.biloxi.com 371 t=0 0 372 m=audio 20000 RTP/AVP 0 373 b=AS:200 374 a=rtpmap:0 PCMU/8000 375 m=video 30000 RTP/AVP 32 376 b=AS:1000 377 a=rtpmap:32 MPV/90000 379 SDP Offer with ICE (Bundled media offered) 381 v=0 382 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com 383 s= 384 c=IN IP4 host.atlanta.com 385 t=0 0 386 a=group:BUNDLE foo bar 387 m=audio 10000 RTP/AVP 0 8 97 388 a=mid:foo 389 b=AS:200 390 a=rtpmap:0 PCMU/8000 391 a=rtpmap:8 PCMA/8000 392 a=rtpmap:97 iLBC/8000 393 a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host 394 m=video 10000 RTP/AVP 31 32 395 a=mid:bar 396 b=AS:1000 397 a=rtpmap:31 H261/90000 398 a=rtpmap:32 MPV/90000 399 a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host 401 11. IANA Considerations 403 This document requests IANA to register the new SDP Grouping semantic 404 extension called BUNDLE. 406 12. Acknowledgements 408 The usage of the SDP grouping mechanism is based on a similar 409 alternative proposed by Harald Alvestrand. The SDP examples are also 410 modified versions from the ones in the Alvestrand proposal. 412 Thanks to the nice flight crew on AY 021 for providing good sparkling 413 wine, and a nice working athmosphere, for working on this draft. 415 13. Change Log 417 [RFC EDITOR NOTE: Please remove this section when publishing] 419 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 420 o Draft name changed. 421 o Harald Alvestrand added as co-author. 422 o "Multiplex" terminology changed to "bundle". 423 o Added text about single versus multiple RTP Sessions. 424 o Added reference to RFC 3550. 426 14. References 428 14.1. Normative References 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, March 1997. 433 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 434 with Session Description Protocol (SDP)", RFC 3264, 435 June 2002. 437 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 438 Description Protocol", RFC 4566, July 2006. 440 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 441 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 443 14.2. Informative References 445 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 446 Jacobson, "RTP: A Transport Protocol for Real-Time 447 Applications", STD 64, RFC 3550, July 2003. 449 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 450 (ICE): A Protocol for Network Address Translator (NAT) 451 Traversal for Offer/Answer Protocols", RFC 5245, 452 April 2010. 454 Authors' Addresses 456 Christer Holmberg 457 Ericsson 458 Hirsalantie 11 459 Jorvas 02420 460 Finland 462 Email: christer.holmberg@ericsson.com 464 Harald Tveit Alvestrand 465 Google 466 Kungsbron 2 467 Stockholm 11122 468 Sweden 470 Email: harald@alvestrand.no