idnits 2.17.1 draft-ietf-mmusic-rfc8843bis-06.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 (17 November 2021) is 892 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 1843 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 8829 (Obsoleted by RFC 9429) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Obsoletes: 8843 (if approved) H. Alvestrand 5 Updates: 3264, 5888, 7941 (if approved) Google 6 Intended status: Standards Track C. Jennings 7 Expires: 21 May 2022 Cisco 8 17 November 2021 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-rfc8843bis-06 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 21 May 2022. 49 RFC 8843 Bundled Media November 2021 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Revised BSD License text as 62 described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Revised BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 81 1.2. BUNDLE Mechanism . . . . . . . . . . . . . . . . . . . . 4 82 1.3. Protocol Extensions . . . . . . . . . . . . . . . . . . . 5 83 1.4. Changes from RFC 8843 . . . . . . . . . . . . . . . . . . 6 84 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 87 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 8 88 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 9 89 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 90 7.1. Generic SDP Considerations . . . . . . . . . . . . . . . 11 91 7.1.1. Connection Data ("c=") . . . . . . . . . . . . . . . 11 92 7.1.2. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . 11 93 7.1.3. Attributes ("a=") . . . . . . . . . . . . . . . . . . 11 94 7.2. Generating the Initial BUNDLE Offer . . . . . . . . . . . 12 95 7.2.1. Suggesting the Offerer-Tagged 'm=' Section . . . . . 13 96 7.2.2. Example: Initial BUNDLE Offer . . . . . . . . . . . . 14 97 7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 15 98 7.3.1. Answerer Selection of Tagged 'm=' Sections . . . . . 17 100 RFC 8843 Bundled Media November 2021 102 7.3.2. Moving a Media Description Out of a BUNDLE Group . . 17 103 7.3.3. Rejecting a Media Description in a BUNDLE Group . . . 18 104 7.3.4. Example: SDP Answer . . . . . . . . . . . . . . . . . 19 105 7.3.5. RFC 8843 Considerations . . . . . . . . . . . . . . . 20 106 7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 20 107 7.4.1. RFC 8843 Considerations . . . . . . . . . . . . . . . 21 108 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 22 109 7.5.1. Adding a Media Description to a BUNDLE Group . . . . 22 110 7.5.2. Moving a Media Description Out of a BUNDLE Group . . 23 111 7.5.3. Disabling a Media Description in a BUNDLE Group . . . 23 112 7.6. 3PCC Considerations . . . . . . . . . . . . . . . . . . . 24 113 8. Protocol Identification . . . . . . . . . . . . . . . . . . . 24 114 8.1. STUN, DTLS, and SRTP . . . . . . . . . . . . . . . . . . 25 115 9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 25 116 9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 25 117 9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 26 118 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 119 Description . . . . . . . . . . . . . . . . . . . . . . . 27 120 9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 33 121 9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 33 122 10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 35 123 11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 36 124 12. RTP Header Extensions Consideration . . . . . . . . . . . . . 37 125 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 37 126 13.1. Original Text from RFC 3264, Section 5.1, 2nd 127 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 37 128 13.2. New Text Replacing RFC 3264, Section 5.1, 2nd 129 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38 130 13.3. Original Text from RFC 3264, Section 8.4, 6th 131 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38 132 13.4. New Text Replacing RFC 3264, Section 8.4, 6th 133 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38 134 14. Update to RFC 5888 . . . . . . . . . . . . . . . . . . . . . 39 135 14.1. Original Text from RFC 5888, Section 9.2, 3rd 136 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 39 137 14.2. New Text Replacing RFC 5888, Section 9.2, 3rd 138 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 39 139 15. RTP/RTCP Extensions for identification-tag Transport . . . . 39 140 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 40 141 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 41 142 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 143 16.1. New SDES Item . . . . . . . . . . . . . . . . . . . . . 41 144 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 42 145 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 42 146 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 43 147 17. Security Considerations . . . . . . . . . . . . . . . . . . . 43 148 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 44 149 18.1. Example: Tagged "m=" Section Selections . . . . . . . . 44 151 RFC 8843 Bundled Media November 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 November 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 November 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 November 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 November 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 November 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 November 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 November 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 November 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 November 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 November 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 November 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 November 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 November 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 November 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 November 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 November 2021 933 7.3.5. RFC 8843 Considerations 935 In RFC 8843, instead of assigning the offerer BUNDLE address:port to 936 each "m=" section within the BUNDLE group when modifying the session 937 (Section 7.5), the offerer only assigned the offerer BUNDLE 938 address:port to the offerer-tagged "m=" section. For every other 939 "m=" section within the BUNDLE group, the offerer included an SDP 940 'bundle-only' attribute in, and assigned a zero port value to, the 941 "m=" section. The way an answerer compliant to this specification 942 processes such offer is considered an implementation issue (e.g., 943 based on whether the answerer needs to be backward compatible with 944 RFC 8843 compliant offerers), and is outside the scope of this 945 specification. The example below shows such SDP Offer: 947 SDP Offer 949 v=0 950 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 951 s= 952 c=IN IP6 2001:db8::3 953 t=0 0 954 a=group:BUNDLE foo bar 956 m=audio 10000 RTP/AVP 0 8 97 957 b=AS:200 958 a=mid:foo 959 a=rtcp-mux 960 a=rtpmap:0 PCMU/8000 961 a=rtpmap:8 PCMA/8000 962 a=rtpmap:97 iLBC/8000 963 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 965 m=video 0 RTP/AVP 31 32 966 b=AS:1000 967 a=mid:bar 968 a=bundle-only 969 a=rtpmap:31 H261/90000 970 a=rtpmap:32 MPV/90000 971 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 973 7.4. Offerer Processing of the SDP Answer 975 When an offerer receives an answer, if the answer contains a BUNDLE 976 group, the offerer MUST check that any bundled "m=" section in the 977 answer was indicated as bundled in the corresponding offer (for the 978 same BUNDLE group). If there is no mismatch, the offerer MUST apply 979 the properties (BUNDLE address:port, BUNDLE attributes, etc.) of the 980 offerer-tagged "m=" section (selected by the answerer; see 982 RFC 8843 Bundled Media November 2021 984 Section 7.3.1) to each bundled "m=" section within the BUNDLE group. 986 NOTE: As the answerer might reject one or more bundled "m=" sections 987 in an initial BUNDLE Offer, or move a bundled "m=" section out of a 988 BUNDLE group, a given bundled "m=" section in the offer might not be 989 indicated as bundled in the corresponding answer. 991 If the answer does not contain a BUNDLE group, the offerer MUST 992 process the answer as a normal answer. 994 7.4.1. RFC 8843 Considerations 996 In RFC 8843, instead of assigning the answerer BUNDLE address:port to 997 each "m=" section within the BUNDLE group when generating the SDP 998 Answer (Section 7.3), the answerer only assigned the answerer BUNDLE 999 address:port to the answerer-tagged "m=" section. For every other 1000 "m=" section within the BUNDLE group, the answerer included an SDP 1001 'bundle-only' attribute in, and assigned a zero port value to, the 1002 "m=" section. The way an offerer compliant to this specification 1003 processes such SDP Answer is considered an implementation issue 1004 (e.g., based on whether the answerer needs to be backward compatible 1005 with RFC 8843 compliant offerers), and is outside the scope of this 1006 specification. The example below shows such SDP Answer: 1008 SDP Answer 1010 v=0 1011 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1012 s= 1013 c=IN IP6 2001:db8::1 1014 t=0 0 1015 a=group:BUNDLE foo bar 1017 m=audio 20000 RTP/AVP 0 1018 b=AS:200 1019 a=mid:foo 1020 a=rtcp-mux 1021 a=rtpmap:0 PCMU/8000 1022 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1024 m=video 0 RTP/AVP 32 1025 b=AS:1000 1026 a=mid:bar 1027 a=bundle-only 1028 a=rtpmap:32 MPV/90000 1029 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1031 RFC 8843 Bundled Media November 2021 1033 7.5. Modifying the Session 1035 When a BUNDLE group has been previously negotiated, and an offerer 1036 generates a subsequent offer, the offerer MUST: 1038 * Pick one bundled "m=" section as the offerer-tagged "m=" section. 1039 The offerer can pick either the "m=" section that was previously 1040 selected by the answerer as the offerer-tagged "m=" section or 1041 another bundled "m=" section within the BUNDLE group; 1043 * Assign a BUNDLE address:port (previously negotiated or newly 1044 suggested) to the offerer-tagged "m=" section, and to every other 1045 bundled "m=" section within the BUNDLE group; 1047 * Include SDP attributes in the bundled "m=" sections following the 1048 rules in Section 7.1.3; 1050 * Include an SDP 'group:BUNDLE' attribute in the offer; and 1052 * Place the identification-tag of each bundled "m=" section in the 1053 SDP 'group:BUNDLE' attribute identification-tag list. The offerer 1054 BUNDLE-tag indicates the offerer-tagged "m=" section. 1056 The offerer MUST NOT pick a given bundled "m=" section as the 1057 offerer-tagged "m=" section if: 1059 * The offerer wants to move the "m=" section out of the BUNDLE group 1060 (Section 7.5.2), or 1062 * The offerer wants to disable the "m=" section (Section 7.5.3). 1064 The offerer can modify the offerer BUNDLE address:port, add and 1065 remove SDP attributes, or modify SDP attribute values in the 1066 subsequent offer. Changes to the offerer BUNDLE address:port and the 1067 offerer BUNDLE attributes will (if the offer is accepted by the 1068 answerer) be applied to each bundled "m=" section within the BUNDLE 1069 group. 1071 7.5.1. Adding a Media Description to a BUNDLE Group 1073 When an offerer generates a subsequent offer, in which it wants to 1074 add a bundled "m=" section to a previously negotiated BUNDLE group, 1075 the offerer follows the procedures in Section 7.5. The offerer picks 1076 either the added "m=" section or an "m=" section previously added to 1077 the BUNDLE group as the offerer-tagged "m=" section. 1079 RFC 8843 Bundled Media November 2021 1081 NOTE: As described in Section 7.3.2, the answerer cannot move the 1082 added "m=" section out of the BUNDLE group in its answer. If the 1083 answerer wants to move the "m=" section out of the BUNDLE group, it 1084 will have to first accept it into the BUNDLE group in the answer, and 1085 then send a subsequent offer where the "m=" section is moved out of 1086 the BUNDLE group (Section 7.5.2). 1088 7.5.2. Moving a Media Description Out of a BUNDLE Group 1090 When an offerer generates a subsequent offer, in which it wants to 1091 remove a bundled "m=" section from a BUNDLE group, the offerer: 1093 * MUST assign a unique address:port to the "m=" section; 1095 * MUST include SDP attributes in the "m=" section following the 1096 normal offer/answer rules for each attribute; 1098 * MUST NOT place the identification-tag associated with the "m=" 1099 section in the SDP 'group:BUNDLE' attribute identification-tag 1100 list associated with the BUNDLE group; and 1102 * MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 1103 section. 1105 For the other bundled "m=" sections within the BUNDLE group, the 1106 offerer follows the procedures in Section 7.5. 1108 An offerer MUST NOT move an "m=" section from one BUNDLE group to 1109 another within a single offer. If the offerer wants to move an "m=" 1110 section from one BUNDLE group to another, it MUST first move the 1111 BUNDLE group out of the current BUNDLE group, and then generate a 1112 second offer where the "m=" section is added to another BUNDLE group 1113 (Section 7.5.1). 1115 Section 18.4 shows an example of an offer for moving an "m=" section 1116 out of a BUNDLE group. 1118 7.5.3. Disabling a Media Description in a BUNDLE Group 1120 When an offerer generates a subsequent offer, in which it wants to 1121 disable a bundled "m=" section from a BUNDLE group, the offerer: 1123 * MUST assign a zero port value to the "m=" section, following the 1124 procedures in [RFC4566]; 1126 * MUST NOT place the identification-tag associated with the "m=" 1127 section in the SDP 'group:BUNDLE' attribute identification-tag 1128 list associated with the BUNDLE group; and 1130 RFC 8843 Bundled Media November 2021 1132 * MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 1133 section. 1135 For the other bundled "m=" sections within the BUNDLE group, the 1136 offerer follows the procedures in Section 7.5. 1138 Section 18.5 shows an example of an offer and answer for disabling an 1139 "m=" section within a BUNDLE group. 1141 7.6. 3PCC Considerations 1143 In some 3rd Party Call Control (3PCC) scenarios a new session will be 1144 established between an endpoint that is currently part of an ongoing 1145 session and an endpoint that is currently not part of an ongoing 1146 session. The endpoint that is part of a session will generate a 1147 subsequent SDP Offer that will be forwarded to the other endpoint by 1148 a 3PCC controller. The endpoint that is not part of a session will 1149 process the Offer as an initial SDP Offer. 1151 The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent 1152 Client (UAC) to send a re-INVITE request without an SDP body 1153 (sometimes referred to as an empty re-INVITE). In such cases, the 1154 User Agent Server (UAS) will include an SDP Offer in the associated 1155 200 (OK) response. If the UAS is a part of an ongoing SIP session, 1156 it will include a subsequent offer in the 200 (OK) response. The 1157 offer will be received by a 3PCC controller (UAC) and then forwarded 1158 to another User Agent (UA). If the UA is not part of an ongoing SIP 1159 session, it will process the offer as an initial SDP Offer. 1161 When the BUNDLE mechanism is used, an initial BUNDLE Offer is 1162 constructed using different rules than subsequent BUNDLE Offers, and 1163 it cannot be assumed that a UA is able to correctly process a 1164 subsequent BUNDLE Offer as an initial BUNDLE Offer. Therefore, the 1165 3PCC controller SHOULD rewrite the subsequent BUNDLE Offer into a 1166 valid initial BUNDLE Offer, following the procedures in Section 7.2, 1167 before it forwards the BUNDLE Offer to a UA. In the rewritten BUNDLE 1168 Offer the 3PCC controller will set the port value to zero (and 1169 include an SDP 'bundle-only' attribute) for each "m=" section within 1170 the BUNDLE group, excluding the offerer-tagged "m=" section. 1172 8. Protocol Identification 1174 Each "m=" section within a BUNDLE group MUST use the same transport- 1175 layer protocol. If bundled "m=" sections use different upper-layer 1176 protocols on top of the transport-layer protocol, there MUST exist a 1177 publicly available specification that describes how a mechanism 1178 associates received data with the correct protocol for this 1179 particular protocol combination. 1181 RFC 8843 Bundled Media November 2021 1183 In addition, if received data can be associated with more than one 1184 bundled "m=" section, there MUST exist a publicly available 1185 specification that describes a mechanism for associating the received 1186 data with the correct "m=" section. 1188 This document describes a mechanism to identify the protocol of 1189 received data among the Session Traversal Utilities for NAT (STUN), 1190 DTLS, and the Secure Real-time Transport Protocol (SRTP) (in any 1191 combination) when UDP is used as a transport-layer protocol, but it 1192 does not describe how to identify different protocols transported on 1193 DTLS. While the mechanism is generally applicable to other protocols 1194 and transport-layer protocols, any such use requires further 1195 specification that encompasses how to multiplex multiple protocols on 1196 a given transport-layer protocol and how to associate received data 1197 with the correct protocols. 1199 8.1. STUN, DTLS, and SRTP 1201 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 1202 protocol of a received packet among the STUN, DTLS, and SRTP 1203 protocols (in any combination). If an offer or answer includes a 1204 bundled "m=" section that represents these protocols, the offerer or 1205 answerer MUST support the mechanism described in [RFC5764], and no 1206 explicit negotiation is required in order to indicate support and 1207 usage of the mechanism. 1209 [RFC5764] does not describe how to identify different protocols 1210 transported on DTLS, only how to identify the DTLS protocol itself. 1211 If multiple protocols are transported on DTLS, there MUST exist a 1212 specification describing a mechanism for identifying each individual 1213 protocol. In addition, if a received DTLS packet can be associated 1214 with more than one "m=" section, there MUST exist a specification 1215 that describes a mechanism for associating the received DTLS packets 1216 with the correct "m=" section. 1218 Section 9.2 describes how to associate the packets in a received SRTP 1219 stream with the correct "m=" section. 1221 9. RTP Considerations 1223 9.1. Single RTP Session 1225 All RTP-based media within a single BUNDLE group belong to a single 1226 RTP session [RFC3550]. 1228 Since a single BUNDLE transport is used for sending and receiving 1229 bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for 1230 RTP-based bundled media. 1232 RFC 8843 Bundled Media November 2021 1234 Since a single RTP session is used for each BUNDLE group, all "m=" 1235 sections representing RTP-based media within a BUNDLE group will 1236 share a single Synchronization Source (SSRC) numbering space 1237 [RFC3550]. 1239 The following rules and restrictions apply for a single RTP session: 1241 * A specific payload type value can be used in multiple bundled "m=" 1242 sections only if each codec associated with the payload type 1243 number shares an identical codec configuration (Section 9.1.1). 1245 * The proto value in each bundled RTP-based "m=" section MUST be 1246 identical (e.g., RTP/AVPF). 1248 * The RTP MID header extension MUST be enabled, by including an SDP 1249 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 1250 hdrext:sdes:mid' URI value defined in this specification, in each 1251 bundled RTP-based "m=" section in every offer and answer. 1253 * A given SSRC MUST NOT transmit RTP packets using payload types 1254 that originate from different bundled "m=" sections. 1256 NOTE: The last bullet above is to avoid sending multiple media types 1257 from the same SSRC. If transmission of multiple media types are done 1258 with time overlap, RTP and RTCP fail to function. Even if done in 1259 proper sequence, this causes RTP timestamp rate switching issues 1260 [RFC7160]. However, once an SSRC has left the RTP session (by 1261 sending an RTCP BYE packet), that SSRC can be reused by another 1262 source (possibly associated with a different bundled "m=" section) 1263 after a delay of 5 RTCP reporting intervals (the delay is to ensure 1264 the SSRC has timed out, in case the RTCP BYE packet was lost 1265 [RFC3550]). 1267 [RFC7657] defines Differentiated Services (Diffserv) considerations 1268 for RTP-based bundled media sent using a mixture of Diffserv 1269 Codepoints. 1271 9.1.1. Payload Type (PT) Value Reuse 1273 Multiple bundled "m=" sections might describe RTP-based media. As 1274 all RTP-based media associated with a BUNDLE group belong to the same 1275 RTP session, in order for a given payload type value to be used 1276 inside more than one bundled "m=" section, all codecs associated with 1277 the payload type number MUST share an identical codec configuration. 1278 This means that the codecs MUST share the same media type, encoding 1279 name, clock rate, and any parameter that can affect the codec 1280 configuration and packetization. [RFC8859] lists SDP attributes, 1281 whose attribute values are required to be identical for all codecs 1283 RFC 8843 Bundled Media November 2021 1285 that use the same payload type value. 1287 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 1288 Description 1290 As described in [RFC3550], RTP packets are associated with RTP 1291 streams [RFC7656]. Each RTP stream is identified by an SSRC value, 1292 and each RTP packet includes an SSRC field that is used to associate 1293 the packet with the correct RTP stream. RTCP packets also use SSRCs 1294 to identify which RTP streams the packet relates to. However, an 1295 RTCP packet can contain multiple SSRC fields, in the course of 1296 providing feedback or reports on different RTP streams, and therefore 1297 can be associated with multiple such streams. 1299 In order to be able to process received RTP/RTCP packets correctly, 1300 it MUST be possible to associate an RTP stream with the correct "m=" 1301 section, as the "m=" section and SDP attributes associated with the 1302 "m=" section contains information needed to process the packets. 1304 As all RTP streams associated with a BUNDLE group use the same 1305 transport for sending and receiving RTP/RTCP packets, the local 1306 address:port combination part of the transport cannot be used to 1307 associate an RTP stream with the correct "m=" section. In addition, 1308 multiple RTP streams might be associated with the same "m=" section. 1310 An offerer and answerer can inform each other which SSRC values they 1311 will use for an RTP stream by using the SDP 'ssrc' attribute 1312 [RFC5576]. However, an offerer will not know which SSRC values the 1313 answerer will use until the offerer has received the answer providing 1314 that information. Due to this, before the offerer has received the 1315 answer, the offerer will not be able to associate an RTP stream with 1316 the correct "m=" section using the SSRC value associated with the RTP 1317 stream. In addition, the offerer and answerer may start using new 1318 SSRC values mid-session, without informing each other about using the 1319 SDP 'ssrc' attribute. 1321 In order for an offerer and answerer to always be able to associate 1322 an RTP stream with the correct "m=" section, the offerer and answerer 1323 using the BUNDLE extension MUST support the mechanism defined in 1324 Section 15, where the offerer and answerer insert the identification- 1325 tag associated with an "m=" section (provided by the remote peer) 1326 into RTP and RTCP packets associated with a BUNDLE group. 1328 When using this mechanism, the mapping from an SSRC to an 1329 identification-tag is carried in RTP header extensions or RTCP SDES 1330 packets, as specified in Section 15. Since a compound RTCP packet 1331 can contain multiple RTCP SDES packets, and each RTCP SDES packet can 1332 contain multiple chunks, a single RTCP packet can contain several 1334 RFC 8843 Bundled Media November 2021 1336 mappings of SSRC to identification-tag. The offerer and answerer 1337 maintain tables used for routing that are updated each time an RTP/ 1338 RTCP packet contains new information that affects how packets are to 1339 be routed. 1341 However, some legacy implementations may not include this 1342 identification-tag in their RTP and RTCP traffic when using the 1343 BUNDLE mechanism and instead use a mechanism based on the payload 1344 type to associate RTP streams with SDP "m=" sections. In this 1345 situation, each "m=" section needs to use unique payload type values, 1346 in order for the payload type to be a reliable indicator of the 1347 relevant "m=" section for the RTP stream. If an implementation fails 1348 to ensure unique payload type values, it will be impossible to 1349 associate the RTP stream using that payload type value to a 1350 particular "m=" section. Note that when using the payload type to 1351 associate RTP streams with "m=" sections, an RTP stream, identified 1352 by its SSRC, will be mapped to an "m=" section when the first packet 1353 of that RTP stream is received, and the mapping will not be changed 1354 even if the payload type used by that RTP stream changes. In other 1355 words, the SSRC cannot "move" to a different "m=" section simply by 1356 changing the payload type. 1358 Applications can implement RTP stacks in different ways. The 1359 algorithm below details one way that RTP streams can be associated 1360 with "m=" sections, but it is not meant to be prescriptive about 1361 exactly how an RTP stack needs to be implemented. Applications MAY 1362 use any algorithm that achieves equivalent results to those described 1363 in the algorithm below. 1365 To prepare to associate RTP streams with the correct "m=" section, 1366 the following steps MUST be followed for each BUNDLE group: 1368 * Construct a table mapping a MID to an "m=" section for each "m=" 1369 section in this BUNDLE group. Note that an "m=" section may only 1370 have one MID. 1372 * Construct a table mapping SSRCs of incoming RTP streams to an "m=" 1373 section for each "m=" section in this BUNDLE group and for each 1374 SSRC configured for receiving in that "m=" section. 1376 * Construct a table mapping the SSRC of each outgoing RTP stream to 1377 an "m=" section for each "m=" section in this BUNDLE group and for 1378 each SSRC configured for sending in that "m=" section. 1380 RFC 8843 Bundled Media November 2021 1382 * Construct a table mapping a payload type to an "m=" section for 1383 each "m=" section in the BUNDLE group and for each payload type 1384 configured for receiving in that "m=" section. If any payload 1385 type is configured for receiving in more than one "m=" section in 1386 the BUNDLE group, do not include it in the table, as it cannot be 1387 used to uniquely identify an "m=" section. 1389 * Note that for each of these tables, there can only be one mapping 1390 for any given key (MID, SSRC, or PT). In other words, the tables 1391 are not multimaps. 1393 As "m=" sections are added or removed from the BUNDLE groups, or 1394 their configurations are changed, the tables above MUST also be 1395 updated. 1397 When an RTP packet is received, it MUST be delivered to the RTP 1398 stream corresponding to its SSRC. That RTP stream MUST then be 1399 associated with the correct "m=" section within a BUNDLE group, for 1400 additional processing, according to the following steps: 1402 * If the MID associated with the RTP stream is not in the table 1403 mapping a MID to an "m=" section, then the RTP stream is not 1404 decoded, and the payload data is discarded. 1406 * If the packet has a MID, and the packet's extended sequence number 1407 is greater than that of the last MID update, as discussed in 1408 [RFC7941], Section 4.2.6, update the MID associated with the RTP 1409 stream to match the MID carried in the RTP packet, and then update 1410 the mapping tables to include an entry that maps the SSRC of that 1411 RTP stream to the "m=" section for that MID. 1413 * If the SSRC of the RTP stream is in the incoming SSRC mapping 1414 table, check that the payload type used by the RTP stream matches 1415 a payload type included on the matching "m=" section. If so, 1416 associate the RTP stream with that "m=" section. Otherwise, the 1417 RTP stream is not decoded, and the payload data is discarded. 1419 * If the payload type used by the RTP stream is in the payload type 1420 table, update the incoming SSRC mapping table to include an entry 1421 that maps the RTP stream's SSRC to the "m=" section for that 1422 payload type. Associate the RTP stream with the corresponding 1423 "m=" section. 1425 * Otherwise, mark the RTP stream as "not for decoding" and discard 1426 the payload. 1428 RFC 8843 Bundled Media November 2021 1430 If the RTP packet contains one or more Contributing Source (CSRC) 1431 identifiers, then each CSRC is looked up in the incoming SSRC table, 1432 and a copy of the RTP packet is associated with the corresponding 1433 "m=" section for additional processing. 1435 For each RTCP packet received (including each RTCP packet that is 1436 part of a compound RTCP packet), the packet is processed as usual by 1437 the RTP layer, then associated with the appropriate "m=" sections, 1438 and processed for the RTP streams represented by those "m=" sections. 1439 This routing is type dependent, as each kind of RTCP packet has its 1440 own mechanism for associating it with the relevant RTP streams. 1442 RTCP packets that cannot be associated with an appropriate "m=" 1443 section MUST still be processed as usual by the RTP layer, which 1444 updates the metadata associated with the corresponding RTP streams. 1445 This situation can occur with certain multiparty RTP topologies or 1446 when RTCP packets are sent containing a subset of the SDES 1447 information. 1449 Additional rules for processing various types of RTCP packets are 1450 explained below. 1452 * If the RTCP packet is of type SDES, for each chunk in the packet 1453 whose SSRC is found in the incoming SSRC table, deliver a copy of 1454 the SDES packet to the "m=" section associated with that SSRC. In 1455 addition, for any SDES MID items contained in these chunks, if the 1456 MID is found in the table mapping a MID to an "m=" section, update 1457 the incoming SSRC table to include an entry that maps the RTP 1458 stream associated with the chunk's SSRC to the "m=" section 1459 associated with that MID, unless the packet is older than the 1460 packet that most recently updated the mapping for this SSRC, as 1461 discussed in [RFC7941], Section 4.2.6. 1463 * Note that if an SDES packet is received as part of a compound RTCP 1464 packet, the SSRC to "m=" section mapping might not exist until the 1465 SDES packet is handled (e.g., in the case where RTCP for a source 1466 is received before any RTP packets). Therefore, it can be 1467 beneficial for an implementation to delay RTCP packet routing, 1468 such that it either prioritizes processing of the SDES item to 1469 generate or update the mapping or buffers the RTCP information 1470 that needs to be routed until the SDES item(s) has been processed. 1471 If the implementation is unable to follow this recommendation, the 1472 consequence could be that some RTCP information from this 1473 particular RTCP compound packet is not provided to higher layers. 1474 The impact from this is likely minor, when this information 1475 relates to a future incoming RTP stream. 1477 RFC 8843 Bundled Media November 2021 1479 * If the RTCP packet is of type BYE, it indicates that the RTP 1480 streams referenced in the packet are ending. Therefore, for each 1481 SSRC indicated in the packet that is found in the incoming SSRC 1482 table, first deliver a copy of the BYE packet to the "m=" section 1483 associated with that SSRC, and then remove the entry for that SSRC 1484 from the incoming SSRC table after an appropriate delay to account 1485 for "straggler packets", as specified in [RFC3550], Section 6.2.1. 1487 * If the RTCP packet is of type Sender Report (SR) or Receiver 1488 Report (RR), for each report block in the report whose "SSRC of 1489 source" is found in the outgoing SSRC table, deliver a copy of the 1490 SR or RR packet to the "m=" section associated with that SSRC. In 1491 addition, if the packet is of type SR, and the sender SSRC for the 1492 packet is found in the incoming SSRC table, deliver a copy of the 1493 SR packet to the "m=" section associated with that SSRC. 1495 * If the implementation supports the RTCP Extended Report (XR) and 1496 the packet is of type XR, as defined in [RFC3611], for each report 1497 block in the report whose "SSRC of source" is found in the 1498 outgoing SSRC table, deliver a copy of the XR packet to the "m=" 1499 section associated with that SSRC. In addition, if the sender 1500 SSRC for the packet is found in the incoming SSRC table, deliver a 1501 copy of the XR packet to the "m=" section associated with that 1502 SSRC. 1504 * If the RTCP packet is a feedback message of type RTPFB (transport- 1505 layer FB message) or PSFB (payload-specific FB message), as 1506 defined in [RFC4585], it will contain a media source SSRC, and 1507 this SSRC is used for routing certain subtypes of feedback 1508 messages. However, several subtypes of PSFB and RTPFB messages 1509 include a target SSRC(s) in a section called Feedback Control 1510 Information (FCI). For these messages, the target SSRC(s) is used 1511 for routing. 1513 * If the RTCP packet is a feedback packet that does not include 1514 target SSRCs in its FCI section, and the media source SSRC is 1515 found in the outgoing SSRC table, deliver the feedback packet to 1516 the "m=" section associated with that SSRC. RTPFB and PSFB types 1517 that are handled in this way include: 1519 Generic NACK: (PT=RTPFB, FMT=1) [RFC4585]. 1521 Picture Loss Indication (PLI): (PT=PSFB, FMT=1) [RFC4585]. 1523 Slice Loss Indication (SLI): (PT=PSFB, FMT=2) [RFC4585]. 1525 Reference Picture Selection Indication (RPSI): (PT=PSFB, 1526 FMT=3) [RFC4585]. 1528 RFC 8843 Bundled Media November 2021 1530 * If the RTCP packet is a feedback message that does include a 1531 target SSRC(s) in its FCI section, it can either be a request or a 1532 notification. Requests reference an RTP stream that is being sent 1533 by the message recipient, whereas notifications are responses to 1534 an earlier request and therefore reference an RTP stream that is 1535 being received by the message recipient. 1537 * If the RTCP packet is a feedback request that includes a target 1538 SSRC(s), for each target SSRC that is found in the outgoing SSRC 1539 table, deliver a copy of the RTCP packet to the "m=" section 1540 associated with that SSRC. PSFB and RTPFB types that are handled 1541 in this way include: 1543 Full Intra Request (FIR): (PT=PSFB, FMT=4) [RFC5104]. 1545 Temporal-Spatial Trade-off Request (TSTR): (PT=PSFB, FMT=5) 1546 [RFC5104]. 1548 H.271 Video Back Channel Message (VBCM): (PT=PSFB, FMT=7) 1549 [RFC5104]. 1551 Temporary Maximum Media Stream Bit Rate Request (TMMBR): (PT=R 1552 TPFB, FMT=3) [RFC5104]. 1554 Layer Refresh Request (LRR): (PT=PSFB, FMT=10) [LLR-RTCP]. 1556 * If the RTCP packet is a feedback notification that includes a 1557 target SSRC(s), for each target SSRC that is found in the incoming 1558 SSRC table, deliver a copy of the RTCP packet to the "m=" section 1559 associated with the RTP stream with a matching SSRC. PSFB and 1560 RTPFB types that are handled in this way include: 1562 Temporal-Spatial Trade-off Notification (TSTN): (PT=PSFB, 1563 FMT=6) [RFC5104]. This message is a notification in 1564 response to a prior TSTR. 1566 Temporary Maximum Media Stream Bit Rate Notification 1567 (TMMBN): (PT=RTPFB, FMT=4) [RFC5104]. This message is a 1568 notification in response to a prior TMMBR, but it can also 1569 be sent unsolicited. 1571 If the RTCP packet is of type APP, then it is handled in an 1572 application-specific manner. If the application does not 1573 recognize the APP packet, then it MUST be discarded. 1575 RFC 8843 Bundled Media November 2021 1577 9.3. RTP/RTCP Multiplexing 1579 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 1580 multiplexing [RFC5761] for the RTP-based bundled media (i.e., the 1581 same transport will be used for both RTP packets and RTCP packets). 1582 In addition, the offerer and answerer MUST support the SDP 'rtcp-mux- 1583 only' attribute [RFC8858]. 1585 9.3.1. SDP Offer/Answer Procedures 1587 This section describes how an offerer and answerer use the SDP 'rtcp- 1588 mux' [RFC5761] and SDP 'rtcp-mux-only' attributes [RFC8858] to 1589 negotiate usage of RTP/RTCP multiplexing for RTP-based bundled media. 1591 RTP/RTCP multiplexing only applies to RTP-based media. However, as 1592 described in Section 7.1.3, within an offer or answer the SDP 'rtcp- 1593 mux' and SDP 'rtcp-mux-only' attributes might be included in a 1594 bundled "m=" section for non-RTP-based media (if such "m=" section is 1595 the offerer-tagged "m=" section or answerer-tagged "m=" section). 1597 9.3.1.1. Generating the Initial BUNDLE Offer 1599 When an offerer generates an initial BUNDLE Offer, if the offer 1600 contains one or more bundled "m=" sections for RTP-based media (or, 1601 if there is a chance that "m=" sections for RTP-based media will 1602 later be added to the BUNDLE group), the offerer MUST include an SDP 1603 'rtcp-mux' attribute [RFC5761] in each bundled "m=" section 1604 (excluding any bundle-only "m=" sections). In addition, the offerer 1605 MAY include an SDP 'rtcp-mux-only' attribute [RFC8858] in one or more 1606 bundled "m=" sections for RTP-based media. 1608 NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute 1609 depends on whether the offerer supports fallback to usage of a 1610 separate port for RTCP in case the answerer moves one or more "m=" 1611 sections for RTP-based media out of the BUNDLE group in the answer. 1613 NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the 1614 bundled "m=" sections, but does not include an SDP 'rtcp-mux-only' 1615 attribute, the offerer can also include an SDP 'rtcp' attribute 1616 [RFC3605] in one or more RTP-based bundled "m=" sections in order to 1617 provide a fallback port for RTCP, as described in [RFC5761]. 1618 However, the fallback port will only be applied to "m=" sections for 1619 RTP-based media that are moved out of the BUNDLE group by the 1620 answerer. 1622 In the initial BUNDLE Offer, the address:port combination for RTCP 1623 MUST be unique in each bundled "m=" section for RTP-based media 1624 (excluding a bundle-only "m=" section), similar to RTP. 1626 RFC 8843 Bundled Media November 2021 1628 9.3.1.2. Generating the SDP Answer 1630 When an answerer generates an answer, if the answerer supports RTP- 1631 based media, and if a bundled "m=" section in the corresponding offer 1632 contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage 1633 of RTP/RTCP multiplexing, even if there currently are no bundled "m=" 1634 sections for RTP-based media within the BUNDLE group. The answerer 1635 MUST include an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" 1636 section, following the procedures for BUNDLE attributes 1637 (Section 7.1.3). In addition, if the "m=" section that is selected 1638 as the offerer-tagged "m=" section contained an SDP 'rtcp-mux-only' 1639 attribute, the answerer MUST include an SDP 'rtcp-mux-only' attribute 1640 in the answerer-tagged "m=" section. 1642 In an initial BUNDLE Offer, if the suggested offerer-tagged "m=" 1643 section contained an SDP 'rtcp-mux-only' attribute, the "m=" section 1644 was for RTP-based media. If the answerer does not accept the "m=" 1645 section in the created BUNDLE group, and moves the "m=" section out 1646 of the BUNDLE group (Section 7.3.2), the answerer MUST include the 1647 attribute in the moved "m=" section and enable RTP/RTCP multiplexing 1648 for the media associated with the "m=" section. If the answerer 1649 rejects the "m=" section (Section 7.3.3) the answerer MUST NOT 1650 include the attribute. 1652 The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled 1653 "m=" section in the answer. The answerer will use the port value of 1654 the offerer-tagged "m=" section sending RTP and RTCP packets 1655 associated with RTP-based bundled media towards the offerer. 1657 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1658 negotiated in a previous offer/answer exchange, the answerer MUST 1659 include an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" 1660 section. It is not possible to disable RTP/RTCP multiplexing within 1661 a BUNDLE group. 1663 9.3.1.3. Offerer Processing of the SDP Answer 1665 When an offerer receives an answer, if the answerer has accepted the 1666 usage of RTP/RTCP multiplexing (Section 9.3.1.2), the answerer 1667 follows the procedures for RTP/RTCP multiplexing defined in 1668 [RFC5761]. The offerer will use the port value of the answerer- 1669 tagged "m=" section for sending RTP and RTCP packets associated with 1670 RTP-based bundled media towards the answerer. 1672 NOTE: It is considered a protocol error if the answerer has not 1673 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" 1674 sections that the answerer included in the BUNDLE group. 1676 RFC 8843 Bundled Media November 2021 1678 9.3.1.4. Modifying the Session 1680 When an offerer generates a subsequent offer, the offerer MUST 1681 include an SDP 'rtcp-mux' attribute in the offerer-tagged "m=" 1682 section, following the procedures for IDENTICAL multiplexing category 1683 attributes in Section 7.1.3. 1685 10. ICE Considerations 1687 This section describes how to use the BUNDLE grouping extension 1688 together with the ICE mechanism [RFC8445]. 1690 The generic procedures for negotiating the usage of ICE using SDP, 1691 defined in [RFC8839], also apply to the usage of ICE with BUNDLE, 1692 with the following exceptions: 1694 * When the BUNDLE transport has been established, ICE connectivity 1695 checks and keepalives only need to be performed for the BUNDLE 1696 transport, instead of per individual bundled "m=" section within 1697 the BUNDLE group. 1699 * The generic SDP attribute offer/answer considerations 1700 (Section 7.1.3) also apply to ICE-related attributes. Therefore, 1701 when an offerer sends an initial BUNDLE Offer (in order to 1702 negotiate a BUNDLE group), the offerer includes ICE-related media- 1703 level attributes in each bundled "m=" section (excluding any 1704 bundle-only "m=" sections), and each "m=" section MUST contain 1705 unique ICE properties. When an answerer generates an answer 1706 (initial BUNDLE answer or subsequent) that contains a BUNDLE 1707 group, and when an offerer sends a subsequent offer that contains 1708 a BUNDLE group, ICE-related media-level attributes are only 1709 included in the tagged "m=" section (suggested offerer-tagged "m=" 1710 section or answerer-tagged "m=" section), and the ICE properties 1711 are applied to each bundled "m=" section within the BUNDLE group. 1713 NOTE: Most ICE-related media-level SDP attributes belong to the 1714 TRANSPORT multiplexing category [RFC8859], and the generic SDP 1715 attribute offer/answer considerations for the TRANSPORT multiplexing 1716 category apply to the attributes. However, in the case of ICE- 1717 related attributes, the same considerations also apply to ICE-related 1718 media-level attributes that belong to other multiplexing categories. 1720 NOTE: The following ICE-related media-level SDP attributes are 1721 defined in [RFC8839]: 'candidate', 'remote-candidates', 'ice- 1722 mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-pacing'. 1724 RFC 8843 Bundled Media November 2021 1726 Initially, before ICE has produced selected candidate pairs that will 1727 be used for media, there might be multiple transports established (if 1728 multiple candidate pairs are tested). Once ICE has selected 1729 candidate pairs, they form the BUNDLE transport. 1731 Support and usage of the ICE mechanism together with the BUNDLE 1732 extension is OPTIONAL, and the procedures in this section only apply 1733 when the ICE mechanism is used. Note that applications might mandate 1734 usage of the ICE mechanism even if the BUNDLE extension is not used. 1736 NOTE: If the Trickle ICE mechanism [RFC8840] is used, an offerer and 1737 answerer might assign a port value of '9' and an IPv4 address of 1738 '0.0.0.0' (or, the IPv6 equivalent '::') to multiple bundled "m=" 1739 sections in the initial BUNDLE Offer. The offerer and answerer will 1740 follow the normal procedures for generating the offers and answers, 1741 including picking a bundled "m=" section as the suggested offerer- 1742 tagged "m=" section, selecting the tagged "m=" sections, etc. The 1743 only difference is that media cannot be sent until one or more 1744 candidates have been provided. Once a BUNDLE group has been 1745 negotiated, trickled candidates associated with a bundled "m=" 1746 section will be applied to all bundled "m=" sections within the 1747 BUNDLE group. 1749 11. DTLS Considerations 1751 One or more media streams within a BUNDLE group might use the 1752 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1753 to encrypt the data or negotiate encryption keys if another 1754 encryption mechanism is used to encrypt media. 1756 When DTLS is used within a BUNDLE group, the following rules apply: 1758 * There can only be one DTLS association [RFC6347] associated with 1759 the BUNDLE group; 1761 * Each usage of the DTLS association within the BUNDLE group MUST 1762 use the same mechanism for determining which endpoints (the 1763 offerer or answerer) become DTLS client and DTLS server; 1765 * Each usage of the DTLS association within the BUNDLE group MUST 1766 use the same mechanism for determining whether an offer or answer 1767 will trigger the establishment of a new DTLS association or an 1768 existing DTLS association will be used; and 1770 RFC 8843 Bundled Media November 2021 1772 * If the DTLS client supports DTLS-SRTP, it MUST include the 1773 'use_srtp' extension in the DTLS ClientHello message [RFC5764]. 1774 The client MUST include the extension even if the usage of DTLS- 1775 SRTP is not negotiated as part of the multimedia session (e.g., 1776 the SIP session [RFC3261]). 1778 NOTE: The inclusion of the 'use_srtp' extension during the initial 1779 DTLS handshake ensures that a DTLS renegotiation will not be required 1780 in order to include the extension, in case DTLS-SRTP encrypted media 1781 is added to the BUNDLE group later during the multimedia session. 1783 12. RTP Header Extensions Consideration 1785 When RTP header extensions [RFC8285] are used in the context of this 1786 specification, the identifier used for a given extension MUST 1787 identify the same extension across all the bundled media 1788 descriptions. 1790 13. Update to RFC 3264 1792 This section updates RFC 3264, in order to allow extensions to define 1793 the usage of a zero port value in offers and answers for purposes 1794 other than removing or disabling media streams. The following 1795 sections are being updated: 1797 * "Unicast Streams"; see Section 5.1 of [RFC3264] 1799 * "Putting a Unicast Media Stream on Hold"; see Section 8.4 of 1800 [RFC3264]. 1802 13.1. Original Text from RFC 3264, Section 5.1, 2nd Paragraph 1804 | For recvonly and sendrecv streams, the port number and address in 1805 | the offer indicate where the offerer would like to receive the 1806 | media stream. For sendonly RTP streams, the address and port 1807 | number indirectly indicate where the offerer wants to receive RTCP 1808 | reports. Unless there is an explicit indication otherwise, 1809 | reports are sent to the port number one higher than the number 1810 | indicated. The IP address and port present in the offer indicate 1811 | nothing about the source IP address and source port of RTP and 1812 | RTCP packets that will be sent by the offerer. A port number of 1813 | zero in the offer indicates that the stream is offered but MUST 1814 | NOT be used. This has no useful semantics in an initial offer, 1815 | but is allowed for reasons of completeness, since the answer can 1816 | contain a zero port indicating a rejected stream (Section 6). 1817 | Furthermore, existing streams can be terminated by setting the 1818 | port to zero (Section 8). In general, a port number of zero 1819 | indicates that the media stream is not wanted. 1821 RFC 8843 Bundled Media November 2021 1823 13.2. New Text Replacing RFC 3264, Section 5.1, 2nd Paragraph 1825 For recvonly and sendrecv streams, the port number and address in the 1826 offer indicate where the offerer would like to receive the media 1827 stream. For sendonly RTP streams, the address and port number 1828 indirectly indicate where the offerer wants to receive RTCP reports. 1829 Unless there is an explicit indication otherwise, reports are sent to 1830 the port number one higher than the number indicated. The IP address 1831 and port present in the offer indicate nothing about the source IP 1832 address and source port of the RTP and RTCP packets that will be sent 1833 by the offerer. By default, a port number of zero in the offer 1834 indicates that the stream is offered but MUST NOT be used, but an 1835 extension mechanism might specify different semantics for the usage 1836 of a zero port value. Furthermore, existing streams can be 1837 terminated by setting the port to zero (Section 8). In general, a 1838 port number of zero by default indicates that the media stream is not 1839 wanted. 1841 13.3. Original Text from RFC 3264, Section 8.4, 6th Paragraph 1843 | RFC 2543 [10] specified that placing a user on hold was 1844 | accomplished by setting the connection address to 0.0.0.0. Its 1845 | usage for putting a call on hold is no longer recommended, since 1846 | it doesn't allow for RTCP to be used with held streams, doesn't 1847 | work with IPv6, and breaks with connection oriented media. 1848 | However, it can be useful in an initial offer when the offerer 1849 | knows it wants to use a particular set of media streams and 1850 | formats, but doesn't know the addresses and ports at the time of 1851 | the offer. Of course, when used, the port number MUST NOT be 1852 | zero, which would specify that the stream has been disabled. An 1853 | agent MUST be capable of receiving SDP with a connection address 1854 | of 0.0.0.0, in which case it means that neither RTP nor RTCP 1855 | should be sent to the peer. 1857 13.4. New Text Replacing RFC 3264, Section 8.4, 6th Paragraph 1859 RFC 2543 [RFC2543] specifies that placing a user on hold was 1860 accomplished by setting the connection address to 0.0.0.0. Its usage 1861 for putting a call on hold is no longer recommended, since it doesn't 1862 allow for RTCP to be used with held streams, doesn't work with IPv6, 1863 and breaks with connection oriented media. However, it can be useful 1864 in an initial offer when the offerer knows it wants to use a 1865 particular set of media streams and formats, but doesn't know the 1866 addresses and ports at the time of the offer. Of course, when used, 1867 the port number MUST NOT be zero, if it would specify that the stream 1868 has been disabled. However, an extension mechanism might specify 1869 different semantics of the zero port number usage. An agent MUST be 1870 capable of receiving SDP with a connection address of 0.0.0.0, in 1872 RFC 8843 Bundled Media November 2021 1874 which case it means that neither RTP nor RTCP is to be sent to the 1875 peer. 1877 14. Update to RFC 5888 1879 This section updates RFC 5888 [RFC5888], in order for extensions to 1880 allow an SDP 'group' attribute containing an identification-tag that 1881 identifies an "m=" section with the port set to zero. "Group Value 1882 in Answers" (Section 9.2 of [RFC5888]) is updated. 1884 14.1. Original Text from RFC 5888, Section 9.2, 3rd Paragraph 1886 | SIP entities refuse media streams by setting the port to zero in 1887 | the corresponding "m" line. "a=group" lines MUST NOT contain 1888 | identification-tags that correspond to "m" lines with the port set 1889 | to zero. 1891 14.2. New Text Replacing RFC 5888, Section 9.2, 3rd Paragraph 1893 SIP entities refuse media streams by setting the port to zero in the 1894 corresponding "m" line. "a=group" lines MUST NOT contain 1895 identification-tags that correspond to "m" lines with the port set to 1896 zero, but an extension mechanism might specify different semantics 1897 for including identification-tags that correspond to such "m=" lines. 1899 15. RTP/RTCP Extensions for identification-tag Transport 1901 Offerers and answerers [RFC3264] can associate identification-tags 1902 with "m=" sections within offers and answers, using the procedures in 1903 [RFC5888]. Each identification-tag uniquely represents an "m=" 1904 section. 1906 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1907 used to carry identification-tags within RTCP SDES packets. This 1908 section also defines a new RTP SDES header extension [RFC7941], which 1909 is used to carry the 'MID' RTCP SDES item in RTP packets. 1911 The SDES item and RTP SDES header extension make it possible for a 1912 receiver to associate each RTP stream with a specific "m=" section, 1913 with which the receiver has associated an identification-tag, even if 1914 those "m=" sections are part of the same RTP session. The RTP SDES 1915 header extension also ensures that the media recipient gets the 1916 identification-tag upon receipt of the first decodable media and is 1917 able to associate the media with the correct application. 1919 RFC 8843 Bundled Media November 2021 1921 A media recipient informs the media sender about the identification- 1922 tag associated with an "m=" section through the use of a 'mid' 1923 attribute [RFC5888]. The media sender then inserts the 1924 identification-tag in RTCP and RTP packets sent to the media 1925 recipient. 1927 NOTE: The text above defines how identification-tags are carried in 1928 offers and answers. The usage of other signaling protocols for 1929 carrying identification-tags is not prevented, but the usage of such 1930 protocols is outside the scope of this document. 1932 [RFC3550] defines general procedures regarding the RTCP transmission 1933 interval. The RTCP MID SDES item SHOULD be sent in the first few 1934 RTCP packets after joining the session and SHOULD be sent regularly 1935 thereafter. The exact number of RTCP packets in which this SDES item 1936 is sent is intentionally not specified here, as it will depend on the 1937 expected packet-loss rate, the RTCP reporting interval, and the 1938 allowable overhead. 1940 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1941 be included in some RTP packets at the start of the session and 1942 whenever the SSRC changes. It might also be useful to include the 1943 header extension in RTP packets that comprise access points in the 1944 media (e.g., with video I-frames). The exact number of RTP packets 1945 in which this header extension is sent is intentionally not specified 1946 here, as it will depend on expected packet-loss rate and loss 1947 patterns, the overhead the application can tolerate, and the 1948 importance of immediate receipt of the identification-tag. 1950 For robustness, endpoints need to be prepared for situations where 1951 the reception of the identification-tag is delayed and SHOULD NOT 1952 terminate sessions in such cases, as the identification-tag is likely 1953 to arrive soon. 1955 15.1. RTCP MID SDES Item 1957 0 1 2 3 1958 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 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 | MID=15 | length | identification-tag ... 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP. 1965 The identification-tag is not zero terminated. 1967 RFC 8843 Bundled Media November 2021 1969 15.2. RTP SDES Header Extension For MID 1971 The payload, containing the identification-tag, of the RTP SDES 1972 header extension element can be encoded using either the 1-byte or 1973 the 2-byte header [RFC7941]. The identification-tag payload is UTF-8 1974 encoded, as in SDP. 1976 The identification-tag is not zero terminated. Note that the set of 1977 header extensions included in the packet needs to be padded to the 1978 next 32-bit boundary using zero bytes [RFC8285]. 1980 As the identification-tag is included in an RTCP SDES item, an RTP 1981 SDES header extension, or both, there needs to be some consideration 1982 about the packet expansion caused by the identification-tag. To 1983 avoid Maximum Transmission Unit (MTU) issues for the RTP packets, the 1984 header extension's size needs to be taken into account when encoding 1985 the media. 1987 It is recommended that the identification-tag be kept short. Due to 1988 the properties of the RTP header extension mechanism, when using the 1989 1-byte header, a tag that is 1-3 bytes will result in a minimal 1990 number of 32-bit words used for the RTP SDES header extension, in 1991 case no other header extensions are included at the same time. Note, 1992 do take into account that some single characters when UTF-8 encoded 1993 will result in multiple octets. The identification-tag MUST NOT 1994 contain any user information, and applications SHALL avoid generating 1995 the identification-tag using a pattern that enables user or 1996 application identification. 1998 16. IANA Considerations 2000 16.1. New SDES Item 2002 This document updates the MID SDES item to the IANA "RTP SDES Item 2003 Types" registry as follows: 2005 Value: 15 2007 Abbrev.: MID 2009 Name: Media Identification 2011 Reference: RFC XXXX 2013 RFC 8843 Bundled Media November 2021 2015 16.2. New RTP SDES Header Extension URI 2017 This document updates the extension URI in the RTP SDES Compact 2018 Header Extensions sub-registry of the RTP Compact Header Extensions 2019 registry sub-registry, according to the following data: 2021 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 2023 Description: Media identification 2025 Contact: IESG (iesg@ietf.org) 2027 Reference: RFC XXXX 2029 The SDES item does not reveal privacy information about the users. 2030 It is simply used to associate RTP-based media with the correct SDP 2031 media description ("m=" section) in the SDP used to negotiate the 2032 media. 2034 The purpose of the extension is for the offerer to be able to 2035 associate received multiplexed RTP-based media before the offerer 2036 receives the associated answer. 2038 16.3. New SDP Attribute 2040 This document updates the SDP media-level attribute, 'bundle-only', 2041 according to the following data: 2043 Attribute name: bundle-only 2045 Type of attribute: media 2047 Subject to charset: No 2049 Purpose: Request a media description to be accepted in the answer 2050 only if kept within a BUNDLE group by the answerer. 2052 Appropriate values: N/A 2054 Contact name: IESG 2056 Contact e-mail: iesg@ietf.org 2058 Reference: RFC XXXX 2060 Mux category: NORMAL 2062 RFC 8843 Bundled Media November 2021 2064 16.4. New SDP Group Semantics 2066 This document updates the following semantics in the "Semantics for 2067 the 'group' SDP Attribute" subregistry (under the "Session 2068 Description Protocol (SDP) Parameters" registry): 2070 +================+========+==============+===========+ 2071 | Semantics | Token | Mux Category | Reference | 2072 +================+========+==============+===========+ 2073 | Media bundling | BUNDLE | NORMAL | RFC XXXX | 2074 +----------------+--------+--------------+-----------+ 2076 Table 1 2078 17. Security Considerations 2080 The security considerations defined in [RFC3264] and [RFC5888] apply 2081 to the BUNDLE extension. BUNDLE does not change which information, 2082 e.g., RTP streams, flows over the network, except for the usage of 2083 the MID SDES item as discussed below. Primarily, it changes which 2084 addresses and ports, and thus in which (RTP) sessions, the 2085 information flows to. This affects the security contexts being used 2086 and can cause previously separated information flows to share the 2087 same security context. This has very little impact on the 2088 performance of the security mechanism of the RTP sessions. In cases 2089 where one would have applied different security policies on the 2090 different RTP streams being bundled, or where the parties having 2091 access to the security contexts would have differed between the RTP 2092 streams, additional analysis of the implications are needed before 2093 selecting to apply BUNDLE. 2095 The identification-tag, independent of transport, RTCP SDES packet, 2096 or RTP header extension, can expose the value to parties beyond the 2097 signaling chain. Therefore, the identification-tag values MUST be 2098 generated in a fashion that does not leak user information, e.g., 2099 randomly or using a per-bundle group counter, and SHOULD be 3 bytes 2100 or fewer to allow them to efficiently fit into the MID RTP header 2101 extension. Note that if implementations use different methods for 2102 generating identification-tags, this could enable fingerprinting of 2103 the implementation making it vulnerable to targeted attacks. The 2104 identification-tag is exposed on the RTP stream level when included 2105 in the RTP header extensions; however, what it reveals of the RTP 2106 media stream structure of the endpoint and application was already 2107 possible to deduce from the RTP streams without the MID SDES header 2108 extensions. As the identification-tag is also used to route the 2109 media stream to the right application functionality, it is important 2110 that the value received is the one intended by the sender; thus, 2111 integrity and the authenticity of the source are important to prevent 2113 RFC 8843 Bundled Media November 2021 2115 denial of service on the application. Existing SRTP configurations 2116 and other security mechanisms protecting the whole RTP/RTCP packets 2117 will provide the necessary protection. 2119 When the BUNDLE extension is used, the set of configurations of the 2120 security mechanism used in all the bundled media descriptions will 2121 need to be compatible so that they can be used simultaneously, at 2122 least per direction or endpoint. When using SRTP, this will be the 2123 case, at least for the IETF-defined key-management solutions due to 2124 their SDP attributes ("a=crypto", "a=fingerprint", "a=mikey") and 2125 their classification in [RFC8859]. 2127 The security considerations of "RTP Header Extension for the RTP 2128 Control Protocol (RTCP) Source Description Items" [RFC7941] require 2129 that when RTCP is confidentiality protected, any SDES RTP header 2130 extension carrying an SDES item, such as the MID RTP header 2131 extension, is also protected using commensurate strength algorithms. 2132 However, assuming the above requirements and recommendations are 2133 followed, there are no known significant security risks with leaving 2134 the MID RTP header extension without confidentiality protection. 2135 Therefore, this specification updates RFC 7941 by adding the 2136 exception that this requirement MAY be ignored for the MID RTP header 2137 extension. Security mechanisms for RTP/RTCP are discussed in 2138 "Options for Securing RTP Sessions" [RFC7201], for example, SRTP 2139 [RFC3711] can provide the necessary security functions of ensuring 2140 the integrity and source authenticity. 2142 18. Examples 2144 18.1. Example: Tagged "m=" Section Selections 2146 The example below shows: 2148 * An initial BUNDLE Offer, in which the offerer wants to negotiate a 2149 BUNDLE group and indicates the audio "m=" section as the suggested 2150 offerer-tagged "m=" section. 2152 * An initial BUNDLE answer, in which the answerer accepts the 2153 creation of the BUNDLE group, selects the audio "m=" section in 2154 the offer as the offerer-tagged "m=" section, selects the audio 2155 "m=" section in the answer as the answerer-tagged "m=" section, 2156 and assigns the answerer BUNDLE address:port to that "m=" section. 2158 SDP Offer (1) 2160 RFC 8843 Bundled Media November 2021 2162 v=0 2163 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2164 s= 2165 c=IN IP6 2001:db8::3 2166 t=0 0 2167 a=group:BUNDLE foo bar 2169 m=audio 10000 RTP/AVP 0 8 97 2170 b=AS:200 2171 a=mid:foo 2172 a=rtcp-mux 2173 a=rtpmap:0 PCMU/8000 2174 a=rtpmap:8 PCMA/8000 2175 a=rtpmap:97 iLBC/8000 2176 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2178 m=video 10002 RTP/AVP 31 32 2179 b=AS:1000 2180 a=mid:bar 2181 a=rtcp-mux 2182 a=rtpmap:31 H261/90000 2183 a=rtpmap:32 MPV/90000 2184 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2186 SDP Answer (2) 2188 v=0 2189 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2190 s= 2191 c=IN IP6 2001:db8::1 2192 t=0 0 2193 a=group:BUNDLE foo bar 2195 m=audio 20000 RTP/AVP 0 2196 b=AS:200 2197 a=mid:foo 2198 a=rtcp-mux 2199 a=rtpmap:0 PCMU/8000 2200 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2202 m=video 20000 RTP/AVP 32 2203 b=AS:1000 2204 a=mid:bar 2205 a=rtpmap:32 MPV/90000 2206 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2208 RFC 8843 Bundled Media November 2021 2210 18.2. Example: BUNDLE Group Rejected 2212 The example below shows: 2214 * An initial BUNDLE Offer, in which the offerer wants to negotiate a 2215 BUNDLE group and indicates the audio "m=" section as the suggested 2216 offerer-tagged "m=" section. 2218 * An initial BUNDLE answer, in which the answerer rejects the 2219 creation of the BUNDLE group, generates a normal answer, and 2220 assigns a unique address:port to each "m=" section in the answer. 2222 SDP Offer (1) 2224 v=0 2225 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2226 s= 2227 c=IN IP6 2001:db8::3 2228 t=0 0 2229 a=group:BUNDLE foo bar 2231 m=audio 10000 RTP/AVP 0 8 97 2232 b=AS:200 2233 a=mid:foo 2234 a=rtcp-mux 2235 a=rtpmap:0 PCMU/8000 2236 a=rtpmap:8 PCMA/8000 2237 a=rtpmap:97 iLBC/8000 2238 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2240 m=video 10002 RTP/AVP 31 32 2241 b=AS:1000 2242 a=mid:bar 2243 a=rtcp-mux 2244 a=rtpmap:31 H261/90000 2245 a=rtpmap:32 MPV/90000 2246 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2248 SDP Answer (2) 2250 RFC 8843 Bundled Media November 2021 2252 v=0 2253 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2254 s= 2255 c=IN IP6 2001:db8::1 2256 t=0 0 2258 m=audio 20000 RTP/AVP 0 2259 b=AS:200 2260 a=rtcp-mux 2261 a=rtpmap:0 PCMU/8000 2263 m=video 30000 RTP/AVP 32 2264 b=AS:1000 2265 a=rtcp-mux 2266 a=rtpmap:32 MPV/90000 2268 18.3. Example: Offerer Adds a Media Description to a BUNDLE Group 2270 The example below shows: 2272 * A subsequent offer, in which the offerer adds a new bundled "m=" 2273 section (video), indicated by the "zen" identification-tag, to a 2274 previously negotiated BUNDLE group; indicates the new "m=" section 2275 as the offerer-tagged "m=" section; and assigns the offerer BUNDLE 2276 address:port to that "m=" section. 2278 * A subsequent answer, in which the answerer indicates the new video 2279 "m=" section in the answer as the answerer-tagged "m=" section and 2280 assigns the answerer BUNDLE address:port to that "m=" section. 2282 SDP Offer (1) 2284 RFC 8843 Bundled Media November 2021 2286 v=0 2287 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2288 s= 2289 c=IN IP6 2001:db8::3 2290 t=0 0 2291 a=group:BUNDLE zen foo bar 2293 m=audio 10000 RTP/AVP 0 8 97 2294 b=AS:200 2295 a=mid:foo 2296 a=rtpmap:0 PCMU/8000 2297 a=rtpmap:8 PCMA/8000 2298 a=rtpmap:97 iLBC/8000 2299 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2301 m=video 10000 RTP/AVP 31 32 2302 b=AS:1000 2303 a=mid:bar 2304 a=rtpmap:31 H261/90000 2305 a=rtpmap:32 MPV/90000 2306 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2308 m=video 10000 RTP/AVP 66 2309 b=AS:1000 2310 a=mid:zen 2311 a=rtcp-mux 2312 a=rtpmap:66 H261/90000 2313 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2315 SDP Answer (2) 2317 RFC 8843 Bundled Media November 2021 2319 v=0 2320 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2321 s= 2322 c=IN IP6 2001:db8::1 2323 t=0 0 2324 a=group:BUNDLE zen foo bar 2326 m=audio 20000 RTP/AVP 0 2327 b=AS:200 2328 a=mid:foo 2329 a=rtpmap:0 PCMU/8000 2330 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2332 m=video 20000 RTP/AVP 32 2333 b=AS:1000 2334 a=mid:bar 2335 a=rtpmap:32 MPV/90000 2336 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2338 m=video 20000 RTP/AVP 66 2339 b=AS:1000 2340 a=mid:zen 2341 a=rtcp-mux 2342 a=rtpmap:66 H261/90000 2343 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2345 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 2347 The example below shows: 2349 * A subsequent offer, in which the offerer removes an "m=" section 2350 (video), indicated by the "zen" identification-tag, from a 2351 previously negotiated BUNDLE group; indicates one of the bundled 2352 "m=" sections (audio) remaining in the BUNDLE group as the 2353 offerer-tagged "m=" section; and assigns the offerer BUNDLE 2354 address:port to that "m=" section. 2356 * A subsequent answer, in which the answerer removes the "m=" 2357 section from the BUNDLE group, indicates the audio "m=" section in 2358 the answer as the answerer-tagged "m=" section, and assigns the 2359 answerer BUNDLE address:port to that "m=" section. 2361 SDP Offer (1) 2363 RFC 8843 Bundled Media November 2021 2365 v=0 2366 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2367 s= 2368 c=IN IP6 2001:db8::3 2369 t=0 0 2370 a=group:BUNDLE foo bar 2372 m=audio 10000 RTP/AVP 0 8 97 2373 b=AS:200 2374 a=mid:foo 2375 a=rtcp-mux 2376 a=rtpmap:0 PCMU/8000 2377 a=rtpmap:8 PCMA/8000 2378 a=rtpmap:97 iLBC/8000 2379 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2381 m=video 10000 RTP/AVP 31 32 2382 b=AS:1000 2383 a=mid:bar 2384 a=rtpmap:31 H261/90000 2385 a=rtpmap:32 MPV/90000 2386 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2388 m=video 50000 RTP/AVP 66 2389 b=AS:1000 2390 a=mid:zen 2391 a=rtcp-mux 2392 a=rtpmap:66 H261/90000 2394 SDP Answer (2) 2396 RFC 8843 Bundled Media November 2021 2398 v=0 2399 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2400 s= 2401 c=IN IP6 2001:db8::1 2402 t=0 0 2403 a=group:BUNDLE foo bar 2405 m=audio 20000 RTP/AVP 0 2406 b=AS:200 2407 a=mid:foo 2408 a=rtcp-mux 2409 a=rtpmap:0 PCMU/8000 2410 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2412 m=video 20000 RTP/AVP 32 2413 b=AS:1000 2414 a=mid:bar 2415 a=rtpmap:32 MPV/90000 2416 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2418 m=video 60000 RTP/AVP 66 2419 b=AS:1000 2420 a=mid:zen 2421 a=rtcp-mux 2422 a=rtpmap:66 H261/90000 2424 18.5. Example: Offerer Disables a Media Description within a BUNDLE 2425 Group 2427 The example below shows: 2429 * A subsequent offer, in which the offerer disables (by assigning a 2430 zero port value) an "m=" section (video), indicated by the "zen" 2431 identification-tag, from a previously negotiated BUNDLE group; 2432 indicates one of the bundled "m=" sections (audio) remaining 2433 active in the BUNDLE group as the offerer-tagged "m=" section; and 2434 assigns the offerer BUNDLE address:port to that "m=" section. 2436 * A subsequent answer, in which the answerer disables the "m=" 2437 section, indicates the audio "m=" section in the answer as the 2438 answerer-tagged "m=" section, and assigns the answerer BUNDLE 2439 address:port to that "m=" section. 2441 SDP Offer (1) 2443 RFC 8843 Bundled Media November 2021 2445 v=0 2446 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2447 s= 2448 t=0 0 2449 a=group:BUNDLE foo bar 2451 m=audio 10000 RTP/AVP 0 8 97 2452 c=IN IP6 2001:db8::3 2453 b=AS:200 2454 a=mid:foo 2455 a=rtcp-mux 2456 a=rtpmap:0 PCMU/8000 2457 a=rtpmap:8 PCMA/8000 2458 a=rtpmap:97 iLBC/8000 2459 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2461 m=video 10000 RTP/AVP 31 32 2462 c=IN IP6 2001:db8::3 2463 b=AS:1000 2464 a=mid:bar 2465 a=rtpmap:31 H261/90000 2466 a=rtpmap:32 MPV/90000 2467 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2469 m=video 0 RTP/AVP 66 2470 a=mid:zen 2471 a=rtpmap:66 H261/90000 2473 SDP Answer (2) 2475 RFC 8843 Bundled Media November 2021 2477 v=0 2478 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2479 s= 2480 t=0 0 2481 a=group:BUNDLE foo bar 2483 m=audio 20000 RTP/AVP 0 2484 c=IN IP6 2001:db8::1 2485 b=AS:200 2486 a=mid:foo 2487 a=rtcp-mux 2488 a=rtpmap:0 PCMU/8000 2489 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2491 m=video 20000 RTP/AVP 32 2492 c=IN IP6 2001:db8::1 2493 b=AS:1000 2494 a=mid:bar 2495 a=rtpmap:32 MPV/90000 2496 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2498 m=video 0 RTP/AVP 66 2499 a=mid:zen 2500 a=rtpmap:66 H261/90000 2502 19. References 2504 19.1. Normative References 2506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2507 Requirement Levels", BCP 14, RFC 2119, 2508 DOI 10.17487/RFC2119, March 1997, 2509 . 2511 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2512 with Session Description Protocol (SDP)", RFC 3264, 2513 DOI 10.17487/RFC3264, June 2002, 2514 . 2516 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2517 Jacobson, "RTP: A Transport Protocol for Real-Time 2518 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2519 July 2003, . 2521 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2522 in Session Description Protocol (SDP)", RFC 3605, 2523 DOI 10.17487/RFC3605, October 2003, 2524 . 2526 RFC 8843 Bundled Media November 2021 2528 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2529 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2530 2003, . 2532 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2533 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2534 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2535 . 2537 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2538 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2539 July 2006, . 2541 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2542 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2543 . 2545 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2546 Control Packets on a Single Port", RFC 5761, 2547 DOI 10.17487/RFC5761, April 2010, 2548 . 2550 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2551 Security (DTLS) Extension to Establish Keys for the Secure 2552 Real-time Transport Protocol (SRTP)", RFC 5764, 2553 DOI 10.17487/RFC5764, May 2010, 2554 . 2556 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2557 Protocol (SDP) Grouping Framework", RFC 5888, 2558 DOI 10.17487/RFC5888, June 2010, 2559 . 2561 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2562 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2563 January 2012, . 2565 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2566 Header Extension for the RTP Control Protocol (RTCP) 2567 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2568 August 2016, . 2570 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2571 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2572 May 2017, . 2574 RFC 8843 Bundled Media November 2021 2576 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 2577 Mechanism for RTP Header Extensions", RFC 8285, 2578 DOI 10.17487/RFC8285, October 2017, 2579 . 2581 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2582 Connectivity Establishment (ICE): A Protocol for Network 2583 Address Translator (NAT) Traversal", RFC 8445, 2584 DOI 10.17487/RFC8445, July 2018, 2585 . 2587 [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keranen, 2588 A., and R. Shpount, "Session Description Protocol (SDP) 2589 Offer/Answer Procedures for Interactive Connectivity 2590 Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, 2591 January 2021, . 2593 [RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 2594 Session Initiation Protocol (SIP) Usage for Incremental 2595 Provisioning of Candidates for the Interactive 2596 Connectivity Establishment (Trickle ICE)", RFC 8840, 2597 DOI 10.17487/RFC8840, January 2021, 2598 . 2600 [RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP 2601 Control Protocol (RTCP) Multiplexing Using the Session 2602 Description Protocol (SDP)", RFC 8858, 2603 DOI 10.17487/RFC8858, January 2021, 2604 . 2606 [RFC8859] Nandakumar, S., "A Framework for Session Description 2607 Protocol (SDP) Attributes When Multiplexing", RFC 8859, 2608 DOI 10.17487/RFC8859, January 2021, 2609 . 2611 19.2. Informative References 2613 [LLR-RTCP] Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 2614 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 2615 Message", Work in Progress, Internet-Draft, draft-ietf- 2616 avtext-lrr-07, 2 July 2017, 2617 . 2620 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 2621 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 2622 DOI 10.17487/RFC2543, March 1999, 2623 . 2625 RFC 8843 Bundled Media November 2021 2627 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2628 A., Peterson, J., Sparks, R., Handley, M., and E. 2629 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2630 DOI 10.17487/RFC3261, June 2002, 2631 . 2633 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2634 "RTP Control Protocol Extended Reports (RTCP XR)", 2635 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2636 . 2638 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2639 "Extended RTP Profile for Real-time Transport Control 2640 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2641 DOI 10.17487/RFC4585, July 2006, 2642 . 2644 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2645 "Codec Control Messages in the RTP Audio-Visual Profile 2646 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 2647 February 2008, . 2649 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2650 Media Attributes in the Session Description Protocol 2651 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2652 . 2654 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2655 Clock Rates in an RTP Session", RFC 7160, 2656 DOI 10.17487/RFC7160, April 2014, 2657 . 2659 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2660 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2661 . 2663 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2664 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2665 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2666 DOI 10.17487/RFC7656, November 2015, 2667 . 2669 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 2670 (Diffserv) and Real-Time Communication", RFC 7657, 2671 DOI 10.17487/RFC7657, November 2015, 2672 . 2674 RFC 8843 Bundled Media November 2021 2676 [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., 2677 "JavaScript Session Establishment Protocol (JSEP)", 2678 RFC 8829, DOI 10.17487/RFC8829, January 2021, 2679 . 2681 [RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: 2682 Incremental Provisioning of Candidates for the Interactive 2683 Connectivity Establishment (ICE) Protocol", RFC 8838, 2684 DOI 10.17487/RFC8838, January 2021, 2685 . 2687 Appendix A. Design Considerations 2689 One of the main issues regarding the BUNDLE grouping extensions has 2690 been whether, in offers and answers, the same port value can be 2691 inserted in "m=" lines associated with a BUNDLE group, as the purpose 2692 of the extension is to negotiate the usage of a single transport for 2693 media specified by the "m=" sections. Issues with both approaches, 2694 discussed in the Appendix, have been raised. The outcome was to 2695 specify a mechanism that uses offers with both different and 2696 identical port values. 2698 Below are the primary issues that have been considered when defining 2699 the "BUNDLE" grouping extension: 2701 1) Interoperability with existing User Agents (UAs). 2703 2) Interoperability with intermediary Back-to-Back User Agent 2704 (B2BUA) and proxy entities. 2706 3) Time to gather, and the number of, ICE candidates. 2708 4) Different error scenarios and when they occur. 2710 5) SDP offer/answer impacts, including usage of port number value 2711 zero. 2713 A.1. UA Interoperability 2715 Consider the following SDP offer/answer exchange, where Alice sends 2716 an offer to Bob: 2718 SDP Offer 2720 RFC 8843 Bundled Media November 2021 2722 v=0 2723 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2724 s= 2725 c=IN IP4 atlanta.example.com 2726 t=0 0 2728 m=audio 10000 RTP/AVP 97 2729 a=rtpmap:97 iLBC/8000 2730 m=video 10002 RTP/AVP 97 2731 a=rtpmap:97 H261/90000 2733 SDP Answer 2735 v=0 2736 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2737 s= 2738 c=IN IP4 biloxi.example.com 2739 t=0 0 2741 m=audio 20000 RTP/AVP 97 2742 a=rtpmap:97 iLBC/8000 2743 m=video 20002 RTP/AVP 97 2744 a=rtpmap:97 H261/90000 2746 RFC 4961 specifies a way of doing symmetric RTP, but that is a later 2747 extension to RTP, and Bob cannot assume that Alice supports RFC 4961. 2748 This means that Alice may be sending RTP from a different port than 2749 10000 or 10002 -- some implementations simply send the RTP from an 2750 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2751 way that Bob knows if the packet is to be passed to the video or 2752 audio codec is by looking at the port it was received on. This 2753 prompted some SDP implementations to use a port number as an index to 2754 find the correct "m=" line in the SDP, since each "m"= section 2755 contains a different port number. As a result, some implementations 2756 that do support symmetric RTP and ICE still use an SDP data structure 2757 where SDP with "m=" sections with the same port such as: 2759 SDP Offer 2761 RFC 8843 Bundled Media November 2021 2763 v=0 2764 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2765 s= 2766 c=IN IP4 atlanta.example.com 2767 t=0 0 2769 m=audio 10000 RTP/AVP 97 2770 a=rtpmap:97 iLBC/8000 2771 m=video 10000 RTP/AVP 98 2772 a=rtpmap:98 H261/90000 2774 will result in the second "m=" section being considered an SDP error 2775 because it has the same port as the first line. 2777 A.2. Usage of Port Number Value Zero 2779 In an offer or answer, the media specified by an "m=" section can be 2780 disabled/rejected by setting the port number value to zero. This is 2781 different from, e.g., using the SDP direction attributes, where RTCP 2782 traffic will continue even if the SDP 'inactive' attribute is 2783 indicated for the associated "m=" section. 2785 If each "m=" section associated with a BUNDLE group would contain 2786 different port values, and one of those port values would be used for 2787 a BUNDLE address:port associated with the BUNDLE group, problems 2788 would occur if an endpoint wants to disable/reject the "m=" section 2789 associated with that port, by setting the port value to zero. After 2790 that, no "m=" section would contain the port value that is used for 2791 the BUNDLE address:port. In addition, it is unclear what would 2792 happen to the ICE candidates associated with the "m=" section, as 2793 they are also used for the BUNDLE address:port. 2795 A.3. B2BUA and Proxy Interoperability 2797 Some back-to-back user agents may be configured in a mode where if 2798 the incoming call leg contains an SDP attribute the B2BUA does not 2799 understand, the B2BUA still generates that SDP attribute in the Offer 2800 for the outgoing call leg. Consider a B2BUA that did not understand 2801 the SDP 'rtcp' attribute, defined in RFC 3605, yet acted this way. 2802 Further, assume that the B2BUA was configured to tear down any call 2803 where it did not see any RTCP for 5 minutes. In this case, if the 2804 B2BUA received an Offer like: 2806 SDP Offer 2808 RFC 8843 Bundled Media November 2021 2810 v=0 2811 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2812 s= 2813 c=IN IP4 atlanta.example.com 2814 t=0 0 2816 m=audio 49170 RTP/AVP 0 2817 a=rtcp:53020 2819 It would be looking for RTCP on port 49171 but would not see any 2820 because the RTCP would be on port 53020, and after five minutes, it 2821 would tear down the call. Similarly, a B2BUA that did not understand 2822 BUNDLE yet put it in its offer may be looking for media on the wrong 2823 port and tear down the call. It is worth noting that a B2BUA that 2824 generated an Offer with capabilities it does not understand is not 2825 compliant with the specifications. 2827 A.3.1. Traffic Policing 2829 Sometimes intermediaries do not act as B2BUAs, in the sense that they 2830 don't modify SDP bodies nor do they terminate SIP dialogs. However, 2831 they may still use SDP information (e.g., IP address and port) in 2832 order to control traffic gating functions and to set traffic policing 2833 rules. There might be rules that will trigger a session to be 2834 terminated in case media is not sent or received on the ports 2835 retrieved from the SDP. This typically occurs once the session is 2836 already established and ongoing. 2838 A.3.2. Bandwidth Allocation 2840 Sometimes, intermediaries do not act as B2BUAs, in the sense that 2841 they don't modify SDP bodies nor do they terminate SIP dialogs. 2842 However, they may still use SDP information (e.g., codecs and media 2843 types) in order to control bandwidth allocation functions. The 2844 bandwidth allocation is done per "m=" section, which means that it 2845 might not be enough if media specified by all "m=" sections try to 2846 use that bandwidth. That may simply lead to either bad user 2847 experience or termination of the call. 2849 A.4. Candidate Gathering 2851 When using ICE, a candidate needs to be gathered for each port. This 2852 takes approximately 20 ms extra for each extra "m=" section due to 2853 the NAT pacing requirements. All of this gathering can be overlapped 2854 with other things while, e.g., a web page is loading to minimize the 2855 impact. If the client only wants to generate Traversal Using Relays 2856 around NAT (TURN) or STUN ICE candidates for one of the "m=" lines 2857 and then use Trickle ICE [RFC8838] to get the non-host ICE candidates 2859 RFC 8843 Bundled Media November 2021 2861 for the rest of the "m=" sections, it MAY do that and will not need 2862 any additional gathering time. 2864 Some people have suggested a TURN extension to get a bunch of TURN 2865 allocations at once. This would only provide a single STUN result, 2866 so in cases where the other end did not support BUNDLE, it may cause 2867 more use of the TURN server, but it would be quick in the cases where 2868 both sides supported BUNDLE and would fall back to a successful call 2869 in the other cases. 2871 Acknowledgements 2873 The usage of the SDP grouping extension for negotiating bundled media 2874 is based on similar alternatives proposed by Harald Alvestrand and 2875 Cullen Jennings. The BUNDLE extension described in this document is 2876 based on the different alternative proposals, and text (e.g., SDP 2877 examples) has been borrowed (and, in some cases, modified) from those 2878 alternative proposals. 2880 The SDP examples are also modified versions from the ones in the 2881 Alvestrand proposal. 2883 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 2884 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 2885 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin 2886 Uberti, Taylor Brandstetter, Byron Campen, and Eric Rescorla for 2887 reading the text and providing useful feedback. 2889 Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus 2890 Westerlund for providing the text for the section on RTP/RTCP stream 2891 association. 2893 Thanks to Magnus Westerlund, Colin Perkins, and Jonathan Lennox for 2894 providing help and text on the RTP/RTCP procedures. 2896 Thanks to Charlie Kaufman for performing the Sec-Dir review. 2898 Thanks to Linda Dunbar for performing the Gen-ART review. 2900 Thanks to Spotify for providing music for the countless hours of 2901 document editing. 2903 Authors' Addresses 2904 RFC 8843 Bundled Media November 2021 2906 Christer Holmberg 2907 Ericsson 2908 Hirsalantie 11 2909 FI-02420 Jorvas 2910 Finland 2912 Email: christer.holmberg@ericsson.com 2914 Harald Tveit Alvestrand 2915 Google 2916 Kungsbron 2 2917 SE-11122 Stockholm 2918 Sweden 2920 Email: harald@alvestrand.no 2922 Cullen Jennings 2923 Cisco 2924 400 3rd Avenue SW, Suite 350 2925 Calgary AB T2P 4H2 2926 Canada 2928 Email: fluffy@iii.ca