idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 14, 2013) is 3840 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) == Outdated reference: A later version (-05) exists of draft-nandakumar-mmusic-sdp-mux-attributes-04 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-02) exists of draft-ietf-mmusic-trickle-ice-00 Summary: 1 error (**), 0 flaws (~~), 3 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 17, 2014 Google 6 C. Jennings 7 Cisco 8 October 14, 2013 10 Multiplexing Negotiation Using Session Description Protocol (SDP) Port 11 Numbers 12 draft-ietf-mmusic-sdp-bundle-negotiation-05.txt 14 Abstract 16 This specification defines a new SDP Grouping Framework extension, 17 "BUNDLE", that can be used with the Session Description Protocol 18 (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, 19 which refers to the usage of a single 5-tuple for media associated 20 with multiple SDP media descriptions ("m=" lines). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 17, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 60 5. SDP Grouping Framework BUNDLE Extension Semantics . . . . . . 5 61 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 62 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 6.2. Bundled SDP Information . . . . . . . . . . . . . . . . . 5 64 6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 65 6.2.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . 6 66 6.2.3. rtcp-mux Attribute . . . . . . . . . . . . . . . . . 6 67 6.2.4. rtcp Attribute . . . . . . . . . . . . . . . . . . . 6 68 6.2.5. DTLS-SRTP fingerprint Attribute . . . . . . . . . . . 6 69 6.2.6. SDES crypto Attribute . . . . . . . . . . . . . . . . 6 70 6.2.7. Other Attributes (a=) . . . . . . . . . . . . . . . . 6 71 6.3. RFC 5888 restrictions . . . . . . . . . . . . . . . . . . 6 72 6.4. SDP Offerer Procedures . . . . . . . . . . . . . . . . . 7 73 6.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 74 6.4.2. Request BUNDLE address selection . . . . . . . . . . 8 75 6.4.3. Bundle Address Synchronization (BAS) . . . . . . . . 8 76 6.4.4. Adding a media description to a BUNDLE group . . . . 8 77 6.4.5. Moving A Media Description Out Of A BUNDLE Group . . 9 78 6.4.6. Disabling A Media Description In A BUNDLE Group . . . 9 79 6.5. SDP Answerer Procedures . . . . . . . . . . . . . . . . . 9 80 6.5.1. Offerer Bundle Address Selection . . . . . . . . . . 10 81 6.5.2. Anwerer Bundle Address Selection . . . . . . . . . . 10 82 6.5.3. Moving A Media Description Out Of A BUNDLE Group . . 10 83 6.5.4. Rejecting A Media Description In A BUNDLE Group . . . 11 84 7. Single vs Multiple RTP Sessions . . . . . . . . . . . . . . . 11 85 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 7.2. Single RTP Session . . . . . . . . . . . . . . . . . . . 11 87 8. Usage With ICE . . . . . . . . . . . . . . . . . . . . . . . 12 88 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 8.2. Candidates . . . . . . . . . . . . . . . . . . . . . . . 12 90 8.3. Candidates . . . . . . . . . . . . . . . . . . . . . . . 12 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 92 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 10.1. Example: Bundle Address Selection . . . . . . . . . . . 13 94 10.2. Example: Bundle Mechanism Rejected . . . . . . . . . . . 14 95 10.3. Example: Offerer Adds A Media Description To A BUNDLE 96 Group . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 10.4. Example: Offerer Moves A Media Description Out Of A 99 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 17 100 10.5. Example: Offerer Disables A Media Description In A 101 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 19 102 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 103 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 104 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 20 105 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 106 14.1. Normative References . . . . . . . . . . . . . . . . . . 21 107 14.2. Informative References . . . . . . . . . . . . . . . . . 22 108 Appendix A. Design Considerations . . . . . . . . . . . . . . . 22 109 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 22 110 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 23 111 A.3. Usage of port number value zero . . . . . . . . . . . . . 24 112 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 25 113 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 25 114 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 25 115 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 26 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 118 1. Introduction 120 In the IETF RTCWEB WG, a need to use a single 5-tuple for sending and 121 receiving media associated with multiple SDP media descriptions ("m=" 122 lines) has been identified. This would e.g. allow the usage of a 123 single set of Interactive Connectivity Establishment (ICE) [RFC5245] 124 candidates for multiple media descriptions. Normally different media 125 types (audio, video etc) will be described using different media 126 descriptions. 128 This specification defines a new SDP Grouping Framework [RFC5888] 129 extension, "BUNDLE", that can be used with the Session Description 130 Protocol (SDP) Offer/Answer mechanism [RFC3264] to negotiate the 131 usage of bundled media, which refers to the usage of a single 5-tuple 132 for media associated with multiple SDP media descriptions ("m=" 133 lines). 135 The Offerer and Answerer [RFC3264] use the BUNDLE mechanism to 136 negotiate a single BUNDLE address to be used for the bundled media 137 associated with a BUNDLE group. 139 The BUNDLE mechanism allows an SDP Offerer and SDP Answerer to assign 140 identical addresses to multiple "m=" lines, if those "m=" lines are 141 associated with a BUNDLE group. However, until it is known whether 142 both the Offerer and Answerer support the BUNDLE mechanism, unique 143 addresses are assigned to each "m=" line, including those associated 144 with a BUNDLE group. 146 NOTE: As defined in RFC 4566 [RFC4566], the semantics of multiple 147 "m=" lines using the same port number value are undefined, and there 148 is no grouping defined by such means. Instead, an explicit grouping 149 mechanism needs to be used to express the intended semantics. This 150 specification provides such extension. 152 SDP Offers and SDP Answer can contain multiple BUNDLE groups. For 153 each BUNDLE group, a BUNDLE address is negotiated. Multiple BUNDLE 154 groups cannot share the same bundle address. 156 The default assumption is that all Real-Time Protocol (RTP) [RFC3550] 157 based media flows within a BUNDLE group belongs to the same RTP 158 Session [RFC3550]. Future extensions can change that assumption. 160 The BUNDLE mechanism is backward compatible. Endpoints that do not 161 support the BUNDLE mechanism are expected to generate SDP Offers and 162 SDP Answers without an SDP group:BUNDLE attribute, and are expected 163 to assign unique addresses to each "m=" line, according to the 164 procedures in [RFC4566] and [RFC3264] 166 2. Terminology 168 5-tuple: A collection of the following values: source address, source 169 port, destination address, destination port and protocol. 171 Bundled media: Two or more RTP streams using a single 5-tuple. The 172 RTCP streams associated with the RTP streams also use a single 173 5-tuple, which might be the same, but can also be different, as the 174 one used by the RTP streams. 176 Unique address: This refers to an IP address and IP port combination, 177 that can only be associated with a single "m=" line within an SDP 178 Session. 180 BUNDLE address: This refers to an IP address and IP port combination, 181 that is associated with each "m=" line within a BUNDLE group, within 182 an SDP Session. The zero IP port value BUNDLE address MUST NOT be 183 used in a BUNDLE address. 185 NOTE: "m=" lines that share a BUNDLE address MUST also share other 186 parameters related to the media transport plane, e.g. ICE candidate 187 information. 189 3. Conventions 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in BCP 14, RFC 2119 194 [RFC2119]. 196 4. Applicability Statement 198 The mechanism in this specification only applies to the Session 199 Description Protocol (SDP) [RFC4566], when used together with the SDP 200 Offer/Answer mechanism [RFC3264]. 202 5. SDP Grouping Framework BUNDLE Extension Semantics 204 This section defines a new SDP Grouping Framework extension, BUNDLE. 206 The BUNDLE extension can be indicated using an SDP session-level 207 'group' attribute. Each SDP Media Description ("m=" line) that is 208 grouped together, using SDP media-level mid attributes, belongs to a 209 given BUNDLE group. 211 6. SDP Offer/Answer Procedures 213 6.1. General 215 This section describes the usage of the SDP Offer/Answer mechanism 216 [RFC3264] to negotiate the usage of the BUNDLE mechanism, to 217 negotiate the BUNDLE address, and to add, remove and reject SDP Media 218 Descriptions ("m=" lines) [RFC4566] associated with a BUNDLE group. 220 The generic rules and procedures defined in [RFC3264] and [RFC5888] 221 apply when the SDP Offer/Answer mechanism is used with the BUNDLE 222 mechanism. For example, if an SDP Offer is rejected, the previously 223 negotiated SDP parameters and characteristics (including those 224 associated with BUNDLE groups) apply. 226 When an endpoint, acting as an Offerer or Answerer [RFC3264], 227 generates an SDP Offer, or an SDP Answer, the endpoint MUST assign an 228 SDP media-level mid value for each "m=" line in a BUNDLE group. In 229 addition, the endpoint MUST assign an SDP session-level group:BUNDLE 230 attribute for each BUNDLE group, and place each mid associated with 231 the SDP group:BUNDLE attribute mid list. 233 6.2. Bundled SDP Information 235 6.2.1. General 236 This section describes restrictions associated with the usage of SDP 237 parameters and extensions within a BUNDLE group. It also describes, 238 when parameter and attribute values have been assigned to each "m=" 239 line in the BUNDLE group, how to calculate a value for the whole 240 BUNDLE group. 242 6.2.2. Bandwidth (b=) 244 The total proposed bandwidth is the sum of the proposed bandwidth for 245 each "m=" line associated with a negotiated BUNDLE group. 247 6.2.3. rtcp-mux Attribute 249 For each "m=" line in a BUNDLE group, an Offerer and Answerer MUST 250 assign an SDP rtcp-mux attribute [RFC5761]. 252 6.2.4. rtcp Attribute 254 When used, for each RTP media "m=" line in a BUNDLE group, an Offerer 255 and Answerer MUST assign an SDP rtcp attribute [RFC3605] with an 256 identical attribute value. 258 6.2.5. DTLS-SRTP fingerprint Attribute 260 When DTLS-SRTP is used, for each RTP media "m=" line in a BUNDLE 261 group, an Offerer and Answerer MUST assign an SDP DTLS-SRTP 262 fingerprint attribute with identical attribute values. 264 6.2.6. SDES crypto Attribute 266 When SDES is used, for each RTP media "m=" line in a BUNDLE group, an 267 Offerer and Answerer MUST assign an SDP crypto attribute, with unique 268 attribute values. 270 6.2.7. Other Attributes (a=) 272 There are also special rules for handling many different attributes 273 as defined in [I-D.nandakumar-mmusic-sdp-mux-attributes]. It might 274 not possible to use bundle with some attributes. 276 6.3. RFC 5888 restrictions 278 Based on the rules and procedures in [RFC5888], the following 279 restrictions also apply to BUNDLE groups in SDP Answers: 281 o 1) A BUNDLE group must not be added to an SDP Answer, unless the 282 same BUNDLE group was included in the associated SDP Offer; and 284 o 2) An SDP "m=" line must not be added to a BUNDLE group in the SDP 285 Answer, unless it was in the same BUNDLE group in the associated 286 SDP Offer. 288 6.4. SDP Offerer Procedures 290 6.4.1. General 292 When an Offerer generates an Offer, it assigns an address to each 293 "m=" line, according to the procedures in [RFC3264]. To each "m=" 294 line within a BUNDLE group the Offerer assigns either an address that 295 is unique to that "m=" line, or a shared address that is also 296 assigned to other "m=" lines within the BUNDLE group. Such shared 297 address can be, but does not have to be, a previously selected BUNDLE 298 address Section 6.5.1. 300 OPEN ISSUE (Q6): There is a discussion on whether assigning a shared 301 address to multiple "m=" lines shall be allowed until the Answerer 302 has indicated support of BUNDLE. 304 o (http://www.ietf.org/mail-archive/web/mmusic/current/ 305 msg12245.html) 307 The Offerer MUST NOT assign an address (unique or shared), that it 308 has assigned to an "m=" line within a BUNDLE group, to an "m=" line 309 outside the BUNDLE group. 311 The Offerer MUST, for a BUNDLE group, on the SDP session level 312 [RFC4566], insert an SDP group:BUNDLE attribute associated with the 313 BUNDLE group. The Offerer MUST assign an SDP 'mid' attribute 314 [RFC5888] to each "m=" line within the BUNDLE group, and place the 315 mid value in the group:BUNDLE attribute mid list. 317 The Offerer MAY assign an SDP 'bundle-only' attribute [ref-to-be- 318 added] to one or more "m=" lines within a BUNDLE group. 320 OPEN ISSUE (Q8): It still needs to be decided whether a zero port 321 value can be assigned to a 'bundle-only' "m=" line. 323 o (http://www.ietf.org/mail-archive/web/mmusic/current/ 324 msg12075.html) 326 o (http://www.ietf.org/mail-archive/web/mmusic/current/ 327 msg12226.html) 329 o (http://www.ietf.org/mail-archive/web/mmusic/current/ 330 msg12339.html) 332 6.4.2. Request BUNDLE address selection 334 When an Offerer generates an Offer, it MUST indicate which address 335 (unique or shared) within a BUNDLE group it wishes the Answer to 336 select as the Offerer's BUNDLE address for the BUNDLE group 337 Section 6.5.1. The Offerer MUST do this even if the Answerer has, in 338 a previous Answer within the dialog, already selected the Offerer's 339 BUNDLE address. 341 In order to request an address (unique or shared) to be selected as 342 the Offerer's BUNDLE address for a BUNDLE group, the Offerer places 343 the mid value, associated with the "m=" line representing the 344 requested address, first in the SDP group:BUNDLE attribute mid list 345 associated with the BUNDLE group. 347 Section 10.1 shows an example of a Bundle Address Request. 349 6.4.3. Bundle Address Synchronization (BAS) 351 When an Offerer receives an Answer, in which an offered BUNDLE group 352 is accepted, if the Offerer in the associated Offer assigned an 353 address (unique or shared), that does not represent the BUNDLE 354 address selected for the Offerer, to an "m=" line within the BUNDLE 355 group, the Offerer MUST send a subsequent Offer, in which it assigns 356 the BUNDLE address selected for the Offerer to each "m=" line within 357 the BUNDLE group. This procedure is referred to as Bundle Address 358 Synchronization (BAS), and the Offer is referred to as a BAS Offer. 360 The Offerer MAY modify any SDP parameter in a BAS Offer. 362 NOTE: It is important that the BAS Offer gets accepted by the 363 Answerer, so the Offerer needs to consider the necessity to modify 364 SDP parameters that could get the Answerer to reject the BAS Offer. 365 Removing "m=" lines, or reducing the number of codecs, in the BAS 366 Offer used for the is considered to have a low risk of being 367 rejected. 369 NOTE: The main purpose of the BAS Offer is to make sure that 370 intermediaries, that might not support the BUNDLE mechanism, have 371 correct information regarding which address is going to be used for 372 the bundled media. 374 Section 10.1 shows an example of an BAS Offer. 376 6.4.4. Adding a media description to a BUNDLE group 378 When an Offerer generates an Offer, in which it adds an "m=" line to 379 a BUNDLE group, the Offerer assigns an address (unique or shared) to 380 the "m=" line, assigns an SDP 'mid' attribute to the "m=" line, and 381 places the mid value in the group:BUNDLE attribute mid list 382 associated with the BUNDLE group, according to the procedures in 383 Section 6.4.2. If the Offerer wishes the Answerer to select the 384 address assigned to the added "m=" as the Offerer's BUNDLE address, 385 the mid value associated with the "m=" line is placed first in the 386 list, according to the procedures in Section 6.4.2. 388 Section 10.3 shows an example of an Offer used to add an "m=" line to 389 a BUNDLE group. 391 6.4.5. Moving A Media Description Out Of A BUNDLE Group 393 When an Offerer generates an Offer, in which an "m=" line is moved 394 out of a BUNDLE group, the Offerer MUST assign a unique address to 395 the moved "m=" line. In addition, the Offerer MUST NOT anymore 396 include a mid value, representing the "m=" line, in the SDP 397 group:BUNDLE attribute mid list associated with the BUNDLE group. 399 Section 10.4 shows an example of an Offer used to move an "m=" line 400 out of a BUNDLE group. 402 6.4.6. Disabling A Media Description In A BUNDLE Group 404 When an Offerer generates an Offer, in which an "m=" line associated 405 with a BUNDLE group is disabled, the Offerer MUST assign an address 406 with a zero port value [RFC4566] to the disabled "m=" line. In 407 addition, the Offerer MUST NOT anymore include a mid value, 408 representing the "m=" line, in the SDP group:BUNDLE attribute mid 409 list associated with the BUNDLE group. 411 OPEN ISSUE (Q8): It still needs to be decided whether a zero port 412 value can be assigned to a 'bundle-only' "m=" line. 414 o (http://www.ietf.org/mail-archive/web/mmusic/current/ 415 msg12075.html) 417 o (http://www.ietf.org/mail-archive/web/mmusic/current/ 418 msg12226.html) 420 o (http://www.ietf.org/mail-archive/web/mmusic/current/ 421 msg12339.html) 423 Section 10.5 shows an example of an Offer used to disable an "m=" 424 line in a BUNDLE group. 426 6.5. SDP Answerer Procedures 427 6.5.1. Offerer Bundle Address Selection 429 When an Answerer generates an Answer that contains a BUNDLE group, 430 the Answer MUST select the Offerer's BUNDLE address. The first mid 431 value in the SDP group:BUNDLE attribute mid list of the Offer 432 represents the address which the Offerer wishes the Answer to select 433 as the Offerer's BUNDLE address Section 6.4.2. 435 The Answerer SHOULD select the address represented by the first mid 436 value, unless the Answerer in the associated Answer will reject the 437 "m=" line associated with the mid value, or remove the "m=" line from 438 the BUNDLE group. In such case the Answerer MUST select an address 439 associated with the first unrejected mid value that remains in the 440 SDP group:BUNDLE attribute mid list of the Offer. 442 In the SDP Answer, the Answerer MUST place the mid value associated 443 with the selected Offerer's BUNDLE address first in the SDP 444 group:BUNDLE attribute mid list associated with the BUNDLE group. 446 Section 10.1 shows an example of an Offerer's BUNDLE address 447 selection. 449 6.5.2. Anwerer Bundle Address Selection 451 When an Answerer creates an Answer that contains a BUNDLE group, the 452 Answerer MUST assign a local shared address, the Answerer's BUNDLE 453 address, to each "m=" line within the BUNDLE group. 455 The Answerer is allowed to change its BUNDLE address in any SDP 456 Answer. 458 The Answerer MUST NOT assign a shared address, that it has assigned 459 to an "m=" line within a BUNDLE group, to an "m=" line outside the 460 BUNDLE group. 462 Section 10.1 shows an example of an Answerer's local BUNDLE address 463 selection. 465 6.5.3. Moving A Media Description Out Of A BUNDLE Group 467 When an Answerer generates an Answer, in which an "m=" line is moved 468 out of a BUNDLE group, the Answerer assigns an address to the moved 469 "m=" line based on the type of address that the Offerer assigned to 470 the associated "m=" line in the associated Offer, as described below. 472 If the Offerer assigned a shared address to the "m=" line, the 473 answerer MUST reject the moved "m=" line, according to the procedures 474 in Section 6.5.4. 476 If the Offerer assigned an SDP 'bundle-only' attribute to the "m=" 477 line, the Answerer MUST reject the moved "m=" line, according to the 478 procedures in Section 6.5.4. 480 If the Offerer assigned a unique address to the "m=" line, the Answer 481 MUST assign a unique address to the moved "m=" line. 483 In addition, in either case above, the Answerer MUST NOT anymore 484 include a mid value, representing the "m=" line, in the SDP 485 group:BUNDLE attribute list associated with the BUNDLE group. 487 6.5.4. Rejecting A Media Description In A BUNDLE Group 489 When an Answerer generates an Answer, in which an "m=" line 490 associated with a BUNDLE group is rejected, the Answerer MUST assign 491 an address with a zero port value to the rejected "m=" line, 492 according to the procedures in [RFC4566]. In addition, the Answerer 493 MUST NOT anymore include a mid value, representing the "m=" line, in 494 the SDP group:BUNDLE attribute midlist associated with the BUNDLE 495 group. 497 7. Single vs Multiple RTP Sessions 499 7.1. General 501 By default, all RTP based media flows within a given BUNDLE group 502 belong to a single RTP session [RFC3550]. Multiple BUNDLE groups 503 will form multiple RTP Sessions. 505 The usage of multiple RTP Sessions within a given BUNDLE group, or 506 the usage of a single RTP Session that spans over multiple BUNDLE 507 groups, is outside the scope of this specification. Other 508 specification needs to extend the BUNDLE mechanism in order to allow 509 such usages. 511 7.2. Single RTP Session 513 When a single RTP Session is used, media associated with all "m=" 514 lines part of a bundle group share a single SSRC [RFC3550] numbering 515 space. 517 In addition, the following rules and restrictions apply for a single 518 RTP Session: 520 o The dynamic payload type values used in the "m=" lines MUST NOT 521 overlap. 523 o The "proto" value in each "m=" line MUST be identical (e.g. RTP/ 524 AVPF). 526 o A given SSRC SHOULD NOT transmit RTP packets using payload types 527 that originates from different "m=" lines. 529 NOTE: The last bullet above is to avoid sending multiple media types 530 from the same SSRC. If transmission of multiple media types are done 531 with time overlap RTP and RTCP fails to function. Even if done in 532 proper sequence this causes RTP Timestamp rate switching issues [ref 533 to draft-ietf-avtext-multiple-clock-rates]. 535 8. Usage With ICE 537 8.1. General 539 This section describes how to use the BUNDLE grouping extension 540 together with the Interactive Connectivity Establishment (ICE) 541 mechanism [RFC5245]. 543 8.2. Candidates 545 When an ICE-enabled endpoint generates an SDP Offer, which contains a 546 BUNDLE group, the SDP Offerer MUST include ICE candidates for each 547 "m=" line associated with a "BUNDLE" group, except for any "m=" line 548 with a zero port number value. If the "m=" lines associated with the 549 BUNDLE group contain different port number values, the SDP Offerer 550 MUST also insert different candidate values in each "m=" line 551 associated with the BUNDLE group. If the "m=" lines associated with 552 the BUNDLE group contain an identical port number value, the 553 candidate values MUST also be identical. 555 When an ICE-enabled endpoint generates and SDP Answer, which contains 556 a BUNDLE group, the Answerer MUST include ICE candidates for each 557 "m=" line associated with the "BUNDLE" group, except for any "m=" 558 line where the port number value is set to zero. The Answerer MUST 559 insert identical candidate values in each "m=" line associated with 560 the BUNDLE group. 562 8.3. Candidates 564 Once it is known that both endpoints support, and accept to use, the 565 BUNDLE grouping extension, ICE connectivity checks and keep-alives 566 only needs to be performed for the whole BUNDLE group, instead of for 567 each individual "m=" line associated with the group. 569 9. Security Considerations 570 This specification does not significantly change the security 571 considerations of SDP which can be found in Section X of TBD. 573 TODO: Think carefully about security analysis of reuse of same SDES 574 key on multiple "m=" lines when the far end does not use BUNDLE and 575 warn developers of any risks. 577 10. Examples 579 10.1. Example: Bundle Address Selection 581 The example below shows: 583 o 1. An SDP Offer, in which the Offerer assigns unique addresses to 584 each "m=" line in the BUNDLE group, and requests the Answerer to 585 select the Offerer's BUNDLE address. 587 o 2. An SDP Answer, in which the Answerer selects the BUNDLE 588 address for the Offerer, and assigns its own local BUNDLE address 589 to each "m=" line in the BUNDLE group. 591 o 3. A subsequent SDP Offer, which is used to perform a Bundle 592 Address Synchronization (BAS). 594 SDP Offer (1) 596 v=0 597 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 598 s= 599 c=IN IP4 atlanta.example.com 600 t=0 0 601 a=group:BUNDLE foo bar 602 m=audio 10000 RTP/AVP 0 8 97 603 a=mid:foo 604 b=AS:200 605 a=rtpmap:0 PCMU/8000 606 a=rtpmap:8 PCMA/8000 607 a=rtpmap:97 iLBC/8000 608 m=video 10002 RTP/AVP 31 32 609 a=mid:bar 610 b=AS:1000 611 a=rtpmap:31 H261/90000 612 a=rtpmap:32 MPV/90000 614 SDP Answer (2) 615 v=0 616 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 617 s= 618 c=IN IP4 biloxi.example.com 619 t=0 0 620 a=group:BUNDLE foo bar 621 m=audio 20000 RTP/AVP 0 622 a=mid:foo 623 b=AS:200 624 a=rtpmap:0 PCMU/8000 625 m=video 20000 RTP/AVP 32 626 a=mid:bar 627 b=AS:1000 628 a=rtpmap:32 MPV/90000 630 SDP Offer (3) 632 v=0 633 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 634 s= 635 c=IN IP4 atlanta.example.com 636 t=0 0 637 a=group:BUNDLE foo bar 638 m=audio 10000 RTP/AVP 0 8 97 639 a=mid:foo 640 b=AS:200 641 a=rtpmap:0 PCMU/8000 642 a=rtpmap:8 PCMA/8000 643 a=rtpmap:97 iLBC/8000 644 m=video 10000 RTP/AVP 31 32 645 a=mid:bar 646 b=AS:1000 647 a=rtpmap:31 H261/90000 648 a=rtpmap:32 MPV/90000 650 10.2. Example: Bundle Mechanism Rejected 652 The example below shows: 654 o 1. An SDP Offer, in which the Offerer assigns unique addresses to 655 each "m=" line in the BUNDLE group, and requests the Answerer to 656 select the Offerer's BUNDLE address. 658 o 2. An SDP Answer, in which the Answerer rejects the BUNDLE group, 659 and assigns unique addresses to each "m=" line. 661 SDP Offer (1) 663 v=0 664 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 665 s= 666 c=IN IP4 atlanta.example.com 667 t=0 0 668 a=group:BUNDLE foo bar 669 m=audio 10000 RTP/AVP 0 8 97 670 a=mid:foo 671 b=AS:200 672 a=rtpmap:0 PCMU/8000 673 a=rtpmap:8 PCMA/8000 674 a=rtpmap:97 iLBC/8000 675 m=video 10002 RTP/AVP 31 32 676 a=mid:bar 677 b=AS:1000 678 a=rtpmap:31 H261/90000 679 a=rtpmap:32 MPV/90000 681 SDP Answer (2) 683 v=0 684 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 685 s= 686 c=IN IP4 biloxi.example.com 687 t=0 0 688 m=audio 20000 RTP/AVP 0 689 b=AS:200 690 a=rtpmap:0 PCMU/8000 691 m=video 30000 RTP/AVP 32 692 b=AS:1000 693 a=rtpmap:32 MPV/90000 695 10.3. Example: Offerer Adds A Media Description To A BUNDLE Group 697 The example below shows: 699 o 1. An SDP Offer, in which the Offerer adds an "m=" line, 700 represented by the "zen" mid value, to a previously negotiated 701 BUNDLE group, assigns a unique address to the added "m=" line, and 702 assigns the previously negotiated BUNDLE address to the previously 703 added "m=" lines in the BUNDLE group. 705 o 2. An SDP Answer, in which the Answerer assigns its own local 706 BUNDLE address to each "m=" line (including the added "m=" line) 707 in the BUNDLE group. 709 o 3. A subsequent SDP Offer, which is used to perform a Bundle 710 Address Synchronization (BAS). 712 SDP Offer (1) 714 v=0 715 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 716 s= 717 c=IN IP4 atlanta.example.com 718 t=0 0 719 a=group:BUNDLE foo bar zen 720 m=audio 10000 RTP/AVP 0 8 97 721 a=mid:foo 722 b=AS:200 723 a=rtpmap:0 PCMU/8000 724 a=rtpmap:8 PCMA/8000 725 a=rtpmap:97 iLBC/8000 726 m=video 10000 RTP/AVP 31 32 727 a=mid:bar 728 b=AS:1000 729 a=rtpmap:31 H261/90000 730 a=rtpmap:32 MPV/90000 731 m=video 20000 RTP/AVP 66 732 a=mid:zen 733 b=AS:1000 734 a=rtpmap:66 H261/90000 736 SDP Answer (2) 738 v=0 739 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 740 s= 741 c=IN IP4 biloxi.example.com 742 t=0 0 743 a=group:BUNDLE foo bar zen 744 m=audio 20000 RTP/AVP 0 745 a=mid:foo 746 b=AS:200 747 a=rtpmap:0 PCMU/8000 748 m=video 20000 RTP/AVP 32 749 a=mid:bar 750 b=AS:1000 751 a=rtpmap:32 MPV/90000 752 m=video 20000 RTP/AVP 66 753 a=mid:zen 754 b=AS:1000 755 a=rtpmap:66 H261/90000 757 SDP Offer (3) 759 v=0 760 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 761 s= 762 c=IN IP4 atlanta.example.com 763 t=0 0 764 a=group:BUNDLE foo bar zen 765 m=audio 10000 RTP/AVP 0 8 97 766 a=mid:foo 767 b=AS:200 768 a=rtpmap:0 PCMU/8000 769 a=rtpmap:8 PCMA/8000 770 a=rtpmap:97 iLBC/8000 771 m=video 10000 RTP/AVP 31 32 772 a=mid:bar 773 b=AS:1000 774 a=rtpmap:31 H261/90000 775 a=rtpmap:32 MPV/90000 776 m=video 10000 RTP/AVP 66 777 a=mid:zen 778 b=AS:1000 779 a=rtpmap:66 H261/90000 781 10.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 783 The example below shows: 785 o 1. An SDP Offer, in which the Offerer moves an "m=" line out of a 786 previously negotiated BUNDLE group, assigns a unique address to 787 the moved "m=" line, and assigns the previously negotiated BUNDLE 788 address to the remaining "m=" lines in the BUNDLE group. 790 o 2. An SDP Answer, in which the Answerer moves the corresponding 791 "m=" line out of the BUNDLE group, and assigns unique address to 792 the moved "m=" line, and assigns the previously negotiated BUNDLE 793 address to the remaining "m=" lines in the BUNDLE group. 795 SDP Offer (1) 797 v=0 798 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 799 s= 800 c=IN IP4 atlanta.example.com 801 t=0 0 802 a=group:BUNDLE foo bar 803 m=audio 10000 RTP/AVP 0 8 97 804 a=mid:foo 805 b=AS:200 806 a=rtpmap:0 PCMU/8000 807 a=rtpmap:8 PCMA/8000 808 a=rtpmap:97 iLBC/8000 809 m=video 10000 RTP/AVP 31 32 810 a=mid:bar 811 b=AS:1000 812 a=rtpmap:31 H261/90000 813 a=rtpmap:32 MPV/90000 814 m=video 50000 RTP/AVP 66 815 b=AS:1000 816 a=rtpmap:66 H261/90000 818 SDP Answer (2) 820 v=0 821 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 822 s= 823 c=IN IP4 biloxi.example.com 824 t=0 0 825 a=group:BUNDLE foo bar 826 m=audio 20000 RTP/AVP 0 827 a=mid:foo 828 b=AS:200 829 a=rtpmap:0 PCMU/8000 830 m=video 20000 RTP/AVP 32 831 a=mid:bar 832 b=AS:1000 833 a=rtpmap:32 MPV/90000 834 m=video 60000 RTP/AVP 66 835 b=AS:1000 836 a=rtpmap:66 H261/90000 838 10.5. Example: Offerer Disables A Media Description In A BUNDLE Group 840 The example below shows: 842 o 1. An SDP Offer, in which the Offerer moves an "m=" line out of a 843 previously negotiated BUNDLE group, assigns a zero port number the 844 moved "m=" line in order to disable it, and assigns the previously 845 negotiated BUNDLE address to the remaining "m=" lines in the 846 BUNDLE group. 848 o 2. An SDP Answer, in which the Answerer moves the corresponding 849 "m=" line out of the BUNDLE group, and assigns a zero port value 850 to the moved "m=" line in order to disable it, and assigns the 851 previously negotiated BUNDLE address to the remaining "m=" lines 852 in the BUNDLE group. 854 SDP Offer (1) 856 v=0 857 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 858 s= 859 c=IN IP4 atlanta.example.com 860 t=0 0 861 a=group:BUNDLE foo bar 862 m=audio 10000 RTP/AVP 0 8 97 863 a=mid:foo 864 b=AS:200 865 a=rtpmap:0 PCMU/8000 866 a=rtpmap:8 PCMA/8000 867 a=rtpmap:97 iLBC/8000 868 m=video 10000 RTP/AVP 31 32 869 a=mid:bar 870 b=AS:1000 871 a=rtpmap:31 H261/90000 872 a=rtpmap:32 MPV/90000 873 m=video 0 RTP/AVP 66 874 a=rtpmap:66 H261/90000 876 SDP Answer (2) 878 v=0 879 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 880 s= 881 c=IN IP4 biloxi.example.com 882 t=0 0 883 a=group:BUNDLE foo bar 884 m=audio 20000 RTP/AVP 0 885 a=mid:foo 886 b=AS:200 887 a=rtpmap:0 PCMU/8000 888 m=video 20000 RTP/AVP 32 889 a=mid:bar 890 b=AS:1000 891 a=rtpmap:32 MPV/90000 892 m=video 0 RTP/AVP 66 893 a=rtpmap:66 H261/90000 895 11. IANA Considerations 897 This document requests IANA to register the new SDP Grouping semantic 898 extension called BUNDLE. 900 12. Acknowledgements 902 The usage of the SDP grouping extension for negotiating bundled media 903 is based on a similar alternatives proposed by Harald Alvestrand and 904 Cullen Jennings. The BUNDLE mechanism described in this document is 905 based on the different alternative proposals, and text (e.g. SDP 906 examples) have been borrowed (and, in some cases, modified) from 907 those alternative proposals. 909 The SDP examples are also modified versions from the ones in the 910 Alvestrand proposal. 912 Thanks to Paul Kyzivat and Martin Thompson for taking the the time to 913 read the text along the way, and providing useful feedback. 915 13. Change Log 917 [RFC EDITOR NOTE: Please remove this section when publishing] 919 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 921 o Updated Offerer procedures (http://www.ietf.org/mail-archive/web/ 922 mmusic/current/msg12293.html). 924 o Updated Answerer procedures (http://www.ietf.org/mail-archive/web/ 925 mmusic/current/msg12333.html). 927 o Usage of SDP 'bundle-only' attribute added. 929 o Reference to Trickle ICE document added. 931 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 933 o Mechanism modified, to be based on usage of SDP Offers with both 934 different and identical port number values, depending on whether 935 it is known if the remote endpoint supports the extension. 937 o Cullen Jennings added as co-author. 939 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 941 o No changes. New version due to expiration. 943 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 945 o No changes. New version due to expiration. 947 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 949 o Draft name changed. 951 o Harald Alvestrand added as co-author. 953 o "Multiplex" terminology changed to "bundle". 955 o Added text about single versus multiple RTP Sessions. 957 o Added reference to RFC 3550. 959 14. References 961 14.1. Normative References 963 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 964 Requirement Levels", BCP 14, RFC 2119, March 1997. 966 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 967 with Session Description Protocol (SDP)", RFC 3264, June 968 2002. 970 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 971 Description Protocol", RFC 4566, July 2006. 973 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 974 Control Packets on a Single Port", RFC 5761, April 2010. 976 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 977 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 979 [I-D.nandakumar-mmusic-sdp-mux-attributes] 980 Nandakumar, S. and C. Jennings, "A Framework for SDP 981 Attributes when Multiplexing ", draft-nandakumar-mmusic- 982 sdp-mux-attributes-04 (work in progress), September 2013. 984 14.2. Informative References 986 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 987 Jacobson, "RTP: A Transport Protocol for Real-Time 988 Applications", STD 64, RFC 3550, July 2003. 990 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 991 in Session Description Protocol (SDP)", RFC 3605, October 992 2003. 994 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 995 (ICE): A Protocol for Network Address Translator (NAT) 996 Traversal for Offer/Answer Protocols", RFC 5245, April 997 2010. 999 [I-D.ietf-mmusic-trickle-ice] 1000 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 1001 Incremental Provisioning of Candidates for the Interactive 1002 Connectivity Establishment (ICE) Protocol ", draft-ietf- 1003 mmusic-trickle-ice-00 (work in progress), October 2013. 1005 Appendix A. Design Considerations 1007 A.1. General 1009 One of the main issues regarding the BUNDLE grouping extensions has 1010 been whether, in SDP Offers and SDP Answers, the same port number 1011 value should be inserted in "m=" lines associated with a BUNDLE 1012 group, as the purpose of the extension is to negotiate the usage of a 1013 single 5-tuple for media associated with the "m=" lines. Issues with 1014 both approaches, discussed in the Appendix have been raised. The 1015 outcome was to specify a mechanism which uses SDP Offers with both 1016 different and identical port number values. 1018 Below are the primary issues that have been considered when defining 1019 the "BUNDLE" grouping extension: 1021 o 1) Interoperability with existing UAs. 1023 o 2) Interoperability with intermediary B2BUA- and proxy entities. 1025 o 3) Time to gather, and the number of, ICE candidates. 1027 o 4) Different error scenarios, and when they occur. 1029 o 5) SDP Offer/Answer impacts, including usage of port number value 1030 zero. 1032 NOTE: Before this document is published as an RFC, this 1033 Appendix might be removed. 1035 A.2. UA Interoperability 1037 Consider the following SDP Offer/Answer exchange, where Alice sends 1038 an SDP Offer to Bob: 1040 SDP Offer 1042 v=0 1043 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1044 s= 1045 c=IN IP4 atlanta.example.com 1046 t=0 0 1047 m=audio 10000 RTP/AVP 97 1048 a=rtpmap:97 iLBC/8000 1049 m=video 10002 RTP/AVP 97 1050 a=rtpmap:97 H261/90000 1052 SDP Answer 1054 v=0 1055 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1056 s= 1057 c=IN IP4 biloxi.example.com 1058 t=0 0 1059 m=audio 20000 RTP/AVP 97 1060 a=rtpmap:97 iLBC/8000 1061 m=video 20002 RTP/AVP 97 1062 a=rtpmap:97 H261/90000 1064 RFC 4961 specifies a way of doing symmetric RTP but that is an a 1065 later invention to RTP and Bob can not assume that Alice supports RFC 1066 4961. This means that Alice may be sending RTP from a different port 1067 than 10000 or 10002 - some implementation simply send the RTP from an 1068 ephemeral port. When Bob's endpoint receives an RTP packet, the only 1069 way that Bob know if it should be passed to the video or audio codec 1070 is by looking at the port it was received on. This lead some SDP 1071 implementations to use the fact that each "m=" line had a different 1072 port number to use that port number as an index to find the correct m 1073 line in the SDP. As a result, some implementations that do support 1074 symmetric RTP and ICE still use a SDP data structure where SDP with 1075 "m=" lines with the same port such as: 1077 SDP Offer 1079 v=0 1080 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1081 s= 1082 c=IN IP4 atlanta.example.com 1083 t=0 0 1084 m=audio 10000 RTP/AVP 97 1085 a=rtpmap:97 iLBC/8000 1086 m=video 10000 RTP/AVP 98 1087 a=rtpmap:98 H261/90000 1089 will result in the second "m=" line being considered an SDP error 1090 because it has the same port as the first line. 1092 A.3. Usage of port number value zero 1094 In an SDP Offer or SDP Answer, the media associated with an "m=" line 1095 can be disabled/rejected by setting the port number value to zero. 1096 This is different from e.g. using the SDP direction attributes, where 1097 RTCP traffic will continue even if the SDP "inactive" attribute is 1098 indicated for the associated "m=" line. 1100 If each "m=" line associated with a BUNDLE group would contain 1101 different port number values, and one of those port would be used for 1102 the 5-tuple, problems would occur if an endpoint wants to disable/ 1103 reject the "m=" line associated with that port, by setting the port 1104 number value to zero. After that, no "m=" line would contain the 1105 port number value which is used for the 5-tuple. In addition, it is 1106 unclear what would happen to the ICE candidates associated with the 1107 "m=" line, as they are also used for the 5-tuple. 1109 A.4. B2BUA And Proxy Interoperability 1111 Some back to back user agents may be configured in a mode where if 1112 the incoming call leg contains an SDP attribute the B2BUA does not 1113 understand, the B2BUS still generates that SDP attribute in the Offer 1114 for the outgoing call leg. Consider an B2BUA that did not understand 1115 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 1116 Further assume that the B2BUA was configured to tear down any call 1117 where it did not see any RTCP for 5 minutes. In this cases, if the 1118 B2BUA received an Offer like: 1120 SDP Offer 1122 v=0 1123 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1124 s= 1125 c=IN IP4 atlanta.example.com 1126 t=0 0 1127 m=audio 49170 RTP/AVP 0 1128 a=rtcp:53020 1130 It would be looking for RTCP on port 49172 but would not see any 1131 because the RTCP would be on port 53020 and after five minutes, it 1132 would tear down the call. Similarly, an SBC that did not understand 1133 BUNDLE yet put BUNDLE in it's offer may be looking for media on the 1134 wrong port and tear down the call. It is worth noting that a B2BUA 1135 that generated an Offer with capabilities it does not understand is 1136 not compliant with the specifications. 1138 A.4.1. Traffic Policing 1140 Sometimes intermediaries do not act as B2BUA, in the sense that they 1141 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 1142 however, they may use SDP information (e.g. IP address and port) in 1143 order to control traffic gating functions, and to set traffic 1144 policing rules. There might be rules which will trigger a session to 1145 be terminated in case media is not sent or received on the ports 1146 retrieved from the SDP. This typically occurs once the session is 1147 already established and ongoing. 1149 A.4.2. Bandwidth Allocation 1151 Sometimes intermediaries do not act as B2BUA, in the sense that they 1152 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 1153 however, they may use SDP information (e.g. codecs and media types) 1154 in order to control bandwidth allocation functions. The bandwidth 1155 allocation is done per "m=" line, which means that it might not be 1156 enough if media associated with all "m=" lines try to use that 1157 bandwidth. That may either simply lead to bad user experience, or to 1158 termination of the call. 1160 A.5. Candidate Gathering 1162 When using ICE, an candidate needs to be gathered for each port. 1163 This takes approximately 20 ms extra for each extra "m=" line due to 1164 the NAT pacing requirements. All of this gather can be overlapped 1165 with other things while the page is loading to minimize the impact. 1166 If the client only wants to generate TURN or STUN ICE candidates for 1167 one of the "m=" lines and then use trickle ICE 1168 [I-D.ietf-mmusic-trickle-ice] to get the non host ICE candidates for 1169 the rest of the "m=" lines, it MAY do that and will not need any 1170 additional gathering time. 1172 Some people have suggested a TURN extension to get a bunch of TURN 1173 allocation at once. This would only provide a single STUN result so 1174 in cases where the other end did not support BUNDLE, may cause more 1175 use of the TURN server but would be quick in the cases where both 1176 sides supported BUNDLE and would fall back to a successful call in 1177 the other cases. 1179 Authors' Addresses 1181 Christer Holmberg 1182 Ericsson 1183 Hirsalantie 11 1184 Jorvas 02420 1185 Finland 1187 Email: christer.holmberg@ericsson.com 1189 Harald Tveit Alvestrand 1190 Google 1191 Kungsbron 2 1192 Stockholm 11122 1193 Sweden 1195 Email: harald@alvestrand.no 1196 Cullen Jennings 1197 Cisco 1198 400 3rd Avenue SW, Suite 350 1199 Calgary, AB T2P 4H2 1200 Canada 1202 Email: fluffy@iii.ca