idnits 2.17.1 draft-ietf-mmusic-rfc8843bis-02.txt: -(2384): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. 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 (7 June 2021) is 1025 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 1684 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Obsoletes: 8843 (if approved) H. Alvestrand 5 Updates: 3264, 5888, 7941 (if approved) Google 6 Intended status: Standards Track C. Jennings 7 Expires: 9 December 2021 Cisco 8 7 June 2021 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-rfc8843bis-02 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 9 December 2021. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 This document may contain material from IETF Documents or IETF 64 Contributions published or made publicly available before November 65 10, 2008. The person(s) controlling the copyright in some of this 66 material may not have granted the IETF Trust the right to allow 67 modifications of such material outside the IETF Standards Process. 68 Without obtaining an adequate license from the person(s) controlling 69 the copyright in such materials, this document may not be modified 70 outside the IETF Standards Process, and derivative works of it may 71 not be created outside the IETF Standards Process, except to format 72 it for publication as an RFC or to translate it into languages other 73 than English. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 78 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.2. BUNDLE Mechanism . . . . . . . . . . . . . . . . . . . . 4 80 1.3. Protocol Extensions . . . . . . . . . . . . . . . . . . . 5 81 1.4. Changes from RFC 8843 . . . . . . . . . . . . . . . . . . 6 82 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 83 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 85 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 8 86 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 9 87 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 88 7.1. Generic SDP Considerations . . . . . . . . . . . . . . . 11 89 7.1.1. Connection Data ("c=") . . . . . . . . . . . . . . . 11 90 7.1.2. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . 11 91 7.1.3. Attributes ("a=") . . . . . . . . . . . . . . . . . . 11 92 7.2. Generating the Initial SDP Offer . . . . . . . . . . . . 12 93 7.2.1. Suggesting the Offerer-Tagged 'm=' Section . . . . . 13 94 7.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 14 95 7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 14 96 7.3.1. Answerer Selection of Tagged 'm=' Sections . . . . . 16 97 7.3.2. Moving a Media Description Out of a BUNDLE Group . . 17 98 7.3.3. Rejecting a Media Description in a BUNDLE Group . . . 18 99 7.3.4. Example: SDP Answer . . . . . . . . . . . . . . . . . 18 100 7.3.5. RFC 8843 Considerations . . . . . . . . . . . . . . . 19 101 7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 20 102 7.4.1. RFC 8843 Considerations . . . . . . . . . . . . . . . 21 103 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 21 104 7.5.1. Adding a Media Description to a BUNDLE Group . . . . 22 105 7.5.2. Moving a Media Description Out of a BUNDLE Group . . 22 106 7.5.3. Disabling a Media Description in a BUNDLE Group . . . 23 107 8. Protocol Identification . . . . . . . . . . . . . . . . . . . 24 108 8.1. STUN, DTLS, and SRTP . . . . . . . . . . . . . . . . . . 24 109 9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 25 110 9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 25 111 9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 26 112 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 113 Description . . . . . . . . . . . . . . . . . . . . . . . 26 114 9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 32 115 9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 32 116 10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 34 117 11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 35 118 12. RTP Header Extensions Consideration . . . . . . . . . . . . . 36 119 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 36 120 13.1. Original Text from RFC 3264, Section 5.1, 2nd 121 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 36 122 13.2. New Text Replacing RFC 3264, Section 5.1, 2nd 123 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 37 124 13.3. Original Text from RFC 3264, Section 8.4, 6th 125 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 37 126 13.4. New Text Replacing RFC 3264, Section 8.4, 6th 127 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38 128 14. Update to RFC 5888 . . . . . . . . . . . . . . . . . . . . . 38 129 14.1. Original Text from RFC 5888, Section 9.2, 3rd 130 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38 131 14.2. New Text Replacing RFC 5888, Section 9.2, 3rd 132 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38 133 15. RTP/RTCP Extensions for identification-tag Transport . . . . 38 134 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 40 135 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 40 136 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 137 16.1. New SDES Item . . . . . . . . . . . . . . . . . . . . . 40 138 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 41 139 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 41 140 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 42 141 17. Security Considerations . . . . . . . . . . . . . . . . . . . 42 142 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 43 143 18.1. Example: Tagged "m=" Section Selections . . . . . . . . 43 144 18.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 45 145 18.3. Example: Offerer Adds a Media Description to a BUNDLE 146 Group . . . . . . . . . . . . . . . . . . . . . . . . . 46 147 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE 148 Group . . . . . . . . . . . . . . . . . . . . . . . . . 48 149 18.5. Example: Offerer Disables a Media Description within a 150 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 50 151 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 152 19.1. Normative References . . . . . . . . . . . . . . . . . . 52 153 19.2. Informative References . . . . . . . . . . . . . . . . . 54 154 Appendix A. Design Considerations . . . . . . . . . . . . . . . 56 155 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 56 156 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 58 157 A.3. B2BUA and Proxy Interoperability . . . . . . . . . . . . 58 158 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 59 159 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 59 160 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 59 161 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 60 162 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 164 1. Introduction 166 1.1. Background 168 When the SDP offer/answer mechanism [RFC3264] is used to negotiate 169 the establishment of multimedia communication sessions, if separate 170 transports (5-tuples) are negotiated for each individual media 171 stream, each transport consumes additional resources (especially when 172 Interactive Connectivity Establishment (ICE) [RFC8445] is used). For 173 this reason, it is attractive to use a single transport for multiple 174 media streams. 176 1.2. BUNDLE Mechanism 178 This specification defines a way to use a single transport (BUNDLE 179 transport) for sending and receiving media (bundled media) described 180 by multiple SDP media descriptions ("m=" sections). The address:port 181 combination used by an endpoint for sending and receiving bundled 182 media is referred to as the BUNDLE address:port. The set of SDP 183 attributes that are applied to each "m=" section within a BUNDLE 184 group is referred to as BUNDLE attributes. The same BUNDLE transport 185 is used for sending and receiving bundled media, which means that the 186 symmetric Real-time Transport Protocol (RTP) mechanism [RFC4961] is 187 always used for RTP-based bundled media. 189 This specification defines a new SDP Grouping Framework [RFC5888] 190 extension called 'BUNDLE'. The extension can be used with the 191 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 192 to negotiate which "m=" sections will become part of a BUNDLE group. 194 In addition, the offerer and answerer [RFC3264] use the BUNDLE 195 extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE 196 address:port and answerer BUNDLE address:port) and the set of BUNDLE 197 attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) 198 that will be applied to each "m=" section within the BUNDLE group. 200 The use of a BUNDLE transport allows the usage of a single set of ICE 201 [RFC8445] candidates for the whole BUNDLE group. 203 A given BUNDLE address:port MUST only be associated with a single 204 BUNDLE group. If an SDP offer or SDP answer (hereafter referred to 205 as "offer" and "answer") contains multiple BUNDLE groups, the 206 procedures in this specification apply to each group independently. 207 All RTP-based bundled media associated with a given BUNDLE group 208 belong to a single RTP session [RFC3550]. 210 The BUNDLE extension is backward compatible. Endpoints that do not 211 support the extension are expected to generate offers and answers 212 without an SDP 'group:BUNDLE' attribute and assign a unique 213 address:port to each "m=" section within an offer and answer, 214 according to the procedures in [RFC3264] and [RFC4566]. 216 1.3. Protocol Extensions 218 In addition to defining the new SDP Grouping Framework extension, 219 this specification defines the following protocol extensions and RFC 220 updates. This specification: 222 * defines a new SDP attribute, 'bundle-only', which can be used to 223 request that a specific "m=" section (and the associated media) be 224 used only if kept within a BUNDLE group. 226 * updates RFC 3264 [RFC3264], to also allow assigning a zero port 227 value to an "m=" section in cases where the media described by the 228 "m=" section is not disabled or rejected. 230 * defines a new RTCP [RFC3550] SDES item, 'MID', and a new RTP SDES 231 header extension that can be used to associate RTP streams with 232 "m=" sections. 234 * updates [RFC7941] by adding an exception, for the MID RTP header 235 extension, to the requirement regarding protection of an SDES RTP 236 header extension carrying an SDES item for the MID RTP header 237 extension. 239 1.4. Changes from RFC 8843 241 When RFC 8843 and [RFC8829] were published an inconsistency between 242 the specifications was identified. The procedures regarding 243 assigning the port value to a bundled "m=" section in an answer 244 (initial or subsequent) and a subsequent offer were inconsistent. At 245 the IETF 110 meeting it was agreed to publish new versions of the 246 RFCs, in which the inconsistency is removed. This specification 247 removes the inconsistency by aligning the port value assignment 248 procedure with the procedure in RFC 8829. 250 In addition, this document implements the following erratas: 6431, 251 6437 253 2. Terminology 255 "m=" section: SDP bodies contain one or more media descriptions, 256 referred to as "m=" sections. Each "m=" section is represented 257 by an SDP "m=" line and zero or more SDP attributes associated 258 with the "m=" line. A local address:port combination is 259 assigned to each "m=" section. 261 5-tuple: A collection of the following values: source address, 262 source port, destination address, destination port, and 263 transport-layer protocol. 265 Unique address:port: An address:port combination that is assigned 266 to only one "m=" section in an offer or answer. 268 Offerer BUNDLE-tag: The first identification-tag in a given SDP 269 'group:BUNDLE' attribute identification-tag list in an offer. 271 Answerer BUNDLE-tag: The first identification-tag in a given SDP 272 'group:BUNDLE' attribute identification-tag list in an answer. 274 Suggested offerer-tagged "m=" section: The bundled "m=" section 275 identified by the offerer BUNDLE-tag in an initial BUNDLE 276 offer, before a BUNDLE group has been negotiated. 278 Offerer-tagged "m=" section: The bundled "m=" section identified 279 by the offerer BUNDLE-tag in a subsequent offer. The "m=" 280 section contains characteristics (offerer BUNDLE address:port 281 and offerer BUNDLE attributes) that are applied to each "m=" 282 section within the BUNDLE group. 284 Answerer-tagged "m=" section: The bundled "m=" section identified 285 by the answerer BUNDLE-tag in an answer (initial BUNDLE answer 286 or subsequent). The "m=" section contains characteristics 287 (answerer BUNDLE address:port and answerer BUNDLE attributes) 288 that are applied to each "m=" section within the BUNDLE group. 290 BUNDLE address:port: An address:port combination that an endpoint 291 uses for sending and receiving bundled media. 293 Offerer BUNDLE address:port: The address:port combination used by 294 the offerer for sending and receiving media. 296 Answerer BUNDLE address:port: The address:port combination used 297 by the answerer for sending and receiving media. 299 BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category 300 SDP attributes. Once a BUNDLE group has been created, the 301 attribute values apply to each bundled "m=" section within the 302 BUNDLE group. 304 Offerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing 305 category SDP attributes included in the offerer-tagged "m=" 306 section. 308 Answerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing 309 category SDP attributes included in the answerer-tagged "m=" 310 section. 312 BUNDLE transport: The transport (5-tuple) used by all media 313 described by the "m=" sections within a BUNDLE group. 315 BUNDLE group: A set of bundled "m=" sections, created using an 316 SDP offer/answer exchange, that uses a single BUNDLE transport, 317 and a single set of BUNDLE attributes, for sending and 318 receiving all media (bundled media) described by the set of 319 "m=" sections. The same BUNDLE transport is used for sending 320 and receiving bundled media. 322 Bundled "m=" section: An "m=" section, whose identification-tag 323 is placed in an SDP 'group:BUNDLE' attribute identification-tag 324 list in an offer or answer. 326 Bundle-only "m=" section: A bundled "m=" section that contains an 327 SDP 'bundle-only' attribute. 329 Bundled media: All media associated with a given BUNDLE group. 331 Initial BUNDLE offer: The first offer, within an SDP session 332 (e.g., a SIP dialog when SIP [RFC3261] is used to carry SDP), 333 in which the offerer indicates that it wants to negotiate a 334 given BUNDLE group. 336 Initial BUNDLE answer: The answer to an initial BUNDLE offer in 337 which the offerer indicates that it wants to negotiate a BUNDLE 338 group, and the answerer accepts the creation of the BUNDLE 339 group. The BUNDLE group is created once the answerer sends the 340 initial BUNDLE answer. 342 Subsequent offer: An offer that contains a BUNDLE group that has 343 been created as part of a previous offer/answer exchange. 345 Subsequent answer: An answer to a subsequent offer. 347 Identification-tag: A unique token value that is used to identify 348 an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" 349 section carries the unique identification-tag assigned to that 350 "m=" section. The session-level SDP 'group' attribute 351 [RFC5888] carries a list of identification-tags, identifying 352 the "m=" sections associated with that particular 'group' 353 attribute. 355 3. Conventions 357 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 358 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 359 "OPTIONAL" in this document are to be interpreted as described in 360 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 361 capitals, as shown here. 363 4. Applicability Statement 365 The mechanism in this specification only applies to SDP [RFC4566], 366 when used together with the SDP offer/answer mechanism [RFC3264]. 367 Declarative usage of SDP is out of scope of this document and is thus 368 undefined. 370 5. SDP Grouping Framework BUNDLE Extension 372 This section defines a new SDP Grouping Framework [RFC5888] 373 extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP 374 offer/answer mechanism to negotiate a set of "m=" sections that will 375 become part of a BUNDLE group. Within a BUNDLE group, each "m=" 376 section uses a BUNDLE transport for sending and receiving bundled 377 media. Each endpoint uses a single address:port combination for 378 sending and receiving the bundled media. 380 The BUNDLE extension is indicated using an SDP 'group' attribute with 381 a semantics value [RFC5888] of "BUNDLE". An identification-tag is 382 assigned to each bundled "m=" section, and each identification-tag is 383 listed in the SDP 'group:BUNDLE' attribute identification-tag list. 384 Each "m=" section whose identification-tag is listed in the 385 identification-tag list is associated with a given BUNDLE group. 387 SDP bodies can contain multiple BUNDLE groups. Any given bundled 388 "m=" section MUST NOT be associated with more than one BUNDLE group 389 at any given time. 391 NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' 392 attribute identification-tag list does not have to be the same as the 393 order in which the "m=" sections occur in the SDP. 395 The multiplexing category [RFC8859] for the 'group:BUNDLE' attribute 396 is 'NORMAL'. 398 Section 7 defines the detailed SDP offer/answer procedures for the 399 BUNDLE extension. 401 6. SDP 'bundle-only' Attribute 403 This section defines a new SDP media-level attribute [RFC4566], 404 'bundle-only'. 'bundle-only' is a property attribute [RFC4566] and 405 hence has no value. 407 In order to ensure that an answerer that does not support the BUNDLE 408 extension always rejects a bundled "m=" section in an offer, the 409 offerer can assign a zero port value to the "m=" section. According 410 to [RFC3264], an answerer will reject such an "m=" section. By 411 including an SDP 'bundle-only' attribute in a bundled "m=" section, 412 the offerer can request that the answerer accepts the "m=" section 413 only if the answerer supports the BUNDLE extension and if the 414 answerer keeps the "m=" section within the associated BUNDLE group. 416 Name: bundle-only 418 Value: N/A 420 Usage Level: media 422 Charset Dependent: no 424 Example: a=bundle-only 426 The usage of the 'bundle-only' attribute is only defined for a 427 bundled "m=" section with a zero port value. Other usage is 428 unspecified. If an offerer or answerer receives a 'bundle-only' 429 attribute in a non-bundled "m=" section the offerer or answerer MUST 430 discard the attribute. 432 Section 7 defines the detailed SDP offer/answer procedures for the 433 'bundle-only' attribute. 435 7. SDP Offer/Answer Procedures 437 This section describes the SDP offer/answer [RFC3264] procedures for: 439 * Negotiating a BUNDLE group; 441 * Suggesting and selecting the tagged "m=" sections (offerer-tagged 442 "m=" section and answerer-tagged "m=" section); 444 * Adding an "m=" section to a BUNDLE group; 446 * Moving an "m=" section out of a BUNDLE group; and 448 * Disabling an "m=" section within a BUNDLE group. 450 The generic rules and procedures defined in [RFC3264] and [RFC5888] 451 also apply to the BUNDLE extension. For example, if an offer is 452 rejected by the answerer, the previously negotiated addresses:ports, 453 SDP parameters, and characteristics (including those associated with 454 a BUNDLE group) apply. Hence, if an offerer generates an offer in 455 order to negotiate a BUNDLE group, and the answerer rejects the 456 offer, the BUNDLE group is not created. 458 The procedures in this section are independent of the media type or 459 "m=" line proto value assigned to a bundled "m=" section. Section 6 460 defines additional considerations for the usage of the SDP 'bundle- 461 only' attribute. Section 9 defines additional considerations for 462 RTP-based media. Section 10 defines additional considerations for 463 the usage of the ICE [RFC8445] mechanism. 465 Offers and answers can contain multiple BUNDLE groups. The 466 procedures in this section apply independently to a given BUNDLE 467 group. 469 7.1. Generic SDP Considerations 471 This section describes generic restrictions associated with the usage 472 of SDP parameters within a BUNDLE group. It also describes how to 473 calculate a value for the whole BUNDLE group, when parameter and 474 attribute values have been assigned to each bundled "m=" section. 476 7.1.1. Connection Data ("c=") 478 The "c=" line nettype value [RFC4566] associated with a bundled "m=" 479 section MUST be 'IN'. 481 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" 482 section MUST be 'IP4' or 'IP6'. The same value MUST be associated 483 with each "m=" section. 485 NOTE: Extensions to this specification can specify usage of the 486 BUNDLE mechanism for other nettype and addrtype values than the ones 487 listed above. 489 7.1.2. Bandwidth ("b=") 491 An offerer and answerer MUST use the rules and restrictions defined 492 in [RFC8859] for associating the SDP bandwidth ("b=") line with 493 bundled "m=" sections. 495 7.1.3. Attributes ("a=") 497 An offerer and answerer MUST include SDP attributes in every bundled 498 "m=" section where applicable, following the normal offer/answer 499 procedures for each attribute, with the following exceptions: 501 * In the initial BUNDLE offer, the offerer MUST NOT include 502 IDENTICAL and TRANSPORT multiplexing category SDP attributes 503 (BUNDLE attributes) in bundle-only "m=" sections. The offerer 504 MUST include such attributes in all other bundled "m=" sections. 505 In the initial BUNDLE offer, each bundled "m=" line can contain a 506 different set of BUNDLE attributes and attribute values. Once the 507 offerer-tagged "m=" section has been selected, the BUNDLE 508 attributes contained in the offerer-tagged "m=" section will apply 509 to each bundled "m=" section within the BUNDLE group. 511 * In a subsequent offer, or in an answer (initial of subsequent), 512 the offerer and answerer MUST include IDENTICAL and TRANSPORT 513 multiplexing category SDP attributes (BUNDLE attributes) only in 514 the tagged "m=" section (offerer-tagged "m=" section or answerer- 515 tagged "m=" section). The offerer and answerer MUST NOT include 516 such attributes in any other bundled "m=" section. The BUNDLE 517 attributes contained in the tagged "m=" section will apply to each 518 bundled "m=" section within the BUNDLE group. 520 * In an offer (initial BUNDLE offer or subsequent), or in an answer 521 (initial BUNDLE answer or subsequent), the offerer and answerer 522 MUST include SDP attributes from categories other than IDENTICAL 523 and TRANSPORT in each bundled "m=" section that a given attribute 524 applies to. Each bundled "m=" line can contain a different set of 525 such attributes, and attribute values, as such attributes only 526 apply to the given bundled "m=" section in which they are 527 included. 529 NOTE: A consequence of the rules above is that media-specific 530 IDENTICAL and TRANSPORT multiplexing category SDP attributes that are 531 applicable only to some of the bundled "m=" sections within the 532 BUNDLE group might appear in the tagged "m=" section for which they 533 are not applicable. For instance, the tagged "m=" section might 534 contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section 535 does not describe RTP-based media (but another bundled "m=" section 536 within the BUNDLE group does describe RTP-based media). 538 7.2. Generating the Initial SDP Offer 540 The procedures in this section apply to the first offer, within an 541 SDP session (e.g., a SIP dialog when SIP [RFC3261] is used to carry 542 SDP), in which the offerer indicates that it wants to negotiate a 543 given BUNDLE group. This could occur in the initial offer, or in a 544 subsequent offer, of the SDP session. 546 When an offerer generates an initial BUNDLE offer, in order to 547 negotiate a BUNDLE group, it MUST: 549 * Assign a unique address:port to each bundled "m=" section, 550 following the procedures in [RFC3264], excluding any bundle-only 551 "m=" sections (see below); 553 * Pick a bundled "m=" section as the suggested offerer-tagged "m=" 554 (Section 7.2.1); 556 * Include SDP attributes in the bundled "m=" sections following the 557 rules in Section 7.1.3; 559 * Include an SDP 'group:BUNDLE' attribute in the offer; and 561 * Place the identification-tag of each bundled "m=" section in the 562 SDP 'group:BUNDLE' attribute identification-tag list. The offerer 563 BUNDLE-tag indicates the suggested offerer-tagged "m=" section. 565 NOTE: When the offerer assigns unique addresses:ports to multiple 566 bundled "m=" sections, the offerer needs to be prepared to receive 567 bundled media on each unique address:port, until it receives the 568 associated answer and finds out which bundled "m=" section (and 569 associated address:port combination) the answerer has selected as the 570 offerer-tagged "m=" section. 572 If the offerer wants to request that the answerer accepts a given 573 bundled "m=" section only if the answerer keeps the "m=" section 574 within the negotiated BUNDLE group, the offerer MUST: 576 * Include an SDP 'bundle-only' attribute (Section 7.2.1) in the "m=" 577 section, and 579 * Assign a zero port value to the "m=" section. 581 NOTE: If the offerer assigns a zero port value to a bundled "m=" 582 section, but does not include an SDP 'bundle-only' attribute in the 583 "m=" section, it is an indication that the offerer wants to disable 584 the "m=" section (Section 7.5.3). 586 Sections 7.2.2 and 18.1 show an example of an initial BUNDLE offer. 588 7.2.1. Suggesting the Offerer-Tagged 'm=' Section 590 In the initial BUNDLE offer, the bundled "m=" section indicated by 591 the offerer BUNDLE-tag is the suggested offerer-tagged "m=" section. 592 The address:port combination associated with the "m=" section will be 593 used by the offerer for sending and receiving bundled media if the 594 answerer selects the "m=" section as the offerer-tagged "m=" section 595 (Section 7.3.1). In addition, if the answerer selects the "m=" 596 section as the offerer-tagged "m=" section, the BUNDLE attributes 597 included in the "m=" section will be applied to each "m=" section 598 within the negotiated BUNDLE group. 600 The offerer MUST NOT suggest a bundle-only "m=" section as the 601 offerer-tagged "m=" section. 603 It is RECOMMENDED that the suggested offerer-tagged "m=" section be a 604 bundled "m=" section that the offerer believes is unlikely that the 605 answerer will reject or move out of the BUNDLE group. How such 606 assumption is made is outside the scope of this document. 608 7.2.2. Example: Initial SDP Offer 610 The example shows an initial BUNDLE offer. The offer includes two 611 "m=" sections in the offer and suggests that both "m=" sections are 612 included in a BUNDLE group. The audio "m=" section is the suggested 613 offerer-tagged "m=" section, indicated by placing the identification- 614 tag associated with the "m=" section (offerer BUNDLE-tag) first in 615 the SDP group:BUNDLE attribute identification-id list. 617 SDP Offer 619 v=0 620 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 621 s= 622 c=IN IP6 2001:db8::3 623 t=0 0 624 a=group:BUNDLE foo bar 626 m=audio 10000 RTP/AVP 0 8 97 627 b=AS:200 628 a=mid:foo 629 a=rtcp-mux 630 a=rtpmap:0 PCMU/8000 631 a=rtpmap:8 PCMA/8000 632 a=rtpmap:97 iLBC/8000 633 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 635 m=video 10002 RTP/AVP 31 32 636 b=AS:1000 637 a=mid:bar 638 a=rtcp-mux 639 a=rtpmap:31 H261/90000 640 a=rtpmap:32 MPV/90000 641 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 643 7.3. Generating the SDP Answer 645 When an answerer generates an answer (initial BUNDLE answer or 646 subsequent) that contains a BUNDLE group, the following general SDP 647 Grouping Framework restrictions, defined in [RFC5888], also apply to 648 the BUNDLE group: 650 * The answerer is only allowed to include a BUNDLE group in an 651 initial BUNDLE answer if the offerer requested the BUNDLE group to 652 be created in the corresponding initial BUNDLE offer; 654 * The answerer is only allowed to include a BUNDLE group in a 655 subsequent answer if the corresponding subsequent offer contains a 656 previously negotiated BUNDLE group; 658 * The answerer is only allowed to include a bundled "m=" section in 659 an answer if the "m=" section was indicated as bundled in the 660 corresponding offer; and 662 * The answerer is only allowed to include a bundled "m=" section in 663 the same BUNDLE group as the bundled "m=" line in the 664 corresponding offer. 666 In addition, when an answerer generates an answer (initial BUNDLE 667 answer or subsequent) that contains a BUNDLE group, the answerer 668 MUST: 670 * In case of an initial BUNDLE answer, select the offerer-tagged 671 "m=" section using the procedures in Section 7.3.1. In case of a 672 subsequent answer, the offerer-tagged "m=" section is indicated in 673 the corresponding subsequent offer and MUST NOT be changed by the 674 answerer; 676 * Select the answerer-tagged "m=" section (Section 7.3.1); 678 * Assign the answerer BUNDLE address:port to the answerer-tagged 679 "m=" section, and to every other bundled "m=" section within the 680 BUNDLE group; 682 * Include SDP attributes in the bundled "m=" sections following the 683 rules in Section 7.1.3; 685 * Include an SDP 'group:BUNDLE' attribute in the answer; and 687 * Place the identification-tag of each bundled "m=" section in the 688 SDP 'group:BUNDLE' attribute identification-tag list. The 689 answerer BUNDLE-tag indicates the answerer-tagged "m=" section 690 (Section 7.3.1). 692 If the answerer does not want to keep an "m=" section within a BUNDLE 693 group, it MUST: 695 * Move the "m=" section out of the BUNDLE group (Section 7.3.2); or 697 * Reject the "m=" section (Section 7.3.3). 699 The answerer can modify the answerer BUNDLE address:port, add and 700 remove SDP attributes, or modify SDP attribute values in a subsequent 701 answer. Changes to the answerer BUNDLE address:port and the answerer 702 BUNDLE attributes will be applied to each bundled "m=" section within 703 the BUNDLE group. 705 NOTE: If a bundled "m=" section in an offer contains a zero port 706 value, but the "m=" section does not contain an SDP 'bundle-only' 707 attribute, it is an indication that the offerer wants to disable the 708 "m=" section (Section 7.5.3). 710 7.3.1. Answerer Selection of Tagged 'm=' Sections 712 When selecting the offerer-tagged "m=" section, the answerer MUST 713 first check whether the "m=" section fulfills the following criteria 714 Section 7.2.1: 716 * The answerer will not move the "m=" section out of the BUNDLE 717 group (Section 7.3.2); 719 * The answerer will not reject the "m=" section (Section 7.3.3); and 721 * The "m=" section does not contain a zero port value. 723 If all of the criteria above are fulfilled, the answerer MUST select 724 the "m=" section as the offerer-tagged "m=" section and MUST also 725 mark the corresponding "m=" section in the answer as the answerer- 726 tagged "m=" section. In the answer, the answerer BUNDLE-tag 727 indicates the answerer-tagged "m=" section. 729 If one or more of the criteria are not fulfilled, the answerer MUST 730 pick the next identification-tag in the identification-tag list in 731 the offer and perform the same criteria check for the "m=" section 732 indicated by that identification-tag. If there are no more 733 identification-tags in the identification-tag list, the answerer MUST 734 NOT create the BUNDLE group. Unless the answerer rejects the whole 735 offer, the answerer MUST apply the answerer procedures for moving an 736 "m=" section out of a BUNDLE group (Section 7.3.2) or rejecting an 737 "m=" section within a BUNDLE group (Section 7.3.3) to every bundled 738 "m=" section in the offer when creating the answer. 740 Section 18.1 shows an example of an offerer BUNDLE address:port 741 selection. 743 Sections 7.3.4 and 18.1 show an example of an answerer-tagged "m=" 744 section selection. 746 7.3.2. Moving a Media Description Out of a BUNDLE Group 748 When an answerer generates the answer, if the answerer wants to move 749 a bundled "m=" section out of the negotiated BUNDLE group, the 750 answerer MUST first check the following criteria: 752 * In the corresponding offer, the "m=" section is within a 753 previously negotiated BUNDLE group, and 755 * In the corresponding offer, the "m=" section contains an SDP 756 'bundle-only' attribute. 758 If either criterion above is fulfilled, the answerer cannot move the 759 "m=" section out of the BUNDLE group in the answer. The answerer can 760 reject the whole offer, reject each bundled "m=" section within the 761 BUNDLE group (Section 7.3.3), or keep the "m=" section within the 762 BUNDLE group in the answer and later create an offer where the "m=" 763 section is moved out of the BUNDLE group (Section 7.5.2). 765 NOTE: One consequence of the rules above is that, once a BUNDLE group 766 has been negotiated, a bundled "m=" section cannot be moved out of 767 the BUNDLE group in an answer. Instead, an offer is needed. 769 When the answerer generates an answer, in which it moves a bundled 770 "m=" section out of a BUNDLE group, the answerer: 772 * MUST assign a unique address:port to the "m=" section; 774 * MUST include any applicable SDP attribute in the "m=" section, 775 using the normal offer/answer procedures for each attribute; 777 * MUST NOT place the identification-tag associated with the "m=" 778 section in the SDP 'group:BUNDLE' attribute identification-tag 779 list associated with the BUNDLE group; and 781 * MUST NOT include an SDP 'bundle-only' attribute to the "m=" 782 section. 784 Because an answerer is not allowed to move an "m=" section from one 785 BUNDLE group to another within an answer (Section 7.3), if the 786 answerer wants to move an "m=" section from one BUNDLE group to 787 another, it MUST first move the "m=" section out of the current 788 BUNDLE group and then generate an offer where the "m=" section is 789 added to another BUNDLE group (Section 7.5.1). 791 7.3.3. Rejecting a Media Description in a BUNDLE Group 793 When an answerer wants to reject a bundled "m=" section in an answer, 794 it MUST first check the following criterion: 796 * In the corresponding offer, the "m=" section is the offerer-tagged 797 "m=" section. 799 If the criterion above is fulfilled, the answerer cannot reject the 800 "m=" section in the answer. The answerer can reject the whole offer, 801 reject each bundled "m=" section within the BUNDLE group, or keep the 802 "m=" section within the BUNDLE group in the answer and later create 803 an offer where the "m=" section is disabled within the BUNDLE group 804 (Section 7.5.3). 806 When an answerer generates an answer, in which it rejects a bundled 807 "m=" section, the answerer: 809 * MUST assign a zero port value to the "m=" section, according to 810 the procedures in [RFC3264]; 812 * MUST NOT place the identification-tag associated with the "m=" 813 section in the SDP 'group:BUNDLE' attribute identification-tag 814 list associated with the BUNDLE group; and 816 * MUST NOT include an SDP 'bundle-only' attribute in the "m=" 817 section. 819 7.3.4. Example: SDP Answer 821 The example below shows an answer, based on the corresponding offer 822 in Section 7.2.2. The answerer accepts both bundled "m=" sections 823 within the created BUNDLE group. The audio "m=" section is the 824 answerer-tagged "m=" section, indicated by placing the 825 identification-tag associated with the "m=" section (answerer BUNDLE- 826 tag) first in the SDP group;BUNDLE attribute identification-id list. 828 SDP Answer 829 v=0 830 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 831 s= 832 c=IN IP6 2001:db8::1 833 t=0 0 834 a=group:BUNDLE foo bar 836 m=audio 20000 RTP/AVP 0 837 b=AS:200 838 a=mid:foo 839 a=rtcp-mux 840 a=rtpmap:0 PCMU/8000 841 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 843 m=video 20000 RTP/AVP 32 844 b=AS:1000 845 a=mid:bar 846 a=rtpmap:32 MPV/90000 847 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 849 7.3.5. RFC 8843 Considerations 851 In RFC 8843, instead of assigning the offerer BUNDLE address:port to 852 each "m=" section within the BUNDLE group when modifying the session 853 (Section 7.5), the offerer only assigned the offerer BUNDLE 854 address:port to the offerer-tagged "m=" section. For every other 855 "m=" section within the BUNDLE group, the offerer included an SDP 856 'bundle-only' attribute in, and assigned a zero port value to, the 857 "m=" section. In order to be backward compatible with offerers that 858 implement RFC 8843, an answerer SHOULD accept such offers. The 859 example below shows such offer: 861 SDP Offer 862 v=0 863 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 864 s= 865 c=IN IP6 2001:db8::3 866 t=0 0 867 a=group:BUNDLE foo bar 869 m=audio 10000 RTP/AVP 0 8 97 870 b=AS:200 871 a=mid:foo 872 a=rtcp-mux 873 a=rtpmap:0 PCMU/8000 874 a=rtpmap:8 PCMA/8000 875 a=rtpmap:97 iLBC/8000 876 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 878 m=video 0 RTP/AVP 31 32 879 b=AS:1000 880 a=mid:bar 881 a=bundle-only 882 a=rtpmap:31 H261/90000 883 a=rtpmap:32 MPV/90000 884 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 886 7.4. Offerer Processing of the SDP Answer 888 When an offerer receives an answer, if the answer contains a BUNDLE 889 group, the offerer MUST check that any bundled "m=" section in the 890 answer was indicated as bundled in the corresponding offer. If there 891 is no mismatch, the offerer MUST apply the properties (BUNDLE 892 address:port, BUNDLE attributes, etc.) of the offerer-tagged "m=" 893 section (selected by the answerer; see Section 7.3.1) to each bundled 894 "m=" section within the BUNDLE group. 896 NOTE: As the answerer might reject one or more bundled "m=" sections 897 in an initial BUNDLE offer, or move a bundled "m=" section out of a 898 BUNDLE group, a given bundled "m=" section in the offer might not be 899 indicated as bundled in the corresponding answer. 901 If the answer does not contain a BUNDLE group, the offerer MUST 902 process the answer as a normal answer. 904 7.4.1. RFC 8843 Considerations 906 In RFC 8843, instead of assigning the answerer BUNDLE address:port to 907 each "m=" section within the BUNDLE group when generating the answer 908 (Section 7.3), the answerer only assigned the answerer BUNDLE 909 address:port to the answerer-tagged "m=" section. For every other 910 "m=" section within the BUNDLE group, the answerer included an SDP 911 'bundle-only' attribute in, and assigned a zero port value to, the 912 "m=" section. In order to be backward compatible with answerers that 913 implement RFC 8843, an offerer SHOULD accept such answers. The 914 example below shows such answer: 916 SDP Answer 918 v=0 919 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 920 s= 921 c=IN IP6 2001:db8::1 922 t=0 0 923 a=group:BUNDLE foo bar 925 m=audio 20000 RTP/AVP 0 926 b=AS:200 927 a=mid:foo 928 a=rtcp-mux 929 a=rtpmap:0 PCMU/8000 930 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 932 m=video 0 RTP/AVP 32 933 b=AS:1000 934 a=mid:bar 935 a=bundle-only 936 a=rtpmap:32 MPV/90000 937 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 939 7.5. Modifying the Session 941 When a BUNDLE group has been previously negotiated, and an offerer 942 generates a subsequent offer, the offerer MUST: 944 * Pick one bundled "m=" section as the offerer-tagged "m=" section. 945 The offerer can pick either the "m=" section that was previously 946 selected by the answerer as the offerer-tagged "m=" section or 947 another bundled "m=" section within the BUNDLE group; 949 * Assign a BUNDLE address:port (previously negotiated or newly 950 suggested) to the offerer-tagged "m=" section, and to every other 951 bundled "m=" section within the BUNDLE group; 953 * Include SDP attributes in the bundled "m=" sections following the 954 rules in Section 7.1.3; 956 * Include an SDP 'group:BUNDLE' attribute in the offer; and 958 * Place the identification-tag of each bundled "m=" section in the 959 SDP 'group:BUNDLE' attribute identification-tag list. The offerer 960 BUNDLE-tag indicates the offerer-tagged "m=" section. 962 The offerer MUST NOT pick a given bundled "m=" section as the 963 offerer-tagged "m=" section if: 965 * The offerer wants to move the "m=" section out of the BUNDLE group 966 (Section 7.5.2), or 968 * The offerer wants to disable the "m=" section (Section 7.5.3). 970 The offerer can modify the offerer BUNDLE address:port, add and 971 remove SDP attributes, or modify SDP attribute values in the 972 subsequent offer. Changes to the offerer BUNDLE address:port and the 973 offerer BUNDLE attributes will (if the offer is accepted by the 974 answerer) be applied to each bundled "m=" section within the BUNDLE 975 group. 977 7.5.1. Adding a Media Description to a BUNDLE Group 979 When an offerer generates a subsequent offer, in which it wants to 980 add a bundled "m=" section to a previously negotiated BUNDLE group, 981 the offerer follows the procedures in Section 7.5. The offerer picks 982 either the added "m=" section or an "m=" section previously added to 983 the BUNDLE group as the offerer-tagged "m=" section. 985 NOTE: As described in Section 7.3.2, the answerer cannot move the 986 added "m=" section out of the BUNDLE group in its answer. If the 987 answer wants to move the "m=" section out of the BUNDLE group, it 988 will have to first accept it into the BUNDLE group in the answer, and 989 then send a subsequent offer where the "m=" section is moved out of 990 the BUNDLE group (Section 7.5.2). 992 7.5.2. Moving a Media Description Out of a BUNDLE Group 994 When an offerer generates a subsequent offer, in which it wants to 995 remove a bundled "m=" section from a BUNDLE group, the offerer: 997 * MUST assign a unique address:port to the "m=" section; 999 * MUST include SDP attributes in the "m=" section following the 1000 normal offer/answer rules for each attribute; 1002 * MUST NOT place the identification-tag associated with the "m=" 1003 section in the SDP 'group:BUNDLE' attribute identification-tag 1004 list associated with the BUNDLE group; and 1006 * MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 1007 section. 1009 For the other bundled "m=" sections within the BUNDLE group, the 1010 offerer follows the procedures in Section 7.5. 1012 An offerer MUST NOT move an "m=" section from one BUNDLE group to 1013 another within a single offer. If the offerer wants to move an "m=" 1014 section from one BUNDLE group to another, it MUST first move the 1015 BUNDLE group out of the current BUNDLE group, and then generate a 1016 second offer where the "m=" section is added to another BUNDLE group 1017 (Section 7.5.1). 1019 Section 18.4 shows an example of an offer for moving an "m=" section 1020 out of a BUNDLE group. 1022 7.5.3. Disabling a Media Description in a BUNDLE Group 1024 When an offerer generates a subsequent offer, in which it wants to 1025 disable a bundled "m=" section from a BUNDLE group, the offerer: 1027 * MUST assign a zero port value to the "m=" section, following the 1028 procedures in [RFC4566]; 1030 * MUST NOT place the identification-tag associated with the "m=" 1031 section in the SDP 'group:BUNDLE' attribute identification-tag 1032 list associated with the BUNDLE group; and 1034 * MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 1035 section. 1037 For the other bundled "m=" sections within the BUNDLE group, the 1038 offerer follows the procedures in Section 7.5. 1040 Section 18.5 shows an example of an offer and answer for disabling an 1041 "m=" section within a BUNDLE group. 1043 8. Protocol Identification 1045 Each "m=" section within a BUNDLE group MUST use the same transport- 1046 layer protocol. If bundled "m=" sections use different upper-layer 1047 protocols on top of the transport-layer protocol, there MUST exist a 1048 publicly available specification that describes how a mechanism 1049 associates received data with the correct protocol for this 1050 particular protocol combination. 1052 In addition, if received data can be associated with more than one 1053 bundled "m=" section, there MUST exist a publicly available 1054 specification that describes a mechanism for associating the received 1055 data with the correct "m=" section. 1057 This document describes a mechanism to identify the protocol of 1058 received data among the Session Traversal Utilities for NAT (STUN), 1059 DTLS, and the Secure Real-time Transport Protocol (SRTP) (in any 1060 combination) when UDP is used as a transport-layer protocol, but it 1061 does not describe how to identify different protocols transported on 1062 DTLS. While the mechanism is generally applicable to other protocols 1063 and transport-layer protocols, any such use requires further 1064 specification that encompasses how to multiplex multiple protocols on 1065 a given transport-layer protocol and how to associate received data 1066 with the correct protocols. 1068 8.1. STUN, DTLS, and SRTP 1070 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 1071 protocol of a received packet among the STUN, DTLS, and SRTP 1072 protocols (in any combination). If an offer or answer includes a 1073 bundled "m=" section that represents these protocols, the offerer or 1074 answerer MUST support the mechanism described in [RFC5764], and no 1075 explicit negotiation is required in order to indicate support and 1076 usage of the mechanism. 1078 [RFC5764] does not describe how to identify different protocols 1079 transported on DTLS, only how to identify the DTLS protocol itself. 1080 If multiple protocols are transported on DTLS, there MUST exist a 1081 specification describing a mechanism for identifying each individual 1082 protocol. In addition, if a received DTLS packet can be associated 1083 with more than one "m=" section, there MUST exist a specification 1084 that describes a mechanism for associating the received DTLS packets 1085 with the correct "m=" section. 1087 Section 9.2 describes how to associate the packets in a received SRTP 1088 stream with the correct "m=" section. 1090 9. RTP Considerations 1092 9.1. Single RTP Session 1094 All RTP-based media within a single BUNDLE group belong to a single 1095 RTP session [RFC3550]. 1097 Since a single BUNDLE transport is used for sending and receiving 1098 bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for 1099 RTP-based bundled media. 1101 Since a single RTP session is used for each BUNDLE group, all "m=" 1102 sections representing RTP-based media within a BUNDLE group will 1103 share a single Synchronization Source (SSRC) numbering space 1104 [RFC3550]. 1106 The following rules and restrictions apply for a single RTP session: 1108 * A specific payload type value can be used in multiple bundled "m=" 1109 sections only if each codec associated with the payload type 1110 number shares an identical codec configuration (Section 9.1.1). 1112 * The proto value in each bundled RTP-based "m=" section MUST be 1113 identical (e.g., RTP/AVPF). 1115 * The RTP MID header extension MUST be enabled, by including an SDP 1116 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 1117 hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section 1118 in every offer and answer. 1120 * A given SSRC MUST NOT transmit RTP packets using payload types 1121 that originate from different bundled "m=" sections. 1123 NOTE: The last bullet above is to avoid sending multiple media types 1124 from the same SSRC. If transmission of multiple media types are done 1125 with time overlap, RTP and RTCP fail to function. Even if done in 1126 proper sequence, this causes RTP timestamp rate switching issues 1127 [RFC7160]. However, once an SSRC has left the RTP session (by 1128 sending an RTCP BYE packet), that SSRC can be reused by another 1129 source (possibly associated with a different bundled "m=" section) 1130 after a delay of 5 RTCP reporting intervals (the delay is to ensure 1131 the SSRC has timed out, in case the RTCP BYE packet was lost 1132 [RFC3550]). 1134 [RFC7657] defines Differentiated Services (Diffserv) considerations 1135 for RTP-based bundled media sent using a mixture of Diffserv 1136 Codepoints. 1138 9.1.1. Payload Type (PT) Value Reuse 1140 Multiple bundled "m=" sections might describe RTP-based media. As 1141 all RTP-based media associated with a BUNDLE group belong to the same 1142 RTP session, in order for a given payload type value to be used 1143 inside more than one bundled "m=" section, all codecs associated with 1144 the payload type number MUST share an identical codec configuration. 1145 This means that the codecs MUST share the same media type, encoding 1146 name, clock rate, and any parameter that can affect the codec 1147 configuration and packetization. [RFC8859] lists SDP attributes, 1148 whose attribute values are required to be identical for all codecs 1149 that use the same payload type value. 1151 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 1152 Description 1154 As described in [RFC3550], RTP packets are associated with RTP 1155 streams [RFC7656]. Each RTP stream is identified by an SSRC value, 1156 and each RTP packet includes an SSRC field that is used to associate 1157 the packet with the correct RTP stream. RTCP packets also use SSRCs 1158 to identify which RTP streams the packet relates to. However, an 1159 RTCP packet can contain multiple SSRC fields, in the course of 1160 providing feedback or reports on different RTP streams, and therefore 1161 can be associated with multiple such streams. 1163 In order to be able to process received RTP/RTCP packets correctly, 1164 it MUST be possible to associate an RTP stream with the correct "m=" 1165 section, as the "m=" section and SDP attributes associated with the 1166 "m=" section contains information needed to process the packets. 1168 As all RTP streams associated with a BUNDLE group use the same 1169 transport for sending and receiving RTP/RTCP packets, the local 1170 address:port combination part of the transport cannot be used to 1171 associate an RTP stream with the correct "m=" section. In addition, 1172 multiple RTP streams might be associated with the same "m=" section. 1174 An offerer and answerer can inform each other which SSRC values they 1175 will use for an RTP stream by using the SDP 'ssrc' attribute 1176 [RFC5576]. However, an offerer will not know which SSRC values the 1177 answerer will use until the offerer has received the answer providing 1178 that information. Due to this, before the offerer has received the 1179 answer, the offerer will not be able to associate an RTP stream with 1180 the correct "m=" section using the SSRC value associated with the RTP 1181 stream. In addition, the offerer and answerer may start using new 1182 SSRC values mid-session, without informing each other about using the 1183 SDP 'ssrc' attribute. 1185 In order for an offerer and answerer to always be able to associate 1186 an RTP stream with the correct "m=" section, the offerer and answerer 1187 using the BUNDLE extension MUST support the mechanism defined in 1188 Section 15, where the offerer and answerer insert the identification- 1189 tag associated with an "m=" section (provided by the remote peer) 1190 into RTP and RTCP packets associated with a BUNDLE group. 1192 When using this mechanism, the mapping from an SSRC to an 1193 identification-tag is carried in RTP header extensions or RTCP SDES 1194 packets, as specified in Section 15. Since a compound RTCP packet 1195 can contain multiple RTCP SDES packets, and each RTCP SDES packet can 1196 contain multiple chunks, a single RTCP packet can contain several 1197 mappings of SSRC to identification-tag. The offerer and answerer 1198 maintain tables used for routing that are updated each time an RTP/ 1199 RTCP packet contains new information that affects how packets are to 1200 be routed. 1202 However, some legacy implementations may not include this 1203 identification-tag in their RTP and RTCP traffic when using the 1204 BUNDLE mechanism and instead use a mechanism based on the payload 1205 type to associate RTP streams with SDP "m=" sections. In this 1206 situation, each "m=" section needs to use unique payload type values, 1207 in order for the payload type to be a reliable indicator of the 1208 relevant "m=" section for the RTP stream. If an implementation fails 1209 to ensure unique payload type values, it will be impossible to 1210 associate the RTP stream using that payload type value to a 1211 particular "m=" section. Note that when using the payload type to 1212 associate RTP streams with "m=" sections, an RTP stream, identified 1213 by its SSRC, will be mapped to an "m=" section when the first packet 1214 of that RTP stream is received, and the mapping will not be changed 1215 even if the payload type used by that RTP stream changes. In other 1216 words, the SSRC cannot "move" to a different "m=" section simply by 1217 changing the payload type. 1219 Applications can implement RTP stacks in many different ways. The 1220 algorithm below details one way that RTP streams can be associated 1221 with "m=" sections, but it is not meant to be prescriptive about 1222 exactly how an RTP stack needs to be implemented. Applications MAY 1223 use any algorithm that achieves equivalent results to those described 1224 in the algorithm below. 1226 To prepare to associate RTP streams with the correct "m=" section, 1227 the following steps MUST be followed for each BUNDLE group: 1229 * Construct a table mapping a MID to an "m=" section for each "m=" 1230 section in this BUNDLE group. Note that an "m=" section may only 1231 have one MID. 1233 * Construct a table mapping SSRCs of incoming RTP streams to an "m=" 1234 section for each "m=" section in this BUNDLE group and for each 1235 SSRC configured for receiving in that "m=" section. 1237 * Construct a table mapping the SSRC of each outgoing RTP stream to 1238 an "m=" section for each "m=" section in this BUNDLE group and for 1239 each SSRC configured for sending in that "m=" section. 1241 * Construct a table mapping a payload type to an "m=" section for 1242 each "m=" section in the BUNDLE group and for each payload type 1243 configured for receiving in that "m=" section. If any payload 1244 type is configured for receiving in more than one "m=" section in 1245 the BUNDLE group, do not include it in the table, as it cannot be 1246 used to uniquely identify an "m=" section. 1248 * Note that for each of these tables, there can only be one mapping 1249 for any given key (MID, SSRC, or PT). In other words, the tables 1250 are not multimaps. 1252 As "m=" sections are added or removed from the BUNDLE groups, or 1253 their configurations are changed, the tables above MUST also be 1254 updated. 1256 When an RTP packet is received, it MUST be delivered to the RTP 1257 stream corresponding to its SSRC. That RTP stream MUST then be 1258 associated with the correct "m=" section within a BUNDLE group, for 1259 additional processing, according to the following steps: 1261 * If the MID associated with the RTP stream is not in the table 1262 mapping a MID to an "m=" section, then the RTP stream is not 1263 decoded and the payload data is discarded. 1265 * If the packet has a MID, and the packet's extended sequence number 1266 is greater than that of the last MID update, as discussed in 1267 [RFC7941], Section 4.2.6, update the MID associated with the RTP 1268 stream to match the MID carried in the RTP packet, and then update 1269 the mapping tables to include an entry that maps the SSRC of that 1270 RTP stream to the "m=" section for that MID. 1272 * If the SSRC of the RTP stream is in the incoming SSRC mapping 1273 table, check that the payload type used by the RTP stream matches 1274 a payload type included on the matching "m=" section. If so, 1275 associate the RTP stream with that "m=" section. Otherwise, the 1276 RTP stream is not decoded and the payload data is discarded. 1278 * If the payload type used by the RTP stream is in the payload type 1279 table, update the incoming SSRC mapping table to include an entry 1280 that maps the RTP stream's SSRC to the "m=" section for that 1281 payload type. Associate the RTP stream with the corresponding 1282 "m=" section. 1284 * Otherwise, mark the RTP stream as "not for decoding" and discard 1285 the payload. 1287 If the RTP packet contains one or more Contributing Source (CSRC) 1288 identifiers, then each CSRC is looked up in the incoming SSRC table, 1289 and a copy of the RTP packet is associated with the corresponding 1290 "m=" section for additional processing. 1292 For each RTCP packet received (including each RTCP packet that is 1293 part of a compound RTCP packet), the packet is processed as usual by 1294 the RTP layer, then associated with the appropriate "m=" sections, 1295 and processed for the RTP streams represented by those "m=" sections. 1296 This routing is type dependent, as each kind of RTCP packet has its 1297 own mechanism for associating it with the relevant RTP streams. 1299 RTCP packets that cannot be associated with an appropriate "m=" 1300 section MUST still be processed as usual by the RTP layer, which 1301 updates the metadata associated with the corresponding RTP streams. 1302 This situation can occur with certain multiparty RTP topologies or 1303 when RTCP packets are sent containing a subset of the SDES 1304 information. 1306 Additional rules for processing various types of RTCP packets are 1307 explained below. 1309 * If the RTCP packet is of type SDES, for each chunk in the packet 1310 whose SSRC is found in the incoming SSRC table, deliver a copy of 1311 the SDES packet to the "m=" section associated with that SSRC. In 1312 addition, for any SDES MID items contained in these chunks, if the 1313 MID is found in the table mapping a MID to an "m=" section, update 1314 the incoming SSRC table to include an entry that maps the RTP 1315 stream associated with the chunk's SSRC to the "m=" section 1316 associated with that MID, unless the packet is older than the 1317 packet that most recently updated the mapping for this SSRC, as 1318 discussed in [RFC7941], Section 4.2.6. 1320 * Note that if an SDES packet is received as part of a compound RTCP 1321 packet, the SSRC to "m=" section mapping might not exist until the 1322 SDES packet is handled (e.g., in the case where RTCP for a source 1323 is received before any RTP packets). Therefore, it can be 1324 beneficial for an implementation to delay RTCP packet routing, 1325 such that it either prioritizes processing of the SDES item to 1326 generate or update the mapping or buffers the RTCP information 1327 that needs to be routed until the SDES item(s) has been processed. 1328 If the implementation is unable to follow this recommendation, the 1329 consequence could be that some RTCP information from this 1330 particular RTCP compound packet is not provided to higher layers. 1331 The impact from this is likely minor, when this information 1332 relates to a future incoming RTP stream. 1334 * If the RTCP packet is of type BYE, it indicates that the RTP 1335 streams referenced in the packet are ending. Therefore, for each 1336 SSRC indicated in the packet that is found in the incoming SSRC 1337 table, first deliver a copy of the BYE packet to the "m=" section 1338 associated with that SSRC, and then remove the entry for that SSRC 1339 from the incoming SSRC table after an appropriate delay to account 1340 for "straggler packets", as specified in [RFC3550], Section 6.2.1. 1342 * If the RTCP packet is of type Sender Report (SR) or Receiver 1343 Report (RR), for each report block in the report whose "SSRC of 1344 source" is found in the outgoing SSRC table, deliver a copy of the 1345 SR or RR packet to the "m=" section associated with that SSRC. In 1346 addition, if the packet is of type SR, and the sender SSRC for the 1347 packet is found in the incoming SSRC table, deliver a copy of the 1348 SR packet to the "m=" section associated with that SSRC. 1350 * If the implementation supports the RTCP Extended Report (XR) and 1351 the packet is of type XR, as defined in [RFC3611], for each report 1352 block in the report whose "SSRC of source" is found in the 1353 outgoing SSRC table, deliver a copy of the XR packet to the "m=" 1354 section associated with that SSRC. In addition, if the sender 1355 SSRC for the packet is found in the incoming SSRC table, deliver a 1356 copy of the XR packet to the "m=" section associated with that 1357 SSRC. 1359 * If the RTCP packet is a feedback message of type RTPFB (transport- 1360 layer FB message) or PSFB (payload-specific FB message), as 1361 defined in [RFC4585], it will contain a media source SSRC, and 1362 this SSRC is used for routing certain subtypes of feedback 1363 messages. However, several subtypes of PSFB and RTPFB messages 1364 include a target SSRC(s) in a section called Feedback Control 1365 Information (FCI). For these messages, the target SSRC(s) is used 1366 for routing. 1368 * If the RTCP packet is a feedback packet that does not include 1369 target SSRCs in its FCI section, and the media source SSRC is 1370 found in the outgoing SSRC table, deliver the feedback packet to 1371 the "m=" section associated with that SSRC. RTPFB and PSFB types 1372 that are handled in this way include: 1374 Generic NACK: (PT=RTPFB, FMT=1) [RFC4585]. 1376 Picture Loss Indication (PLI): (PT=PSFB, FMT=1) [RFC4585]. 1378 Slice Loss Indication (SLI): (PT=PSFB, FMT=2) [RFC4585]. 1380 Reference Picture Selection Indication (RPSI): (PT=PSFB, 1381 FMT=3) [RFC4585]. 1383 * If the RTCP packet is a feedback message that does include a 1384 target SSRC(s) in its FCI section, it can either be a request or a 1385 notification. Requests reference an RTP stream that is being sent 1386 by the message recipient, whereas notifications are responses to 1387 an earlier request and therefore reference an RTP stream that is 1388 being received by the message recipient. 1390 * If the RTCP packet is a feedback request that includes a target 1391 SSRC(s), for each target SSRC that is found in the outgoing SSRC 1392 table, deliver a copy of the RTCP packet to the "m=" section 1393 associated with that SSRC. PSFB and RTPFB types that are handled 1394 in this way include: 1396 Full Intra Request (FIR): (PT=PSFB, FMT=4) [RFC5104]. 1398 Temporal-Spatial Trade-off Request (TSTR): (PT=PSFB, FMT=5) 1399 [RFC5104]. 1401 H.271 Video Back Channel Message (VBCM): (PT=PSFB, FMT=7) 1402 [RFC5104]. 1404 Temporary Maximum Media Stream Bit Rate Request (TMMBR): (PT=R 1405 TPFB, FMT=3) [RFC5104]. 1407 Layer Refresh Request (LRR): (PT=PSFB, FMT=10) [LLR-RTCP]. 1409 * If the RTCP packet is a feedback notification that includes a 1410 target SSRC(s), for each target SSRC that is found in the incoming 1411 SSRC table, deliver a copy of the RTCP packet to the "m=" section 1412 associated with the RTP stream with a matching SSRC. PSFB and 1413 RTPFB types that are handled in this way include: 1415 Temporal-Spatial Trade-off Notification (TSTN): (PT=PSFB, 1416 FMT=6) [RFC5104]. This message is a notification in 1417 response to a prior TSTR. 1419 Temporary Maximum Media Stream Bit Rate Notification 1420 (TMMBN): (PT=RTPFB, FMT=4) [RFC5104]. This message is a 1421 notification in response to a prior TMMBR, but it can also 1422 be sent unsolicited. 1424 If the RTCP packet is of type APP, then it is handled in an 1425 application-specific manner. If the application does not 1426 recognize the APP packet, then it MUST be discarded. 1428 9.3. RTP/RTCP Multiplexing 1430 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 1431 multiplexing [RFC5761] for the RTP-based bundled media (i.e., the 1432 same transport will be used for both RTP packets and RTCP packets). 1433 In addition, the offerer and answerer MUST support the SDP 'rtcp-mux- 1434 only' attribute [RFC8858]. 1436 9.3.1. SDP Offer/Answer Procedures 1438 This section describes how an offerer and answerer use the SDP 'rtcp- 1439 mux' [RFC5761] and SDP 'rtcp-mux-only' attributes [RFC8858] to 1440 negotiate usage of RTP/RTCP multiplexing for RTP-based bundled media. 1442 RTP/RTCP multiplexing only applies to RTP-based media. However, as 1443 described in Section 7.1.3, within an offer or answer the SDP 'rtcp- 1444 mux' and SDP 'rtcp-mux-only' attributes might be included in a 1445 bundled "m=" section for non-RTP-based media (if such "m=" section is 1446 the offerer-tagged "m=" section or answerer-tagged "m=" section). 1448 9.3.1.1. Generating the Initial SDP BUNDLE Offer 1450 When an offerer generates an initial BUNDLE offer, if the offer 1451 contains one or more bundled "m=" sections for RTP-based media (or, 1452 if there is a chance that "m=" sections for RTP-based media will 1453 later be added to the BUNDLE group), the offerer MUST include an SDP 1454 'rtcp-mux' attribute [RFC5761] in each bundled "m=" section 1455 (excluding any bundle-only "m=" sections). In addition, the offerer 1456 MAY include an SDP 'rtcp-mux-only' attribute [RFC8858] in one or more 1457 bundled "m=" sections for RTP-based media. 1459 NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute 1460 depends on whether the offerer supports fallback to usage of a 1461 separate port for RTCP in case the answerer moves one or more "m=" 1462 sections for RTP-based media out of the BUNDLE group in the answer. 1464 NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the 1465 bundled "m=" sections, but does not include an SDP 'rtcp-mux-only' 1466 attribute, the offerer can also include an SDP 'rtcp' attribute 1467 [RFC3605] in one or more RTP-based bundled "m=" sections in order to 1468 provide a fallback port for RTCP, as described in [RFC5761]. 1470 However, the fallback port will only be applied to "m=" sections for 1471 RTP-based media that are moved out of the BUNDLE group by the 1472 answerer. 1474 In the initial BUNDLE offer, the address:port combination for RTCP 1475 MUST be unique in each bundled "m=" section for RTP-based media 1476 (excluding a bundle-only "m=" section), similar to RTP. 1478 9.3.1.2. Generating the SDP Answer 1480 When an answerer generates an answer, if the answerer supports RTP- 1481 based media, and if a bundled "m=" section in the corresponding offer 1482 contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage 1483 of RTP/RTCP multiplexing, even if there currently are no bundled "m=" 1484 sections for RTP-based media within the BUNDLE group. The answerer 1485 MUST include an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" 1486 section, following the procedures for BUNDLE attributes 1487 (Section 7.1.3). In addition, if the "m=" section that is selected 1488 as the offerer-tagged "m=" section contained an SDP 'rtcp-mux-only' 1489 attribute, the answerer MUST include an SDP 'rtcp-mux-only' attribute 1490 in the answerer-tagged "m=" section. 1492 In an initial BUNDLE offer, if the suggested offerer-tagged "m=" 1493 section contained an SDP 'rtcp-mux-only' attribute, the "m=" section 1494 was for RTP-based media; thus, the answerer does not accept the "m=" 1495 section in the created BUNDLE group, and the answerer MUST move the 1496 "m=" section out of the BUNDLE group (Section 7.3.2); include the 1497 attribute in the moved "m=" section and enable RTP/RTCP multiplexing 1498 for the media associated with the "m=" section; or reject the "m=" 1499 section (Section 7.3.3). 1501 The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled 1502 "m=" section in the answer. The answerer will use the port value of 1503 the offerer-tagged "m=" section sending RTP and RTCP packets 1504 associated with RTP-based bundled media towards the offerer. 1506 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1507 negotiated in a previous offer/answer exchange, the answerer MUST 1508 include an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" 1509 section. It is not possible to disable RTP/RTCP multiplexing within 1510 a BUNDLE group. 1512 9.3.1.3. Offerer Processing of the SDP Answer 1514 When an offerer receives an answer, if the answerer has accepted the 1515 usage of RTP/RTCP multiplexing (Section 9.3.1.2), the answerer 1516 follows the procedures for RTP/RTCP multiplexing defined in 1517 [RFC5761]. The offerer will use the port value of the answerer- 1518 tagged "m=" section for sending RTP and RTCP packets associated with 1519 RTP-based bundled media towards the answerer. 1521 NOTE: It is considered a protocol error if the answerer has not 1522 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" 1523 sections that the answerer included in the BUNDLE group. 1525 9.3.1.4. Modifying the Session 1527 When an offerer generates a subsequent offer, the offerer MUST 1528 include an SDP 'rtcp-mux' attribute in the offerer-tagged "m=" 1529 section, following the procedures for IDENTICAL multiplexing category 1530 attributes in Section 7.1.3. 1532 10. ICE Considerations 1534 This section describes how to use the BUNDLE grouping extension 1535 together with the ICE mechanism [RFC8445]. 1537 The generic procedures for negotiating the usage of ICE using SDP, 1538 defined in [RFC8839], also apply to the usage of ICE with BUNDLE, 1539 with the following exceptions: 1541 * When the BUNDLE transport has been established, ICE connectivity 1542 checks and keepalives only need to be performed for the BUNDLE 1543 transport, instead of per individual bundled "m=" section within 1544 the BUNDLE group. 1546 * The generic SDP attribute offer/answer considerations 1547 (Section 7.1.3) also apply to ICE-related attributes. Therefore, 1548 when an offerer sends an initial BUNDLE offer (in order to 1549 negotiate a BUNDLE group), the offerer includes ICE-related media- 1550 level attributes in each bundled "m=" section (excluding any 1551 bundle-only "m=" sections), and each "m=" section MUST contain 1552 unique ICE properties. When an answerer generates an answer 1553 (initial BUNDLE answer or subsequent) that contains a BUNDLE 1554 group, and when an offerer sends a subsequent offer that contains 1555 a BUNDLE group, ICE-related media-level attributes are only 1556 included in the tagged "m=" section (suggested offerer-tagged "m=" 1557 section or answerer-tagged "m=" section), and the ICE properties 1558 are applied to each bundled "m=" section within the BUNDLE group. 1560 NOTE: Most ICE-related media-level SDP attributes belong to the 1561 TRANSPORT multiplexing category [RFC8859], and the generic SDP 1562 attribute offer/answer considerations for the TRANSPORT multiplexing 1563 category apply to the attributes. However, in the case of ICE- 1564 related attributes, the same considerations also apply to ICE-related 1565 media-level attributes that belong to other multiplexing categories. 1567 NOTE: The following ICE-related media-level SDP attributes are 1568 defined in [RFC8839]: 'candidate', 'remote-candidates', 'ice- 1569 mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-pacing'. 1571 Initially, before ICE has produced selected candidate pairs that will 1572 be used for media, there might be multiple transports established (if 1573 multiple candidate pairs are tested). Once ICE has selected 1574 candidate pairs, they form the BUNDLE transport. 1576 Support and usage of the ICE mechanism together with the BUNDLE 1577 extension is OPTIONAL, and the procedures in this section only apply 1578 when the ICE mechanism is used. Note that applications might mandate 1579 usage of the ICE mechanism even if the BUNDLE extension is not used. 1581 NOTE: If the Trickle ICE mechanism [RFC8840] is used, an offerer and 1582 answerer might assign a port value of '9' and an IPv4 address of 1583 '0.0.0.0' (or, the IPv6 equivalent '::') to multiple bundled "m=" 1584 sections in the initial BUNDLE offer. The offerer and answerer will 1585 follow the normal procedures for generating the offers and answers, 1586 including picking a bundled "m=" section as the suggested offerer- 1587 tagged "m=" section, selecting the tagged "m=" sections, etc. The 1588 only difference is that media cannot be sent until one or more 1589 candidates have been provided. Once a BUNDLE group has been 1590 negotiated, trickled candidates associated with a bundled "m=" 1591 section will be applied to all bundled "m=" sections within the 1592 BUNDLE group. 1594 11. DTLS Considerations 1596 One or more media streams within a BUNDLE group might use the 1597 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1598 to encrypt the data or negotiate encryption keys if another 1599 encryption mechanism is used to encrypt media. 1601 When DTLS is used within a BUNDLE group, the following rules apply: 1603 * There can only be one DTLS association [RFC6347] associated with 1604 the BUNDLE group; 1606 * Each usage of the DTLS association within the BUNDLE group MUST 1607 use the same mechanism for determining which endpoints (the 1608 offerer or answerer) become DTLS client and DTLS server; 1610 * Each usage of the DTLS association within the BUNDLE group MUST 1611 use the same mechanism for determining whether an offer or answer 1612 will trigger the establishment of a new DTLS association or an 1613 existing DTLS association will be used; and 1615 * If the DTLS client supports DTLS-SRTP, it MUST include the 1616 'use_srtp' extension in the DTLS ClientHello message [RFC5764]. 1617 The client MUST include the extension even if the usage of DTLS- 1618 SRTP is not negotiated as part of the multimedia session (e.g., 1619 the SIP session [RFC3261]). 1621 NOTE: The inclusion of the 'use_srtp' extension during the initial 1622 DTLS handshake ensures that a DTLS renegotiation will not be required 1623 in order to include the extension, in case DTLS-SRTP encrypted media 1624 is added to the BUNDLE group later during the multimedia session. 1626 12. RTP Header Extensions Consideration 1628 When RTP header extensions [RFC8285] are used in the context of this 1629 specification, the identifier used for a given extension MUST 1630 identify the same extension across all the bundled media 1631 descriptions. 1633 13. Update to RFC 3264 1635 This section updates RFC 3264, in order to allow extensions to define 1636 the usage of a zero port value in offers and answers for purposes 1637 other than removing or disabling media streams. The following 1638 sections are being updated: 1640 * "Unicast Streams"; see Section 5.1 of [RFC3264] 1642 * "Putting a Unicast Media Stream on Hold"; see Section 8.4 of 1643 [RFC3264]. 1645 13.1. Original Text from RFC 3264, Section 5.1, 2nd Paragraph 1647 | For recvonly and sendrecv streams, the port number and address in 1648 | the offer indicate where the offerer would like to receive the 1649 | media stream. For sendonly RTP streams, the address and port 1650 | number indirectly indicate where the offerer wants to receive RTCP 1651 | reports. Unless there is an explicit indication otherwise, 1652 | reports are sent to the port number one higher than the number 1653 | indicated. The IP address and port present in the offer indicate 1654 | nothing about the source IP address and source port of RTP and 1655 | RTCP packets that will be sent by the offerer. A port number of 1656 | zero in the offer indicates that the stream is offered but MUST 1657 | NOT be used. This has no useful semantics in an initial offer, 1658 | but is allowed for reasons of completeness, since the answer can 1659 | contain a zero port indicating a rejected stream (Section 6). 1660 | Furthermore, existing streams can be terminated by setting the 1661 | port to zero (Section 8). In general, a port number of zero 1662 | indicates that the media stream is not wanted. 1664 13.2. New Text Replacing RFC 3264, Section 5.1, 2nd Paragraph 1666 For recvonly and sendrecv streams, the port number and address in the 1667 offer indicate where the offerer would like to receive the media 1668 stream. For sendonly RTP streams, the address and port number 1669 indirectly indicate where the offerer wants to receive RTCP reports. 1670 Unless there is an explicit indication otherwise, reports are sent to 1671 the port number one higher than the number indicated. The IP address 1672 and port present in the offer indicate nothing about the source IP 1673 address and source port of the RTP and RTCP packets that will be sent 1674 by the offerer. By default, a port number of zero in the offer 1675 indicates that the stream is offered but MUST NOT be used, but an 1676 extension mechanism might specify different semantics for the usage 1677 of a zero port value. Furthermore, existing streams can be 1678 terminated by setting the port to zero (Section 8). In general, a 1679 port number of zero by default indicates that the media stream is not 1680 wanted. 1682 13.3. Original Text from RFC 3264, Section 8.4, 6th Paragraph 1684 | RFC 2543 [10] specified that placing a user on hold was 1685 | accomplished by setting the connection address to 0.0.0.0. Its 1686 | usage for putting a call on hold is no longer recommended, since 1687 | it doesn't allow for RTCP to be used with held streams, doesn't 1688 | work with IPv6, and breaks with connection oriented media. 1689 | However, it can be useful in an initial offer when the offerer 1690 | knows it wants to use a particular set of media streams and 1691 | formats, but doesn't know the addresses and ports at the time of 1692 | the offer. Of course, when used, the port number MUST NOT be 1693 | zero, which would specify that the stream has been disabled. An 1694 | agent MUST be capable of receiving SDP with a connection address 1695 | of 0.0.0.0, in which case it means that neither RTP nor RTCP 1696 | should be sent to the peer. 1698 13.4. New Text Replacing RFC 3264, Section 8.4, 6th Paragraph 1700 RFC 2543 [RFC2543] specifies that placing a user on hold was 1701 accomplished by setting the connection address to 0.0.0.0. Its usage 1702 for putting a call on hold is no longer recommended, since it doesn't 1703 allow for RTCP to be used with held streams, doesn't work with IPv6, 1704 and breaks with connection oriented media. However, it can be useful 1705 in an initial offer when the offerer knows it wants to use a 1706 particular set of media streams and formats, but doesn't know the 1707 addresses and ports at the time of the offer. Of course, when used, 1708 the port number MUST NOT be zero, if it would specify that the stream 1709 has been disabled. However, an extension mechanism might specify 1710 different semantics of the zero port number usage. An agent MUST be 1711 capable of receiving SDP with a connection address of 0.0.0.0, in 1712 which case it means that neither RTP nor RTCP is to be sent to the 1713 peer. 1715 14. Update to RFC 5888 1717 This section updates RFC 5888 [RFC5888], in order for extensions to 1718 allow an SDP 'group' attribute containing an identification-tag that 1719 identifies an "m=" section with the port set to zero. "Group Value 1720 in Answers" (Section 9.2 of [RFC5888]) is updated. 1722 14.1. Original Text from RFC 5888, Section 9.2, 3rd Paragraph 1724 | SIP entities refuse media streams by setting the port to zero in 1725 | the corresponding "m" line. "a=group" lines MUST NOT contain 1726 | identification-tags that correspond to "m" lines with the port set 1727 | to zero. 1729 14.2. New Text Replacing RFC 5888, Section 9.2, 3rd Paragraph 1731 SIP entities refuse media streams by setting the port to zero in the 1732 corresponding "m" line. "a=group" lines MUST NOT contain 1733 identification-tags that correspond to "m" lines with the port set to 1734 zero, but an extension mechanism might specify different semantics 1735 for including identification-tags that correspond to such "m=" lines. 1737 15. RTP/RTCP Extensions for identification-tag Transport 1739 Offerers and answerers [RFC3264] can associate identification-tags 1740 with "m=" sections within offers and answers, using the procedures in 1741 [RFC5888]. Each identification-tag uniquely represents an "m=" 1742 section. 1744 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1745 used to carry identification-tags within RTCP SDES packets. This 1746 section also defines a new RTP SDES header extension [RFC7941], which 1747 is used to carry the 'MID' RTCP SDES item in RTP packets. 1749 The SDES item and RTP SDES header extension make it possible for a 1750 receiver to associate each RTP stream with a specific "m=" section, 1751 with which the receiver has associated an identification-tag, even if 1752 those "m=" sections are part of the same RTP session. The RTP SDES 1753 header extension also ensures that the media recipient gets the 1754 identification-tag upon receipt of the first decodable media and is 1755 able to associate the media with the correct application. 1757 A media recipient informs the media sender about the identification- 1758 tag associated with an "m=" section through the use of a 'mid' 1759 attribute [RFC5888]. The media sender then inserts the 1760 identification-tag in RTCP and RTP packets sent to the media 1761 recipient. 1763 NOTE: The text above defines how identification-tags are carried in 1764 offers and answers. The usage of other signaling protocols for 1765 carrying identification-tags is not prevented, but the usage of such 1766 protocols is outside the scope of this document. 1768 [RFC3550] defines general procedures regarding the RTCP transmission 1769 interval. The RTCP MID SDES item SHOULD be sent in the first few 1770 RTCP packets after joining the session and SHOULD be sent regularly 1771 thereafter. The exact number of RTCP packets in which this SDES item 1772 is sent is intentionally not specified here, as it will depend on the 1773 expected packet-loss rate, the RTCP reporting interval, and the 1774 allowable overhead. 1776 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1777 be included in some RTP packets at the start of the session and 1778 whenever the SSRC changes. It might also be useful to include the 1779 header extension in RTP packets that comprise access points in the 1780 media (e.g., with video I-frames). The exact number of RTP packets 1781 in which this header extension is sent is intentionally not specified 1782 here, as it will depend on expected packet-loss rate and loss 1783 patterns, the overhead the application can tolerate, and the 1784 importance of immediate receipt of the identification-tag. 1786 For robustness, endpoints need to be prepared for situations where 1787 the reception of the identification-tag is delayed and SHOULD NOT 1788 terminate sessions in such cases, as the identification-tag is likely 1789 to arrive soon. 1791 15.1. RTCP MID SDES Item 1793 0 1 2 3 1794 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 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | MID=15 | length | identification-tag ... 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP. 1801 The identification-tag is not zero terminated. 1803 15.2. RTP SDES Header Extension For MID 1805 The payload, containing the identification-tag, of the RTP SDES 1806 header extension element can be encoded using either the 1-byte or 1807 the 2-byte header [RFC7941]. The identification-tag payload is UTF-8 1808 encoded, as in SDP. 1810 The identification-tag is not zero terminated. Note that the set of 1811 header extensions included in the packet needs to be padded to the 1812 next 32-bit boundary using zero bytes [RFC8285]. 1814 As the identification-tag is included in an RTCP SDES item, an RTP 1815 SDES header extension, or both, there needs to be some consideration 1816 about the packet expansion caused by the identification-tag. To 1817 avoid Maximum Transmission Unit (MTU) issues for the RTP packets, the 1818 header extension's size needs to be taken into account when encoding 1819 the media. 1821 It is recommended that the identification-tag be kept short. Due to 1822 the properties of the RTP header extension mechanism, when using the 1823 1-byte header, a tag that is 1-3 bytes will result in a minimal 1824 number of 32-bit words used for the RTP SDES header extension, in 1825 case no other header extensions are included at the same time. Note, 1826 do take into account that some single characters when UTF-8 encoded 1827 will result in multiple octets. The identification-tag MUST NOT 1828 contain any user information, and applications SHALL avoid generating 1829 the identification-tag using a pattern that enables user or 1830 application identification. 1832 16. IANA Considerations 1834 16.1. New SDES Item 1836 This document adds the MID SDES item to the IANA "RTP SDES Item 1837 Types" registry as follows: 1839 Value: 15 1841 Abbrev.: MID 1843 Name: Media Identification 1845 Reference: RFC XXXX 1847 16.2. New RTP SDES Header Extension URI 1849 This document defines a new extension URI in the RTP SDES Compact 1850 Header Extensions sub-registry of the RTP Compact Header Extensions 1851 registry sub-registry, according to the following data: 1853 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1855 Description: Media identification 1857 Contact: IESG (iesg@ietf.org) 1859 Reference: RFC XXXX 1861 The SDES item does not reveal privacy information about the users. 1862 It is simply used to associate RTP-based media with the correct SDP 1863 media description ("m=" section) in the SDP used to negotiate the 1864 media. 1866 The purpose of the extension is for the offerer to be able to 1867 associate received multiplexed RTP-based media before the offerer 1868 receives the associated answer. 1870 16.3. New SDP Attribute 1872 This document defines a new SDP media-level attribute, 'bundle-only', 1873 according to the following data: 1875 Attribute name: bundle-only 1877 Type of attribute: media 1879 Subject to charset: No 1881 Purpose: Request a media description to be accepted in the answer 1882 only if kept within a BUNDLE group by the answerer. 1884 Appropriate values: N/A 1886 Contact name: IESG 1887 Contact e-mail: iesg@ietf.org 1889 Reference: RFC XXXX 1891 Mux category: NORMAL 1893 16.4. New SDP Group Semantics 1895 This document registers the following semantics with IANA in the 1896 "Semantics for the 'group' SDP Attribute" subregistry (under the 1897 "Session Description Protocol (SDP) Parameters" registry): 1899 +================+========+==============+===========+ 1900 | Semantics | Token | Mux Category | Reference | 1901 +================+========+==============+===========+ 1902 | Media bundling | BUNDLE | NORMAL | RFC XXXX | 1903 +----------------+--------+--------------+-----------+ 1905 Table 1 1907 17. Security Considerations 1909 The security considerations defined in [RFC3264] and [RFC5888] apply 1910 to the BUNDLE extension. BUNDLE does not change which information, 1911 e.g., RTP streams, flows over the network, with the exception of the 1912 usage of the MID SDES item as discussed below. Primarily, it changes 1913 which addresses and ports, and thus in which (RTP) sessions, the 1914 information flows to. This affects the security contexts being used 1915 and can cause previously separated information flows to share the 1916 same security context. This has very little impact on the 1917 performance of the security mechanism of the RTP sessions. In cases 1918 where one would have applied different security policies on the 1919 different RTP streams being bundled, or where the parties having 1920 access to the security contexts would have differed between the RTP 1921 streams, additional analysis of the implications are needed before 1922 selecting to apply BUNDLE. 1924 The identification-tag, independent of transport, RTCP SDES packet, 1925 or RTP header extension, can expose the value to parties beyond the 1926 signaling chain. Therefore, the identification-tag values MUST be 1927 generated in a fashion that does not leak user information, e.g., 1928 randomly or using a per-bundle group counter, and SHOULD be 3 bytes 1929 or less to allow them to efficiently fit into the MID RTP header 1930 extension. Note that if implementations use different methods for 1931 generating identification-tags, this could enable fingerprinting of 1932 the implementation making it vulnerable to targeted attacks. The 1933 identification-tag is exposed on the RTP stream level when included 1934 in the RTP header extensions; however, what it reveals of the RTP 1935 media stream structure of the endpoint and application was already 1936 possible to deduce from the RTP streams without the MID SDES header 1937 extensions. As the identification-tag is also used to route the 1938 media stream to the right application functionality, it is important 1939 that the value received is the one intended by the sender; thus, 1940 integrity and the authenticity of the source are important to prevent 1941 denial of service on the application. Existing SRTP configurations 1942 and other security mechanisms protecting the whole RTP/RTCP packets 1943 will provide the necessary protection. 1945 When the BUNDLE extension is used, the set of configurations of the 1946 security mechanism used in all the bundled media descriptions will 1947 need to be compatible so that they can be used simultaneously, at 1948 least per direction or endpoint. When using SRTP, this will be the 1949 case, at least for the IETF-defined key-management solutions due to 1950 their SDP attributes ("a=crypto", "a=fingerprint", "a=mikey") and 1951 their classification in [RFC8859]. 1953 The security considerations of "RTP Header Extension for the RTP 1954 Control Protocol (RTCP) Source Description Items" [RFC7941] require 1955 that when RTCP is confidentiality protected, any SDES RTP header 1956 extension carrying an SDES item, such as the MID RTP header 1957 extension, is also protected using commensurate strength algorithms. 1958 However, assuming the above requirements and recommendations are 1959 followed, there are no known significant security risks with leaving 1960 the MID RTP header extension without confidentiality protection. 1961 Therefore, this specification updates RFC 7941 by adding the 1962 exception that this requirement MAY be ignored for the MID RTP header 1963 extension. Security mechanisms for RTP/RTCP are discussed in 1964 "Options for Securing RTP Sessions" [RFC7201], for example, SRTP 1965 [RFC3711] can provide the necessary security functions of ensuring 1966 the integrity and source authenticity. 1968 18. Examples 1970 18.1. Example: Tagged "m=" Section Selections 1972 The example below shows: 1974 * An initial BUNDLE offer, in which the offerer wants to negotiate a 1975 BUNDLE group and indicates the audio "m=" section as the suggested 1976 offerer-tagged "m=" section. 1978 * An initial BUNDLE answer, in which the answerer accepts the 1979 creation of the BUNDLE group, selects the audio "m=" section in 1980 the offer as the offerer-tagged "m=" section, selects the audio 1981 "m=" section in the answer as the answerer-tagged "m=" section, 1982 and assigns the answerer BUNDLE address:port to that "m=" section. 1984 SDP Offer (1) 1986 v=0 1987 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1988 s= 1989 c=IN IP6 2001:db8::3 1990 t=0 0 1991 a=group:BUNDLE foo bar 1993 m=audio 10000 RTP/AVP 0 8 97 1994 b=AS:200 1995 a=mid:foo 1996 a=rtcp-mux 1997 a=rtpmap:0 PCMU/8000 1998 a=rtpmap:8 PCMA/8000 1999 a=rtpmap:97 iLBC/8000 2000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2002 m=video 10002 RTP/AVP 31 32 2003 b=AS:1000 2004 a=mid:bar 2005 a=rtcp-mux 2006 a=rtpmap:31 H261/90000 2007 a=rtpmap:32 MPV/90000 2008 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2010 SDP Answer (2) 2012 v=0 2013 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2014 s= 2015 c=IN IP6 2001:db8::1 2016 t=0 0 2017 a=group:BUNDLE foo bar 2019 m=audio 20000 RTP/AVP 0 2020 b=AS:200 2021 a=mid:foo 2022 a=rtcp-mux 2023 a=rtpmap:0 PCMU/8000 2024 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2026 m=video 20000 RTP/AVP 32 2027 b=AS:1000 2028 a=mid:bar 2029 a=rtpmap:32 MPV/90000 2030 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2032 18.2. Example: BUNDLE Group Rejected 2034 The example below shows: 2036 * An initial BUNDLE offer, in which the offerer wants to negotiate a 2037 BUNDLE group and indicates the audio "m=" section as the suggested 2038 offerer-tagged "m=" section. 2040 * An initial BUNDLE answer, in which the answerer rejects the 2041 creation of the BUNDLE group, generates a normal answer, and 2042 assigns a unique address:port to each "m=" section in the answer. 2044 SDP Offer (1) 2046 v=0 2047 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2048 s= 2049 c=IN IP6 2001:db8::3 2050 t=0 0 2051 a=group:BUNDLE foo bar 2053 m=audio 10000 RTP/AVP 0 8 97 2054 b=AS:200 2055 a=mid:foo 2056 a=rtcp-mux 2057 a=rtpmap:0 PCMU/8000 2058 a=rtpmap:8 PCMA/8000 2059 a=rtpmap:97 iLBC/8000 2060 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2062 m=video 10002 RTP/AVP 31 32 2063 b=AS:1000 2064 a=mid:bar 2065 a=rtcp-mux 2066 a=rtpmap:31 H261/90000 2067 a=rtpmap:32 MPV/90000 2068 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2070 SDP Answer (2) 2071 v=0 2072 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2073 s= 2074 c=IN IP6 2001:db8::1 2075 t=0 0 2077 m=audio 20000 RTP/AVP 0 2078 b=AS:200 2079 a=rtcp-mux 2080 a=rtpmap:0 PCMU/8000 2082 m=video 30000 RTP/AVP 32 2083 b=AS:1000 2084 a=rtcp-mux 2085 a=rtpmap:32 MPV/90000 2087 18.3. Example: Offerer Adds a Media Description to a BUNDLE Group 2089 The example below shows: 2091 * A subsequent offer, in which the offerer adds a new bundled "m=" 2092 section (video), indicated by the "zen" identification-tag, to a 2093 previously negotiated BUNDLE group; indicates the new "m=" section 2094 as the offerer-tagged "m=" section; and assigns the offerer BUNDLE 2095 address:port to that "m=" section. 2097 * A subsequent answer, in which the answerer indicates the new video 2098 "m=" section in the answer as the answerer-tagged "m=" section and 2099 assigns the answerer BUNDLE address:port to that "m=" section. 2101 SDP Offer (1) 2102 v=0 2103 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2104 s= 2105 c=IN IP6 2001:db8::3 2106 t=0 0 2107 a=group:BUNDLE zen foo bar 2109 m=audio 10000 RTP/AVP 0 8 97 2110 b=AS:200 2111 a=mid:foo 2112 a=rtpmap:0 PCMU/8000 2113 a=rtpmap:8 PCMA/8000 2114 a=rtpmap:97 iLBC/8000 2115 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2117 m=video 10000 RTP/AVP 31 32 2118 b=AS:1000 2119 a=mid:bar 2120 a=rtpmap:31 H261/90000 2121 a=rtpmap:32 MPV/90000 2122 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2124 m=video 10000 RTP/AVP 66 2125 b=AS:1000 2126 a=mid:zen 2127 a=rtcp-mux 2128 a=rtpmap:66 H261/90000 2129 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2131 SDP Answer (2) 2132 v=0 2133 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2134 s= 2135 c=IN IP6 2001:db8::1 2136 t=0 0 2137 a=group:BUNDLE zen foo bar 2139 m=audio 20000 RTP/AVP 0 2140 b=AS:200 2141 a=mid:foo 2142 a=rtpmap:0 PCMU/8000 2143 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2145 m=video 20000 RTP/AVP 32 2146 b=AS:1000 2147 a=mid:bar 2148 a=rtpmap:32 MPV/90000 2149 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2151 m=video 20000 RTP/AVP 66 2152 b=AS:1000 2153 a=mid:zen 2154 a=rtcp-mux 2155 a=rtpmap:66 H261/90000 2156 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2158 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 2160 The example below shows: 2162 * A subsequent offer, in which the offerer removes an "m=" section 2163 (video), indicated by the "zen" identification-tag, from a 2164 previously negotiated BUNDLE group; indicates one of the bundled 2165 "m=" sections (audio) remaining in the BUNDLE group as the 2166 offerer-tagged "m=" section; and assigns the offerer BUNDLE 2167 address:port to that "m=" section. 2169 * A subsequent answer, in which the answerer removes the "m=" 2170 section from the BUNDLE group, indicates the audio "m=" section in 2171 the answer as the answerer-tagged "m=" section, and assigns the 2172 answerer BUNDLE address:port to that "m=" section. 2174 SDP Offer (1) 2175 v=0 2176 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2177 s= 2178 c=IN IP6 2001:db8::3 2179 t=0 0 2180 a=group:BUNDLE foo bar 2182 m=audio 10000 RTP/AVP 0 8 97 2183 b=AS:200 2184 a=mid:foo 2185 a=rtcp-mux 2186 a=rtpmap:0 PCMU/8000 2187 a=rtpmap:8 PCMA/8000 2188 a=rtpmap:97 iLBC/8000 2189 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2191 m=video 10000 RTP/AVP 31 32 2192 b=AS:1000 2193 a=mid:bar 2194 a=rtpmap:31 H261/90000 2195 a=rtpmap:32 MPV/90000 2196 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2198 m=video 50000 RTP/AVP 66 2199 b=AS:1000 2200 a=mid:zen 2201 a=rtcp-mux 2202 a=rtpmap:66 H261/90000 2204 SDP Answer (2) 2205 v=0 2206 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2207 s= 2208 c=IN IP6 2001:db8::1 2209 t=0 0 2210 a=group:BUNDLE foo bar 2212 m=audio 20000 RTP/AVP 0 2213 b=AS:200 2214 a=mid:foo 2215 a=rtcp-mux 2216 a=rtpmap:0 PCMU/8000 2217 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2219 m=video 20000 RTP/AVP 32 2220 b=AS:1000 2221 a=mid:bar 2222 a=rtpmap:32 MPV/90000 2223 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2225 m=video 60000 RTP/AVP 66 2226 b=AS:1000 2227 a=mid:zen 2228 a=rtcp-mux 2229 a=rtpmap:66 H261/90000 2231 18.5. Example: Offerer Disables a Media Description within a BUNDLE 2232 Group 2234 The example below shows: 2236 * A subsequent offer, in which the offerer disables (by assigning a 2237 zero port value) an "m=" section (video), indicated by the "zen" 2238 identification-tag, from a previously negotiated BUNDLE group; 2239 indicates one of the bundled "m=" sections (audio) remaining 2240 active in the BUNDLE group as the offerer-tagged "m=" section; and 2241 assigns the offerer BUNDLE address:port to that "m=" section. 2243 * A subsequent answer, in which the answerer disables the "m=" 2244 section, indicates the audio "m=" section in the answer as the 2245 answerer-tagged "m=" section, and assigns the answerer BUNDLE 2246 address:port to that "m=" section. 2248 SDP Offer (1) 2249 v=0 2250 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2251 s= 2252 t=0 0 2253 a=group:BUNDLE foo bar 2255 m=audio 10000 RTP/AVP 0 8 97 2256 c=IN IP6 2001:db8::3 2257 b=AS:200 2258 a=mid:foo 2259 a=rtcp-mux 2260 a=rtpmap:0 PCMU/8000 2261 a=rtpmap:8 PCMA/8000 2262 a=rtpmap:97 iLBC/8000 2263 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2265 m=video 10000 RTP/AVP 31 32 2266 c=IN IP6 2001:db8::3 2267 b=AS:1000 2268 a=mid:bar 2269 a=rtpmap:31 H261/90000 2270 a=rtpmap:32 MPV/90000 2271 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2273 m=video 0 RTP/AVP 66 2274 a=mid:zen 2275 a=rtpmap:66 H261/90000 2277 SDP Answer (2) 2278 v=0 2279 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2280 s= 2281 t=0 0 2282 a=group:BUNDLE foo bar 2284 m=audio 20000 RTP/AVP 0 2285 c=IN IP6 2001:db8::1 2286 b=AS:200 2287 a=mid:foo 2288 a=rtcp-mux 2289 a=rtpmap:0 PCMU/8000 2290 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2292 m=video 20000 RTP/AVP 32 2293 c=IN IP6 2001:db8::1 2294 b=AS:1000 2295 a=mid:bar 2296 a=rtpmap:32 MPV/90000 2297 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2299 m=video 0 RTP/AVP 66 2300 a=mid:zen 2301 a=rtpmap:66 H261/90000 2303 19. References 2305 19.1. Normative References 2307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2308 Requirement Levels", BCP 14, RFC 2119, 2309 DOI 10.17487/RFC2119, March 1997, 2310 . 2312 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2313 with Session Description Protocol (SDP)", RFC 3264, 2314 DOI 10.17487/RFC3264, June 2002, 2315 . 2317 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2318 Jacobson, "RTP: A Transport Protocol for Real-Time 2319 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2320 July 2003, . 2322 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2323 in Session Description Protocol (SDP)", RFC 3605, 2324 DOI 10.17487/RFC3605, October 2003, 2325 . 2327 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2328 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2329 2003, . 2331 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2332 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2333 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2334 . 2336 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2337 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2338 July 2006, . 2340 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2341 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2342 . 2344 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2345 Control Packets on a Single Port", RFC 5761, 2346 DOI 10.17487/RFC5761, April 2010, 2347 . 2349 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2350 Security (DTLS) Extension to Establish Keys for the Secure 2351 Real-time Transport Protocol (SRTP)", RFC 5764, 2352 DOI 10.17487/RFC5764, May 2010, 2353 . 2355 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2356 Protocol (SDP) Grouping Framework", RFC 5888, 2357 DOI 10.17487/RFC5888, June 2010, 2358 . 2360 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2361 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2362 January 2012, . 2364 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2365 Header Extension for the RTP Control Protocol (RTCP) 2366 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2367 August 2016, . 2369 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2370 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2371 May 2017, . 2373 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 2374 Mechanism for RTP Header Extensions", RFC 8285, 2375 DOI 10.17487/RFC8285, October 2017, 2376 . 2378 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2379 Connectivity Establishment (ICE): A Protocol for Network 2380 Address Translator (NAT) Traversal", RFC 8445, 2381 DOI 10.17487/RFC8445, July 2018, 2382 . 2384 [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, 2385 A., and R. Shpount, "Session Description Protocol (SDP) 2386 Offer/Answer Procedures for Interactive Connectivity 2387 Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, 2388 January 2021, . 2390 [RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 2391 Session Initiation Protocol (SIP) Usage for Incremental 2392 Provisioning of Candidates for the Interactive 2393 Connectivity Establishment (Trickle ICE)", RFC 8840, 2394 DOI 10.17487/RFC8840, January 2021, 2395 . 2397 [RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP 2398 Control Protocol (RTCP) Multiplexing Using the Session 2399 Description Protocol (SDP)", RFC 8858, 2400 DOI 10.17487/RFC8858, January 2021, 2401 . 2403 [RFC8859] Nandakumar, S., "A Framework for Session Description 2404 Protocol (SDP) Attributes When Multiplexing", RFC 8859, 2405 DOI 10.17487/RFC8859, January 2021, 2406 . 2408 19.2. Informative References 2410 [LLR-RTCP] Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 2411 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 2412 Message", Work in Progress, Internet-Draft, draft-ietf- 2413 avtext-lrr-07, 2 July 2017, 2414 . 2416 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 2417 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 2418 DOI 10.17487/RFC2543, March 1999, 2419 . 2421 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2422 A., Peterson, J., Sparks, R., Handley, M., and E. 2423 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2424 DOI 10.17487/RFC3261, June 2002, 2425 . 2427 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2428 "RTP Control Protocol Extended Reports (RTCP XR)", 2429 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2430 . 2432 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2433 "Extended RTP Profile for Real-time Transport Control 2434 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2435 DOI 10.17487/RFC4585, July 2006, 2436 . 2438 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2439 "Codec Control Messages in the RTP Audio-Visual Profile 2440 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 2441 February 2008, . 2443 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2444 Media Attributes in the Session Description Protocol 2445 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2446 . 2448 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2449 Clock Rates in an RTP Session", RFC 7160, 2450 DOI 10.17487/RFC7160, April 2014, 2451 . 2453 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2454 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2455 . 2457 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2458 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2459 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2460 DOI 10.17487/RFC7656, November 2015, 2461 . 2463 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 2464 (Diffserv) and Real-Time Communication", RFC 7657, 2465 DOI 10.17487/RFC7657, November 2015, 2466 . 2468 [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., 2469 "JavaScript Session Establishment Protocol (JSEP)", 2470 RFC 8829, DOI 10.17487/RFC8829, January 2021, 2471 . 2473 [RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: 2474 Incremental Provisioning of Candidates for the Interactive 2475 Connectivity Establishment (ICE) Protocol", RFC 8838, 2476 DOI 10.17487/RFC8838, January 2021, 2477 . 2479 Appendix A. Design Considerations 2481 One of the main issues regarding the BUNDLE grouping extensions has 2482 been whether, in offers and answers, the same port value can be 2483 inserted in "m=" lines associated with a BUNDLE group, as the purpose 2484 of the extension is to negotiate the usage of a single transport for 2485 media specified by the "m=" sections. Issues with both approaches, 2486 discussed in the Appendix, have been raised. The outcome was to 2487 specify a mechanism that uses offers with both different and 2488 identical port values. 2490 Below are the primary issues that have been considered when defining 2491 the "BUNDLE" grouping extension: 2493 1) Interoperability with existing User Agents (UAs). 2495 2) Interoperability with intermediary Back-to-Back User Agent 2496 (B2BUA) and proxy entities. 2498 3) Time to gather, and the number of, ICE candidates. 2500 4) Different error scenarios and when they occur. 2502 5) SDP offer/answer impacts, including usage of port number value 2503 zero. 2505 A.1. UA Interoperability 2507 Consider the following SDP offer/answer exchange, where Alice sends 2508 an offer to Bob: 2510 SDP Offer 2511 v=0 2512 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2513 s= 2514 c=IN IP4 atlanta.example.com 2515 t=0 0 2517 m=audio 10000 RTP/AVP 97 2518 a=rtpmap:97 iLBC/8000 2519 m=video 10002 RTP/AVP 97 2520 a=rtpmap:97 H261/90000 2522 SDP Answer 2524 v=0 2525 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2526 s= 2527 c=IN IP4 biloxi.example.com 2528 t=0 0 2530 m=audio 20000 RTP/AVP 97 2531 a=rtpmap:97 iLBC/8000 2532 m=video 20002 RTP/AVP 97 2533 a=rtpmap:97 H261/90000 2535 RFC 4961 specifies a way of doing symmetric RTP, but that is a later 2536 extension to RTP, and Bob cannot assume that Alice supports RFC 4961. 2537 This means that Alice may be sending RTP from a different port than 2538 10000 or 10002 -- some implementations simply send the RTP from an 2539 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2540 way that Bob knows if the packet is to be passed to the video or 2541 audio codec is by looking at the port it was received on. This 2542 prompted some SDP implementations to use a port number as an index to 2543 find the correct "m=" line in the SDP, since each "m"= section 2544 contains a different port number. As a result, some implementations 2545 that do support symmetric RTP and ICE still use an SDP data structure 2546 where SDP with "m=" sections with the same port such as: 2548 SDP Offer 2549 v=0 2550 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2551 s= 2552 c=IN IP4 atlanta.example.com 2553 t=0 0 2555 m=audio 10000 RTP/AVP 97 2556 a=rtpmap:97 iLBC/8000 2557 m=video 10000 RTP/AVP 98 2558 a=rtpmap:98 H261/90000 2560 will result in the second "m=" section being considered an SDP error 2561 because it has the same port as the first line. 2563 A.2. Usage of Port Number Value Zero 2565 In an offer or answer, the media specified by an "m=" section can be 2566 disabled/rejected by setting the port number value to zero. This is 2567 different from, e.g., using the SDP direction attributes, where RTCP 2568 traffic will continue even if the SDP 'inactive' attribute is 2569 indicated for the associated "m=" section. 2571 If each "m=" section associated with a BUNDLE group would contain 2572 different port values, and one of those port values would be used for 2573 a BUNDLE address:port associated with the BUNDLE group, problems 2574 would occur if an endpoint wants to disable/reject the "m=" section 2575 associated with that port, by setting the port value to zero. After 2576 that, no "m=" section would contain the port value that is used for 2577 the BUNDLE address:port. In addition, it is unclear what would 2578 happen to the ICE candidates associated with the "m=" section, as 2579 they are also used for the BUNDLE address:port. 2581 A.3. B2BUA and Proxy Interoperability 2583 Some back-to-back user agents may be configured in a mode where if 2584 the incoming call leg contains an SDP attribute the B2BUA does not 2585 understand, the B2BUA still generates that SDP attribute in the Offer 2586 for the outgoing call leg. Consider a B2BUA that did not understand 2587 the SDP 'rtcp' attribute, defined in RFC 3605, yet acted this way. 2588 Further assume that the B2BUA was configured to tear down any call 2589 where it did not see any RTCP for 5 minutes. In this case, if the 2590 B2BUA received an Offer like: 2592 SDP Offer 2593 v=0 2594 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2595 s= 2596 c=IN IP4 atlanta.example.com 2597 t=0 0 2599 m=audio 49170 RTP/AVP 0 2600 a=rtcp:53020 2602 It would be looking for RTCP on port 49171 but would not see any 2603 because the RTCP would be on port 53020, and after five minutes, it 2604 would tear down the call. Similarly, a B2BUA that did not understand 2605 BUNDLE yet put it in its offer may be looking for media on the wrong 2606 port and tear down the call. It is worth noting that a B2BUA that 2607 generated an Offer with capabilities it does not understand is not 2608 compliant with the specifications. 2610 A.3.1. Traffic Policing 2612 Sometimes intermediaries do not act as B2BUAs, in the sense that they 2613 don't modify SDP bodies nor do they terminate SIP dialogs. However, 2614 they may still use SDP information (e.g., IP address and port) in 2615 order to control traffic gating functions and to set traffic policing 2616 rules. There might be rules that will trigger a session to be 2617 terminated in case media is not sent or received on the ports 2618 retrieved from the SDP. This typically occurs once the session is 2619 already established and ongoing. 2621 A.3.2. Bandwidth Allocation 2623 Sometimes, intermediaries do not act as B2BUAs, in the sense that 2624 they don't modify SDP bodies nor do they terminate SIP dialogs. 2625 However, they may still use SDP information (e.g., codecs and media 2626 types) in order to control bandwidth allocation functions. The 2627 bandwidth allocation is done per "m=" section, which means that it 2628 might not be enough if media specified by all "m=" sections try to 2629 use that bandwidth. That may simply lead to either bad user 2630 experience or termination of the call. 2632 A.4. Candidate Gathering 2634 When using ICE, a candidate needs to be gathered for each port. This 2635 takes approximately 20 ms extra for each extra "m=" section due to 2636 the NAT pacing requirements. All of this gathering can be overlapped 2637 with other things while, e.g., a web page is loading to minimize the 2638 impact. If the client only wants to generate Traversal Using Relays 2639 around NAT (TURN) or STUN ICE candidates for one of the "m=" lines 2640 and then use Trickle ICE [RFC8838] to get the non-host ICE candidates 2641 for the rest of the "m=" sections, it MAY do that and will not need 2642 any additional gathering time. 2644 Some people have suggested a TURN extension to get a bunch of TURN 2645 allocations at once. This would only provide a single STUN result, 2646 so in cases where the other end did not support BUNDLE, it may cause 2647 more use of the TURN server, but it would be quick in the cases where 2648 both sides supported BUNDLE and would fall back to a successful call 2649 in the other cases. 2651 Acknowledgements 2653 The usage of the SDP grouping extension for negotiating bundled media 2654 is based on similar alternatives proposed by Harald Alvestrand and 2655 Cullen Jennings. The BUNDLE extension described in this document is 2656 based on the different alternative proposals, and text (e.g., SDP 2657 examples) has been borrowed (and, in some cases, modified) from those 2658 alternative proposals. 2660 The SDP examples are also modified versions from the ones in the 2661 Alvestrand proposal. 2663 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 2664 Stach, Ari Keränen, Adam Roach, Christian Groves, Roman Shpount, 2665 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin 2666 Uberti, Taylor Brandstetter, Byron Campen, and Eric Rescorla for 2667 reading the text and providing useful feedback. 2669 Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus 2670 Westerlund for providing the text for the section on RTP/RTCP stream 2671 association. 2673 Thanks to Magnus Westerlund, Colin Perkins, and Jonathan Lennox for 2674 providing help and text on the RTP/RTCP procedures. 2676 Thanks to Charlie Kaufman for performing the Sec-Dir review. 2678 Thanks to Linda Dunbar for performing the Gen-ART review. 2680 Thanks to Spotify for providing music for the countless hours of 2681 document editing. 2683 Authors' Addresses 2684 Christer Holmberg 2685 Ericsson 2686 Hirsalantie 11 2687 FI-02420 Jorvas 2688 Finland 2690 Email: christer.holmberg@ericsson.com 2692 Harald Tveit Alvestrand 2693 Google 2694 Kungsbron 2 2695 SE-11122 Stockholm 2696 Sweden 2698 Email: harald@alvestrand.no 2700 Cullen Jennings 2701 Cisco 2702 400 3rd Avenue SW, Suite 350 2703 Calgary AB T2P 4H2 2704 Canada 2706 Email: fluffy@iii.ca