idnits 2.17.1 draft-holmberg-mmusic-rfc8843bis-00.txt: -(2333): 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. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2666 lines 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 (31 March 2021) is 1122 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 1625 ** 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 (~~), 3 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: 2 October 2021 Cisco 8 31 March 2021 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-holmberg-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 2 October 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 78 1.1. Background 79 1.2. BUNDLE Mechanism 80 1.3. Protocol Extensions 81 1.4. Changes from RFC 8843 82 2. Terminology 83 3. Conventions 84 4. Applicability Statement 85 5. SDP Grouping Framework BUNDLE Extension 86 6. SDP 'bundle-only' Attribute 87 7. SDP Offer/Answer Procedures 88 7.1. Generic SDP Considerations 89 7.1.1. Connection Data ("c=") 90 7.1.2. Bandwidth ("b=") 91 7.1.3. Attributes ("a=") 92 7.2. Generating the Initial SDP Offer 93 7.2.1. Suggesting the Offerer-Tagged 'm=' Section 94 7.2.2. Example: Initial SDP Offer 95 7.3. Generating the SDP Answer 96 7.3.1. Answerer Selection of Tagged 'm=' Sections 97 7.3.2. Moving a Media Description Out of a BUNDLE Group 98 7.3.3. Rejecting a Media Description in a BUNDLE Group 99 7.3.4. Example: SDP Answer 100 7.4. Offerer Processing of the SDP Answer 101 7.5. Modifying the Session 102 7.5.1. Adding a Media Description to a BUNDLE Group 103 7.5.2. Moving a Media Description Out of a BUNDLE Group 104 7.5.3. Disabling a Media Description in a BUNDLE Group 105 8. Protocol Identification 106 8.1. STUN, DTLS, and SRTP 107 9. RTP Considerations 108 9.1. Single RTP Session 109 9.1.1. Payload Type (PT) Value Reuse 110 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 111 Description 112 9.3. RTP/RTCP Multiplexing 113 9.3.1. SDP Offer/Answer Procedures 114 10. ICE Considerations 115 11. DTLS Considerations 116 12. RTP Header Extensions Consideration 117 13. Update to RFC 3264 118 13.1. Original Text from RFC 3264, Section 5.1, 2nd Paragraph 119 13.2. New Text Replacing RFC 3264, Section 5.1, 2nd Paragraph 120 13.3. Original Text from RFC 3264, Section 8.4, 6th Paragraph 121 13.4. New Text Replacing RFC 3264, Section 8.4, 6th Paragraph 122 14. Update to RFC 5888 123 14.1. Original Text from RFC 5888, Section 9.2, 3rd Paragraph 124 14.2. New Text Replacing RFC 5888, Section 9.2, 3rd Paragraph 125 15. RTP/RTCP Extensions for identification-tag Transport 126 15.1. RTCP MID SDES Item 127 15.2. RTP SDES Header Extension For MID 128 16. IANA Considerations 129 16.1. New SDES Item 130 16.2. New RTP SDES Header Extension URI 131 16.3. New SDP Attribute 132 16.4. New SDP Group Semantics 133 17. Security Considerations 134 18. Examples 135 18.1. Example: Tagged "m=" Section Selections 136 18.2. Example: BUNDLE Group Rejected 137 18.3. Example: Offerer Adds a Media Description to a BUNDLE 138 Group 139 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE 140 Group 141 18.5. Example: Offerer Disables a Media Description within a 142 BUNDLE Group 143 19. References 144 19.1. Normative References 145 19.2. Informative References 146 Appendix A. Design Considerations 147 A.1. UA Interoperability 148 A.2. Usage of Port Number Value Zero 149 A.3. B2BUA and Proxy Interoperability 150 A.3.1. Traffic Policing 151 A.3.2. Bandwidth Allocation 152 A.4. Candidate Gathering 153 Acknowledgements 154 Authors' Addresses 156 1. Introduction 158 1.1. Background 160 When the SDP offer/answer mechanism [RFC3264] is used to negotiate 161 the establishment of multimedia communication sessions, if separate 162 transports (5-tuples) are negotiated for each individual media 163 stream, each transport consumes additional resources (especially when 164 Interactive Connectivity Establishment (ICE) [RFC8445] is used). For 165 this reason, it is attractive to use a single transport for multiple 166 media streams. 168 1.2. BUNDLE Mechanism 170 This specification defines a way to use a single transport (BUNDLE 171 transport) for sending and receiving media (bundled media) described 172 by multiple SDP media descriptions ("m=" sections). The address:port 173 combination used by an endpoint for sending and receiving bundled 174 media is referred to as the BUNDLE address:port. The set of SDP 175 attributes that are applied to each "m=" section within a BUNDLE 176 group is referred to as BUNDLE attributes. The same BUNDLE transport 177 is used for sending and receiving bundled media, which means that the 178 symmetric Real-time Transport Protocol (RTP) mechanism [RFC4961] is 179 always used for RTP-based bundled media. 181 This specification defines a new SDP Grouping Framework [RFC5888] 182 extension called 'BUNDLE'. The extension can be used with the 183 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 184 to negotiate which "m=" sections will become part of a BUNDLE group. 185 In addition, the offerer and answerer [RFC3264] use the BUNDLE 186 extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE 187 address:port and answerer BUNDLE address:port) and the set of BUNDLE 188 attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) 189 that will be applied to each "m=" section within the BUNDLE group. 191 The use of a BUNDLE transport allows the usage of a single set of ICE 192 [RFC8445] candidates for the whole BUNDLE group. 194 A given BUNDLE address:port MUST only be associated with a single 195 BUNDLE group. If an SDP offer or SDP answer (hereafter referred to 196 as "offer" and "answer") contains multiple BUNDLE groups, the 197 procedures in this specification apply to each group independently. 198 All RTP-based bundled media associated with a given BUNDLE group 199 belong to a single RTP session [RFC3550]. 201 The BUNDLE extension is backward compatible. Endpoints that do not 202 support the extension are expected to generate offers and answers 203 without an SDP 'group:BUNDLE' attribute and assign a unique 204 address:port to each "m=" section within an offer and answer, 205 according to the procedures in [RFC3264] and [RFC4566]. 207 1.3. Protocol Extensions 209 In addition to defining the new SDP Grouping Framework extension, 210 this specification defines the following protocol extensions and RFC 211 updates. This specification: 213 * defines a new SDP attribute, 'bundle-only', which can be used to 214 request that a specific "m=" section (and the associated media) be 215 used only if kept within a BUNDLE group. 217 * updates RFC 3264 [RFC3264], to also allow assigning a zero port 218 value to an "m=" section in cases where the media described by the 219 "m=" section is not disabled or rejected. 221 * defines a new RTCP [RFC3550] SDES item, 'MID', and a new RTP SDES 222 header extension that can be used to associate RTP streams with 223 "m=" sections. 225 * updates [RFC7941] by adding an exception, for the MID RTP header 226 extension, to the requirement regarding protection of an SDES RTP 227 header extension carrying an SDES item for the MID RTP header 228 extension. 230 1.4. Changes from RFC 8843 232 When RFC 8843 and [RFC8829] were published an inconsistency between 233 the specifications was identified. The procedures regarding 234 assigning the port value to a bundled "m=" section in an answer 235 (initial or subsequent) and a subsequent offer were inconsistent. At 236 the IETF 110 meeting it was agreed to publish new versions of the 237 RFCs, in which the inconsistency is removed. This specification 238 removes the inconsistency by aligning the port value assignment 239 procedure with the procedure in RFC 8829. 241 In addition, this document implements the following erratas: 6431, 242 6437 244 2. Terminology 246 "m=" section: SDP bodies contain one or more media descriptions, 247 referred to as "m=" sections. Each "m=" section is represented 248 by an SDP "m=" line and zero or more SDP attributes associated 249 with the "m=" line. A local address:port combination is 250 assigned to each "m=" section. 252 5-tuple: A collection of the following values: source address, 253 source port, destination address, destination port, and 254 transport-layer protocol. 256 Unique address:port: An address:port combination that is assigned 257 to only one "m=" section in an offer or answer. 259 Offerer BUNDLE-tag: The first identification-tag in a given SDP 260 'group:BUNDLE' attribute identification-tag list in an offer. 262 Answerer BUNDLE-tag: The first identification-tag in a given SDP 263 'group:BUNDLE' attribute identification-tag list in an answer. 265 Suggested offerer-tagged "m=" section: The bundled "m=" section 266 identified by the offerer BUNDLE-tag in an initial BUNDLE 267 offer, before a BUNDLE group has been negotiated. 269 Offerer-tagged "m=" section: The bundled "m=" section identified 270 by the offerer BUNDLE-tag in a subsequent offer. The "m=" 271 section contains characteristics (offerer BUNDLE address:port 272 and offerer BUNDLE attributes) that are applied to each "m=" 273 section within the BUNDLE group. 275 Answerer-tagged "m=" section: The bundled "m=" section identified 276 by the answerer BUNDLE-tag in an answer (initial BUNDLE answer 277 or subsequent). The "m=" section contains characteristics 278 (answerer BUNDLE address:port and answerer BUNDLE attributes) 279 that are applied to each "m=" section within the BUNDLE group. 281 BUNDLE address:port: An address:port combination that an endpoint 282 uses for sending and receiving bundled media. 284 Offerer BUNDLE address:port: The address:port combination used by 285 the offerer for sending and receiving media. 287 Answerer BUNDLE address:port: The address:port combination used 288 by the answerer for sending and receiving media. 290 BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category 291 SDP attributes. Once a BUNDLE group has been created, the 292 attribute values apply to each bundled "m=" section within the 293 BUNDLE group. 295 Offerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing 296 category SDP attributes included in the offerer-tagged "m=" 297 section. 299 Answerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing 300 category SDP attributes included in the answerer-tagged "m=" 301 section. 303 BUNDLE transport: The transport (5-tuple) used by all media 304 described by the "m=" sections within a BUNDLE group. 306 BUNDLE group: A set of bundled "m=" sections, created using an 307 SDP offer/answer exchange, that uses a single BUNDLE transport, 308 and a single set of BUNDLE attributes, for sending and 309 receiving all media (bundled media) described by the set of 310 "m=" sections. The same BUNDLE transport is used for sending 311 and receiving bundled media. 313 Bundled "m=" section: An "m=" section, whose identification-tag 314 is placed in an SDP 'group:BUNDLE' attribute identification-tag 315 list in an offer or answer. 317 Bundle-only "m=" section: A bundled "m=" section that contains an 318 SDP 'bundle-only' attribute. 320 Bundled media: All media associated with a given BUNDLE group. 322 Initial BUNDLE offer: The first offer, within an SDP session 323 (e.g., a SIP dialog when SIP [RFC3261] is used to carry SDP), 324 in which the offerer indicates that it wants to negotiate a 325 given BUNDLE group. 327 Initial BUNDLE answer: The answer to an initial BUNDLE offer in 328 which the offerer indicates that it wants to negotiate a BUNDLE 329 group, and the answerer accepts the creation of the BUNDLE 330 group. The BUNDLE group is created once the answerer sends the 331 initial BUNDLE answer. 333 Subsequent offer: An offer that contains a BUNDLE group that has 334 been created as part of a previous offer/answer exchange. 336 Subsequent answer: An answer to a subsequent offer. 338 Identification-tag: A unique token value that is used to identify 339 an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" 340 section carries the unique identification-tag assigned to that 341 "m=" section. The session-level SDP 'group' attribute 342 [RFC5888] carries a list of identification-tags, identifying 343 the "m=" sections associated with that particular 'group' 344 attribute. 346 3. Conventions 348 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 349 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 350 "OPTIONAL" in this document are to be interpreted as described in 351 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 352 capitals, as shown here. 354 4. Applicability Statement 356 The mechanism in this specification only applies to SDP [RFC4566], 357 when used together with the SDP offer/answer mechanism [RFC3264]. 358 Declarative usage of SDP is out of scope of this document and is thus 359 undefined. 361 5. SDP Grouping Framework BUNDLE Extension 363 This section defines a new SDP Grouping Framework [RFC5888] 364 extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP 365 offer/answer mechanism to negotiate a set of "m=" sections that will 366 become part of a BUNDLE group. Within a BUNDLE group, each "m=" 367 section uses a BUNDLE transport for sending and receiving bundled 368 media. Each endpoint uses a single address:port combination for 369 sending and receiving the bundled media. 371 The BUNDLE extension is indicated using an SDP 'group' attribute with 372 a semantics value [RFC5888] of "BUNDLE". An identification-tag is 373 assigned to each bundled "m=" section, and each identification-tag is 374 listed in the SDP 'group:BUNDLE' attribute identification-tag list. 375 Each "m=" section whose identification-tag is listed in the 376 identification-tag list is associated with a given BUNDLE group. 378 SDP bodies can contain multiple BUNDLE groups. Any given bundled 379 "m=" section MUST NOT be associated with more than one BUNDLE group 380 at any given time. 382 NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' 383 attribute identification-tag list does not have to be the same as the 384 order in which the "m=" sections occur in the SDP. 386 The multiplexing category [RFC8859] for the 'group:BUNDLE' attribute 387 is 'NORMAL'. 389 Section 7 defines the detailed SDP offer/answer procedures for the 390 BUNDLE extension. 392 6. SDP 'bundle-only' Attribute 394 This section defines a new SDP media-level attribute [RFC4566], 395 'bundle-only'. 'bundle-only' is a property attribute [RFC4566] and 396 hence has no value. 398 In order to ensure that an answerer that does not support the BUNDLE 399 extension always rejects a bundled "m=" section in an offer, the 400 offerer can assign a zero port value to the "m=" section. According 401 to [RFC3264], an answerer will reject such an "m=" section. By 402 including an SDP 'bundle-only' attribute in a bundled "m=" section, 403 the offerer can request that the answerer accepts the "m=" section 404 only if the answerer supports the BUNDLE extension and if the 405 answerer keeps the "m=" section within the associated BUNDLE group. 407 Name: bundle-only 409 Value: N/A 411 Usage Level: media 413 Charset Dependent: no 415 Example: a=bundle-only 417 The usage of the 'bundle-only' attribute is only defined for a 418 bundled "m=" section with a zero port value. Other usage is 419 unspecified. If an offerer or answerer receives a 'bundle-only' 420 attribute in a non-bundled "m=" section the offerer or answerer MUST 421 discard the attribute. 423 Section 7 defines the detailed SDP offer/answer procedures for the 424 'bundle-only' attribute. 426 7. SDP Offer/Answer Procedures 428 This section describes the SDP offer/answer [RFC3264] procedures for: 430 * Negotiating a BUNDLE group; 432 * Suggesting and selecting the tagged "m=" sections (offerer-tagged 433 "m=" section and answerer-tagged "m=" section); 435 * Adding an "m=" section to a BUNDLE group; 437 * Moving an "m=" section out of a BUNDLE group; and 439 * Disabling an "m=" section within a BUNDLE group. 441 The generic rules and procedures defined in [RFC3264] and [RFC5888] 442 also apply to the BUNDLE extension. For example, if an offer is 443 rejected by the answerer, the previously negotiated addresses:ports, 444 SDP parameters, and characteristics (including those associated with 445 a BUNDLE group) apply. Hence, if an offerer generates an offer in 446 order to negotiate a BUNDLE group, and the answerer rejects the 447 offer, the BUNDLE group is not created. 449 The procedures in this section are independent of the media type or 450 "m=" line proto value assigned to a bundled "m=" section. Section 6 451 defines additional considerations for the usage of the SDP 'bundle- 452 only' attribute. Section 9 defines additional considerations for 453 RTP-based media. Section 10 defines additional considerations for 454 the usage of the ICE [RFC8445] mechanism. 456 Offers and answers can contain multiple BUNDLE groups. The 457 procedures in this section apply independently to a given BUNDLE 458 group. 460 7.1. Generic SDP Considerations 462 This section describes generic restrictions associated with the usage 463 of SDP parameters within a BUNDLE group. It also describes how to 464 calculate a value for the whole BUNDLE group, when parameter and 465 attribute values have been assigned to each bundled "m=" section. 467 7.1.1. Connection Data ("c=") 469 The "c=" line nettype value [RFC4566] associated with a bundled "m=" 470 section MUST be 'IN'. 472 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" 473 section MUST be 'IP4' or 'IP6'. The same value MUST be associated 474 with each "m=" section. 476 NOTE: Extensions to this specification can specify usage of the 477 BUNDLE mechanism for other nettype and addrtype values than the ones 478 listed above. 480 7.1.2. Bandwidth ("b=") 482 An offerer and answerer MUST use the rules and restrictions defined 483 in [RFC8859] for associating the SDP bandwidth ("b=") line with 484 bundled "m=" sections. 486 7.1.3. Attributes ("a=") 488 An offerer and answerer MUST include SDP attributes in every bundled 489 "m=" section where applicable, following the normal offer/answer 490 procedures for each attribute, with the following exceptions: 492 * In the initial BUNDLE offer, the offerer MUST NOT include 493 IDENTICAL and TRANSPORT multiplexing category SDP attributes 494 (BUNDLE attributes) in bundle-only "m=" sections. The offerer 495 MUST include such attributes in all other bundled "m=" sections. 496 In the initial BUNDLE offer, each bundled "m=" line can contain a 497 different set of BUNDLE attributes and attribute values. Once the 498 offerer-tagged "m=" section has been selected, the BUNDLE 499 attributes contained in the offerer-tagged "m=" section will apply 500 to each bundled "m=" section within the BUNDLE group. 502 * In a subsequent offer, or in an answer (initial of subsequent), 503 the offerer and answerer MUST include IDENTICAL and TRANSPORT 504 multiplexing category SDP attributes (BUNDLE attributes) only in 505 the tagged "m=" section (offerer-tagged "m=" section or answerer- 506 tagged "m=" section). The offerer and answerer MUST NOT include 507 such attributes in any other bundled "m=" section. The BUNDLE 508 attributes contained in the tagged "m=" section will apply to each 509 bundled "m=" section within the BUNDLE group. 511 * In an offer (initial BUNDLE offer or subsequent), or in an answer 512 (initial BUNDLE answer or subsequent), the offerer and answerer 513 MUST include SDP attributes from categories other than IDENTICAL 514 and TRANSPORT in each bundled "m=" section that a given attribute 515 applies to. Each bundled "m=" line can contain a different set of 516 such attributes, and attribute values, as such attributes only 517 apply to the given bundled "m=" section in which they are 518 included. 520 NOTE: A consequence of the rules above is that media-specific 521 IDENTICAL and TRANSPORT multiplexing category SDP attributes that are 522 applicable only to some of the bundled "m=" sections within the 523 BUNDLE group might appear in the tagged "m=" section for which they 524 are not applicable. For instance, the tagged "m=" section might 525 contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section 526 does not describe RTP-based media (but another bundled "m=" section 527 within the BUNDLE group does describe RTP-based media). 529 7.2. Generating the Initial SDP Offer 531 The procedures in this section apply to the first offer, within an 532 SDP session (e.g., a SIP dialog when SIP [RFC3261] is used to carry 533 SDP), in which the offerer indicates that it wants to negotiate a 534 given BUNDLE group. This could occur in the initial offer, or in a 535 subsequent offer, of the SDP session. 537 When an offerer generates an initial BUNDLE offer, in order to 538 negotiate a BUNDLE group, it MUST: 540 * Assign a unique address:port to each bundled "m=" section, 541 following the procedures in [RFC3264], excluding any bundle-only 542 "m=" sections (see below); 544 * Pick a bundled "m=" section as the suggested offerer-tagged "m=" 545 (Section 7.2.1); 547 * Include SDP attributes in the bundled "m=" sections following the 548 rules in Section 7.1.3; 550 * Include an SDP 'group:BUNDLE' attribute in the offer; and 552 * Place the identification-tag of each bundled "m=" section in the 553 SDP 'group:BUNDLE' attribute identification-tag list. The offerer 554 BUNDLE-tag indicates the suggested offerer-tagged "m=" section. 556 NOTE: When the offerer assigns unique addresses:ports to multiple 557 bundled "m=" sections, the offerer needs to be prepared to receive 558 bundled media on each unique address:port, until it receives the 559 associated answer and finds out which bundled "m=" section (and 560 associated address:port combination) the answerer has selected as the 561 offerer-tagged "m=" section. 563 If the offerer wants to request that the answerer accepts a given 564 bundled "m=" section only if the answerer keeps the "m=" section 565 within the negotiated BUNDLE group, the offerer MUST: 567 * Include an SDP 'bundle-only' attribute (Section 7.2.1) in the "m=" 568 section, and 570 * Assign a zero port value to the "m=" section. 572 NOTE: If the offerer assigns a zero port value to a bundled "m=" 573 section, but does not include an SDP 'bundle-only' attribute in the 574 "m=" section, it is an indication that the offerer wants to disable 575 the "m=" section (Section 7.5.3). 577 Sections 7.2.2 and 18.1 show an example of an initial BUNDLE offer. 579 7.2.1. Suggesting the Offerer-Tagged 'm=' Section 581 In the initial BUNDLE offer, the bundled "m=" section indicated by 582 the offerer BUNDLE-tag is the suggested offerer-tagged "m=" section. 583 The address:port combination associated with the "m=" section will be 584 used by the offerer for sending and receiving bundled media if the 585 answerer selects the "m=" section as the offerer-tagged "m=" section 586 (Section 7.3.1). In addition, if the answerer selects the "m=" 587 section as the offerer-tagged "m=" section, the BUNDLE attributes 588 included in the "m=" section will be applied to each "m=" section 589 within the negotiated BUNDLE group. 591 The offerer MUST NOT suggest a bundle-only "m=" section as the 592 offerer-tagged "m=" section. 594 It is RECOMMENDED that the suggested offerer-tagged "m=" section be a 595 bundled "m=" section that the offerer believes is unlikely that the 596 answerer will reject or move out of the BUNDLE group. How such 597 assumption is made is outside the scope of this document. 599 7.2.2. Example: Initial SDP Offer 601 The example shows an initial BUNDLE offer. The offer includes two 602 "m=" sections in the offer and suggests that both "m=" sections are 603 included in a BUNDLE group. The audio "m=" section is the suggested 604 offerer-tagged "m=" section, indicated by placing the identification- 605 tag associated with the "m=" section (offerer BUNDLE-tag) first in 606 the SDP group:BUNDLE attribute identification-id list. 608 SDP Offer 610 v=0 611 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 612 s= 613 c=IN IP6 2001:db8::3 614 t=0 0 615 a=group:BUNDLE foo bar 617 m=audio 10000 RTP/AVP 0 8 97 618 b=AS:200 619 a=mid:foo 620 a=rtcp-mux 621 a=rtpmap:0 PCMU/8000 622 a=rtpmap:8 PCMA/8000 623 a=rtpmap:97 iLBC/8000 624 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 626 m=video 10002 RTP/AVP 31 32 627 b=AS:1000 628 a=mid:bar 629 a=rtcp-mux 630 a=rtpmap:31 H261/90000 631 a=rtpmap:32 MPV/90000 632 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 634 7.3. Generating the SDP Answer 636 When an answerer generates an answer (initial BUNDLE answer or 637 subsequent) that contains a BUNDLE group, the following general SDP 638 Grouping Framework restrictions, defined in [RFC5888], also apply to 639 the BUNDLE group: 641 * The answerer is only allowed to include a BUNDLE group in an 642 initial BUNDLE answer if the offerer requested the BUNDLE group to 643 be created in the corresponding initial BUNDLE offer; 645 * The answerer is only allowed to include a BUNDLE group in a 646 subsequent answer if the corresponding subsequent offer contains a 647 previously negotiated BUNDLE group; 649 * The answerer is only allowed to include a bundled "m=" section in 650 an answer if the "m=" section was indicated as bundled in the 651 corresponding offer; and 653 * The answerer is only allowed to include a bundled "m=" section in 654 the same BUNDLE group as the bundled "m=" line in the 655 corresponding offer. 657 In addition, when an answerer generates an answer (initial BUNDLE 658 answer or subsequent) that contains a BUNDLE group, the answerer 659 MUST: 661 * In case of an initial BUNDLE answer, select the offerer-tagged 662 "m=" section using the procedures in Section 7.3.1. In case of a 663 subsequent answer, the offerer-tagged "m=" section is indicated in 664 the corresponding subsequent offer and MUST NOT be changed by the 665 answerer; 667 * Select the answerer-tagged "m=" section (Section 7.3.1); 669 * Assign the answerer BUNDLE address:port to the answerer-tagged 670 "m=" section, and to every other bundled "m=" section within the 671 BUNDLE group; 673 * Include SDP attributes in the bundled "m=" sections following the 674 rules in Section 7.1.3; 676 * Include an SDP 'group:BUNDLE' attribute in the answer; and 678 * Place the identification-tag of each bundled "m=" section in the 679 SDP 'group:BUNDLE' attribute identification-tag list. The 680 answerer BUNDLE-tag indicates the answerer-tagged "m=" section 681 (Section 7.3.1). 683 If the answerer does not want to keep an "m=" section within a BUNDLE 684 group, it MUST: 686 * Move the "m=" section out of the BUNDLE group (Section 7.3.2); or 688 * Reject the "m=" section (Section 7.3.3). 690 The answerer can modify the answerer BUNDLE address:port, add and 691 remove SDP attributes, or modify SDP attribute values in a subsequent 692 answer. Changes to the answerer BUNDLE address:port and the answerer 693 BUNDLE attributes will be applied to each bundled "m=" section within 694 the BUNDLE group. 696 NOTE: If a bundled "m=" section in an offer contains a zero port 697 value, but the "m=" section does not contain an SDP 'bundle-only' 698 attribute, it is an indication that the offerer wants to disable the 699 "m=" section (Section 7.5.3). 701 NOTE: In RFC 8843, instead of assigning the offerer BUNDLE 702 address:port to each "m=" section within the BUNDLE group when 703 modifying the session (Section 7.5), the offerer only assigned the 704 offerer BUNDLE address:port to the offerer-tagged "m=" section. For 705 every other "m=" section within the BUNDLE group, the offerer 706 included an SDP 'bundle-only' attribute in, and assigned a zero port 707 value to, the "m=" section. In order to be backward compatible with 708 offerers that implement that version of the specification, an 709 answerer needs to accept such offers. 711 7.3.1. Answerer Selection of Tagged 'm=' Sections 713 When selecting the offerer-tagged "m=" section, the answerer MUST 714 first check whether the "m=" section fulfills the following criteria 715 Section 7.2.1: 717 * The answerer will not move the "m=" section out of the BUNDLE 718 group (Section 7.3.2); 720 * The answerer will not reject the "m=" section (Section 7.3.3); and 722 * The "m=" section does not contain a zero port value. 724 If all of the criteria above are fulfilled, the answerer MUST select 725 the "m=" section as the offerer-tagged "m=" section and MUST also 726 mark the corresponding "m=" section in the answer as the answerer- 727 tagged "m=" section. In the answer, the answerer BUNDLE-tag 728 indicates the answerer-tagged "m=" section. 730 If one or more of the criteria are not fulfilled, the answerer MUST 731 pick the next identification-tag in the identification-tag list in 732 the offer and perform the same criteria check for the "m=" section 733 indicated by that identification-tag. If there are no more 734 identification-tags in the identification-tag list, the answerer MUST 735 NOT create the BUNDLE group. Unless the answerer rejects the whole 736 offer, the answerer MUST apply the answerer procedures for moving an 737 "m=" section out of a BUNDLE group (Section 7.3.2) or rejecting an 738 "m=" section within a BUNDLE group (Section 7.3.3) to every bundled 739 "m=" section in the offer when creating the answer. 741 Section 18.1 shows an example of an offerer BUNDLE address:port 742 selection. 744 Sections 7.3.4 and 18.1 show an example of an answerer-tagged "m=" 745 section selection. 747 7.3.2. Moving a Media Description Out of a BUNDLE Group 749 When an answerer generates the answer, if the answerer wants to move 750 a bundled "m=" section out of the negotiated BUNDLE group, the 751 answerer MUST first check the following criteria: 753 * In the corresponding offer, the "m=" section is within a 754 previously negotiated BUNDLE group, and 756 * In the corresponding offer, the "m=" section contains an SDP 757 'bundle-only' attribute. 759 If either criterion above is fulfilled, the answerer cannot move the 760 "m=" section out of the BUNDLE group in the answer. The answerer can 761 reject the whole offer, reject each bundled "m=" section within the 762 BUNDLE group (Section 7.3.3), or keep the "m=" section within the 763 BUNDLE group in the answer and later create an offer where the "m=" 764 section is moved out of the BUNDLE group (Section 7.5.2). 766 NOTE: One consequence of the rules above is that, once a BUNDLE group 767 has been negotiated, a bundled "m=" section cannot be moved out of 768 the BUNDLE group in an answer. Instead, an offer is needed. 770 When the answerer generates an answer, in which it moves a bundled 771 "m=" section out of a BUNDLE group, the answerer: 773 * MUST assign a unique address:port to the "m=" section; 775 * MUST include any applicable SDP attribute in the "m=" section, 776 using the normal offer/answer procedures for each attribute; 778 * MUST NOT place the identification-tag associated with the "m=" 779 section in the SDP 'group:BUNDLE' attribute identification-tag 780 list associated with the BUNDLE group; and 782 * MUST NOT include an SDP 'bundle-only' attribute to the "m=" 783 section. 785 Because an answerer is not allowed to move an "m=" section from one 786 BUNDLE group to another within an answer (Section 7.3), if the 787 answerer wants to move an "m=" section from one BUNDLE group to 788 another, it MUST first move the "m=" section out of the current 789 BUNDLE group and then generate an offer where the "m=" section is 790 added to another BUNDLE group (Section 7.5.1). 792 7.3.3. Rejecting a Media Description in a BUNDLE Group 794 When an answerer wants to reject a bundled "m=" section in an answer, 795 it MUST first check the following criterion: 797 * In the corresponding offer, the "m=" section is the offerer-tagged 798 "m=" section. 800 If the criterion above is fulfilled, the answerer cannot reject the 801 "m=" section in the answer. The answerer can reject the whole offer, 802 reject each bundled "m=" section within the BUNDLE group, or keep the 803 "m=" section within the BUNDLE group in the answer and later create 804 an offer where the "m=" section is disabled within the BUNDLE group 805 (Section 7.5.3). 807 When an answerer generates an answer, in which it rejects a bundled 808 "m=" section, the answerer: 810 * MUST assign a zero port value to the "m=" section, according to 811 the procedures in [RFC3264]; 813 * MUST NOT place the identification-tag associated with the "m=" 814 section in the SDP 'group:BUNDLE' attribute identification-tag 815 list associated with the BUNDLE group; and 817 * MUST NOT include an SDP 'bundle-only' attribute in the "m=" 818 section. 820 7.3.4. Example: SDP Answer 822 The example below shows an answer, based on the corresponding offer 823 in Section 7.2.2. The answerer accepts both bundled "m=" sections 824 within the created BUNDLE group. The audio "m=" section is the 825 answerer-tagged "m=" section, indicated by placing the 826 identification-tag associated with the "m=" section (answerer BUNDLE- 827 tag) first in the SDP group;BUNDLE attribute identification-id list. 828 The answerer includes an SDP 'bundle-only' attribute in, and assigns 829 a zero port value to, the video "m=" section. 831 SDP Answer 833 v=0 834 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 835 s= 836 c=IN IP6 2001:db8::1 837 t=0 0 838 a=group:BUNDLE foo bar 840 m=audio 20000 RTP/AVP 0 841 b=AS:200 842 a=mid:foo 843 a=rtcp-mux 844 a=rtpmap:0 PCMU/8000 845 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 847 m=video 20000 RTP/AVP 32 848 b=AS:1000 849 a=mid:bar 850 a=rtpmap:32 MPV/90000 851 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 853 7.4. Offerer Processing of the SDP Answer 855 When an offerer receives an answer, if the answer contains a BUNDLE 856 group, the offerer MUST check that any bundled "m=" section in the 857 answer was indicated as bundled in the corresponding offer. If there 858 is no mismatch, the offerer MUST apply the properties (BUNDLE 859 address:port, BUNDLE attributes, etc.) of the offerer-tagged "m=" 860 section (selected by the answerer; see Section 7.3.1) to each bundled 861 "m=" section within the BUNDLE group. 863 NOTE: As the answerer might reject one or more bundled "m=" sections 864 in an initial BUNDLE offer, or move a bundled "m=" section out of a 865 BUNDLE group, a given bundled "m=" section in the offer might not be 866 indicated as bundled in the corresponding answer. 868 If the answer does not contain a BUNDLE group, the offerer MUST 869 process the answer as a normal answer. 871 NOTE: In RFC 8843, instead of assigning the answerer BUNDLE 872 address:port to each "m=" section within the BUNDLE group when 873 generating the answer (Section 7.3), the answerer only assigned the 874 answerer BUNDLE address:port to the answerer-tagged "m=" section. 875 For every other "m=" section within the BUNDLE group, the answerer 876 included an SDP 'bundle-only' attribute in, and assigned a zero port 877 value to, the "m=" section. In order to be backward compatible with 878 answerers that implement that version of the specification, an 879 offerer needs to accept such offers. 881 7.5. Modifying the Session 883 When a BUNDLE group has been previously negotiated, and an offerer 884 generates a subsequent offer, the offerer MUST: 886 * Pick one bundled "m=" section as the offerer-tagged "m=" section. 887 The offerer can pick either the "m=" section that was previously 888 selected by the answerer as the offerer-tagged "m=" section or 889 another bundled "m=" section within the BUNDLE group; 891 * Assign a BUNDLE address:port (previously negotiated or newly 892 suggested) to the offerer-tagged "m=" section, and to every other 893 bundled "m=" section within the BUNDLE group; 895 * Include SDP attributes in the bundled "m=" sections following the 896 rules in Section 7.1.3; 898 * Include an SDP 'group:BUNDLE' attribute in the offer; and 900 * Place the identification-tag of each bundled "m=" section in the 901 SDP 'group:BUNDLE' attribute identification-tag list. The offerer 902 BUNDLE-tag indicates the offerer-tagged "m=" section. 904 The offerer MUST NOT pick a given bundled "m=" section as the 905 offerer-tagged "m=" section if: 907 * The offerer wants to move the "m=" section out of the BUNDLE group 908 (Section 7.5.2), or 910 * The offerer wants to disable the "m=" section (Section 7.5.3). 912 The offerer can modify the offerer BUNDLE address:port, add and 913 remove SDP attributes, or modify SDP attribute values in the 914 subsequent offer. Changes to the offerer BUNDLE address:port and the 915 offerer BUNDLE attributes will (if the offer is accepted by the 916 answerer) be applied to each bundled "m=" section within the BUNDLE 917 group. 919 7.5.1. Adding a Media Description to a BUNDLE Group 921 When an offerer generates a subsequent offer, in which it wants to 922 add a bundled "m=" section to a previously negotiated BUNDLE group, 923 the offerer follows the procedures in Section 7.5. The offerer picks 924 either the added "m=" section or an "m=" section previously added to 925 the BUNDLE group as the offerer-tagged "m=" section. 927 NOTE: As described in Section 7.3.2, the answerer cannot move the 928 added "m=" section out of the BUNDLE group in its answer. If the 929 answer wants to move the "m=" section out of the BUNDLE group, it 930 will have to first accept it into the BUNDLE group in the answer, and 931 then send a subsequent offer where the "m=" section is moved out of 932 the BUNDLE group (Section 7.5.2). 934 7.5.2. Moving a Media Description Out of a BUNDLE Group 936 When an offerer generates a subsequent offer, in which it wants to 937 remove a bundled "m=" section from a BUNDLE group, the offerer: 939 * MUST assign a unique address:port to the "m=" section; 941 * MUST include SDP attributes in the "m=" section following the 942 normal offer/answer rules for each attribute; 944 * MUST NOT place the identification-tag associated with the "m=" 945 section in the SDP 'group:BUNDLE' attribute identification-tag 946 list associated with the BUNDLE group; and 948 * MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 949 section. 951 For the other bundled "m=" sections within the BUNDLE group, the 952 offerer follows the procedures in Section 7.5. 954 An offerer MUST NOT move an "m=" section from one BUNDLE group to 955 another within a single offer. If the offerer wants to move an "m=" 956 section from one BUNDLE group to another, it MUST first move the 957 BUNDLE group out of the current BUNDLE group, and then generate a 958 second offer where the "m=" section is added to another BUNDLE group 959 (Section 7.5.1). 961 Section 18.4 shows an example of an offer for moving an "m=" section 962 out of a BUNDLE group. 964 7.5.3. Disabling a Media Description in a BUNDLE Group 966 When an offerer generates a subsequent offer, in which it wants to 967 disable a bundled "m=" section from a BUNDLE group, the offerer: 969 * MUST assign a zero port value to the "m=" section, following the 970 procedures in [RFC4566]; 972 * MUST NOT place the identification-tag associated with the "m=" 973 section in the SDP 'group:BUNDLE' attribute identification-tag 974 list associated with the BUNDLE group; and 976 * MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 977 section. 979 For the other bundled "m=" sections within the BUNDLE group, the 980 offerer follows the procedures in Section 7.5. 982 Section 18.5 shows an example of an offer and answer for disabling an 983 "m=" section within a BUNDLE group. 985 8. Protocol Identification 987 Each "m=" section within a BUNDLE group MUST use the same transport- 988 layer protocol. If bundled "m=" sections use different upper-layer 989 protocols on top of the transport-layer protocol, there MUST exist a 990 publicly available specification that describes how a mechanism 991 associates received data with the correct protocol for this 992 particular protocol combination. 994 In addition, if received data can be associated with more than one 995 bundled "m=" section, there MUST exist a publicly available 996 specification that describes a mechanism for associating the received 997 data with the correct "m=" section. 999 This document describes a mechanism to identify the protocol of 1000 received data among the Session Traversal Utilities for NAT (STUN), 1001 DTLS, and the Secure Real-time Transport Protocol (SRTP) (in any 1002 combination) when UDP is used as a transport-layer protocol, but it 1003 does not describe how to identify different protocols transported on 1004 DTLS. While the mechanism is generally applicable to other protocols 1005 and transport-layer protocols, any such use requires further 1006 specification that encompasses how to multiplex multiple protocols on 1007 a given transport-layer protocol and how to associate received data 1008 with the correct protocols. 1010 8.1. STUN, DTLS, and SRTP 1012 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 1013 protocol of a received packet among the STUN, DTLS, and SRTP 1014 protocols (in any combination). If an offer or answer includes a 1015 bundled "m=" section that represents these protocols, the offerer or 1016 answerer MUST support the mechanism described in [RFC5764], and no 1017 explicit negotiation is required in order to indicate support and 1018 usage of the mechanism. 1020 [RFC5764] does not describe how to identify different protocols 1021 transported on DTLS, only how to identify the DTLS protocol itself. 1022 If multiple protocols are transported on DTLS, there MUST exist a 1023 specification describing a mechanism for identifying each individual 1024 protocol. In addition, if a received DTLS packet can be associated 1025 with more than one "m=" section, there MUST exist a specification 1026 that describes a mechanism for associating the received DTLS packets 1027 with the correct "m=" section. 1029 Section 9.2 describes how to associate the packets in a received SRTP 1030 stream with the correct "m=" section. 1032 9. RTP Considerations 1034 9.1. Single RTP Session 1036 All RTP-based media within a single BUNDLE group belong to a single 1037 RTP session [RFC3550]. 1039 Since a single BUNDLE transport is used for sending and receiving 1040 bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for 1041 RTP-based bundled media. 1043 Since a single RTP session is used for each BUNDLE group, all "m=" 1044 sections representing RTP-based media within a BUNDLE group will 1045 share a single Synchronization Source (SSRC) numbering space 1046 [RFC3550]. 1048 The following rules and restrictions apply for a single RTP session: 1050 * A specific payload type value can be used in multiple bundled "m=" 1051 sections only if each codec associated with the payload type 1052 number shares an identical codec configuration (Section 9.1.1). 1054 * The proto value in each bundled RTP-based "m=" section MUST be 1055 identical (e.g., RTP/AVPF). 1057 * The RTP MID header extension MUST be enabled, by including an SDP 1058 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 1059 hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section 1060 in every offer and answer. 1062 * A given SSRC MUST NOT transmit RTP packets using payload types 1063 that originate from different bundled "m=" sections. 1065 NOTE: The last bullet above is to avoid sending multiple media types 1066 from the same SSRC. If transmission of multiple media types are done 1067 with time overlap, RTP and RTCP fail to function. Even if done in 1068 proper sequence, this causes RTP timestamp rate switching issues 1069 [RFC7160]. However, once an SSRC has left the RTP session (by 1070 sending an RTCP BYE packet), that SSRC can be reused by another 1071 source (possibly associated with a different bundled "m=" section) 1072 after a delay of 5 RTCP reporting intervals (the delay is to ensure 1073 the SSRC has timed out, in case the RTCP BYE packet was lost 1074 [RFC3550]). 1076 [RFC7657] defines Differentiated Services (Diffserv) considerations 1077 for RTP-based bundled media sent using a mixture of Diffserv 1078 Codepoints. 1080 9.1.1. Payload Type (PT) Value Reuse 1082 Multiple bundled "m=" sections might describe RTP-based media. As 1083 all RTP-based media associated with a BUNDLE group belong to the same 1084 RTP session, in order for a given payload type value to be used 1085 inside more than one bundled "m=" section, all codecs associated with 1086 the payload type number MUST share an identical codec configuration. 1087 This means that the codecs MUST share the same media type, encoding 1088 name, clock rate, and any parameter that can affect the codec 1089 configuration and packetization. [RFC8859] lists SDP attributes, 1090 whose attribute values are required to be identical for all codecs 1091 that use the same payload type value. 1093 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 1094 Description 1096 As described in [RFC3550], RTP packets are associated with RTP 1097 streams [RFC7656]. Each RTP stream is identified by an SSRC value, 1098 and each RTP packet includes an SSRC field that is used to associate 1099 the packet with the correct RTP stream. RTCP packets also use SSRCs 1100 to identify which RTP streams the packet relates to. However, an 1101 RTCP packet can contain multiple SSRC fields, in the course of 1102 providing feedback or reports on different RTP streams, and therefore 1103 can be associated with multiple such streams. 1105 In order to be able to process received RTP/RTCP packets correctly, 1106 it MUST be possible to associate an RTP stream with the correct "m=" 1107 section, as the "m=" section and SDP attributes associated with the 1108 "m=" section contains information needed to process the packets. 1110 As all RTP streams associated with a BUNDLE group use the same 1111 transport for sending and receiving RTP/RTCP packets, the local 1112 address:port combination part of the transport cannot be used to 1113 associate an RTP stream with the correct "m=" section. In addition, 1114 multiple RTP streams might be associated with the same "m=" section. 1116 An offerer and answerer can inform each other which SSRC values they 1117 will use for an RTP stream by using the SDP 'ssrc' attribute 1118 [RFC5576]. However, an offerer will not know which SSRC values the 1119 answerer will use until the offerer has received the answer providing 1120 that information. Due to this, before the offerer has received the 1121 answer, the offerer will not be able to associate an RTP stream with 1122 the correct "m=" section using the SSRC value associated with the RTP 1123 stream. In addition, the offerer and answerer may start using new 1124 SSRC values mid-session, without informing each other about using the 1125 SDP 'ssrc' attribute. 1127 In order for an offerer and answerer to always be able to associate 1128 an RTP stream with the correct "m=" section, the offerer and answerer 1129 using the BUNDLE extension MUST support the mechanism defined in 1130 Section 15, where the offerer and answerer insert the identification- 1131 tag associated with an "m=" section (provided by the remote peer) 1132 into RTP and RTCP packets associated with a BUNDLE group. 1134 When using this mechanism, the mapping from an SSRC to an 1135 identification-tag is carried in RTP header extensions or RTCP SDES 1136 packets, as specified in Section 15. Since a compound RTCP packet 1137 can contain multiple RTCP SDES packets, and each RTCP SDES packet can 1138 contain multiple chunks, a single RTCP packet can contain several 1139 mappings of SSRC to identification-tag. The offerer and answerer 1140 maintain tables used for routing that are updated each time an RTP/ 1141 RTCP packet contains new information that affects how packets are to 1142 be routed. 1144 However, some legacy implementations may not include this 1145 identification-tag in their RTP and RTCP traffic when using the 1146 BUNDLE mechanism and instead use a mechanism based on the payload 1147 type to associate RTP streams with SDP "m=" sections. In this 1148 situation, each "m=" section needs to use unique payload type values, 1149 in order for the payload type to be a reliable indicator of the 1150 relevant "m=" section for the RTP stream. If an implementation fails 1151 to ensure unique payload type values, it will be impossible to 1152 associate the RTP stream using that payload type value to a 1153 particular "m=" section. Note that when using the payload type to 1154 associate RTP streams with "m=" sections, an RTP stream, identified 1155 by its SSRC, will be mapped to an "m=" section when the first packet 1156 of that RTP stream is received, and the mapping will not be changed 1157 even if the payload type used by that RTP stream changes. In other 1158 words, the SSRC cannot "move" to a different "m=" section simply by 1159 changing the payload type. 1161 Applications can implement RTP stacks in many different ways. The 1162 algorithm below details one way that RTP streams can be associated 1163 with "m=" sections, but it is not meant to be prescriptive about 1164 exactly how an RTP stack needs to be implemented. Applications MAY 1165 use any algorithm that achieves equivalent results to those described 1166 in the algorithm below. 1168 To prepare to associate RTP streams with the correct "m=" section, 1169 the following steps MUST be followed for each BUNDLE group: 1171 * Construct a table mapping a MID to an "m=" section for each "m=" 1172 section in this BUNDLE group. Note that an "m=" section may only 1173 have one MID. 1175 * Construct a table mapping SSRCs of incoming RTP streams to an "m=" 1176 section for each "m=" section in this BUNDLE group and for each 1177 SSRC configured for receiving in that "m=" section. 1179 * Construct a table mapping the SSRC of each outgoing RTP stream to 1180 an "m=" section for each "m=" section in this BUNDLE group and for 1181 each SSRC configured for sending in that "m=" section. 1183 * Construct a table mapping a payload type to an "m=" section for 1184 each "m=" section in the BUNDLE group and for each payload type 1185 configured for receiving in that "m=" section. If any payload 1186 type is configured for receiving in more than one "m=" section in 1187 the BUNDLE group, do not include it in the table, as it cannot be 1188 used to uniquely identify an "m=" section. 1190 * Note that for each of these tables, there can only be one mapping 1191 for any given key (MID, SSRC, or PT). In other words, the tables 1192 are not multimaps. 1194 As "m=" sections are added or removed from the BUNDLE groups, or 1195 their configurations are changed, the tables above MUST also be 1196 updated. 1198 When an RTP packet is received, it MUST be delivered to the RTP 1199 stream corresponding to its SSRC. That RTP stream MUST then be 1200 associated with the correct "m=" section within a BUNDLE group, for 1201 additional processing, according to the following steps: 1203 * If the MID associated with the RTP stream is not in the table 1204 mapping a MID to an "m=" section, then the RTP stream is not 1205 decoded and the payload data is discarded. 1207 * If the packet has a MID, and the packet's extended sequence number 1208 is greater than that of the last MID update, as discussed in 1209 [RFC7941], Section 4.2.2, update the MID associated with the RTP 1210 stream to match the MID carried in the RTP packet, and then update 1211 the mapping tables to include an entry that maps the SSRC of that 1212 RTP stream to the "m=" section for that MID. 1214 * If the SSRC of the RTP stream is in the incoming SSRC mapping 1215 table, check that the payload type used by the RTP stream matches 1216 a payload type included on the matching "m=" section. If so, 1217 associate the RTP stream with that "m=" section. Otherwise, the 1218 RTP stream is not decoded and the payload data is discarded. 1220 * If the payload type used by the RTP stream is in the payload type 1221 table, update the incoming SSRC mapping table to include an entry 1222 that maps the RTP stream's SSRC to the "m=" section for that 1223 payload type. Associate the RTP stream with the corresponding 1224 "m=" section. 1226 * Otherwise, mark the RTP stream as "not for decoding" and discard 1227 the payload. 1229 If the RTP packet contains one or more Contributing Source (CSRC) 1230 identifiers, then each CSRC is looked up in the incoming SSRC table, 1231 and a copy of the RTP packet is associated with the corresponding 1232 "m=" section for additional processing. 1234 For each RTCP packet received (including each RTCP packet that is 1235 part of a compound RTCP packet), the packet is processed as usual by 1236 the RTP layer, then associated with the appropriate "m=" sections, 1237 and processed for the RTP streams represented by those "m=" sections. 1238 This routing is type dependent, as each kind of RTCP packet has its 1239 own mechanism for associating it with the relevant RTP streams. 1241 RTCP packets that cannot be associated with an appropriate "m=" 1242 section MUST still be processed as usual by the RTP layer, which 1243 updates the metadata associated with the corresponding RTP streams. 1244 This situation can occur with certain multiparty RTP topologies or 1245 when RTCP packets are sent containing a subset of the SDES 1246 information. 1248 Additional rules for processing various types of RTCP packets are 1249 explained below. 1251 * If the RTCP packet is of type SDES, for each chunk in the packet 1252 whose SSRC is found in the incoming SSRC table, deliver a copy of 1253 the SDES packet to the "m=" section associated with that SSRC. In 1254 addition, for any SDES MID items contained in these chunks, if the 1255 MID is found in the table mapping a MID to an "m=" section, update 1256 the incoming SSRC table to include an entry that maps the RTP 1257 stream associated with the chunk's SSRC to the "m=" section 1258 associated with that MID, unless the packet is older than the 1259 packet that most recently updated the mapping for this SSRC, as 1260 discussed in [RFC7941], Section 4.2.6. 1262 * Note that if an SDES packet is received as part of a compound RTCP 1263 packet, the SSRC to "m=" section mapping might not exist until the 1264 SDES packet is handled (e.g., in the case where RTCP for a source 1265 is received before any RTP packets). Therefore, it can be 1266 beneficial for an implementation to delay RTCP packet routing, 1267 such that it either prioritizes processing of the SDES item to 1268 generate or update the mapping or buffers the RTCP information 1269 that needs to be routed until the SDES item(s) has been processed. 1270 If the implementation is unable to follow this recommendation, the 1271 consequence could be that some RTCP information from this 1272 particular RTCP compound packet is not provided to higher layers. 1273 The impact from this is likely minor, when this information 1274 relates to a future incoming RTP stream. 1276 * If the RTCP packet is of type BYE, it indicates that the RTP 1277 streams referenced in the packet are ending. Therefore, for each 1278 SSRC indicated in the packet that is found in the incoming SSRC 1279 table, first deliver a copy of the BYE packet to the "m=" section 1280 associated with that SSRC, and then remove the entry for that SSRC 1281 from the incoming SSRC table after an appropriate delay to account 1282 for "straggler packets", as specified in [RFC3550], Section 6.2.1. 1284 * If the RTCP packet is of type Sender Report (SR) or Receiver 1285 Report (RR), for each report block in the report whose "SSRC of 1286 source" is found in the outgoing SSRC table, deliver a copy of the 1287 SR or RR packet to the "m=" section associated with that SSRC. In 1288 addition, if the packet is of type SR, and the sender SSRC for the 1289 packet is found in the incoming SSRC table, deliver a copy of the 1290 SR packet to the "m=" section associated with that SSRC. 1292 * If the implementation supports the RTCP Extended Report (XR) and 1293 the packet is of type XR, as defined in [RFC3611], for each report 1294 block in the report whose "SSRC of source" is found in the 1295 outgoing SSRC table, deliver a copy of the XR packet to the "m=" 1296 section associated with that SSRC. In addition, if the sender 1297 SSRC for the packet is found in the incoming SSRC table, deliver a 1298 copy of the XR packet to the "m=" section associated with that 1299 SSRC. 1301 * If the RTCP packet is a feedback message of type RTPFB (transport- 1302 layer FB message) or PSFB (payload-specific FB message), as 1303 defined in [RFC4585], it will contain a media source SSRC, and 1304 this SSRC is used for routing certain subtypes of feedback 1305 messages. However, several subtypes of PSFB and RTPFB messages 1306 include a target SSRC(s) in a section called Feedback Control 1307 Information (FCI). For these messages, the target SSRC(s) is used 1308 for routing. 1310 * If the RTCP packet is a feedback packet that does not include 1311 target SSRCs in its FCI section, and the media source SSRC is 1312 found in the outgoing SSRC table, deliver the feedback packet to 1313 the "m=" section associated with that SSRC. RTPFB and PSFB types 1314 that are handled in this way include: 1316 Generic NACK: (PT=RTPFB, FMT=1) [RFC4585]. 1318 Picture Loss Indication (PLI): (PT=PSFB, FMT=1) [RFC4585]. 1320 Slice Loss Indication (SLI): (PT=PSFB, FMT=2) [RFC4585]. 1322 Reference Picture Selection Indication (RPSI): (PT=PSFB, 1323 FMT=3) [RFC4585]. 1325 * If the RTCP packet is a feedback message that does include a 1326 target SSRC(s) in its FCI section, it can either be a request or a 1327 notification. Requests reference an RTP stream that is being sent 1328 by the message recipient, whereas notifications are responses to 1329 an earlier request and therefore reference an RTP stream that is 1330 being received by the message recipient. 1332 * If the RTCP packet is a feedback request that includes a target 1333 SSRC(s), for each target SSRC that is found in the outgoing SSRC 1334 table, deliver a copy of the RTCP packet to the "m=" section 1335 associated with that SSRC. PSFB and RTPFB types that are handled 1336 in this way include: 1338 Full Intra Request (FIR): (PT=PSFB, FMT=4) [RFC5104]. 1340 Temporal-Spatial Trade-off Request (TSTR): (PT=PSFB, FMT=5) 1341 [RFC5104]. 1343 H.271 Video Back Channel Message (VBCM): (PT=PSFB, FMT=7) 1344 [RFC5104]. 1346 Temporary Maximum Media Stream Bit Rate Request (TMMBR): (PT=R 1347 TPFB, FMT=3) [RFC5104]. 1349 Layer Refresh Request (LRR): (PT=PSFB, FMT=10) [LLR-RTCP]. 1351 * If the RTCP packet is a feedback notification that includes a 1352 target SSRC(s), for each target SSRC that is found in the incoming 1353 SSRC table, deliver a copy of the RTCP packet to the "m=" section 1354 associated with the RTP stream with a matching SSRC. PSFB and 1355 RTPFB types that are handled in this way include: 1357 Temporal-Spatial Trade-off Notification (TSTN): (PT=PSFB, 1358 FMT=6) [RFC5104]. This message is a notification in 1359 response to a prior TSTR. 1361 Temporary Maximum Media Stream Bit Rate Notification 1362 (TMMBN): (PT=RTPFB, FMT=4) [RFC5104]. This message is a 1363 notification in response to a prior TMMBR, but it can also 1364 be sent unsolicited. 1366 If the RTCP packet is of type APP, then it is handled in an 1367 application-specific manner. If the application does not 1368 recognize the APP packet, then it MUST be discarded. 1370 9.3. RTP/RTCP Multiplexing 1372 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 1373 multiplexing [RFC5761] for the RTP-based bundled media (i.e., the 1374 same transport will be used for both RTP packets and RTCP packets). 1375 In addition, the offerer and answerer MUST support the SDP 'rtcp-mux- 1376 only' attribute [RFC8858]. 1378 9.3.1. SDP Offer/Answer Procedures 1380 This section describes how an offerer and answerer use the SDP 'rtcp- 1381 mux' [RFC5761] and SDP 'rtcp-mux-only' attributes [RFC8858] to 1382 negotiate usage of RTP/RTCP multiplexing for RTP-based bundled media. 1384 RTP/RTCP multiplexing only applies to RTP-based media. However, as 1385 described in Section 7.1.3, within an offer or answer the SDP 'rtcp- 1386 mux' and SDP 'rtcp-mux-only' attributes might be included in a 1387 bundled "m=" section for non-RTP-based media (if such "m=" section is 1388 the offerer-tagged "m=" section or answerer-tagged "m=" section). 1390 9.3.1.1. Generating the Initial SDP BUNDLE Offer 1392 When an offerer generates an initial BUNDLE offer, if the offer 1393 contains one or more bundled "m=" sections for RTP-based media (or, 1394 if there is a chance that "m=" sections for RTP-based media will 1395 later be added to the BUNDLE group), the offerer MUST include an SDP 1396 'rtcp-mux' attribute [RFC5761] in each bundled "m=" section 1397 (excluding any bundle-only "m=" sections). In addition, the offerer 1398 MAY include an SDP 'rtcp-mux-only' attribute [RFC8858] in one or more 1399 bundled "m=" sections for RTP-based media. 1401 NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute 1402 depends on whether the offerer supports fallback to usage of a 1403 separate port for RTCP in case the answerer moves one or more "m=" 1404 sections for RTP-based media out of the BUNDLE group in the answer. 1406 NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the 1407 bundled "m=" sections, but does not include an SDP 'rtcp-mux-only' 1408 attribute, the offerer can also include an SDP 'rtcp' attribute 1409 [RFC3605] in one or more RTP-based bundled "m=" sections in order to 1410 provide a fallback port for RTCP, as described in [RFC5761]. 1411 However, the fallback port will only be applied to "m=" sections for 1412 RTP-based media that are moved out of the BUNDLE group by the 1413 answerer. 1415 In the initial BUNDLE offer, the address:port combination for RTCP 1416 MUST be unique in each bundled "m=" section for RTP-based media 1417 (excluding a bundle-only "m=" section), similar to RTP. 1419 9.3.1.2. Generating the SDP Answer 1421 When an answerer generates an answer, if the answerer supports RTP- 1422 based media, and if a bundled "m=" section in the corresponding offer 1423 contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage 1424 of RTP/RTCP multiplexing, even if there currently are no bundled "m=" 1425 sections for RTP-based media within the BUNDLE group. The answerer 1426 MUST include an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" 1427 section, following the procedures for BUNDLE attributes 1428 (Section 7.1.3). In addition, if the "m=" section that is selected 1429 as the offerer-tagged "m=" section contained an SDP 'rtcp-mux-only' 1430 attribute, the answerer MUST include an SDP 'rtcp-mux-only' attribute 1431 in the answerer-tagged "m=" section. 1433 In an initial BUNDLE offer, if the suggested offerer-tagged "m=" 1434 section contained an SDP 'rtcp-mux-only' attribute, the "m=" section 1435 was for RTP-based media; thus, the answerer does not accept the "m=" 1436 section in the created BUNDLE group, and the answerer MUST move the 1437 "m=" section out of the BUNDLE group (Section 7.3.2); include the 1438 attribute in the moved "m=" section and enable RTP/RTCP multiplexing 1439 for the media associated with the "m=" section; or reject the "m=" 1440 section (Section 7.3.3). 1442 The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled 1443 "m=" section in the answer. The answerer will use the port value of 1444 the offerer-tagged "m=" section sending RTP and RTCP packets 1445 associated with RTP-based bundled media towards the offerer. 1447 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1448 negotiated in a previous offer/answer exchange, the answerer MUST 1449 include an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" 1450 section. It is not possible to disable RTP/RTCP multiplexing within 1451 a BUNDLE group. 1453 9.3.1.3. Offerer Processing of the SDP Answer 1455 When an offerer receives an answer, if the answerer has accepted the 1456 usage of RTP/RTCP multiplexing (Section 9.3.1.2), the answerer 1457 follows the procedures for RTP/RTCP multiplexing defined in 1458 [RFC5761]. The offerer will use the port value of the answerer- 1459 tagged "m=" section for sending RTP and RTCP packets associated with 1460 RTP-based bundled media towards the answerer. 1462 NOTE: It is considered a protocol error if the answerer has not 1463 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" 1464 sections that the answerer included in the BUNDLE group. 1466 9.3.1.4. Modifying the Session 1468 When an offerer generates a subsequent offer, the offerer MUST 1469 include an SDP 'rtcp-mux' attribute in the offerer-tagged "m=" 1470 section, following the procedures for IDENTICAL multiplexing category 1471 attributes in Section 7.1.3. 1473 10. ICE Considerations 1475 This section describes how to use the BUNDLE grouping extension 1476 together with the ICE mechanism [RFC8445]. 1478 The generic procedures for negotiating the usage of ICE using SDP, 1479 defined in [RFC8839], also apply to the usage of ICE with BUNDLE, 1480 with the following exceptions: 1482 * When the BUNDLE transport has been established, ICE connectivity 1483 checks and keepalives only need to be performed for the BUNDLE 1484 transport, instead of per individual bundled "m=" section within 1485 the BUNDLE group. 1487 * The generic SDP attribute offer/answer considerations 1488 (Section 7.1.3) also apply to ICE-related attributes. Therefore, 1489 when an offerer sends an initial BUNDLE offer (in order to 1490 negotiate a BUNDLE group), the offerer includes ICE-related media- 1491 level attributes in each bundled "m=" section (excluding any 1492 bundle-only "m=" sections), and each "m=" section MUST contain 1493 unique ICE properties. When an answerer generates an answer 1494 (initial BUNDLE answer or subsequent) that contains a BUNDLE 1495 group, and when an offerer sends a subsequent offer that contains 1496 a BUNDLE group, ICE-related media-level attributes are only 1497 included in the tagged "m=" section (suggested offerer-tagged "m=" 1498 section or answerer-tagged "m=" section), and the ICE properties 1499 are applied to each bundled "m=" section within the BUNDLE group. 1501 NOTE: Most ICE-related media-level SDP attributes belong to the 1502 TRANSPORT multiplexing category [RFC8859], and the generic SDP 1503 attribute offer/answer considerations for the TRANSPORT multiplexing 1504 category apply to the attributes. However, in the case of ICE- 1505 related attributes, the same considerations also apply to ICE-related 1506 media-level attributes that belong to other multiplexing categories. 1508 NOTE: The following ICE-related media-level SDP attributes are 1509 defined in [RFC8839]: 'candidate', 'remote-candidates', 'ice- 1510 mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-pacing'. 1512 Initially, before ICE has produced selected candidate pairs that will 1513 be used for media, there might be multiple transports established (if 1514 multiple candidate pairs are tested). Once ICE has selected 1515 candidate pairs, they form the BUNDLE transport. 1517 Support and usage of the ICE mechanism together with the BUNDLE 1518 extension is OPTIONAL, and the procedures in this section only apply 1519 when the ICE mechanism is used. Note that applications might mandate 1520 usage of the ICE mechanism even if the BUNDLE extension is not used. 1522 NOTE: If the Trickle ICE mechanism [RFC8840] is used, an offerer and 1523 answerer might assign a port value of '9' and an IPv4 address of 1524 '0.0.0.0' (or, the IPv6 equivalent '::') to multiple bundled "m=" 1525 sections in the initial BUNDLE offer. The offerer and answerer will 1526 follow the normal procedures for generating the offers and answers, 1527 including picking a bundled "m=" section as the suggested offerer- 1528 tagged "m=" section, selecting the tagged "m=" sections, etc. The 1529 only difference is that media cannot be sent until one or more 1530 candidates have been provided. Once a BUNDLE group has been 1531 negotiated, trickled candidates associated with a bundled "m=" 1532 section will be applied to all bundled "m=" sections within the 1533 BUNDLE group. 1535 11. DTLS Considerations 1537 One or more media streams within a BUNDLE group might use the 1538 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1539 to encrypt the data or negotiate encryption keys if another 1540 encryption mechanism is used to encrypt media. 1542 When DTLS is used within a BUNDLE group, the following rules apply: 1544 * There can only be one DTLS association [RFC6347] associated with 1545 the BUNDLE group; 1547 * Each usage of the DTLS association within the BUNDLE group MUST 1548 use the same mechanism for determining which endpoints (the 1549 offerer or answerer) become DTLS client and DTLS server; 1551 * Each usage of the DTLS association within the BUNDLE group MUST 1552 use the same mechanism for determining whether an offer or answer 1553 will trigger the establishment of a new DTLS association or an 1554 existing DTLS association will be used; and 1556 * If the DTLS client supports DTLS-SRTP, it MUST include the 1557 'use_srtp' extension in the DTLS ClientHello message [RFC5764]. 1558 The client MUST include the extension even if the usage of DTLS- 1559 SRTP is not negotiated as part of the multimedia session (e.g., 1560 the SIP session [RFC3261]). 1562 NOTE: The inclusion of the 'use_srtp' extension during the initial 1563 DTLS handshake ensures that a DTLS renegotiation will not be required 1564 in order to include the extension, in case DTLS-SRTP encrypted media 1565 is added to the BUNDLE group later during the multimedia session. 1567 12. RTP Header Extensions Consideration 1569 When RTP header extensions [RFC8285] are used in the context of this 1570 specification, the identifier used for a given extension MUST 1571 identify the same extension across all the bundled media 1572 descriptions. 1574 13. Update to RFC 3264 1576 This section updates RFC 3264, in order to allow extensions to define 1577 the usage of a zero port value in offers and answers for purposes 1578 other than removing or disabling media streams. The following 1579 sections are being updated: 1581 * "Unicast Streams"; see Section 5.1 of [RFC3264] 1583 * "Putting a Unicast Media Stream on Hold"; see Section 8.4 of 1584 [RFC3264]. 1586 13.1. Original Text from RFC 3264, Section 5.1, 2nd Paragraph 1588 | For recvonly and sendrecv streams, the port number and address in 1589 | the offer indicate where the offerer would like to receive the 1590 | media stream. For sendonly RTP streams, the address and port 1591 | number indirectly indicate where the offerer wants to receive RTCP 1592 | reports. Unless there is an explicit indication otherwise, 1593 | reports are sent to the port number one higher than the number 1594 | indicated. The IP address and port present in the offer indicate 1595 | nothing about the source IP address and source port of RTP and 1596 | RTCP packets that will be sent by the offerer. A port number of 1597 | zero in the offer indicates that the stream is offered but MUST 1598 | NOT be used. This has no useful semantics in an initial offer, 1599 | but is allowed for reasons of completeness, since the answer can 1600 | contain a zero port indicating a rejected stream (Section 6). 1601 | Furthermore, existing streams can be terminated by setting the 1602 | port to zero (Section 8). In general, a port number of zero 1603 | indicates that the media stream is not wanted. 1605 13.2. New Text Replacing RFC 3264, Section 5.1, 2nd Paragraph 1607 For recvonly and sendrecv streams, the port number and address in the 1608 offer indicate where the offerer would like to receive the media 1609 stream. For sendonly RTP streams, the address and port number 1610 indirectly indicate where the offerer wants to receive RTCP reports. 1611 Unless there is an explicit indication otherwise, reports are sent to 1612 the port number one higher than the number indicated. The IP address 1613 and port present in the offer indicate nothing about the source IP 1614 address and source port of the RTP and RTCP packets that will be sent 1615 by the offerer. By default, a port number of zero in the offer 1616 indicates that the stream is offered but MUST NOT be used, but an 1617 extension mechanism might specify different semantics for the usage 1618 of a zero port value. Furthermore, existing streams can be 1619 terminated by setting the port to zero (Section 8). In general, a 1620 port number of zero by default indicates that the media stream is not 1621 wanted. 1623 13.3. Original Text from RFC 3264, Section 8.4, 6th Paragraph 1625 | RFC 2543 [10] specified that placing a user on hold was 1626 | accomplished by setting the connection address to 0.0.0.0. Its 1627 | usage for putting a call on hold is no longer recommended, since 1628 | it doesn't allow for RTCP to be used with held streams, doesn't 1629 | work with IPv6, and breaks with connection oriented media. 1630 | However, it can be useful in an initial offer when the offerer 1631 | knows it wants to use a particular set of media streams and 1632 | formats, but doesn't know the addresses and ports at the time of 1633 | the offer. Of course, when used, the port number MUST NOT be 1634 | zero, which would specify that the stream has been disabled. An 1635 | agent MUST be capable of receiving SDP with a connection address 1636 | of 0.0.0.0, in which case it means that neither RTP nor RTCP 1637 | should be sent to the peer. 1639 13.4. New Text Replacing RFC 3264, Section 8.4, 6th Paragraph 1641 RFC 2543 [RFC2543] specifies that placing a user on hold was 1642 accomplished by setting the connection address to 0.0.0.0. Its usage 1643 for putting a call on hold is no longer recommended, since it doesn't 1644 allow for RTCP to be used with held streams, doesn't work with IPv6, 1645 and breaks with connection oriented media. However, it can be useful 1646 in an initial offer when the offerer knows it wants to use a 1647 particular set of media streams and formats, but doesn't know the 1648 addresses and ports at the time of the offer. Of course, when used, 1649 the port number MUST NOT be zero, if it would specify that the stream 1650 has been disabled. However, an extension mechanism might specify 1651 different semantics of the zero port number usage. An agent MUST be 1652 capable of receiving SDP with a connection address of 0.0.0.0, in 1653 which case it means that neither RTP nor RTCP is to be sent to the 1654 peer. 1656 14. Update to RFC 5888 1658 This section updates RFC 5888 [RFC5888], in order for extensions to 1659 allow an SDP 'group' attribute containing an identification-tag that 1660 identifies an "m=" section with the port set to zero. "Group Value 1661 in Answers" (Section 9.2 of [RFC5888]) is updated. 1663 14.1. Original Text from RFC 5888, Section 9.2, 3rd Paragraph 1665 | SIP entities refuse media streams by setting the port to zero in 1666 | the corresponding "m" line. "a=group" lines MUST NOT contain 1667 | identification-tags that correspond to "m" lines with the port set 1668 | to zero. 1670 14.2. New Text Replacing RFC 5888, Section 9.2, 3rd Paragraph 1672 SIP entities refuse media streams by setting the port to zero in the 1673 corresponding "m" line. "a=group" lines MUST NOT contain 1674 identification-tags that correspond to "m" lines with the port set to 1675 zero, but an extension mechanism might specify different semantics 1676 for including identification-tags that correspond to such "m=" lines. 1678 15. RTP/RTCP Extensions for identification-tag Transport 1680 Offerers and answerers [RFC3264] can associate identification-tags 1681 with "m=" sections within offers and answers, using the procedures in 1682 [RFC5888]. Each identification-tag uniquely represents an "m=" 1683 section. 1685 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1686 used to carry identification-tags within RTCP SDES packets. This 1687 section also defines a new RTP SDES header extension [RFC7941], which 1688 is used to carry the 'MID' RTCP SDES item in RTP packets. 1690 The SDES item and RTP SDES header extension make it possible for a 1691 receiver to associate each RTP stream with a specific "m=" section, 1692 with which the receiver has associated an identification-tag, even if 1693 those "m=" sections are part of the same RTP session. The RTP SDES 1694 header extension also ensures that the media recipient gets the 1695 identification-tag upon receipt of the first decodable media and is 1696 able to associate the media with the correct application. 1698 A media recipient informs the media sender about the identification- 1699 tag associated with an "m=" section through the use of a 'mid' 1700 attribute [RFC5888]. The media sender then inserts the 1701 identification-tag in RTCP and RTP packets sent to the media 1702 recipient. 1704 NOTE: The text above defines how identification-tags are carried in 1705 offers and answers. The usage of other signaling protocols for 1706 carrying identification-tags is not prevented, but the usage of such 1707 protocols is outside the scope of this document. 1709 [RFC3550] defines general procedures regarding the RTCP transmission 1710 interval. The RTCP MID SDES item SHOULD be sent in the first few 1711 RTCP packets after joining the session and SHOULD be sent regularly 1712 thereafter. The exact number of RTCP packets in which this SDES item 1713 is sent is intentionally not specified here, as it will depend on the 1714 expected packet-loss rate, the RTCP reporting interval, and the 1715 allowable overhead. 1717 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1718 be included in some RTP packets at the start of the session and 1719 whenever the SSRC changes. It might also be useful to include the 1720 header extension in RTP packets that comprise access points in the 1721 media (e.g., with video I-frames). The exact number of RTP packets 1722 in which this header extension is sent is intentionally not specified 1723 here, as it will depend on expected packet-loss rate and loss 1724 patterns, the overhead the application can tolerate, and the 1725 importance of immediate receipt of the identification-tag. 1727 For robustness, endpoints need to be prepared for situations where 1728 the reception of the identification-tag is delayed and SHOULD NOT 1729 terminate sessions in such cases, as the identification-tag is likely 1730 to arrive soon. 1732 15.1. RTCP MID SDES Item 1734 0 1 2 3 1735 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 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 | MID=15 | length | identification-tag ... 1738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP. 1742 The identification-tag is not zero terminated. 1744 15.2. RTP SDES Header Extension For MID 1746 The payload, containing the identification-tag, of the RTP SDES 1747 header extension element can be encoded using either the 1-byte or 1748 the 2-byte header [RFC7941]. The identification-tag payload is UTF-8 1749 encoded, as in SDP. 1751 The identification-tag is not zero terminated. Note that the set of 1752 header extensions included in the packet needs to be padded to the 1753 next 32-bit boundary using zero bytes [RFC8285]. 1755 As the identification-tag is included in an RTCP SDES item, an RTP 1756 SDES header extension, or both, there needs to be some consideration 1757 about the packet expansion caused by the identification-tag. To 1758 avoid Maximum Transmission Unit (MTU) issues for the RTP packets, the 1759 header extension's size needs to be taken into account when encoding 1760 the media. 1762 It is recommended that the identification-tag be kept short. Due to 1763 the properties of the RTP header extension mechanism, when using the 1764 1-byte header, a tag that is 1-3 bytes will result in a minimal 1765 number of 32-bit words used for the RTP SDES header extension, in 1766 case no other header extensions are included at the same time. Note, 1767 do take into account that some single characters when UTF-8 encoded 1768 will result in multiple octets. The identification-tag MUST NOT 1769 contain any user information, and applications SHALL avoid generating 1770 the identification-tag using a pattern that enables user or 1771 application identification. 1773 16. IANA Considerations 1775 16.1. New SDES Item 1777 This document adds the MID SDES item to the IANA "RTP SDES Item 1778 Types" registry as follows: 1780 Value: 15 1782 Abbrev.: MID 1784 Name: Media Identification 1786 Reference: RFC XXXX 1788 16.2. New RTP SDES Header Extension URI 1790 This document defines a new extension URI in the RTP SDES Compact 1791 Header Extensions sub-registry of the RTP Compact Header Extensions 1792 registry sub-registry, according to the following data: 1794 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1796 Description: Media identification 1798 Contact: IESG (iesg@ietf.org) 1800 Reference: RFC XXXX 1802 The SDES item does not reveal privacy information about the users. 1803 It is simply used to associate RTP-based media with the correct SDP 1804 media description ("m=" section) in the SDP used to negotiate the 1805 media. 1807 The purpose of the extension is for the offerer to be able to 1808 associate received multiplexed RTP-based media before the offerer 1809 receives the associated answer. 1811 16.3. New SDP Attribute 1813 This document defines a new SDP media-level attribute, 'bundle-only', 1814 according to the following data: 1816 Attribute name: bundle-only 1818 Type of attribute: media 1820 Subject to charset: No 1822 Purpose: Request a media description to be accepted in the answer 1823 only if kept within a BUNDLE group by the answerer. 1825 Appropriate values: N/A 1827 Contact name: IESG 1829 Contact e-mail: iesg@ietf.org 1831 Reference: RFC XXXX 1833 Mux category: NORMAL 1835 16.4. New SDP Group Semantics 1837 This document registers the following semantics with IANA in the 1838 "Semantics for the 'group' SDP Attribute" subregistry (under the 1839 "Session Description Protocol (SDP) Parameters" registry): 1841 +================+========+==============+===========+ 1842 | Semantics | Token | Mux Category | Reference | 1843 +================+========+==============+===========+ 1844 | Media bundling | BUNDLE | NORMAL | RFC XXXX | 1845 +----------------+--------+--------------+-----------+ 1847 Table 1 1849 17. Security Considerations 1851 The security considerations defined in [RFC3264] and [RFC5888] apply 1852 to the BUNDLE extension. BUNDLE does not change which information, 1853 e.g., RTP streams, flows over the network, with the exception of the 1854 usage of the MID SDES item as discussed below. Primarily, it changes 1855 which addresses and ports, and thus in which (RTP) sessions, the 1856 information flows to. This affects the security contexts being used 1857 and can cause previously separated information flows to share the 1858 same security context. This has very little impact on the 1859 performance of the security mechanism of the RTP sessions. In cases 1860 where one would have applied different security policies on the 1861 different RTP streams being bundled, or where the parties having 1862 access to the security contexts would have differed between the RTP 1863 streams, additional analysis of the implications are needed before 1864 selecting to apply BUNDLE. 1866 The identification-tag, independent of transport, RTCP SDES packet, 1867 or RTP header extension, can expose the value to parties beyond the 1868 signaling chain. Therefore, the identification-tag values MUST be 1869 generated in a fashion that does not leak user information, e.g., 1870 randomly or using a per-bundle group counter, and SHOULD be 3 bytes 1871 or less to allow them to efficiently fit into the MID RTP header 1872 extension. Note that if implementations use different methods for 1873 generating identification-tags, this could enable fingerprinting of 1874 the implementation making it vulnerable to targeted attacks. The 1875 identification-tag is exposed on the RTP stream level when included 1876 in the RTP header extensions; however, what it reveals of the RTP 1877 media stream structure of the endpoint and application was already 1878 possible to deduce from the RTP streams without the MID SDES header 1879 extensions. As the identification-tag is also used to route the 1880 media stream to the right application functionality, it is important 1881 that the value received is the one intended by the sender; thus, 1882 integrity and the authenticity of the source are important to prevent 1883 denial of service on the application. Existing SRTP configurations 1884 and other security mechanisms protecting the whole RTP/RTCP packets 1885 will provide the necessary protection. 1887 When the BUNDLE extension is used, the set of configurations of the 1888 security mechanism used in all the bundled media descriptions will 1889 need to be compatible so that they can be used simultaneously, at 1890 least per direction or endpoint. When using SRTP, this will be the 1891 case, at least for the IETF-defined key-management solutions due to 1892 their SDP attributes ("a=crypto", "a=fingerprint", "a=mikey") and 1893 their classification in [RFC8859]. 1895 The security considerations of "RTP Header Extension for the RTP 1896 Control Protocol (RTCP) Source Description Items" [RFC7941] require 1897 that when RTCP is confidentiality protected, any SDES RTP header 1898 extension carrying an SDES item, such as the MID RTP header 1899 extension, is also protected using commensurate strength algorithms. 1900 However, assuming the above requirements and recommendations are 1901 followed, there are no known significant security risks with leaving 1902 the MID RTP header extension without confidentiality protection. 1903 Therefore, this specification updates RFC 7941 by adding the 1904 exception that this requirement MAY be ignored for the MID RTP header 1905 extension. Security mechanisms for RTP/RTCP are discussed in 1906 "Options for Securing RTP Sessions" [RFC7201], for example, SRTP 1907 [RFC3711] can provide the necessary security functions of ensuring 1908 the integrity and source authenticity. 1910 18. Examples 1912 18.1. Example: Tagged "m=" Section Selections 1914 The example below shows: 1916 * An initial BUNDLE offer, in which the offerer wants to negotiate a 1917 BUNDLE group and indicates the audio "m=" section as the suggested 1918 offerer-tagged "m=" section. 1920 * An initial BUNDLE answer, in which the answerer accepts the 1921 creation of the BUNDLE group, selects the audio "m=" section in 1922 the offer as the offerer-tagged "m=" section, selects the audio 1923 "m=" section in the answer as the answerer-tagged "m=" section, 1924 and assigns the answerer BUNDLE address:port to that "m=" section. 1926 SDP Offer (1) 1928 v=0 1929 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1930 s= 1931 c=IN IP6 2001:db8::3 1932 t=0 0 1933 a=group:BUNDLE foo bar 1935 m=audio 10000 RTP/AVP 0 8 97 1936 b=AS:200 1937 a=mid:foo 1938 a=rtcp-mux 1939 a=rtpmap:0 PCMU/8000 1940 a=rtpmap:8 PCMA/8000 1941 a=rtpmap:97 iLBC/8000 1942 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1944 m=video 10002 RTP/AVP 31 32 1945 b=AS:1000 1946 a=mid:bar 1947 a=rtcp-mux 1948 a=rtpmap:31 H261/90000 1949 a=rtpmap:32 MPV/90000 1950 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1952 SDP Answer (2) 1954 v=0 1955 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1956 s= 1957 c=IN IP6 2001:db8::1 1958 t=0 0 1959 a=group:BUNDLE foo bar 1961 m=audio 20000 RTP/AVP 0 1962 b=AS:200 1963 a=mid:foo 1964 a=rtcp-mux 1965 a=rtpmap:0 PCMU/8000 1966 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1968 m=video 20000 RTP/AVP 32 1969 b=AS:1000 1970 a=mid:bar 1971 a=rtpmap:32 MPV/90000 1972 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1974 18.2. Example: BUNDLE Group Rejected 1976 The example below shows: 1978 * An initial BUNDLE offer, in which the offerer wants to negotiate a 1979 BUNDLE group and indicates the audio "m=" section as the suggested 1980 offerer-tagged "m=" section. 1982 * An initial BUNDLE answer, in which the answerer rejects the 1983 creation of the BUNDLE group, generates a normal answer, and 1984 assigns a unique address:port to each "m=" section in the answer. 1986 SDP Offer (1) 1988 v=0 1989 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1990 s= 1991 c=IN IP6 2001:db8::3 1992 t=0 0 1993 a=group:BUNDLE foo bar 1995 m=audio 10000 RTP/AVP 0 8 97 1996 b=AS:200 1997 a=mid:foo 1998 a=rtcp-mux 1999 a=rtpmap:0 PCMU/8000 2000 a=rtpmap:8 PCMA/8000 2001 a=rtpmap:97 iLBC/8000 2002 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2004 m=video 10002 RTP/AVP 31 32 2005 b=AS:1000 2006 a=mid:bar 2007 a=rtcp-mux 2008 a=rtpmap:31 H261/90000 2009 a=rtpmap:32 MPV/90000 2010 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2012 SDP Answer (2) 2014 v=0 2015 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2016 s= 2017 c=IN IP6 2001:db8::1 2018 t=0 0 2020 m=audio 20000 RTP/AVP 0 2021 b=AS:200 2022 a=rtcp-mux 2023 a=rtpmap:0 PCMU/8000 2025 m=video 30000 RTP/AVP 32 2026 b=AS:1000 2027 a=rtcp-mux 2028 a=rtpmap:32 MPV/90000 2030 18.3. Example: Offerer Adds a Media Description to a BUNDLE Group 2032 The example below shows: 2034 * A subsequent offer, in which the offerer adds a new bundled "m=" 2035 section (video), indicated by the "zen" identification-tag, to a 2036 previously negotiated BUNDLE group; indicates the new "m=" section 2037 as the offerer-tagged "m=" section; and assigns the offerer BUNDLE 2038 address:port to that "m=" section. 2040 * A subsequent answer, in which the answerer indicates the new video 2041 "m=" section in the answer as the answerer-tagged "m=" section and 2042 assigns the answerer BUNDLE address:port to that "m=" section. 2044 SDP Offer (1) 2046 v=0 2047 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2048 s= 2049 c=IN IP6 2001:db8::3 2050 t=0 0 2051 a=group:BUNDLE zen foo bar 2053 m=audio 10000 RTP/AVP 0 8 97 2054 b=AS:200 2055 a=mid:foo 2056 a=rtpmap:0 PCMU/8000 2057 a=rtpmap:8 PCMA/8000 2058 a=rtpmap:97 iLBC/8000 2059 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2061 m=video 10000 RTP/AVP 31 32 2062 b=AS:1000 2063 a=mid:bar 2064 a=rtpmap:31 H261/90000 2065 a=rtpmap:32 MPV/90000 2066 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2068 m=video 10000 RTP/AVP 66 2069 b=AS:1000 2070 a=mid:zen 2071 a=rtcp-mux 2072 a=rtpmap:66 H261/90000 2073 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2075 SDP Answer (2) 2077 v=0 2078 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2079 s= 2080 c=IN IP6 2001:db8::1 2081 t=0 0 2082 a=group:BUNDLE zen foo bar 2084 m=audio 20000 RTP/AVP 0 2085 b=AS:200 2086 a=mid:foo 2087 a=rtpmap:0 PCMU/8000 2088 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2090 m=video 20000 RTP/AVP 32 2091 b=AS:1000 2092 a=mid:bar 2093 a=rtpmap:32 MPV/90000 2094 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2096 m=video 20000 RTP/AVP 66 2097 b=AS:1000 2098 a=mid:zen 2099 a=rtcp-mux 2100 a=rtpmap:66 H261/90000 2101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2103 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 2105 The example below shows: 2107 * A subsequent offer, in which the offerer removes an "m=" section 2108 (video), indicated by the "zen" identification-tag, from a 2109 previously negotiated BUNDLE group; indicates one of the bundled 2110 "m=" sections (audio) remaining in the BUNDLE group as the 2111 offerer-tagged "m=" section; and assigns the offerer BUNDLE 2112 address:port to that "m=" section. 2114 * A subsequent answer, in which the answerer removes the "m=" 2115 section from the BUNDLE group, indicates the audio "m=" section in 2116 the answer as the answerer-tagged "m=" section, and assigns the 2117 answerer BUNDLE address:port to that "m=" section. 2119 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) 2152 v=0 2153 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2154 s= 2155 c=IN IP6 2001:db8::1 2156 t=0 0 2157 a=group:BUNDLE foo bar 2159 m=audio 20000 RTP/AVP 0 2160 b=AS:200 2161 a=mid:foo 2162 a=rtcp-mux 2163 a=rtpmap:0 PCMU/8000 2164 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2166 m=video 20000 RTP/AVP 32 2167 b=AS:1000 2168 a=mid:bar 2169 a=rtpmap:32 MPV/90000 2170 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2172 m=video 60000 RTP/AVP 66 2173 b=AS:1000 2174 a=mid:zen 2175 a=rtcp-mux 2176 a=rtpmap:66 H261/90000 2178 18.5. Example: Offerer Disables a Media Description within a BUNDLE 2179 Group 2181 The example below shows: 2183 * A subsequent offer, in which the offerer disables (by assigning a 2184 zero port value) an "m=" section (video), indicated by the "zen" 2185 identification-tag, from a previously negotiated BUNDLE group; 2186 indicates one of the bundled "m=" sections (audio) remaining 2187 active in the BUNDLE group as the offerer-tagged "m=" section; and 2188 assigns the offerer BUNDLE address:port to that "m=" section. 2190 * A subsequent answer, in which the answerer disables the "m=" 2191 section, indicates the audio "m=" section in the answer as the 2192 answerer-tagged "m=" section, and assigns the answerer BUNDLE 2193 address:port to that "m=" section. 2195 SDP Offer (1) 2197 v=0 2198 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2199 s= 2200 t=0 0 2201 a=group:BUNDLE foo bar 2203 m=audio 10000 RTP/AVP 0 8 97 2204 c=IN IP6 2001:db8::3 2205 b=AS:200 2206 a=mid:foo 2207 a=rtcp-mux 2208 a=rtpmap:0 PCMU/8000 2209 a=rtpmap:8 PCMA/8000 2210 a=rtpmap:97 iLBC/8000 2211 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2213 m=video 10000 RTP/AVP 31 32 2214 c=IN IP6 2001:db8::3 2215 b=AS:1000 2216 a=mid:bar 2217 a=rtpmap:31 H261/90000 2218 a=rtpmap:32 MPV/90000 2219 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2221 m=video 0 RTP/AVP 66 2222 a=mid:zen 2223 a=rtpmap:66 H261/90000 2225 SDP Answer (2) 2227 v=0 2228 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2229 s= 2230 t=0 0 2231 a=group:BUNDLE foo bar 2233 m=audio 20000 RTP/AVP 0 2234 c=IN IP6 2001:db8::1 2235 b=AS:200 2236 a=mid:foo 2237 a=rtcp-mux 2238 a=rtpmap:0 PCMU/8000 2239 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2241 m=video 20000 RTP/AVP 32 2242 c=IN IP6 2001:db8::1 2243 b=AS:1000 2244 a=mid:bar 2245 a=rtpmap:32 MPV/90000 2246 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2248 m=video 0 RTP/AVP 66 2249 a=mid:zen 2250 a=rtpmap:66 H261/90000 2252 19. References 2254 19.1. Normative References 2256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2257 Requirement Levels", BCP 14, RFC 2119, 2258 DOI 10.17487/RFC2119, March 1997, 2259 . 2261 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2262 with Session Description Protocol (SDP)", RFC 3264, 2263 DOI 10.17487/RFC3264, June 2002, 2264 . 2266 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2267 Jacobson, "RTP: A Transport Protocol for Real-Time 2268 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2269 July 2003, . 2271 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2272 in Session Description Protocol (SDP)", RFC 3605, 2273 DOI 10.17487/RFC3605, October 2003, 2274 . 2276 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2277 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2278 2003, . 2280 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2281 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2282 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2283 . 2285 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2286 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2287 July 2006, . 2289 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2290 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2291 . 2293 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2294 Control Packets on a Single Port", RFC 5761, 2295 DOI 10.17487/RFC5761, April 2010, 2296 . 2298 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2299 Security (DTLS) Extension to Establish Keys for the Secure 2300 Real-time Transport Protocol (SRTP)", RFC 5764, 2301 DOI 10.17487/RFC5764, May 2010, 2302 . 2304 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2305 Protocol (SDP) Grouping Framework", RFC 5888, 2306 DOI 10.17487/RFC5888, June 2010, 2307 . 2309 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2310 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2311 January 2012, . 2313 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2314 Header Extension for the RTP Control Protocol (RTCP) 2315 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2316 August 2016, . 2318 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2319 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2320 May 2017, . 2322 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 2323 Mechanism for RTP Header Extensions", RFC 8285, 2324 DOI 10.17487/RFC8285, October 2017, 2325 . 2327 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2328 Connectivity Establishment (ICE): A Protocol for Network 2329 Address Translator (NAT) Traversal", RFC 8445, 2330 DOI 10.17487/RFC8445, July 2018, 2331 . 2333 [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, 2334 A., and R. Shpount, "Session Description Protocol (SDP) 2335 Offer/Answer Procedures for Interactive Connectivity 2336 Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, 2337 January 2021, . 2339 [RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 2340 Session Initiation Protocol (SIP) Usage for Incremental 2341 Provisioning of Candidates for the Interactive 2342 Connectivity Establishment (Trickle ICE)", RFC 8840, 2343 DOI 10.17487/RFC8840, January 2021, 2344 . 2346 [RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP 2347 Control Protocol (RTCP) Multiplexing Using the Session 2348 Description Protocol (SDP)", RFC 8858, 2349 DOI 10.17487/RFC8858, January 2021, 2350 . 2352 [RFC8859] Nandakumar, S., "A Framework for Session Description 2353 Protocol (SDP) Attributes When Multiplexing", RFC 8859, 2354 DOI 10.17487/RFC8859, January 2021, 2355 . 2357 19.2. Informative References 2359 [LLR-RTCP] Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 2360 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 2361 Message", Work in Progress, Internet-Draft, draft-ietf- 2362 avtext-lrr-07, 2 July 2017, 2363 . 2365 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 2366 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 2367 DOI 10.17487/RFC2543, March 1999, 2368 . 2370 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2371 A., Peterson, J., Sparks, R., Handley, M., and E. 2372 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2373 DOI 10.17487/RFC3261, June 2002, 2374 . 2376 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2377 "RTP Control Protocol Extended Reports (RTCP XR)", 2378 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2379 . 2381 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2382 "Extended RTP Profile for Real-time Transport Control 2383 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2384 DOI 10.17487/RFC4585, July 2006, 2385 . 2387 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2388 "Codec Control Messages in the RTP Audio-Visual Profile 2389 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 2390 February 2008, . 2392 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2393 Media Attributes in the Session Description Protocol 2394 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2395 . 2397 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2398 Clock Rates in an RTP Session", RFC 7160, 2399 DOI 10.17487/RFC7160, April 2014, 2400 . 2402 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2403 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2404 . 2406 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2407 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2408 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2409 DOI 10.17487/RFC7656, November 2015, 2410 . 2412 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 2413 (Diffserv) and Real-Time Communication", RFC 7657, 2414 DOI 10.17487/RFC7657, November 2015, 2415 . 2417 [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., 2418 "JavaScript Session Establishment Protocol (JSEP)", 2419 RFC 8829, DOI 10.17487/RFC8829, January 2021, 2420 . 2422 [RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: 2423 Incremental Provisioning of Candidates for the Interactive 2424 Connectivity Establishment (ICE) Protocol", RFC 8838, 2425 DOI 10.17487/RFC8838, January 2021, 2426 . 2428 Appendix A. Design Considerations 2430 One of the main issues regarding the BUNDLE grouping extensions has 2431 been whether, in offers and answers, the same port value can be 2432 inserted in "m=" lines associated with a BUNDLE group, as the purpose 2433 of the extension is to negotiate the usage of a single transport for 2434 media specified by the "m=" sections. Issues with both approaches, 2435 discussed in the Appendix, have been raised. The outcome was to 2436 specify a mechanism that uses offers with both different and 2437 identical port values. 2439 Below are the primary issues that have been considered when defining 2440 the "BUNDLE" grouping extension: 2442 1) Interoperability with existing User Agents (UAs). 2444 2) Interoperability with intermediary Back-to-Back User Agent 2445 (B2BUA) and proxy entities. 2447 3) Time to gather, and the number of, ICE candidates. 2449 4) Different error scenarios and when they occur. 2451 5) SDP offer/answer impacts, including usage of port number value 2452 zero. 2454 A.1. UA Interoperability 2456 Consider the following SDP offer/answer exchange, where Alice sends 2457 an offer to Bob: 2459 SDP Offer 2461 v=0 2462 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2463 s= 2464 c=IN IP4 atlanta.example.com 2465 t=0 0 2467 m=audio 10000 RTP/AVP 97 2468 a=rtpmap:97 iLBC/8000 2469 m=video 10002 RTP/AVP 97 2470 a=rtpmap:97 H261/90000 2472 SDP Answer 2474 v=0 2475 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2476 s= 2477 c=IN IP4 biloxi.example.com 2478 t=0 0 2480 m=audio 20000 RTP/AVP 97 2481 a=rtpmap:97 iLBC/8000 2482 m=video 20002 RTP/AVP 97 2483 a=rtpmap:97 H261/90000 2485 RFC 4961 specifies a way of doing symmetric RTP, but that is a later 2486 extension to RTP, and Bob cannot assume that Alice supports RFC 4961. 2487 This means that Alice may be sending RTP from a different port than 2488 10000 or 10002 -- some implementations simply send the RTP from an 2489 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2490 way that Bob knows if the packet is to be passed to the video or 2491 audio codec is by looking at the port it was received on. This 2492 prompted some SDP implementations to use a port number as an index to 2493 find the correct "m=" line in the SDP, since each "m"= section 2494 contains a different port number. As a result, some implementations 2495 that do support symmetric RTP and ICE still use an SDP data structure 2496 where SDP with "m=" sections with the same port such as: 2498 SDP Offer 2500 v=0 2501 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2502 s= 2503 c=IN IP4 atlanta.example.com 2504 t=0 0 2506 m=audio 10000 RTP/AVP 97 2507 a=rtpmap:97 iLBC/8000 2508 m=video 10000 RTP/AVP 98 2509 a=rtpmap:98 H261/90000 2511 will result in the second "m=" section being considered an SDP error 2512 because it has the same port as the first line. 2514 A.2. Usage of Port Number Value Zero 2516 In an offer or answer, the media specified by an "m=" section can be 2517 disabled/rejected by setting the port number value to zero. This is 2518 different from, e.g., using the SDP direction attributes, where RTCP 2519 traffic will continue even if the SDP 'inactive' attribute is 2520 indicated for the associated "m=" section. 2522 If each "m=" section associated with a BUNDLE group would contain 2523 different port values, and one of those port values would be used for 2524 a BUNDLE address:port associated with the BUNDLE group, problems 2525 would occur if an endpoint wants to disable/reject the "m=" section 2526 associated with that port, by setting the port value to zero. After 2527 that, no "m=" section would contain the port value that is used for 2528 the BUNDLE address:port. In addition, it is unclear what would 2529 happen to the ICE candidates associated with the "m=" section, as 2530 they are also used for the BUNDLE address:port. 2532 A.3. B2BUA and Proxy Interoperability 2534 Some back-to-back user agents may be configured in a mode where if 2535 the incoming call leg contains an SDP attribute the B2BUA does not 2536 understand, the B2BUA still generates that SDP attribute in the Offer 2537 for the outgoing call leg. Consider a B2BUA that did not understand 2538 the SDP 'rtcp' attribute, defined in RFC 3605, yet acted this way. 2539 Further assume that the B2BUA was configured to tear down any call 2540 where it did not see any RTCP for 5 minutes. In this case, if the 2541 B2BUA received an Offer like: 2543 SDP Offer 2545 v=0 2546 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2547 s= 2548 c=IN IP4 atlanta.example.com 2549 t=0 0 2551 m=audio 49170 RTP/AVP 0 2552 a=rtcp:53020 2554 It would be looking for RTCP on port 49171 but would not see any 2555 because the RTCP would be on port 53020, and after five minutes, it 2556 would tear down the call. Similarly, a B2BUA that did not understand 2557 BUNDLE yet put it in its offer may be looking for media on the wrong 2558 port and tear down the call. It is worth noting that a B2BUA that 2559 generated an Offer with capabilities it does not understand is not 2560 compliant with the specifications. 2562 A.3.1. Traffic Policing 2564 Sometimes intermediaries do not act as B2BUAs, in the sense that they 2565 don't modify SDP bodies nor do they terminate SIP dialogs. However, 2566 they may still use SDP information (e.g., IP address and port) in 2567 order to control traffic gating functions and to set traffic policing 2568 rules. There might be rules that will trigger a session to be 2569 terminated in case media is not sent or received on the ports 2570 retrieved from the SDP. This typically occurs once the session is 2571 already established and ongoing. 2573 A.3.2. Bandwidth Allocation 2575 Sometimes, intermediaries do not act as B2BUAs, in the sense that 2576 they don't modify SDP bodies nor do they terminate SIP dialogs. 2577 However, they may still use SDP information (e.g., codecs and media 2578 types) in order to control bandwidth allocation functions. The 2579 bandwidth allocation is done per "m=" section, which means that it 2580 might not be enough if media specified by all "m=" sections try to 2581 use that bandwidth. That may simply lead to either bad user 2582 experience or termination of the call. 2584 A.4. Candidate Gathering 2586 When using ICE, a candidate needs to be gathered for each port. This 2587 takes approximately 20 ms extra for each extra "m=" section due to 2588 the NAT pacing requirements. All of this gathering can be overlapped 2589 with other things while, e.g., a web page is loading to minimize the 2590 impact. If the client only wants to generate Traversal Using Relays 2591 around NAT (TURN) or STUN ICE candidates for one of the "m=" lines 2592 and then use Trickle ICE [RFC8838] to get the non-host ICE candidates 2593 for the rest of the "m=" sections, it MAY do that and will not need 2594 any additional gathering time. 2596 Some people have suggested a TURN extension to get a bunch of TURN 2597 allocations at once. This would only provide a single STUN result, 2598 so in cases where the other end did not support BUNDLE, it may cause 2599 more use of the TURN server, but it would be quick in the cases where 2600 both sides supported BUNDLE and would fall back to a successful call 2601 in the other cases. 2603 Acknowledgements 2605 The usage of the SDP grouping extension for negotiating bundled media 2606 is based on similar alternatives proposed by Harald Alvestrand and 2607 Cullen Jennings. The BUNDLE extension described in this document is 2608 based on the different alternative proposals, and text (e.g., SDP 2609 examples) has been borrowed (and, in some cases, modified) from those 2610 alternative proposals. 2612 The SDP examples are also modified versions from the ones in the 2613 Alvestrand proposal. 2615 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 2616 Stach, Ari Keränen, Adam Roach, Christian Groves, Roman Shpount, 2617 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin 2618 Uberti, Taylor Brandstetter, Byron Campen, and Eric Rescorla for 2619 reading the text and providing useful feedback. 2621 Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus 2622 Westerlund for providing the text for the section on RTP/RTCP stream 2623 association. 2625 Thanks to Magnus Westerlund, Colin Perkins, and Jonathan Lennox for 2626 providing help and text on the RTP/RTCP procedures. 2628 Thanks to Charlie Kaufman for performing the Sec-Dir review. 2630 Thanks to Linda Dunbar for performing the Gen-ART review. 2632 Thanks to Spotify for providing music for the countless hours of 2633 document editing. 2635 Authors' Addresses 2637 Christer Holmberg 2638 Ericsson 2639 Hirsalantie 11 2640 FI-02420 Jorvas 2641 Finland 2643 Email: christer.holmberg@ericsson.com 2645 Harald Tveit Alvestrand 2646 Google 2647 Kungsbron 2 2648 SE-11122 Stockholm 2649 Sweden 2651 Email: harald@alvestrand.no 2653 Cullen Jennings 2654 Cisco 2655 400 3rd Avenue SW, Suite 350 2656 Calgary AB T2P 4H2 2657 Canada 2659 Email: fluffy@iii.ca