idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-07.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3264, but the abstract doesn't seem to directly say this. It does mention RFC3264 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3264, updated by this document, for RFC5378 checks: 2002-01-31) -- 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 (April 23, 2014) is 3654 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Section 8' is mentioned on line 283, but not defined == Missing Reference: 'Section 6' is mentioned on line 284, but not defined == Missing Reference: 'Section 9' is mentioned on line 286, but not defined -- Looks like a reference, but probably isn't: '10' on line 1005 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-01 -- 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-01 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 5 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 Updates: 3264 (if approved) H. Alvestrand 5 Intended status: Standards Track Google 6 Expires: October 25, 2014 C. Jennings 7 Cisco 8 April 23, 2014 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-07.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 sending and 20 receiving media associated with multiple SDP media descriptions ("m=" 21 lines). 23 This specification also updates sections 5.1, 8.1 and 8.2 of RFC 24 3264, in order to allow an answerer to in an SDP answer assign a non- 25 zero port value to an "m=" line, even if the offerer in the 26 associated SDP offer had assigned a zero port value to the "m=" line. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 25, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 66 5. SDP Grouping Framework BUNDLE Extension Semantics . . . . . . 6 67 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 6 69 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 70 5.2.2. SDP Information Considerations . . . . . . . . . . . 7 71 5.2.3. Generating the Initial SDP Offer . . . . . . . . . . 8 72 5.2.4. Generating the SDP Answer . . . . . . . . . . . . . . 8 73 5.2.5. Offerer Processing of the SDP Answer . . . . . . . . 10 74 5.2.6. Modifying the Session . . . . . . . . . . . . . . . . 11 75 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 13 76 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 6.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 13 78 6.2.1. Generating the Initial SDP Offer . . . . . . . . . . 13 79 6.2.2. Generating the SDP Answer . . . . . . . . . . . . . . 13 80 6.2.3. Offerer Processing of the SDP Answer . . . . . . . . 14 81 6.2.4. Modifying the Session . . . . . . . . . . . . . . . . 14 82 7. Protocol Identification . . . . . . . . . . . . . . . . . . . 15 83 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 7.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 15 85 8. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 8.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 15 87 8.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 16 88 8.1.2. Payload Type (PT) Value Re-usage . . . . . . . . . . 16 89 8.2. Associating RTP Packets With Correct SDP Media 90 Description . . . . . . . . . . . . . . . . . . . . . . . 16 91 8.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 17 92 8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 17 93 8.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . 18 94 9. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 20 95 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 9.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 20 97 9.2.1. Generating the Initial SDP Offer . . . . . . . . . . 20 98 9.2.2. Generating the SDP Answer . . . . . . . . . . . . . . 20 99 9.2.3. Offerer Processing of the SDP Answer . . . . . . . . 20 100 9.2.4. Modifying the Session . . . . . . . . . . . . . . . . 20 101 9.2.5. Keep-alives . . . . . . . . . . . . . . . . . . . . . 20 102 10. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 21 103 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 21 104 10.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 21 105 10.3. New text replacing section 5.1 (2nd paragraph) of RFC 106 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 107 10.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 22 108 10.5. New text replacing section 8.2 (2nd paragraph) of RFC 109 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 110 10.6. Original text of section 8.4 (6th paragraph) of RFC 3264 22 111 10.7. New text replacing section 8.4 (6th paragraph) of RFC 112 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 113 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 114 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23 115 12.1. Example: Bundle Address Selection . . . . . . . . . . . 23 116 12.2. Example: Bundle Mechanism Rejected . . . . . . . . . . . 24 117 12.3. Example: Offerer Adds A Media Description To A BUNDLE 118 Group . . . . . . . . . . . . . . . . . . . . . . . . . 25 119 12.4. Example: Offerer Moves A Media Description Out Of A 120 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 27 121 12.5. Example: Offerer Disables A Media Description Within A 122 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 30 123 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 124 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 125 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 32 126 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 127 16.1. Normative References . . . . . . . . . . . . . . . . . . 34 128 16.2. Informative References . . . . . . . . . . . . . . . . . 34 129 Appendix A. Design Considerations . . . . . . . . . . . . . . . 35 130 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 35 131 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 36 132 A.3. Usage of port number value zero . . . . . . . . . . . . . 37 133 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 37 134 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 38 135 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 38 136 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 39 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 139 1. Introduction 141 In the IETF RTCWEB WG, a need to use a single 5-tuple for sending and 142 receiving media associated with multiple SDP media descriptions ("m=" 143 lines) has been identified. This would e.g. allow the usage of a 144 single set of Interactive Connectivity Establishment (ICE) [RFC5245] 145 candidates for multiple media descriptions. Normally different media 146 types (audio, video etc) will be described using different media 147 descriptions. 149 This specification defines a new SDP Grouping Framework [RFC5888] 150 extension, "BUNDLE", that can be used with the Session Description 151 Protocol (SDP) Offer/Answer mechanism [RFC3264] to negotiate the 152 usage of bundled media, which refers to the usage of a single 5-tuple 153 for sending and receiving media associated with multiple SDP media 154 descriptions ("m=" lines). 156 The offerer and answerer [RFC3264] use the BUNDLE mechanism to 157 negotiate BUNDLE addresses, one for the offerer (offerer BUNDLE 158 address) and one for the answerer (answerer BUNDLE address) to be 159 used for the bundled media associated with a BUNDLE group. 161 Once the offerer and the answerer have negotiated a BUNDLE group, and 162 the associated BUNDLE addresses, each endpoint can assign its BUNDLE 163 address to each "m=" line within, and use the address to send and 164 receive all media associated with, the BUNDLE group. 166 NOTE: As defined in RFC 4566 [RFC4566], the semantics of assigning 167 the same port value to multiple "m=" lines are undefined, and there 168 is no grouping defined by such means. Instead, an explicit grouping 169 mechanism needs to be used to express the intended semantics. This 170 specification provides such an extension. 172 SDP bodies can contain multiple BUNDLE groups. Each BUNDLE group 173 MUST use a unique 5-tuple. Any given "m=" line can only be 174 associated with a single BUNDLE group. 176 The procedures in this specification apply independently to a given 177 BUNDLE group. 179 All Real-time Transport Protocol (RTP) [RFC3550] based media flows 180 associated with a single BUNDLE group belong to a single RTP session 181 [RFC3550]. 183 The BUNDLE mechanism is backward compatible. Endpoints that do not 184 support the BUNDLE mechanism are expected to generate SDP offers and 185 SDP answers without an SDP 'group:BUNDLE' attribute, and are expected 186 to assign a unique address to each "m=" line within an SDP offer and 187 SDP answer, according to the procedures in [RFC4566] and [RFC3264] 189 This specification also updates sections 5.1, 8.1 and 8.2 of 190 [RFC3264], in order to allow an answerer to assign a non-zero port 191 value to an "m=" line in an SDP answer, even if the offerer in the 192 associated SDP offer had assigned a zero port value to the "m=" line. 194 2. Terminology 196 5-tuple: A collection of the following values: source address, source 197 port, destination address, destination port and protocol. 199 Unique address: An IP address and IP port combination that is 200 assigned to a single "m=" line in an SDP offer or SDP answer. 202 Shared address: An IP address and IP port combination that is 203 assigned to multiple "m=" lines in an SDP offer or SDP answer. 205 Offerer suggested BUNDLE mid: The first mid value in a given SDP 206 'group:BUNDLE' attribute mid list in an SDP offer. 208 Answerer selected BUNDLE mid: The first mid value in a given SDP 209 'group:BUNDLE' attribute mid list in an SDP answer. 211 Offerer BUNDLE address: Within a given BUNDLE group, an IP address 212 and IP port combination used by an offerer to receive all media 213 associated with each "m=" line within the BUNDLE group. 215 Answerer BUNDLE address: Within a given BUNDLE group, an IP address 216 and IP port combination used by an answerer to receive all media 217 associated with each "m=" line within the BUNDLE group. 219 BUNDLE group: A set of "m=" lines, created using an SDP offer/answer 220 exchange, for which a single 5-tuple is used to send and receive 221 media. Each endpoint uses its BUNDLE address, associated with the 222 BUNDLE group, to send and receive the media. 224 Bundled "m=" line: An "m=" line, in an SDP offer or SDP answer, 225 associated with a BUNDLE group. 227 Bundle-only "m=" line: An "m=" line, to which an SDP 'bundle-only' 228 attribute has been assigned. 230 Bundled media: All media associated with a BUNDLE group. 232 Initial SDP offer: The first SDP offer, within an SDP session, in 233 which the offerer indicates that it wants to create a given BUNDLE 234 group. 236 Subsequent SDP offer: An SDP offer which contains a BUNDLE group that 237 has been created as part of a previous SDP offer/answer exchange. 239 3. Conventions 241 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 242 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 243 document are to be interpreted as described in BCP 14, RFC 2119 244 [RFC2119]. 246 4. Applicability Statement 248 The mechanism in this specification only applies to the Session 249 Description Protocol (SDP) [RFC4566], when used together with the SDP 250 Offer/Answer mechanism [RFC3264]. 252 5. SDP Grouping Framework BUNDLE Extension Semantics 254 5.1. General 256 This section defines a new SDP Grouping Framework extension, BUNDLE. 258 The BUNDLE extension can be indicated using an SDP session-level 259 'group' attribute. Each SDP Media Description ("m=" line) that is 260 grouped together, using SDP media-level mid attributes, belongs to a 261 given BUNDLE group. 263 5.2. SDP Offer/Answer Procedures 265 5.2.1. General 267 This section describes usage of the SDP offer/answer mechanism 268 [RFC3264] for negotiating usage of the BUNDLE mechanism, for creating 269 a BUNDLE group, for selecting the BUNDLE addresses (offerer BUNDLE 270 address and answerer BUNDLE address), for adding an "m=" line to a 271 BUNDLE group, for moving an "m=" line out of a BUNDLE group, and for 272 disabling an "m=" line within a BUNDLE group. 274 The generic rules and procedures defined in [RFC3264] and [RFC5888] 275 also apply to the BUNDLE mechanism. For example, if an SDP offer is 276 rejected by the answerer, the previously negotiated SDP parameters 277 and characteristics (including those associated with a BUNDLE group) 278 apply. Hence, if an offerer generates an SDP offer in which the 279 offerer wants to create a BUNDLE group, and the answerer rejects the 280 SDP offer, the BUNDLE group is not created. 282 The procedures in this section are independent of the media type or 283 transport protocol represented by a bundled "m=" line. [Section 8] 284 defines additional considerations for RTP based media. [Section 6] 285 defines additional considerations for the usage of the SDP 'bundle- 286 only' attribute. [Section 9] defines additional considerations for 287 the usage of Interactive Connectivity Establishment (ICE) mechanism 288 [RFC5245]. 290 5.2.2. SDP Information Considerations 292 5.2.2.1. General 294 This section describes restrictions associated with the usage of SDP 295 parameters within a BUNDLE group. It also describes, when parameter 296 and attribute values have been assigned to each bundled "m=" line, 297 how to calculate a value for the whole BUNDLE group. 299 5.2.2.2. Connection Data (c=) 301 The "c=" line nettype value [RFC4566] assigned to a bundled "m=" line 302 MUST be 'IN'. 304 The "c=" line addrtype value [RFC4566] assigned to a bundled "m=" 305 line MUST be 'IP4' or 'IP6'. The same value MUST be assigned to each 306 "m=" line. 308 NOTE: Extensions to this specification can specify usage of the 309 BUNDLE mechanism for other nettype and addrtype values than the ones 310 listed above. 312 5.2.2.3. Bandwidth (b=) 314 The total proposed bandwidth is the sum of the proposed bandwidth for 315 each bundled "m=" line. 317 5.2.2.4. Attributes (a=) 319 [I-D.nandakumar-mmusic-sdp-mux-attributes] defines rules and 320 restrictions for assigning different types of SDP attributes to a 321 bundled "m=" line. 323 5.2.3. Generating the Initial SDP Offer 325 5.2.3.1. General 327 When an offerer generates an initial SDP offer, in order to create a 328 BUNDLE group, the offerer MUST in the SDP offer assign a unique 329 address to each "m=" line with a non-zero port value, following the 330 procedures in [RFC3264]. 332 The offerer MUST in the SDP offer insert an SDP session level 333 'group:BUNDLE' attribute, associated with the BUNDLE group, and 334 assign an SDP 'mid' attribute [RFC5888] to each "m=" line that the 335 offerer wants to be within the BUNDLE group, and place the 'mid' 336 attribute value in the 'group:BUNDLE' attribute mid list. 338 [Section 12.1] shows an example of an initial SDP offer. 340 5.2.3.2. Request offerer BUNDLE address selection 342 When an offerer generates an initial SDP offer, in order to create a 343 BUNDLE group, the offerer MUST in the SDP offer indicate which unique 344 address, associated with one of the "m=" lines that the offerer wants 345 to be within the BUNDLE group, that the offerer wants the answerer to 346 select as the offerer BUNDLE address [Section 5.2.4.2]. In the SDP 347 offer, the offerer BUNDLE mid value represents that address. 349 5.2.4. Generating the SDP Answer 351 5.2.4.1. RFC 5888 restrictions 353 When an answerer generates an SDP answer, the following restrictions, 354 defined in [RFC5888], also apply a BUNDLE group: 356 o 1) The answerer MUST NOT in the SDP answer include a BUNDLE group, 357 unless the offerer in the associated SDP offer requested the 358 BUNDLE group to be created; and 360 o 2) The answerer MUST NOT in the SDP answer include an "m=" line 361 within a BUNDLE group, unless the offerer in the associated SDP 362 offer requested the "m=" line to be within the BUNDLE group. 364 5.2.4.2. Answerer Selection of Offerer Bundle Address 366 When an answerer generates an SDP answer, it MUST select a BUNDLE 367 address for the offerer, referred to as the offerer BUNDLE address. 368 The answerer MUST select an address which the offerer in the 369 associated SDP offer requested to be within the BUNDLE group. 371 In the SDP offer, the offerer suggested BUNDLE mid represents the 372 "m=" line to which the offerer in the SDP offer has assigned the 373 address that it wants the answerer to select as the offerer BUNDLE 374 address [Section 5.2.3.2]. The answerer MUST first select the "m=" 375 line associated with the offerer suggested BUNDLE mid, and check 376 whether it fulfils the following criteria: 378 o The answerer will in the SDP answer create the BUNDLE group; 380 o The answerer will not in the SDP answer move the "m=" line out of 381 the BUNDLE group [Section 5.2.4.4]; 383 o The answerer will not in the SDP answer reject the "m=" line 384 [Section 5.2.4.5]; and 386 o The offerer did not in the associated SDP offer assign a zero port 387 value to the "m=" line. 389 If all of the criteria above is fulfilled, the answerer MUST select 390 the address associated with the "m=" line as the offerer BUNDLE 391 address. 393 If all of the criteria is not fulfilled, the answerer MUST select the 394 next mid value in the mid list, and perform the same criteria check 395 for the "m=" line associated with the mid value. 397 In the SDP answer, the answerer selected BUNDLE mid value represents 398 the "m=" line which address (in the associated SDP offer) the 399 answerer has selected as the offerer BUNDLE address. 401 [Section 12.1] shows an example of an offerer BUNDLE address 402 selection. 404 5.2.4.3. Answerer Selection of Answerer BUNDLE Address 406 When an answerer generates an SDP answer, the answerer MUST select a 407 BUNDLE address for itself, referred to as the answerer BUNDLE 408 address, and in the SDP answer assign the answerer BUNDLE address to 409 each "m=" line within the created BUNDLE group. 411 The answerer MUST NOT in the SDP answer assign the answerer BUNDLE 412 address to an "m=" line that is not associated with the BUNDLE group, 413 or to an "m=" line that is associated with another BUNDLE group. 415 The answerer is allowed to select a new answerer BUNDLE address in 416 every SDP answer that the answerer generates. 418 [Section 12.1] shows an example of an answerer BUNDLE address 419 selection. 421 5.2.4.4. Moving A Media Description Out Of A BUNDLE Group 423 When an answerer generates an SDP answer, in which the answerer moves 424 a bundled "m=" line out a BUNDLE group, the answerer assigns an 425 address to the moved "m=" line based on the type of address that the 426 offerer in the associated SDP offer assigned to the "m=" line. 428 o If the offerer in the SDP offer has assigned a shared address 429 (e.g. a previously selected offerer BUNDLE address) to the "m=" 430 line, the answerer MUST in the SDP answer reject the moved "m=" 431 line, according to the procedures in [Section 5.2.4.5]. 433 o If the offerer in the SDP offer assigned an SDP 'bundle-only' 434 attribute to the "m=" line, the answerer MUST in the SDP answer 435 reject the moved "m=" line, according to the procedures in 436 [Section 5.2.4.5]. 438 o If the offerer in the SDP offer assigned a unique address to the 439 "m=" line, the answerer MUST in the SDP answer assign a unique 440 address to the moved "m=" line. 442 In addition, in either case above, the answerer MUST NOT in the SDP 443 answer include a mid value, associated with the moved "m=" line, in 444 the SDP 'group:BUNDLE' attribute mid list associated with the BUNDLE 445 group. 447 5.2.4.5. Rejecting A Media Description In A BUNDLE Group 449 When an answerer generates an SDP answer, in which the answerer 450 rejects an "m=" line, the answerer MUST in the SDP answer assign an 451 address with a zero port value to the rejected "m=" line, according 452 to the procedures in [RFC4566]. 454 In addition, the answerer MUST NOT in the SDP answer include a mid 455 value, associated with the rejected "m=" line, in the SDP 456 'group:BUNDLE' attribute mid list associated with the BUNDLE group. 458 5.2.5. Offerer Processing of the SDP Answer 460 5.2.5.1. General 462 When an offerer receives an SDP answer, the offerer MUST apply the 463 selected offerer BUNDLE address to each bundled "m=" line. If the 464 offerer generates a subsequent SDP offer, the offerer MUST in the SDP 465 offer assign the offerer BUNDLE address to each bundled "m=" line 466 (including any 'bundle-only' "m=" line) [Section 5.2.6]. 468 If the SDP answer does not contain a BUNDLE group, the offerer MUST 469 cease to use any procedure associated with the BUNDLE mechanism. 471 5.2.5.2. Bundle Address Synchronization (BAS) 473 If the selected offerer BUNDLE address is different than the address 474 that the offerer in the associated SDP offer assigned to a bundled 475 "m=" line (including an "m=" line that the offerer in the SDP offer 476 added to an existing BUNDLE group [Section 5.2.6.2]), and the bundled 477 "m=" line was not rejected [Section 5.2.4.5], or moved out of the 478 BUNDLE group [Section 5.2.4.4] by the answerer, the offerer SHOULD as 479 soon as possible generate a subsequent SDP offer, in which the 480 offerer assigns the offerer BUNDLE address to each bundled "m=" line. 481 This procedure is referred to as Bundle Address Synchronization 482 (BAS), and the SDP offer is referred to as a BAS Offer. 484 The offerer MAY in the BAS offer modify any SDP parameter. 486 NOTE: It is important that the BAS offer gets accepted by the 487 answerer. For that reason the offerer needs to consider the 488 necessity to in the BAS offer modify SDP parameters that could get 489 the answerer to reject the BAS offer. Disabling "m=" lines, or 490 reducing the number of codecs, in a BAS offer is considered to have a 491 low risk of being rejected. 493 NOTE: The main purpose of the BAS offer is to ensure that 494 intermediaries, that might not support the BUNDLE mechanism, have 495 correct information regarding the address is going to be used to 496 transport the bundled media. 498 [Section 12.1] shows an example where an offerer sends a BAS offer. 500 5.2.6. Modifying the Session 502 5.2.6.1. General 504 When an offerer generates a subsequent SDP offer, the offerer MUST in 505 the SDP offer assign the previously selected offerer BUNDLE address 506 [Section 5.2.4.2] to each bundled "m=" line (including any bundle- 507 only "m=" line), unless the offerer in the SDP offer moves the "m=" 508 line out of the BUNDLE group [Section 5.2.6.3], or disables the "m=" 509 line [Section 5.2.6.4]. 511 If the SDP offerer in the SDP offer adds an "m=" line to the BUNDLE 512 group [Section 5.2.6.2], the offerer MAY assign the previously 513 selected offerer BUNDLE address to the added "m=" line. 515 In addition, the offerer MUST in the SDP offer indicate which address 516 (unique or previously selected offerer BUNDLE address) it wants the 517 answerer to select as the offerer BUNDLE address, following the 518 procedures in [Section 5.2.3.2]. The offerer MUST do this even if 519 the offerer in the SDP offer assigns a previously selected offerer 520 BUNDLE address to each bundled "m=" line. 522 5.2.6.2. Adding a media description to a BUNDLE group 524 When an offerer generates an SDP offer, in which the offerer wants to 525 add an "m=" line to a BUNDLE group, the offerer assigns in the SDP 526 offer an address (unique or previously selected offerer BUNDLE 527 address) to the "m=" line, assigns an SDP 'mid' attribute to the "m=" 528 line, and places the mid value in the SDP 'group:BUNDLE' attribute 529 mid list associated with the BUNDLE group [Section 5.2.3.2]. 531 NOTE: If the offerer wants the answerer to select the address 532 associated with the added "m=" as the offerer BUNDLE address, the 533 offerer suggested BUNDLE mid MUST represent the added "m=" line 534 [Section 5.2.3.2]. 536 [Section 12.3] shows an example where an offerer sends an SDP offer 537 in order to add an "m=" line to a BUNDLE group. 539 5.2.6.3. Moving A Media Description Out Of A BUNDLE Group 541 When an offerer generates an SDP offer, in which the offerer wants to 542 move a bundled "m=" line out of a BUNDLE group, the offerer MUST 543 assign a unique address to the "m=" line. In addition, the offerer 544 MUST NOT place a mid value associated with the "m=" line in the SDP 545 'group:BUNDLE' attribute mid list associated with the BUNDLE group. 547 NOTE: The offerer MAY keep a previously assigned SDP 'mid' attribute 548 in an "m=" line that it wants to move out of a BUNDLE group, e.g. if 549 the mid value is used for some other SDP grouping extension than 550 BUNDLE. 552 [Section 12.4] shows an example where an offerer sends an SDP offer 553 in order to move an "m=" line out of a BUNDLE group. 555 5.2.6.4. Disabling A Media Description In A BUNDLE Group 557 When an offerer generates an SDP offer, in which the offerer wants to 558 disable a bundled "m=" line, the offerer MUST assign an address with 559 a zero port alue to the "m=" line, following the procedures in 560 [RFC4566]. In addition, the offerer MUST NOT place a mid value 561 associated with the "m=" line in the SDP 'group:BUNDLE' attribute mid 562 list associated with the BUNDLE group. 564 NOTE: The offerer MAY assign an SDP 'mid' attribute to an "m=" line 565 that it wants to disable, e.g. if the mid value is used for some 566 other SDP grouping extension than BUNDLE. 568 [Section 12.5] shows an example where an offerer sends an SDP offer 569 in order to disable an "m=" line within a BUNDLE group. 571 6. SDP 'bundle-only' Attribute 573 6.1. General 575 This section defines a new SDP media-level attribute [RFC4566], 576 'bundle-only'. An offerer can in an SDP offer assign a 'bundle-only' 577 "m=" line to a bundled "m=" line (including an "m=" line that the 578 offerer wants to add to the BUNDLE group [Section 5.2.6.2]), in order 579 to ensure that the answerer only accepts the "m=" line if the 580 answerer supports the BUNDLE mechanism, and if the answerer in the 581 SDP answer keeps the "m=" line within the BUNDLE group. 583 6.2. SDP Offer/Answer Procedures 585 6.2.1. Generating the Initial SDP Offer 587 When an offerer generates an initial SDP offer, in order to create a 588 BUNDLE group, the offerer can in the SDP offer assign an SDP 'bundle- 589 only' attribute to an "m=" line that the offerer wants to be within 590 the BUNDLE group. 592 The offerer MUST in the SDP offer assign a zero port value the 593 bundle-only "m=" line. 595 6.2.2. Generating the SDP Answer 597 When the answerer selects the offerer BUNDLE address 598 [Section 5.2.4.2], the answerer MUST also take a bundle-only "m=" 599 line with a non-zero port value into consideration. 601 If the offerer in the SDP offer has assigned a zero port value to a 602 bundle-only "m=" line, and if the answerer accepts the "m=" line, the 603 answerer will treat the "m=" line as any other bundle "m=" line when 604 the answerer generates the SDP answer [Section 5.2.4]. 606 NOTE: If the offerer in the SDP offer has assigned a zero port value 607 to a bundled "m=" line, but the offerer has not assigned a 'bundle- 608 only' SDP attribute to the "m=" line, it is an indication that the 609 offerer wants to disable the "m=" line [Section 5.2.6.4]. 611 If the answerer in the SDP answer does not keep the bundle-only "m=" 612 line within the BUNDLE group, the answerer MUST in the SDP answer 613 reject the "m=" line [Section 5.2.4.5]. 615 The answerer MUST NOT in the SDP answer assign an SDP 'bundle-only' 616 attribute to an "m=" line (even if the offerer in the associated SDP 617 offer has assigned a 'bundle-only' attribute to the "m="line). 619 6.2.3. Offerer Processing of the SDP Answer 621 When the offerer receives an SDP answer, the offerer follows the 622 procedures in [Section 5.2.5]. If the offerer in the associated SDP 623 offer assigned an SDP 'bundle-only' attribute to an "m=" line, and 624 the "m=" line was accepted (and was kept within the BUNDLE group) by 625 the answerer, the selected offerer BUNDLE address also applies to the 626 "m=" line. 628 6.2.4. Modifying the Session 630 When an offerer creates a subsequent SDP offer, the offerer follows 631 the procedures in [Section 5.2.6]. If the offerer in the SDP offer 632 assigns an SDP 'bundle-only' attribute to a bundled "m=" line, in 633 order to ensure that the answerer accepts the "m=" line only if the 634 answerer keeps the "m=" line within the BUNDLE group, the offerer 635 MUST NOT assign a zero port value to the "m=" line. Instead, the 636 offerer MUST in the SDP offer assign the offerer BUNDLE address or, 637 if the "m=" line is added to the BUNDLE group [Section 5.2.6.2], 638 either the offerer BUNDLE address or a unique address, to the "m=" 639 line. 641 NOTE: The offerer can in a subsequent SDP offer assign an SDP 642 'bundle-only' attribute to a bundled "m=" line even if the offerer 643 did not assign a 'bundle-only' attribute to the "m=" line in a 644 previous SDP offer. 646 If the offerer in the SDP offer wants to move a bundled "m=" line out 647 of a BUNDLE group [Section 5.2.6.3], the offerer MUST NOT in the SDP 648 offer assign a 'bundle-only' attribute to the "m=" line. 650 If the offerer in the SDP offer wants to disable a bundled "m=" line 651 [Section 5.2.6.4], the offerer MUST NOT in the SDP offer assign a 652 'bundle-only' attribute to the "m=" line. 654 7. Protocol Identification 656 7.1. General 658 If bundled "m=" lines represent different transport protocols, there 659 MUST exist a specification which describes a mechanism, for this 660 specific transport protocol combination, how to associate a received 661 packet with the correct transport protocol. 663 In addition, if a received packet can be associated with more than 664 one bundled "m=" line, there MUST exist a specification which 665 describes a mechanism how to associated the received packet with the 666 correct "m=" line. 668 7.2. STUN, DTLS, SRTP 670 Section 5.1.2 of [RFC5764] describes a mechanism how to identify the 671 protocol among the STUN, DTLS and SRTP protocols (in any 672 combination). If an offer or answerer in SDP offers or answers 673 include bundled "m=" lines that represent these protocols, the 674 offerer or answerer MUST support the mechanism described in 675 [RFC5764], and no explicit negotiation is required in order to 676 indicate support and usage of the mechanism. 678 [RFC5764] does not describe how to identify different protocols 679 transported on DTLS, only how to identify the DTLS protocol itself. 680 If multiple protocols are transported on DTLS, there MUST exist a 681 specification describing a mechanism how to identify each individual 682 protocol. In addition, if a received DTLS packet can be associated 683 with more than one "m=" line, there MUST exist a specification which 684 describes a mechanism how to associate the received DTLS packet with 685 the correct "m=" line. 687 [Section 8.2] describes how to associate a received (S)RTP packet 688 with the correct "m=" line. 690 8. RTP Considerations 692 8.1. Single RTP Session 693 8.1.1. General 695 All RTP-based media within a single BUNDLE group belong to a single 696 RTP session [RFC3550]. Disjoint BUNDLE groups will form multiple RTP 697 sessions, one per BUNDLE group. 699 Since a single RTP session is used for each bundle group, all "m=" 700 lines representing RTP-based media in a bundle group will share a 701 single SSRC numbering space [RFC3550]. 703 The following rules and restrictions apply for a single RTP session: 705 o A specific payload type value can be used in multiple bundled "m=" 706 lines if each codec associated with the payload type number shares 707 an identical codec configuration [Section 8.1.2]. 709 o The "proto" value in each bundled "m=" line MUST be identical 710 (e.g. RTP/AVPF). 712 o A given SSRC SHOULD NOT transmit RTP packets using payload types 713 that originates from different bundled "m=" lines. 715 NOTE: The last bullet above is to avoid sending multiple media types 716 from the same SSRC. If transmission of multiple media types are done 717 with time overlap RTP and RTCP fails to function. Even if done in 718 proper sequence this causes RTP Timestamp rate switching issues [ref 719 to draft-ietf-avtext-multiple-clock-rates]. 721 8.1.2. Payload Type (PT) Value Re-usage 723 Multiple bundled "m=" lines might represent RTP based media. As all 724 RTP based media associated with a BUNDLE group belong to the same RTP 725 session, in order for a given payload type value to used inside more 726 than one bundled "m=" line, all codecs associated with the payload 727 type numbers MUST share an identical codec configuration. This means 728 that the codecs MUST share the same media type, encoding name, clock 729 rate and any parameter that can affect the codec configuration and 730 packetization. [I-D.nandakumar-mmusic-sdp-mux-attributes] lists SDP 731 attributes, which attribute values must be identical for all codecs 732 that use the same payload type value. 734 8.2. Associating RTP Packets With Correct SDP Media Description 736 In general, there are multiple mechanisms that can be used by an 737 endpoint in order to associate received RTP packets with the bundled 738 "m=" line representing the RTP packets. Such mechanisms include 739 using the local address:port combination on which the RTP packets are 740 received, the payload type value carried inside the RTP packets, the 741 SSRC values carried inside the RTP packets, and other "m=" line 742 specific information carried inside the RTP packets. 744 As all RTP packets associated with a BUNDLE group are sent and 745 received using the same 5-tuple, the local address:port combination 746 cannot be used to associate received RTP packets with the correct 747 "m=" line. 749 As described in [Section 8.1.2], the same payload type value might be 750 used inside RTP packets described by multiple "m=" lines. In such 751 cases, the payload type value cannot be used to associate received 752 RTP packets with the correct "m=" line. 754 An offerer and answerer can in an SDP offer and answer inform each 755 other which SSRC values they will use inside sent RTP packets by, by 756 assigning an SDP 'ssrc' attribute [RFC5576] to each bundled "m=" line 757 which contains a payload type value that is also used inside another 758 bundled "m=" line. As the SSRC values will be carried inside the RTP 759 packets, the offerer and answerer can then use that information to 760 associate received RTP packets with the correct "m=" line. However, 761 an offerer will not know which SSRC values the answerer will use 762 until it has received the SDP answer providing that information. Due 763 to this, before the offerer has received the SDP answer, the offerer 764 will not be able to associate received RTP packets with the correct 765 "m=" line using the SSRC values. 767 In order for an offerer and answerer to always be able to associate 768 received RTP packets with the correct "m=" line, the offerer and 769 answerer MUST in an SDP offer and answer assign an SDP "receiver-id" 770 attribute [receiver-id-reference-to-be-added] to each bundled "m=" 771 line which contains a payload type value that is also used inside 772 another bundled "m=" line. If an answerer accepts such "m=" line, 773 and keeps it within the BNDLE group, the answerer MUST insert the 774 'receiver-id' attribute value in RTP packets, associated with the 775 "m=" line, sent towards the offerer. 777 OPEN ISSUE: We need a mechanism that implements the 'receiver-id' 778 mechanism and the associated SDP attribute. 780 8.3. RTP/RTCP Multiplexing 782 8.3.1. General 784 When a BUNDLE group, which contains RTP based media, is created, the 785 offerer and answerer MUST negotiate whether to enable RTP/RTCP 786 multiplexing for the RTP based media associated with the BUNDLE group 787 [RFC5761]. 789 If RTP/RTCP multiplexing is not enabled, separate 5-tuples will be 790 used for sending and receiving the RTP packets and the RTCP packets. 792 8.3.2. SDP Offer/Answer Procedures 794 8.3.2.1. General 796 This section describes how an offerer and answerer can use the SDP 797 'rtcp-mux' attribute [RFC5761] and the SDP 'rtcp' attribute [RFC3605] 798 to negotiate usage of RTP/RTCP multiplexing for RTP based associated 799 with a BUNDLE group. 801 8.3.2.2. Generating the Initial SDP Offer 803 When an offerer generates an initial SDP offer, if the offerer wants 804 to negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, 805 the offerer MUST in the SDP offer assign an SDP 'rtcp-mux' attribute 806 [RFC5761] to each bundled "m=" line (including any bundle-only "m=" 807 line). In addition, the offerer MUST in the SDP offer assign an SDP 808 'rtcp' attribute [RFC3605] to each bundled "m=" line (including any 809 bundle-only "m=" line), with an attribute value that is identical to 810 the port value assigned to the "m=" line itself. 812 If the offerer does not want to negotiate usage of RTP/RTCP 813 multiplexing, the offerer MUST NOT assign the SDP attributes above to 814 any bundled "m=" line. 816 8.3.2.3. Generating the SDP Answer 818 8.3.2.3.1. Generating the SDP Answer to an Initial SDP Offer 820 When the answerer generates an SDP answer to an initial SDP offer, if 821 the offerer in the associated SDP offer indicated support of RTP/RTCP 822 multiplexing [RFC5761] within a BUNDLE group, the answerer MUST in 823 the SDP answer either accept or reject usage of RTP/RTCP 824 multiplexing. 826 If the answerer accepts usage of RTP/RTCP multiplexing within the 827 BUNDLE group, the answerer MUST in the SDP answer assign an SDP 828 'rtcp-mux' attribute to each bundled "m=" line. The answerer MUST 829 NOT in the SDP answer assign an SDP 'rtcp' attribute to any bundled 830 "m=" line. 832 OPEN ISSUE: Do we want to include the SDP 'rtcp' attribute also in 833 the SDP answer, eventhough it is not needed? 834 If the answerer rejects usage of RTP/RTCP multiplexing within the 835 BUNDLE group, the answerer MUST NOT in the SDP answer assign an SDP 836 'rtcp-mux' or SDP 'rtcp' attribute to any bundled "m=" line. 838 8.3.2.3.2. Generating the SDP Answer to a Subsequent SDP Offer 840 When the answerer generates an SDP answer to a subsequent SDP offer, 841 if the offerer in the associated SDP offer indicated support of RTP/ 842 RTCP multiplexing [RFC5761] within a BUNDLE group, the answerer MUST 843 in the SDP answer assign an SDP 'rtcp-mux' attribute and SDP 'rtcp' 844 attribute to each bundled "m=" line. 846 NOTE: The BUNDLE mechanism does not allow the answerer to, in a 847 subsequent SDP answer, disable usage of RTP/RTCP multiplexing, if the 848 offerer in the associated SDP offer indicates that it wants to 849 continue using RTP/RTCP multiplexing. 851 8.3.2.4. Offerer Processing of the SDP Answer 853 When the offerer receives an SDP answer, it follows the procedures 854 defined in [RFC5245]. 856 8.3.2.5. Modifying the Session 858 When an offerer generates a subsequent SDP offer, if the offerer 859 wants to negotiate usage of RTP/RTCP multiplexing within a BUNDLE 860 group, or if the offerer wants to continue usage of previously 861 negotiated RTP/RTCP multiplexing within the BUNDLE group, the offerer 862 MUST in the SDP offer assign 'rtcp-mux' and 'rtcp' attributes to each 863 bundled "m=" line (including bundle-only "m=" lines), unless the "m=" 864 line is disabled or removed from the BUNDLE group. 866 If the offerer does not want to negotiate usage of RTP/RTCP 867 multiplexing within the BUNDLE group, or if the offerer wants to 868 disable previously negotiated usage of RTP/RTCP multiplexing within a 869 BUNDLE group, the offerer MUST NOT in the SDP offer assign 'rtcp-mux' 870 and 'rtcp' attributes to any bundled "m=" line. 872 NOTE: It is RECOMMENDED that, once usage of RTP/RTCP multiplexing has 873 been negotiated within a BUNDLE group, that the usage of not 874 disabled. Disabling RTP/RTCP multiplexing means that the offerer and 875 answerer need to reserve new IP ports, to be used for sending and 876 receiving RTCP packets. 878 9. ICE Considerations 880 9.1. General 882 This section describes how to use the BUNDLE grouping extension 883 together with the Interactive Connectivity Establishment (ICE) 884 mechanism [RFC5245]. 886 Support and usage of ICE mechanism together with the BUNDLE mechanism 887 is optional. 889 9.2. SDP Offer/Answer Procedures 891 9.2.1. Generating the Initial SDP Offer 893 When an offerer generates an initial SDP offer, which contains a 894 BUNDLE group, the offerer MUST assign ICE candidates [RFC5245] to 895 each bundled "m=" line, except to an "m=" line to which the offerer 896 assigns a zero port value (e.g. a bundle-only "m=" line). The 897 offerer MUST assign unique ICE candidate values to each "m=" line. 899 9.2.2. Generating the SDP Answer 901 When an answerer generates and SDP Answer, which contains a BUNDLE 902 group, the answerer MUST assign ICE candidates to each bundled "m=" 903 line. The answerer MUST assign identical ICE candidate values to 904 each bundled "m=" line. 906 9.2.3. Offerer Processing of the SDP Answer 908 When the offerer receives an SDP answer, it follows the procedures 909 defined in [RFC5245]. 911 9.2.4. Modifying the Session 913 When an offerer generates a subsequent SDP offer, for each bundled 914 "m=" line to which the offerer assigns its BUNDLE address, the 915 offerer MUST assign identical ICE candidate values. The offerer MUST 916 assign the ICE candidate values associated with the "m=" line that 917 was used by the answerer to select the offerer BUNDLE address [ref- 918 to-be-added]. 920 9.2.5. Keep-alives 922 Once it is known that both endpoints support, and accept to use, the 923 BUNDLE grouping extension, ICE connectivity checks and keep-alives 924 only needs to be performed for the whole BUNDLE group, instead of for 925 each bundled "m=" line. 927 10. Update to RFC 3264 929 10.1. General 931 This section replaces the text of the following sections of RFC 3264: 933 o Section 5.1 (Unicast Streams). 935 o Section 8.2 (Removing a Media Stream). 937 o Section 8.4 (Putting a Unicast Media Stream on Hold). 939 10.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 941 For recvonly and sendrecv streams, the port number and address in the 942 offer indicate where the offerer would like to receive the media 943 stream. For sendonly RTP streams, the address and port number 944 indirectly indicate where the offerer wants to receive RTCP reports. 945 Unless there is an explicit indication otherwise, reports are sent to 946 the port number one higher than the number indicated. The IP address 947 and port present in the offer indicate nothing about the source IP 948 address and source port of RTP and RTCP packets that will be sent by 949 the offerer. A port number of zero in the offer indicates that the 950 stream is offered but MUST NOT be used. This has no useful semantics 951 in an initial offer, but is allowed for reasons of completeness, 952 since the answer can contain a zero port indicating a rejected stream 953 (Section 6). Furthermore, existing streams can be terminated by 954 setting the port to zero (Section 8). In general, a port number of 955 zero indicates that the media stream is not wanted. 957 10.3. New text replacing section 5.1 (2nd paragraph) of RFC 3264 959 For recvonly and sendrecv streams, the port number and address in the 960 offer indicate where the offerer would like to receive the media 961 stream. For sendonly RTP streams, the address and port number 962 indirectly indicate where the offerer wants to receive RTCP reports. 963 Unless there is an explicit indication otherwise, reports are sent to 964 the port number one higher than the number indicated. The IP address 965 and port present in the offer indicate nothing about the source IP 966 address and source port of RTP and RTCP packets that will be sent by 967 the offerer. A port number of zero in the offer by default indicates 968 that the stream is offered but MUST NOT be used, but an extension 969 mechanism might specify different semantics for the usage of a zero 970 port value. Furthermore, existing streams can be terminated by 971 setting the port to zero (Section 8). In general, a port number of 972 zero by default indicates that the media stream is not wanted. 974 10.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 976 A stream that is offered with a port of zero MUST be marked with port 977 zero in the answer. Like the offer, the answer MAY omit all 978 attributes present previously, and MAY list just a single media 979 format from amongst those in the offer. 981 10.5. New text replacing section 8.2 (2nd paragraph) of RFC 3264 983 A stream that is offered with a port of zero MUST by default be 984 marked with port zero in the answer, unless an extension mechanism, 985 which specifies semantics for the usage of a non-zero port value, is 986 used. 988 10.6. Original text of section 8.4 (6th paragraph) of RFC 3264 990 RFC 2543 [10] specified that placing a user on hold was accomplished 991 by setting the connection address to 0.0.0.0. Its usage for putting 992 a call on hold is no longer recommended, since it doesn't allow for 993 RTCP to be used with held streams, doesn't work with IPv6, and breaks 994 with connection oriented media. However, it can be useful in an 995 initial offer when the offerer knows it wants to use a particular set 996 of media streams and formats, but doesn't know the addresses and 997 ports at the time of the offer. Of course, when used, the port 998 number MUST NOT be zero, which would specify that the stream has been 999 disabled. An agent MUST be capable of receiving SDP with a 1000 connection address of 0.0.0.0, in which case it means that neither 1001 RTP nor RTCP should be sent to the peer. 1003 10.7. New text replacing section 8.4 (6th paragraph) of RFC 3264 1005 RFC 2543 [10] specified that placing a user on hold was accomplished 1006 by setting the connection address to 0.0.0.0. Its usage for putting 1007 a call on hold is no longer recommended, since it doesn't allow for 1008 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1009 with connection oriented media. However, it can be useful in an 1010 initial offer when the offerer knows it wants to use a particular set 1011 of media streams and formats, but doesn't know the addresses and 1012 ports at the time of the offer. Of course, when used, the port 1013 number MUST NOT be zero, if it would specify that the stream has been 1014 disabled. However, an extension mechanism might specify different 1015 semantics of the zero port number usage. An agent MUST be capable of 1016 receiving SDP with a connection address of 0.0.0.0, in which case it 1017 means that neither RTP nor RTCP should be sent to the peer. 1019 11. Security Considerations 1021 This specification does not significantly change the security 1022 considerations of SDP which can be found in Section X of TBD. 1024 TODO: Think carefully about security analysis of reuse of same SDES 1025 key on multiple "m=" lines when the far end does not use BUNDLE and 1026 warn developers of any risks. 1028 12. Examples 1030 12.1. Example: Bundle Address Selection 1032 The example below shows: 1034 o 1. An SDP offer, in which the offerer assigns a unique address to 1035 each bundled "m=" line within the BUNDLE group. 1037 o 2. An SDP answer, in which the answerer selects the offerer 1038 BUNDLE address, and in which selects its own BUNDLE address (the 1039 answerer BUNDLE address) and assigns it each bundled "m=" line 1040 within the BUNDLE group. 1042 o 3. A subsequent SDP offer (BAS offer), which is used to perform a 1043 Bundle Address Synchronization (BAS). 1045 SDP Offer (1) 1047 v=0 1048 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1049 s= 1050 c=IN IP4 atlanta.example.com 1051 t=0 0 1052 a=group:BUNDLE foo bar 1053 m=audio 10000 RTP/AVP 0 8 97 1054 a=mid:foo 1055 b=AS:200 1056 a=rtpmap:0 PCMU/8000 1057 a=rtpmap:8 PCMA/8000 1058 a=rtpmap:97 iLBC/8000 1059 m=video 10002 RTP/AVP 31 32 1060 a=mid:bar 1061 b=AS:1000 1062 a=rtpmap:31 H261/90000 1063 a=rtpmap:32 MPV/90000 1065 SDP Answer (2) 1067 v=0 1068 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1069 s= 1070 c=IN IP4 biloxi.example.com 1071 t=0 0 1072 a=group:BUNDLE foo bar 1073 m=audio 20000 RTP/AVP 0 1074 a=mid:foo 1075 b=AS:200 1076 a=rtpmap:0 PCMU/8000 1077 m=video 20000 RTP/AVP 32 1078 a=mid:bar 1079 b=AS:1000 1080 a=rtpmap:32 MPV/90000 1082 SDP Offer (3) 1084 v=0 1085 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1086 s= 1087 c=IN IP4 atlanta.example.com 1088 t=0 0 1089 a=group:BUNDLE foo bar 1090 m=audio 10000 RTP/AVP 0 8 97 1091 a=mid:foo 1092 b=AS:200 1093 a=rtpmap:0 PCMU/8000 1094 a=rtpmap:8 PCMA/8000 1095 a=rtpmap:97 iLBC/8000 1096 m=video 10000 RTP/AVP 31 32 1097 a=mid:bar 1098 b=AS:1000 1099 a=rtpmap:31 H261/90000 1100 a=rtpmap:32 MPV/90000 1102 12.2. Example: Bundle Mechanism Rejected 1104 The example below shows: 1106 o 1. An SDP offer, in which the offerer assigns a unique address to 1107 each bundled "m=" line within the BUNDLE group. 1109 o 2. An SDP answer, in which the answerer rejects the offered 1110 BUNDLE group, and assigns a unique addresses to each "m=" line 1111 (following normal RFC 3264 procedures). 1113 SDP Offer (1) 1115 v=0 1116 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1117 s= 1118 c=IN IP4 atlanta.example.com 1119 t=0 0 1120 a=group:BUNDLE foo bar 1121 m=audio 10000 RTP/AVP 0 8 97 1122 a=mid:foo 1123 b=AS:200 1124 a=rtpmap:0 PCMU/8000 1125 a=rtpmap:8 PCMA/8000 1126 a=rtpmap:97 iLBC/8000 1127 m=video 10002 RTP/AVP 31 32 1128 a=mid:bar 1129 b=AS:1000 1130 a=rtpmap:31 H261/90000 1131 a=rtpmap:32 MPV/90000 1133 SDP Answer (2) 1135 v=0 1136 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1137 s= 1138 c=IN IP4 biloxi.example.com 1139 t=0 0 1140 m=audio 20000 RTP/AVP 0 1141 b=AS:200 1142 a=rtpmap:0 PCMU/8000 1143 m=video 30000 RTP/AVP 32 1144 b=AS:1000 1145 a=rtpmap:32 MPV/90000 1147 12.3. Example: Offerer Adds A Media Description To A BUNDLE Group 1149 The example below shows: 1151 o 1. An SDP offer, in which the offerer adds a new "m=" line, 1152 represented by the "zen" mid value, to a previously negotiated 1153 BUNDLE group, assigns a unique address to the added "m=" line, and 1154 assigns the previously selected offerer BUNDLE address to each of 1155 the other bundled "m=" lines within the BUNDLE group. 1157 o 2. An SDP answer, in which the answerer assigns the answerer 1158 BUNDLE address to each bundled "m=" line (including the newly 1159 added "m=" line) within the BUNDLE group. 1161 o 3. A subsequent SDP offer (BAS offer), which is used to perform a 1162 Bundle Address Synchronization (BAS). 1164 SDP Offer (1) 1166 v=0 1167 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1168 s= 1169 c=IN IP4 atlanta.example.com 1170 t=0 0 1171 a=group:BUNDLE foo bar zen 1172 m=audio 10000 RTP/AVP 0 8 97 1173 a=mid:foo 1174 b=AS:200 1175 a=rtpmap:0 PCMU/8000 1176 a=rtpmap:8 PCMA/8000 1177 a=rtpmap:97 iLBC/8000 1178 m=video 10000 RTP/AVP 31 32 1179 a=mid:bar 1180 b=AS:1000 1181 a=rtpmap:31 H261/90000 1182 a=rtpmap:32 MPV/90000 1183 m=video 20000 RTP/AVP 66 1184 a=mid:zen 1185 b=AS:1000 1186 a=rtpmap:66 H261/90000 1188 SDP Answer (2) 1190 v=0 1191 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1192 s= 1193 c=IN IP4 biloxi.example.com 1194 t=0 0 1195 a=group:BUNDLE foo bar zen 1196 m=audio 20000 RTP/AVP 0 1197 a=mid:foo 1198 b=AS:200 1199 a=rtpmap:0 PCMU/8000 1200 m=video 20000 RTP/AVP 32 1201 a=mid:bar 1202 b=AS:1000 1203 a=rtpmap:32 MPV/90000 1204 m=video 20000 RTP/AVP 66 1205 a=mid:zen 1206 b=AS:1000 1207 a=rtpmap:66 H261/90000 1209 SDP Offer (3) 1211 v=0 1212 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1213 s= 1214 c=IN IP4 atlanta.example.com 1215 t=0 0 1216 a=group:BUNDLE foo bar zen 1217 m=audio 10000 RTP/AVP 0 8 97 1218 a=mid:foo 1219 b=AS:200 1220 a=rtpmap:0 PCMU/8000 1221 a=rtpmap:8 PCMA/8000 1222 a=rtpmap:97 iLBC/8000 1223 m=video 10000 RTP/AVP 31 32 1224 a=mid:bar 1225 b=AS:1000 1226 a=rtpmap:31 H261/90000 1227 a=rtpmap:32 MPV/90000 1228 m=video 10000 RTP/AVP 66 1229 a=mid:zen 1230 b=AS:1000 1231 a=rtpmap:66 H261/90000 1233 12.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 1235 The example below shows: 1237 o 1. An SDP offer, in which the offerer moves a bundled "m=" line 1238 out of a BUNDLE group, assigns a unique address to the moved "m=" 1239 line, and assigns the offerer BUNDLE address to each other bundled 1240 "m=" line within the BUNDLE group. 1242 o 2. An SDP answer, in which the answerer moves the "m=" line out 1243 of the BUNDLE group, assigns unique address to the moved "m=" 1244 line, and assigns the answerer BUNDLE address to each other 1245 bundled "m=" line within the BUNDLE group. 1247 SDP Offer (1) 1249 v=0 1250 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1251 s= 1252 c=IN IP4 atlanta.example.com 1253 t=0 0 1254 a=group:BUNDLE foo bar 1255 m=audio 10000 RTP/AVP 0 8 97 1256 a=mid:foo 1257 b=AS:200 1258 a=rtpmap:0 PCMU/8000 1259 a=rtpmap:8 PCMA/8000 1260 a=rtpmap:97 iLBC/8000 1261 m=video 10000 RTP/AVP 31 32 1262 a=mid:bar 1263 b=AS:1000 1264 a=rtpmap:31 H261/90000 1265 a=rtpmap:32 MPV/90000 1266 m=video 50000 RTP/AVP 66 1267 b=AS:1000 1268 a=rtpmap:66 H261/90000 1270 SDP Answer (2) 1272 v=0 1273 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1274 s= 1275 c=IN IP4 biloxi.example.com 1276 t=0 0 1277 a=group:BUNDLE foo bar 1278 m=audio 20000 RTP/AVP 0 1279 a=mid:foo 1280 b=AS:200 1281 a=rtpmap:0 PCMU/8000 1282 m=video 20000 RTP/AVP 32 1283 a=mid:bar 1284 b=AS:1000 1285 a=rtpmap:32 MPV/90000 1286 m=video 60000 RTP/AVP 66 1287 b=AS:1000 1288 a=rtpmap:66 H261/90000 1290 12.5. Example: Offerer Disables A Media Description Within A BUNDLE 1291 Group 1293 The example below shows: 1295 o 1. An SDP offer, in which the offerer disables a bundled "m=" 1296 line within BUNDLE group, assigns a zero port number the disabled 1297 "m=" line, and assigns the offerer BUNDLE address to each of the 1298 other bundled "m=" lines within the BUNDLE group. 1300 o 2. An SDP answer, in which the answerer moves the disabled "m=" 1301 line out of the BUNDLE group, assigns a zero port value to the 1302 disabled "m=" line, and assigns the answerer BUNDLE address to 1303 each of the other bundled "m=" lines within the BUNDLE group. 1305 SDP Offer (1) 1307 v=0 1308 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1309 s= 1310 c=IN IP4 atlanta.example.com 1311 t=0 0 1312 a=group:BUNDLE foo bar 1313 m=audio 10000 RTP/AVP 0 8 97 1314 a=mid:foo 1315 b=AS:200 1316 a=rtpmap:0 PCMU/8000 1317 a=rtpmap:8 PCMA/8000 1318 a=rtpmap:97 iLBC/8000 1319 m=video 10000 RTP/AVP 31 32 1320 a=mid:bar 1321 b=AS:1000 1322 a=rtpmap:31 H261/90000 1323 a=rtpmap:32 MPV/90000 1324 m=video 0 RTP/AVP 66 1325 a=rtpmap:66 H261/90000 1327 SDP Answer (2) 1329 v=0 1330 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1331 s= 1332 c=IN IP4 biloxi.example.com 1333 t=0 0 1334 a=group:BUNDLE foo bar 1335 m=audio 20000 RTP/AVP 0 1336 a=mid:foo 1337 b=AS:200 1338 a=rtpmap:0 PCMU/8000 1339 m=video 20000 RTP/AVP 32 1340 a=mid:bar 1341 b=AS:1000 1342 a=rtpmap:32 MPV/90000 1343 m=video 0 RTP/AVP 66 1344 a=rtpmap:66 H261/90000 1346 13. IANA Considerations 1348 This document requests IANA to register the new SDP Grouping semantic 1349 extension called BUNDLE. 1351 14. Acknowledgements 1353 The usage of the SDP grouping extension for negotiating bundled media 1354 is based on a similar alternatives proposed by Harald Alvestrand and 1355 Cullen Jennings. The BUNDLE mechanism described in this document is 1356 based on the different alternative proposals, and text (e.g. SDP 1357 examples) have been borrowed (and, in some cases, modified) from 1358 those alternative proposals. 1360 The SDP examples are also modified versions from the ones in the 1361 Alvestrand proposal. 1363 Thanks to Paul Kyzivat and Martin Thompson for taking the the time to 1364 read the text along the way, and providing useful feedback. 1366 15. Change Log 1368 [RFC EDITOR NOTE: Please remove this section when publishing] 1370 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 1372 o Draft title changed. 1374 o Added "SDP" to section names containing "Offer" or "Answer". 1376 o Editorial fixes based on comments from Paul Kyzivat (http:// 1377 www.ietf.org/mail-archive/web/mmusic/current/msg13314.html). 1379 o Editorial fixed based on comments from Colin Perkins (http:// 1380 www.ietf.org/mail-archive/web/mmusic/current/msg13318.html). 1382 o - Removed text about extending BUNDLE to allow multiple RTP 1383 sessions within a BUNDLE group. 1385 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 1387 o Major re-structure of SDP Offer/Answer sections, to align with RFC 1388 3264 structure. 1390 o Additional definitions added. 1392 o - Shared address. 1394 o - Bundled "m=" line. 1396 o - Bundle-only "m=" line. 1398 o - Offerer suggested BUNDLE mid. 1400 o - Answerer selected BUNDLE mid. 1402 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 1403 to multiple "m=" lines until it has received an SDP Answer 1404 indicating support of the BUNDLE mechanism. 1406 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 1407 Answerer supports the BUNDLE mechanism, assign a zero port value 1408 to a 'bundle-only' "m=" line. 1410 o SDP 'bundle-only' attribute section added. 1412 o Connection data nettype/addrtype restrictions added. 1414 o RFC 3264 update section added. 1416 o Indicating that a specific payload type value can be used in 1417 multiple "m=" lines, if the value represents the same codec 1418 configuration in each "m=" line. 1420 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 1422 o Updated Offerer procedures (http://www.ietf.org/mail-archive/web/ 1423 mmusic/current/msg12293.html). 1425 o Updated Answerer procedures (http://www.ietf.org/mail-archive/web/ 1426 mmusic/current/msg12333.html). 1428 o Usage of SDP 'bundle-only' attribute added. 1430 o Reference to Trickle ICE document added. 1432 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 1434 o Mechanism modified, to be based on usage of SDP Offers with both 1435 different and identical port number values, depending on whether 1436 it is known if the remote endpoint supports the extension. 1438 o Cullen Jennings added as co-author. 1440 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 1441 o No changes. New version due to expiration. 1443 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 1445 o No changes. New version due to expiration. 1447 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 1449 o Draft name changed. 1451 o Harald Alvestrand added as co-author. 1453 o "Multiplex" terminology changed to "bundle". 1455 o Added text about single versus multiple RTP Sessions. 1457 o Added reference to RFC 3550. 1459 16. References 1461 16.1. Normative References 1463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1464 Requirement Levels", BCP 14, RFC 2119, March 1997. 1466 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1467 with Session Description Protocol (SDP)", RFC 3264, June 1468 2002. 1470 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1471 Description Protocol", RFC 4566, July 2006. 1473 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1474 Control Packets on a Single Port", RFC 5761, April 2010. 1476 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1477 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1479 [I-D.nandakumar-mmusic-sdp-mux-attributes] 1480 Nandakumar, S., "A Framework for SDP Attributes when 1481 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-01 1482 (work in progress), February 2014. 1484 16.2. Informative References 1486 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1487 Jacobson, "RTP: A Transport Protocol for Real-Time 1488 Applications", STD 64, RFC 3550, July 2003. 1490 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1491 in Session Description Protocol (SDP)", RFC 3605, October 1492 2003. 1494 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1495 (ICE): A Protocol for Network Address Translator (NAT) 1496 Traversal for Offer/Answer Protocols", RFC 5245, April 1497 2010. 1499 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1500 Media Attributes in the Session Description Protocol 1501 (SDP)", RFC 5576, June 2009. 1503 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1504 Security (DTLS) Extension to Establish Keys for the Secure 1505 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1507 [I-D.ietf-mmusic-trickle-ice] 1508 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 1509 Incremental Provisioning of Candidates for the Interactive 1510 Connectivity Establishment (ICE) Protocol", draft-ietf- 1511 mmusic-trickle-ice-01 (work in progress), February 2014. 1513 Appendix A. Design Considerations 1515 A.1. General 1517 One of the main issues regarding the BUNDLE grouping extensions has 1518 been whether, in SDP Offers and SDP Answers, the same port number 1519 value should be inserted in "m=" lines associated with a BUNDLE 1520 group, as the purpose of the extension is to negotiate the usage of a 1521 single 5-tuple for media associated with the "m=" lines. Issues with 1522 both approaches, discussed in the Appendix have been raised. The 1523 outcome was to specify a mechanism which uses SDP Offers with both 1524 different and identical port number values. 1526 Below are the primary issues that have been considered when defining 1527 the "BUNDLE" grouping extension: 1529 o 1) Interoperability with existing UAs. 1531 o 2) Interoperability with intermediary B2BUA- and proxy entities. 1533 o 3) Time to gather, and the number of, ICE candidates. 1535 o 4) Different error scenarios, and when they occur. 1537 o 5) SDP Offer/Answer impacts, including usage of port number value 1538 zero. 1540 NOTE: Before this document is published as an RFC, this 1541 Appendix might be removed. 1543 A.2. UA Interoperability 1545 Consider the following SDP Offer/Answer exchange, where Alice sends 1546 an SDP Offer to Bob: 1548 SDP Offer 1550 v=0 1551 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1552 s= 1553 c=IN IP4 atlanta.example.com 1554 t=0 0 1555 m=audio 10000 RTP/AVP 97 1556 a=rtpmap:97 iLBC/8000 1557 m=video 10002 RTP/AVP 97 1558 a=rtpmap:97 H261/90000 1560 SDP Answer 1562 v=0 1563 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1564 s= 1565 c=IN IP4 biloxi.example.com 1566 t=0 0 1567 m=audio 20000 RTP/AVP 97 1568 a=rtpmap:97 iLBC/8000 1569 m=video 20002 RTP/AVP 97 1570 a=rtpmap:97 H261/90000 1572 RFC 4961 specifies a way of doing symmetric RTP but that is an a 1573 later invention to RTP and Bob can not assume that Alice supports RFC 1574 4961. This means that Alice may be sending RTP from a different port 1575 than 10000 or 10002 - some implementation simply send the RTP from an 1576 ephemeral port. When Bob's endpoint receives an RTP packet, the only 1577 way that Bob know if it should be passed to the video or audio codec 1578 is by looking at the port it was received on. This lead some SDP 1579 implementations to use the fact that each "m=" line had a different 1580 port number to use that port number as an index to find the correct m 1581 line in the SDP. As a result, some implementations that do support 1582 symmetric RTP and ICE still use a SDP data structure where SDP with 1583 "m=" lines with the same port such as: 1585 SDP Offer 1587 v=0 1588 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1589 s= 1590 c=IN IP4 atlanta.example.com 1591 t=0 0 1592 m=audio 10000 RTP/AVP 97 1593 a=rtpmap:97 iLBC/8000 1594 m=video 10000 RTP/AVP 98 1595 a=rtpmap:98 H261/90000 1597 will result in the second "m=" line being considered an SDP error 1598 because it has the same port as the first line. 1600 A.3. Usage of port number value zero 1602 In an SDP Offer or SDP Answer, the media associated with an "m=" line 1603 can be disabled/rejected by setting the port number value to zero. 1604 This is different from e.g. using the SDP direction attributes, where 1605 RTCP traffic will continue even if the SDP "inactive" attribute is 1606 indicated for the associated "m=" line. 1608 If each "m=" line associated with a BUNDLE group would contain 1609 different port number values, and one of those port would be used for 1610 the 5-tuple, problems would occur if an endpoint wants to disable/ 1611 reject the "m=" line associated with that port, by setting the port 1612 number value to zero. After that, no "m=" line would contain the 1613 port number value which is used for the 5-tuple. In addition, it is 1614 unclear what would happen to the ICE candidates associated with the 1615 "m=" line, as they are also used for the 5-tuple. 1617 A.4. B2BUA And Proxy Interoperability 1619 Some back to back user agents may be configured in a mode where if 1620 the incoming call leg contains an SDP attribute the B2BUA does not 1621 understand, the B2BUS still generates that SDP attribute in the Offer 1622 for the outgoing call leg. Consider an B2BUA that did not understand 1623 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 1624 Further assume that the B2BUA was configured to tear down any call 1625 where it did not see any RTCP for 5 minutes. In this cases, if the 1626 B2BUA received an Offer like: 1628 SDP Offer 1630 v=0 1631 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1632 s= 1633 c=IN IP4 atlanta.example.com 1634 t=0 0 1635 m=audio 49170 RTP/AVP 0 1636 a=rtcp:53020 1638 It would be looking for RTCP on port 49172 but would not see any 1639 because the RTCP would be on port 53020 and after five minutes, it 1640 would tear down the call. Similarly, an SBC that did not understand 1641 BUNDLE yet put BUNDLE in it's offer may be looking for media on the 1642 wrong port and tear down the call. It is worth noting that a B2BUA 1643 that generated an Offer with capabilities it does not understand is 1644 not compliant with the specifications. 1646 A.4.1. Traffic Policing 1648 Sometimes intermediaries do not act as B2BUA, in the sense that they 1649 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 1650 however, they may use SDP information (e.g. IP address and port) in 1651 order to control traffic gating functions, and to set traffic 1652 policing rules. There might be rules which will trigger a session to 1653 be terminated in case media is not sent or received on the ports 1654 retrieved from the SDP. This typically occurs once the session is 1655 already established and ongoing. 1657 A.4.2. Bandwidth Allocation 1659 Sometimes intermediaries do not act as B2BUA, in the sense that they 1660 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 1661 however, they may use SDP information (e.g. codecs and media types) 1662 in order to control bandwidth allocation functions. The bandwidth 1663 allocation is done per "m=" line, which means that it might not be 1664 enough if media associated with all "m=" lines try to use that 1665 bandwidth. That may either simply lead to bad user experience, or to 1666 termination of the call. 1668 A.5. Candidate Gathering 1670 When using ICE, an candidate needs to be gathered for each port. 1671 This takes approximately 20 ms extra for each extra "m=" line due to 1672 the NAT pacing requirements. All of this gather can be overlapped 1673 with other things while the page is loading to minimize the impact. 1674 If the client only wants to generate TURN or STUN ICE candidates for 1675 one of the "m=" lines and then use trickle ICE 1676 [I-D.ietf-mmusic-trickle-ice] to get the non host ICE candidates for 1677 the rest of the "m=" lines, it MAY do that and will not need any 1678 additional gathering time. 1680 Some people have suggested a TURN extension to get a bunch of TURN 1681 allocation at once. This would only provide a single STUN result so 1682 in cases where the other end did not support BUNDLE, may cause more 1683 use of the TURN server but would be quick in the cases where both 1684 sides supported BUNDLE and would fall back to a successful call in 1685 the other cases. 1687 Authors' Addresses 1689 Christer Holmberg 1690 Ericsson 1691 Hirsalantie 11 1692 Jorvas 02420 1693 Finland 1695 Email: christer.holmberg@ericsson.com 1697 Harald Tveit Alvestrand 1698 Google 1699 Kungsbron 2 1700 Stockholm 11122 1701 Sweden 1703 Email: harald@alvestrand.no 1705 Cullen Jennings 1706 Cisco 1707 400 3rd Avenue SW, Suite 350 1708 Calgary, AB T2P 4H2 1709 Canada 1711 Email: fluffy@iii.ca