idnits 2.17.1 draft-ietf-mmusic-rfc8843bis-00.txt: -(2330): 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 (6 May 2021) is 1086 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 1630 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 8829 (Obsoleted by RFC 9429) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Obsoletes: 8843 (if approved) H. Alvestrand 5 Updates: 3264, 5888, 7941 (if approved) Google 6 Intended status: Standards Track C. Jennings 7 Expires: 7 November 2021 Cisco 8 6 May 2021 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-rfc8843bis-00 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 7 November 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 . . . . . . . . . . . . . . . . . 19 100 7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 19 101 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 20 102 7.5.1. Adding a Media Description to a BUNDLE Group . . . . 21 103 7.5.2. Moving a Media Description Out of a BUNDLE Group . . 21 104 7.5.3. Disabling a Media Description in a BUNDLE Group . . . 22 105 8. Protocol Identification . . . . . . . . . . . . . . . . . . . 22 106 8.1. STUN, DTLS, and SRTP . . . . . . . . . . . . . . . . . . 23 107 9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 23 108 9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 23 109 9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 24 110 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 111 Description . . . . . . . . . . . . . . . . . . . . . . . 24 112 9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 30 113 9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 31 114 10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 33 115 11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 34 116 12. RTP Header Extensions Consideration . . . . . . . . . . . . . 35 117 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 35 118 13.1. Original Text from RFC 3264, Section 5.1, 2nd 119 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 35 120 13.2. New Text Replacing RFC 3264, Section 5.1, 2nd 121 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 36 122 13.3. Original Text from RFC 3264, Section 8.4, 6th 123 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 36 124 13.4. New Text Replacing RFC 3264, Section 8.4, 6th 125 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 36 126 14. Update to RFC 5888 . . . . . . . . . . . . . . . . . . . . . 37 127 14.1. Original Text from RFC 5888, Section 9.2, 3rd 128 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 37 129 14.2. New Text Replacing RFC 5888, Section 9.2, 3rd 130 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 37 131 15. RTP/RTCP Extensions for identification-tag Transport . . . . 37 132 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 38 133 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 39 134 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 135 16.1. New SDES Item . . . . . . . . . . . . . . . . . . . . . 39 136 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 40 137 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 40 138 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 41 139 17. Security Considerations . . . . . . . . . . . . . . . . . . . 41 140 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 42 141 18.1. Example: Tagged "m=" Section Selections . . . . . . . . 42 142 18.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 44 143 18.3. Example: Offerer Adds a Media Description to a BUNDLE 144 Group . . . . . . . . . . . . . . . . . . . . . . . . . 45 146 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE 147 Group . . . . . . . . . . . . . . . . . . . . . . . . . 47 148 18.5. Example: Offerer Disables a Media Description within a 149 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 49 150 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 151 19.1. Normative References . . . . . . . . . . . . . . . . . . 51 152 19.2. Informative References . . . . . . . . . . . . . . . . . 53 153 Appendix A. Design Considerations . . . . . . . . . . . . . . . 55 154 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 55 155 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 57 156 A.3. B2BUA and Proxy Interoperability . . . . . . . . . . . . 57 157 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 58 158 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 58 159 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 58 160 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59 161 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 163 1. Introduction 165 1.1. Background 167 When the SDP offer/answer mechanism [RFC3264] is used to negotiate 168 the establishment of multimedia communication sessions, if separate 169 transports (5-tuples) are negotiated for each individual media 170 stream, each transport consumes additional resources (especially when 171 Interactive Connectivity Establishment (ICE) [RFC8445] is used). For 172 this reason, it is attractive to use a single transport for multiple 173 media streams. 175 1.2. BUNDLE Mechanism 177 This specification defines a way to use a single transport (BUNDLE 178 transport) for sending and receiving media (bundled media) described 179 by multiple SDP media descriptions ("m=" sections). The address:port 180 combination used by an endpoint for sending and receiving bundled 181 media is referred to as the BUNDLE address:port. The set of SDP 182 attributes that are applied to each "m=" section within a BUNDLE 183 group is referred to as BUNDLE attributes. The same BUNDLE transport 184 is used for sending and receiving bundled media, which means that the 185 symmetric Real-time Transport Protocol (RTP) mechanism [RFC4961] is 186 always used for RTP-based bundled media. 188 This specification defines a new SDP Grouping Framework [RFC5888] 189 extension called 'BUNDLE'. The extension can be used with the 190 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 191 to negotiate which "m=" sections will become part of a BUNDLE group. 192 In addition, the offerer and answerer [RFC3264] use the BUNDLE 193 extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE 194 address:port and answerer BUNDLE address:port) and the set of BUNDLE 195 attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) 196 that will be applied to each "m=" section within the BUNDLE group. 198 The use of a BUNDLE transport allows the usage of a single set of ICE 199 [RFC8445] candidates for the whole BUNDLE group. 201 A given BUNDLE address:port MUST only be associated with a single 202 BUNDLE group. If an SDP offer or SDP answer (hereafter referred to 203 as "offer" and "answer") contains multiple BUNDLE groups, the 204 procedures in this specification apply to each group independently. 205 All RTP-based bundled media associated with a given BUNDLE group 206 belong to a single RTP session [RFC3550]. 208 The BUNDLE extension is backward compatible. Endpoints that do not 209 support the extension are expected to generate offers and answers 210 without an SDP 'group:BUNDLE' attribute and assign a unique 211 address:port to each "m=" section within an offer and answer, 212 according to the procedures in [RFC3264] and [RFC4566]. 214 1.3. Protocol Extensions 216 In addition to defining the new SDP Grouping Framework extension, 217 this specification defines the following protocol extensions and RFC 218 updates. This specification: 220 * defines a new SDP attribute, 'bundle-only', which can be used to 221 request that a specific "m=" section (and the associated media) be 222 used only if kept within a BUNDLE group. 224 * updates RFC 3264 [RFC3264], to also allow assigning a zero port 225 value to an "m=" section in cases where the media described by the 226 "m=" section is not disabled or rejected. 228 * defines a new RTCP [RFC3550] SDES item, 'MID', and a new RTP SDES 229 header extension that can be used to associate RTP streams with 230 "m=" sections. 232 * updates [RFC7941] by adding an exception, for the MID RTP header 233 extension, to the requirement regarding protection of an SDES RTP 234 header extension carrying an SDES item for the MID RTP header 235 extension. 237 1.4. Changes from RFC 8843 239 When RFC 8843 and [RFC8829] were published an inconsistency between 240 the specifications was identified. The procedures regarding 241 assigning the port value to a bundled "m=" section in an answer 242 (initial or subsequent) and a subsequent offer were inconsistent. At 243 the IETF 110 meeting it was agreed to publish new versions of the 244 RFCs, in which the inconsistency is removed. This specification 245 removes the inconsistency by aligning the port value assignment 246 procedure with the procedure in RFC 8829. 248 In addition, this document implements the following erratas: 6431, 249 6437 251 2. Terminology 253 "m=" section: SDP bodies contain one or more media descriptions, 254 referred to as "m=" sections. Each "m=" section is represented 255 by an SDP "m=" line and zero or more SDP attributes associated 256 with the "m=" line. A local address:port combination is 257 assigned to each "m=" section. 259 5-tuple: A collection of the following values: source address, 260 source port, destination address, destination port, and 261 transport-layer protocol. 263 Unique address:port: An address:port combination that is assigned 264 to only one "m=" section in an offer or answer. 266 Offerer BUNDLE-tag: The first identification-tag in a given SDP 267 'group:BUNDLE' attribute identification-tag list in an offer. 269 Answerer BUNDLE-tag: The first identification-tag in a given SDP 270 'group:BUNDLE' attribute identification-tag list in an answer. 272 Suggested offerer-tagged "m=" section: The bundled "m=" section 273 identified by the offerer BUNDLE-tag in an initial BUNDLE 274 offer, before a BUNDLE group has been negotiated. 276 Offerer-tagged "m=" section: The bundled "m=" section identified 277 by the offerer BUNDLE-tag in a subsequent offer. The "m=" 278 section contains characteristics (offerer BUNDLE address:port 279 and offerer BUNDLE attributes) that are applied to each "m=" 280 section within the BUNDLE group. 282 Answerer-tagged "m=" section: The bundled "m=" section identified 283 by the answerer BUNDLE-tag in an answer (initial BUNDLE answer 284 or subsequent). The "m=" section contains characteristics 285 (answerer BUNDLE address:port and answerer BUNDLE attributes) 286 that are applied to each "m=" section within the BUNDLE group. 288 BUNDLE address:port: An address:port combination that an endpoint 289 uses for sending and receiving bundled media. 291 Offerer BUNDLE address:port: The address:port combination used by 292 the offerer for sending and receiving media. 294 Answerer BUNDLE address:port: The address:port combination used 295 by the answerer for sending and receiving media. 297 BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category 298 SDP attributes. Once a BUNDLE group has been created, the 299 attribute values apply to each bundled "m=" section within the 300 BUNDLE group. 302 Offerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing 303 category SDP attributes included in the offerer-tagged "m=" 304 section. 306 Answerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing 307 category SDP attributes included in the answerer-tagged "m=" 308 section. 310 BUNDLE transport: The transport (5-tuple) used by all media 311 described by the "m=" sections within a BUNDLE group. 313 BUNDLE group: A set of bundled "m=" sections, created using an 314 SDP offer/answer exchange, that uses a single BUNDLE transport, 315 and a single set of BUNDLE attributes, for sending and 316 receiving all media (bundled media) described by the set of 317 "m=" sections. The same BUNDLE transport is used for sending 318 and receiving bundled media. 320 Bundled "m=" section: An "m=" section, whose identification-tag 321 is placed in an SDP 'group:BUNDLE' attribute identification-tag 322 list in an offer or answer. 324 Bundle-only "m=" section: A bundled "m=" section that contains an 325 SDP 'bundle-only' attribute. 327 Bundled media: All media associated with a given BUNDLE group. 329 Initial BUNDLE offer: The first offer, within an SDP session 330 (e.g., a SIP dialog when SIP [RFC3261] is used to carry SDP), 331 in which the offerer indicates that it wants to negotiate a 332 given BUNDLE group. 334 Initial BUNDLE answer: The answer to an initial BUNDLE offer in 335 which the offerer indicates that it wants to negotiate a BUNDLE 336 group, and the answerer accepts the creation of the BUNDLE 337 group. The BUNDLE group is created once the answerer sends the 338 initial BUNDLE answer. 340 Subsequent offer: An offer that contains a BUNDLE group that has 341 been created as part of a previous offer/answer exchange. 343 Subsequent answer: An answer to a subsequent offer. 345 Identification-tag: A unique token value that is used to identify 346 an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" 347 section carries the unique identification-tag assigned to that 348 "m=" section. The session-level SDP 'group' attribute 349 [RFC5888] carries a list of identification-tags, identifying 350 the "m=" sections associated with that particular 'group' 351 attribute. 353 3. Conventions 355 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 356 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 357 "OPTIONAL" in this document are to be interpreted as described in 358 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 359 capitals, as shown here. 361 4. Applicability Statement 363 The mechanism in this specification only applies to SDP [RFC4566], 364 when used together with the SDP offer/answer mechanism [RFC3264]. 365 Declarative usage of SDP is out of scope of this document and is thus 366 undefined. 368 5. SDP Grouping Framework BUNDLE Extension 370 This section defines a new SDP Grouping Framework [RFC5888] 371 extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP 372 offer/answer mechanism to negotiate a set of "m=" sections that will 373 become part of a BUNDLE group. Within a BUNDLE group, each "m=" 374 section uses a BUNDLE transport for sending and receiving bundled 375 media. Each endpoint uses a single address:port combination for 376 sending and receiving the bundled media. 378 The BUNDLE extension is indicated using an SDP 'group' attribute with 379 a semantics value [RFC5888] of "BUNDLE". An identification-tag is 380 assigned to each bundled "m=" section, and each identification-tag is 381 listed in the SDP 'group:BUNDLE' attribute identification-tag list. 382 Each "m=" section whose identification-tag is listed in the 383 identification-tag list is associated with a given BUNDLE group. 385 SDP bodies can contain multiple BUNDLE groups. Any given bundled 386 "m=" section MUST NOT be associated with more than one BUNDLE group 387 at any given time. 389 NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' 390 attribute identification-tag list does not have to be the same as the 391 order in which the "m=" sections occur in the SDP. 393 The multiplexing category [RFC8859] for the 'group:BUNDLE' attribute 394 is 'NORMAL'. 396 Section 7 defines the detailed SDP offer/answer procedures for the 397 BUNDLE extension. 399 6. SDP 'bundle-only' Attribute 401 This section defines a new SDP media-level attribute [RFC4566], 402 'bundle-only'. 'bundle-only' is a property attribute [RFC4566] and 403 hence has no value. 405 In order to ensure that an answerer that does not support the BUNDLE 406 extension always rejects a bundled "m=" section in an offer, the 407 offerer can assign a zero port value to the "m=" section. According 408 to [RFC3264], an answerer will reject such an "m=" section. By 409 including an SDP 'bundle-only' attribute in a bundled "m=" section, 410 the offerer can request that the answerer accepts the "m=" section 411 only if the answerer supports the BUNDLE extension and if the 412 answerer keeps the "m=" section within the associated BUNDLE group. 414 Name: bundle-only 416 Value: N/A 418 Usage Level: media 420 Charset Dependent: no 422 Example: a=bundle-only 424 The usage of the 'bundle-only' attribute is only defined for a 425 bundled "m=" section with a zero port value. Other usage is 426 unspecified. If an offerer or answerer receives a 'bundle-only' 427 attribute in a non-bundled "m=" section the offerer or answerer MUST 428 discard the attribute. 430 Section 7 defines the detailed SDP offer/answer procedures for the 431 'bundle-only' attribute. 433 7. SDP Offer/Answer Procedures 435 This section describes the SDP offer/answer [RFC3264] procedures for: 437 * Negotiating a BUNDLE group; 439 * Suggesting and selecting the tagged "m=" sections (offerer-tagged 440 "m=" section and answerer-tagged "m=" section); 442 * Adding an "m=" section to a BUNDLE group; 444 * Moving an "m=" section out of a BUNDLE group; and 446 * Disabling an "m=" section within a BUNDLE group. 448 The generic rules and procedures defined in [RFC3264] and [RFC5888] 449 also apply to the BUNDLE extension. For example, if an offer is 450 rejected by the answerer, the previously negotiated addresses:ports, 451 SDP parameters, and characteristics (including those associated with 452 a BUNDLE group) apply. Hence, if an offerer generates an offer in 453 order to negotiate a BUNDLE group, and the answerer rejects the 454 offer, the BUNDLE group is not created. 456 The procedures in this section are independent of the media type or 457 "m=" line proto value assigned to a bundled "m=" section. Section 6 458 defines additional considerations for the usage of the SDP 'bundle- 459 only' attribute. Section 9 defines additional considerations for 460 RTP-based media. Section 10 defines additional considerations for 461 the usage of the ICE [RFC8445] mechanism. 463 Offers and answers can contain multiple BUNDLE groups. The 464 procedures in this section apply independently to a given BUNDLE 465 group. 467 7.1. Generic SDP Considerations 469 This section describes generic restrictions associated with the usage 470 of SDP parameters within a BUNDLE group. It also describes how to 471 calculate a value for the whole BUNDLE group, when parameter and 472 attribute values have been assigned to each bundled "m=" section. 474 7.1.1. Connection Data ("c=") 476 The "c=" line nettype value [RFC4566] associated with a bundled "m=" 477 section MUST be 'IN'. 479 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" 480 section MUST be 'IP4' or 'IP6'. The same value MUST be associated 481 with each "m=" section. 483 NOTE: Extensions to this specification can specify usage of the 484 BUNDLE mechanism for other nettype and addrtype values than the ones 485 listed above. 487 7.1.2. Bandwidth ("b=") 489 An offerer and answerer MUST use the rules and restrictions defined 490 in [RFC8859] for associating the SDP bandwidth ("b=") line with 491 bundled "m=" sections. 493 7.1.3. Attributes ("a=") 495 An offerer and answerer MUST include SDP attributes in every bundled 496 "m=" section where applicable, following the normal offer/answer 497 procedures for each attribute, with the following exceptions: 499 * In the initial BUNDLE offer, the offerer MUST NOT include 500 IDENTICAL and TRANSPORT multiplexing category SDP attributes 501 (BUNDLE attributes) in bundle-only "m=" sections. The offerer 502 MUST include such attributes in all other bundled "m=" sections. 503 In the initial BUNDLE offer, each bundled "m=" line can contain a 504 different set of BUNDLE attributes and attribute values. Once the 505 offerer-tagged "m=" section has been selected, the BUNDLE 506 attributes contained in the offerer-tagged "m=" section will apply 507 to each bundled "m=" section within the BUNDLE group. 509 * In a subsequent offer, or in an answer (initial of subsequent), 510 the offerer and answerer MUST include IDENTICAL and TRANSPORT 511 multiplexing category SDP attributes (BUNDLE attributes) only in 512 the tagged "m=" section (offerer-tagged "m=" section or answerer- 513 tagged "m=" section). The offerer and answerer MUST NOT include 514 such attributes in any other bundled "m=" section. The BUNDLE 515 attributes contained in the tagged "m=" section will apply to each 516 bundled "m=" section within the BUNDLE group. 518 * In an offer (initial BUNDLE offer or subsequent), or in an answer 519 (initial BUNDLE answer or subsequent), the offerer and answerer 520 MUST include SDP attributes from categories other than IDENTICAL 521 and TRANSPORT in each bundled "m=" section that a given attribute 522 applies to. Each bundled "m=" line can contain a different set of 523 such attributes, and attribute values, as such attributes only 524 apply to the given bundled "m=" section in which they are 525 included. 527 NOTE: A consequence of the rules above is that media-specific 528 IDENTICAL and TRANSPORT multiplexing category SDP attributes that are 529 applicable only to some of the bundled "m=" sections within the 530 BUNDLE group might appear in the tagged "m=" section for which they 531 are not applicable. For instance, the tagged "m=" section might 532 contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section 533 does not describe RTP-based media (but another bundled "m=" section 534 within the BUNDLE group does describe RTP-based media). 536 7.2. Generating the Initial SDP Offer 538 The procedures in this section apply to the first offer, within an 539 SDP session (e.g., a SIP dialog when SIP [RFC3261] is used to carry 540 SDP), in which the offerer indicates that it wants to negotiate a 541 given BUNDLE group. This could occur in the initial offer, or in a 542 subsequent offer, of the SDP session. 544 When an offerer generates an initial BUNDLE offer, in order to 545 negotiate a BUNDLE group, it MUST: 547 * Assign a unique address:port to each bundled "m=" section, 548 following the procedures in [RFC3264], excluding any bundle-only 549 "m=" sections (see below); 551 * Pick a bundled "m=" section as the suggested offerer-tagged "m=" 552 (Section 7.2.1); 554 * Include SDP attributes in the bundled "m=" sections following the 555 rules in Section 7.1.3; 557 * Include an SDP 'group:BUNDLE' attribute in the offer; and 559 * Place the identification-tag of each bundled "m=" section in the 560 SDP 'group:BUNDLE' attribute identification-tag list. The offerer 561 BUNDLE-tag indicates the suggested offerer-tagged "m=" section. 563 NOTE: When the offerer assigns unique addresses:ports to multiple 564 bundled "m=" sections, the offerer needs to be prepared to receive 565 bundled media on each unique address:port, until it receives the 566 associated answer and finds out which bundled "m=" section (and 567 associated address:port combination) the answerer has selected as the 568 offerer-tagged "m=" section. 570 If the offerer wants to request that the answerer accepts a given 571 bundled "m=" section only if the answerer keeps the "m=" section 572 within the negotiated BUNDLE group, the offerer MUST: 574 * Include an SDP 'bundle-only' attribute (Section 7.2.1) in the "m=" 575 section, and 577 * Assign a zero port value to the "m=" section. 579 NOTE: If the offerer assigns a zero port value to a bundled "m=" 580 section, but does not include an SDP 'bundle-only' attribute in the 581 "m=" section, it is an indication that the offerer wants to disable 582 the "m=" section (Section 7.5.3). 584 Sections 7.2.2 and 18.1 show an example of an initial BUNDLE offer. 586 7.2.1. Suggesting the Offerer-Tagged 'm=' Section 588 In the initial BUNDLE offer, the bundled "m=" section indicated by 589 the offerer BUNDLE-tag is the suggested offerer-tagged "m=" section. 590 The address:port combination associated with the "m=" section will be 591 used by the offerer for sending and receiving bundled media if the 592 answerer selects the "m=" section as the offerer-tagged "m=" section 593 (Section 7.3.1). In addition, if the answerer selects the "m=" 594 section as the offerer-tagged "m=" section, the BUNDLE attributes 595 included in the "m=" section will be applied to each "m=" section 596 within the negotiated BUNDLE group. 598 The offerer MUST NOT suggest a bundle-only "m=" section as the 599 offerer-tagged "m=" section. 601 It is RECOMMENDED that the suggested offerer-tagged "m=" section be a 602 bundled "m=" section that the offerer believes is unlikely that the 603 answerer will reject or move out of the BUNDLE group. How such 604 assumption is made is outside the scope of this document. 606 7.2.2. Example: Initial SDP Offer 608 The example shows an initial BUNDLE offer. The offer includes two 609 "m=" sections in the offer and suggests that both "m=" sections are 610 included in a BUNDLE group. The audio "m=" section is the suggested 611 offerer-tagged "m=" section, indicated by placing the identification- 612 tag associated with the "m=" section (offerer BUNDLE-tag) first in 613 the SDP group:BUNDLE attribute identification-id list. 615 SDP Offer 617 v=0 618 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 619 s= 620 c=IN IP6 2001:db8::3 621 t=0 0 622 a=group:BUNDLE foo bar 624 m=audio 10000 RTP/AVP 0 8 97 625 b=AS:200 626 a=mid:foo 627 a=rtcp-mux 628 a=rtpmap:0 PCMU/8000 629 a=rtpmap:8 PCMA/8000 630 a=rtpmap:97 iLBC/8000 631 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 633 m=video 10002 RTP/AVP 31 32 634 b=AS:1000 635 a=mid:bar 636 a=rtcp-mux 637 a=rtpmap:31 H261/90000 638 a=rtpmap:32 MPV/90000 639 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 641 7.3. Generating the SDP Answer 643 When an answerer generates an answer (initial BUNDLE answer or 644 subsequent) that contains a BUNDLE group, the following general SDP 645 Grouping Framework restrictions, defined in [RFC5888], also apply to 646 the BUNDLE group: 648 * The answerer is only allowed to include a BUNDLE group in an 649 initial BUNDLE answer if the offerer requested the BUNDLE group to 650 be created in the corresponding initial BUNDLE offer; 652 * The answerer is only allowed to include a BUNDLE group in a 653 subsequent answer if the corresponding subsequent offer contains a 654 previously negotiated BUNDLE group; 656 * The answerer is only allowed to include a bundled "m=" section in 657 an answer if the "m=" section was indicated as bundled in the 658 corresponding offer; and 660 * The answerer is only allowed to include a bundled "m=" section in 661 the same BUNDLE group as the bundled "m=" line in the 662 corresponding offer. 664 In addition, when an answerer generates an answer (initial BUNDLE 665 answer or subsequent) that contains a BUNDLE group, the answerer 666 MUST: 668 * In case of an initial BUNDLE answer, select the offerer-tagged 669 "m=" section using the procedures in Section 7.3.1. In case of a 670 subsequent answer, the offerer-tagged "m=" section is indicated in 671 the corresponding subsequent offer and MUST NOT be changed by the 672 answerer; 674 * Select the answerer-tagged "m=" section (Section 7.3.1); 676 * Assign the answerer BUNDLE address:port to the answerer-tagged 677 "m=" section, and to every other bundled "m=" section within the 678 BUNDLE group; 680 * Include SDP attributes in the bundled "m=" sections following the 681 rules in Section 7.1.3; 683 * Include an SDP 'group:BUNDLE' attribute in the answer; and 685 * Place the identification-tag of each bundled "m=" section in the 686 SDP 'group:BUNDLE' attribute identification-tag list. The 687 answerer BUNDLE-tag indicates the answerer-tagged "m=" section 688 (Section 7.3.1). 690 If the answerer does not want to keep an "m=" section within a BUNDLE 691 group, it MUST: 693 * Move the "m=" section out of the BUNDLE group (Section 7.3.2); or 695 * Reject the "m=" section (Section 7.3.3). 697 The answerer can modify the answerer BUNDLE address:port, add and 698 remove SDP attributes, or modify SDP attribute values in a subsequent 699 answer. Changes to the answerer BUNDLE address:port and the answerer 700 BUNDLE attributes will be applied to each bundled "m=" section within 701 the BUNDLE group. 703 NOTE: If a bundled "m=" section in an offer contains a zero port 704 value, but the "m=" section does not contain an SDP 'bundle-only' 705 attribute, it is an indication that the offerer wants to disable the 706 "m=" section (Section 7.5.3). 708 NOTE: In RFC 8843, instead of assigning the offerer BUNDLE 709 address:port to each "m=" section within the BUNDLE group when 710 modifying the session (Section 7.5), the offerer only assigned the 711 offerer BUNDLE address:port to the offerer-tagged "m=" section. For 712 every other "m=" section within the BUNDLE group, the offerer 713 included an SDP 'bundle-only' attribute in, and assigned a zero port 714 value to, the "m=" section. In order to be backward compatible with 715 offerers that implement that version of the specification, an 716 answerer SHOULD accept such offers. 718 7.3.1. Answerer Selection of Tagged 'm=' Sections 720 When selecting the offerer-tagged "m=" section, the answerer MUST 721 first check whether the "m=" section fulfills the following criteria 722 Section 7.2.1: 724 * The answerer will not move the "m=" section out of the BUNDLE 725 group (Section 7.3.2); 727 * The answerer will not reject the "m=" section (Section 7.3.3); and 729 * The "m=" section does not contain a zero port value. 731 If all of the criteria above are fulfilled, the answerer MUST select 732 the "m=" section as the offerer-tagged "m=" section and MUST also 733 mark the corresponding "m=" section in the answer as the answerer- 734 tagged "m=" section. In the answer, the answerer BUNDLE-tag 735 indicates the answerer-tagged "m=" section. 737 If one or more of the criteria are not fulfilled, the answerer MUST 738 pick the next identification-tag in the identification-tag list in 739 the offer and perform the same criteria check for the "m=" section 740 indicated by that identification-tag. If there are no more 741 identification-tags in the identification-tag list, the answerer MUST 742 NOT create the BUNDLE group. Unless the answerer rejects the whole 743 offer, the answerer MUST apply the answerer procedures for moving an 744 "m=" section out of a BUNDLE group (Section 7.3.2) or rejecting an 745 "m=" section within a BUNDLE group (Section 7.3.3) to every bundled 746 "m=" section in the offer when creating the answer. 748 Section 18.1 shows an example of an offerer BUNDLE address:port 749 selection. 751 Sections 7.3.4 and 18.1 show an example of an answerer-tagged "m=" 752 section selection. 754 7.3.2. Moving a Media Description Out of a BUNDLE Group 756 When an answerer generates the answer, if the answerer wants to move 757 a bundled "m=" section out of the negotiated BUNDLE group, the 758 answerer MUST first check the following criteria: 760 * In the corresponding offer, the "m=" section is within a 761 previously negotiated BUNDLE group, and 763 * In the corresponding offer, the "m=" section contains an SDP 764 'bundle-only' attribute. 766 If either criterion above is fulfilled, the answerer cannot move the 767 "m=" section out of the BUNDLE group in the answer. The answerer can 768 reject the whole offer, reject each bundled "m=" section within the 769 BUNDLE group (Section 7.3.3), or keep the "m=" section within the 770 BUNDLE group in the answer and later create an offer where the "m=" 771 section is moved out of the BUNDLE group (Section 7.5.2). 773 NOTE: One consequence of the rules above is that, once a BUNDLE group 774 has been negotiated, a bundled "m=" section cannot be moved out of 775 the BUNDLE group in an answer. Instead, an offer is needed. 777 When the answerer generates an answer, in which it moves a bundled 778 "m=" section out of a BUNDLE group, the answerer: 780 * MUST assign a unique address:port to the "m=" section; 782 * MUST include any applicable SDP attribute in the "m=" section, 783 using the normal offer/answer procedures for each attribute; 785 * MUST NOT place the identification-tag associated with the "m=" 786 section in the SDP 'group:BUNDLE' attribute identification-tag 787 list associated with the BUNDLE group; and 789 * MUST NOT include an SDP 'bundle-only' attribute to the "m=" 790 section. 792 Because an answerer is not allowed to move an "m=" section from one 793 BUNDLE group to another within an answer (Section 7.3), if the 794 answerer wants to move an "m=" section from one BUNDLE group to 795 another, it MUST first move the "m=" section out of the current 796 BUNDLE group and then generate an offer where the "m=" section is 797 added to another BUNDLE group (Section 7.5.1). 799 7.3.3. Rejecting a Media Description in a BUNDLE Group 801 When an answerer wants to reject a bundled "m=" section in an answer, 802 it MUST first check the following criterion: 804 * In the corresponding offer, the "m=" section is the offerer-tagged 805 "m=" section. 807 If the criterion above is fulfilled, the answerer cannot reject the 808 "m=" section in the answer. The answerer can reject the whole offer, 809 reject each bundled "m=" section within the BUNDLE group, or keep the 810 "m=" section within the BUNDLE group in the answer and later create 811 an offer where the "m=" section is disabled within the BUNDLE group 812 (Section 7.5.3). 814 When an answerer generates an answer, in which it rejects a bundled 815 "m=" section, the answerer: 817 * MUST assign a zero port value to the "m=" section, according to 818 the procedures in [RFC3264]; 820 * MUST NOT place the identification-tag associated with the "m=" 821 section in the SDP 'group:BUNDLE' attribute identification-tag 822 list associated with the BUNDLE group; and 824 * MUST NOT include an SDP 'bundle-only' attribute in the "m=" 825 section. 827 7.3.4. Example: SDP Answer 829 The example below shows an answer, based on the corresponding offer 830 in Section 7.2.2. The answerer accepts both bundled "m=" sections 831 within the created BUNDLE group. The audio "m=" section is the 832 answerer-tagged "m=" section, indicated by placing the 833 identification-tag associated with the "m=" section (answerer BUNDLE- 834 tag) first in the SDP group;BUNDLE attribute identification-id list. 836 SDP Answer 838 v=0 839 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 840 s= 841 c=IN IP6 2001:db8::1 842 t=0 0 843 a=group:BUNDLE foo bar 845 m=audio 20000 RTP/AVP 0 846 b=AS:200 847 a=mid:foo 848 a=rtcp-mux 849 a=rtpmap:0 PCMU/8000 850 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 852 m=video 20000 RTP/AVP 32 853 b=AS:1000 854 a=mid:bar 855 a=rtpmap:32 MPV/90000 856 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 858 7.4. Offerer Processing of the SDP Answer 860 When an offerer receives an answer, if the answer contains a BUNDLE 861 group, the offerer MUST check that any bundled "m=" section in the 862 answer was indicated as bundled in the corresponding offer. If there 863 is no mismatch, the offerer MUST apply the properties (BUNDLE 864 address:port, BUNDLE attributes, etc.) of the offerer-tagged "m=" 865 section (selected by the answerer; see Section 7.3.1) to each bundled 866 "m=" section within the BUNDLE group. 868 NOTE: As the answerer might reject one or more bundled "m=" sections 869 in an initial BUNDLE offer, or move a bundled "m=" section out of a 870 BUNDLE group, a given bundled "m=" section in the offer might not be 871 indicated as bundled in the corresponding answer. 873 If the answer does not contain a BUNDLE group, the offerer MUST 874 process the answer as a normal answer. 876 NOTE: In RFC 8843, instead of assigning the answerer BUNDLE 877 address:port to each "m=" section within the BUNDLE group when 878 generating the answer (Section 7.3), the answerer only assigned the 879 answerer BUNDLE address:port to the answerer-tagged "m=" section. 880 For every other "m=" section within the BUNDLE group, the answerer 881 included an SDP 'bundle-only' attribute in, and assigned a zero port 882 value to, the "m=" section. In order to be backward compatible with 883 answerers that implement that version of the specification, an 884 offerer SHOULD accept such answers. 886 7.5. Modifying the Session 888 When a BUNDLE group has been previously negotiated, and an offerer 889 generates a subsequent offer, the offerer MUST: 891 * Pick one bundled "m=" section as the offerer-tagged "m=" section. 892 The offerer can pick either the "m=" section that was previously 893 selected by the answerer as the offerer-tagged "m=" section or 894 another bundled "m=" section within the BUNDLE group; 896 * Assign a BUNDLE address:port (previously negotiated or newly 897 suggested) to the offerer-tagged "m=" section, and to every other 898 bundled "m=" section within the BUNDLE group; 900 * Include SDP attributes in the bundled "m=" sections following the 901 rules in Section 7.1.3; 903 * Include an SDP 'group:BUNDLE' attribute in the offer; and 905 * Place the identification-tag of each bundled "m=" section in the 906 SDP 'group:BUNDLE' attribute identification-tag list. The offerer 907 BUNDLE-tag indicates the offerer-tagged "m=" section. 909 The offerer MUST NOT pick a given bundled "m=" section as the 910 offerer-tagged "m=" section if: 912 * The offerer wants to move the "m=" section out of the BUNDLE group 913 (Section 7.5.2), or 915 * The offerer wants to disable the "m=" section (Section 7.5.3). 917 The offerer can modify the offerer BUNDLE address:port, add and 918 remove SDP attributes, or modify SDP attribute values in the 919 subsequent offer. Changes to the offerer BUNDLE address:port and the 920 offerer BUNDLE attributes will (if the offer is accepted by the 921 answerer) be applied to each bundled "m=" section within the BUNDLE 922 group. 924 7.5.1. Adding a Media Description to a BUNDLE Group 926 When an offerer generates a subsequent offer, in which it wants to 927 add a bundled "m=" section to a previously negotiated BUNDLE group, 928 the offerer follows the procedures in Section 7.5. The offerer picks 929 either the added "m=" section or an "m=" section previously added to 930 the BUNDLE group as the offerer-tagged "m=" section. 932 NOTE: As described in Section 7.3.2, the answerer cannot move the 933 added "m=" section out of the BUNDLE group in its answer. If the 934 answer wants to move the "m=" section out of the BUNDLE group, it 935 will have to first accept it into the BUNDLE group in the answer, and 936 then send a subsequent offer where the "m=" section is moved out of 937 the BUNDLE group (Section 7.5.2). 939 7.5.2. Moving a Media Description Out of a BUNDLE Group 941 When an offerer generates a subsequent offer, in which it wants to 942 remove a bundled "m=" section from a BUNDLE group, the offerer: 944 * MUST assign a unique address:port to the "m=" section; 946 * MUST include SDP attributes in the "m=" section following the 947 normal offer/answer rules for each attribute; 949 * MUST NOT place the identification-tag associated with the "m=" 950 section in the SDP 'group:BUNDLE' attribute identification-tag 951 list associated with the BUNDLE group; and 953 * MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 954 section. 956 For the other bundled "m=" sections within the BUNDLE group, the 957 offerer follows the procedures in Section 7.5. 959 An offerer MUST NOT move an "m=" section from one BUNDLE group to 960 another within a single offer. If the offerer wants to move an "m=" 961 section from one BUNDLE group to another, it MUST first move the 962 BUNDLE group out of the current BUNDLE group, and then generate a 963 second offer where the "m=" section is added to another BUNDLE group 964 (Section 7.5.1). 966 Section 18.4 shows an example of an offer for moving an "m=" section 967 out of a BUNDLE group. 969 7.5.3. Disabling a Media Description in a BUNDLE Group 971 When an offerer generates a subsequent offer, in which it wants to 972 disable a bundled "m=" section from a BUNDLE group, the offerer: 974 * MUST assign a zero port value to the "m=" section, following the 975 procedures in [RFC4566]; 977 * MUST NOT place the identification-tag associated with the "m=" 978 section in the SDP 'group:BUNDLE' attribute identification-tag 979 list associated with the BUNDLE group; and 981 * MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 982 section. 984 For the other bundled "m=" sections within the BUNDLE group, the 985 offerer follows the procedures in Section 7.5. 987 Section 18.5 shows an example of an offer and answer for disabling an 988 "m=" section within a BUNDLE group. 990 8. Protocol Identification 992 Each "m=" section within a BUNDLE group MUST use the same transport- 993 layer protocol. If bundled "m=" sections use different upper-layer 994 protocols on top of the transport-layer protocol, there MUST exist a 995 publicly available specification that describes how a mechanism 996 associates received data with the correct protocol for this 997 particular protocol combination. 999 In addition, if received data can be associated with more than one 1000 bundled "m=" section, there MUST exist a publicly available 1001 specification that describes a mechanism for associating the received 1002 data with the correct "m=" section. 1004 This document describes a mechanism to identify the protocol of 1005 received data among the Session Traversal Utilities for NAT (STUN), 1006 DTLS, and the Secure Real-time Transport Protocol (SRTP) (in any 1007 combination) when UDP is used as a transport-layer protocol, but it 1008 does not describe how to identify different protocols transported on 1009 DTLS. While the mechanism is generally applicable to other protocols 1010 and transport-layer protocols, any such use requires further 1011 specification that encompasses how to multiplex multiple protocols on 1012 a given transport-layer protocol and how to associate received data 1013 with the correct protocols. 1015 8.1. STUN, DTLS, and SRTP 1017 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 1018 protocol of a received packet among the STUN, DTLS, and SRTP 1019 protocols (in any combination). If an offer or answer includes a 1020 bundled "m=" section that represents these protocols, the offerer or 1021 answerer MUST support the mechanism described in [RFC5764], and no 1022 explicit negotiation is required in order to indicate support and 1023 usage of the mechanism. 1025 [RFC5764] does not describe how to identify different protocols 1026 transported on DTLS, only how to identify the DTLS protocol itself. 1027 If multiple protocols are transported on DTLS, there MUST exist a 1028 specification describing a mechanism for identifying each individual 1029 protocol. In addition, if a received DTLS packet can be associated 1030 with more than one "m=" section, there MUST exist a specification 1031 that describes a mechanism for associating the received DTLS packets 1032 with the correct "m=" section. 1034 Section 9.2 describes how to associate the packets in a received SRTP 1035 stream with the correct "m=" section. 1037 9. RTP Considerations 1039 9.1. Single RTP Session 1041 All RTP-based media within a single BUNDLE group belong to a single 1042 RTP session [RFC3550]. 1044 Since a single BUNDLE transport is used for sending and receiving 1045 bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for 1046 RTP-based bundled media. 1048 Since a single RTP session is used for each BUNDLE group, all "m=" 1049 sections representing RTP-based media within a BUNDLE group will 1050 share a single Synchronization Source (SSRC) numbering space 1051 [RFC3550]. 1053 The following rules and restrictions apply for a single RTP session: 1055 * A specific payload type value can be used in multiple bundled "m=" 1056 sections only if each codec associated with the payload type 1057 number shares an identical codec configuration (Section 9.1.1). 1059 * The proto value in each bundled RTP-based "m=" section MUST be 1060 identical (e.g., RTP/AVPF). 1062 * The RTP MID header extension MUST be enabled, by including an SDP 1063 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 1064 hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section 1065 in every offer and answer. 1067 * A given SSRC MUST NOT transmit RTP packets using payload types 1068 that originate from different bundled "m=" sections. 1070 NOTE: The last bullet above is to avoid sending multiple media types 1071 from the same SSRC. If transmission of multiple media types are done 1072 with time overlap, RTP and RTCP fail to function. Even if done in 1073 proper sequence, this causes RTP timestamp rate switching issues 1074 [RFC7160]. However, once an SSRC has left the RTP session (by 1075 sending an RTCP BYE packet), that SSRC can be reused by another 1076 source (possibly associated with a different bundled "m=" section) 1077 after a delay of 5 RTCP reporting intervals (the delay is to ensure 1078 the SSRC has timed out, in case the RTCP BYE packet was lost 1079 [RFC3550]). 1081 [RFC7657] defines Differentiated Services (Diffserv) considerations 1082 for RTP-based bundled media sent using a mixture of Diffserv 1083 Codepoints. 1085 9.1.1. Payload Type (PT) Value Reuse 1087 Multiple bundled "m=" sections might describe RTP-based media. As 1088 all RTP-based media associated with a BUNDLE group belong to the same 1089 RTP session, in order for a given payload type value to be used 1090 inside more than one bundled "m=" section, all codecs associated with 1091 the payload type number MUST share an identical codec configuration. 1092 This means that the codecs MUST share the same media type, encoding 1093 name, clock rate, and any parameter that can affect the codec 1094 configuration and packetization. [RFC8859] lists SDP attributes, 1095 whose attribute values are required to be identical for all codecs 1096 that use the same payload type value. 1098 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 1099 Description 1101 As described in [RFC3550], RTP packets are associated with RTP 1102 streams [RFC7656]. Each RTP stream is identified by an SSRC value, 1103 and each RTP packet includes an SSRC field that is used to associate 1104 the packet with the correct RTP stream. RTCP packets also use SSRCs 1105 to identify which RTP streams the packet relates to. However, an 1106 RTCP packet can contain multiple SSRC fields, in the course of 1107 providing feedback or reports on different RTP streams, and therefore 1108 can be associated with multiple such streams. 1110 In order to be able to process received RTP/RTCP packets correctly, 1111 it MUST be possible to associate an RTP stream with the correct "m=" 1112 section, as the "m=" section and SDP attributes associated with the 1113 "m=" section contains information needed to process the packets. 1115 As all RTP streams associated with a BUNDLE group use the same 1116 transport for sending and receiving RTP/RTCP packets, the local 1117 address:port combination part of the transport cannot be used to 1118 associate an RTP stream with the correct "m=" section. In addition, 1119 multiple RTP streams might be associated with the same "m=" section. 1121 An offerer and answerer can inform each other which SSRC values they 1122 will use for an RTP stream by using the SDP 'ssrc' attribute 1123 [RFC5576]. However, an offerer will not know which SSRC values the 1124 answerer will use until the offerer has received the answer providing 1125 that information. Due to this, before the offerer has received the 1126 answer, the offerer will not be able to associate an RTP stream with 1127 the correct "m=" section using the SSRC value associated with the RTP 1128 stream. In addition, the offerer and answerer may start using new 1129 SSRC values mid-session, without informing each other about using the 1130 SDP 'ssrc' attribute. 1132 In order for an offerer and answerer to always be able to associate 1133 an RTP stream with the correct "m=" section, the offerer and answerer 1134 using the BUNDLE extension MUST support the mechanism defined in 1135 Section 15, where the offerer and answerer insert the identification- 1136 tag associated with an "m=" section (provided by the remote peer) 1137 into RTP and RTCP packets associated with a BUNDLE group. 1139 When using this mechanism, the mapping from an SSRC to an 1140 identification-tag is carried in RTP header extensions or RTCP SDES 1141 packets, as specified in Section 15. Since a compound RTCP packet 1142 can contain multiple RTCP SDES packets, and each RTCP SDES packet can 1143 contain multiple chunks, a single RTCP packet can contain several 1144 mappings of SSRC to identification-tag. The offerer and answerer 1145 maintain tables used for routing that are updated each time an RTP/ 1146 RTCP packet contains new information that affects how packets are to 1147 be routed. 1149 However, some legacy implementations may not include this 1150 identification-tag in their RTP and RTCP traffic when using the 1151 BUNDLE mechanism and instead use a mechanism based on the payload 1152 type to associate RTP streams with SDP "m=" sections. In this 1153 situation, each "m=" section needs to use unique payload type values, 1154 in order for the payload type to be a reliable indicator of the 1155 relevant "m=" section for the RTP stream. If an implementation fails 1156 to ensure unique payload type values, it will be impossible to 1157 associate the RTP stream using that payload type value to a 1158 particular "m=" section. Note that when using the payload type to 1159 associate RTP streams with "m=" sections, an RTP stream, identified 1160 by its SSRC, will be mapped to an "m=" section when the first packet 1161 of that RTP stream is received, and the mapping will not be changed 1162 even if the payload type used by that RTP stream changes. In other 1163 words, the SSRC cannot "move" to a different "m=" section simply by 1164 changing the payload type. 1166 Applications can implement RTP stacks in many different ways. The 1167 algorithm below details one way that RTP streams can be associated 1168 with "m=" sections, but it is not meant to be prescriptive about 1169 exactly how an RTP stack needs to be implemented. Applications MAY 1170 use any algorithm that achieves equivalent results to those described 1171 in the algorithm below. 1173 To prepare to associate RTP streams with the correct "m=" section, 1174 the following steps MUST be followed for each BUNDLE group: 1176 * Construct a table mapping a MID to an "m=" section for each "m=" 1177 section in this BUNDLE group. Note that an "m=" section may only 1178 have one MID. 1180 * Construct a table mapping SSRCs of incoming RTP streams to an "m=" 1181 section for each "m=" section in this BUNDLE group and for each 1182 SSRC configured for receiving in that "m=" section. 1184 * Construct a table mapping the SSRC of each outgoing RTP stream to 1185 an "m=" section for each "m=" section in this BUNDLE group and for 1186 each SSRC configured for sending in that "m=" section. 1188 * Construct a table mapping a payload type to an "m=" section for 1189 each "m=" section in the BUNDLE group and for each payload type 1190 configured for receiving in that "m=" section. If any payload 1191 type is configured for receiving in more than one "m=" section in 1192 the BUNDLE group, do not include it in the table, as it cannot be 1193 used to uniquely identify an "m=" section. 1195 * Note that for each of these tables, there can only be one mapping 1196 for any given key (MID, SSRC, or PT). In other words, the tables 1197 are not multimaps. 1199 As "m=" sections are added or removed from the BUNDLE groups, or 1200 their configurations are changed, the tables above MUST also be 1201 updated. 1203 When an RTP packet is received, it MUST be delivered to the RTP 1204 stream corresponding to its SSRC. That RTP stream MUST then be 1205 associated with the correct "m=" section within a BUNDLE group, for 1206 additional processing, according to the following steps: 1208 * If the MID associated with the RTP stream is not in the table 1209 mapping a MID to an "m=" section, then the RTP stream is not 1210 decoded and the payload data is discarded. 1212 * If the packet has a MID, and the packet's extended sequence number 1213 is greater than that of the last MID update, as discussed in 1214 [RFC7941], Section 4.2.2, update the MID associated with the RTP 1215 stream to match the MID carried in the RTP packet, and then update 1216 the mapping tables to include an entry that maps the SSRC of that 1217 RTP stream to the "m=" section for that MID. 1219 * If the SSRC of the RTP stream is in the incoming SSRC mapping 1220 table, check that the payload type used by the RTP stream matches 1221 a payload type included on the matching "m=" section. If so, 1222 associate the RTP stream with that "m=" section. Otherwise, the 1223 RTP stream is not decoded and the payload data is discarded. 1225 * If the payload type used by the RTP stream is in the payload type 1226 table, update the incoming SSRC mapping table to include an entry 1227 that maps the RTP stream's SSRC to the "m=" section for that 1228 payload type. Associate the RTP stream with the corresponding 1229 "m=" section. 1231 * Otherwise, mark the RTP stream as "not for decoding" and discard 1232 the payload. 1234 If the RTP packet contains one or more Contributing Source (CSRC) 1235 identifiers, then each CSRC is looked up in the incoming SSRC table, 1236 and a copy of the RTP packet is associated with the corresponding 1237 "m=" section for additional processing. 1239 For each RTCP packet received (including each RTCP packet that is 1240 part of a compound RTCP packet), the packet is processed as usual by 1241 the RTP layer, then associated with the appropriate "m=" sections, 1242 and processed for the RTP streams represented by those "m=" sections. 1243 This routing is type dependent, as each kind of RTCP packet has its 1244 own mechanism for associating it with the relevant RTP streams. 1246 RTCP packets that cannot be associated with an appropriate "m=" 1247 section MUST still be processed as usual by the RTP layer, which 1248 updates the metadata associated with the corresponding RTP streams. 1249 This situation can occur with certain multiparty RTP topologies or 1250 when RTCP packets are sent containing a subset of the SDES 1251 information. 1253 Additional rules for processing various types of RTCP packets are 1254 explained below. 1256 * If the RTCP packet is of type SDES, for each chunk in the packet 1257 whose SSRC is found in the incoming SSRC table, deliver a copy of 1258 the SDES packet to the "m=" section associated with that SSRC. In 1259 addition, for any SDES MID items contained in these chunks, if the 1260 MID is found in the table mapping a MID to an "m=" section, update 1261 the incoming SSRC table to include an entry that maps the RTP 1262 stream associated with the chunk's SSRC to the "m=" section 1263 associated with that MID, unless the packet is older than the 1264 packet that most recently updated the mapping for this SSRC, as 1265 discussed in [RFC7941], Section 4.2.6. 1267 * Note that if an SDES packet is received as part of a compound RTCP 1268 packet, the SSRC to "m=" section mapping might not exist until the 1269 SDES packet is handled (e.g., in the case where RTCP for a source 1270 is received before any RTP packets). Therefore, it can be 1271 beneficial for an implementation to delay RTCP packet routing, 1272 such that it either prioritizes processing of the SDES item to 1273 generate or update the mapping or buffers the RTCP information 1274 that needs to be routed until the SDES item(s) has been processed. 1275 If the implementation is unable to follow this recommendation, the 1276 consequence could be that some RTCP information from this 1277 particular RTCP compound packet is not provided to higher layers. 1278 The impact from this is likely minor, when this information 1279 relates to a future incoming RTP stream. 1281 * If the RTCP packet is of type BYE, it indicates that the RTP 1282 streams referenced in the packet are ending. Therefore, for each 1283 SSRC indicated in the packet that is found in the incoming SSRC 1284 table, first deliver a copy of the BYE packet to the "m=" section 1285 associated with that SSRC, and then remove the entry for that SSRC 1286 from the incoming SSRC table after an appropriate delay to account 1287 for "straggler packets", as specified in [RFC3550], Section 6.2.1. 1289 * If the RTCP packet is of type Sender Report (SR) or Receiver 1290 Report (RR), for each report block in the report whose "SSRC of 1291 source" is found in the outgoing SSRC table, deliver a copy of the 1292 SR or RR packet to the "m=" section associated with that SSRC. In 1293 addition, if the packet is of type SR, and the sender SSRC for the 1294 packet is found in the incoming SSRC table, deliver a copy of the 1295 SR packet to the "m=" section associated with that SSRC. 1297 * If the implementation supports the RTCP Extended Report (XR) and 1298 the packet is of type XR, as defined in [RFC3611], for each report 1299 block in the report whose "SSRC of source" is found in the 1300 outgoing SSRC table, deliver a copy of the XR packet to the "m=" 1301 section associated with that SSRC. In addition, if the sender 1302 SSRC for the packet is found in the incoming SSRC table, deliver a 1303 copy of the XR packet to the "m=" section associated with that 1304 SSRC. 1306 * If the RTCP packet is a feedback message of type RTPFB (transport- 1307 layer FB message) or PSFB (payload-specific FB message), as 1308 defined in [RFC4585], it will contain a media source SSRC, and 1309 this SSRC is used for routing certain subtypes of feedback 1310 messages. However, several subtypes of PSFB and RTPFB messages 1311 include a target SSRC(s) in a section called Feedback Control 1312 Information (FCI). For these messages, the target SSRC(s) is used 1313 for routing. 1315 * If the RTCP packet is a feedback packet that does not include 1316 target SSRCs in its FCI section, and the media source SSRC is 1317 found in the outgoing SSRC table, deliver the feedback packet to 1318 the "m=" section associated with that SSRC. RTPFB and PSFB types 1319 that are handled in this way include: 1321 Generic NACK: (PT=RTPFB, FMT=1) [RFC4585]. 1323 Picture Loss Indication (PLI): (PT=PSFB, FMT=1) [RFC4585]. 1325 Slice Loss Indication (SLI): (PT=PSFB, FMT=2) [RFC4585]. 1327 Reference Picture Selection Indication (RPSI): (PT=PSFB, 1328 FMT=3) [RFC4585]. 1330 * If the RTCP packet is a feedback message that does include a 1331 target SSRC(s) in its FCI section, it can either be a request or a 1332 notification. Requests reference an RTP stream that is being sent 1333 by the message recipient, whereas notifications are responses to 1334 an earlier request and therefore reference an RTP stream that is 1335 being received by the message recipient. 1337 * If the RTCP packet is a feedback request that includes a target 1338 SSRC(s), for each target SSRC that is found in the outgoing SSRC 1339 table, deliver a copy of the RTCP packet to the "m=" section 1340 associated with that SSRC. PSFB and RTPFB types that are handled 1341 in this way include: 1343 Full Intra Request (FIR): (PT=PSFB, FMT=4) [RFC5104]. 1345 Temporal-Spatial Trade-off Request (TSTR): (PT=PSFB, FMT=5) 1346 [RFC5104]. 1348 H.271 Video Back Channel Message (VBCM): (PT=PSFB, FMT=7) 1349 [RFC5104]. 1351 Temporary Maximum Media Stream Bit Rate Request (TMMBR): (PT=R 1352 TPFB, FMT=3) [RFC5104]. 1354 Layer Refresh Request (LRR): (PT=PSFB, FMT=10) [LLR-RTCP]. 1356 * If the RTCP packet is a feedback notification that includes a 1357 target SSRC(s), for each target SSRC that is found in the incoming 1358 SSRC table, deliver a copy of the RTCP packet to the "m=" section 1359 associated with the RTP stream with a matching SSRC. PSFB and 1360 RTPFB types that are handled in this way include: 1362 Temporal-Spatial Trade-off Notification (TSTN): (PT=PSFB, 1363 FMT=6) [RFC5104]. This message is a notification in 1364 response to a prior TSTR. 1366 Temporary Maximum Media Stream Bit Rate Notification 1367 (TMMBN): (PT=RTPFB, FMT=4) [RFC5104]. This message is a 1368 notification in response to a prior TMMBR, but it can also 1369 be sent unsolicited. 1371 If the RTCP packet is of type APP, then it is handled in an 1372 application-specific manner. If the application does not 1373 recognize the APP packet, then it MUST be discarded. 1375 9.3. RTP/RTCP Multiplexing 1377 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 1378 multiplexing [RFC5761] for the RTP-based bundled media (i.e., the 1379 same transport will be used for both RTP packets and RTCP packets). 1380 In addition, the offerer and answerer MUST support the SDP 'rtcp-mux- 1381 only' attribute [RFC8858]. 1383 9.3.1. SDP Offer/Answer Procedures 1385 This section describes how an offerer and answerer use the SDP 'rtcp- 1386 mux' [RFC5761] and SDP 'rtcp-mux-only' attributes [RFC8858] to 1387 negotiate usage of RTP/RTCP multiplexing for RTP-based bundled media. 1389 RTP/RTCP multiplexing only applies to RTP-based media. However, as 1390 described in Section 7.1.3, within an offer or answer the SDP 'rtcp- 1391 mux' and SDP 'rtcp-mux-only' attributes might be included in a 1392 bundled "m=" section for non-RTP-based media (if such "m=" section is 1393 the offerer-tagged "m=" section or answerer-tagged "m=" section). 1395 9.3.1.1. Generating the Initial SDP BUNDLE Offer 1397 When an offerer generates an initial BUNDLE offer, if the offer 1398 contains one or more bundled "m=" sections for RTP-based media (or, 1399 if there is a chance that "m=" sections for RTP-based media will 1400 later be added to the BUNDLE group), the offerer MUST include an SDP 1401 'rtcp-mux' attribute [RFC5761] in each bundled "m=" section 1402 (excluding any bundle-only "m=" sections). In addition, the offerer 1403 MAY include an SDP 'rtcp-mux-only' attribute [RFC8858] in one or more 1404 bundled "m=" sections for RTP-based media. 1406 NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute 1407 depends on whether the offerer supports fallback to usage of a 1408 separate port for RTCP in case the answerer moves one or more "m=" 1409 sections for RTP-based media out of the BUNDLE group in the answer. 1411 NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the 1412 bundled "m=" sections, but does not include an SDP 'rtcp-mux-only' 1413 attribute, the offerer can also include an SDP 'rtcp' attribute 1414 [RFC3605] in one or more RTP-based bundled "m=" sections in order to 1415 provide a fallback port for RTCP, as described in [RFC5761]. 1416 However, the fallback port will only be applied to "m=" sections for 1417 RTP-based media that are moved out of the BUNDLE group by the 1418 answerer. 1420 In the initial BUNDLE offer, the address:port combination for RTCP 1421 MUST be unique in each bundled "m=" section for RTP-based media 1422 (excluding a bundle-only "m=" section), similar to RTP. 1424 9.3.1.2. Generating the SDP Answer 1426 When an answerer generates an answer, if the answerer supports RTP- 1427 based media, and if a bundled "m=" section in the corresponding offer 1428 contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage 1429 of RTP/RTCP multiplexing, even if there currently are no bundled "m=" 1430 sections for RTP-based media within the BUNDLE group. The answerer 1431 MUST include an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" 1432 section, following the procedures for BUNDLE attributes 1433 (Section 7.1.3). In addition, if the "m=" section that is selected 1434 as the offerer-tagged "m=" section contained an SDP 'rtcp-mux-only' 1435 attribute, the answerer MUST include an SDP 'rtcp-mux-only' attribute 1436 in the answerer-tagged "m=" section. 1438 In an initial BUNDLE offer, if the suggested offerer-tagged "m=" 1439 section contained an SDP 'rtcp-mux-only' attribute, the "m=" section 1440 was for RTP-based media; thus, the answerer does not accept the "m=" 1441 section in the created BUNDLE group, and the answerer MUST move the 1442 "m=" section out of the BUNDLE group (Section 7.3.2); include the 1443 attribute in the moved "m=" section and enable RTP/RTCP multiplexing 1444 for the media associated with the "m=" section; or reject the "m=" 1445 section (Section 7.3.3). 1447 The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled 1448 "m=" section in the answer. The answerer will use the port value of 1449 the offerer-tagged "m=" section sending RTP and RTCP packets 1450 associated with RTP-based bundled media towards the offerer. 1452 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1453 negotiated in a previous offer/answer exchange, the answerer MUST 1454 include an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" 1455 section. It is not possible to disable RTP/RTCP multiplexing within 1456 a BUNDLE group. 1458 9.3.1.3. Offerer Processing of the SDP Answer 1460 When an offerer receives an answer, if the answerer has accepted the 1461 usage of RTP/RTCP multiplexing (Section 9.3.1.2), the answerer 1462 follows the procedures for RTP/RTCP multiplexing defined in 1463 [RFC5761]. The offerer will use the port value of the answerer- 1464 tagged "m=" section for sending RTP and RTCP packets associated with 1465 RTP-based bundled media towards the answerer. 1467 NOTE: It is considered a protocol error if the answerer has not 1468 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" 1469 sections that the answerer included in the BUNDLE group. 1471 9.3.1.4. Modifying the Session 1473 When an offerer generates a subsequent offer, the offerer MUST 1474 include an SDP 'rtcp-mux' attribute in the offerer-tagged "m=" 1475 section, following the procedures for IDENTICAL multiplexing category 1476 attributes in Section 7.1.3. 1478 10. ICE Considerations 1480 This section describes how to use the BUNDLE grouping extension 1481 together with the ICE mechanism [RFC8445]. 1483 The generic procedures for negotiating the usage of ICE using SDP, 1484 defined in [RFC8839], also apply to the usage of ICE with BUNDLE, 1485 with the following exceptions: 1487 * When the BUNDLE transport has been established, ICE connectivity 1488 checks and keepalives only need to be performed for the BUNDLE 1489 transport, instead of per individual bundled "m=" section within 1490 the BUNDLE group. 1492 * The generic SDP attribute offer/answer considerations 1493 (Section 7.1.3) also apply to ICE-related attributes. Therefore, 1494 when an offerer sends an initial BUNDLE offer (in order to 1495 negotiate a BUNDLE group), the offerer includes ICE-related media- 1496 level attributes in each bundled "m=" section (excluding any 1497 bundle-only "m=" sections), and each "m=" section MUST contain 1498 unique ICE properties. When an answerer generates an answer 1499 (initial BUNDLE answer or subsequent) that contains a BUNDLE 1500 group, and when an offerer sends a subsequent offer that contains 1501 a BUNDLE group, ICE-related media-level attributes are only 1502 included in the tagged "m=" section (suggested offerer-tagged "m=" 1503 section or answerer-tagged "m=" section), and the ICE properties 1504 are applied to each bundled "m=" section within the BUNDLE group. 1506 NOTE: Most ICE-related media-level SDP attributes belong to the 1507 TRANSPORT multiplexing category [RFC8859], and the generic SDP 1508 attribute offer/answer considerations for the TRANSPORT multiplexing 1509 category apply to the attributes. However, in the case of ICE- 1510 related attributes, the same considerations also apply to ICE-related 1511 media-level attributes that belong to other multiplexing categories. 1513 NOTE: The following ICE-related media-level SDP attributes are 1514 defined in [RFC8839]: 'candidate', 'remote-candidates', 'ice- 1515 mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-pacing'. 1517 Initially, before ICE has produced selected candidate pairs that will 1518 be used for media, there might be multiple transports established (if 1519 multiple candidate pairs are tested). Once ICE has selected 1520 candidate pairs, they form the BUNDLE transport. 1522 Support and usage of the ICE mechanism together with the BUNDLE 1523 extension is OPTIONAL, and the procedures in this section only apply 1524 when the ICE mechanism is used. Note that applications might mandate 1525 usage of the ICE mechanism even if the BUNDLE extension is not used. 1527 NOTE: If the Trickle ICE mechanism [RFC8840] is used, an offerer and 1528 answerer might assign a port value of '9' and an IPv4 address of 1529 '0.0.0.0' (or, the IPv6 equivalent '::') to multiple bundled "m=" 1530 sections in the initial BUNDLE offer. The offerer and answerer will 1531 follow the normal procedures for generating the offers and answers, 1532 including picking a bundled "m=" section as the suggested offerer- 1533 tagged "m=" section, selecting the tagged "m=" sections, etc. The 1534 only difference is that media cannot be sent until one or more 1535 candidates have been provided. Once a BUNDLE group has been 1536 negotiated, trickled candidates associated with a bundled "m=" 1537 section will be applied to all bundled "m=" sections within the 1538 BUNDLE group. 1540 11. DTLS Considerations 1542 One or more media streams within a BUNDLE group might use the 1543 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1544 to encrypt the data or negotiate encryption keys if another 1545 encryption mechanism is used to encrypt media. 1547 When DTLS is used within a BUNDLE group, the following rules apply: 1549 * There can only be one DTLS association [RFC6347] associated with 1550 the BUNDLE group; 1552 * Each usage of the DTLS association within the BUNDLE group MUST 1553 use the same mechanism for determining which endpoints (the 1554 offerer or answerer) become DTLS client and DTLS server; 1556 * Each usage of the DTLS association within the BUNDLE group MUST 1557 use the same mechanism for determining whether an offer or answer 1558 will trigger the establishment of a new DTLS association or an 1559 existing DTLS association will be used; and 1561 * If the DTLS client supports DTLS-SRTP, it MUST include the 1562 'use_srtp' extension in the DTLS ClientHello message [RFC5764]. 1563 The client MUST include the extension even if the usage of DTLS- 1564 SRTP is not negotiated as part of the multimedia session (e.g., 1565 the SIP session [RFC3261]). 1567 NOTE: The inclusion of the 'use_srtp' extension during the initial 1568 DTLS handshake ensures that a DTLS renegotiation will not be required 1569 in order to include the extension, in case DTLS-SRTP encrypted media 1570 is added to the BUNDLE group later during the multimedia session. 1572 12. RTP Header Extensions Consideration 1574 When RTP header extensions [RFC8285] are used in the context of this 1575 specification, the identifier used for a given extension MUST 1576 identify the same extension across all the bundled media 1577 descriptions. 1579 13. Update to RFC 3264 1581 This section updates RFC 3264, in order to allow extensions to define 1582 the usage of a zero port value in offers and answers for purposes 1583 other than removing or disabling media streams. The following 1584 sections are being updated: 1586 * "Unicast Streams"; see Section 5.1 of [RFC3264] 1588 * "Putting a Unicast Media Stream on Hold"; see Section 8.4 of 1589 [RFC3264]. 1591 13.1. Original Text from RFC 3264, Section 5.1, 2nd Paragraph 1593 | For recvonly and sendrecv streams, the port number and address in 1594 | the offer indicate where the offerer would like to receive the 1595 | media stream. For sendonly RTP streams, the address and port 1596 | number indirectly indicate where the offerer wants to receive RTCP 1597 | reports. Unless there is an explicit indication otherwise, 1598 | reports are sent to the port number one higher than the number 1599 | indicated. The IP address and port present in the offer indicate 1600 | nothing about the source IP address and source port of RTP and 1601 | RTCP packets that will be sent by the offerer. A port number of 1602 | zero in the offer indicates that the stream is offered but MUST 1603 | NOT be used. This has no useful semantics in an initial offer, 1604 | but is allowed for reasons of completeness, since the answer can 1605 | contain a zero port indicating a rejected stream (Section 6). 1606 | Furthermore, existing streams can be terminated by setting the 1607 | port to zero (Section 8). In general, a port number of zero 1608 | indicates that the media stream is not wanted. 1610 13.2. New Text Replacing RFC 3264, Section 5.1, 2nd Paragraph 1612 For recvonly and sendrecv streams, the port number and address in the 1613 offer indicate where the offerer would like to receive the media 1614 stream. For sendonly RTP streams, the address and port number 1615 indirectly indicate where the offerer wants to receive RTCP reports. 1616 Unless there is an explicit indication otherwise, reports are sent to 1617 the port number one higher than the number indicated. The IP address 1618 and port present in the offer indicate nothing about the source IP 1619 address and source port of the RTP and RTCP packets that will be sent 1620 by the offerer. By default, a port number of zero in the offer 1621 indicates that the stream is offered but MUST NOT be used, but an 1622 extension mechanism might specify different semantics for the usage 1623 of a zero port value. Furthermore, existing streams can be 1624 terminated by setting the port to zero (Section 8). In general, a 1625 port number of zero by default indicates that the media stream is not 1626 wanted. 1628 13.3. Original Text from RFC 3264, Section 8.4, 6th Paragraph 1630 | RFC 2543 [10] specified that placing a user on hold was 1631 | accomplished by setting the connection address to 0.0.0.0. Its 1632 | usage for putting a call on hold is no longer recommended, since 1633 | it doesn't allow for RTCP to be used with held streams, doesn't 1634 | work with IPv6, and breaks with connection oriented media. 1635 | However, it can be useful in an initial offer when the offerer 1636 | knows it wants to use a particular set of media streams and 1637 | formats, but doesn't know the addresses and ports at the time of 1638 | the offer. Of course, when used, the port number MUST NOT be 1639 | zero, which would specify that the stream has been disabled. An 1640 | agent MUST be capable of receiving SDP with a connection address 1641 | of 0.0.0.0, in which case it means that neither RTP nor RTCP 1642 | should be sent to the peer. 1644 13.4. New Text Replacing RFC 3264, Section 8.4, 6th Paragraph 1646 RFC 2543 [RFC2543] specifies that placing a user on hold was 1647 accomplished by setting the connection address to 0.0.0.0. Its usage 1648 for putting a call on hold is no longer recommended, since it doesn't 1649 allow for RTCP to be used with held streams, doesn't work with IPv6, 1650 and breaks with connection oriented media. However, it can be useful 1651 in an initial offer when the offerer knows it wants to use a 1652 particular set of media streams and formats, but doesn't know the 1653 addresses and ports at the time of the offer. Of course, when used, 1654 the port number MUST NOT be zero, if it would specify that the stream 1655 has been disabled. However, an extension mechanism might specify 1656 different semantics of the zero port number usage. An agent MUST be 1657 capable of receiving SDP with a connection address of 0.0.0.0, in 1658 which case it means that neither RTP nor RTCP is to be sent to the 1659 peer. 1661 14. Update to RFC 5888 1663 This section updates RFC 5888 [RFC5888], in order for extensions to 1664 allow an SDP 'group' attribute containing an identification-tag that 1665 identifies an "m=" section with the port set to zero. "Group Value 1666 in Answers" (Section 9.2 of [RFC5888]) is updated. 1668 14.1. Original Text from RFC 5888, Section 9.2, 3rd Paragraph 1670 | SIP entities refuse media streams by setting the port to zero in 1671 | the corresponding "m" line. "a=group" lines MUST NOT contain 1672 | identification-tags that correspond to "m" lines with the port set 1673 | to zero. 1675 14.2. New Text Replacing RFC 5888, Section 9.2, 3rd Paragraph 1677 SIP entities refuse media streams by setting the port to zero in the 1678 corresponding "m" line. "a=group" lines MUST NOT contain 1679 identification-tags that correspond to "m" lines with the port set to 1680 zero, but an extension mechanism might specify different semantics 1681 for including identification-tags that correspond to such "m=" lines. 1683 15. RTP/RTCP Extensions for identification-tag Transport 1685 Offerers and answerers [RFC3264] can associate identification-tags 1686 with "m=" sections within offers and answers, using the procedures in 1687 [RFC5888]. Each identification-tag uniquely represents an "m=" 1688 section. 1690 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1691 used to carry identification-tags within RTCP SDES packets. This 1692 section also defines a new RTP SDES header extension [RFC7941], which 1693 is used to carry the 'MID' RTCP SDES item in RTP packets. 1695 The SDES item and RTP SDES header extension make it possible for a 1696 receiver to associate each RTP stream with a specific "m=" section, 1697 with which the receiver has associated an identification-tag, even if 1698 those "m=" sections are part of the same RTP session. The RTP SDES 1699 header extension also ensures that the media recipient gets the 1700 identification-tag upon receipt of the first decodable media and is 1701 able to associate the media with the correct application. 1703 A media recipient informs the media sender about the identification- 1704 tag associated with an "m=" section through the use of a 'mid' 1705 attribute [RFC5888]. The media sender then inserts the 1706 identification-tag in RTCP and RTP packets sent to the media 1707 recipient. 1709 NOTE: The text above defines how identification-tags are carried in 1710 offers and answers. The usage of other signaling protocols for 1711 carrying identification-tags is not prevented, but the usage of such 1712 protocols is outside the scope of this document. 1714 [RFC3550] defines general procedures regarding the RTCP transmission 1715 interval. The RTCP MID SDES item SHOULD be sent in the first few 1716 RTCP packets after joining the session and SHOULD be sent regularly 1717 thereafter. The exact number of RTCP packets in which this SDES item 1718 is sent is intentionally not specified here, as it will depend on the 1719 expected packet-loss rate, the RTCP reporting interval, and the 1720 allowable overhead. 1722 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1723 be included in some RTP packets at the start of the session and 1724 whenever the SSRC changes. It might also be useful to include the 1725 header extension in RTP packets that comprise access points in the 1726 media (e.g., with video I-frames). The exact number of RTP packets 1727 in which this header extension is sent is intentionally not specified 1728 here, as it will depend on expected packet-loss rate and loss 1729 patterns, the overhead the application can tolerate, and the 1730 importance of immediate receipt of the identification-tag. 1732 For robustness, endpoints need to be prepared for situations where 1733 the reception of the identification-tag is delayed and SHOULD NOT 1734 terminate sessions in such cases, as the identification-tag is likely 1735 to arrive soon. 1737 15.1. RTCP MID SDES Item 1739 0 1 2 3 1740 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 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 | MID=15 | length | identification-tag ... 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP. 1747 The identification-tag is not zero terminated. 1749 15.2. RTP SDES Header Extension For MID 1751 The payload, containing the identification-tag, of the RTP SDES 1752 header extension element can be encoded using either the 1-byte or 1753 the 2-byte header [RFC7941]. The identification-tag payload is UTF-8 1754 encoded, as in SDP. 1756 The identification-tag is not zero terminated. Note that the set of 1757 header extensions included in the packet needs to be padded to the 1758 next 32-bit boundary using zero bytes [RFC8285]. 1760 As the identification-tag is included in an RTCP SDES item, an RTP 1761 SDES header extension, or both, there needs to be some consideration 1762 about the packet expansion caused by the identification-tag. To 1763 avoid Maximum Transmission Unit (MTU) issues for the RTP packets, the 1764 header extension's size needs to be taken into account when encoding 1765 the media. 1767 It is recommended that the identification-tag be kept short. Due to 1768 the properties of the RTP header extension mechanism, when using the 1769 1-byte header, a tag that is 1-3 bytes will result in a minimal 1770 number of 32-bit words used for the RTP SDES header extension, in 1771 case no other header extensions are included at the same time. Note, 1772 do take into account that some single characters when UTF-8 encoded 1773 will result in multiple octets. The identification-tag MUST NOT 1774 contain any user information, and applications SHALL avoid generating 1775 the identification-tag using a pattern that enables user or 1776 application identification. 1778 16. IANA Considerations 1780 16.1. New SDES Item 1782 This document adds the MID SDES item to the IANA "RTP SDES Item 1783 Types" registry as follows: 1785 Value: 15 1787 Abbrev.: MID 1789 Name: Media Identification 1791 Reference: RFC XXXX 1793 16.2. New RTP SDES Header Extension URI 1795 This document defines a new extension URI in the RTP SDES Compact 1796 Header Extensions sub-registry of the RTP Compact Header Extensions 1797 registry sub-registry, according to the following data: 1799 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1801 Description: Media identification 1803 Contact: IESG (iesg@ietf.org) 1805 Reference: RFC XXXX 1807 The SDES item does not reveal privacy information about the users. 1808 It is simply used to associate RTP-based media with the correct SDP 1809 media description ("m=" section) in the SDP used to negotiate the 1810 media. 1812 The purpose of the extension is for the offerer to be able to 1813 associate received multiplexed RTP-based media before the offerer 1814 receives the associated answer. 1816 16.3. New SDP Attribute 1818 This document defines a new SDP media-level attribute, 'bundle-only', 1819 according to the following data: 1821 Attribute name: bundle-only 1823 Type of attribute: media 1825 Subject to charset: No 1827 Purpose: Request a media description to be accepted in the answer 1828 only if kept within a BUNDLE group by the answerer. 1830 Appropriate values: N/A 1832 Contact name: IESG 1834 Contact e-mail: iesg@ietf.org 1836 Reference: RFC XXXX 1838 Mux category: NORMAL 1840 16.4. New SDP Group Semantics 1842 This document registers the following semantics with IANA in the 1843 "Semantics for the 'group' SDP Attribute" subregistry (under the 1844 "Session Description Protocol (SDP) Parameters" registry): 1846 +================+========+==============+===========+ 1847 | Semantics | Token | Mux Category | Reference | 1848 +================+========+==============+===========+ 1849 | Media bundling | BUNDLE | NORMAL | RFC XXXX | 1850 +----------------+--------+--------------+-----------+ 1852 Table 1 1854 17. Security Considerations 1856 The security considerations defined in [RFC3264] and [RFC5888] apply 1857 to the BUNDLE extension. BUNDLE does not change which information, 1858 e.g., RTP streams, flows over the network, with the exception of the 1859 usage of the MID SDES item as discussed below. Primarily, it changes 1860 which addresses and ports, and thus in which (RTP) sessions, the 1861 information flows to. This affects the security contexts being used 1862 and can cause previously separated information flows to share the 1863 same security context. This has very little impact on the 1864 performance of the security mechanism of the RTP sessions. In cases 1865 where one would have applied different security policies on the 1866 different RTP streams being bundled, or where the parties having 1867 access to the security contexts would have differed between the RTP 1868 streams, additional analysis of the implications are needed before 1869 selecting to apply BUNDLE. 1871 The identification-tag, independent of transport, RTCP SDES packet, 1872 or RTP header extension, can expose the value to parties beyond the 1873 signaling chain. Therefore, the identification-tag values MUST be 1874 generated in a fashion that does not leak user information, e.g., 1875 randomly or using a per-bundle group counter, and SHOULD be 3 bytes 1876 or less to allow them to efficiently fit into the MID RTP header 1877 extension. Note that if implementations use different methods for 1878 generating identification-tags, this could enable fingerprinting of 1879 the implementation making it vulnerable to targeted attacks. The 1880 identification-tag is exposed on the RTP stream level when included 1881 in the RTP header extensions; however, what it reveals of the RTP 1882 media stream structure of the endpoint and application was already 1883 possible to deduce from the RTP streams without the MID SDES header 1884 extensions. As the identification-tag is also used to route the 1885 media stream to the right application functionality, it is important 1886 that the value received is the one intended by the sender; thus, 1887 integrity and the authenticity of the source are important to prevent 1888 denial of service on the application. Existing SRTP configurations 1889 and other security mechanisms protecting the whole RTP/RTCP packets 1890 will provide the necessary protection. 1892 When the BUNDLE extension is used, the set of configurations of the 1893 security mechanism used in all the bundled media descriptions will 1894 need to be compatible so that they can be used simultaneously, at 1895 least per direction or endpoint. When using SRTP, this will be the 1896 case, at least for the IETF-defined key-management solutions due to 1897 their SDP attributes ("a=crypto", "a=fingerprint", "a=mikey") and 1898 their classification in [RFC8859]. 1900 The security considerations of "RTP Header Extension for the RTP 1901 Control Protocol (RTCP) Source Description Items" [RFC7941] require 1902 that when RTCP is confidentiality protected, any SDES RTP header 1903 extension carrying an SDES item, such as the MID RTP header 1904 extension, is also protected using commensurate strength algorithms. 1905 However, assuming the above requirements and recommendations are 1906 followed, there are no known significant security risks with leaving 1907 the MID RTP header extension without confidentiality protection. 1908 Therefore, this specification updates RFC 7941 by adding the 1909 exception that this requirement MAY be ignored for the MID RTP header 1910 extension. Security mechanisms for RTP/RTCP are discussed in 1911 "Options for Securing RTP Sessions" [RFC7201], for example, SRTP 1912 [RFC3711] can provide the necessary security functions of ensuring 1913 the integrity and source authenticity. 1915 18. Examples 1917 18.1. Example: Tagged "m=" Section Selections 1919 The example below shows: 1921 * An initial BUNDLE offer, in which the offerer wants to negotiate a 1922 BUNDLE group and indicates the audio "m=" section as the suggested 1923 offerer-tagged "m=" section. 1925 * An initial BUNDLE answer, in which the answerer accepts the 1926 creation of the BUNDLE group, selects the audio "m=" section in 1927 the offer as the offerer-tagged "m=" section, selects the audio 1928 "m=" section in the answer as the answerer-tagged "m=" section, 1929 and assigns the answerer BUNDLE address:port to that "m=" section. 1931 SDP Offer (1) 1932 v=0 1933 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1934 s= 1935 c=IN IP6 2001:db8::3 1936 t=0 0 1937 a=group:BUNDLE foo bar 1939 m=audio 10000 RTP/AVP 0 8 97 1940 b=AS:200 1941 a=mid:foo 1942 a=rtcp-mux 1943 a=rtpmap:0 PCMU/8000 1944 a=rtpmap:8 PCMA/8000 1945 a=rtpmap:97 iLBC/8000 1946 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1948 m=video 10002 RTP/AVP 31 32 1949 b=AS:1000 1950 a=mid:bar 1951 a=rtcp-mux 1952 a=rtpmap:31 H261/90000 1953 a=rtpmap:32 MPV/90000 1954 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1956 SDP Answer (2) 1958 v=0 1959 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1960 s= 1961 c=IN IP6 2001:db8::1 1962 t=0 0 1963 a=group:BUNDLE foo bar 1965 m=audio 20000 RTP/AVP 0 1966 b=AS:200 1967 a=mid:foo 1968 a=rtcp-mux 1969 a=rtpmap:0 PCMU/8000 1970 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1972 m=video 20000 RTP/AVP 32 1973 b=AS:1000 1974 a=mid:bar 1975 a=rtpmap:32 MPV/90000 1976 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1978 18.2. Example: BUNDLE Group Rejected 1980 The example below shows: 1982 * An initial BUNDLE offer, in which the offerer wants to negotiate a 1983 BUNDLE group and indicates the audio "m=" section as the suggested 1984 offerer-tagged "m=" section. 1986 * An initial BUNDLE answer, in which the answerer rejects the 1987 creation of the BUNDLE group, generates a normal answer, and 1988 assigns a unique address:port to each "m=" section in the answer. 1990 SDP Offer (1) 1992 v=0 1993 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1994 s= 1995 c=IN IP6 2001:db8::3 1996 t=0 0 1997 a=group:BUNDLE foo bar 1999 m=audio 10000 RTP/AVP 0 8 97 2000 b=AS:200 2001 a=mid:foo 2002 a=rtcp-mux 2003 a=rtpmap:0 PCMU/8000 2004 a=rtpmap:8 PCMA/8000 2005 a=rtpmap:97 iLBC/8000 2006 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2008 m=video 10002 RTP/AVP 31 32 2009 b=AS:1000 2010 a=mid:bar 2011 a=rtcp-mux 2012 a=rtpmap:31 H261/90000 2013 a=rtpmap:32 MPV/90000 2014 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2016 SDP Answer (2) 2017 v=0 2018 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2019 s= 2020 c=IN IP6 2001:db8::1 2021 t=0 0 2023 m=audio 20000 RTP/AVP 0 2024 b=AS:200 2025 a=rtcp-mux 2026 a=rtpmap:0 PCMU/8000 2028 m=video 30000 RTP/AVP 32 2029 b=AS:1000 2030 a=rtcp-mux 2031 a=rtpmap:32 MPV/90000 2033 18.3. Example: Offerer Adds a Media Description to a BUNDLE Group 2035 The example below shows: 2037 * A subsequent offer, in which the offerer adds a new bundled "m=" 2038 section (video), indicated by the "zen" identification-tag, to a 2039 previously negotiated BUNDLE group; indicates the new "m=" section 2040 as the offerer-tagged "m=" section; and assigns the offerer BUNDLE 2041 address:port to that "m=" section. 2043 * A subsequent answer, in which the answerer indicates the new video 2044 "m=" section in the answer as the answerer-tagged "m=" section and 2045 assigns the answerer BUNDLE address:port to that "m=" section. 2047 SDP Offer (1) 2048 v=0 2049 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2050 s= 2051 c=IN IP6 2001:db8::3 2052 t=0 0 2053 a=group:BUNDLE zen foo bar 2055 m=audio 10000 RTP/AVP 0 8 97 2056 b=AS:200 2057 a=mid:foo 2058 a=rtpmap:0 PCMU/8000 2059 a=rtpmap:8 PCMA/8000 2060 a=rtpmap:97 iLBC/8000 2061 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2063 m=video 10000 RTP/AVP 31 32 2064 b=AS:1000 2065 a=mid:bar 2066 a=rtpmap:31 H261/90000 2067 a=rtpmap:32 MPV/90000 2068 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2070 m=video 10000 RTP/AVP 66 2071 b=AS:1000 2072 a=mid:zen 2073 a=rtcp-mux 2074 a=rtpmap:66 H261/90000 2075 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2077 SDP Answer (2) 2078 v=0 2079 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2080 s= 2081 c=IN IP6 2001:db8::1 2082 t=0 0 2083 a=group:BUNDLE zen foo bar 2085 m=audio 20000 RTP/AVP 0 2086 b=AS:200 2087 a=mid:foo 2088 a=rtpmap:0 PCMU/8000 2089 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2091 m=video 20000 RTP/AVP 32 2092 b=AS:1000 2093 a=mid:bar 2094 a=rtpmap:32 MPV/90000 2095 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2097 m=video 20000 RTP/AVP 66 2098 b=AS:1000 2099 a=mid:zen 2100 a=rtcp-mux 2101 a=rtpmap:66 H261/90000 2102 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2104 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 2106 The example below shows: 2108 * A subsequent offer, in which the offerer removes an "m=" section 2109 (video), indicated by the "zen" identification-tag, from a 2110 previously negotiated BUNDLE group; indicates one of the bundled 2111 "m=" sections (audio) remaining in the BUNDLE group as the 2112 offerer-tagged "m=" section; and assigns the offerer BUNDLE 2113 address:port to that "m=" section. 2115 * A subsequent answer, in which the answerer removes the "m=" 2116 section from the BUNDLE group, indicates the audio "m=" section in 2117 the answer as the answerer-tagged "m=" section, and assigns the 2118 answerer BUNDLE address:port to that "m=" section. 2120 SDP Offer (1) 2121 v=0 2122 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2123 s= 2124 c=IN IP6 2001:db8::3 2125 t=0 0 2126 a=group:BUNDLE foo bar 2128 m=audio 10000 RTP/AVP 0 8 97 2129 b=AS:200 2130 a=mid:foo 2131 a=rtcp-mux 2132 a=rtpmap:0 PCMU/8000 2133 a=rtpmap:8 PCMA/8000 2134 a=rtpmap:97 iLBC/8000 2135 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2137 m=video 10000 RTP/AVP 31 32 2138 b=AS:1000 2139 a=mid:bar 2140 a=rtpmap:31 H261/90000 2141 a=rtpmap:32 MPV/90000 2142 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2144 m=video 50000 RTP/AVP 66 2145 b=AS:1000 2146 a=mid:zen 2147 a=rtcp-mux 2148 a=rtpmap:66 H261/90000 2150 SDP Answer (2) 2151 v=0 2152 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2153 s= 2154 c=IN IP6 2001:db8::1 2155 t=0 0 2156 a=group:BUNDLE foo bar 2158 m=audio 20000 RTP/AVP 0 2159 b=AS:200 2160 a=mid:foo 2161 a=rtcp-mux 2162 a=rtpmap:0 PCMU/8000 2163 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2165 m=video 20000 RTP/AVP 32 2166 b=AS:1000 2167 a=mid:bar 2168 a=rtpmap:32 MPV/90000 2169 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2171 m=video 60000 RTP/AVP 66 2172 b=AS:1000 2173 a=mid:zen 2174 a=rtcp-mux 2175 a=rtpmap:66 H261/90000 2177 18.5. Example: Offerer Disables a Media Description within a BUNDLE 2178 Group 2180 The example below shows: 2182 * A subsequent offer, in which the offerer disables (by assigning a 2183 zero port value) an "m=" section (video), indicated by the "zen" 2184 identification-tag, from a previously negotiated BUNDLE group; 2185 indicates one of the bundled "m=" sections (audio) remaining 2186 active in the BUNDLE group as the offerer-tagged "m=" section; and 2187 assigns the offerer BUNDLE address:port to that "m=" section. 2189 * A subsequent answer, in which the answerer disables the "m=" 2190 section, indicates the audio "m=" section in the answer as the 2191 answerer-tagged "m=" section, and assigns the answerer BUNDLE 2192 address:port to that "m=" section. 2194 SDP Offer (1) 2195 v=0 2196 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2197 s= 2198 t=0 0 2199 a=group:BUNDLE foo bar 2201 m=audio 10000 RTP/AVP 0 8 97 2202 c=IN IP6 2001:db8::3 2203 b=AS:200 2204 a=mid:foo 2205 a=rtcp-mux 2206 a=rtpmap:0 PCMU/8000 2207 a=rtpmap:8 PCMA/8000 2208 a=rtpmap:97 iLBC/8000 2209 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2211 m=video 10000 RTP/AVP 31 32 2212 c=IN IP6 2001:db8::3 2213 b=AS:1000 2214 a=mid:bar 2215 a=rtpmap:31 H261/90000 2216 a=rtpmap:32 MPV/90000 2217 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2219 m=video 0 RTP/AVP 66 2220 a=mid:zen 2221 a=rtpmap:66 H261/90000 2223 SDP Answer (2) 2224 v=0 2225 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2226 s= 2227 t=0 0 2228 a=group:BUNDLE foo bar 2230 m=audio 20000 RTP/AVP 0 2231 c=IN IP6 2001:db8::1 2232 b=AS:200 2233 a=mid:foo 2234 a=rtcp-mux 2235 a=rtpmap:0 PCMU/8000 2236 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2238 m=video 20000 RTP/AVP 32 2239 c=IN IP6 2001:db8::1 2240 b=AS:1000 2241 a=mid:bar 2242 a=rtpmap:32 MPV/90000 2243 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2245 m=video 0 RTP/AVP 66 2246 a=mid:zen 2247 a=rtpmap:66 H261/90000 2249 19. References 2251 19.1. Normative References 2253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2254 Requirement Levels", BCP 14, RFC 2119, 2255 DOI 10.17487/RFC2119, March 1997, 2256 . 2258 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2259 with Session Description Protocol (SDP)", RFC 3264, 2260 DOI 10.17487/RFC3264, June 2002, 2261 . 2263 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2264 Jacobson, "RTP: A Transport Protocol for Real-Time 2265 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2266 July 2003, . 2268 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2269 in Session Description Protocol (SDP)", RFC 3605, 2270 DOI 10.17487/RFC3605, October 2003, 2271 . 2273 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2274 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2275 2003, . 2277 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2278 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2279 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2280 . 2282 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2283 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2284 July 2006, . 2286 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2287 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2288 . 2290 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2291 Control Packets on a Single Port", RFC 5761, 2292 DOI 10.17487/RFC5761, April 2010, 2293 . 2295 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2296 Security (DTLS) Extension to Establish Keys for the Secure 2297 Real-time Transport Protocol (SRTP)", RFC 5764, 2298 DOI 10.17487/RFC5764, May 2010, 2299 . 2301 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2302 Protocol (SDP) Grouping Framework", RFC 5888, 2303 DOI 10.17487/RFC5888, June 2010, 2304 . 2306 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2307 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2308 January 2012, . 2310 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2311 Header Extension for the RTP Control Protocol (RTCP) 2312 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2313 August 2016, . 2315 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2316 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2317 May 2017, . 2319 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 2320 Mechanism for RTP Header Extensions", RFC 8285, 2321 DOI 10.17487/RFC8285, October 2017, 2322 . 2324 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2325 Connectivity Establishment (ICE): A Protocol for Network 2326 Address Translator (NAT) Traversal", RFC 8445, 2327 DOI 10.17487/RFC8445, July 2018, 2328 . 2330 [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, 2331 A., and R. Shpount, "Session Description Protocol (SDP) 2332 Offer/Answer Procedures for Interactive Connectivity 2333 Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, 2334 January 2021, . 2336 [RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 2337 Session Initiation Protocol (SIP) Usage for Incremental 2338 Provisioning of Candidates for the Interactive 2339 Connectivity Establishment (Trickle ICE)", RFC 8840, 2340 DOI 10.17487/RFC8840, January 2021, 2341 . 2343 [RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP 2344 Control Protocol (RTCP) Multiplexing Using the Session 2345 Description Protocol (SDP)", RFC 8858, 2346 DOI 10.17487/RFC8858, January 2021, 2347 . 2349 [RFC8859] Nandakumar, S., "A Framework for Session Description 2350 Protocol (SDP) Attributes When Multiplexing", RFC 8859, 2351 DOI 10.17487/RFC8859, January 2021, 2352 . 2354 19.2. Informative References 2356 [LLR-RTCP] Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 2357 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 2358 Message", Work in Progress, Internet-Draft, draft-ietf- 2359 avtext-lrr-07, 2 July 2017, 2360 . 2362 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 2363 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 2364 DOI 10.17487/RFC2543, March 1999, 2365 . 2367 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2368 A., Peterson, J., Sparks, R., Handley, M., and E. 2369 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2370 DOI 10.17487/RFC3261, June 2002, 2371 . 2373 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2374 "RTP Control Protocol Extended Reports (RTCP XR)", 2375 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2376 . 2378 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2379 "Extended RTP Profile for Real-time Transport Control 2380 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2381 DOI 10.17487/RFC4585, July 2006, 2382 . 2384 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2385 "Codec Control Messages in the RTP Audio-Visual Profile 2386 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 2387 February 2008, . 2389 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2390 Media Attributes in the Session Description Protocol 2391 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2392 . 2394 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2395 Clock Rates in an RTP Session", RFC 7160, 2396 DOI 10.17487/RFC7160, April 2014, 2397 . 2399 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2400 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2401 . 2403 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2404 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2405 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2406 DOI 10.17487/RFC7656, November 2015, 2407 . 2409 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 2410 (Diffserv) and Real-Time Communication", RFC 7657, 2411 DOI 10.17487/RFC7657, November 2015, 2412 . 2414 [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., 2415 "JavaScript Session Establishment Protocol (JSEP)", 2416 RFC 8829, DOI 10.17487/RFC8829, January 2021, 2417 . 2419 [RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: 2420 Incremental Provisioning of Candidates for the Interactive 2421 Connectivity Establishment (ICE) Protocol", RFC 8838, 2422 DOI 10.17487/RFC8838, January 2021, 2423 . 2425 Appendix A. Design Considerations 2427 One of the main issues regarding the BUNDLE grouping extensions has 2428 been whether, in offers and answers, the same port value can be 2429 inserted in "m=" lines associated with a BUNDLE group, as the purpose 2430 of the extension is to negotiate the usage of a single transport for 2431 media specified by the "m=" sections. Issues with both approaches, 2432 discussed in the Appendix, have been raised. The outcome was to 2433 specify a mechanism that uses offers with both different and 2434 identical port values. 2436 Below are the primary issues that have been considered when defining 2437 the "BUNDLE" grouping extension: 2439 1) Interoperability with existing User Agents (UAs). 2441 2) Interoperability with intermediary Back-to-Back User Agent 2442 (B2BUA) and proxy entities. 2444 3) Time to gather, and the number of, ICE candidates. 2446 4) Different error scenarios and when they occur. 2448 5) SDP offer/answer impacts, including usage of port number value 2449 zero. 2451 A.1. UA Interoperability 2453 Consider the following SDP offer/answer exchange, where Alice sends 2454 an offer to Bob: 2456 SDP Offer 2457 v=0 2458 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2459 s= 2460 c=IN IP4 atlanta.example.com 2461 t=0 0 2463 m=audio 10000 RTP/AVP 97 2464 a=rtpmap:97 iLBC/8000 2465 m=video 10002 RTP/AVP 97 2466 a=rtpmap:97 H261/90000 2468 SDP Answer 2470 v=0 2471 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2472 s= 2473 c=IN IP4 biloxi.example.com 2474 t=0 0 2476 m=audio 20000 RTP/AVP 97 2477 a=rtpmap:97 iLBC/8000 2478 m=video 20002 RTP/AVP 97 2479 a=rtpmap:97 H261/90000 2481 RFC 4961 specifies a way of doing symmetric RTP, but that is a later 2482 extension to RTP, and Bob cannot assume that Alice supports RFC 4961. 2483 This means that Alice may be sending RTP from a different port than 2484 10000 or 10002 -- some implementations simply send the RTP from an 2485 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2486 way that Bob knows if the packet is to be passed to the video or 2487 audio codec is by looking at the port it was received on. This 2488 prompted some SDP implementations to use a port number as an index to 2489 find the correct "m=" line in the SDP, since each "m"= section 2490 contains a different port number. As a result, some implementations 2491 that do support symmetric RTP and ICE still use an SDP data structure 2492 where SDP with "m=" sections with the same port such as: 2494 SDP Offer 2495 v=0 2496 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2497 s= 2498 c=IN IP4 atlanta.example.com 2499 t=0 0 2501 m=audio 10000 RTP/AVP 97 2502 a=rtpmap:97 iLBC/8000 2503 m=video 10000 RTP/AVP 98 2504 a=rtpmap:98 H261/90000 2506 will result in the second "m=" section being considered an SDP error 2507 because it has the same port as the first line. 2509 A.2. Usage of Port Number Value Zero 2511 In an offer or answer, the media specified by an "m=" section can be 2512 disabled/rejected by setting the port number value to zero. This is 2513 different from, e.g., using the SDP direction attributes, where RTCP 2514 traffic will continue even if the SDP 'inactive' attribute is 2515 indicated for the associated "m=" section. 2517 If each "m=" section associated with a BUNDLE group would contain 2518 different port values, and one of those port values would be used for 2519 a BUNDLE address:port associated with the BUNDLE group, problems 2520 would occur if an endpoint wants to disable/reject the "m=" section 2521 associated with that port, by setting the port value to zero. After 2522 that, no "m=" section would contain the port value that is used for 2523 the BUNDLE address:port. In addition, it is unclear what would 2524 happen to the ICE candidates associated with the "m=" section, as 2525 they are also used for the BUNDLE address:port. 2527 A.3. B2BUA and Proxy Interoperability 2529 Some back-to-back user agents may be configured in a mode where if 2530 the incoming call leg contains an SDP attribute the B2BUA does not 2531 understand, the B2BUA still generates that SDP attribute in the Offer 2532 for the outgoing call leg. Consider a B2BUA that did not understand 2533 the SDP 'rtcp' attribute, defined in RFC 3605, yet acted this way. 2534 Further assume that the B2BUA was configured to tear down any call 2535 where it did not see any RTCP for 5 minutes. In this case, if the 2536 B2BUA received an Offer like: 2538 SDP Offer 2539 v=0 2540 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2541 s= 2542 c=IN IP4 atlanta.example.com 2543 t=0 0 2545 m=audio 49170 RTP/AVP 0 2546 a=rtcp:53020 2548 It would be looking for RTCP on port 49171 but would not see any 2549 because the RTCP would be on port 53020, and after five minutes, it 2550 would tear down the call. Similarly, a B2BUA that did not understand 2551 BUNDLE yet put it in its offer may be looking for media on the wrong 2552 port and tear down the call. It is worth noting that a B2BUA that 2553 generated an Offer with capabilities it does not understand is not 2554 compliant with the specifications. 2556 A.3.1. Traffic Policing 2558 Sometimes intermediaries do not act as B2BUAs, in the sense that they 2559 don't modify SDP bodies nor do they terminate SIP dialogs. However, 2560 they may still use SDP information (e.g., IP address and port) in 2561 order to control traffic gating functions and to set traffic policing 2562 rules. There might be rules that will trigger a session to be 2563 terminated in case media is not sent or received on the ports 2564 retrieved from the SDP. This typically occurs once the session is 2565 already established and ongoing. 2567 A.3.2. Bandwidth Allocation 2569 Sometimes, intermediaries do not act as B2BUAs, in the sense that 2570 they don't modify SDP bodies nor do they terminate SIP dialogs. 2571 However, they may still use SDP information (e.g., codecs and media 2572 types) in order to control bandwidth allocation functions. The 2573 bandwidth allocation is done per "m=" section, which means that it 2574 might not be enough if media specified by all "m=" sections try to 2575 use that bandwidth. That may simply lead to either bad user 2576 experience or termination of the call. 2578 A.4. Candidate Gathering 2580 When using ICE, a candidate needs to be gathered for each port. This 2581 takes approximately 20 ms extra for each extra "m=" section due to 2582 the NAT pacing requirements. All of this gathering can be overlapped 2583 with other things while, e.g., a web page is loading to minimize the 2584 impact. If the client only wants to generate Traversal Using Relays 2585 around NAT (TURN) or STUN ICE candidates for one of the "m=" lines 2586 and then use Trickle ICE [RFC8838] to get the non-host ICE candidates 2587 for the rest of the "m=" sections, it MAY do that and will not need 2588 any additional gathering time. 2590 Some people have suggested a TURN extension to get a bunch of TURN 2591 allocations at once. This would only provide a single STUN result, 2592 so in cases where the other end did not support BUNDLE, it may cause 2593 more use of the TURN server, but it would be quick in the cases where 2594 both sides supported BUNDLE and would fall back to a successful call 2595 in the other cases. 2597 Acknowledgements 2599 The usage of the SDP grouping extension for negotiating bundled media 2600 is based on similar alternatives proposed by Harald Alvestrand and 2601 Cullen Jennings. The BUNDLE extension described in this document is 2602 based on the different alternative proposals, and text (e.g., SDP 2603 examples) has been borrowed (and, in some cases, modified) from those 2604 alternative proposals. 2606 The SDP examples are also modified versions from the ones in the 2607 Alvestrand proposal. 2609 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 2610 Stach, Ari Keränen, Adam Roach, Christian Groves, Roman Shpount, 2611 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin 2612 Uberti, Taylor Brandstetter, Byron Campen, and Eric Rescorla for 2613 reading the text and providing useful feedback. 2615 Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus 2616 Westerlund for providing the text for the section on RTP/RTCP stream 2617 association. 2619 Thanks to Magnus Westerlund, Colin Perkins, and Jonathan Lennox for 2620 providing help and text on the RTP/RTCP procedures. 2622 Thanks to Charlie Kaufman for performing the Sec-Dir review. 2624 Thanks to Linda Dunbar for performing the Gen-ART review. 2626 Thanks to Spotify for providing music for the countless hours of 2627 document editing. 2629 Authors' Addresses 2630 Christer Holmberg 2631 Ericsson 2632 Hirsalantie 11 2633 FI-02420 Jorvas 2634 Finland 2636 Email: christer.holmberg@ericsson.com 2638 Harald Tveit Alvestrand 2639 Google 2640 Kungsbron 2 2641 SE-11122 Stockholm 2642 Sweden 2644 Email: harald@alvestrand.no 2646 Cullen Jennings 2647 Cisco 2648 400 3rd Avenue SW, Suite 350 2649 Calgary AB T2P 4H2 2650 Canada 2652 Email: fluffy@iii.ca