idnits 2.17.1 draft-ietf-mmusic-rfc8843bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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 (6 September 2021) is 935 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 1823 ** 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) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 6 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: 10 March 2022 Cisco 8 6 September 2021 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-rfc8843bis-05 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 10 March 2022. 49 RFC 8843 Bundled Media September 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 Simplified BSD License text 62 as described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Simplified 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 September 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 . . . . . . . . . . 21 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 . . . . 23 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 . . . 24 112 7.6. SIP Considerations . . . . . . . . . . . . . . . . . . . 24 113 8. Protocol Identification . . . . . . . . . . . . . . . . . . . 25 114 8.1. STUN, DTLS, and SRTP . . . . . . . . . . . . . . . . . . 25 115 9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 26 116 9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 26 117 9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . . . . . 39 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 . . . . . . . . . . . . . . . . . . . 41 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 September 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 September 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 September 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 September 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 September 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 September 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 September 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 September 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 September 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 September 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 September 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 September 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 September 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 September 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 September 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 September 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 September 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 RFC 8843 Bundled Media September 2021 975 7.4. Offerer Processing of the SDP Answer 977 When an offerer receives an answer, if the answer contains a BUNDLE 978 group, the offerer MUST check that any bundled "m=" section in the 979 answer was indicated as bundled in the corresponding offer (for the 980 same BUNDLE group). If there is no mismatch, the offerer MUST apply 981 the properties (BUNDLE address:port, BUNDLE attributes, etc.) of the 982 offerer-tagged "m=" section (selected by the answerer; see 983 Section 7.3.1) to each bundled "m=" section within the BUNDLE group. 985 NOTE: As the answerer might reject one or more bundled "m=" sections 986 in an initial BUNDLE offer, or move a bundled "m=" section out of a 987 BUNDLE group, a given bundled "m=" section in the offer might not be 988 indicated as bundled in the corresponding answer. 990 If the answer does not contain a BUNDLE group, the offerer MUST 991 process the answer as a normal answer. 993 7.4.1. RFC 8843 Considerations 995 In RFC 8843, instead of assigning the answerer BUNDLE address:port to 996 each "m=" section within the BUNDLE group when generating the SDP 997 Answer (Section 7.3), the answerer only assigned the answerer BUNDLE 998 address:port to the answerer-tagged "m=" section. For every other 999 "m=" section within the BUNDLE group, the answerer included an SDP 1000 'bundle-only' attribute in, and assigned a zero port value to, the 1001 "m=" section. The way an offerer compliant to this specification 1002 processes such SDP Answer is considered an implementation issue 1003 (e.g., based on whether the answerer needs to be backward compatible 1004 with RFC 8843 compliant offerers), and is outside the scope of this 1005 specification. The example below shows such SDP Answer: 1007 SDP Answer 1009 RFC 8843 Bundled Media September 2021 1011 v=0 1012 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1013 s= 1014 c=IN IP6 2001:db8::1 1015 t=0 0 1016 a=group:BUNDLE foo bar 1018 m=audio 20000 RTP/AVP 0 1019 b=AS:200 1020 a=mid:foo 1021 a=rtcp-mux 1022 a=rtpmap:0 PCMU/8000 1023 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1025 m=video 0 RTP/AVP 32 1026 b=AS:1000 1027 a=mid:bar 1028 a=bundle-only 1029 a=rtpmap:32 MPV/90000 1030 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1032 7.5. Modifying the Session 1034 When a BUNDLE group has been previously negotiated, and an offerer 1035 generates a subsequent offer, the offerer MUST: 1037 * Pick one bundled "m=" section as the offerer-tagged "m=" section. 1038 The offerer can pick either the "m=" section that was previously 1039 selected by the answerer as the offerer-tagged "m=" section or 1040 another bundled "m=" section within the BUNDLE group; 1042 * Assign a BUNDLE address:port (previously negotiated or newly 1043 suggested) to the offerer-tagged "m=" section, and to every other 1044 bundled "m=" section within the BUNDLE group; 1046 * Include SDP attributes in the bundled "m=" sections following the 1047 rules in Section 7.1.3; 1049 * Include an SDP 'group:BUNDLE' attribute in the offer; and 1051 * Place the identification-tag of each bundled "m=" section in the 1052 SDP 'group:BUNDLE' attribute identification-tag list. The offerer 1053 BUNDLE-tag indicates the offerer-tagged "m=" section. 1055 The offerer MUST NOT pick a given bundled "m=" section as the 1056 offerer-tagged "m=" section if: 1058 RFC 8843 Bundled Media September 2021 1060 * The offerer wants to move the "m=" section out of the BUNDLE group 1061 (Section 7.5.2), or 1063 * The offerer wants to disable the "m=" section (Section 7.5.3). 1065 The offerer can modify the offerer BUNDLE address:port, add and 1066 remove SDP attributes, or modify SDP attribute values in the 1067 subsequent offer. Changes to the offerer BUNDLE address:port and the 1068 offerer BUNDLE attributes will (if the offer is accepted by the 1069 answerer) be applied to each bundled "m=" section within the BUNDLE 1070 group. 1072 7.5.1. Adding a Media Description to a BUNDLE Group 1074 When an offerer generates a subsequent offer, in which it wants to 1075 add a bundled "m=" section to a previously negotiated BUNDLE group, 1076 the offerer follows the procedures in Section 7.5. The offerer picks 1077 either the added "m=" section or an "m=" section previously added to 1078 the BUNDLE group as the offerer-tagged "m=" section. 1080 NOTE: As described in Section 7.3.2, the answerer cannot move the 1081 added "m=" section out of the BUNDLE group in its answer. If the 1082 answerer wants to move the "m=" section out of the BUNDLE group, it 1083 will have to first accept it into the BUNDLE group in the answer, and 1084 then send a subsequent offer where the "m=" section is moved out of 1085 the BUNDLE group (Section 7.5.2). 1087 7.5.2. Moving a Media Description Out of a BUNDLE Group 1089 When an offerer generates a subsequent offer, in which it wants to 1090 remove a bundled "m=" section from a BUNDLE group, the offerer: 1092 * MUST assign a unique address:port to the "m=" section; 1094 * MUST include SDP attributes in the "m=" section following the 1095 normal offer/answer rules for each attribute; 1097 * MUST NOT place the identification-tag associated with the "m=" 1098 section in the SDP 'group:BUNDLE' attribute identification-tag 1099 list associated with the BUNDLE group; and 1101 * MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 1102 section. 1104 For the other bundled "m=" sections within the BUNDLE group, the 1105 offerer follows the procedures in Section 7.5. 1107 RFC 8843 Bundled Media September 2021 1109 An offerer MUST NOT move an "m=" section from one BUNDLE group to 1110 another within a single offer. If the offerer wants to move an "m=" 1111 section from one BUNDLE group to another, it MUST first move the 1112 BUNDLE group out of the current BUNDLE group, and then generate a 1113 second offer where the "m=" section is added to another BUNDLE group 1114 (Section 7.5.1). 1116 Section 18.4 shows an example of an offer for moving an "m=" section 1117 out of a BUNDLE group. 1119 7.5.3. Disabling a Media Description in a BUNDLE Group 1121 When an offerer generates a subsequent offer, in which it wants to 1122 disable a bundled "m=" section from a BUNDLE group, the offerer: 1124 * MUST assign a zero port value to the "m=" section, following the 1125 procedures in [RFC4566]; 1127 * MUST NOT place the identification-tag associated with the "m=" 1128 section in the SDP 'group:BUNDLE' attribute identification-tag 1129 list associated with the BUNDLE group; and 1131 * MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 1132 section. 1134 For the other bundled "m=" sections within the BUNDLE group, the 1135 offerer follows the procedures in Section 7.5. 1137 Section 18.5 shows an example of an offer and answer for disabling an 1138 "m=" section within a BUNDLE group. 1140 7.6. SIP Considerations 1142 The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent 1143 Client (UAC) to send a re-INVITE request without an SDP body 1144 (sometimes referred to as an empty re-INVITE). In such cases, the 1145 User Agent Server (UAS) will include an SDP Offer in the associated 1146 200 OK response. This is typically used for 3rd Party Call Control 1147 (3PCC) scenarios. From a BUNDLE perspective, such SDP Offer SHOULD 1148 be generated using the procedures defined in Section 7.2. 1150 RFC 8843 Bundled Media September 2021 1152 8. Protocol Identification 1154 Each "m=" section within a BUNDLE group MUST use the same transport- 1155 layer protocol. If bundled "m=" sections use different upper-layer 1156 protocols on top of the transport-layer protocol, there MUST exist a 1157 publicly available specification that describes how a mechanism 1158 associates received data with the correct protocol for this 1159 particular protocol combination. 1161 In addition, if received data can be associated with more than one 1162 bundled "m=" section, there MUST exist a publicly available 1163 specification that describes a mechanism for associating the received 1164 data with the correct "m=" section. 1166 This document describes a mechanism to identify the protocol of 1167 received data among the Session Traversal Utilities for NAT (STUN), 1168 DTLS, and the Secure Real-time Transport Protocol (SRTP) (in any 1169 combination) when UDP is used as a transport-layer protocol, but it 1170 does not describe how to identify different protocols transported on 1171 DTLS. While the mechanism is generally applicable to other protocols 1172 and transport-layer protocols, any such use requires further 1173 specification that encompasses how to multiplex multiple protocols on 1174 a given transport-layer protocol and how to associate received data 1175 with the correct protocols. 1177 8.1. STUN, DTLS, and SRTP 1179 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 1180 protocol of a received packet among the STUN, DTLS, and SRTP 1181 protocols (in any combination). If an offer or answer includes a 1182 bundled "m=" section that represents these protocols, the offerer or 1183 answerer MUST support the mechanism described in [RFC5764], and no 1184 explicit negotiation is required in order to indicate support and 1185 usage of the mechanism. 1187 [RFC5764] does not describe how to identify different protocols 1188 transported on DTLS, only how to identify the DTLS protocol itself. 1189 If multiple protocols are transported on DTLS, there MUST exist a 1190 specification describing a mechanism for identifying each individual 1191 protocol. In addition, if a received DTLS packet can be associated 1192 with more than one "m=" section, there MUST exist a specification 1193 that describes a mechanism for associating the received DTLS packets 1194 with the correct "m=" section. 1196 Section 9.2 describes how to associate the packets in a received SRTP 1197 stream with the correct "m=" section. 1199 RFC 8843 Bundled Media September 2021 1201 9. RTP Considerations 1203 9.1. Single RTP Session 1205 All RTP-based media within a single BUNDLE group belong to a single 1206 RTP session [RFC3550]. 1208 Since a single BUNDLE transport is used for sending and receiving 1209 bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for 1210 RTP-based bundled media. 1212 Since a single RTP session is used for each BUNDLE group, all "m=" 1213 sections representing RTP-based media within a BUNDLE group will 1214 share a single Synchronization Source (SSRC) numbering space 1215 [RFC3550]. 1217 The following rules and restrictions apply for a single RTP session: 1219 * A specific payload type value can be used in multiple bundled "m=" 1220 sections only if each codec associated with the payload type 1221 number shares an identical codec configuration (Section 9.1.1). 1223 * The proto value in each bundled RTP-based "m=" section MUST be 1224 identical (e.g., RTP/AVPF). 1226 * The RTP MID header extension MUST be enabled, by including an SDP 1227 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 1228 hdrext:sdes:mid' URI value defined in this specification, in each 1229 bundled RTP-based "m=" section in every offer and answer. 1231 * A given SSRC MUST NOT transmit RTP packets using payload types 1232 that originate from different bundled "m=" sections. 1234 NOTE: The last bullet above is to avoid sending multiple media types 1235 from the same SSRC. If transmission of multiple media types are done 1236 with time overlap, RTP and RTCP fail to function. Even if done in 1237 proper sequence, this causes RTP timestamp rate switching issues 1238 [RFC7160]. However, once an SSRC has left the RTP session (by 1239 sending an RTCP BYE packet), that SSRC can be reused by another 1240 source (possibly associated with a different bundled "m=" section) 1241 after a delay of 5 RTCP reporting intervals (the delay is to ensure 1242 the SSRC has timed out, in case the RTCP BYE packet was lost 1243 [RFC3550]). 1245 [RFC7657] defines Differentiated Services (Diffserv) considerations 1246 for RTP-based bundled media sent using a mixture of Diffserv 1247 Codepoints. 1249 RFC 8843 Bundled Media September 2021 1251 9.1.1. Payload Type (PT) Value Reuse 1253 Multiple bundled "m=" sections might describe RTP-based media. As 1254 all RTP-based media associated with a BUNDLE group belong to the same 1255 RTP session, in order for a given payload type value to be used 1256 inside more than one bundled "m=" section, all codecs associated with 1257 the payload type number MUST share an identical codec configuration. 1258 This means that the codecs MUST share the same media type, encoding 1259 name, clock rate, and any parameter that can affect the codec 1260 configuration and packetization. [RFC8859] lists SDP attributes, 1261 whose attribute values are required to be identical for all codecs 1262 that use the same payload type value. 1264 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 1265 Description 1267 As described in [RFC3550], RTP packets are associated with RTP 1268 streams [RFC7656]. Each RTP stream is identified by an SSRC value, 1269 and each RTP packet includes an SSRC field that is used to associate 1270 the packet with the correct RTP stream. RTCP packets also use SSRCs 1271 to identify which RTP streams the packet relates to. However, an 1272 RTCP packet can contain multiple SSRC fields, in the course of 1273 providing feedback or reports on different RTP streams, and therefore 1274 can be associated with multiple such streams. 1276 In order to be able to process received RTP/RTCP packets correctly, 1277 it MUST be possible to associate an RTP stream with the correct "m=" 1278 section, as the "m=" section and SDP attributes associated with the 1279 "m=" section contains information needed to process the packets. 1281 As all RTP streams associated with a BUNDLE group use the same 1282 transport for sending and receiving RTP/RTCP packets, the local 1283 address:port combination part of the transport cannot be used to 1284 associate an RTP stream with the correct "m=" section. In addition, 1285 multiple RTP streams might be associated with the same "m=" section. 1287 An offerer and answerer can inform each other which SSRC values they 1288 will use for an RTP stream by using the SDP 'ssrc' attribute 1289 [RFC5576]. However, an offerer will not know which SSRC values the 1290 answerer will use until the offerer has received the answer providing 1291 that information. Due to this, before the offerer has received the 1292 answer, the offerer will not be able to associate an RTP stream with 1293 the correct "m=" section using the SSRC value associated with the RTP 1294 stream. In addition, the offerer and answerer may start using new 1295 SSRC values mid-session, without informing each other about using the 1296 SDP 'ssrc' attribute. 1298 RFC 8843 Bundled Media September 2021 1300 In order for an offerer and answerer to always be able to associate 1301 an RTP stream with the correct "m=" section, the offerer and answerer 1302 using the BUNDLE extension MUST support the mechanism defined in 1303 Section 15, where the offerer and answerer insert the identification- 1304 tag associated with an "m=" section (provided by the remote peer) 1305 into RTP and RTCP packets associated with a BUNDLE group. 1307 When using this mechanism, the mapping from an SSRC to an 1308 identification-tag is carried in RTP header extensions or RTCP SDES 1309 packets, as specified in Section 15. Since a compound RTCP packet 1310 can contain multiple RTCP SDES packets, and each RTCP SDES packet can 1311 contain multiple chunks, a single RTCP packet can contain several 1312 mappings of SSRC to identification-tag. The offerer and answerer 1313 maintain tables used for routing that are updated each time an RTP/ 1314 RTCP packet contains new information that affects how packets are to 1315 be routed. 1317 However, some legacy implementations may not include this 1318 identification-tag in their RTP and RTCP traffic when using the 1319 BUNDLE mechanism and instead use a mechanism based on the payload 1320 type to associate RTP streams with SDP "m=" sections. In this 1321 situation, each "m=" section needs to use unique payload type values, 1322 in order for the payload type to be a reliable indicator of the 1323 relevant "m=" section for the RTP stream. If an implementation fails 1324 to ensure unique payload type values, it will be impossible to 1325 associate the RTP stream using that payload type value to a 1326 particular "m=" section. Note that when using the payload type to 1327 associate RTP streams with "m=" sections, an RTP stream, identified 1328 by its SSRC, will be mapped to an "m=" section when the first packet 1329 of that RTP stream is received, and the mapping will not be changed 1330 even if the payload type used by that RTP stream changes. In other 1331 words, the SSRC cannot "move" to a different "m=" section simply by 1332 changing the payload type. 1334 Applications can implement RTP stacks in different ways. The 1335 algorithm below details one way that RTP streams can be associated 1336 with "m=" sections, but it is not meant to be prescriptive about 1337 exactly how an RTP stack needs to be implemented. Applications MAY 1338 use any algorithm that achieves equivalent results to those described 1339 in the algorithm below. 1341 To prepare to associate RTP streams with the correct "m=" section, 1342 the following steps MUST be followed for each BUNDLE group: 1344 * Construct a table mapping a MID to an "m=" section for each "m=" 1345 section in this BUNDLE group. Note that an "m=" section may only 1346 have one MID. 1348 RFC 8843 Bundled Media September 2021 1350 * Construct a table mapping SSRCs of incoming RTP streams to an "m=" 1351 section for each "m=" section in this BUNDLE group and for each 1352 SSRC configured for receiving in that "m=" section. 1354 * Construct a table mapping the SSRC of each outgoing RTP stream to 1355 an "m=" section for each "m=" section in this BUNDLE group and for 1356 each SSRC configured for sending in that "m=" section. 1358 * Construct a table mapping a payload type to an "m=" section for 1359 each "m=" section in the BUNDLE group and for each payload type 1360 configured for receiving in that "m=" section. If any payload 1361 type is configured for receiving in more than one "m=" section in 1362 the BUNDLE group, do not include it in the table, as it cannot be 1363 used to uniquely identify an "m=" section. 1365 * Note that for each of these tables, there can only be one mapping 1366 for any given key (MID, SSRC, or PT). In other words, the tables 1367 are not multimaps. 1369 As "m=" sections are added or removed from the BUNDLE groups, or 1370 their configurations are changed, the tables above MUST also be 1371 updated. 1373 When an RTP packet is received, it MUST be delivered to the RTP 1374 stream corresponding to its SSRC. That RTP stream MUST then be 1375 associated with the correct "m=" section within a BUNDLE group, for 1376 additional processing, according to the following steps: 1378 * If the MID associated with the RTP stream is not in the table 1379 mapping a MID to an "m=" section, then the RTP stream is not 1380 decoded, and the payload data is discarded. 1382 * If the packet has a MID, and the packet's extended sequence number 1383 is greater than that of the last MID update, as discussed in 1384 [RFC7941], Section 4.2.6, update the MID associated with the RTP 1385 stream to match the MID carried in the RTP packet, and then update 1386 the mapping tables to include an entry that maps the SSRC of that 1387 RTP stream to the "m=" section for that MID. 1389 * If the SSRC of the RTP stream is in the incoming SSRC mapping 1390 table, check that the payload type used by the RTP stream matches 1391 a payload type included on the matching "m=" section. If so, 1392 associate the RTP stream with that "m=" section. Otherwise, the 1393 RTP stream is not decoded, and the payload data is discarded. 1395 RFC 8843 Bundled Media September 2021 1397 * If the payload type used by the RTP stream is in the payload type 1398 table, update the incoming SSRC mapping table to include an entry 1399 that maps the RTP stream's SSRC to the "m=" section for that 1400 payload type. Associate the RTP stream with the corresponding 1401 "m=" section. 1403 * Otherwise, mark the RTP stream as "not for decoding" and discard 1404 the payload. 1406 If the RTP packet contains one or more Contributing Source (CSRC) 1407 identifiers, then each CSRC is looked up in the incoming SSRC table, 1408 and a copy of the RTP packet is associated with the corresponding 1409 "m=" section for additional processing. 1411 For each RTCP packet received (including each RTCP packet that is 1412 part of a compound RTCP packet), the packet is processed as usual by 1413 the RTP layer, then associated with the appropriate "m=" sections, 1414 and processed for the RTP streams represented by those "m=" sections. 1415 This routing is type dependent, as each kind of RTCP packet has its 1416 own mechanism for associating it with the relevant RTP streams. 1418 RTCP packets that cannot be associated with an appropriate "m=" 1419 section MUST still be processed as usual by the RTP layer, which 1420 updates the metadata associated with the corresponding RTP streams. 1421 This situation can occur with certain multiparty RTP topologies or 1422 when RTCP packets are sent containing a subset of the SDES 1423 information. 1425 Additional rules for processing various types of RTCP packets are 1426 explained below. 1428 * If the RTCP packet is of type SDES, for each chunk in the packet 1429 whose SSRC is found in the incoming SSRC table, deliver a copy of 1430 the SDES packet to the "m=" section associated with that SSRC. In 1431 addition, for any SDES MID items contained in these chunks, if the 1432 MID is found in the table mapping a MID to an "m=" section, update 1433 the incoming SSRC table to include an entry that maps the RTP 1434 stream associated with the chunk's SSRC to the "m=" section 1435 associated with that MID, unless the packet is older than the 1436 packet that most recently updated the mapping for this SSRC, as 1437 discussed in [RFC7941], Section 4.2.6. 1439 * Note that if an SDES packet is received as part of a compound RTCP 1440 packet, the SSRC to "m=" section mapping might not exist until the 1441 SDES packet is handled (e.g., in the case where RTCP for a source 1442 is received before any RTP packets). Therefore, it can be 1443 beneficial for an implementation to delay RTCP packet routing, 1444 such that it either prioritizes processing of the SDES item to 1446 RFC 8843 Bundled Media September 2021 1448 generate or update the mapping or buffers the RTCP information 1449 that needs to be routed until the SDES item(s) has been processed. 1450 If the implementation is unable to follow this recommendation, the 1451 consequence could be that some RTCP information from this 1452 particular RTCP compound packet is not provided to higher layers. 1453 The impact from this is likely minor, when this information 1454 relates to a future incoming RTP stream. 1456 * If the RTCP packet is of type BYE, it indicates that the RTP 1457 streams referenced in the packet are ending. Therefore, for each 1458 SSRC indicated in the packet that is found in the incoming SSRC 1459 table, first deliver a copy of the BYE packet to the "m=" section 1460 associated with that SSRC, and then remove the entry for that SSRC 1461 from the incoming SSRC table after an appropriate delay to account 1462 for "straggler packets", as specified in [RFC3550], Section 6.2.1. 1464 * If the RTCP packet is of type Sender Report (SR) or Receiver 1465 Report (RR), for each report block in the report whose "SSRC of 1466 source" is found in the outgoing SSRC table, deliver a copy of the 1467 SR or RR packet to the "m=" section associated with that SSRC. In 1468 addition, if the packet is of type SR, and the sender SSRC for the 1469 packet is found in the incoming SSRC table, deliver a copy of the 1470 SR packet to the "m=" section associated with that SSRC. 1472 * If the implementation supports the RTCP Extended Report (XR) and 1473 the packet is of type XR, as defined in [RFC3611], for each report 1474 block in the report whose "SSRC of source" is found in the 1475 outgoing SSRC table, deliver a copy of the XR packet to the "m=" 1476 section associated with that SSRC. In addition, if the sender 1477 SSRC for the packet is found in the incoming SSRC table, deliver a 1478 copy of the XR packet to the "m=" section associated with that 1479 SSRC. 1481 * If the RTCP packet is a feedback message of type RTPFB (transport- 1482 layer FB message) or PSFB (payload-specific FB message), as 1483 defined in [RFC4585], it will contain a media source SSRC, and 1484 this SSRC is used for routing certain subtypes of feedback 1485 messages. However, several subtypes of PSFB and RTPFB messages 1486 include a target SSRC(s) in a section called Feedback Control 1487 Information (FCI). For these messages, the target SSRC(s) is used 1488 for routing. 1490 * If the RTCP packet is a feedback packet that does not include 1491 target SSRCs in its FCI section, and the media source SSRC is 1492 found in the outgoing SSRC table, deliver the feedback packet to 1493 the "m=" section associated with that SSRC. RTPFB and PSFB types 1494 that are handled in this way include: 1496 RFC 8843 Bundled Media September 2021 1498 Generic NACK: (PT=RTPFB, FMT=1) [RFC4585]. 1500 Picture Loss Indication (PLI): (PT=PSFB, FMT=1) [RFC4585]. 1502 Slice Loss Indication (SLI): (PT=PSFB, FMT=2) [RFC4585]. 1504 Reference Picture Selection Indication (RPSI): (PT=PSFB, 1505 FMT=3) [RFC4585]. 1507 * If the RTCP packet is a feedback message that does include a 1508 target SSRC(s) in its FCI section, it can either be a request or a 1509 notification. Requests reference an RTP stream that is being sent 1510 by the message recipient, whereas notifications are responses to 1511 an earlier request and therefore reference an RTP stream that is 1512 being received by the message recipient. 1514 * If the RTCP packet is a feedback request that includes a target 1515 SSRC(s), for each target SSRC that is found in the outgoing SSRC 1516 table, deliver a copy of the RTCP packet to the "m=" section 1517 associated with that SSRC. PSFB and RTPFB types that are handled 1518 in this way include: 1520 Full Intra Request (FIR): (PT=PSFB, FMT=4) [RFC5104]. 1522 Temporal-Spatial Trade-off Request (TSTR): (PT=PSFB, FMT=5) 1523 [RFC5104]. 1525 H.271 Video Back Channel Message (VBCM): (PT=PSFB, FMT=7) 1526 [RFC5104]. 1528 Temporary Maximum Media Stream Bit Rate Request (TMMBR): (PT=R 1529 TPFB, FMT=3) [RFC5104]. 1531 Layer Refresh Request (LRR): (PT=PSFB, FMT=10) [LLR-RTCP]. 1533 * If the RTCP packet is a feedback notification that includes a 1534 target SSRC(s), for each target SSRC that is found in the incoming 1535 SSRC table, deliver a copy of the RTCP packet to the "m=" section 1536 associated with the RTP stream with a matching SSRC. PSFB and 1537 RTPFB types that are handled in this way include: 1539 Temporal-Spatial Trade-off Notification (TSTN): (PT=PSFB, 1540 FMT=6) [RFC5104]. This message is a notification in 1541 response to a prior TSTR. 1543 Temporary Maximum Media Stream Bit Rate Notification 1544 (TMMBN): (PT=RTPFB, FMT=4) [RFC5104]. This message is a 1546 RFC 8843 Bundled Media September 2021 1548 notification in response to a prior TMMBR, but it can also 1549 be sent unsolicited. 1551 If the RTCP packet is of type APP, then it is handled in an 1552 application-specific manner. If the application does not 1553 recognize the APP packet, then it MUST be discarded. 1555 9.3. RTP/RTCP Multiplexing 1557 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 1558 multiplexing [RFC5761] for the RTP-based bundled media (i.e., the 1559 same transport will be used for both RTP packets and RTCP packets). 1560 In addition, the offerer and answerer MUST support the SDP 'rtcp-mux- 1561 only' attribute [RFC8858]. 1563 9.3.1. SDP Offer/Answer Procedures 1565 This section describes how an offerer and answerer use the SDP 'rtcp- 1566 mux' [RFC5761] and SDP 'rtcp-mux-only' attributes [RFC8858] to 1567 negotiate usage of RTP/RTCP multiplexing for RTP-based bundled media. 1569 RTP/RTCP multiplexing only applies to RTP-based media. However, as 1570 described in Section 7.1.3, within an offer or answer the SDP 'rtcp- 1571 mux' and SDP 'rtcp-mux-only' attributes might be included in a 1572 bundled "m=" section for non-RTP-based media (if such "m=" section is 1573 the offerer-tagged "m=" section or answerer-tagged "m=" section). 1575 9.3.1.1. Generating the Initial BUNDLE Offer 1577 When an offerer generates an initial BUNDLE offer, if the offer 1578 contains one or more bundled "m=" sections for RTP-based media (or, 1579 if there is a chance that "m=" sections for RTP-based media will 1580 later be added to the BUNDLE group), the offerer MUST include an SDP 1581 'rtcp-mux' attribute [RFC5761] in each bundled "m=" section 1582 (excluding any bundle-only "m=" sections). In addition, the offerer 1583 MAY include an SDP 'rtcp-mux-only' attribute [RFC8858] in one or more 1584 bundled "m=" sections for RTP-based media. 1586 NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute 1587 depends on whether the offerer supports fallback to usage of a 1588 separate port for RTCP in case the answerer moves one or more "m=" 1589 sections for RTP-based media out of the BUNDLE group in the answer. 1591 NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the 1592 bundled "m=" sections, but does not include an SDP 'rtcp-mux-only' 1593 attribute, the offerer can also include an SDP 'rtcp' attribute 1594 [RFC3605] in one or more RTP-based bundled "m=" sections in order to 1595 provide a fallback port for RTCP, as described in [RFC5761]. 1597 RFC 8843 Bundled Media September 2021 1599 However, the fallback port will only be applied to "m=" sections for 1600 RTP-based media that are moved out of the BUNDLE group by the 1601 answerer. 1603 In the initial BUNDLE offer, the address:port combination for RTCP 1604 MUST be unique in each bundled "m=" section for RTP-based media 1605 (excluding a bundle-only "m=" section), similar to RTP. 1607 9.3.1.2. Generating the SDP Answer 1609 When an answerer generates an answer, if the answerer supports RTP- 1610 based media, and if a bundled "m=" section in the corresponding offer 1611 contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage 1612 of RTP/RTCP multiplexing, even if there currently are no bundled "m=" 1613 sections for RTP-based media within the BUNDLE group. The answerer 1614 MUST include an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" 1615 section, following the procedures for BUNDLE attributes 1616 (Section 7.1.3). In addition, if the "m=" section that is selected 1617 as the offerer-tagged "m=" section contained an SDP 'rtcp-mux-only' 1618 attribute, the answerer MUST include an SDP 'rtcp-mux-only' attribute 1619 in the answerer-tagged "m=" section. 1621 In an initial BUNDLE offer, if the suggested offerer-tagged "m=" 1622 section contained an SDP 'rtcp-mux-only' attribute, the "m=" section 1623 was for RTP-based media. If the answerer does not accept the "m=" 1624 section in the created BUNDLE group, and moves the "m=" section out 1625 of the BUNDLE group (Section 7.3.2), the answerer MUST include the 1626 attribute in the moved "m=" section and enable RTP/RTCP multiplexing 1627 for the media associated with the "m=" section. If the answerer 1628 rejects the "m=" section (Section 7.3.3) the answerer MUST NOT 1629 include the attribute. 1631 The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled 1632 "m=" section in the answer. The answerer will use the port value of 1633 the offerer-tagged "m=" section sending RTP and RTCP packets 1634 associated with RTP-based bundled media towards the offerer. 1636 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1637 negotiated in a previous offer/answer exchange, the answerer MUST 1638 include an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" 1639 section. It is not possible to disable RTP/RTCP multiplexing within 1640 a BUNDLE group. 1642 RFC 8843 Bundled Media September 2021 1644 9.3.1.3. Offerer Processing of the SDP Answer 1646 When an offerer receives an answer, if the answerer has accepted the 1647 usage of RTP/RTCP multiplexing (Section 9.3.1.2), the answerer 1648 follows the procedures for RTP/RTCP multiplexing defined in 1649 [RFC5761]. The offerer will use the port value of the answerer- 1650 tagged "m=" section for sending RTP and RTCP packets associated with 1651 RTP-based bundled media towards the answerer. 1653 NOTE: It is considered a protocol error if the answerer has not 1654 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" 1655 sections that the answerer included in the BUNDLE group. 1657 9.3.1.4. Modifying the Session 1659 When an offerer generates a subsequent offer, the offerer MUST 1660 include an SDP 'rtcp-mux' attribute in the offerer-tagged "m=" 1661 section, following the procedures for IDENTICAL multiplexing category 1662 attributes in Section 7.1.3. 1664 10. ICE Considerations 1666 This section describes how to use the BUNDLE grouping extension 1667 together with the ICE mechanism [RFC8445]. 1669 The generic procedures for negotiating the usage of ICE using SDP, 1670 defined in [RFC8839], also apply to the usage of ICE with BUNDLE, 1671 with the following exceptions: 1673 * When the BUNDLE transport has been established, ICE connectivity 1674 checks and keepalives only need to be performed for the BUNDLE 1675 transport, instead of per individual bundled "m=" section within 1676 the BUNDLE group. 1678 * The generic SDP attribute offer/answer considerations 1679 (Section 7.1.3) also apply to ICE-related attributes. Therefore, 1680 when an offerer sends an initial BUNDLE offer (in order to 1681 negotiate a BUNDLE group), the offerer includes ICE-related media- 1682 level attributes in each bundled "m=" section (excluding any 1683 bundle-only "m=" sections), and each "m=" section MUST contain 1684 unique ICE properties. When an answerer generates an answer 1685 (initial BUNDLE answer or subsequent) that contains a BUNDLE 1686 group, and when an offerer sends a subsequent offer that contains 1687 a BUNDLE group, ICE-related media-level attributes are only 1688 included in the tagged "m=" section (suggested offerer-tagged "m=" 1689 section or answerer-tagged "m=" section), and the ICE properties 1690 are applied to each bundled "m=" section within the BUNDLE group. 1692 RFC 8843 Bundled Media September 2021 1694 NOTE: Most ICE-related media-level SDP attributes belong to the 1695 TRANSPORT multiplexing category [RFC8859], and the generic SDP 1696 attribute offer/answer considerations for the TRANSPORT multiplexing 1697 category apply to the attributes. However, in the case of ICE- 1698 related attributes, the same considerations also apply to ICE-related 1699 media-level attributes that belong to other multiplexing categories. 1701 NOTE: The following ICE-related media-level SDP attributes are 1702 defined in [RFC8839]: 'candidate', 'remote-candidates', 'ice- 1703 mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-pacing'. 1705 Initially, before ICE has produced selected candidate pairs that will 1706 be used for media, there might be multiple transports established (if 1707 multiple candidate pairs are tested). Once ICE has selected 1708 candidate pairs, they form the BUNDLE transport. 1710 Support and usage of the ICE mechanism together with the BUNDLE 1711 extension is OPTIONAL, and the procedures in this section only apply 1712 when the ICE mechanism is used. Note that applications might mandate 1713 usage of the ICE mechanism even if the BUNDLE extension is not used. 1715 NOTE: If the Trickle ICE mechanism [RFC8840] is used, an offerer and 1716 answerer might assign a port value of '9' and an IPv4 address of 1717 '0.0.0.0' (or, the IPv6 equivalent '::') to multiple bundled "m=" 1718 sections in the initial BUNDLE offer. The offerer and answerer will 1719 follow the normal procedures for generating the offers and answers, 1720 including picking a bundled "m=" section as the suggested offerer- 1721 tagged "m=" section, selecting the tagged "m=" sections, etc. The 1722 only difference is that media cannot be sent until one or more 1723 candidates have been provided. Once a BUNDLE group has been 1724 negotiated, trickled candidates associated with a bundled "m=" 1725 section will be applied to all bundled "m=" sections within the 1726 BUNDLE group. 1728 11. DTLS Considerations 1730 One or more media streams within a BUNDLE group might use the 1731 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1732 to encrypt the data or negotiate encryption keys if another 1733 encryption mechanism is used to encrypt media. 1735 When DTLS is used within a BUNDLE group, the following rules apply: 1737 * There can only be one DTLS association [RFC6347] associated with 1738 the BUNDLE group; 1740 RFC 8843 Bundled Media September 2021 1742 * Each usage of the DTLS association within the BUNDLE group MUST 1743 use the same mechanism for determining which endpoints (the 1744 offerer or answerer) become DTLS client and DTLS server; 1746 * Each usage of the DTLS association within the BUNDLE group MUST 1747 use the same mechanism for determining whether an offer or answer 1748 will trigger the establishment of a new DTLS association or an 1749 existing DTLS association will be used; and 1751 * If the DTLS client supports DTLS-SRTP, it MUST include the 1752 'use_srtp' extension in the DTLS ClientHello message [RFC5764]. 1753 The client MUST include the extension even if the usage of DTLS- 1754 SRTP is not negotiated as part of the multimedia session (e.g., 1755 the SIP session [RFC3261]). 1757 NOTE: The inclusion of the 'use_srtp' extension during the initial 1758 DTLS handshake ensures that a DTLS renegotiation will not be required 1759 in order to include the extension, in case DTLS-SRTP encrypted media 1760 is added to the BUNDLE group later during the multimedia session. 1762 12. RTP Header Extensions Consideration 1764 When RTP header extensions [RFC8285] are used in the context of this 1765 specification, the identifier used for a given extension MUST 1766 identify the same extension across all the bundled media 1767 descriptions. 1769 13. Update to RFC 3264 1771 This section updates RFC 3264, in order to allow extensions to define 1772 the usage of a zero port value in offers and answers for purposes 1773 other than removing or disabling media streams. The following 1774 sections are being updated: 1776 * "Unicast Streams"; see Section 5.1 of [RFC3264] 1778 * "Putting a Unicast Media Stream on Hold"; see Section 8.4 of 1779 [RFC3264]. 1781 13.1. Original Text from RFC 3264, Section 5.1, 2nd Paragraph 1783 | For recvonly and sendrecv streams, the port number and address in 1784 | the offer indicate where the offerer would like to receive the 1785 | media stream. For sendonly RTP streams, the address and port 1786 | number indirectly indicate where the offerer wants to receive RTCP 1787 | reports. Unless there is an explicit indication otherwise, 1788 | reports are sent to the port number one higher than the number 1789 | indicated. The IP address and port present in the offer indicate 1791 RFC 8843 Bundled Media September 2021 1793 | nothing about the source IP address and source port of RTP and 1794 | RTCP packets that will be sent by the offerer. A port number of 1795 | zero in the offer indicates that the stream is offered but MUST 1796 | NOT be used. This has no useful semantics in an initial offer, 1797 | but is allowed for reasons of completeness, since the answer can 1798 | contain a zero port indicating a rejected stream (Section 6). 1799 | Furthermore, existing streams can be terminated by setting the 1800 | port to zero (Section 8). In general, a port number of zero 1801 | indicates that the media stream is not wanted. 1803 13.2. New Text Replacing RFC 3264, Section 5.1, 2nd Paragraph 1805 For recvonly and sendrecv streams, the port number and address in the 1806 offer indicate where the offerer would like to receive the media 1807 stream. For sendonly RTP streams, the address and port number 1808 indirectly indicate where the offerer wants to receive RTCP reports. 1809 Unless there is an explicit indication otherwise, reports are sent to 1810 the port number one higher than the number indicated. The IP address 1811 and port present in the offer indicate nothing about the source IP 1812 address and source port of the RTP and RTCP packets that will be sent 1813 by the offerer. By default, a port number of zero in the offer 1814 indicates that the stream is offered but MUST NOT be used, but an 1815 extension mechanism might specify different semantics for the usage 1816 of a zero port value. Furthermore, existing streams can be 1817 terminated by setting the port to zero (Section 8). In general, a 1818 port number of zero by default indicates that the media stream is not 1819 wanted. 1821 13.3. Original Text from RFC 3264, Section 8.4, 6th Paragraph 1823 | RFC 2543 [10] specified that placing a user on hold was 1824 | accomplished by setting the connection address to 0.0.0.0. Its 1825 | usage for putting a call on hold is no longer recommended, since 1826 | it doesn't allow for RTCP to be used with held streams, doesn't 1827 | work with IPv6, and breaks with connection oriented media. 1828 | However, it can be useful in an initial offer when the offerer 1829 | knows it wants to use a particular set of media streams and 1830 | formats, but doesn't know the addresses and ports at the time of 1831 | the offer. Of course, when used, the port number MUST NOT be 1832 | zero, which would specify that the stream has been disabled. An 1833 | agent MUST be capable of receiving SDP with a connection address 1834 | of 0.0.0.0, in which case it means that neither RTP nor RTCP 1835 | should be sent to the peer. 1837 RFC 8843 Bundled Media September 2021 1839 13.4. New Text Replacing RFC 3264, Section 8.4, 6th Paragraph 1841 RFC 2543 [RFC2543] specifies that placing a user on hold was 1842 accomplished by setting the connection address to 0.0.0.0. Its usage 1843 for putting a call on hold is no longer recommended, since it doesn't 1844 allow for RTCP to be used with held streams, doesn't work with IPv6, 1845 and breaks with connection oriented media. However, it can be useful 1846 in an initial offer when the offerer knows it wants to use a 1847 particular set of media streams and formats, but doesn't know the 1848 addresses and ports at the time of the offer. Of course, when used, 1849 the port number MUST NOT be zero, if it would specify that the stream 1850 has been disabled. However, an extension mechanism might specify 1851 different semantics of the zero port number usage. An agent MUST be 1852 capable of receiving SDP with a connection address of 0.0.0.0, in 1853 which case it means that neither RTP nor RTCP is to be sent to the 1854 peer. 1856 14. Update to RFC 5888 1858 This section updates RFC 5888 [RFC5888], in order for extensions to 1859 allow an SDP 'group' attribute containing an identification-tag that 1860 identifies an "m=" section with the port set to zero. "Group Value 1861 in Answers" (Section 9.2 of [RFC5888]) is updated. 1863 14.1. Original Text from RFC 5888, Section 9.2, 3rd Paragraph 1865 | SIP entities refuse media streams by setting the port to zero in 1866 | the corresponding "m" line. "a=group" lines MUST NOT contain 1867 | identification-tags that correspond to "m" lines with the port set 1868 | to zero. 1870 14.2. New Text Replacing RFC 5888, Section 9.2, 3rd Paragraph 1872 SIP entities refuse media streams by setting the port to zero in the 1873 corresponding "m" line. "a=group" lines MUST NOT contain 1874 identification-tags that correspond to "m" lines with the port set to 1875 zero, but an extension mechanism might specify different semantics 1876 for including identification-tags that correspond to such "m=" lines. 1878 15. RTP/RTCP Extensions for identification-tag Transport 1880 Offerers and answerers [RFC3264] can associate identification-tags 1881 with "m=" sections within offers and answers, using the procedures in 1882 [RFC5888]. Each identification-tag uniquely represents an "m=" 1883 section. 1885 RFC 8843 Bundled Media September 2021 1887 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1888 used to carry identification-tags within RTCP SDES packets. This 1889 section also defines a new RTP SDES header extension [RFC7941], which 1890 is used to carry the 'MID' RTCP SDES item in RTP packets. 1892 The SDES item and RTP SDES header extension make it possible for a 1893 receiver to associate each RTP stream with a specific "m=" section, 1894 with which the receiver has associated an identification-tag, even if 1895 those "m=" sections are part of the same RTP session. The RTP SDES 1896 header extension also ensures that the media recipient gets the 1897 identification-tag upon receipt of the first decodable media and is 1898 able to associate the media with the correct application. 1900 A media recipient informs the media sender about the identification- 1901 tag associated with an "m=" section through the use of a 'mid' 1902 attribute [RFC5888]. The media sender then inserts the 1903 identification-tag in RTCP and RTP packets sent to the media 1904 recipient. 1906 NOTE: The text above defines how identification-tags are carried in 1907 offers and answers. The usage of other signaling protocols for 1908 carrying identification-tags is not prevented, but the usage of such 1909 protocols is outside the scope of this document. 1911 [RFC3550] defines general procedures regarding the RTCP transmission 1912 interval. The RTCP MID SDES item SHOULD be sent in the first few 1913 RTCP packets after joining the session and SHOULD be sent regularly 1914 thereafter. The exact number of RTCP packets in which this SDES item 1915 is sent is intentionally not specified here, as it will depend on the 1916 expected packet-loss rate, the RTCP reporting interval, and the 1917 allowable overhead. 1919 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1920 be included in some RTP packets at the start of the session and 1921 whenever the SSRC changes. It might also be useful to include the 1922 header extension in RTP packets that comprise access points in the 1923 media (e.g., with video I-frames). The exact number of RTP packets 1924 in which this header extension is sent is intentionally not specified 1925 here, as it will depend on expected packet-loss rate and loss 1926 patterns, the overhead the application can tolerate, and the 1927 importance of immediate receipt of the identification-tag. 1929 For robustness, endpoints need to be prepared for situations where 1930 the reception of the identification-tag is delayed and SHOULD NOT 1931 terminate sessions in such cases, as the identification-tag is likely 1932 to arrive soon. 1934 RFC 8843 Bundled Media September 2021 1936 15.1. RTCP MID SDES Item 1938 0 1 2 3 1939 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 1940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1941 | MID=15 | length | identification-tag ... 1942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP. 1946 The identification-tag is not zero terminated. 1948 15.2. RTP SDES Header Extension For MID 1950 The payload, containing the identification-tag, of the RTP SDES 1951 header extension element can be encoded using either the 1-byte or 1952 the 2-byte header [RFC7941]. The identification-tag payload is UTF-8 1953 encoded, as in SDP. 1955 The identification-tag is not zero terminated. Note that the set of 1956 header extensions included in the packet needs to be padded to the 1957 next 32-bit boundary using zero bytes [RFC8285]. 1959 As the identification-tag is included in an RTCP SDES item, an RTP 1960 SDES header extension, or both, there needs to be some consideration 1961 about the packet expansion caused by the identification-tag. To 1962 avoid Maximum Transmission Unit (MTU) issues for the RTP packets, the 1963 header extension's size needs to be taken into account when encoding 1964 the media. 1966 It is recommended that the identification-tag be kept short. Due to 1967 the properties of the RTP header extension mechanism, when using the 1968 1-byte header, a tag that is 1-3 bytes will result in a minimal 1969 number of 32-bit words used for the RTP SDES header extension, in 1970 case no other header extensions are included at the same time. Note, 1971 do take into account that some single characters when UTF-8 encoded 1972 will result in multiple octets. The identification-tag MUST NOT 1973 contain any user information, and applications SHALL avoid generating 1974 the identification-tag using a pattern that enables user or 1975 application identification. 1977 16. IANA Considerations 1979 16.1. New SDES Item 1981 This document updates the MID SDES item to the IANA "RTP SDES Item 1982 Types" registry as follows: 1984 RFC 8843 Bundled Media September 2021 1986 Value: 15 1988 Abbrev.: MID 1990 Name: Media Identification 1992 Reference: RFC XXXX 1994 16.2. New RTP SDES Header Extension URI 1996 This document updates the extension URI in the RTP SDES Compact 1997 Header Extensions sub-registry of the RTP Compact Header Extensions 1998 registry sub-registry, according to the following data: 2000 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 2002 Description: Media identification 2004 Contact: IESG (iesg@ietf.org) 2006 Reference: RFC XXXX 2008 The SDES item does not reveal privacy information about the users. 2009 It is simply used to associate RTP-based media with the correct SDP 2010 media description ("m=" section) in the SDP used to negotiate the 2011 media. 2013 The purpose of the extension is for the offerer to be able to 2014 associate received multiplexed RTP-based media before the offerer 2015 receives the associated answer. 2017 16.3. New SDP Attribute 2019 This document updates the SDP media-level attribute, 'bundle-only', 2020 according to the following data: 2022 Attribute name: bundle-only 2024 Type of attribute: media 2026 Subject to charset: No 2028 Purpose: Request a media description to be accepted in the answer 2029 only if kept within a BUNDLE group by the answerer. 2031 Appropriate values: N/A 2033 Contact name: IESG 2035 RFC 8843 Bundled Media September 2021 2037 Contact e-mail: iesg@ietf.org 2039 Reference: RFC XXXX 2041 Mux category: NORMAL 2043 16.4. New SDP Group Semantics 2045 This document updates the following semantics in the "Semantics for 2046 the 'group' SDP Attribute" subregistry (under the "Session 2047 Description Protocol (SDP) Parameters" registry): 2049 +================+========+==============+===========+ 2050 | Semantics | Token | Mux Category | Reference | 2051 +================+========+==============+===========+ 2052 | Media bundling | BUNDLE | NORMAL | RFC XXXX | 2053 +----------------+--------+--------------+-----------+ 2055 Table 1 2057 17. Security Considerations 2059 The security considerations defined in [RFC3264] and [RFC5888] apply 2060 to the BUNDLE extension. BUNDLE does not change which information, 2061 e.g., RTP streams, flows over the network, except for the usage of 2062 the MID SDES item as discussed below. Primarily, it changes which 2063 addresses and ports, and thus in which (RTP) sessions, the 2064 information flows to. This affects the security contexts being used 2065 and can cause previously separated information flows to share the 2066 same security context. This has very little impact on the 2067 performance of the security mechanism of the RTP sessions. In cases 2068 where one would have applied different security policies on the 2069 different RTP streams being bundled, or where the parties having 2070 access to the security contexts would have differed between the RTP 2071 streams, additional analysis of the implications are needed before 2072 selecting to apply BUNDLE. 2074 The identification-tag, independent of transport, RTCP SDES packet, 2075 or RTP header extension, can expose the value to parties beyond the 2076 signaling chain. Therefore, the identification-tag values MUST be 2077 generated in a fashion that does not leak user information, e.g., 2078 randomly or using a per-bundle group counter, and SHOULD be 3 bytes 2079 or fewer to allow them to efficiently fit into the MID RTP header 2080 extension. Note that if implementations use different methods for 2081 generating identification-tags, this could enable fingerprinting of 2082 the implementation making it vulnerable to targeted attacks. The 2083 identification-tag is exposed on the RTP stream level when included 2084 in the RTP header extensions; however, what it reveals of the RTP 2086 RFC 8843 Bundled Media September 2021 2088 media stream structure of the endpoint and application was already 2089 possible to deduce from the RTP streams without the MID SDES header 2090 extensions. As the identification-tag is also used to route the 2091 media stream to the right application functionality, it is important 2092 that the value received is the one intended by the sender; thus, 2093 integrity and the authenticity of the source are important to prevent 2094 denial of service on the application. Existing SRTP configurations 2095 and other security mechanisms protecting the whole RTP/RTCP packets 2096 will provide the necessary protection. 2098 When the BUNDLE extension is used, the set of configurations of the 2099 security mechanism used in all the bundled media descriptions will 2100 need to be compatible so that they can be used simultaneously, at 2101 least per direction or endpoint. When using SRTP, this will be the 2102 case, at least for the IETF-defined key-management solutions due to 2103 their SDP attributes ("a=crypto", "a=fingerprint", "a=mikey") and 2104 their classification in [RFC8859]. 2106 The security considerations of "RTP Header Extension for the RTP 2107 Control Protocol (RTCP) Source Description Items" [RFC7941] require 2108 that when RTCP is confidentiality protected, any SDES RTP header 2109 extension carrying an SDES item, such as the MID RTP header 2110 extension, is also protected using commensurate strength algorithms. 2111 However, assuming the above requirements and recommendations are 2112 followed, there are no known significant security risks with leaving 2113 the MID RTP header extension without confidentiality protection. 2114 Therefore, this specification updates RFC 7941 by adding the 2115 exception that this requirement MAY be ignored for the MID RTP header 2116 extension. Security mechanisms for RTP/RTCP are discussed in 2117 "Options for Securing RTP Sessions" [RFC7201], for example, SRTP 2118 [RFC3711] can provide the necessary security functions of ensuring 2119 the integrity and source authenticity. 2121 18. Examples 2123 18.1. Example: Tagged "m=" Section Selections 2125 The example below shows: 2127 * An initial BUNDLE offer, in which the offerer wants to negotiate a 2128 BUNDLE group and indicates the audio "m=" section as the suggested 2129 offerer-tagged "m=" section. 2131 * An initial BUNDLE answer, in which the answerer accepts the 2132 creation of the BUNDLE group, selects the audio "m=" section in 2133 the offer as the offerer-tagged "m=" section, selects the audio 2134 "m=" section in the answer as the answerer-tagged "m=" section, 2135 and assigns the answerer BUNDLE address:port to that "m=" section. 2137 RFC 8843 Bundled Media September 2021 2139 SDP Offer (1) 2141 v=0 2142 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2143 s= 2144 c=IN IP6 2001:db8::3 2145 t=0 0 2146 a=group:BUNDLE foo bar 2148 m=audio 10000 RTP/AVP 0 8 97 2149 b=AS:200 2150 a=mid:foo 2151 a=rtcp-mux 2152 a=rtpmap:0 PCMU/8000 2153 a=rtpmap:8 PCMA/8000 2154 a=rtpmap:97 iLBC/8000 2155 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2157 m=video 10002 RTP/AVP 31 32 2158 b=AS:1000 2159 a=mid:bar 2160 a=rtcp-mux 2161 a=rtpmap:31 H261/90000 2162 a=rtpmap:32 MPV/90000 2163 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2165 SDP Answer (2) 2167 v=0 2168 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2169 s= 2170 c=IN IP6 2001:db8::1 2171 t=0 0 2172 a=group:BUNDLE foo bar 2174 m=audio 20000 RTP/AVP 0 2175 b=AS:200 2176 a=mid:foo 2177 a=rtcp-mux 2178 a=rtpmap:0 PCMU/8000 2179 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2181 m=video 20000 RTP/AVP 32 2182 b=AS:1000 2183 a=mid:bar 2184 a=rtpmap:32 MPV/90000 2185 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2187 RFC 8843 Bundled Media September 2021 2189 18.2. Example: BUNDLE Group Rejected 2191 The example below shows: 2193 * An initial BUNDLE offer, in which the offerer wants to negotiate a 2194 BUNDLE group and indicates the audio "m=" section as the suggested 2195 offerer-tagged "m=" section. 2197 * An initial BUNDLE answer, in which the answerer rejects the 2198 creation of the BUNDLE group, generates a normal answer, and 2199 assigns a unique address:port to each "m=" section in the answer. 2201 SDP Offer (1) 2203 v=0 2204 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2205 s= 2206 c=IN IP6 2001:db8::3 2207 t=0 0 2208 a=group:BUNDLE foo bar 2210 m=audio 10000 RTP/AVP 0 8 97 2211 b=AS:200 2212 a=mid:foo 2213 a=rtcp-mux 2214 a=rtpmap:0 PCMU/8000 2215 a=rtpmap:8 PCMA/8000 2216 a=rtpmap:97 iLBC/8000 2217 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2219 m=video 10002 RTP/AVP 31 32 2220 b=AS:1000 2221 a=mid:bar 2222 a=rtcp-mux 2223 a=rtpmap:31 H261/90000 2224 a=rtpmap:32 MPV/90000 2225 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2227 SDP Answer (2) 2229 RFC 8843 Bundled Media September 2021 2231 v=0 2232 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2233 s= 2234 c=IN IP6 2001:db8::1 2235 t=0 0 2237 m=audio 20000 RTP/AVP 0 2238 b=AS:200 2239 a=rtcp-mux 2240 a=rtpmap:0 PCMU/8000 2242 m=video 30000 RTP/AVP 32 2243 b=AS:1000 2244 a=rtcp-mux 2245 a=rtpmap:32 MPV/90000 2247 18.3. Example: Offerer Adds a Media Description to a BUNDLE Group 2249 The example below shows: 2251 * A subsequent offer, in which the offerer adds a new bundled "m=" 2252 section (video), indicated by the "zen" identification-tag, to a 2253 previously negotiated BUNDLE group; indicates the new "m=" section 2254 as the offerer-tagged "m=" section; and assigns the offerer BUNDLE 2255 address:port to that "m=" section. 2257 * A subsequent answer, in which the answerer indicates the new video 2258 "m=" section in the answer as the answerer-tagged "m=" section and 2259 assigns the answerer BUNDLE address:port to that "m=" section. 2261 SDP Offer (1) 2263 RFC 8843 Bundled Media September 2021 2265 v=0 2266 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2267 s= 2268 c=IN IP6 2001:db8::3 2269 t=0 0 2270 a=group:BUNDLE zen foo bar 2272 m=audio 10000 RTP/AVP 0 8 97 2273 b=AS:200 2274 a=mid:foo 2275 a=rtpmap:0 PCMU/8000 2276 a=rtpmap:8 PCMA/8000 2277 a=rtpmap:97 iLBC/8000 2278 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2280 m=video 10000 RTP/AVP 31 32 2281 b=AS:1000 2282 a=mid:bar 2283 a=rtpmap:31 H261/90000 2284 a=rtpmap:32 MPV/90000 2285 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2287 m=video 10000 RTP/AVP 66 2288 b=AS:1000 2289 a=mid:zen 2290 a=rtcp-mux 2291 a=rtpmap:66 H261/90000 2292 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2294 SDP Answer (2) 2296 RFC 8843 Bundled Media September 2021 2298 v=0 2299 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2300 s= 2301 c=IN IP6 2001:db8::1 2302 t=0 0 2303 a=group:BUNDLE zen foo bar 2305 m=audio 20000 RTP/AVP 0 2306 b=AS:200 2307 a=mid:foo 2308 a=rtpmap:0 PCMU/8000 2309 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2311 m=video 20000 RTP/AVP 32 2312 b=AS:1000 2313 a=mid:bar 2314 a=rtpmap:32 MPV/90000 2315 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2317 m=video 20000 RTP/AVP 66 2318 b=AS:1000 2319 a=mid:zen 2320 a=rtcp-mux 2321 a=rtpmap:66 H261/90000 2322 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2324 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 2326 The example below shows: 2328 * A subsequent offer, in which the offerer removes an "m=" section 2329 (video), indicated by the "zen" identification-tag, from a 2330 previously negotiated BUNDLE group; indicates one of the bundled 2331 "m=" sections (audio) remaining in the BUNDLE group as the 2332 offerer-tagged "m=" section; and assigns the offerer BUNDLE 2333 address:port to that "m=" section. 2335 * A subsequent answer, in which the answerer removes the "m=" 2336 section from the BUNDLE group, indicates the audio "m=" section in 2337 the answer as the answerer-tagged "m=" section, and assigns the 2338 answerer BUNDLE address:port to that "m=" section. 2340 SDP Offer (1) 2342 RFC 8843 Bundled Media September 2021 2344 v=0 2345 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2346 s= 2347 c=IN IP6 2001:db8::3 2348 t=0 0 2349 a=group:BUNDLE foo bar 2351 m=audio 10000 RTP/AVP 0 8 97 2352 b=AS:200 2353 a=mid:foo 2354 a=rtcp-mux 2355 a=rtpmap:0 PCMU/8000 2356 a=rtpmap:8 PCMA/8000 2357 a=rtpmap:97 iLBC/8000 2358 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2360 m=video 10000 RTP/AVP 31 32 2361 b=AS:1000 2362 a=mid:bar 2363 a=rtpmap:31 H261/90000 2364 a=rtpmap:32 MPV/90000 2365 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2367 m=video 50000 RTP/AVP 66 2368 b=AS:1000 2369 a=mid:zen 2370 a=rtcp-mux 2371 a=rtpmap:66 H261/90000 2373 SDP Answer (2) 2375 RFC 8843 Bundled Media September 2021 2377 v=0 2378 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2379 s= 2380 c=IN IP6 2001:db8::1 2381 t=0 0 2382 a=group:BUNDLE foo bar 2384 m=audio 20000 RTP/AVP 0 2385 b=AS:200 2386 a=mid:foo 2387 a=rtcp-mux 2388 a=rtpmap:0 PCMU/8000 2389 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2391 m=video 20000 RTP/AVP 32 2392 b=AS:1000 2393 a=mid:bar 2394 a=rtpmap:32 MPV/90000 2395 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2397 m=video 60000 RTP/AVP 66 2398 b=AS:1000 2399 a=mid:zen 2400 a=rtcp-mux 2401 a=rtpmap:66 H261/90000 2403 18.5. Example: Offerer Disables a Media Description within a BUNDLE 2404 Group 2406 The example below shows: 2408 * A subsequent offer, in which the offerer disables (by assigning a 2409 zero port value) an "m=" section (video), indicated by the "zen" 2410 identification-tag, from a previously negotiated BUNDLE group; 2411 indicates one of the bundled "m=" sections (audio) remaining 2412 active in the BUNDLE group as the offerer-tagged "m=" section; and 2413 assigns the offerer BUNDLE address:port to that "m=" section. 2415 * A subsequent answer, in which the answerer disables the "m=" 2416 section, indicates the audio "m=" section in the answer as the 2417 answerer-tagged "m=" section, and assigns the answerer BUNDLE 2418 address:port to that "m=" section. 2420 SDP Offer (1) 2422 RFC 8843 Bundled Media September 2021 2424 v=0 2425 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2426 s= 2427 t=0 0 2428 a=group:BUNDLE foo bar 2430 m=audio 10000 RTP/AVP 0 8 97 2431 c=IN IP6 2001:db8::3 2432 b=AS:200 2433 a=mid:foo 2434 a=rtcp-mux 2435 a=rtpmap:0 PCMU/8000 2436 a=rtpmap:8 PCMA/8000 2437 a=rtpmap:97 iLBC/8000 2438 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2440 m=video 10000 RTP/AVP 31 32 2441 c=IN IP6 2001:db8::3 2442 b=AS:1000 2443 a=mid:bar 2444 a=rtpmap:31 H261/90000 2445 a=rtpmap:32 MPV/90000 2446 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2448 m=video 0 RTP/AVP 66 2449 a=mid:zen 2450 a=rtpmap:66 H261/90000 2452 SDP Answer (2) 2454 RFC 8843 Bundled Media September 2021 2456 v=0 2457 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2458 s= 2459 t=0 0 2460 a=group:BUNDLE foo bar 2462 m=audio 20000 RTP/AVP 0 2463 c=IN IP6 2001:db8::1 2464 b=AS:200 2465 a=mid:foo 2466 a=rtcp-mux 2467 a=rtpmap:0 PCMU/8000 2468 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2470 m=video 20000 RTP/AVP 32 2471 c=IN IP6 2001:db8::1 2472 b=AS:1000 2473 a=mid:bar 2474 a=rtpmap:32 MPV/90000 2475 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2477 m=video 0 RTP/AVP 66 2478 a=mid:zen 2479 a=rtpmap:66 H261/90000 2481 19. References 2483 19.1. Normative References 2485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2486 Requirement Levels", BCP 14, RFC 2119, 2487 DOI 10.17487/RFC2119, March 1997, 2488 . 2490 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2491 with Session Description Protocol (SDP)", RFC 3264, 2492 DOI 10.17487/RFC3264, June 2002, 2493 . 2495 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2496 Jacobson, "RTP: A Transport Protocol for Real-Time 2497 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2498 July 2003, . 2500 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2501 in Session Description Protocol (SDP)", RFC 3605, 2502 DOI 10.17487/RFC3605, October 2003, 2503 . 2505 RFC 8843 Bundled Media September 2021 2507 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2508 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2509 2003, . 2511 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2512 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2513 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2514 . 2516 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2517 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2518 July 2006, . 2520 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2521 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2522 . 2524 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2525 Control Packets on a Single Port", RFC 5761, 2526 DOI 10.17487/RFC5761, April 2010, 2527 . 2529 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2530 Security (DTLS) Extension to Establish Keys for the Secure 2531 Real-time Transport Protocol (SRTP)", RFC 5764, 2532 DOI 10.17487/RFC5764, May 2010, 2533 . 2535 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2536 Protocol (SDP) Grouping Framework", RFC 5888, 2537 DOI 10.17487/RFC5888, June 2010, 2538 . 2540 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2541 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2542 January 2012, . 2544 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2545 Header Extension for the RTP Control Protocol (RTCP) 2546 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2547 August 2016, . 2549 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2550 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2551 May 2017, . 2553 RFC 8843 Bundled Media September 2021 2555 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 2556 Mechanism for RTP Header Extensions", RFC 8285, 2557 DOI 10.17487/RFC8285, October 2017, 2558 . 2560 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2561 Connectivity Establishment (ICE): A Protocol for Network 2562 Address Translator (NAT) Traversal", RFC 8445, 2563 DOI 10.17487/RFC8445, July 2018, 2564 . 2566 [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keranen, 2567 A., and R. Shpount, "Session Description Protocol (SDP) 2568 Offer/Answer Procedures for Interactive Connectivity 2569 Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, 2570 January 2021, . 2572 [RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 2573 Session Initiation Protocol (SIP) Usage for Incremental 2574 Provisioning of Candidates for the Interactive 2575 Connectivity Establishment (Trickle ICE)", RFC 8840, 2576 DOI 10.17487/RFC8840, January 2021, 2577 . 2579 [RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP 2580 Control Protocol (RTCP) Multiplexing Using the Session 2581 Description Protocol (SDP)", RFC 8858, 2582 DOI 10.17487/RFC8858, January 2021, 2583 . 2585 [RFC8859] Nandakumar, S., "A Framework for Session Description 2586 Protocol (SDP) Attributes When Multiplexing", RFC 8859, 2587 DOI 10.17487/RFC8859, January 2021, 2588 . 2590 19.2. Informative References 2592 [LLR-RTCP] Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 2593 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 2594 Message", Work in Progress, Internet-Draft, draft-ietf- 2595 avtext-lrr-07, 2 July 2017, 2596 . 2599 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 2600 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 2601 DOI 10.17487/RFC2543, March 1999, 2602 . 2604 RFC 8843 Bundled Media September 2021 2606 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2607 A., Peterson, J., Sparks, R., Handley, M., and E. 2608 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2609 DOI 10.17487/RFC3261, June 2002, 2610 . 2612 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2613 "RTP Control Protocol Extended Reports (RTCP XR)", 2614 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2615 . 2617 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2618 "Extended RTP Profile for Real-time Transport Control 2619 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2620 DOI 10.17487/RFC4585, July 2006, 2621 . 2623 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2624 "Codec Control Messages in the RTP Audio-Visual Profile 2625 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 2626 February 2008, . 2628 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2629 Media Attributes in the Session Description Protocol 2630 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2631 . 2633 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2634 Clock Rates in an RTP Session", RFC 7160, 2635 DOI 10.17487/RFC7160, April 2014, 2636 . 2638 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2639 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2640 . 2642 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2643 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2644 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2645 DOI 10.17487/RFC7656, November 2015, 2646 . 2648 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 2649 (Diffserv) and Real-Time Communication", RFC 7657, 2650 DOI 10.17487/RFC7657, November 2015, 2651 . 2653 RFC 8843 Bundled Media September 2021 2655 [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., 2656 "JavaScript Session Establishment Protocol (JSEP)", 2657 RFC 8829, DOI 10.17487/RFC8829, January 2021, 2658 . 2660 [RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: 2661 Incremental Provisioning of Candidates for the Interactive 2662 Connectivity Establishment (ICE) Protocol", RFC 8838, 2663 DOI 10.17487/RFC8838, January 2021, 2664 . 2666 Appendix A. Design Considerations 2668 One of the main issues regarding the BUNDLE grouping extensions has 2669 been whether, in offers and answers, the same port value can be 2670 inserted in "m=" lines associated with a BUNDLE group, as the purpose 2671 of the extension is to negotiate the usage of a single transport for 2672 media specified by the "m=" sections. Issues with both approaches, 2673 discussed in the Appendix, have been raised. The outcome was to 2674 specify a mechanism that uses offers with both different and 2675 identical port values. 2677 Below are the primary issues that have been considered when defining 2678 the "BUNDLE" grouping extension: 2680 1) Interoperability with existing User Agents (UAs). 2682 2) Interoperability with intermediary Back-to-Back User Agent 2683 (B2BUA) and proxy entities. 2685 3) Time to gather, and the number of, ICE candidates. 2687 4) Different error scenarios and when they occur. 2689 5) SDP offer/answer impacts, including usage of port number value 2690 zero. 2692 A.1. UA Interoperability 2694 Consider the following SDP offer/answer exchange, where Alice sends 2695 an offer to Bob: 2697 SDP Offer 2699 RFC 8843 Bundled Media September 2021 2701 v=0 2702 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2703 s= 2704 c=IN IP4 atlanta.example.com 2705 t=0 0 2707 m=audio 10000 RTP/AVP 97 2708 a=rtpmap:97 iLBC/8000 2709 m=video 10002 RTP/AVP 97 2710 a=rtpmap:97 H261/90000 2712 SDP Answer 2714 v=0 2715 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2716 s= 2717 c=IN IP4 biloxi.example.com 2718 t=0 0 2720 m=audio 20000 RTP/AVP 97 2721 a=rtpmap:97 iLBC/8000 2722 m=video 20002 RTP/AVP 97 2723 a=rtpmap:97 H261/90000 2725 RFC 4961 specifies a way of doing symmetric RTP, but that is a later 2726 extension to RTP, and Bob cannot assume that Alice supports RFC 4961. 2727 This means that Alice may be sending RTP from a different port than 2728 10000 or 10002 -- some implementations simply send the RTP from an 2729 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2730 way that Bob knows if the packet is to be passed to the video or 2731 audio codec is by looking at the port it was received on. This 2732 prompted some SDP implementations to use a port number as an index to 2733 find the correct "m=" line in the SDP, since each "m"= section 2734 contains a different port number. As a result, some implementations 2735 that do support symmetric RTP and ICE still use an SDP data structure 2736 where SDP with "m=" sections with the same port such as: 2738 SDP Offer 2740 RFC 8843 Bundled Media September 2021 2742 v=0 2743 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2744 s= 2745 c=IN IP4 atlanta.example.com 2746 t=0 0 2748 m=audio 10000 RTP/AVP 97 2749 a=rtpmap:97 iLBC/8000 2750 m=video 10000 RTP/AVP 98 2751 a=rtpmap:98 H261/90000 2753 will result in the second "m=" section being considered an SDP error 2754 because it has the same port as the first line. 2756 A.2. Usage of Port Number Value Zero 2758 In an offer or answer, the media specified by an "m=" section can be 2759 disabled/rejected by setting the port number value to zero. This is 2760 different from, e.g., using the SDP direction attributes, where RTCP 2761 traffic will continue even if the SDP 'inactive' attribute is 2762 indicated for the associated "m=" section. 2764 If each "m=" section associated with a BUNDLE group would contain 2765 different port values, and one of those port values would be used for 2766 a BUNDLE address:port associated with the BUNDLE group, problems 2767 would occur if an endpoint wants to disable/reject the "m=" section 2768 associated with that port, by setting the port value to zero. After 2769 that, no "m=" section would contain the port value that is used for 2770 the BUNDLE address:port. In addition, it is unclear what would 2771 happen to the ICE candidates associated with the "m=" section, as 2772 they are also used for the BUNDLE address:port. 2774 A.3. B2BUA and Proxy Interoperability 2776 Some back-to-back user agents may be configured in a mode where if 2777 the incoming call leg contains an SDP attribute the B2BUA does not 2778 understand, the B2BUA still generates that SDP attribute in the Offer 2779 for the outgoing call leg. Consider a B2BUA that did not understand 2780 the SDP 'rtcp' attribute, defined in RFC 3605, yet acted this way. 2781 Further, assume that the B2BUA was configured to tear down any call 2782 where it did not see any RTCP for 5 minutes. In this case, if the 2783 B2BUA received an Offer like: 2785 SDP Offer 2787 RFC 8843 Bundled Media September 2021 2789 v=0 2790 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2791 s= 2792 c=IN IP4 atlanta.example.com 2793 t=0 0 2795 m=audio 49170 RTP/AVP 0 2796 a=rtcp:53020 2798 It would be looking for RTCP on port 49171 but would not see any 2799 because the RTCP would be on port 53020, and after five minutes, it 2800 would tear down the call. Similarly, a B2BUA that did not understand 2801 BUNDLE yet put it in its offer may be looking for media on the wrong 2802 port and tear down the call. It is worth noting that a B2BUA that 2803 generated an Offer with capabilities it does not understand is not 2804 compliant with the specifications. 2806 A.3.1. Traffic Policing 2808 Sometimes intermediaries do not act as B2BUAs, in the sense that they 2809 don't modify SDP bodies nor do they terminate SIP dialogs. However, 2810 they may still use SDP information (e.g., IP address and port) in 2811 order to control traffic gating functions and to set traffic policing 2812 rules. There might be rules that will trigger a session to be 2813 terminated in case media is not sent or received on the ports 2814 retrieved from the SDP. This typically occurs once the session is 2815 already established and ongoing. 2817 A.3.2. Bandwidth Allocation 2819 Sometimes, intermediaries do not act as B2BUAs, in the sense that 2820 they don't modify SDP bodies nor do they terminate SIP dialogs. 2821 However, they may still use SDP information (e.g., codecs and media 2822 types) in order to control bandwidth allocation functions. The 2823 bandwidth allocation is done per "m=" section, which means that it 2824 might not be enough if media specified by all "m=" sections try to 2825 use that bandwidth. That may simply lead to either bad user 2826 experience or termination of the call. 2828 A.4. Candidate Gathering 2830 When using ICE, a candidate needs to be gathered for each port. This 2831 takes approximately 20 ms extra for each extra "m=" section due to 2832 the NAT pacing requirements. All of this gathering can be overlapped 2833 with other things while, e.g., a web page is loading to minimize the 2834 impact. If the client only wants to generate Traversal Using Relays 2835 around NAT (TURN) or STUN ICE candidates for one of the "m=" lines 2836 and then use Trickle ICE [RFC8838] to get the non-host ICE candidates 2838 RFC 8843 Bundled Media September 2021 2840 for the rest of the "m=" sections, it MAY do that and will not need 2841 any additional gathering time. 2843 Some people have suggested a TURN extension to get a bunch of TURN 2844 allocations at once. This would only provide a single STUN result, 2845 so in cases where the other end did not support BUNDLE, it may cause 2846 more use of the TURN server, but it would be quick in the cases where 2847 both sides supported BUNDLE and would fall back to a successful call 2848 in the other cases. 2850 Acknowledgements 2852 The usage of the SDP grouping extension for negotiating bundled media 2853 is based on similar alternatives proposed by Harald Alvestrand and 2854 Cullen Jennings. The BUNDLE extension described in this document is 2855 based on the different alternative proposals, and text (e.g., SDP 2856 examples) has been borrowed (and, in some cases, modified) from those 2857 alternative proposals. 2859 The SDP examples are also modified versions from the ones in the 2860 Alvestrand proposal. 2862 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 2863 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 2864 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin 2865 Uberti, Taylor Brandstetter, Byron Campen, and Eric Rescorla for 2866 reading the text and providing useful feedback. 2868 Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus 2869 Westerlund for providing the text for the section on RTP/RTCP stream 2870 association. 2872 Thanks to Magnus Westerlund, Colin Perkins, and Jonathan Lennox for 2873 providing help and text on the RTP/RTCP procedures. 2875 Thanks to Charlie Kaufman for performing the Sec-Dir review. 2877 Thanks to Linda Dunbar for performing the Gen-ART review. 2879 Thanks to Spotify for providing music for the countless hours of 2880 document editing. 2882 Authors' Addresses 2883 RFC 8843 Bundled Media September 2021 2885 Christer Holmberg 2886 Ericsson 2887 Hirsalantie 11 2888 FI-02420 Jorvas 2889 Finland 2891 Email: christer.holmberg@ericsson.com 2893 Harald Tveit Alvestrand 2894 Google 2895 Kungsbron 2 2896 SE-11122 Stockholm 2897 Sweden 2899 Email: harald@alvestrand.no 2901 Cullen Jennings 2902 Cisco 2903 400 3rd Avenue SW, Suite 350 2904 Calgary AB T2P 4H2 2905 Canada 2907 Email: fluffy@iii.ca