idnits 2.17.1 draft-ietf-mmusic-rfc8843bis-09.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 abstract seems to indicate that this document obsoletes RFC5888, but the header doesn't have an 'Obsoletes:' line to match this. -- The draft header indicates that this document updates RFC7941, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3264, updated by this document, for RFC5378 checks: 2002-01-31) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (5 December 2021) is 872 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) -- Looks like a reference, but probably isn't: '10' on line 1840 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 8829 (Obsoleted by RFC 9429) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 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 Obsoletes: 8843 (if approved) H. Alvestrand 5 Updates: 3264, 5888, 7941 (if approved) Google 6 Intended status: Standards Track C. Jennings 7 Expires: 8 June 2022 Cisco 8 5 December 2021 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-rfc8843bis-09 14 Abstract 16 This specification defines a new Session Description Protocol (SDP) 17 Grouping Framework extension called 'BUNDLE'. The extension can be 18 used with the SDP offer/answer mechanism to negotiate the usage of a 19 single transport (5-tuple) for sending and receiving media described 20 by multiple SDP media descriptions ("m=" sections). Such transport 21 is referred to as a BUNDLE transport, and the media is referred to as 22 bundled media. The "m=" sections that use the BUNDLE transport form 23 a BUNDLE group. 25 This specification defines a new RTP Control Protocol (RTCP) Source 26 Description (SDES) item and a new RTP header extension. 28 This specification updates RFCs 3264, 5888, and 7941. 30 This specification obsoletes RFC 8843. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 8 June 2022. 49 RFC 8843 Bundled Media December 2021 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Revised BSD License text as 62 described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Revised BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 81 1.2. BUNDLE Mechanism . . . . . . . . . . . . . . . . . . . . 4 82 1.3. Protocol Extensions . . . . . . . . . . . . . . . . . . . 5 83 1.4. Changes from RFC 8843 . . . . . . . . . . . . . . . . . . 6 84 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 87 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 8 88 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 9 89 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 90 7.1. Generic SDP Considerations . . . . . . . . . . . . . . . 11 91 7.1.1. Connection Data ("c=") . . . . . . . . . . . . . . . 11 92 7.1.2. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . 11 93 7.1.3. Attributes ("a=") . . . . . . . . . . . . . . . . . . 11 94 7.2. Generating the Initial BUNDLE offer . . . . . . . . . . . 12 95 7.2.1. Suggesting the Offerer-Tagged 'm=' Section . . . . . 13 96 7.2.2. Example: Initial BUNDLE offer . . . . . . . . . . . . 14 97 7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 15 98 7.3.1. Answerer Selection of Tagged 'm=' Sections . . . . . 17 100 RFC 8843 Bundled Media December 2021 102 7.3.2. Moving a Media Description Out of a BUNDLE Group . . 17 103 7.3.3. Rejecting a Media Description in a BUNDLE Group . . . 18 104 7.3.4. Example: SDP Answer . . . . . . . . . . . . . . . . . 19 105 7.3.5. RFC 8843 Considerations . . . . . . . . . . . . . . . 20 106 7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 20 107 7.4.1. RFC 8843 Considerations . . . . . . . . . . . . . . . 21 108 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 22 109 7.5.1. Adding a Media Description to a BUNDLE Group . . . . 22 110 7.5.2. Moving a Media Description Out of a BUNDLE Group . . 23 111 7.5.3. Disabling a Media Description in a BUNDLE Group . . . 23 112 7.6. 3PCC Considerations . . . . . . . . . . . . . . . . . . . 24 113 8. Protocol Identification . . . . . . . . . . . . . . . . . . . 24 114 8.1. STUN, DTLS, and SRTP . . . . . . . . . . . . . . . . . . 25 115 9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 25 116 9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 25 117 9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 26 118 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 119 Description . . . . . . . . . . . . . . . . . . . . . . . 27 120 9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 33 121 9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 33 122 10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 35 123 11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 36 124 12. RTP Header Extensions Consideration . . . . . . . . . . . . . 37 125 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 37 126 13.1. Original Text from RFC 3264, Section 5.1, 2nd 127 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 37 128 13.2. New Text Replacing RFC 3264, Section 5.1, 2nd 129 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38 130 13.3. Original Text from RFC 3264, Section 8.4, 6th 131 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38 132 13.4. New Text Replacing RFC 3264, Section 8.4, 6th 133 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38 134 14. Update to RFC 5888 . . . . . . . . . . . . . . . . . . . . . 39 135 14.1. Original Text from RFC 5888, Section 9.2, 3rd 136 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 39 137 14.2. New Text Replacing RFC 5888, Section 9.2, 3rd 138 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 39 139 15. RTP/RTCP Extensions for identification-tag Transport . . . . 39 140 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 40 141 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 41 142 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 143 16.1. New SDES Item . . . . . . . . . . . . . . . . . . . . . 41 144 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 42 145 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 42 146 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 43 147 17. Security Considerations . . . . . . . . . . . . . . . . . . . 43 148 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 44 149 18.1. Example: Tagged "m=" Section Selections . . . . . . . . 44 151 RFC 8843 Bundled Media December 2021 153 18.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 46 154 18.3. Example: Offerer Adds a Media Description to a BUNDLE 155 Group . . . . . . . . . . . . . . . . . . . . . . . . . 47 156 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE 157 Group . . . . . . . . . . . . . . . . . . . . . . . . . 49 158 18.5. Example: Offerer Disables a Media Description within a 159 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 51 160 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 161 19.1. Normative References . . . . . . . . . . . . . . . . . . 53 162 19.2. Informative References . . . . . . . . . . . . . . . . . 55 163 Appendix A. Design Considerations . . . . . . . . . . . . . . . 57 164 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 57 165 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 59 166 A.3. B2BUA and Proxy Interoperability . . . . . . . . . . . . 59 167 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 60 168 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 60 169 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 60 170 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61 171 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 173 1. Introduction 175 1.1. Background 177 When the SDP offer/answer mechanism [RFC3264] is used to negotiate 178 the establishment of multimedia communication sessions, if separate 179 transports (5-tuples) are negotiated for each individual media 180 stream, each transport consumes additional resources (especially when 181 Interactive Connectivity Establishment (ICE) [RFC8445] is used). For 182 this reason, it is attractive to use a single transport for multiple 183 media streams. 185 1.2. BUNDLE Mechanism 187 This specification defines a way to use a single transport (BUNDLE 188 transport) for sending and receiving media (bundled media) described 189 by multiple SDP media descriptions ("m=" sections). The address:port 190 combination used by an endpoint for sending and receiving bundled 191 media is referred to as the BUNDLE address:port. The set of SDP 192 attributes that are applied to each "m=" section within a BUNDLE 193 group is referred to as BUNDLE attributes. The same BUNDLE transport 194 is used for sending and receiving bundled media, which means that the 195 symmetric Real-time Transport Protocol (RTP) mechanism [RFC4961] is 196 always used for RTP-based bundled media. 198 This specification defines a new SDP Grouping Framework [RFC5888] 199 extension called 'BUNDLE'. The extension can be used with the 200 Session Description Protocol (SDP) offer/answer mechanism [RFC3264] 202 RFC 8843 Bundled Media December 2021 204 to negotiate which "m=" sections will become part of a BUNDLE group. 205 In addition, the offerer and answerer [RFC3264] use the BUNDLE 206 extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE 207 address:port and answerer BUNDLE address:port) and the set of BUNDLE 208 attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) 209 that will be applied to each "m=" section within the BUNDLE group. 211 The use of a BUNDLE transport allows the usage of a single set of ICE 212 [RFC8445] candidates for the whole BUNDLE group. 214 A given BUNDLE address:port MUST only be associated with a single 215 BUNDLE group. If an SDP offer or SDP answer (hereafter referred to 216 as "offer" and "answer") contains multiple BUNDLE groups, the 217 procedures in this specification apply to each group independently. 218 All RTP-based bundled media associated with a given BUNDLE group 219 belong to a single RTP session [RFC3550]. 221 The BUNDLE extension is backward compatible. Endpoints that do not 222 support the extension are expected to generate offers and answers 223 without an SDP 'group:BUNDLE' attribute and assign a unique 224 address:port to each "m=" section within an offer and answer, 225 according to the procedures in [RFC3264] and [RFC4566]. 227 1.3. Protocol Extensions 229 In addition to defining the new SDP Grouping Framework extension, 230 this specification defines the following protocol extensions and RFC 231 updates. This specification: 233 * defines a new SDP attribute, 'bundle-only', which can be used to 234 request that a specific "m=" section (and the associated media) be 235 used only if kept within a BUNDLE group. 237 * updates RFC 3264 [RFC3264], to also allow assigning a zero port 238 value to an "m=" section in cases where the media described by the 239 "m=" section is not disabled or rejected. 241 * defines a new RTCP [RFC3550] SDES item, 'MID', and a new RTP SDES 242 header extension that can be used to associate RTP streams with 243 "m=" sections. 245 * updates [RFC7941] by adding an exception, for the MID RTP header 246 extension, to the requirement regarding protection of an SDES RTP 247 header extension carrying an SDES item for the MID RTP header 248 extension. 250 RFC 8843 Bundled Media December 2021 252 * updates [RFC5888] by allowing an SDP 'group' attribute to contain 253 an identification-tag that identifies an "m=" section with the 254 port value set to zero. 256 1.4. Changes from RFC 8843 258 When RFC 8843 and [RFC8829] were published an inconsistency between 259 the specifications was identified. The procedures regarding 260 assigning the port value to a bundled "m=" section in an answer 261 (initial or subsequent) and a subsequent offer were inconsistent. 262 This specification removes the inconsistency by aligning the port 263 value assignment procedure with the procedure in RFC 8829. 265 In addition, this document implements the following erratas: 6431, 266 6437 268 2. Terminology 270 "m=" section: SDP bodies contain one or more media descriptions, 271 referred to as "m=" sections. Each "m=" section is represented 272 by an SDP "m=" line and zero or more SDP attributes associated 273 with the "m=" line. A local address:port combination is 274 assigned to each "m=" section. 276 5-tuple: A collection of the following values: source address, 277 source port, destination address, destination port, and 278 transport-layer protocol. 280 Unique address:port: An address:port combination that is assigned 281 to only one "m=" section in an offer or answer. 283 Offerer BUNDLE-tag: The first identification-tag in a given SDP 284 'group:BUNDLE' attribute identification-tag list in an offer. 286 Answerer BUNDLE-tag: The first identification-tag in a given SDP 287 'group:BUNDLE' attribute identification-tag list in an answer. 289 Suggested offerer-tagged "m=" section: The bundled "m=" section 290 identified by the offerer BUNDLE-tag in an initial BUNDLE 291 offer, before a BUNDLE group has been negotiated. 293 Offerer-tagged "m=" section: The bundled "m=" section identified 294 by the offerer BUNDLE-tag in a subsequent offer. The "m=" 295 section contains characteristics (offerer BUNDLE address:port 296 and offerer BUNDLE attributes) that are applied to each "m=" 297 section within the BUNDLE group. 299 Answerer-tagged "m=" section: The bundled "m=" section identified 301 RFC 8843 Bundled Media December 2021 303 by the answerer BUNDLE-tag in an answer (initial BUNDLE answer 304 or subsequent). The "m=" section contains characteristics 305 (answerer BUNDLE address:port and answerer BUNDLE attributes) 306 that are applied to each "m=" section within the BUNDLE group. 308 BUNDLE address:port: An address:port combination that an endpoint 309 uses for sending and receiving bundled media. 311 Offerer BUNDLE address:port: The address:port combination used by 312 the offerer for sending and receiving media. 314 Answerer BUNDLE address:port: The address:port combination used 315 by the answerer for sending and receiving media. 317 BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category 318 SDP attributes. Once a BUNDLE group has been created, the 319 attribute values apply to each bundled "m=" section within the 320 BUNDLE group. 322 Offerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing 323 category SDP attributes included in the offerer-tagged "m=" 324 section. 326 Answerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing 327 category SDP attributes included in the answerer-tagged "m=" 328 section. 330 BUNDLE transport: The transport (5-tuple) used by all media 331 described by the "m=" sections within a BUNDLE group. 333 BUNDLE group: A set of bundled "m=" sections, created using an 334 SDP offer/answer exchange, that uses a single BUNDLE transport, 335 and a single set of BUNDLE attributes, for sending and 336 receiving all media (bundled media) described by the set of 337 "m=" sections. The same BUNDLE transport is used for sending 338 and receiving bundled media. 340 Bundled "m=" section: An "m=" section, whose identification-tag 341 is placed in an SDP 'group:BUNDLE' attribute identification-tag 342 list in an offer or answer. 344 Bundle-only "m=" section: A bundled "m=" section that contains an 345 SDP 'bundle-only' attribute. 347 Bundled media: All media associated with a given BUNDLE group. 349 Initial BUNDLE offer: The first offer, within an SDP session 351 RFC 8843 Bundled Media December 2021 353 (e.g., a SIP dialog when SIP [RFC3261] is used to carry SDP), 354 in which the offerer indicates that it wants to negotiate a 355 given BUNDLE group. 357 Initial BUNDLE answer: The answer to an initial BUNDLE offer in 358 which the offerer indicates that it wants to negotiate a BUNDLE 359 group, and the answerer accepts the creation of the BUNDLE 360 group. The BUNDLE group is created once the answerer sends the 361 initial BUNDLE answer. 363 Subsequent offer: An offer that contains a BUNDLE group that has 364 been created as part of a previous offer/answer exchange. 366 Subsequent answer: An answer to a subsequent offer. 368 Identification-tag: A unique token value that is used to identify 369 an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" 370 section carries the unique identification-tag assigned to that 371 "m=" section. The session-level SDP 'group' attribute 372 [RFC5888] carries a list of identification-tags, identifying 373 the "m=" sections associated with that particular 'group' 374 attribute. 376 3. Conventions 378 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 379 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 380 "OPTIONAL" in this document are to be interpreted as described in 381 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 382 capitals, as shown here. 384 4. Applicability Statement 386 The mechanism in this specification only applies to SDP [RFC4566], 387 when used together with the SDP offer/answer mechanism [RFC3264]. 388 Declarative usage of SDP is out of scope of this document and is thus 389 undefined. 391 5. SDP Grouping Framework BUNDLE Extension 393 This section defines a new SDP Grouping Framework [RFC5888] 394 extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP 395 offer/answer mechanism to negotiate a set of "m=" sections that will 396 become part of a BUNDLE group. Within a BUNDLE group, each "m=" 397 section uses a BUNDLE transport for sending and receiving bundled 398 media. Each endpoint uses a single address:port combination for 399 sending and receiving the bundled media. 401 RFC 8843 Bundled Media December 2021 403 The BUNDLE extension is indicated using an SDP 'group' attribute with 404 a semantics value [RFC5888] of "BUNDLE". An identification-tag is 405 assigned to each bundled "m=" section, and each identification-tag is 406 listed in the SDP 'group:BUNDLE' attribute identification-tag list. 407 Each "m=" section whose identification-tag is listed in the 408 identification-tag list is associated with a given BUNDLE group. 410 SDP bodies can contain multiple BUNDLE groups. Any given bundled 411 "m=" section MUST NOT be associated with more than one BUNDLE group 412 at any given time. 414 NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' 415 attribute identification-tag list does not have to be the same as the 416 order in which the "m=" sections occur in the SDP. 418 The multiplexing category [RFC8859] for the 'group:BUNDLE' attribute 419 is 'NORMAL'. 421 Section 7 defines the detailed SDP offer/answer procedures for the 422 BUNDLE extension. 424 6. SDP 'bundle-only' Attribute 426 This section defines a new SDP media-level attribute [RFC4566], 427 'bundle-only'. 'bundle-only' is a property attribute [RFC4566] and 428 hence has no value. 430 In order to ensure that an answerer that does not support the BUNDLE 431 extension always rejects a bundled "m=" section in an offer, the 432 offerer can assign a zero port value to the "m=" section. According 433 to [RFC3264], an answerer will reject such an "m=" section. By 434 including an SDP 'bundle-only' attribute in a bundled "m=" section, 435 the offerer can request that the answerer accepts the "m=" section 436 only if the answerer supports the BUNDLE extension and if the 437 answerer keeps the "m=" section within the associated BUNDLE group. 439 Name: bundle-only 441 Value: N/A 443 Usage Level: media 445 Charset Dependent: no 447 Example: a=bundle-only 449 RFC 8843 Bundled Media December 2021 451 The usage of the 'bundle-only' attribute is only defined for a 452 bundled "m=" section with a zero port value. Other usage is 453 unspecified. If an offerer or answerer receives a 'bundle-only' 454 attribute in a non-bundled "m=" section the offerer or answerer MUST 455 discard the attribute. 457 Section 7 defines the detailed SDP offer/answer procedures for the 458 'bundle-only' attribute. 460 7. SDP Offer/Answer Procedures 462 This section describes the SDP offer/answer [RFC3264] procedures for: 464 * Negotiating a BUNDLE group; 466 * Suggesting and selecting the tagged "m=" sections (offerer-tagged 467 "m=" section and answerer-tagged "m=" section); 469 * Adding an "m=" section to a BUNDLE group; 471 * Moving an "m=" section out of a BUNDLE group; and 473 * Disabling an "m=" section within a BUNDLE group. 475 The generic rules and procedures defined in [RFC3264] and [RFC5888] 476 also apply to the BUNDLE extension. For example, if an offer is 477 rejected by the answerer, the previously negotiated addresses:ports, 478 SDP parameters, and characteristics (including those associated with 479 a BUNDLE group) apply. Hence, if an offerer generates an offer in 480 order to negotiate a BUNDLE group, and the answerer rejects the 481 offer, the BUNDLE group is not created. 483 The procedures in this section are independent of the media type or 484 "m=" line proto value assigned to a bundled "m=" section. Section 6 485 defines additional considerations for the usage of the SDP 'bundle- 486 only' attribute. Section 9 defines additional considerations for 487 RTP-based media. Section 10 defines additional considerations for 488 the usage of the ICE [RFC8445] mechanism. 490 Offers and answers can contain multiple BUNDLE groups. The 491 procedures in this section apply independently to a given BUNDLE 492 group. 494 RFC 8843 Bundled Media December 2021 496 7.1. Generic SDP Considerations 498 This section describes generic restrictions associated with the usage 499 of SDP parameters within a BUNDLE group. It also describes how to 500 calculate a value for the whole BUNDLE group, when parameter and 501 attribute values have been assigned to each bundled "m=" section. 503 7.1.1. Connection Data ("c=") 505 The "c=" line nettype value [RFC4566] associated with a bundled "m=" 506 section MUST be 'IN'. 508 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" 509 section MUST be 'IP4' or 'IP6'. The same value MUST be associated 510 with each "m=" section. 512 NOTE: Extensions to this specification can specify usage of the 513 BUNDLE mechanism for other nettype and addrtype values than the ones 514 listed above. 516 7.1.2. Bandwidth ("b=") 518 An offerer and answerer MUST use the rules and restrictions defined 519 in [RFC8859] for associating the SDP bandwidth ("b=") line with 520 bundled "m=" sections. 522 7.1.3. Attributes ("a=") 524 An offerer and answerer MUST include SDP attributes in every bundled 525 "m=" section where applicable, following the normal offer/answer 526 procedures for each attribute, with the following exceptions: 528 * In the initial BUNDLE offer, the offerer MUST NOT include 529 IDENTICAL and TRANSPORT multiplexing category SDP attributes 530 (BUNDLE attributes) in bundle-only "m=" sections. The offerer 531 MUST include such attributes in all other bundled "m=" sections. 532 In the initial BUNDLE offer, each bundled "m=" line can contain a 533 different set of BUNDLE attributes and attribute values. Once the 534 offerer-tagged "m=" section has been selected, the BUNDLE 535 attributes contained in the offerer-tagged "m=" section will apply 536 to each bundled "m=" section within the BUNDLE group. 538 RFC 8843 Bundled Media December 2021 540 * In a subsequent offer, or in an answer (initial or subsequent), 541 the offerer and answerer MUST include IDENTICAL and TRANSPORT 542 multiplexing category SDP attributes (BUNDLE attributes) only in 543 the tagged "m=" section (offerer-tagged "m=" section or answerer- 544 tagged "m=" section). The offerer and answerer MUST NOT include 545 such attributes in any other bundled "m=" section. The BUNDLE 546 attributes contained in the tagged "m=" section will apply to each 547 bundled "m=" section within the BUNDLE group. 549 * In an offer (initial BUNDLE offer or subsequent), or in an answer 550 (initial BUNDLE answer or subsequent), the offerer and answerer 551 MUST include SDP attributes from categories other than IDENTICAL 552 and TRANSPORT in each bundled "m=" section that a given attribute 553 applies to. Each bundled "m=" line can contain a different set of 554 such attributes, and attribute values, as such attributes only 555 apply to the given bundled "m=" section in which they are 556 included. 558 NOTE: A consequence of the rules above is that media-specific 559 IDENTICAL and TRANSPORT multiplexing category SDP attributes that are 560 applicable only to some of the bundled "m=" sections within the 561 BUNDLE group might appear in the tagged "m=" section for which they 562 are not applicable. For instance, the tagged "m=" section might 563 contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section 564 does not describe RTP-based media (but another bundled "m=" section 565 within the BUNDLE group does describe RTP-based media). 567 7.2. Generating the Initial BUNDLE offer 569 The procedures in this section apply to the first offer, within an 570 SDP session (e.g., a SIP dialog when SIP [RFC3261] is used to carry 571 SDP), in which the offerer indicates that it wants to negotiate a 572 given BUNDLE group. This could occur in the initial offer, or in a 573 subsequent offer, of the SDP session. 575 When an offerer generates an initial BUNDLE offer, in order to 576 negotiate a BUNDLE group, it MUST: 578 * Assign a unique address:port to each bundled "m=" section, 579 following the procedures in [RFC3264], excluding any bundle-only 580 "m=" sections (see below); 582 * Pick a bundled "m=" section as the suggested offerer-tagged "m=" 583 (Section 7.2.1); 585 * Include SDP attributes in the bundled "m=" sections following the 586 rules in Section 7.1.3; 588 RFC 8843 Bundled Media December 2021 590 * Include an SDP 'group:BUNDLE' attribute in the offer; and 592 * Place the identification-tag of each bundled "m=" section in the 593 SDP 'group:BUNDLE' attribute identification-tag list. The offerer 594 BUNDLE-tag indicates the suggested offerer-tagged "m=" section. 596 NOTE: When the offerer assigns unique addresses:ports to multiple 597 bundled "m=" sections, the offerer needs to be prepared to receive 598 bundled media on each unique address:port, until it receives the 599 associated answer and finds out which bundled "m=" section (and 600 associated address:port combination) the answerer has selected as the 601 offerer-tagged "m=" section. 603 If the offerer wants to request that the answerer accepts a given 604 bundled "m=" section only if the answerer keeps the "m=" section 605 within the negotiated BUNDLE group, the offerer MUST: 607 * Include an SDP 'bundle-only' attribute (Section 7.2.1) in the "m=" 608 section, and 610 * Assign a zero port value to the "m=" section. 612 NOTE: If the offerer assigns a zero port value to a bundled "m=" 613 section, but does not include an SDP 'bundle-only' attribute in the 614 "m=" section, it is an indication that the offerer wants to disable 615 the "m=" section (Section 7.5.3). 617 Sections 7.2.2 and 18.1 show an example of an initial BUNDLE offer. 619 7.2.1. Suggesting the Offerer-Tagged 'm=' Section 621 In the initial BUNDLE offer, the bundled "m=" section indicated by 622 the offerer BUNDLE-tag is the suggested offerer-tagged "m=" section. 623 The address:port combination associated with the "m=" section will be 624 used by the offerer for sending and receiving bundled media if the 625 answerer selects the "m=" section as the offerer-tagged "m=" section 626 (Section 7.3.1). In addition, if the answerer selects the "m=" 627 section as the offerer-tagged "m=" section, the BUNDLE attributes 628 included in the "m=" section will be applied to each "m=" section 629 within the negotiated BUNDLE group. 631 The offerer MUST NOT suggest a bundle-only "m=" section as the 632 offerer-tagged "m=" section. 634 It is RECOMMENDED that the suggested offerer-tagged "m=" section be a 635 bundled "m=" section that the offerer believes is unlikely that the 636 answerer will reject or move out of the BUNDLE group. How such 637 assumption is made is outside the scope of this document. 639 RFC 8843 Bundled Media December 2021 641 7.2.2. Example: Initial BUNDLE offer 643 The following example shows an initial BUNDLE offer. The offer 644 includes two "m=" sections in the offer and suggests that both "m=" 645 sections are included in a BUNDLE group. The audio "m=" section is 646 the suggested offerer-tagged "m=" section, indicated by placing the 647 identification-tag associated with the "m=" section (offerer BUNDLE- 648 tag) first in the SDP group:BUNDLE attribute identification-id list. 650 SDP Offer 652 v=0 653 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 654 s= 655 c=IN IP6 2001:db8::3 656 t=0 0 657 a=group:BUNDLE foo bar 659 m=audio 10000 RTP/AVP 0 8 97 660 b=AS:200 661 a=mid:foo 662 a=rtcp-mux 663 a=rtpmap:0 PCMU/8000 664 a=rtpmap:8 PCMA/8000 665 a=rtpmap:97 iLBC/8000 666 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 668 m=video 10002 RTP/AVP 31 32 669 b=AS:1000 670 a=mid:bar 671 a=rtcp-mux 672 a=rtpmap:31 H261/90000 673 a=rtpmap:32 MPV/90000 674 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 676 The following example shows an initial BUNDLE offer. The offer 677 includes two "m=" sections in the offer and suggests that both "m=" 678 sections are included in a BUNDLE group. The offerer includes an SDP 679 'bundle-only' attribute in the video "m=" section, to request that 680 the answerer accepts the "m=" section only if the answerer supports 681 the BUNDLE extension and if the answerer keeps the "m=" section 682 within the associated BUNDLE group. The audio "m=" section is the 683 suggested offerer-tagged "m=" section, indicated by placing the 684 identification-tag associated with the "m=" section (offerer BUNDLE- 685 tag) first in the SDP group:BUNDLE attribute identification-id list. 687 SDP Offer 689 RFC 8843 Bundled Media December 2021 691 v=0 692 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 693 s= 694 c=IN IP6 2001:db8::3 695 t=0 0 696 a=group:BUNDLE foo bar 698 m=audio 10000 RTP/AVP 0 8 97 699 b=AS:200 700 a=mid:foo 701 a=rtcp-mux 702 a=rtpmap:0 PCMU/8000 703 a=rtpmap:8 PCMA/8000 704 a=rtpmap:97 iLBC/8000 705 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 707 m=video 0 RTP/AVP 31 32 708 b=AS:1000 709 a=mid:bar 710 a=bundle-only 711 a=rtpmap:31 H261/90000 712 a=rtpmap:32 MPV/90000 713 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 715 7.3. Generating the SDP Answer 717 When an answerer generates an answer (initial BUNDLE answer or 718 subsequent) that contains a BUNDLE group, the following general SDP 719 Grouping Framework restrictions, defined in [RFC5888], also apply to 720 the BUNDLE group: 722 * The answerer is only allowed to include a BUNDLE group in an 723 initial BUNDLE answer if the offerer requested the BUNDLE group to 724 be created in the corresponding initial BUNDLE offer; 726 * The answerer is only allowed to include a BUNDLE group in a 727 subsequent answer if the corresponding subsequent offer contains a 728 previously negotiated BUNDLE group; 730 * The answerer is only allowed to include a bundled "m=" section in 731 an answer if the "m=" section was indicated as bundled in the 732 corresponding offer; and 734 * The answerer is only allowed to include a bundled "m=" section in 735 the same BUNDLE group as the bundled "m=" line in the 736 corresponding offer. 738 RFC 8843 Bundled Media December 2021 740 In addition, when an answerer generates an answer (initial BUNDLE 741 answer or subsequent) that contains a BUNDLE group, the answerer 742 MUST: 744 * In case of an initial BUNDLE answer, select the offerer-tagged 745 "m=" section using the procedures in Section 7.3.1. In case of a 746 subsequent answer, the offerer-tagged "m=" section is indicated in 747 the corresponding subsequent offer and MUST NOT be changed by the 748 answerer; 750 * Select the answerer-tagged "m=" section (Section 7.3.1); 752 * Assign the answerer BUNDLE address:port to the answerer-tagged 753 "m=" section, and to every other bundled "m=" section within the 754 BUNDLE group; 756 * Include SDP attributes in the bundled "m=" sections following the 757 rules in Section 7.1.3; 759 * Include an SDP 'group:BUNDLE' attribute in the answer; and 761 * Place the identification-tag of each bundled "m=" section in the 762 SDP 'group:BUNDLE' attribute identification-tag list. The 763 answerer BUNDLE-tag indicates the answerer-tagged "m=" section 764 (Section 7.3.1). 766 If the answerer does not want to keep an "m=" section within a BUNDLE 767 group, it MUST: 769 * Move the "m=" section out of the BUNDLE group (Section 7.3.2); or 771 * Reject the "m=" section (Section 7.3.3). 773 The answerer can modify the answerer BUNDLE address:port, add and 774 remove SDP attributes, or modify SDP attribute values in a subsequent 775 answer. Changes to the answerer BUNDLE address:port and the answerer 776 BUNDLE attributes will be applied to each bundled "m=" section within 777 the BUNDLE group. 779 NOTE: If a bundled "m=" section in an offer contains a zero port 780 value, but the "m=" section does not contain an SDP 'bundle-only' 781 attribute, it is an indication that the offerer wants to disable the 782 "m=" section (Section 7.5.3). 784 RFC 8843 Bundled Media December 2021 786 7.3.1. Answerer Selection of Tagged 'm=' Sections 788 When selecting the offerer-tagged "m=" section, the answerer MUST 789 first check whether the "m=" section fulfills the following criteria 790 Section 7.2.1: 792 * The answerer will not move the "m=" section out of the BUNDLE 793 group (Section 7.3.2); 795 * The answerer will not reject the "m=" section (Section 7.3.3); and 797 * The "m=" section does not contain a zero port value. 799 If all of the criteria above are fulfilled, the answerer MUST select 800 the "m=" section as the offerer-tagged "m=" section and MUST also 801 mark the corresponding "m=" section in the answer as the answerer- 802 tagged "m=" section. In the answer, the answerer BUNDLE-tag 803 indicates the answerer-tagged "m=" section. 805 If one or more of the criteria are not fulfilled, the answerer MUST 806 pick the next identification-tag in the identification-tag list in 807 the offer and perform the same criteria check for the "m=" section 808 indicated by that identification-tag. If there are no more 809 identification-tags in the identification-tag list, the answerer MUST 810 NOT create the BUNDLE group. In addition, unless the answerer 811 rejects the whole offer, the answerer MUST apply the answerer 812 procedures for moving an "m=" section out of a BUNDLE group 813 (Section 7.3.2) or rejecting an "m=" section within a BUNDLE group 814 (Section 7.3.3) to every bundled "m=" section in the offer when 815 creating the answer. 817 Section 18.1 shows an example of an offerer BUNDLE address:port 818 selection. 820 Sections 7.3.4 and 18.1 show an example of an answerer-tagged "m=" 821 section selection. 823 7.3.2. Moving a Media Description Out of a BUNDLE Group 825 When an answerer generates the answer, if the answerer wants to move 826 a bundled "m=" section out of the negotiated BUNDLE group, the 827 answerer MUST first check the following criteria: 829 * In the corresponding offer, the "m=" section is within a 830 previously negotiated BUNDLE group, and 832 * In the corresponding offer, the "m=" section contains an SDP 833 'bundle-only' attribute. 835 RFC 8843 Bundled Media December 2021 837 If either criterion above is fulfilled, the answerer cannot move the 838 "m=" section out of the BUNDLE group in the answer. The answerer can 839 reject the whole offer, reject each bundled "m=" section within the 840 BUNDLE group (Section 7.3.3), or keep the "m=" section within the 841 BUNDLE group in the answer and later create an offer where the "m=" 842 section is moved out of the BUNDLE group (Section 7.5.2). 844 NOTE: One consequence of the rules above is that, once a BUNDLE group 845 has been negotiated, a bundled "m=" section cannot be moved out of 846 the BUNDLE group in an answer. Instead, an offer is needed. 848 When the answerer generates an answer, in which it moves a bundled 849 "m=" section out of a BUNDLE group, the answerer: 851 * MUST assign a unique address:port to the "m=" section; 853 * MUST include any applicable SDP attribute in the "m=" section, 854 using the normal offer/answer procedures for each attribute; 856 * MUST NOT place the identification-tag associated with the "m=" 857 section in the SDP 'group:BUNDLE' attribute identification-tag 858 list associated with the BUNDLE group; and 860 * MUST NOT include an SDP 'bundle-only' attribute to the "m=" 861 section. 863 Because an answerer is not allowed to move an "m=" section from one 864 BUNDLE group to another within an answer (Section 7.3), if the 865 answerer wants to move an "m=" section from one BUNDLE group to 866 another, it MUST first move the "m=" section out of the current 867 BUNDLE group and then generate an offer where the "m=" section is 868 added to another BUNDLE group (Section 7.5.1). 870 7.3.3. Rejecting a Media Description in a BUNDLE Group 872 When an answerer wants to reject a bundled "m=" section in an answer, 873 it MUST first check the following criterion: 875 * In the corresponding offer (subsequent), the "m=" section is the 876 offerer-tagged "m=" section. 878 If the criterion above is fulfilled, the answerer cannot reject the 879 "m=" section in the answer. The answerer can reject the whole offer, 880 reject each bundled "m=" section within the BUNDLE group, or keep the 881 "m=" section within the BUNDLE group in the answer and later create 882 an offer where the "m=" section is disabled within the BUNDLE group 883 (Section 7.5.3). 885 RFC 8843 Bundled Media December 2021 887 When an answerer generates an answer, in which it rejects a bundled 888 "m=" section, the answerer: 890 * MUST assign a zero port value to the "m=" section, according to 891 the procedures in [RFC3264]; 893 * MUST NOT place the identification-tag associated with the "m=" 894 section in the SDP 'group:BUNDLE' attribute identification-tag 895 list associated with the BUNDLE group; and 897 * MUST NOT include an SDP 'bundle-only' attribute in the "m=" 898 section. 900 7.3.4. Example: SDP Answer 902 The example below shows an answer, based on the corresponding offer 903 in Section 7.2.2. The answerer accepts both bundled "m=" sections 904 within the created BUNDLE group. The audio "m=" section is the 905 answerer-tagged "m=" section, indicated by placing the 906 identification-tag associated with the "m=" section (answerer BUNDLE- 907 tag) first in the SDP group;BUNDLE attribute identification-id list. 909 SDP Answer 911 v=0 912 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 913 s= 914 c=IN IP6 2001:db8::1 915 t=0 0 916 a=group:BUNDLE foo bar 918 m=audio 20000 RTP/AVP 0 919 b=AS:200 920 a=mid:foo 921 a=rtcp-mux 922 a=rtpmap:0 PCMU/8000 923 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 925 m=video 20000 RTP/AVP 32 926 b=AS:1000 927 a=mid:bar 928 a=rtpmap:32 MPV/90000 929 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 931 RFC 8843 Bundled Media December 2021 933 7.3.5. RFC 8843 Considerations 935 In RFC 8843, instead of assigning the offerer BUNDLE address:port to 936 each "m=" section within the BUNDLE group when modifying the session 937 (Section 7.5), the offerer only assigned the offerer BUNDLE 938 address:port to the offerer-tagged "m=" section. For every other 939 "m=" section within the BUNDLE group, the offerer included an SDP 940 'bundle-only' attribute in, and assigned a zero port value to, the 941 "m=" section. The way an answerer compliant to this specification 942 processes such offer is considered an implementation issue (e.g., 943 based on whether the answerer needs to be backward compatible with 944 RFC 8843 compliant offerers), and is outside the scope of this 945 specification. The example below shows such SDP offer: 947 SDP Offer 949 v=0 950 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 951 s= 952 c=IN IP6 2001:db8::3 953 t=0 0 954 a=group:BUNDLE foo bar 956 m=audio 10000 RTP/AVP 0 8 97 957 b=AS:200 958 a=mid:foo 959 a=rtcp-mux 960 a=rtpmap:0 PCMU/8000 961 a=rtpmap:8 PCMA/8000 962 a=rtpmap:97 iLBC/8000 963 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 965 m=video 0 RTP/AVP 31 32 966 b=AS:1000 967 a=mid:bar 968 a=bundle-only 969 a=rtpmap:31 H261/90000 970 a=rtpmap:32 MPV/90000 971 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 973 7.4. Offerer Processing of the SDP Answer 975 When an offerer receives an answer, if the answer contains a BUNDLE 976 group, the offerer MUST check that any bundled "m=" section in the 977 answer was indicated as bundled in the corresponding offer (for the 978 same BUNDLE group). If there is no mismatch, the offerer MUST apply 979 the properties (BUNDLE address:port, BUNDLE attributes, etc.) of the 980 offerer-tagged "m=" section (selected by the answerer; see 982 RFC 8843 Bundled Media December 2021 984 Section 7.3.1) to each bundled "m=" section within the BUNDLE group. 986 NOTE: As the answerer might reject one or more bundled "m=" sections 987 in an initial BUNDLE offer, or move a bundled "m=" section out of a 988 BUNDLE group, a given bundled "m=" section in the offer might not be 989 indicated as bundled in the corresponding answer. 991 If the answer does not contain a BUNDLE group, the offerer MUST 992 process the answer as a normal answer. 994 7.4.1. RFC 8843 Considerations 996 In RFC 8843, instead of assigning the answerer BUNDLE address:port to 997 each "m=" section within the BUNDLE group when generating the SDP 998 answer(Section 7.3), the answerer only assigned the answerer BUNDLE 999 address:port to the answerer-tagged "m=" section. For every other 1000 "m=" section within the BUNDLE group, the answerer included an SDP 1001 'bundle-only' attribute in, and assigned a zero port value to, the 1002 "m=" section. The way an offerer compliant to this specification 1003 processes such SDP answer is considered an implementation issue 1004 (e.g., based on whether the answerer needs to be backward compatible 1005 with RFC 8843 compliant offerers), and is outside the scope of this 1006 specification. The example below shows such SDP answer: 1008 SDP Answer 1010 v=0 1011 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1012 s= 1013 c=IN IP6 2001:db8::1 1014 t=0 0 1015 a=group:BUNDLE foo bar 1017 m=audio 20000 RTP/AVP 0 1018 b=AS:200 1019 a=mid:foo 1020 a=rtcp-mux 1021 a=rtpmap:0 PCMU/8000 1022 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1024 m=video 0 RTP/AVP 32 1025 b=AS:1000 1026 a=mid:bar 1027 a=bundle-only 1028 a=rtpmap:32 MPV/90000 1029 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1031 RFC 8843 Bundled Media December 2021 1033 7.5. Modifying the Session 1035 When a BUNDLE group has been previously negotiated, and an offerer 1036 generates a subsequent offer, the offerer MUST: 1038 * Pick one bundled "m=" section as the offerer-tagged "m=" section. 1039 The offerer can pick either the "m=" section that was previously 1040 selected by the answerer as the offerer-tagged "m=" section or 1041 another bundled "m=" section within the BUNDLE group; 1043 * Assign a BUNDLE address:port (previously negotiated or newly 1044 suggested) to the offerer-tagged "m=" section, and to every other 1045 bundled "m=" section within the BUNDLE group; 1047 * Include SDP attributes in the bundled "m=" sections following the 1048 rules in Section 7.1.3; 1050 * Include an SDP 'group:BUNDLE' attribute in the offer; and 1052 * Place the identification-tag of each bundled "m=" section in the 1053 SDP 'group:BUNDLE' attribute identification-tag list. The offerer 1054 BUNDLE-tag indicates the offerer-tagged "m=" section. 1056 The offerer MUST NOT pick a given bundled "m=" section as the 1057 offerer-tagged "m=" section if: 1059 * The offerer wants to move the "m=" section out of the BUNDLE group 1060 (Section 7.5.2), or 1062 * The offerer wants to disable the "m=" section (Section 7.5.3). 1064 The offerer can modify the offerer BUNDLE address:port, add and 1065 remove SDP attributes, or modify SDP attribute values in the 1066 subsequent offer. Changes to the offerer BUNDLE address:port and the 1067 offerer BUNDLE attributes will (if the offer is accepted by the 1068 answerer) be applied to each bundled "m=" section within the BUNDLE 1069 group. 1071 7.5.1. Adding a Media Description to a BUNDLE Group 1073 When an offerer generates a subsequent offer, in which it wants to 1074 add a bundled "m=" section to a previously negotiated BUNDLE group, 1075 the offerer follows the procedures in Section 7.5. The offerer picks 1076 either the added "m=" section or an "m=" section previously added to 1077 the BUNDLE group as the offerer-tagged "m=" section. 1079 RFC 8843 Bundled Media December 2021 1081 NOTE: As described in Section 7.3.2, the answerer cannot move the 1082 added "m=" section out of the BUNDLE group in its answer. If the 1083 answerer wants to move the "m=" section out of the BUNDLE group, it 1084 will have to first accept it into the BUNDLE group in the answer, and 1085 then send a subsequent offer where the "m=" section is moved out of 1086 the BUNDLE group (Section 7.5.2). 1088 7.5.2. Moving a Media Description Out of a BUNDLE Group 1090 When an offerer generates a subsequent offer, in which it wants to 1091 remove a bundled "m=" section from a BUNDLE group, the offerer: 1093 * MUST assign a unique address:port to the "m=" section; 1095 * MUST include SDP attributes in the "m=" section following the 1096 normal offer/answer rules for each attribute; 1098 * MUST NOT place the identification-tag associated with the "m=" 1099 section in the SDP 'group:BUNDLE' attribute identification-tag 1100 list associated with the BUNDLE group; and 1102 * MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 1103 section. 1105 For the other bundled "m=" sections within the BUNDLE group, the 1106 offerer follows the procedures in Section 7.5. 1108 An offerer MUST NOT move an "m=" section from one BUNDLE group to 1109 another within a single offer. If the offerer wants to move an "m=" 1110 section from one BUNDLE group to another, it MUST first move the 1111 BUNDLE group out of the current BUNDLE group, and then generate a 1112 second offer where the "m=" section is added to another BUNDLE group 1113 (Section 7.5.1). 1115 Section 18.4 shows an example of an offer for moving an "m=" section 1116 out of a BUNDLE group. 1118 7.5.3. Disabling a Media Description in a BUNDLE Group 1120 When an offerer generates a subsequent offer, in which it wants to 1121 disable a bundled "m=" section from a BUNDLE group, the offerer: 1123 * MUST assign a zero port value to the "m=" section, following the 1124 procedures in [RFC4566]; 1126 * MUST NOT place the identification-tag associated with the "m=" 1127 section in the SDP 'group:BUNDLE' attribute identification-tag 1128 list associated with the BUNDLE group; and 1130 RFC 8843 Bundled Media December 2021 1132 * MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 1133 section. 1135 For the other bundled "m=" sections within the BUNDLE group, the 1136 offerer follows the procedures in Section 7.5. 1138 Section 18.5 shows an example of an offer and answer for disabling an 1139 "m=" section within a BUNDLE group. 1141 7.6. 3PCC Considerations 1143 In some 3rd Party Call Control (3PCC) scenarios a new session will be 1144 established between an endpoint that is currently part of an ongoing 1145 session and an endpoint that is not currently part of an ongoing 1146 session. In this situation, the endpoint that is not part of a 1147 session, while expecting an initial offer, can receive an SDP offer 1148 created as a subsequent offer. The text below describes how this can 1149 occur with the Session Initiation Protocol (SIP) [RFC3261]. 1151 SIP allows a User Agent Client (UAC) to send a re-INVITE request 1152 without an SDP body (sometimes referred to as an empty re-INVITE). 1153 In such cases, the User Agent Server (UAS) will include an SDP offer 1154 in the associated 200 (OK) response, and when the UAS is a part of an 1155 ongoing SIP session, this offer will be a subsequent offer. This 1156 offer will be received by the 3PCC controller (UAC) and then 1157 forwarded to another User Agent (UA). When that UA is not part of an 1158 ongoing SIP session, as noted above, it will process the offer as an 1159 initial SDP offer. 1161 When the BUNDLE mechanism is used, an initial BUNDLE offer is 1162 constructed using different rules than subsequent BUNDLE offers, and 1163 it cannot be assumed that a UA is able to correctly process a 1164 subsequent BUNDLE offer as an initial BUNDLE offer. Therefore, the 1165 3PCC controller SHOULD take actions to mitigate this problem, and 1166 e.g., rewrite the subsequent BUNDLE offer into a valid initial BUNDLE 1167 offer (Section 7.2), before it forwards the BUNDLE offer to a UA. 1169 8. Protocol Identification 1171 Each "m=" section within a BUNDLE group MUST use the same transport- 1172 layer protocol. If bundled "m=" sections use different upper-layer 1173 protocols on top of the transport-layer protocol, there MUST exist a 1174 publicly available specification that describes how a mechanism 1175 associates received data with the correct protocol for this 1176 particular protocol combination. 1178 RFC 8843 Bundled Media December 2021 1180 In addition, if received data can be associated with more than one 1181 bundled "m=" section, there MUST exist a publicly available 1182 specification that describes a mechanism for associating the received 1183 data with the correct "m=" section. 1185 This document describes a mechanism to identify the protocol of 1186 received data among the Session Traversal Utilities for NAT (STUN), 1187 DTLS, and the Secure Real-time Transport Protocol (SRTP) (in any 1188 combination) when UDP is used as a transport-layer protocol, but it 1189 does not describe how to identify different protocols transported on 1190 DTLS. While the mechanism is generally applicable to other protocols 1191 and transport-layer protocols, any such use requires further 1192 specification that encompasses how to multiplex multiple protocols on 1193 a given transport-layer protocol and how to associate received data 1194 with the correct protocols. 1196 8.1. STUN, DTLS, and SRTP 1198 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 1199 protocol of a received packet among the STUN, DTLS, and SRTP 1200 protocols (in any combination). If an offer or answer includes a 1201 bundled "m=" section that represents these protocols, the offerer or 1202 answerer MUST support the mechanism described in [RFC5764], and no 1203 explicit negotiation is required in order to indicate support and 1204 usage of the mechanism. 1206 [RFC5764] does not describe how to identify different protocols 1207 transported on DTLS, only how to identify the DTLS protocol itself. 1208 If multiple protocols are transported on DTLS, there MUST exist a 1209 specification describing a mechanism for identifying each individual 1210 protocol. In addition, if a received DTLS packet can be associated 1211 with more than one "m=" section, there MUST exist a specification 1212 that describes a mechanism for associating the received DTLS packets 1213 with the correct "m=" section. 1215 Section 9.2 describes how to associate the packets in a received SRTP 1216 stream with the correct "m=" section. 1218 9. RTP Considerations 1220 9.1. Single RTP Session 1222 All RTP-based media within a single BUNDLE group belong to a single 1223 RTP session [RFC3550]. 1225 Since a single BUNDLE transport is used for sending and receiving 1226 bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for 1227 RTP-based bundled media. 1229 RFC 8843 Bundled Media December 2021 1231 Since a single RTP session is used for each BUNDLE group, all "m=" 1232 sections representing RTP-based media within a BUNDLE group will 1233 share a single Synchronization Source (SSRC) numbering space 1234 [RFC3550]. 1236 The following rules and restrictions apply for a single RTP session: 1238 * A specific payload type value can be used in multiple bundled "m=" 1239 sections only if each codec associated with the payload type 1240 number shares an identical codec configuration (Section 9.1.1). 1242 * The proto value in each bundled RTP-based "m=" section MUST be 1243 identical (e.g., RTP/AVPF). 1245 * The RTP MID header extension MUST be enabled, by including an SDP 1246 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 1247 hdrext:sdes:mid' URI value defined in this specification, in each 1248 bundled RTP-based "m=" section in every offer and answer. 1250 * A given SSRC MUST NOT transmit RTP packets using payload types 1251 that originate from different bundled "m=" sections. 1253 NOTE: The last bullet above is to avoid sending multiple media types 1254 from the same SSRC. If transmission of multiple media types are done 1255 with time overlap, RTP and RTCP fail to function. Even if done in 1256 proper sequence, this causes RTP timestamp rate switching issues 1257 [RFC7160]. However, once an SSRC has left the RTP session (by 1258 sending an RTCP BYE packet), that SSRC can be reused by another 1259 source (possibly associated with a different bundled "m=" section) 1260 after a delay of 5 RTCP reporting intervals (the delay is to ensure 1261 the SSRC has timed out, in case the RTCP BYE packet was lost 1262 [RFC3550]). 1264 [RFC7657] defines Differentiated Services (Diffserv) considerations 1265 for RTP-based bundled media sent using a mixture of Diffserv 1266 Codepoints. 1268 9.1.1. Payload Type (PT) Value Reuse 1270 Multiple bundled "m=" sections might describe RTP-based media. As 1271 all RTP-based media associated with a BUNDLE group belong to the same 1272 RTP session, in order for a given payload type value to be used 1273 inside more than one bundled "m=" section, all codecs associated with 1274 the payload type number MUST share an identical codec configuration. 1275 This means that the codecs MUST share the same media type, encoding 1276 name, clock rate, and any parameter that can affect the codec 1277 configuration and packetization. [RFC8859] lists SDP attributes, 1278 whose attribute values are required to be identical for all codecs 1280 RFC 8843 Bundled Media December 2021 1282 that use the same payload type value. 1284 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 1285 Description 1287 As described in [RFC3550], RTP packets are associated with RTP 1288 streams [RFC7656]. Each RTP stream is identified by an SSRC value, 1289 and each RTP packet includes an SSRC field that is used to associate 1290 the packet with the correct RTP stream. RTCP packets also use SSRCs 1291 to identify which RTP streams the packet relates to. However, an 1292 RTCP packet can contain multiple SSRC fields, in the course of 1293 providing feedback or reports on different RTP streams, and therefore 1294 can be associated with multiple such streams. 1296 In order to be able to process received RTP/RTCP packets correctly, 1297 it MUST be possible to associate an RTP stream with the correct "m=" 1298 section, as the "m=" section and SDP attributes associated with the 1299 "m=" section contains information needed to process the packets. 1301 As all RTP streams associated with a BUNDLE group use the same 1302 transport for sending and receiving RTP/RTCP packets, the local 1303 address:port combination part of the transport cannot be used to 1304 associate an RTP stream with the correct "m=" section. In addition, 1305 multiple RTP streams might be associated with the same "m=" section. 1307 An offerer and answerer can inform each other which SSRC values they 1308 will use for an RTP stream by using the SDP 'ssrc' attribute 1309 [RFC5576]. However, an offerer will not know which SSRC values the 1310 answerer will use until the offerer has received the answer providing 1311 that information. Due to this, before the offerer has received the 1312 answer, the offerer will not be able to associate an RTP stream with 1313 the correct "m=" section using the SSRC value associated with the RTP 1314 stream. In addition, the offerer and answerer may start using new 1315 SSRC values mid-session, without informing each other about using the 1316 SDP 'ssrc' attribute. 1318 In order for an offerer and answerer to always be able to associate 1319 an RTP stream with the correct "m=" section, the offerer and answerer 1320 using the BUNDLE extension MUST support the mechanism defined in 1321 Section 15, where the offerer and answerer insert the identification- 1322 tag associated with an "m=" section (provided by the remote peer) 1323 into RTP and RTCP packets associated with a BUNDLE group. 1325 When using this mechanism, the mapping from an SSRC to an 1326 identification-tag is carried in RTP header extensions or RTCP SDES 1327 packets, as specified in Section 15. Since a compound RTCP packet 1328 can contain multiple RTCP SDES packets, and each RTCP SDES packet can 1329 contain multiple chunks, a single RTCP packet can contain several 1331 RFC 8843 Bundled Media December 2021 1333 mappings of SSRC to identification-tag. The offerer and answerer 1334 maintain tables used for routing that are updated each time an RTP/ 1335 RTCP packet contains new information that affects how packets are to 1336 be routed. 1338 However, some legacy implementations may not include this 1339 identification-tag in their RTP and RTCP traffic when using the 1340 BUNDLE mechanism and instead use a mechanism based on the payload 1341 type to associate RTP streams with SDP "m=" sections. In this 1342 situation, each "m=" section needs to use unique payload type values, 1343 in order for the payload type to be a reliable indicator of the 1344 relevant "m=" section for the RTP stream. If an implementation fails 1345 to ensure unique payload type values, it will be impossible to 1346 associate the RTP stream using that payload type value to a 1347 particular "m=" section. Note that when using the payload type to 1348 associate RTP streams with "m=" sections, an RTP stream, identified 1349 by its SSRC, will be mapped to an "m=" section when the first packet 1350 of that RTP stream is received, and the mapping will not be changed 1351 even if the payload type used by that RTP stream changes. In other 1352 words, the SSRC cannot "move" to a different "m=" section simply by 1353 changing the payload type. 1355 Applications can implement RTP stacks in different ways. The 1356 algorithm below details one way that RTP streams can be associated 1357 with "m=" sections, but it is not meant to be prescriptive about 1358 exactly how an RTP stack needs to be implemented. Applications MAY 1359 use any algorithm that achieves equivalent results to those described 1360 in the algorithm below. 1362 To prepare to associate RTP streams with the correct "m=" section, 1363 the following steps MUST be followed for each BUNDLE group: 1365 * Construct a table mapping a MID to an "m=" section for each "m=" 1366 section in this BUNDLE group. Note that an "m=" section may only 1367 have one MID. 1369 * Construct a table mapping SSRCs of incoming RTP streams to an "m=" 1370 section for each "m=" section in this BUNDLE group and for each 1371 SSRC configured for receiving in that "m=" section. 1373 * Construct a table mapping the SSRC of each outgoing RTP stream to 1374 an "m=" section for each "m=" section in this BUNDLE group and for 1375 each SSRC configured for sending in that "m=" section. 1377 RFC 8843 Bundled Media December 2021 1379 * Construct a table mapping a payload type to an "m=" section for 1380 each "m=" section in the BUNDLE group and for each payload type 1381 configured for receiving in that "m=" section. If any payload 1382 type is configured for receiving in more than one "m=" section in 1383 the BUNDLE group, do not include it in the table, as it cannot be 1384 used to uniquely identify an "m=" section. 1386 * Note that for each of these tables, there can only be one mapping 1387 for any given key (MID, SSRC, or PT). In other words, the tables 1388 are not multimaps. 1390 As "m=" sections are added or removed from the BUNDLE groups, or 1391 their configurations are changed, the tables above MUST also be 1392 updated. 1394 When an RTP packet is received, it MUST be delivered to the RTP 1395 stream corresponding to its SSRC. That RTP stream MUST then be 1396 associated with the correct "m=" section within a BUNDLE group, for 1397 additional processing, according to the following steps: 1399 * If the MID associated with the RTP stream is not in the table 1400 mapping a MID to an "m=" section, then the RTP stream is not 1401 decoded, and the payload data is discarded. 1403 * If the packet has a MID, and the packet's extended sequence number 1404 is greater than that of the last MID update, as discussed in 1405 [RFC7941], Section 4.2.6, update the MID associated with the RTP 1406 stream to match the MID carried in the RTP packet, and then update 1407 the mapping tables to include an entry that maps the SSRC of that 1408 RTP stream to the "m=" section for that MID. 1410 * If the SSRC of the RTP stream is in the incoming SSRC mapping 1411 table, check that the payload type used by the RTP stream matches 1412 a payload type included on the matching "m=" section. If so, 1413 associate the RTP stream with that "m=" section. Otherwise, the 1414 RTP stream is not decoded, and the payload data is discarded. 1416 * If the payload type used by the RTP stream is in the payload type 1417 table, update the incoming SSRC mapping table to include an entry 1418 that maps the RTP stream's SSRC to the "m=" section for that 1419 payload type. Associate the RTP stream with the corresponding 1420 "m=" section. 1422 * Otherwise, mark the RTP stream as "not for decoding" and discard 1423 the payload. 1425 RFC 8843 Bundled Media December 2021 1427 If the RTP packet contains one or more Contributing Source (CSRC) 1428 identifiers, then each CSRC is looked up in the incoming SSRC table, 1429 and a copy of the RTP packet is associated with the corresponding 1430 "m=" section for additional processing. 1432 For each RTCP packet received (including each RTCP packet that is 1433 part of a compound RTCP packet), the packet is processed as usual by 1434 the RTP layer, then associated with the appropriate "m=" sections, 1435 and processed for the RTP streams represented by those "m=" sections. 1436 This routing is type dependent, as each kind of RTCP packet has its 1437 own mechanism for associating it with the relevant RTP streams. 1439 RTCP packets that cannot be associated with an appropriate "m=" 1440 section MUST still be processed as usual by the RTP layer, which 1441 updates the metadata associated with the corresponding RTP streams. 1442 This situation can occur with certain multiparty RTP topologies or 1443 when RTCP packets are sent containing a subset of the SDES 1444 information. 1446 Additional rules for processing various types of RTCP packets are 1447 explained below. 1449 * If the RTCP packet is of type SDES, for each chunk in the packet 1450 whose SSRC is found in the incoming SSRC table, deliver a copy of 1451 the SDES packet to the "m=" section associated with that SSRC. In 1452 addition, for any SDES MID items contained in these chunks, if the 1453 MID is found in the table mapping a MID to an "m=" section, update 1454 the incoming SSRC table to include an entry that maps the RTP 1455 stream associated with the chunk's SSRC to the "m=" section 1456 associated with that MID, unless the packet is older than the 1457 packet that most recently updated the mapping for this SSRC, as 1458 discussed in [RFC7941], Section 4.2.6. 1460 * Note that if an SDES packet is received as part of a compound RTCP 1461 packet, the SSRC to "m=" section mapping might not exist until the 1462 SDES packet is handled (e.g., in the case where RTCP for a source 1463 is received before any RTP packets). Therefore, it can be 1464 beneficial for an implementation to delay RTCP packet routing, 1465 such that it either prioritizes processing of the SDES item to 1466 generate or update the mapping or buffers the RTCP information 1467 that needs to be routed until the SDES item(s) has been processed. 1468 If the implementation is unable to follow this recommendation, the 1469 consequence could be that some RTCP information from this 1470 particular RTCP compound packet is not provided to higher layers. 1471 The impact from this is likely minor, when this information 1472 relates to a future incoming RTP stream. 1474 RFC 8843 Bundled Media December 2021 1476 * If the RTCP packet is of type BYE, it indicates that the RTP 1477 streams referenced in the packet are ending. Therefore, for each 1478 SSRC indicated in the packet that is found in the incoming SSRC 1479 table, first deliver a copy of the BYE packet to the "m=" section 1480 associated with that SSRC, and then remove the entry for that SSRC 1481 from the incoming SSRC table after an appropriate delay to account 1482 for "straggler packets", as specified in [RFC3550], Section 6.2.1. 1484 * If the RTCP packet is of type Sender Report (SR) or Receiver 1485 Report (RR), for each report block in the report whose "SSRC of 1486 source" is found in the outgoing SSRC table, deliver a copy of the 1487 SR or RR packet to the "m=" section associated with that SSRC. In 1488 addition, if the packet is of type SR, and the sender SSRC for the 1489 packet is found in the incoming SSRC table, deliver a copy of the 1490 SR packet to the "m=" section associated with that SSRC. 1492 * If the implementation supports the RTCP Extended Report (XR) and 1493 the packet is of type XR, as defined in [RFC3611], for each report 1494 block in the report whose "SSRC of source" is found in the 1495 outgoing SSRC table, deliver a copy of the XR packet to the "m=" 1496 section associated with that SSRC. In addition, if the sender 1497 SSRC for the packet is found in the incoming SSRC table, deliver a 1498 copy of the XR packet to the "m=" section associated with that 1499 SSRC. 1501 * If the RTCP packet is a feedback message of type RTPFB (transport- 1502 layer FB message) or PSFB (payload-specific FB message), as 1503 defined in [RFC4585], it will contain a media source SSRC, and 1504 this SSRC is used for routing certain subtypes of feedback 1505 messages. However, several subtypes of PSFB and RTPFB messages 1506 include a target SSRC(s) in a section called Feedback Control 1507 Information (FCI). For these messages, the target SSRC(s) is used 1508 for routing. 1510 * If the RTCP packet is a feedback packet that does not include 1511 target SSRCs in its FCI section, and the media source SSRC is 1512 found in the outgoing SSRC table, deliver the feedback packet to 1513 the "m=" section associated with that SSRC. RTPFB and PSFB types 1514 that are handled in this way include: 1516 Generic NACK: (PT=RTPFB, FMT=1) [RFC4585]. 1518 Picture Loss Indication (PLI): (PT=PSFB, FMT=1) [RFC4585]. 1520 Slice Loss Indication (SLI): (PT=PSFB, FMT=2) [RFC4585]. 1522 Reference Picture Selection Indication (RPSI): (PT=PSFB, 1523 FMT=3) [RFC4585]. 1525 RFC 8843 Bundled Media December 2021 1527 * If the RTCP packet is a feedback message that does include a 1528 target SSRC(s) in its FCI section, it can either be a request or a 1529 notification. Requests reference an RTP stream that is being sent 1530 by the message recipient, whereas notifications are responses to 1531 an earlier request and therefore reference an RTP stream that is 1532 being received by the message recipient. 1534 * If the RTCP packet is a feedback request that includes a target 1535 SSRC(s), for each target SSRC that is found in the outgoing SSRC 1536 table, deliver a copy of the RTCP packet to the "m=" section 1537 associated with that SSRC. PSFB and RTPFB types that are handled 1538 in this way include: 1540 Full Intra Request (FIR): (PT=PSFB, FMT=4) [RFC5104]. 1542 Temporal-Spatial Trade-off Request (TSTR): (PT=PSFB, FMT=5) 1543 [RFC5104]. 1545 H.271 Video Back Channel Message (VBCM): (PT=PSFB, FMT=7) 1546 [RFC5104]. 1548 Temporary Maximum Media Stream Bit Rate Request (TMMBR): (PT=R 1549 TPFB, FMT=3) [RFC5104]. 1551 Layer Refresh Request (LRR): (PT=PSFB, FMT=10) [LLR-RTCP]. 1553 * If the RTCP packet is a feedback notification that includes a 1554 target SSRC(s), for each target SSRC that is found in the incoming 1555 SSRC table, deliver a copy of the RTCP packet to the "m=" section 1556 associated with the RTP stream with a matching SSRC. PSFB and 1557 RTPFB types that are handled in this way include: 1559 Temporal-Spatial Trade-off Notification (TSTN): (PT=PSFB, 1560 FMT=6) [RFC5104]. This message is a notification in 1561 response to a prior TSTR. 1563 Temporary Maximum Media Stream Bit Rate Notification 1564 (TMMBN): (PT=RTPFB, FMT=4) [RFC5104]. This message is a 1565 notification in response to a prior TMMBR, but it can also 1566 be sent unsolicited. 1568 If the RTCP packet is of type APP, then it is handled in an 1569 application-specific manner. If the application does not 1570 recognize the APP packet, then it MUST be discarded. 1572 RFC 8843 Bundled Media December 2021 1574 9.3. RTP/RTCP Multiplexing 1576 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 1577 multiplexing [RFC5761] for the RTP-based bundled media (i.e., the 1578 same transport will be used for both RTP packets and RTCP packets). 1579 In addition, the offerer and answerer MUST support the SDP 'rtcp-mux- 1580 only' attribute [RFC8858]. 1582 9.3.1. SDP Offer/Answer Procedures 1584 This section describes how an offerer and answerer use the SDP 'rtcp- 1585 mux' [RFC5761] and SDP 'rtcp-mux-only' attributes [RFC8858] to 1586 negotiate usage of RTP/RTCP multiplexing for RTP-based bundled media. 1588 RTP/RTCP multiplexing only applies to RTP-based media. However, as 1589 described in Section 7.1.3, within an offer or answer the SDP 'rtcp- 1590 mux' and SDP 'rtcp-mux-only' attributes might be included in a 1591 bundled "m=" section for non-RTP-based media (if such "m=" section is 1592 the offerer-tagged "m=" section or answerer-tagged "m=" section). 1594 9.3.1.1. Generating the Initial BUNDLE offer 1596 When an offerer generates an initial BUNDLE offer, if the offer 1597 contains one or more bundled "m=" sections for RTP-based media (or, 1598 if there is a chance that "m=" sections for RTP-based media will 1599 later be added to the BUNDLE group), the offerer MUST include an SDP 1600 'rtcp-mux' attribute [RFC5761] in each bundled "m=" section 1601 (excluding any bundle-only "m=" sections). In addition, the offerer 1602 MAY include an SDP 'rtcp-mux-only' attribute [RFC8858] in one or more 1603 bundled "m=" sections for RTP-based media. 1605 NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute 1606 depends on whether the offerer supports fallback to usage of a 1607 separate port for RTCP in case the answerer moves one or more "m=" 1608 sections for RTP-based media out of the BUNDLE group in the answer. 1610 NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the 1611 bundled "m=" sections, but does not include an SDP 'rtcp-mux-only' 1612 attribute, the offerer can also include an SDP 'rtcp' attribute 1613 [RFC3605] in one or more RTP-based bundled "m=" sections in order to 1614 provide a fallback port for RTCP, as described in [RFC5761]. 1615 However, the fallback port will only be applied to "m=" sections for 1616 RTP-based media that are moved out of the BUNDLE group by the 1617 answerer. 1619 In the initial BUNDLE offer, the address:port combination for RTCP 1620 MUST be unique in each bundled "m=" section for RTP-based media 1621 (excluding a bundle-only "m=" section), similar to RTP. 1623 RFC 8843 Bundled Media December 2021 1625 9.3.1.2. Generating the SDP Answer 1627 When an answerer generates an answer, if the answerer supports RTP- 1628 based media, and if a bundled "m=" section in the corresponding offer 1629 contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage 1630 of RTP/RTCP multiplexing, even if there currently are no bundled "m=" 1631 sections for RTP-based media within the BUNDLE group. The answerer 1632 MUST include an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" 1633 section, following the procedures for BUNDLE attributes 1634 (Section 7.1.3). In addition, if the "m=" section that is selected 1635 as the offerer-tagged "m=" section contained an SDP 'rtcp-mux-only' 1636 attribute, the answerer MUST include an SDP 'rtcp-mux-only' attribute 1637 in the answerer-tagged "m=" section. 1639 In an initial BUNDLE offer, if the suggested offerer-tagged "m=" 1640 section contained an SDP 'rtcp-mux-only' attribute, the "m=" section 1641 was for RTP-based media. If the answerer does not accept the "m=" 1642 section in the created BUNDLE group, and moves the "m=" section out 1643 of the BUNDLE group (Section 7.3.2), the answerer MUST include the 1644 attribute in the moved "m=" section and enable RTP/RTCP multiplexing 1645 for the media associated with the "m=" section. If the answerer 1646 rejects the "m=" section (Section 7.3.3) the answerer MUST NOT 1647 include the attribute. 1649 The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled 1650 "m=" section in the answer. The answerer will use the port value of 1651 the offerer-tagged "m=" section sending RTP and RTCP packets 1652 associated with RTP-based bundled media towards the offerer. 1654 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1655 negotiated in a previous offer/answer exchange, the answerer MUST 1656 include an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" 1657 section. It is not possible to disable RTP/RTCP multiplexing within 1658 a BUNDLE group. 1660 9.3.1.3. Offerer Processing of the SDP Answer 1662 When an offerer receives an answer, if the answerer has accepted the 1663 usage of RTP/RTCP multiplexing (Section 9.3.1.2), the answerer 1664 follows the procedures for RTP/RTCP multiplexing defined in 1665 [RFC5761]. The offerer will use the port value of the answerer- 1666 tagged "m=" section for sending RTP and RTCP packets associated with 1667 RTP-based bundled media towards the answerer. 1669 NOTE: It is considered a protocol error if the answerer has not 1670 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" 1671 sections that the answerer included in the BUNDLE group. 1673 RFC 8843 Bundled Media December 2021 1675 9.3.1.4. Modifying the Session 1677 When an offerer generates a subsequent offer, the offerer MUST 1678 include an SDP 'rtcp-mux' attribute in the offerer-tagged "m=" 1679 section, following the procedures for IDENTICAL multiplexing category 1680 attributes in Section 7.1.3. 1682 10. ICE Considerations 1684 This section describes how to use the BUNDLE grouping extension 1685 together with the ICE mechanism [RFC8445]. 1687 The generic procedures for negotiating the usage of ICE using SDP, 1688 defined in [RFC8839], also apply to the usage of ICE with BUNDLE, 1689 with the following exceptions: 1691 * When the BUNDLE transport has been established, ICE connectivity 1692 checks and keepalives only need to be performed for the BUNDLE 1693 transport, instead of per individual bundled "m=" section within 1694 the BUNDLE group. 1696 * The generic SDP attribute offer/answer considerations 1697 (Section 7.1.3) also apply to ICE-related attributes. Therefore, 1698 when an offerer sends an initial BUNDLE offer (in order to 1699 negotiate a BUNDLE group), the offerer includes ICE-related media- 1700 level attributes in each bundled "m=" section (excluding any 1701 bundle-only "m=" sections), and each "m=" section MUST contain 1702 unique ICE properties. When an answerer generates an answer 1703 (initial BUNDLE answer or subsequent) that contains a BUNDLE 1704 group, and when an offerer sends a subsequent offer that contains 1705 a BUNDLE group, ICE-related media-level attributes are only 1706 included in the tagged "m=" section (suggested offerer-tagged "m=" 1707 section or answerer-tagged "m=" section), and the ICE properties 1708 are applied to each bundled "m=" section within the BUNDLE group. 1710 NOTE: Most ICE-related media-level SDP attributes belong to the 1711 TRANSPORT multiplexing category [RFC8859], and the generic SDP 1712 attribute offer/answer considerations for the TRANSPORT multiplexing 1713 category apply to the attributes. However, in the case of ICE- 1714 related attributes, the same considerations also apply to ICE-related 1715 media-level attributes that belong to other multiplexing categories. 1717 NOTE: The following ICE-related media-level SDP attributes are 1718 defined in [RFC8839]: 'candidate', 'remote-candidates', 'ice- 1719 mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-pacing'. 1721 RFC 8843 Bundled Media December 2021 1723 Initially, before ICE has produced selected candidate pairs that will 1724 be used for media, there might be multiple transports established (if 1725 multiple candidate pairs are tested). Once ICE has selected 1726 candidate pairs, they form the BUNDLE transport. 1728 Support and usage of the ICE mechanism together with the BUNDLE 1729 extension is OPTIONAL, and the procedures in this section only apply 1730 when the ICE mechanism is used. Note that applications might mandate 1731 usage of the ICE mechanism even if the BUNDLE extension is not used. 1733 NOTE: If the Trickle ICE mechanism [RFC8840] is used, an offerer and 1734 answerer might assign a port value of '9' and an IPv4 address of 1735 '0.0.0.0' (or, the IPv6 equivalent '::') to multiple bundled "m=" 1736 sections in the initial BUNDLE offer. The offerer and answerer will 1737 follow the normal procedures for generating the offers and answers, 1738 including picking a bundled "m=" section as the suggested offerer- 1739 tagged "m=" section, selecting the tagged "m=" sections, etc. The 1740 only difference is that media cannot be sent until one or more 1741 candidates have been provided. Once a BUNDLE group has been 1742 negotiated, trickled candidates associated with a bundled "m=" 1743 section will be applied to all bundled "m=" sections within the 1744 BUNDLE group. 1746 11. DTLS Considerations 1748 One or more media streams within a BUNDLE group might use the 1749 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1750 to encrypt the data or negotiate encryption keys if another 1751 encryption mechanism is used to encrypt media. 1753 When DTLS is used within a BUNDLE group, the following rules apply: 1755 * There can only be one DTLS association [RFC6347] associated with 1756 the BUNDLE group; 1758 * Each usage of the DTLS association within the BUNDLE group MUST 1759 use the same mechanism for determining which endpoints (the 1760 offerer or answerer) become DTLS client and DTLS server; 1762 * Each usage of the DTLS association within the BUNDLE group MUST 1763 use the same mechanism for determining whether an offer or answer 1764 will trigger the establishment of a new DTLS association or an 1765 existing DTLS association will be used; and 1767 RFC 8843 Bundled Media December 2021 1769 * If the DTLS client supports DTLS-SRTP, it MUST include the 1770 'use_srtp' extension in the DTLS ClientHello message [RFC5764]. 1771 The client MUST include the extension even if the usage of DTLS- 1772 SRTP is not negotiated as part of the multimedia session (e.g., 1773 the SIP session [RFC3261]). 1775 NOTE: The inclusion of the 'use_srtp' extension during the initial 1776 DTLS handshake ensures that a DTLS renegotiation will not be required 1777 in order to include the extension, in case DTLS-SRTP encrypted media 1778 is added to the BUNDLE group later during the multimedia session. 1780 12. RTP Header Extensions Consideration 1782 When RTP header extensions [RFC8285] are used in the context of this 1783 specification, the identifier used for a given extension MUST 1784 identify the same extension across all the bundled media 1785 descriptions. 1787 13. Update to RFC 3264 1789 This section updates RFC 3264, in order to allow extensions to define 1790 the usage of a zero port value in offers and answers for purposes 1791 other than removing or disabling media streams. The following 1792 sections are being updated: 1794 * "Unicast Streams"; see Section 5.1 of [RFC3264] 1796 * "Putting a Unicast Media Stream on Hold"; see Section 8.4 of 1797 [RFC3264]. 1799 13.1. Original Text from RFC 3264, Section 5.1, 2nd Paragraph 1801 | For recvonly and sendrecv streams, the port number and address in 1802 | the offer indicate where the offerer would like to receive the 1803 | media stream. For sendonly RTP streams, the address and port 1804 | number indirectly indicate where the offerer wants to receive RTCP 1805 | reports. Unless there is an explicit indication otherwise, 1806 | reports are sent to the port number one higher than the number 1807 | indicated. The IP address and port present in the offer indicate 1808 | nothing about the source IP address and source port of RTP and 1809 | RTCP packets that will be sent by the offerer. A port number of 1810 | zero in the offer indicates that the stream is offered but MUST 1811 | NOT be used. This has no useful semantics in an initial offer, 1812 | but is allowed for reasons of completeness, since the answer can 1813 | contain a zero port indicating a rejected stream (Section 6). 1814 | Furthermore, existing streams can be terminated by setting the 1815 | port to zero (Section 8). In general, a port number of zero 1816 | indicates that the media stream is not wanted. 1818 RFC 8843 Bundled Media December 2021 1820 13.2. New Text Replacing RFC 3264, Section 5.1, 2nd Paragraph 1822 For recvonly and sendrecv streams, the port number and address in the 1823 offer indicate where the offerer would like to receive the media 1824 stream. For sendonly RTP streams, the address and port number 1825 indirectly indicate where the offerer wants to receive RTCP reports. 1826 Unless there is an explicit indication otherwise, reports are sent to 1827 the port number one higher than the number indicated. The IP address 1828 and port present in the offer indicate nothing about the source IP 1829 address and source port of the RTP and RTCP packets that will be sent 1830 by the offerer. By default, a port number of zero in the offer 1831 indicates that the stream is offered but MUST NOT be used, but an 1832 extension mechanism might specify different semantics for the usage 1833 of a zero port value. Furthermore, existing streams can be 1834 terminated by setting the port to zero (Section 8). In general, a 1835 port number of zero by default indicates that the media stream is not 1836 wanted. 1838 13.3. Original Text from RFC 3264, Section 8.4, 6th Paragraph 1840 | RFC 2543 [10] specified that placing a user on hold was 1841 | accomplished by setting the connection address to 0.0.0.0. Its 1842 | usage for putting a call on hold is no longer recommended, since 1843 | it doesn't allow for RTCP to be used with held streams, doesn't 1844 | work with IPv6, and breaks with connection oriented media. 1845 | However, it can be useful in an initial offer when the offerer 1846 | knows it wants to use a particular set of media streams and 1847 | formats, but doesn't know the addresses and ports at the time of 1848 | the offer. Of course, when used, the port number MUST NOT be 1849 | zero, which would specify that the stream has been disabled. An 1850 | agent MUST be capable of receiving SDP with a connection address 1851 | of 0.0.0.0, in which case it means that neither RTP nor RTCP 1852 | should be sent to the peer. 1854 13.4. New Text Replacing RFC 3264, Section 8.4, 6th Paragraph 1856 RFC 2543 [RFC2543] specifies that placing a user on hold was 1857 accomplished by setting the connection address to 0.0.0.0. Its usage 1858 for putting a call on hold is no longer recommended, since it doesn't 1859 allow for RTCP to be used with held streams, doesn't work with IPv6, 1860 and breaks with connection oriented media. However, it can be useful 1861 in an initial offer when the offerer knows it wants to use a 1862 particular set of media streams and formats, but doesn't know the 1863 addresses and ports at the time of the offer. Of course, when used, 1864 the port number MUST NOT be zero, if it would specify that the stream 1865 has been disabled. However, an extension mechanism might specify 1866 different semantics of the zero port number usage. An agent MUST be 1867 capable of receiving SDP with a connection address of 0.0.0.0, in 1869 RFC 8843 Bundled Media December 2021 1871 which case it means that neither RTP nor RTCP is to be sent to the 1872 peer. 1874 14. Update to RFC 5888 1876 This section updates RFC 5888 [RFC5888], in order for extensions to 1877 allow an SDP 'group' attribute containing an identification-tag that 1878 identifies an "m=" section with the port set to zero. "Group Value 1879 in Answers" (Section 9.2 of [RFC5888]) is updated. 1881 14.1. Original Text from RFC 5888, Section 9.2, 3rd Paragraph 1883 | SIP entities refuse media streams by setting the port to zero in 1884 | the corresponding "m" line. "a=group" lines MUST NOT contain 1885 | identification-tags that correspond to "m" lines with the port set 1886 | to zero. 1888 14.2. New Text Replacing RFC 5888, Section 9.2, 3rd Paragraph 1890 SIP entities refuse media streams by setting the port to zero in the 1891 corresponding "m" line. "a=group" lines MUST NOT contain 1892 identification-tags that correspond to "m" lines with the port set to 1893 zero, but an extension mechanism might specify different semantics 1894 for including identification-tags that correspond to such "m=" lines. 1896 15. RTP/RTCP Extensions for identification-tag Transport 1898 Offerers and answerers [RFC3264] can associate identification-tags 1899 with "m=" sections within offers and answers, using the procedures in 1900 [RFC5888]. Each identification-tag uniquely represents an "m=" 1901 section. 1903 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1904 used to carry identification-tags within RTCP SDES packets. This 1905 section also defines a new RTP SDES header extension [RFC7941], which 1906 is used to carry the 'MID' RTCP SDES item in RTP packets. 1908 The SDES item and RTP SDES header extension make it possible for a 1909 receiver to associate each RTP stream with a specific "m=" section, 1910 with which the receiver has associated an identification-tag, even if 1911 those "m=" sections are part of the same RTP session. The RTP SDES 1912 header extension also ensures that the media recipient gets the 1913 identification-tag upon receipt of the first decodable media and is 1914 able to associate the media with the correct application. 1916 RFC 8843 Bundled Media December 2021 1918 A media recipient informs the media sender about the identification- 1919 tag associated with an "m=" section through the use of a 'mid' 1920 attribute [RFC5888]. The media sender then inserts the 1921 identification-tag in RTCP and RTP packets sent to the media 1922 recipient. 1924 NOTE: The text above defines how identification-tags are carried in 1925 offers and answers. The usage of other signaling protocols for 1926 carrying identification-tags is not prevented, but the usage of such 1927 protocols is outside the scope of this document. 1929 [RFC3550] defines general procedures regarding the RTCP transmission 1930 interval. The RTCP MID SDES item SHOULD be sent in the first few 1931 RTCP packets after joining the session and SHOULD be sent regularly 1932 thereafter. The exact number of RTCP packets in which this SDES item 1933 is sent is intentionally not specified here, as it will depend on the 1934 expected packet-loss rate, the RTCP reporting interval, and the 1935 allowable overhead. 1937 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1938 be included in some RTP packets at the start of the session and 1939 whenever the SSRC changes. It might also be useful to include the 1940 header extension in RTP packets that comprise access points in the 1941 media (e.g., with video I-frames). The exact number of RTP packets 1942 in which this header extension is sent is intentionally not specified 1943 here, as it will depend on expected packet-loss rate and loss 1944 patterns, the overhead the application can tolerate, and the 1945 importance of immediate receipt of the identification-tag. 1947 For robustness, endpoints need to be prepared for situations where 1948 the reception of the identification-tag is delayed and SHOULD NOT 1949 terminate sessions in such cases, as the identification-tag is likely 1950 to arrive soon. 1952 15.1. RTCP MID SDES Item 1954 0 1 2 3 1955 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 | MID=15 | length | identification-tag ... 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP. 1962 The identification-tag is not zero terminated. 1964 RFC 8843 Bundled Media December 2021 1966 15.2. RTP SDES Header Extension For MID 1968 The payload, containing the identification-tag, of the RTP SDES 1969 header extension element can be encoded using either the 1-byte or 1970 the 2-byte header [RFC7941]. The identification-tag payload is UTF-8 1971 encoded, as in SDP. 1973 The identification-tag is not zero terminated. Note that the set of 1974 header extensions included in the packet needs to be padded to the 1975 next 32-bit boundary using zero bytes [RFC8285]. 1977 As the identification-tag is included in an RTCP SDES item, an RTP 1978 SDES header extension, or both, there needs to be some consideration 1979 about the packet expansion caused by the identification-tag. To 1980 avoid Maximum Transmission Unit (MTU) issues for the RTP packets, the 1981 header extension's size needs to be taken into account when encoding 1982 the media. 1984 It is recommended that the identification-tag be kept short. Due to 1985 the properties of the RTP header extension mechanism, when using the 1986 1-byte header, a tag that is 1-3 bytes will result in a minimal 1987 number of 32-bit words used for the RTP SDES header extension, in 1988 case no other header extensions are included at the same time. Note, 1989 do take into account that some single characters when UTF-8 encoded 1990 will result in multiple octets. The identification-tag MUST NOT 1991 contain any user information, and applications SHALL avoid generating 1992 the identification-tag using a pattern that enables user or 1993 application identification. 1995 16. IANA Considerations 1997 16.1. New SDES Item 1999 This document updates the MID SDES item to the IANA "RTP SDES Item 2000 Types" registry as follows: 2002 Value: 15 2004 Abbrev.: MID 2006 Name: Media Identification 2008 Reference: RFC XXXX 2010 RFC 8843 Bundled Media December 2021 2012 16.2. New RTP SDES Header Extension URI 2014 This document updates the extension URI in the RTP SDES Compact 2015 Header Extensions sub-registry of the RTP Compact Header Extensions 2016 registry sub-registry, according to the following data: 2018 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 2020 Description: Media identification 2022 Contact: IESG (iesg@ietf.org) 2024 Reference: RFC XXXX 2026 The SDES item does not reveal privacy information about the users. 2027 It is simply used to associate RTP-based media with the correct SDP 2028 media description ("m=" section) in the SDP used to negotiate the 2029 media. 2031 The purpose of the extension is for the offerer to be able to 2032 associate received multiplexed RTP-based media before the offerer 2033 receives the associated answer. 2035 16.3. New SDP Attribute 2037 This document updates the SDP media-level attribute, 'bundle-only', 2038 according to the following data: 2040 Attribute name: bundle-only 2042 Type of attribute: media 2044 Subject to charset: No 2046 Purpose: Request a media description to be accepted in the answer 2047 only if kept within a BUNDLE group by the answerer. 2049 Appropriate values: N/A 2051 Contact name: IESG 2053 Contact e-mail: iesg@ietf.org 2055 Reference: RFC XXXX 2057 Mux category: NORMAL 2059 RFC 8843 Bundled Media December 2021 2061 16.4. New SDP Group Semantics 2063 This document updates the following semantics in the "Semantics for 2064 the 'group' SDP Attribute" subregistry (under the "Session 2065 Description Protocol (SDP) Parameters" registry): 2067 +================+========+==============+===========+ 2068 | Semantics | Token | Mux Category | Reference | 2069 +================+========+==============+===========+ 2070 | Media bundling | BUNDLE | NORMAL | RFC XXXX | 2071 +----------------+--------+--------------+-----------+ 2073 Table 1 2075 17. Security Considerations 2077 The security considerations defined in [RFC3264] and [RFC5888] apply 2078 to the BUNDLE extension. BUNDLE does not change which information, 2079 e.g., RTP streams, flows over the network, except for the usage of 2080 the MID SDES item as discussed below. Primarily, it changes which 2081 addresses and ports, and thus in which (RTP) sessions, the 2082 information flows to. This affects the security contexts being used 2083 and can cause previously separated information flows to share the 2084 same security context. This has very little impact on the 2085 performance of the security mechanism of the RTP sessions. In cases 2086 where one would have applied different security policies on the 2087 different RTP streams being bundled, or where the parties having 2088 access to the security contexts would have differed between the RTP 2089 streams, additional analysis of the implications are needed before 2090 selecting to apply BUNDLE. 2092 The identification-tag, independent of transport, RTCP SDES packet, 2093 or RTP header extension, can expose the value to parties beyond the 2094 signaling chain. Therefore, the identification-tag values MUST be 2095 generated in a fashion that does not leak user information, e.g., 2096 randomly or using a per-bundle group counter, and SHOULD be 3 bytes 2097 or fewer to allow them to efficiently fit into the MID RTP header 2098 extension. Note that if implementations use different methods for 2099 generating identification-tags, this could enable fingerprinting of 2100 the implementation making it vulnerable to targeted attacks. The 2101 identification-tag is exposed on the RTP stream level when included 2102 in the RTP header extensions; however, what it reveals of the RTP 2103 media stream structure of the endpoint and application was already 2104 possible to deduce from the RTP streams without the MID SDES header 2105 extensions. As the identification-tag is also used to route the 2106 media stream to the right application functionality, it is important 2107 that the value received is the one intended by the sender; thus, 2108 integrity and the authenticity of the source are important to prevent 2110 RFC 8843 Bundled Media December 2021 2112 denial of service on the application. Existing SRTP configurations 2113 and other security mechanisms protecting the whole RTP/RTCP packets 2114 will provide the necessary protection. 2116 When the BUNDLE extension is used, the set of configurations of the 2117 security mechanism used in all the bundled media descriptions will 2118 need to be compatible so that they can be used simultaneously, at 2119 least per direction or endpoint. When using SRTP, this will be the 2120 case, at least for the IETF-defined key-management solutions due to 2121 their SDP attributes ("a=crypto", "a=fingerprint", "a=mikey") and 2122 their classification in [RFC8859]. 2124 The security considerations of "RTP Header Extension for the RTP 2125 Control Protocol (RTCP) Source Description Items" [RFC7941] require 2126 that when RTCP is confidentiality protected, any SDES RTP header 2127 extension carrying an SDES item, such as the MID RTP header 2128 extension, is also protected using commensurate strength algorithms. 2129 However, assuming the above requirements and recommendations are 2130 followed, there are no known significant security risks with leaving 2131 the MID RTP header extension without confidentiality protection. 2132 Therefore, this specification updates RFC 7941 by adding the 2133 exception that this requirement MAY be ignored for the MID RTP header 2134 extension. Security mechanisms for RTP/RTCP are discussed in 2135 "Options for Securing RTP Sessions" [RFC7201], for example, SRTP 2136 [RFC3711] can provide the necessary security functions of ensuring 2137 the integrity and source authenticity. 2139 18. Examples 2141 18.1. Example: Tagged "m=" Section Selections 2143 The example below shows: 2145 * An initial BUNDLE offer, in which the offerer wants to negotiate a 2146 BUNDLE group and indicates the audio "m=" section as the suggested 2147 offerer-tagged "m=" section. 2149 * An initial BUNDLE answer, in which the answerer accepts the 2150 creation of the BUNDLE group, selects the audio "m=" section in 2151 the offer as the offerer-tagged "m=" section, selects the audio 2152 "m=" section in the answer as the answerer-tagged "m=" section, 2153 and assigns the answerer BUNDLE address:port to that "m=" section. 2155 SDP Offer (1) 2157 RFC 8843 Bundled Media December 2021 2159 v=0 2160 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2161 s= 2162 c=IN IP6 2001:db8::3 2163 t=0 0 2164 a=group:BUNDLE foo bar 2166 m=audio 10000 RTP/AVP 0 8 97 2167 b=AS:200 2168 a=mid:foo 2169 a=rtcp-mux 2170 a=rtpmap:0 PCMU/8000 2171 a=rtpmap:8 PCMA/8000 2172 a=rtpmap:97 iLBC/8000 2173 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2175 m=video 10002 RTP/AVP 31 32 2176 b=AS:1000 2177 a=mid:bar 2178 a=rtcp-mux 2179 a=rtpmap:31 H261/90000 2180 a=rtpmap:32 MPV/90000 2181 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2183 SDP Answer (2) 2185 v=0 2186 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2187 s= 2188 c=IN IP6 2001:db8::1 2189 t=0 0 2190 a=group:BUNDLE foo bar 2192 m=audio 20000 RTP/AVP 0 2193 b=AS:200 2194 a=mid:foo 2195 a=rtcp-mux 2196 a=rtpmap:0 PCMU/8000 2197 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2199 m=video 20000 RTP/AVP 32 2200 b=AS:1000 2201 a=mid:bar 2202 a=rtpmap:32 MPV/90000 2203 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2205 RFC 8843 Bundled Media December 2021 2207 18.2. Example: BUNDLE Group Rejected 2209 The example below shows: 2211 * An initial BUNDLE offer, in which the offerer wants to negotiate a 2212 BUNDLE group and indicates the audio "m=" section as the suggested 2213 offerer-tagged "m=" section. 2215 * An initial BUNDLE answer, in which the answerer rejects the 2216 creation of the BUNDLE group, generates a normal answer, and 2217 assigns a unique address:port to each "m=" section in the answer. 2219 SDP Offer (1) 2221 v=0 2222 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2223 s= 2224 c=IN IP6 2001:db8::3 2225 t=0 0 2226 a=group:BUNDLE foo bar 2228 m=audio 10000 RTP/AVP 0 8 97 2229 b=AS:200 2230 a=mid:foo 2231 a=rtcp-mux 2232 a=rtpmap:0 PCMU/8000 2233 a=rtpmap:8 PCMA/8000 2234 a=rtpmap:97 iLBC/8000 2235 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2237 m=video 10002 RTP/AVP 31 32 2238 b=AS:1000 2239 a=mid:bar 2240 a=rtcp-mux 2241 a=rtpmap:31 H261/90000 2242 a=rtpmap:32 MPV/90000 2243 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2245 SDP Answer (2) 2247 RFC 8843 Bundled Media December 2021 2249 v=0 2250 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2251 s= 2252 c=IN IP6 2001:db8::1 2253 t=0 0 2255 m=audio 20000 RTP/AVP 0 2256 b=AS:200 2257 a=rtcp-mux 2258 a=rtpmap:0 PCMU/8000 2260 m=video 30000 RTP/AVP 32 2261 b=AS:1000 2262 a=rtcp-mux 2263 a=rtpmap:32 MPV/90000 2265 18.3. Example: Offerer Adds a Media Description to a BUNDLE Group 2267 The example below shows: 2269 * A subsequent offer, in which the offerer adds a new bundled "m=" 2270 section (video), indicated by the "zen" identification-tag, to a 2271 previously negotiated BUNDLE group; indicates the new "m=" section 2272 as the offerer-tagged "m=" section; and assigns the offerer BUNDLE 2273 address:port to that "m=" section. 2275 * A subsequent answer, in which the answerer indicates the new video 2276 "m=" section in the answer as the answerer-tagged "m=" section and 2277 assigns the answerer BUNDLE address:port to that "m=" section. 2279 SDP Offer (1) 2281 RFC 8843 Bundled Media December 2021 2283 v=0 2284 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2285 s= 2286 c=IN IP6 2001:db8::3 2287 t=0 0 2288 a=group:BUNDLE zen foo bar 2290 m=audio 10000 RTP/AVP 0 8 97 2291 b=AS:200 2292 a=mid:foo 2293 a=rtpmap:0 PCMU/8000 2294 a=rtpmap:8 PCMA/8000 2295 a=rtpmap:97 iLBC/8000 2296 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2298 m=video 10000 RTP/AVP 31 32 2299 b=AS:1000 2300 a=mid:bar 2301 a=rtpmap:31 H261/90000 2302 a=rtpmap:32 MPV/90000 2303 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2305 m=video 10000 RTP/AVP 66 2306 b=AS:1000 2307 a=mid:zen 2308 a=rtcp-mux 2309 a=rtpmap:66 H261/90000 2310 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2312 SDP Answer (2) 2314 RFC 8843 Bundled Media December 2021 2316 v=0 2317 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2318 s= 2319 c=IN IP6 2001:db8::1 2320 t=0 0 2321 a=group:BUNDLE zen foo bar 2323 m=audio 20000 RTP/AVP 0 2324 b=AS:200 2325 a=mid:foo 2326 a=rtpmap:0 PCMU/8000 2327 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2329 m=video 20000 RTP/AVP 32 2330 b=AS:1000 2331 a=mid:bar 2332 a=rtpmap:32 MPV/90000 2333 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2335 m=video 20000 RTP/AVP 66 2336 b=AS:1000 2337 a=mid:zen 2338 a=rtcp-mux 2339 a=rtpmap:66 H261/90000 2340 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2342 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 2344 The example below shows: 2346 * A subsequent offer, in which the offerer removes an "m=" section 2347 (video), indicated by the "zen" identification-tag, from a 2348 previously negotiated BUNDLE group; indicates one of the bundled 2349 "m=" sections (audio) remaining in the BUNDLE group as the 2350 offerer-tagged "m=" section; and assigns the offerer BUNDLE 2351 address:port to that "m=" section. 2353 * A subsequent answer, in which the answerer removes the "m=" 2354 section from the BUNDLE group, indicates the audio "m=" section in 2355 the answer as the answerer-tagged "m=" section, and assigns the 2356 answerer BUNDLE address:port to that "m=" section. 2358 SDP Offer (1) 2360 RFC 8843 Bundled Media December 2021 2362 v=0 2363 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2364 s= 2365 c=IN IP6 2001:db8::3 2366 t=0 0 2367 a=group:BUNDLE foo bar 2369 m=audio 10000 RTP/AVP 0 8 97 2370 b=AS:200 2371 a=mid:foo 2372 a=rtcp-mux 2373 a=rtpmap:0 PCMU/8000 2374 a=rtpmap:8 PCMA/8000 2375 a=rtpmap:97 iLBC/8000 2376 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2378 m=video 10000 RTP/AVP 31 32 2379 b=AS:1000 2380 a=mid:bar 2381 a=rtpmap:31 H261/90000 2382 a=rtpmap:32 MPV/90000 2383 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2385 m=video 50000 RTP/AVP 66 2386 b=AS:1000 2387 a=mid:zen 2388 a=rtcp-mux 2389 a=rtpmap:66 H261/90000 2391 SDP Answer (2) 2393 RFC 8843 Bundled Media December 2021 2395 v=0 2396 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2397 s= 2398 c=IN IP6 2001:db8::1 2399 t=0 0 2400 a=group:BUNDLE foo bar 2402 m=audio 20000 RTP/AVP 0 2403 b=AS:200 2404 a=mid:foo 2405 a=rtcp-mux 2406 a=rtpmap:0 PCMU/8000 2407 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2409 m=video 20000 RTP/AVP 32 2410 b=AS:1000 2411 a=mid:bar 2412 a=rtpmap:32 MPV/90000 2413 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2415 m=video 60000 RTP/AVP 66 2416 b=AS:1000 2417 a=mid:zen 2418 a=rtcp-mux 2419 a=rtpmap:66 H261/90000 2421 18.5. Example: Offerer Disables a Media Description within a BUNDLE 2422 Group 2424 The example below shows: 2426 * A subsequent offer, in which the offerer disables (by assigning a 2427 zero port value) an "m=" section (video), indicated by the "zen" 2428 identification-tag, from a previously negotiated BUNDLE group; 2429 indicates one of the bundled "m=" sections (audio) remaining 2430 active in the BUNDLE group as the offerer-tagged "m=" section; and 2431 assigns the offerer BUNDLE address:port to that "m=" section. 2433 * A subsequent answer, in which the answerer disables the "m=" 2434 section, indicates the audio "m=" section in the answer as the 2435 answerer-tagged "m=" section, and assigns the answerer BUNDLE 2436 address:port to that "m=" section. 2438 SDP Offer (1) 2440 RFC 8843 Bundled Media December 2021 2442 v=0 2443 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2444 s= 2445 t=0 0 2446 a=group:BUNDLE foo bar 2448 m=audio 10000 RTP/AVP 0 8 97 2449 c=IN IP6 2001:db8::3 2450 b=AS:200 2451 a=mid:foo 2452 a=rtcp-mux 2453 a=rtpmap:0 PCMU/8000 2454 a=rtpmap:8 PCMA/8000 2455 a=rtpmap:97 iLBC/8000 2456 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2458 m=video 10000 RTP/AVP 31 32 2459 c=IN IP6 2001:db8::3 2460 b=AS:1000 2461 a=mid:bar 2462 a=rtpmap:31 H261/90000 2463 a=rtpmap:32 MPV/90000 2464 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2466 m=video 0 RTP/AVP 66 2467 a=mid:zen 2468 a=rtpmap:66 H261/90000 2470 SDP Answer (2) 2472 RFC 8843 Bundled Media December 2021 2474 v=0 2475 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2476 s= 2477 t=0 0 2478 a=group:BUNDLE foo bar 2480 m=audio 20000 RTP/AVP 0 2481 c=IN IP6 2001:db8::1 2482 b=AS:200 2483 a=mid:foo 2484 a=rtcp-mux 2485 a=rtpmap:0 PCMU/8000 2486 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2488 m=video 20000 RTP/AVP 32 2489 c=IN IP6 2001:db8::1 2490 b=AS:1000 2491 a=mid:bar 2492 a=rtpmap:32 MPV/90000 2493 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2495 m=video 0 RTP/AVP 66 2496 a=mid:zen 2497 a=rtpmap:66 H261/90000 2499 19. References 2501 19.1. Normative References 2503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2504 Requirement Levels", BCP 14, RFC 2119, 2505 DOI 10.17487/RFC2119, March 1997, 2506 . 2508 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2509 with Session Description Protocol (SDP)", RFC 3264, 2510 DOI 10.17487/RFC3264, June 2002, 2511 . 2513 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2514 Jacobson, "RTP: A Transport Protocol for Real-Time 2515 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2516 July 2003, . 2518 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2519 in Session Description Protocol (SDP)", RFC 3605, 2520 DOI 10.17487/RFC3605, October 2003, 2521 . 2523 RFC 8843 Bundled Media December 2021 2525 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2526 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2527 2003, . 2529 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2530 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2531 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2532 . 2534 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2535 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2536 July 2006, . 2538 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2539 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2540 . 2542 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2543 Control Packets on a Single Port", RFC 5761, 2544 DOI 10.17487/RFC5761, April 2010, 2545 . 2547 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2548 Security (DTLS) Extension to Establish Keys for the Secure 2549 Real-time Transport Protocol (SRTP)", RFC 5764, 2550 DOI 10.17487/RFC5764, May 2010, 2551 . 2553 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2554 Protocol (SDP) Grouping Framework", RFC 5888, 2555 DOI 10.17487/RFC5888, June 2010, 2556 . 2558 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2559 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2560 January 2012, . 2562 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2563 Header Extension for the RTP Control Protocol (RTCP) 2564 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2565 August 2016, . 2567 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2568 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2569 May 2017, . 2571 RFC 8843 Bundled Media December 2021 2573 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 2574 Mechanism for RTP Header Extensions", RFC 8285, 2575 DOI 10.17487/RFC8285, October 2017, 2576 . 2578 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2579 Connectivity Establishment (ICE): A Protocol for Network 2580 Address Translator (NAT) Traversal", RFC 8445, 2581 DOI 10.17487/RFC8445, July 2018, 2582 . 2584 [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keranen, 2585 A., and R. Shpount, "Session Description Protocol (SDP) 2586 Offer/Answer Procedures for Interactive Connectivity 2587 Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, 2588 January 2021, . 2590 [RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 2591 Session Initiation Protocol (SIP) Usage for Incremental 2592 Provisioning of Candidates for the Interactive 2593 Connectivity Establishment (Trickle ICE)", RFC 8840, 2594 DOI 10.17487/RFC8840, January 2021, 2595 . 2597 [RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP 2598 Control Protocol (RTCP) Multiplexing Using the Session 2599 Description Protocol (SDP)", RFC 8858, 2600 DOI 10.17487/RFC8858, January 2021, 2601 . 2603 [RFC8859] Nandakumar, S., "A Framework for Session Description 2604 Protocol (SDP) Attributes When Multiplexing", RFC 8859, 2605 DOI 10.17487/RFC8859, January 2021, 2606 . 2608 19.2. Informative References 2610 [LLR-RTCP] Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 2611 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 2612 Message", Work in Progress, Internet-Draft, draft-ietf- 2613 avtext-lrr-07, 2 July 2017, 2614 . 2617 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 2618 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 2619 DOI 10.17487/RFC2543, March 1999, 2620 . 2622 RFC 8843 Bundled Media December 2021 2624 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2625 A., Peterson, J., Sparks, R., Handley, M., and E. 2626 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2627 DOI 10.17487/RFC3261, June 2002, 2628 . 2630 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2631 "RTP Control Protocol Extended Reports (RTCP XR)", 2632 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2633 . 2635 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2636 "Extended RTP Profile for Real-time Transport Control 2637 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2638 DOI 10.17487/RFC4585, July 2006, 2639 . 2641 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2642 "Codec Control Messages in the RTP Audio-Visual Profile 2643 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 2644 February 2008, . 2646 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2647 Media Attributes in the Session Description Protocol 2648 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2649 . 2651 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2652 Clock Rates in an RTP Session", RFC 7160, 2653 DOI 10.17487/RFC7160, April 2014, 2654 . 2656 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2657 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2658 . 2660 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2661 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2662 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2663 DOI 10.17487/RFC7656, November 2015, 2664 . 2666 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 2667 (Diffserv) and Real-Time Communication", RFC 7657, 2668 DOI 10.17487/RFC7657, November 2015, 2669 . 2671 RFC 8843 Bundled Media December 2021 2673 [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., 2674 "JavaScript Session Establishment Protocol (JSEP)", 2675 RFC 8829, DOI 10.17487/RFC8829, January 2021, 2676 . 2678 [RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: 2679 Incremental Provisioning of Candidates for the Interactive 2680 Connectivity Establishment (ICE) Protocol", RFC 8838, 2681 DOI 10.17487/RFC8838, January 2021, 2682 . 2684 Appendix A. Design Considerations 2686 One of the main issues regarding the BUNDLE grouping extensions has 2687 been whether, in offers and answers, the same port value can be 2688 inserted in "m=" lines associated with a BUNDLE group, as the purpose 2689 of the extension is to negotiate the usage of a single transport for 2690 media specified by the "m=" sections. Issues with both approaches, 2691 discussed in the Appendix, have been raised. The outcome was to 2692 specify a mechanism that uses offers with both different and 2693 identical port values. 2695 Below are the primary issues that have been considered when defining 2696 the "BUNDLE" grouping extension: 2698 1) Interoperability with existing User Agents (UAs). 2700 2) Interoperability with intermediary Back-to-Back User Agent 2701 (B2BUA) and proxy entities. 2703 3) Time to gather, and the number of, ICE candidates. 2705 4) Different error scenarios and when they occur. 2707 5) SDP offer/answer impacts, including usage of port number value 2708 zero. 2710 A.1. UA Interoperability 2712 Consider the following SDP offer/answer exchange, where Alice sends 2713 an offer to Bob: 2715 SDP Offer 2717 RFC 8843 Bundled Media December 2021 2719 v=0 2720 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2721 s= 2722 c=IN IP4 atlanta.example.com 2723 t=0 0 2725 m=audio 10000 RTP/AVP 97 2726 a=rtpmap:97 iLBC/8000 2727 m=video 10002 RTP/AVP 97 2728 a=rtpmap:97 H261/90000 2730 SDP Answer 2732 v=0 2733 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2734 s= 2735 c=IN IP4 biloxi.example.com 2736 t=0 0 2738 m=audio 20000 RTP/AVP 97 2739 a=rtpmap:97 iLBC/8000 2740 m=video 20002 RTP/AVP 97 2741 a=rtpmap:97 H261/90000 2743 RFC 4961 specifies a way of doing symmetric RTP, but that is a later 2744 extension to RTP, and Bob cannot assume that Alice supports RFC 4961. 2745 This means that Alice may be sending RTP from a different port than 2746 10000 or 10002 -- some implementations simply send the RTP from an 2747 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2748 way that Bob knows if the packet is to be passed to the video or 2749 audio codec is by looking at the port it was received on. This 2750 prompted some SDP implementations to use a port number as an index to 2751 find the correct "m=" line in the SDP, since each "m"= section 2752 contains a different port number. As a result, some implementations 2753 that do support symmetric RTP and ICE still use an SDP data structure 2754 where SDP with "m=" sections with the same port such as: 2756 SDP Offer 2758 RFC 8843 Bundled Media December 2021 2760 v=0 2761 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2762 s= 2763 c=IN IP4 atlanta.example.com 2764 t=0 0 2766 m=audio 10000 RTP/AVP 97 2767 a=rtpmap:97 iLBC/8000 2768 m=video 10000 RTP/AVP 98 2769 a=rtpmap:98 H261/90000 2771 will result in the second "m=" section being considered an SDP error 2772 because it has the same port as the first line. 2774 A.2. Usage of Port Number Value Zero 2776 In an offer or answer, the media specified by an "m=" section can be 2777 disabled/rejected by setting the port number value to zero. This is 2778 different from, e.g., using the SDP direction attributes, where RTCP 2779 traffic will continue even if the SDP 'inactive' attribute is 2780 indicated for the associated "m=" section. 2782 If each "m=" section associated with a BUNDLE group would contain 2783 different port values, and one of those port values would be used for 2784 a BUNDLE address:port associated with the BUNDLE group, problems 2785 would occur if an endpoint wants to disable/reject the "m=" section 2786 associated with that port, by setting the port value to zero. After 2787 that, no "m=" section would contain the port value that is used for 2788 the BUNDLE address:port. In addition, it is unclear what would 2789 happen to the ICE candidates associated with the "m=" section, as 2790 they are also used for the BUNDLE address:port. 2792 A.3. B2BUA and Proxy Interoperability 2794 Some back-to-back user agents may be configured in a mode where if 2795 the incoming call leg contains an SDP attribute the B2BUA does not 2796 understand, the B2BUA still generates that SDP attribute in the offer 2797 for the outgoing call leg. Consider a B2BUA that did not understand 2798 the SDP 'rtcp' attribute, defined in RFC 3605, yet acted this way. 2799 Further, assume that the B2BUA was configured to tear down any call 2800 where it did not see any RTCP for 5 minutes. In this case, if the 2801 B2BUA received an offer like: 2803 SDP Offer 2805 RFC 8843 Bundled Media December 2021 2807 v=0 2808 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2809 s= 2810 c=IN IP4 atlanta.example.com 2811 t=0 0 2813 m=audio 49170 RTP/AVP 0 2814 a=rtcp:53020 2816 It would be looking for RTCP on port 49171 but would not see any 2817 because the RTCP would be on port 53020, and after five minutes, it 2818 would tear down the call. Similarly, a B2BUA that did not understand 2819 BUNDLE yet put it in its offer may be looking for media on the wrong 2820 port and tear down the call. It is worth noting that a B2BUA that 2821 generated an offer with capabilities it does not understand is not 2822 compliant with the specifications. 2824 A.3.1. Traffic Policing 2826 Sometimes intermediaries do not act as B2BUAs, in the sense that they 2827 don't modify SDP bodies nor do they terminate SIP dialogs. However, 2828 they may still use SDP information (e.g., IP address and port) in 2829 order to control traffic gating functions and to set traffic policing 2830 rules. There might be rules that will trigger a session to be 2831 terminated in case media is not sent or received on the ports 2832 retrieved from the SDP. This typically occurs once the session is 2833 already established and ongoing. 2835 A.3.2. Bandwidth Allocation 2837 Sometimes, intermediaries do not act as B2BUAs, in the sense that 2838 they don't modify SDP bodies nor do they terminate SIP dialogs. 2839 However, they may still use SDP information (e.g., codecs and media 2840 types) in order to control bandwidth allocation functions. The 2841 bandwidth allocation is done per "m=" section, which means that it 2842 might not be enough if media specified by all "m=" sections try to 2843 use that bandwidth. That may simply lead to either bad user 2844 experience or termination of the call. 2846 A.4. Candidate Gathering 2848 When using ICE, a candidate needs to be gathered for each port. This 2849 takes approximately 20 ms extra for each extra "m=" section due to 2850 the NAT pacing requirements. All of this gathering can be overlapped 2851 with other things while, e.g., a web page is loading to minimize the 2852 impact. If the client only wants to generate Traversal Using Relays 2853 around NAT (TURN) or STUN ICE candidates for one of the "m=" lines 2854 and then use Trickle ICE [RFC8838] to get the non-host ICE candidates 2856 RFC 8843 Bundled Media December 2021 2858 for the rest of the "m=" sections, it MAY do that and will not need 2859 any additional gathering time. 2861 Some people have suggested a TURN extension to get a bunch of TURN 2862 allocations at once. This would only provide a single STUN result, 2863 so in cases where the other end did not support BUNDLE, it may cause 2864 more use of the TURN server, but it would be quick in the cases where 2865 both sides supported BUNDLE and would fall back to a successful call 2866 in the other cases. 2868 Acknowledgements 2870 The usage of the SDP grouping extension for negotiating bundled media 2871 is based on similar alternatives proposed by Harald Alvestrand and 2872 Cullen Jennings. The BUNDLE extension described in this document is 2873 based on the different alternative proposals, and text (e.g., SDP 2874 examples) has been borrowed (and, in some cases, modified) from those 2875 alternative proposals. 2877 The SDP examples are also modified versions from the ones in the 2878 Alvestrand proposal. 2880 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 2881 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 2882 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin 2883 Uberti, Taylor Brandstetter, Byron Campen, and Eric Rescorla for 2884 reading the text and providing useful feedback. 2886 Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus 2887 Westerlund for providing the text for the section on RTP/RTCP stream 2888 association. 2890 Thanks to Magnus Westerlund, Colin Perkins, and Jonathan Lennox for 2891 providing help and text on the RTP/RTCP procedures. 2893 Thanks to Charlie Kaufman for performing the Sec-Dir review. 2895 Thanks to Linda Dunbar for performing the Gen-ART review. 2897 Thanks to Spotify for providing music for the countless hours of 2898 document editing. 2900 Authors' Addresses 2901 RFC 8843 Bundled Media December 2021 2903 Christer Holmberg 2904 Ericsson 2905 Hirsalantie 11 2906 FI-02420 Jorvas 2907 Finland 2909 Email: christer.holmberg@ericsson.com 2911 Harald Tveit Alvestrand 2912 Google 2913 Kungsbron 2 2914 SE-11122 Stockholm 2915 Sweden 2917 Email: harald@alvestrand.no 2919 Cullen Jennings 2920 Cisco 2921 400 3rd Avenue SW, Suite 350 2922 Calgary AB T2P 4H2 2923 Canada 2925 Email: fluffy@iii.ca