idnits 2.17.00 (12 Aug 2021) /tmp/idnits12202/draft-ietf-mmusic-sdp-bundle-negotiation-54.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (December 15, 2018) is 1246 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 1635 == Missing Reference: 'RFCXXXX' is mentioned on line 1841, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: draft-ietf-ice-rfc5245bis has been published as RFC 8445 == Outdated reference: draft-ietf-mmusic-sdp-mux-attributes has been published as RFC 8859 == Outdated reference: draft-ietf-mmusic-mux-exclusive has been published as RFC 8858 == Outdated reference: draft-ietf-mmusic-ice-sip-sdp has been published as RFC 8839 == Outdated reference: draft-ietf-mmusic-trickle-ice-sip has been published as RFC 8840 == Outdated reference: draft-ietf-ice-trickle has been published as RFC 8838 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 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 Updates: 3264,5888,7941 (if approved) H. Alvestrand 5 Intended status: Standards Track Google 6 Expires: June 18, 2019 C. Jennings 7 Cisco 8 December 15, 2018 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-54.txt 14 Abstract 16 This specification defines a new Session Description Protocol (SDP) 17 Grouping Framework extension, 'BUNDLE'. The extension can be used 18 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 updates RFC 3264, to also allow assigning a zero 26 port value to a "m=" section in cases where the media described by 27 the "m=" section is not disabled or rejected. 29 This specification updates RFC 5888, to also allow an SDP 'group' 30 attribute to contain an identification-tag that identifies a "m=" 31 section with the port set to zero. 33 This specification defines a new RTP Control Protocol (RTCP) source 34 description (SDES) item and a new RTP header extension that can be 35 used to correlate bundled RTP/RTCP packets with their appropriate 36 "m=" section. 38 This specification updates RFC 7941, by adding an exception, for the 39 MID RTP header extension, to the requirement regarding protection of 40 an SDES RTP header extension carrying an SDES item for the MID RTP 41 header extension. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on June 18, 2019. 60 Copyright Notice 62 Copyright (c) 2018 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 This document may contain material from IETF Documents or IETF 76 Contributions published or made publicly available before November 77 10, 2008. The person(s) controlling the copyright in some of this 78 material may not have granted the IETF Trust the right to allow 79 modifications of such material outside the IETF Standards Process. 80 Without obtaining an adequate license from the person(s) controlling 81 the copyright in such materials, this document may not be modified 82 outside the IETF Standards Process, and derivative works of it may 83 not be created outside the IETF Standards Process, except to format 84 it for publication as an RFC or to translate it into languages other 85 than English. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 90 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 91 1.2. BUNDLE Mechanism . . . . . . . . . . . . . . . . . . . . 4 92 1.3. Protocol Extensions . . . . . . . . . . . . . . . . . . . 5 93 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 94 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 95 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 96 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 8 97 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 9 98 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 99 7.1. Generic SDP Considerations . . . . . . . . . . . . . . . 10 100 7.1.1. Connection Data (c=) . . . . . . . . . . . . . . . . 10 101 7.1.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . 11 102 7.1.3. Attributes (a=) . . . . . . . . . . . . . . . . . . . 11 103 7.2. Generating the Initial SDP Offer . . . . . . . . . . . . 12 104 7.2.1. Suggesting the Offerer tagged 'm=' section . . . . . 13 105 7.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 13 106 7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 14 107 7.3.1. Answerer Selection of tagged 'm=' sections . . . . . 16 108 7.3.2. Moving A Media Description Out Of A BUNDLE Group . . 16 109 7.3.3. Rejecting a Media Description in a BUNDLE Group . . . 17 110 7.3.4. Example: SDP Answer . . . . . . . . . . . . . . . . . 18 111 7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 19 112 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 19 113 7.5.1. Adding a Media Description to a BUNDLE group . . . . 20 114 7.5.2. Moving a Media Description Out of a BUNDLE Group . . 21 115 7.5.3. Disabling a Media Description in a BUNDLE Group . . . 21 116 8. Protocol Identification . . . . . . . . . . . . . . . . . . . 22 117 8.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 22 118 9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 23 119 9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 23 120 9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 24 121 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 122 Description . . . . . . . . . . . . . . . . . . . . . . . 24 123 9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 30 124 9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 30 125 10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 32 126 11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 33 127 12. RTP Header Extensions Consideration . . . . . . . . . . . . . 34 128 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 34 129 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 34 130 13.2. New text replacing section 5.1 (2nd paragraph) of RFC 131 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 132 13.3. Original text of section 8.4 (6th paragraph) of RFC 3264 35 133 13.4. New text replacing section 8.4 (6th paragraph) of RFC 134 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 135 14. Update to RFC 5888 . . . . . . . . . . . . . . . . . . . . . 36 136 14.1. Original text of section 9.2 (3rd paragraph) of RFC 5888 36 137 14.2. New text replacing section 9.2 (3rd paragraph) of RFC 138 5888 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 139 15. RTP/RTCP extensions for identification-tag transport . . . . 36 140 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 37 141 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 38 142 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 143 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 38 144 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 39 145 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 39 146 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 40 147 17. Security Considerations . . . . . . . . . . . . . . . . . . . 40 148 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41 149 18.1. Example: Tagged m= Section Selections . . . . . . . . . 41 150 18.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 43 151 18.3. Example: Offerer Adds a Media Description to a BUNDLE 152 Group . . . . . . . . . . . . . . . . . . . . . . . . . 45 153 18.4. Example: Offerer Moves a Media Description Out of a 154 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46 155 18.5. Example: Offerer Disables a Media Description Within a 156 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 48 157 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 158 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 50 159 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 61 160 21.1. Normative References . . . . . . . . . . . . . . . . . . 61 161 21.2. Informative References . . . . . . . . . . . . . . . . . 64 162 Appendix A. Design Considerations . . . . . . . . . . . . . . . 65 163 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 65 164 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 67 165 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 67 166 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 68 167 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 68 168 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 68 169 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 171 1. Introduction 173 1.1. Background 175 When the SDP offer/answer mechanism [RFC3264] is used to negotiate 176 the establishment of multimedia communication sessions, if separate 177 transports (5-tuples) are negotiated for each individual media 178 stream, each transport consumes additional resources (especially when 179 Interactive Connectivity Establishment (ICE) 180 [I-D.ietf-ice-rfc5245bis] is used). For this reason, it is 181 attractive to use a single transport for multiple media streams. 183 1.2. BUNDLE Mechanism 185 This specification defines a way to use a single transport (BUNDLE 186 transport) for sending and receiving media (bundled media) described 187 by multiple SDP media descriptions ("m=" sections). The address:port 188 combination used by an endpoint for sending and receiving bundled 189 media is referred to as the BUNDLE address:port. The set of SDP 190 attributes that are applied to each "m=" section within a BUNDLE 191 group is referred to as BUNDLE attributes. The same BUNDLE transport 192 is used for sending and receiving bundled media, which means that the 193 symmetric Real-time Transport Protocol (RTP) mechanism [RFC4961] is 194 always used for RTP-based bundled media. 196 This specification defines a new SDP Grouping Framework [RFC5888] 197 extension called 'BUNDLE'. The extension can be used with the 198 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 199 to negotiate which "m=" sections will become part of a BUNDLE group. 200 In addition, the offerer and answerer [RFC3264] use the BUNDLE 201 extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE 202 address:port and answerer BUNDLE address:port) and the set of BUNDLE 203 attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) 204 that will be applied to each "m=" section within the BUNDLE group. 206 The use of a BUNDLE transport allows the usage of a single set of 207 Interactive Connectivity Establishment (ICE) 208 [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group. 210 A given BUNDLE address:port MUST only be associated with a single 211 BUNDLE group. If an SDP offer or answer contains multiple BUNDLE 212 groups, the procedures in this specification apply to each group 213 independently. All RTP-based bundled media associated with a given 214 BUNDLE group belong to a single RTP session [RFC3550]. 216 The BUNDLE extension is backward compatible. Endpoints that do not 217 support the extension are expected to generate offers and answers 218 without an SDP 'group:BUNDLE' attribute, and are expected to assign a 219 unique address:port to each "m=" section within an offer and answer, 220 according to the procedures in [RFC4566] and [RFC3264]. 222 1.3. Protocol Extensions 224 In addition to defining the new SDP Grouping Framework extension, 225 this specification defines the following protocol extensions and RFC 226 updates: 228 o The specification defines a new SDP attribute, 'bundle-only', 229 which can be used to request that a specific "m=" section (and the 230 associated media) is used only used if kept within a BUNDLE group. 232 o The specification updates RFC 3264 [RFC3264], to also allow 233 assigning a zero port value to a "m=" section in cases where the 234 media described by the "m=" section is not disabled or rejected. 236 o The specification defines a new RTP Control Protocol (RTCP) 237 [RFC3550] source description (SDES) item, 'MID', and a new RTP 238 SDES header extension that can be used to associate RTP streams 239 with "m=" sections. 241 o The specification updates [RFC7941], by adding an exception, for 242 the MID RTP header extension, to the requirement regarding 243 protection of an SDES RTP header extension carrying an SDES item 244 for the MID RTP header extension. 246 2. Terminology 248 o "m=" section: SDP bodies contain one or more media descriptions, 249 referred to as "m=" sections. Each "m=" section is represented by 250 an SDP "m=" line, and zero or more SDP attributes associated with 251 the "m=" line. A local address:port combination is assigned to 252 each "m=" section. 254 o 5-tuple: A collection of the following values: source address, 255 source port, destination address, destination port, and transport- 256 layer protocol. 258 o Unique address:port: An address:port combination that is assigned 259 to only one "m=" section in an offer or answer. 261 o Offerer BUNDLE-tag: The first identification-tag in a given SDP 262 'group:BUNDLE' attribute identification-tag list in an offer. 264 o Answerer BUNDLE-tag: The first identification-tag in a given SDP 265 'group:BUNDLE' attribute identification-tag list in an answer. 267 o Suggested offerer tagged "m=" section: The bundled "m=" section 268 identified by the offerer BUNDLE-tag in an initial BUNDLE offer, 269 before a BUNDLE group has been negotiated. 271 o Offerer tagged "m=" section: The bundled "m=" section identified 272 by the offerer BUNDLE-tag in a subsequent offer. The "m=" section 273 contains characteristics (offerer BUNDLE address:port and offerer 274 BUNDLE attributes) applied to each "m=" section within the BUNDLE 275 group. 277 o Answerer tagged "m=" section: The bundled "m=" section identified 278 by the answerer BUNDLE-tag in an answer (initial BUNDLE answer or 279 subsequent). The "m=" section contains characteristics (answerer 280 BUNDLE address:port and answerer BUNDLE attributes) applied to 281 each "m=" section within the BUNDLE group. 283 o BUNDLE address:port: An address:port combination that an endpoint 284 uses for sending and receiving bundled media. 286 o Offerer BUNDLE address:port: the address:port combination used by 287 the offerer for sending and receiving media. 289 o Answerer BUNDLE address:port: the address:port combination used by 290 the answerer for sending and receiving media. 292 o BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category 293 SDP attributes. Once a BUNDLE group has been created, the 294 attribute values apply to each bundled "m=" section within the 295 BUNDLE group. 297 o Offerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing 298 category SDP attributes included in the offerer tagged "m=" 299 section. 301 o Answerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing 302 category SDP attributes included in the answerer tagged "m=" 303 section. 305 o BUNDLE transport: The transport (5-tuple) used by all media 306 described by the "m=" sections within a BUNDLE group. 308 o BUNDLE group: A set of bundled "m=" sections, created using an SDP 309 Offer/Answer exchange, which uses a single BUNDLE transport, and a 310 single set of BUNDLE attributes, for sending and receiving all 311 media (bundled media) described by the set of "m=" sections. The 312 same BUNDLE transport is used for sending and receiving bundled 313 media. 315 o Bundled "m=" section: An "m=" section, whose identification-tag is 316 placed in an SDP 'group:BUNDLE' attribute identification-tag list 317 in an offer or answer. 319 o Bundle-only "m=" section: A bundled "m=" section that contains an 320 SDP 'bundle-only' attribute. 322 o Bundled media: All media associated with a given BUNDLE group. 324 o Initial BUNDLE offer: The first offer, within an SDP session (e.g. 325 a SIP dialog when the Session Initiation Protocol (SIP) [RFC3261] 326 is used to carry SDP), in which the offerer indicates that it 327 wants to negotiate a given BUNDLE group. 329 o Initial BUNDLE answer: The answer to an initial BUNDLE offer in 330 which the offerer indicates that it wants to negotiate a BUNDLE 331 group, and where the answerer accepts the creation of the BUNDLE 332 group. The BUNDLE group is created once the answerer sends the 333 initial BUNDLE answer. 335 o Subsequent offer: An offer which contains a BUNDLE group that has 336 been created as part of a previous offer/answer exchange. 338 o Subsequent answer: An answer to a subsequent offer. 340 o Identification-tag: A unique token value that is used to identify 341 an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" 342 section carries the unique identification-tag assigned to that 343 "m=" section. The session-level SDP 'group' attribute [RFC5888] 344 carries a list of identification-tags, identifying the "m=" 345 sections associated with that particular 'group' attribute. 347 3. Conventions 349 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 350 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 351 "OPTIONAL" in this document are to be interpreted as described in BCP 352 14 [RFC2119] [RFC8174] when, and only when, they appear in all 353 capitals, as shown here. 355 4. Applicability Statement 357 The mechanism in this specification only applies to the Session 358 Description Protocol (SDP) [RFC4566], when used together with the SDP 359 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 360 scope of this document, and is thus undefined. 362 5. SDP Grouping Framework BUNDLE Extension 364 This section defines a new SDP Grouping Framework [RFC5888] 365 extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP 366 Offer/Answer mechanism to negotiate a set of "m=" sections that will 367 become part of a BUNDLE group. Within a BUNDLE group, each "m=" 368 section uses a BUNDLE transport for sending and receiving bundled 369 media. Each endpoint uses a single address:port combination for 370 sending and receiving the bundled media. 372 The BUNDLE extension is indicated using an SDP 'group' attribute with 373 a semantics value [RFC5888] of "BUNDLE". An identification-tag is 374 assigned to each bundled "m=" section, and each identification-tag is 375 listed in the SDP 'group:BUNDLE' attribute identification-tag list. 376 Each "m=" section whose identification-tag is listed in the 377 identification-tag list is associated with a given BUNDLE group. 379 SDP bodies can contain multiple BUNDLE groups. Any given bundled 380 "m=" section MUST NOT be associated with more than one BUNDLE group 381 at any given time. 383 NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' 384 attribute identification-tag list does not have to be the same as the 385 order in which the "m=" sections occur in the SDP. 387 The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] for 388 the 'group:BUNDLE' attribute is 'NORMAL'. 390 Section 7 defines the detailed SDP Offer/Answer procedures for the 391 BUNDLE extension. 393 6. SDP 'bundle-only' Attribute 395 This section defines a new SDP media-level attribute [RFC4566], 396 'bundle-only'. 'bundle-only' is a property attribute [RFC4566], and 397 hence has no value. 399 In order to ensure that an answerer that does not support the BUNDLE 400 extension always rejects a bundled "m=" section in an offer, the 401 offerer can assign a zero port value to the "m=" section. According 402 to [RFC3264] an answerer will reject such an "m=" section. By 403 including an SDP 'bundle-only' attribute in a bundled "m=" section, 404 the offerer can request that the answerer accepts the "m=" section 405 only if the answerer supports the BUNDLE extension, and if the 406 answerer keeps the "m=" section within the associated BUNDLE group. 408 Name: bundle-only 410 Value: N/A 412 Usage Level: media 414 Charset Dependent: no 416 Example: 418 a=bundle-only 420 Once the offerer tagged "m=" section and the answerer tagged "m=" 421 section have been selected, an offerer and answerer will include an 422 SDP 'bundle-only' attribute in, and assign a zero port value to, 423 every other bundled "m=" section. 425 The usage of the 'bundle-only' attribute is only defined for a 426 bundled "m=" section with a zero port value. Other usage is 427 unspecified. 429 Section 7 defines the detailed SDP Offer/Answer procedures for the 430 'bundle-only' attribute. 432 7. SDP Offer/Answer Procedures 434 This section describes the SDP Offer/Answer [RFC3264] procedures for: 436 o Negotiating a BUNDLE group; and 438 o Suggesting and selecting the tagged "m=" sections (offerer tagged 439 "m=" section and answerer tagged "m=" section); and 441 o Adding an "m=" section to a BUNDLE group; and 443 o Moving an "m=" section out of a BUNDLE group; and 445 o Disabling an "m=" section within a BUNDLE group. 447 The generic rules and procedures defined in [RFC3264] and [RFC5888] 448 also apply to the BUNDLE extension. For example, if an offer is 449 rejected by the answerer, the previously negotiated addresses:ports, 450 SDP parameters and characteristics (including those associated with a 451 BUNDLE group) apply. Hence, if an offerer generates an offer in 452 order to negotiate a BUNDLE group, and the answerer rejects the 453 offer, the BUNDLE group is not created. 455 The procedures in this section are independent of the media type or 456 "m=" line proto value assigned to a bundled "m=" section. Section 9 457 defines additional considerations for RTP based media. Section 6 458 defines additional considerations for the usage of the SDP 'bundle- 459 only' attribute. Section 10 defines additional considerations for 460 the usage of Interactive Connectivity Establishment (ICE) 461 [I-D.ietf-ice-rfc5245bis] mechanism. 463 Offers and answers can contain multiple BUNDLE groups. The 464 procedures in this section apply independently to a given BUNDLE 465 group. 467 7.1. Generic SDP Considerations 469 This section describes generic restrictions associated with the usage 470 of SDP parameters within a BUNDLE group. It also describes how to 471 calculate a value for the whole BUNDLE group, when parameter and 472 attribute values have been assigned to each bundled "m=" section. 474 7.1.1. Connection Data (c=) 476 The "c=" line nettype value [RFC4566] associated with a bundled "m=" 477 section MUST be 'IN'. 479 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" 480 section MUST be 'IP4' or 'IP6'. The same value MUST be associated 481 with each "m=" section. 483 NOTE: Extensions to this specification can specify usage of the 484 BUNDLE mechanism for other nettype and addrtype values than the ones 485 listed above. 487 7.1.2. Bandwidth (b=) 489 An offerer and answerer MUST use the rules and restrictions defined 490 in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP 491 bandwidth (b=) line with bundled "m=" sections. 493 7.1.3. Attributes (a=) 495 An offerer and answerer MUST include SDP attributes in every bundled 496 "m=" section where applicable, following the normal offer/answer 497 procedures for each attribute, with the following exceptions: 499 o In the initial BUNDLE offer, the offerer MUST NOT include 500 IDENTICAL and TRANSPORT multiplexing category SDP attributes 501 (BUNDLE attributes) in bundle-only "m=" sections. The offerer 502 MUST include such attributes in all other bundled "m=" sections. 503 In the initial BUNDLE offer each bundled "m=" line can contain a 504 different set of BUNDLE attributes, and attribute values. Once 505 the offerer tagged "m=" section has been selected, the BUNDLE 506 attributes contained in the offerer tagged "m=" section will apply 507 to each bundled "m=" section within the BUNDLE group. 509 o In a subsequent offer, or in an answer (initial of subsequent), 510 the offerer and answerer MUST include IDENTICAL and TRANSPORT 511 multiplexing category SDP attributes (BUNDLE attributes) only in 512 the tagged "m=" section (offerer tagged "m=" section or answerer 513 tagged "m=" section). The offerer and answerer MUST NOT include 514 such attributes in any other bundled "m=" section. The BUNDLE 515 attributes contained in the tagged "m=" section will apply to each 516 bundled "m=" section within the BUNDLE group. 518 o In an offer (initial BUNDLE offer or subsequent), or in an answer 519 (initial BUNDLE answer or subsequent), the offerer and answerer 520 MUST include SDP attributes of other categories than IDENTICAL and 521 TRANSPORT in each bundled "m=" section that a given attribute 522 applies to. Each bundled "m=" line can contain a different set of 523 such attributes, and attribute values, as such attributes only 524 apply to the given bundled "m=" section in which they are 525 included. 527 NOTE: A consequence of the rules above is that media-specific 528 IDENTICAL and TRANSPORT multiplexing category SDP attributes which 529 are applicable only to some of the bundled "m=" sections within the 530 BUNDLE group might appear in the tagged "m=" section for which they 531 are not applicable. For instance, the tagged "m=" section might 532 contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section 533 does not describe RTP-based media (but another bundled "m=" section 534 within the BUNDLE group does describe RTP-based media). 536 7.2. Generating the Initial SDP Offer 538 The procedures in this section apply to the first offer, within an 539 SDP session (e.g. a SIP dialog when the Session Initiation Protocol 540 (SIP) [RFC3261] is used to carry SDP), in which the offerer indicates 541 that it wants to negotiate a given BUNDLE group. This could occur in 542 the initial offer, or in a subsequent offer, of the SDP session. 544 When an offerer generates an initial BUNDLE offer, in order to 545 negotiate a BUNDLE group, it MUST: 547 o Assign a unique address:port to each bundled "m=" section, 548 following the procedures in [RFC3264], excluding any bundle-only 549 "m=" sections (see below); and 551 o Pick a bundled "m=" section as the suggested offerer tagged "m=" 552 section [Section 7.2.1]; and 554 o Include SDP attributes in the bundled "m=" sections following the 555 rules in [Section 7.1.3]; and 557 o Include an SDP 'group:BUNDLE' attribute in the offer; and 559 o Place the identification-tag of each bundled "m=" section in the 560 SDP 'group:BUNDLE' attribute identification-tag list. The offerer 561 BUNDLE-tag indicates the suggested offerer tagged "m=" section. 563 NOTE: When the offerer assigns unique addresses:ports to multiple 564 bundled "m=" sections, the offerer needs to be prepared to receive 565 bundled media on each unique address:port, until it receives the 566 associated answer and finds out which bundled "m=" section (and 567 associated address:port combination) the answerer has selected as the 568 offerer tagged "m=" section. 570 If the offerer wants to request that the answerer accepts a given 571 bundled "m=" section only if the answerer keeps the "m=" section 572 within the negotiated BUNDLE group, the offerer MUST: 574 o Include an SDP 'bundle-only' attribute [Section 7.2.1] in the "m=" 575 section; and 577 o Assign a zero port value to the "m=" section. 579 NOTE: If the offerer assigns a zero port value to a bundled "m=" 580 section, but does not include an SDP 'bundle-only' attribute in the 581 "m=" section, it is an indication that the offerer wants to disable 582 the "m=" section [Section 7.5.3]. 584 [Section 7.2.2] and [Section 18.1] show an example of an initial 585 BUNDLE offer. 587 7.2.1. Suggesting the Offerer tagged 'm=' section 589 In the initial BUNDLE offer, the bundled "m=" section indicated by 590 the offerer BUNDLE-tag is the suggested offerer tagged "m=" section. 591 The address:port combination associated with the "m=" section will be 592 used by the offerer for sending and receiving bundled media if the 593 answerer selects the "m=" section as the offerer tagged "m=" section 594 [Section 7.3.1]. In addition, if the answerer selects the "m=" 595 section as the offerer tagged "m=" section, the BUNDLE attributes 596 included in the "m=" section will be applied to each "m=" section 597 within the negotiated BUNDLE group. 599 The offerer MUST NOT suggest a bundle-only "m=" section as the 600 offerer tagged "m=" section. 602 It is RECOMMENDED that the suggested offerer tagged "m=" section is a 603 bundled "m=" section that the offerer believes it is unlikely that 604 the answerer will reject, or move out of the BUNDLE group. How such 605 assumption is made is outside the scope of this document. 607 7.2.2. Example: Initial SDP Offer 609 The example shows an initial BUNDLE offer. The offer includes two 610 "m=" sections in the offer, and suggests that both "m=" sections are 611 included in a BUNDLE group. The audio "m=" section is the suggested 612 offerer tagged "m=" section, indicated by placing the identification- 613 tag associated with the "m=" section (offerer BUNDLE-tag) first in 614 the SDP group:BUNDLE attribute identification-id list. 616 SDP Offer 618 v=0 619 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 620 s= 621 c=IN IP6 2001:db8::3 622 t=0 0 623 a=group:BUNDLE foo bar 625 m=audio 10000 RTP/AVP 0 8 97 626 b=AS:200 627 a=mid:foo 628 a=rtcp-mux 629 a=rtpmap:0 PCMU/8000 630 a=rtpmap:8 PCMA/8000 631 a=rtpmap:97 iLBC/8000 632 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 634 m=video 10002 RTP/AVP 31 32 635 b=AS:1000 636 a=mid:bar 637 a=rtcp-mux 638 a=rtpmap:31 H261/90000 639 a=rtpmap:32 MPV/90000 640 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 642 7.3. Generating the SDP Answer 644 When an answerer generates an answer (initial BUNDLE answer or 645 subsequent) that contains a BUNDLE group the following general SDP 646 grouping framework restrictions, defined in [RFC5888], also apply to 647 the BUNDLE group: 649 o The answerer is only allowed to include a BUNDLE group in an 650 initial BUNDLE answer if the offerer requested the BUNDLE group to 651 be created in the corresponding initial BUNDLE offer; and 653 o The answerer is only allowed to include a BUNDLE group in a 654 subsequent answer if the corresponding subsequent offer contains a 655 previously negotiated BUNDLE group; and 657 o The answerer is only allowed to include a bundled "m=" section in 658 an answer if the "m=" section was indicated as bundled in the 659 corresponding offer; and 661 o The answerer is only allowed to include a bundled "m=" section in 662 the same BUNDLE group as the bundled "m=" line in the 663 corresponding offer. 665 In addition, when an answerer generates an answer (initial BUNDLE 666 answer or subsequent) that contains a BUNDLE group, the answerer 667 MUST: 669 o In case of an initial BUNDLE answer, select the offerer tagged 670 "m=" section using the procedures in Section 7.3.1. In case of a 671 subsequent answer, the offerer tagged "m=" section is indicated in 672 the corresponding subsequent offer, and MUST NOT be changed by the 673 answerer; and 675 o Select the answerer tagged "m=" section [Section 7.3.1]; and 677 o Assign the answerer BUNDLE address:port to the answerer tagged 678 "m=" section; and 680 o Include an SDP 'bundle-only' attribute in, and assign a zero port 681 value to, every other bundled "m=" section within the BUNDLE 682 group; and 684 o Include SDP attributes in the bundled "m=" sections following the 685 rules in [Section 7.1.3]; and 687 o Include an SDP 'group:BUNDLE' attribute in the answer; and 689 o Place the identification-tag of each bundled "m=" section in the 690 SDP 'group:BUNDLE' attribute identification-tag list. The 691 answerer BUNDLE-tag indicates the answerer tagged "m=" section 692 [Section 7.3.1]. 694 If the answerer does not want to keep an "m=" section within a BUNDLE 695 group, it MUST: 697 o Move the "m=" section out of the BUNDLE group [Section 7.3.2]; or 699 o Reject the "m=" section [Section 7.3.3]. 701 The answerer can modify the answerer BUNDLE address:port, add and 702 remove SDP attributes, or modify SDP attribute values, in a 703 subsequent answer. Changes to the answerer BUNDLE address:port and 704 the answerer BUNDLE attributes will be applied to each bundled "m=" 705 section within the BUNDLE group. 707 NOTE: If a bundled "m=" section in an offer contains a zero port 708 value, but the "m=" section does not contain an SDP 'bundle-only' 709 attribute, it is an indication that the offerer wants to disable the 710 "m=" section [Section 7.5.3]. 712 7.3.1. Answerer Selection of tagged 'm=' sections 714 When the answerer selects the offerer tagged "m=" section, it first 715 checks the suggested offerer tagged "m=" section [Section 7.2.1]. 716 The answerer MUST check whether the "m=" section fulfils the 717 following criteria: 719 o The answerer will not move the "m=" section out of the BUNDLE 720 group [Section 7.3.2]; and 722 o The answerer will not reject the "m=" section [Section 7.3.3]; and 724 o The "m=" section does not contain a zero port value. 726 If all of the criteria above are fulfilled, the answerer MUST select 727 the "m=" section as the offerer tagged "m=" section, and MUST also 728 mark the corresponding "m=" section in the answer as the answerer 729 tagged "m=" section. In the answer the answerer BUNDLE-tag indicates 730 the answerer tagged "m=" section. 732 If one or more of the criteria are not fulfilled, the answerer MUST 733 pick the next identification-tag in the identification-tag list in 734 the offer, and perform the same criteria check for the "m=" section 735 indicated by that identification-tag. If there are no more 736 identification-tags in the identification-tag list, the answerer MUST 737 NOT create the BUNDLE group. Unless the answerer rejects the whole 738 offer, the answerer MUST apply the answerer procedures for moving an 739 "m=" section out of a BUNDLE group [Section 7.3.2] or rejecting an 740 "m=" section within a BUNDLE group [Section 7.3.3] to every bundled 741 "m=" section in the offer when creating the answer. 743 [Section 18.1] shows an example of an offerer BUNDLE address:port 744 selection. 746 [Section 7.3.4] and [Section 18.1] show an example of an answerer 747 tagged "m=" section selection. 749 7.3.2. Moving A Media Description Out Of A BUNDLE Group 751 When an answerer generates the answer, if the answerer wants to move 752 a bundled "m=" section out of the negotiated BUNDLE group, the 753 answerer MUST first check the following criteria: 755 o In the corresponding offer, the "m=" section is within a 756 previously negotiated BUNDLE group; and 758 o In the corresponding offer, the "m=" section contains an SDP 759 'bundle-only' attribute. 761 If either criterium above is fulfilled the answerer can not move the 762 "m=" section out of the BUNDLE group in the answer. The answerer can 763 either reject the whole offer, reject each bundled "m=" section 764 within the BUNDLE group [Section 7.3.3], or keep the "m=" section 765 within the BUNDLE group in the answer and later create an offer where 766 the "m=" section is moved out of the BUNDLE group [Section 7.5.2]. 768 NOTE: One consequence of the rules above is that, once a BUNDLE group 769 has been negotiated, a bundled "m=" section can not be moved out of 770 the BUNDLE group in an answer. Instead an offer is needed. 772 When the answerer generates an answer, in which it moves a bundled 773 "m=" section out of a BUNDLE group, the answerer: 775 o MUST assign a unique address:port to the "m=" section; and 777 o MUST include any applicable SDP attribute in the "m=" section, 778 using the normal offer/answer procedures for the each Attributes; 779 and 781 o MUST NOT place the identification-tag associated with the "m=" 782 section in the SDP 'group:BUNDLE' attribute identification-tag 783 list associated with the BUNDLE group. 785 o MUST NOT include an SDP 'bundle-only' attribute to the "m=" 786 section; and 788 Because an answerer is not allowed to move an "m=" section from one 789 BUNDLE group to another within an answer [Section 7.3], if the 790 answerer wants to move an "m=" section from one BUNDLE group to 791 another it MUST first move the "m=" section out of the current BUNDLE 792 group, and then generate an offer where the "m=" section is added to 793 another BUNDLE group [Section 7.5.1]. 795 7.3.3. Rejecting a Media Description in a BUNDLE Group 797 When an answerer wants to reject a bundled "m=" section in an answer, 798 it MUST first check the following criterion: 800 o In the corresponding offer, the "m=" section is the offerer tagged 801 "m=" section. 803 If the criterium above is fulfilled the answerer can not reject the 804 "m=" section in the answer. The answerer can either reject the whole 805 offer, reject each bundled "m=" section within the BUNDLE group, or 806 keep the "m=" section within the BUNDLE group in the answer and later 807 create an offer where the "m=" section is disabled within the BUNDLE 808 group [Section 7.5.3]. 810 When an answerer generates an answer, in which it rejects a bundled 811 "m=" section, the answerer: 813 o MUST assign a zero port value to the "m=" section, according to 814 the procedures in [RFC3264]; and 816 o MUST NOT place the identification-tag associated with the "m=" 817 section in the SDP 'group:BUNDLE' attribute identification-tag 818 list associated with the BUNDLE group; and 820 o MUST NOT include an SDP 'bundle-only' attribute in the "m=" 821 section. 823 7.3.4. Example: SDP Answer 825 The example below shows an answer, based on the corresponding offer 826 in [Section 7.2.2]. The answerer accepts both bundled "m=" sections 827 within the created BUNDLE group. The audio "m=" section is the 828 answerer tagged "m=" section, indicated by placing the 829 identification-tag associated with the "m=" section (answerer BUNDLE- 830 tag) first in the SDP group;BUNDLE attribute identification-id list. 831 The answerer includes an SDP 'bundle-only' attribute in, and assigns 832 a zero port value to, the video "m=" section. 834 SDP Answer 836 v=0 837 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 838 s= 839 c=IN IP6 2001:db8::1 840 t=0 0 841 a=group:BUNDLE foo bar 843 m=audio 20000 RTP/AVP 0 844 b=AS:200 845 a=mid:foo 846 a=rtcp-mux 847 a=rtpmap:0 PCMU/8000 848 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 850 m=video 0 RTP/AVP 32 851 b=AS:1000 852 a=mid:bar 853 a=bundle-only 854 a=rtpmap:32 MPV/90000 855 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 857 7.4. Offerer Processing of the SDP Answer 859 When an offerer receives an answer, if the answer contains a BUNDLE 860 group, the offerer MUST check that any bundled "m=" section in the 861 answer was indicated as bundled in the corresponding offer. If there 862 is no mismatch, the offerer MUST apply the properties (BUNDLE 863 address:port, BUNDLE attributes etc) of the offerer tagged "m=" 864 section (selected by the answerer [Section 7.3.1]) to each bundled 865 "m=" section within the BUNDLE group. 867 NOTE: As the answerer might reject one or more bundled "m=" sections 868 in an initial BUNDLE offer, or move a bundled "m=" section out of a 869 BUNDLE group, a given bundled "m=" section in the offer might not be 870 indicated as bundled in the corresponding answer. 872 If the answer does not contain a BUNDLE group, the offerer MUST 873 process the answer as a normal answer. 875 7.5. Modifying the Session 877 When a BUNDLE group has previously been negotiated, and an offerer 878 generates a subsequent offer, the offerer MUST: 880 o Pick one bundled "m=" section as the offerer tagged "m=" section. 881 The offerer can either pick the "m=" section that was previously 882 selected by the answerer as the offerer tagged "m=" section, or 883 pick another bundled "m=" section within the BUNDLE group; and 885 o Assign a BUNDLE address:port (previously negotiated or newly 886 suggest) to the offerer tagged "m=" section; and 888 o Include an SDP 'bundle-only' attribute in, and assign a zero port 889 value to, every other bundled "m=" section within the BUNDLE 890 group; and 892 o Include SDP attributes in the bundled "m=" sections following the 893 rules in [Section 7.1.3]; and 895 o Include an SDP 'group:BUNDLE' attribute in the offer; and 897 o Place the identification-tag of each bundled "m=" section in the 898 SDP 'group:BUNDLE' attribute identification-tag list. The offerer 899 BUNDLE-tag indicates the offerer tagged "m=" section. 901 The offerer MUST NOT pick a given bundled "m=" section as the offerer 902 tagged "m=" section if: 904 o The offerer wants to move the "m=" section out of the BUNDLE group 905 [Section 7.5.2]; or 907 o The offerer wants to disable the "m=" section [Section 7.5.3]. 909 The offerer can modify the offerer BUNDLE address:port, add and 910 remove SDP attributes, or modify SDP attribute values, in the 911 subsequent offer. Changes to the offerer BUNDLE address:port and the 912 offerer BUNDLE attributes will (if the offer is accepted by the 913 answerer) be applied to each bundled "m=" section within the BUNDLE 914 group. 916 7.5.1. Adding a Media Description to a BUNDLE group 918 When an offerer generates a subsequent offer, in which it wants to 919 add a bundled "m=" section to a previously negotiated BUNDLE group, 920 the offerer follows the procedures in Section 7.5. The offerer 921 either picks the added "m=" section, or an "m=" section previously 922 added to the BUNDLE group, as the offerer tagged "m=" section. 924 NOTE: As described in Section 7.3.2, the answerer can not move the 925 added "m=" section out of the BUNDLE group in its answer. If the 926 answer wants to move the "m=" section out of the BUNDLE group, it 927 will have to first accept it into the BUNDLE group in the answer, and 928 then send a subsequent offer where the "m=" section is moved out of 929 the BUNDLE group [Section 7.5.2]. 931 7.5.2. Moving a Media Description Out of a BUNDLE Group 933 When an offerer generates a subsequent offer, in which it want to 934 remove a bundled "m=" section from a BUNDLE group, the offerer: 936 o MUST assign a unique address:port to the "m=" section; and 938 o MUST include SDP attributes in the "m=" section following the 939 normal offer/answer rules for each attribute; and 941 o MUST NOT place the identification-tag associated with the "m=" 942 section in the SDP 'group:BUNDLE' attribute identification-tag 943 list associated with the BUNDLE group; and 945 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 946 section. 948 For the other bundled "m=" sections within the BUNDLE group, the 949 offerer follows the procedures in [Section 7.5]. 951 An offerer MUST NOT move an "m=" section from one BUNDLE group to 952 another within a single offer. If the offerer wants to move an "m=" 953 section from one BUNDLE group to another it MUST first move the 954 BUNDLE group out of the current BUNDLE group, and then generate a 955 second offer where the "m=" section is added to another BUNDLE group 956 [Section 7.5.1]. 958 [Section 18.4] shows an example of an offer for moving an "m=" 959 section out of a BUNDLE group. 961 7.5.3. Disabling a Media Description in a BUNDLE Group 963 When an offerer generates a subsequent offer, in which it want to 964 disable a bundled "m=" section from a BUNDLE group, the offerer: 966 o MUST assign a zero port value to the "m=" section, following the 967 procedures in [RFC4566]; and 969 o MUST NOT place the identification-tag associated with the "m=" 970 section in the SDP 'group:BUNDLE' attribute identification-tag 971 list associated with the BUNDLE group; and 973 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 974 section. 976 For the other bundled "m=" sections within the BUNDLE group, the 977 offerer follows the procedures in [Section 7.5]. 979 [Section 18.5] shows an example of an offer and answer for disabling 980 an "m=" section within a BUNDLE group. 982 8. Protocol Identification 984 Each "m=" section within a BUNDLE group MUST use the same transport- 985 layer protocol. If bundled "m=" sections use different upper-layer 986 protocols on top of the transport-layer protocol, there MUST exist a 987 publicly available specification which describes a mechanism how to 988 associate received data with the correct protocol for this particular 989 protocol combination. 991 In addition, if received data can be associated with more than one 992 bundled "m=" section, there MUST exist a publicly available 993 specification which describes a mechanism for associating the 994 received data with the correct "m=" section. 996 This document describes a mechanism to identify the protocol of 997 received data among the STUN, DTLS and SRTP protocols (in any 998 combination), when UDP is used as transport-layer protocol, but it 999 does not describe how to identify different protocols transported on 1000 DTLS. While the mechanism is generally applicable to other protocols 1001 and transport-layer protocols, any such use requires further 1002 specification around how to multiplex multiple protocols on a given 1003 transport-layer protocol, and how to associate received data with the 1004 correct protocols. 1006 8.1. STUN, DTLS, SRTP 1008 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 1009 protocol of a received packet among the STUN, DTLS and SRTP protocols 1010 (in any combination). If an offer or answer includes a bundled "m=" 1011 section that represents these protocols, the offerer or answerer MUST 1012 support the mechanism described in [RFC5764], and no explicit 1013 negotiation is required in order to indicate support and usage of the 1014 mechanism. 1016 [RFC5764] does not describe how to identify different protocols 1017 transported on DTLS, only how to identify the DTLS protocol itself. 1018 If multiple protocols are transported on DTLS, there MUST exist a 1019 specification describing a mechanism for identifying each individual 1020 protocol. In addition, if a received DTLS packet can be associated 1021 with more than one "m=" section, there MUST exist a specification 1022 which describes a mechanism for associating the received DTLS packets 1023 with the correct "m=" section. 1025 [Section 9.2] describes how to associate the packets in a received 1026 SRTP stream with the correct "m=" section. 1028 9. RTP Considerations 1030 9.1. Single RTP Session 1032 All RTP-based media within a single BUNDLE group belong to a single 1033 RTP session [RFC3550]. 1035 Since a single BUNDLE transport is used for sending and receiving 1036 bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for 1037 RTP-based bundled media. 1039 Since a single RTP session is used for each BUNDLE group, all "m=" 1040 sections representing RTP-based media within a BUNDLE group will 1041 share a single SSRC numbering space [RFC3550]. 1043 The following rules and restrictions apply for a single RTP session: 1045 o A specific payload type value can be used in multiple bundled "m=" 1046 sections only if each codec associated with the payload type 1047 number shares an identical codec configuration [Section 9.1.1]. 1049 o The proto value in each bundled RTP-based "m=" section MUST be 1050 identical (e.g., RTP/AVPF). 1052 o The RTP MID header extension MUST be enabled, by including an SDP 1053 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 1054 hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section 1055 in every offer and answer. 1057 o A given SSRC MUST NOT transmit RTP packets using payload types 1058 that originate from different bundled "m=" sections. 1060 NOTE: The last bullet above is to avoid sending multiple media types 1061 from the same SSRC. If transmission of multiple media types are done 1062 with time overlap, RTP and RTCP fail to function. Even if done in 1063 proper sequence this causes RTP Timestamp rate switching issues 1064 [RFC7160]. However, once an SSRC has left the RTP session (by 1065 sending an RTCP BYE packet), that SSRC can be reused by another 1066 source (possibly associated with a different bundled "m=" section) 1067 after a delay of 5 RTCP reporting intervals (the delay is to ensure 1068 the SSRC has timed out, in case the RTCP BYE packet was lost 1069 [RFC3550]). 1071 [RFC7657] defines Differentiated Services (Diffserv) considerations 1072 for RTP-based bundled media sent using a mixture of Diffserv 1073 Codepoints. 1075 9.1.1. Payload Type (PT) Value Reuse 1077 Multiple bundled "m=" sections might describe RTP based media. As 1078 all RTP based media associated with a BUNDLE group belong to the same 1079 RTP session, in order for a given payload type value to be used 1080 inside more than one bundled "m=" section, all codecs associated with 1081 the payload type number MUST share an identical codec configuration. 1082 This means that the codecs MUST share the same media type, encoding 1083 name, clock rate and any parameter that can affect the codec 1084 configuration and packetization. 1085 [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose 1086 attribute values are required to be identical for all codecs that use 1087 the same payload type value. 1089 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 1090 Description 1092 As described in [RFC3550], RTP packets are associated with RTP 1093 streams [RFC7656]. Each RTP stream is identified by an SSRC value, 1094 and each RTP packet includes an SSRC field that is used to associate 1095 the packet with the correct RTP stream. RTCP packets also use SSRCs 1096 to identify which RTP streams the packet relates to. However, a RTCP 1097 packet can contain multiple SSRC fields, in the course of providing 1098 feedback or reports on different RTP streams, and therefore can be 1099 associated with multiple such streams. 1101 In order to be able to process received RTP/RTCP packets correctly, 1102 it MUST be possible to associate an RTP stream with the correct "m=" 1103 section, as the "m=" section and SDP attributes associated with the 1104 "m=" section contains information needed to process the packets. 1106 As all RTP streams associated with a BUNDLE group use the same 1107 transport for sending and receiving RTP/RTCP packets, the local 1108 address:port combination part of the transport cannot be used to 1109 associate an RTP stream with the correct "m=" section. In addition, 1110 multiple RTP streams might be associated with the same "m=" section. 1112 An offerer and answerer can inform each other which SSRC values they 1113 will use for an RTP stream by using the SDP 'ssrc' attribute 1114 [RFC5576]. However, an offerer will not know which SSRC values the 1115 answerer will use until the offerer has received the answer providing 1116 that information. Due to this, before the offerer has received the 1117 answer, the offerer will not be able to associate an RTP stream with 1118 the correct "m=" section using the SSRC value associated with the RTP 1119 stream. In addition, the offerer and answerer may start using new 1120 SSRC values mid-session, without informing each other using the SDP 1121 'ssrc' attribute. 1123 In order for an offerer and answerer to always be able to associate 1124 an RTP stream with the correct "m=" section, the offerer and answerer 1125 using the BUNDLE extension MUST support the mechanism defined in 1126 Section 15, where the offerer and answerer insert the identification- 1127 tag associated with an "m=" section (provided by the remote peer) 1128 into RTP and RTCP packets associated with a BUNDLE group. 1130 When using this mechanism, the mapping from an SSRC to an 1131 identification-tag is carried in RTP header extensions or RTCP SDES 1132 packets, as specified in Section 15. Since a compound RTCP packet 1133 can contain multiple RTCP SDES packets, and each RTCP SDES packet can 1134 contain multiple chunks, a single RTCP packet can contain several 1135 SSRC to identification-tag mappings. The offerer and answerer 1136 maintain tables used for routing that are updated each time an RTP/ 1137 RTCP packet contains new information that affects how packets are to 1138 be routed. 1140 However, some legacy implementations may not include this 1141 identification-tag in their RTP and RTCP traffic when using the 1142 BUNDLE mechanism, and instead use a payload type based mechanism to 1143 associate RTP streams with SDP "m=" sections. In this situation, 1144 each "m=" section needs to use unique payload type values, in order 1145 for the payload type to be a reliable indicator of the relevant "m=" 1146 section for the RTP stream. If an implementation fails to ensure 1147 unique payload type values it will be impossible to associate the RTP 1148 stream using that payload type value to a particular "m=" section. 1149 Note that when using the payload type to associate RTP streams with 1150 "m=" sections an RTP stream, identified by its SSRC, will be mapped 1151 to an "m=" section when the first packet of that RTP stream is 1152 received, and the mapping will not be changed even if the payload 1153 type used by that RTP stream changes. In other words, the SSRC 1154 cannot "move" to a different "m=" section simply by changing the 1155 payload type. 1157 Applications can implement RTP stacks in many different ways. The 1158 algorithm below details one way that RTP streams can be associated 1159 with "m=" sections, but is not meant to be prescriptive about exactly 1160 how an RTP stack needs to be implemented. Applications MAY use any 1161 algorithm that achieves equivalent results to those described in the 1162 algorithm below. 1164 To prepare to associate RTP streams with the correct "m=" section, 1165 the following steps MUST be followed for each BUNDLE group: 1167 Construct a table mapping MID to "m=" section for each "m=" 1168 section in this BUNDLE group. Note that an "m=" section may only 1169 have one MID. 1171 Construct a table mapping SSRCs of incoming RTP streams to "m=" 1172 section for each "m=" section in this BUNDLE group and for each 1173 SSRC configured for receiving in that "m=" section. 1175 Construct a table mapping the SSRC of each outgoing RTP stream to 1176 "m=" section for each "m=" section in this BUNDLE group and for 1177 each SSRC configured for sending in that "m=" section. 1179 Construct a table mapping payload type to "m=" section for each 1180 "m=" section in the BUNDLE group and for each payload type 1181 configured for receiving in that "m=" section. If any payload 1182 type is configured for receiving in more than one "m=" section in 1183 the BUNDLE group, do not include it in the table, as it cannot be 1184 used to uniquely identify an "m=" section. 1186 Note that for each of these tables, there can only be one mapping 1187 for any given key (MID, SSRC, or PT). In other words, the tables 1188 are not multimaps. 1190 As "m=" sections are added or removed from the BUNDLE groups, or 1191 their configurations are changed, the tables above MUST also be 1192 updated. 1194 When an RTP packet is received, it MUST be delivered to the RTP 1195 stream corresponding to its SSRC. That RTP stream MUST then be 1196 associated with the correct "m=" section within a BUNDLE group, for 1197 additional processing, according to the following steps: 1199 If the MID associated with the RTP stream is not in the table 1200 mapping MID to "m=" section, then the RTP stream is not decoded 1201 and the payload data is discarded. 1203 If the packet has a MID, and the packet's extended sequence number 1204 is greater than that of the last MID update, as discussed in 1205 [RFC7941], Section 4.2.6, update the MID associated with the RTP 1206 stream to match the MID carried in the RTP packet, then update the 1207 mapping tables to include an entry that maps the SSRC of that RTP 1208 stream to the "m=" section for that MID. 1210 If the SSRC of the RTP stream is in the incoming SSRC mapping 1211 table, check that the payload type used by the RTP stream matches 1212 a payload type included on the matching "m=" section. If so, 1213 associate the RTP stream with that "m=" section. Otherwise, the 1214 RTP stream is not decoded and the payload data is discarded. 1216 If the payload type used by the RTP stream is in the payload type 1217 table, update the incoming SSRC mapping table to include an entry 1218 that maps the RTP stream's SSRC to the "m=" section for that 1219 payload type. Associate the RTP stream with the corresponding 1220 "m=" section. 1222 Otherwise, mark the RTP stream as not for decoding and discard the 1223 payload. 1225 If the RTP packet contains one or more contributing source (CSRC) 1226 identifiers, then each CSRC is looked up in the incoming SSRC table 1227 and a copy of the RTP packet is associated with the corresponding 1228 "m=" section for additional processing. 1230 For each RTCP packet received (including each RTCP packet that is 1231 part of a compound RTCP packet), the packet is processed as usual by 1232 the RTP layer, then associated with the appropriate "m=" sections, 1233 and processed for the RTP streams represented by those "m=" sections. 1234 This routing is type-dependent, as each kind of RTCP packet has its 1235 own mechanism for associating it with the relevant RTP streams. 1237 RTCP packets that cannot be associated with an appropriate "m=" 1238 section MUST still be processed as usual by the RTP layer, updating 1239 the metadata associated with the corresponding RTP streams. This 1240 situation can occur with certain multiparty RTP topologies, or when 1241 RTCP packets are sent containing a subset of the SDES information. 1243 Additional rules for processing various types of RTCP packets are 1244 explained below. 1246 If the RTCP packet is of type SDES, for each chunk in the packet 1247 whose SSRC is found in the incoming SSRC table, deliver a copy of 1248 the SDES packet to the "m=" section associated with that SSRC. In 1249 addition, for any SDES MID items contained in these chunks, if the 1250 MID is found in the table mapping MID to "m=" section, update the 1251 incoming SSRC table to include an entry that maps the RTP stream 1252 associated with the chunk's SSRC to the "m=" section associated 1253 with that MID, unless the packet is older than the packet that 1254 most recently updated the mapping for this SSRC, as discussed in 1255 [RFC7941], Section 4.2.6. 1257 Note that if an SDES packet is received as part of a compound RTCP 1258 packet, the SSRC to "m=" section mapping might not exist until the 1259 SDES packet is handled (e.g., in the case where RTCP for a source 1260 is received before any RTP packets). Therefore, it can be 1261 beneficial for an implementation to delay RTCP packet routing, 1262 such that it either prioritizes processing of the SDES item to 1263 generate or update the mapping, or buffers the RTCP information 1264 that needs to be routed until the SDES item(s) has been processed. 1265 If the implementation is unable to follow this recommendation, the 1266 consequence could be that some RTCP information from this 1267 particular RTCP compound packet is not provided to higher layers. 1268 The impact from this is likely minor, when this information 1269 relates to a future incoming RTP stream. 1271 If the RTCP packet is of type BYE, it indicates that the RTP 1272 streams referenced in the packet are ending. Therefore, for each 1273 SSRC indicated in the packet that is found in the incoming SSRC 1274 table, first deliver a copy of the BYE packet to the "m=" section 1275 associated with that SSRC, then remove the entry for that SSRC 1276 from the incoming SSRC table after an appropriate delay to account 1277 for "straggler packets", as specified in [RFC3550], Section 6.2.1. 1279 If the RTCP packet is of type SR or RR, for each report block in 1280 the report whose "SSRC of source" is found in the outgoing SSRC 1281 table, deliver a copy of the SR or RR packet to the "m=" section 1282 associated with that SSRC. In addition, if the packet is of type 1283 SR, and the sender SSRC for the packet is found in the incoming 1284 SSRC table, deliver a copy of the SR packet to the "m=" section 1285 associated with that SSRC. 1287 If the implementation supports RTCP XR and the packet is of type 1288 XR, as defined in [RFC3611], for each report block in the report 1289 whose "SSRC of source" is found in the outgoing SSRC table, 1290 deliver a copy of the XR packet to the "m=" section associated 1291 with that SSRC. In addition, if the sender SSRC for the packet is 1292 found in the incoming SSRC table, deliver a copy of the XR packet 1293 to the "m=" section associated with that SSRC. 1295 If the RTCP packet is a feedback message of type RTPFB or PSFB, as 1296 defined in [RFC4585], it will contain a media source SSRC, and 1297 this SSRC is used for routing certain subtypes of feedback 1298 messages. However, several subtypes of PSFB and RTPFB messages 1299 include target SSRC(s) in a section called Feedback Control 1300 Information (FCI). For these messages, the target SSRC(s) are 1301 used for routing. 1303 If the RTCP packet is a feedback packet that does not include 1304 target SSRCs in its FCI section, and the media source SSRC is 1305 found in the outgoing SSRC table, deliver the feedback packet to 1306 the "m=" section associated with that SSRC. RTPFB and PSFB types 1307 that are handled in this way include: 1309 Generic NACK: [RFC4585] (PT=RTPFB, FMT=1). 1311 Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1). 1313 Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2). 1315 Reference Picture Selection Indication (RPSI): [RFC4585] 1316 (PT=PSFB, FMT=3). 1318 If the RTCP packet is a feedback message that does include target 1319 SSRC(s) in its FCI section, it can either be a request or a 1320 notification. Requests reference a RTP stream that is being sent 1321 by the message recipient, whereas notifications are responses to 1322 an earlier request, and therefore reference a RTP stream that is 1323 being received by the message recipient. 1325 If the RTCP packet is a feedback request that includes target 1326 SSRC(s), for each target SSRC that is found in the outgoing SSRC 1327 table, deliver a copy of the RTCP packet to the "m=" section 1328 associated with that SSRC. PSFB and RTPFB types that are handled 1329 in this way include: 1331 Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). 1333 Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, 1334 FMT=5). 1336 H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, 1337 FMT=7). 1339 Temporary Maximum Media Bit Rate Request (TMMBR): [RFC5104] 1340 (PT=RTPFB, FMT=3). 1342 Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, 1343 FMT=10). 1345 If the RTCP packet is a feedback notification that includes target 1346 SSRC(s), for each target SSRC that is found in the incoming SSRC 1347 table, deliver a copy of the RTCP packet to the "m=" section 1348 associated with the RTP stream with matching SSRC. PSFB and RTPFB 1349 types that are handled in this way include: 1351 Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] 1352 (PT=PSFB, FMT=6). This message is a notification in response 1353 to a prior TSTR. 1355 Temporary Maximum Media Bit Rate Notification (TMMBN): [RFC5104] 1356 (PT=RTPFB, FMT=4). This message is a notification in response 1357 to a prior TMMBR, but can also be sent unsolicited. 1359 If the RTCP packet is of type APP, then it is handled in an 1360 application specific manner. If the application does not 1361 recognise the APP packet, then it MUST be discarded. 1363 9.3. RTP/RTCP Multiplexing 1365 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 1366 multiplexing [RFC5761] for the RTP-based bundled media (i.e., the 1367 same transport will be used for both RTP packets and RTCP packets). 1368 In addition, the offerer and answerer MUST support the SDP 'rtcp-mux- 1369 only' attribute [I-D.ietf-mmusic-mux-exclusive]. 1371 9.3.1. SDP Offer/Answer Procedures 1373 This section describes how an offerer and answerer use the SDP 'rtcp- 1374 mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute 1375 [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP 1376 multiplexing for RTP-based bundled media. 1378 RTP/RTCP multiplexing only applies to RTP-based media. However, as 1379 described in Section 7.1.3, within an offer or answer the SDP 'rtcp- 1380 mux' and SDP 'rtcp-mux-only' attributes might be included in a 1381 bundled "m=" section for non-RTP-based media (if such "m=" section is 1382 the offerer tagged "m=" section or answerer tagged "m=" section). 1384 9.3.1.1. Generating the Initial SDP BUNDLE Offer 1386 When an offerer generates an initial BUNDLE offer, if the offer 1387 contains one or more bundled "m=" sections for RTP-based media (or, 1388 if there is a chance that "m=" sections for RTP-based media will 1389 later be added to the BUNDLE group), the offerer MUST include an SDP 1390 'rtcp-mux' attribute [RFC5761] in each bundled "m=" section 1391 (excluding any bundle-only "m=" sections). In addition, the offerer 1392 MAY include an SDP 'rtcp-mux-only' attribute 1393 [I-D.ietf-mmusic-mux-exclusive] in one or more bundled "m=" sections 1394 for RTP-based media. 1396 NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute 1397 depends on whether the offerer supports fallback to usage of a 1398 separate port for RTCP in case the answerer moves one or more "m=" 1399 sections for RTP-based media out of the BUNDLE group in the answer. 1401 NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the 1402 bundled "m=" sections, but does not include an SDP 'rtcp-mux-only' 1403 attribute, the offerer can also include an SDP 'rtcp' attribute 1404 [RFC3605] in one or more RTP-based bundled "m=" sections in order to 1405 provide a fallback port for RTCP, as described in [RFC5761]. 1406 However, the fallback port will only be applied to "m=" sections for 1407 RTP-based media that are moved out of the BUNDLE group by the 1408 answerer. 1410 In the initial BUNDLE offer, the address:port combination for RTCP 1411 MUST be unique in each bundled "m=" section for RTP-based media 1412 (excluding a bundle-only "m=" section), similar to RTP. 1414 9.3.1.2. Generating the SDP Answer 1416 When an answerer generates an answer, if the answerer supports RTP- 1417 based media, and if a bundled "m=" section in the corresponding offer 1418 contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage 1419 of RTP/RTCP multiplexing, even if there currently are no bundled "m=" 1420 sections for RTP-based media within the BUNDLE group. The answerer 1421 MUST include an SDP 'rtcp-mux' attribute in the answerer tagged "m=" 1422 section, following the procedures for BUNDLE attributes 1423 [Section 7.1.3]. In addition, if the "m=" section that is selected 1424 as the offerer tagged "m=" section contained an SDP "rtcp-mux-only" 1425 attribute, the answerer MUST include an SDP "rtcp-mux-only" attribute 1426 in the answerer tagged "m=" section. 1428 In an initial BUNDLE offer, if the suggested offerer tagged "m=" 1429 section contained an SDP 'rtcp-mux-only' attribute, the "m=" section 1430 was for RTP-based media, and the answerer does not accept the "m=" 1431 section in the created BUNDLE group, the answerer MUST either move 1432 the "m=" section out of the BUNDLE group [Section 7.3.2], include the 1433 attribute in the moved "m=" section and enable RTP/RTCP multiplexing 1434 for the media associated with the "m=" section, or reject the "m=" 1435 section [Section 7.3.3]. 1437 The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled 1438 "m=" section in the answer. The answerer will use the port value of 1439 the tagged offerer "m=" section sending RTP and RTCP packets 1440 associated with RTP-based bundled media towards the offerer. 1442 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1443 negotiated in a previous offer/answer exchange, the answerer MUST 1444 include an SDP 'rtcp-mux' attribute in the answerer tagged "m=" 1445 section . It is not possible to disable RTP/RTCP multiplexing within 1446 a BUNDLE group. 1448 9.3.1.3. Offerer Processing of the SDP Answer 1450 When an offerer receives an answer, if the answerer has accepted the 1451 usage of RTP/RTCP multiplexing [Section 9.3.1.2], the answerer 1452 follows the procedures for RTP/RTCP multiplexing defined in 1453 [RFC5761]. The offerer will use the port value of the answerer 1454 tagged "m=" section for sending RTP and RTCP packets associated with 1455 RTP-based bundled media towards the answerer. 1457 NOTE: It is considered a protocol error if the answerer has not 1458 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" 1459 sections that the answerer included in the BUNDLE group. 1461 9.3.1.4. Modifying the Session 1463 When an offerer generates a subsequent offer, the offerer MUST 1464 include an SDP 'rtcp-mux' attribute in the offerer tagged "m=" 1465 section, following the procedures for IDENTICAL multiplexing category 1466 attributes in Section 7.1.3. 1468 10. ICE Considerations 1470 This section describes how to use the BUNDLE grouping extension 1471 together with the Interactive Connectivity Establishment (ICE) 1472 mechanism [I-D.ietf-ice-rfc5245bis]. 1474 The generic procedures for negotiating usage of ICE using SDP, 1475 defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE 1476 with BUNDLE, with the following exceptions: 1478 o When the BUNDLE transport has been established, ICE connectivity 1479 checks and keep-alives only need to be performed for the BUNDLE 1480 transport, instead of per individual bundled "m=" section within 1481 the BUNDLE group. 1483 o The generic SDP attribute offer/answer considerations 1484 [Section 7.1.3] also apply to ICE-related attributes. Therefore, 1485 when an offer sends an initial BUNDLE offer (in order to negotiate 1486 a BUNDLE group) the offerer include ICE-related media-level 1487 attributes in each bundled "m=" section (excluding any bundle-only 1488 "m=" section), and each "m=" section MUST contain unique ICE 1489 properties. When an answerer generates an answer (initial BUNDLE 1490 answer or subsequent) that contains a BUNDLE group, and when an 1491 offerer sends a subsequent offer that contains a BUNDLE group, 1492 ICE-related media-level attributes are only included in the tagged 1493 "m=" section (suggested offerer tagged "m=" section or answerer 1494 tagged "m=" section), and the ICE properties are applied to each 1495 bundled "m=" section within the BUNDLE group. 1497 NOTE: Most ICE-related media-level SDP attributes belong to the 1498 TRANSPORT multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes], 1499 and the generic SDP attribute offer/answer considerations for 1500 TRANSPORT multiplexing category apply to the attributes. However, in 1501 the case of ICE-related attributes, the same considerations also 1502 apply to ICE-related media-level attributes that belong to other 1503 multiplexing categories. 1505 NOTE: The following ICE-related media-level SDP attributes are 1506 defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidate', 'remote- 1507 candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- 1508 pacing'. 1510 Initially, before ICE has produced selected candidate pairs that will 1511 be used for media, there might be multiple transports established (if 1512 multiple candidate pairs are tested). Once ICE has selected 1513 candidate pairs, they form the BUNDLE transport. 1515 Support and usage of ICE mechanism together with the BUNDLE extension 1516 is OPTIONAL, and the procedures in this section only apply when the 1517 ICE mechanism is used. Note that applications might mandate usage of 1518 the ICE mechanism even if the BUNDLE extension is not used. 1520 NOTE: If the trickle ICE mechanism [I-D.ietf-mmusic-trickle-ice-sip] 1521 is used, an offerer and answerer might assign a port value of '9', 1522 and an IPv4 address of '0.0.0.0' (or, the IPv6 equivalent '::') to 1523 multiple bundled "m=" sections in the initial BUNDLE offer. The 1524 offerer and answerer will follow the normal procedures for generating 1525 the offers and answers, including picking a bundled "m=" section as 1526 the suggested offerer tagged "m=" section, selecting the tagged "m=" 1527 sections etc. The only difference is that media can not be sent 1528 until one or more candidates have been provided. Once a BUNDLE group 1529 has been negotiated, trickled candidates associated with a bundled 1530 "m=" section will be applied to all bundled "m=" sections within the 1531 BUNDLE group. 1533 11. DTLS Considerations 1535 One or more media streams within a BUNDLE group might use the 1536 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1537 to encrypt the data, or to negotiate encryption keys if another 1538 encryption mechanism is used to encrypt media. 1540 When DTLS is used within a BUNDLE group, the following rules apply: 1542 o There can only be one DTLS association [RFC6347] associated with 1543 the BUNDLE group; and 1545 o Each usage of the DTLS association within the BUNDLE group MUST 1546 use the same mechanism for determining which endpoints (the 1547 offerer or answerer) become DTLS client and DTLS server; and 1549 o Each usage of the DTLS association within the BUNDLE group MUST 1550 use the same mechanism for determining whether an offer or answer 1551 will trigger the establishment of a new DTLS association, or 1552 whether an existing DTLS association will be used; and 1554 o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include 1555 the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message 1556 [RFC5764]. The client MUST include the extension even if the 1557 usage of DTLS-SRTP is not negotiated as part of the multimedia 1558 session (e.g., SIP session [RFC3261]). 1560 NOTE: The inclusion of the 'use_srtp' extension during the initial 1561 DTLS handshake ensures that a DTLS renegotiation will not be required 1562 in order to include the extension, in case DTLS-SRTP encrypted media 1563 is added to the BUNDLE group later during the multimedia session. 1565 12. RTP Header Extensions Consideration 1567 When [RFC8285] RTP header extensions are used in the context of this 1568 specification, the identifier used for a given extension MUST 1569 identify the same extension across all the bundled media 1570 descriptions. 1572 13. Update to RFC 3264 1574 This section updates RFC 3264, in order to allow extensions to define 1575 the usage of a zero port value in offers and answers for other 1576 purposes than removing or disabling media streams. The following 1577 sections of RFC 3264 are updated: 1579 o Section 5.1 (Unicast Streams). 1581 o Section 8.4 (Putting a Unicast Media Stream on Hold). 1583 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 1585 For recvonly and sendrecv streams, the port number and address in the 1586 offer indicate where the offerer would like to receive the media 1587 stream. For sendonly RTP streams, the address and port number 1588 indirectly indicate where the offerer wants to receive RTCP reports. 1589 Unless there is an explicit indication otherwise, reports are sent to 1590 the port number one higher than the number indicated. The IP address 1591 and port present in the offer indicate nothing about the source IP 1592 address and source port of RTP and RTCP packets that will be sent by 1593 the offerer. A port number of zero in the offer indicates that the 1594 stream is offered but MUST NOT be used. This has no useful semantics 1595 in an initial offer, but is allowed for reasons of completeness, 1596 since the answer can contain a zero port indicating a rejected stream 1597 (Section 6). Furthermore, existing streams can be terminated by 1598 setting the port to zero (Section 8). In general, a port number of 1599 zero indicates that the media stream is not wanted. 1601 13.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 1603 For recvonly and sendrecv streams, the port number and address in the 1604 offer indicate where the offerer would like to receive the media 1605 stream. For sendonly RTP streams, the address and port number 1606 indirectly indicate where the offerer wants to receive RTCP reports. 1607 Unless there is an explicit indication otherwise, reports are sent to 1608 the port number one higher than the number indicated. The IP address 1609 and port present in the offer indicate nothing about the source IP 1610 address and source port of RTP and RTCP packets that will be sent by 1611 the offerer. A port number of zero in the offer by default indicates 1612 that the stream is offered but MUST NOT be used, but an extension 1613 mechanism might specify different semantics for the usage of a zero 1614 port value. Furthermore, existing streams can be terminated by 1615 setting the port to zero (Section 8). In general, a port number of 1616 zero by default indicates that the media stream is not wanted. 1618 13.3. Original text of section 8.4 (6th paragraph) of RFC 3264 1620 RFC 2543 [10] specified that placing a user on hold was accomplished 1621 by setting the connection address to 0.0.0.0. Its usage for putting 1622 a call on hold is no longer recommended, since it doesn't allow for 1623 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1624 with connection oriented media. However, it can be useful in an 1625 initial offer when the offerer knows it wants to use a particular set 1626 of media streams and formats, but doesn't know the addresses and 1627 ports at the time of the offer. Of course, when used, the port 1628 number MUST NOT be zero, which would specify that the stream has been 1629 disabled. An agent MUST be capable of receiving SDP with a 1630 connection address of 0.0.0.0, in which case it means that neither 1631 RTP nor RTCP is to be sent to the peer. 1633 13.4. New text replacing section 8.4 (6th paragraph) of RFC 3264 1635 RFC 2543 [10] specified that placing a user on hold was accomplished 1636 by setting the connection address to 0.0.0.0. Its usage for putting 1637 a call on hold is no longer recommended, since it doesn't allow for 1638 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1639 with connection oriented media. However, it can be useful in an 1640 initial offer when the offerer knows it wants to use a particular set 1641 of media streams and formats, but doesn't know the addresses and 1642 ports at the time of the offer. Of course, when used, the port 1643 number MUST NOT be zero, if it would specify that the stream has been 1644 disabled. However, an extension mechanism might specify different 1645 semantics of the zero port number usage. An agent MUST be capable of 1646 receiving SDP with a connection address of 0.0.0.0, in which case it 1647 means that neither RTP nor RTCP is to be sent to the peer. 1649 14. Update to RFC 5888 1651 This section updates RFC 5888 [RFC5888]), in order to allow 1652 extensions to allow an SDP 'group' attribute containing an 1653 identification-tag that identifies a "m=" section with the port set 1654 to zero Section 9.2 (Group Value in Answers) of RFC 5888 is updated. 1656 14.1. Original text of section 9.2 (3rd paragraph) of RFC 5888 1658 SIP entities refuse media streams by setting the port to zero in the 1659 corresponding "m" line. "a=group" lines MUST NOT contain 1660 identification-tags that correspond to "m" lines with the port set to 1661 zero. 1663 14.2. New text replacing section 9.2 (3rd paragraph) of RFC 5888 1665 SIP entities refuse media streams by setting the port to zero in the 1666 corresponding "m" line. "a=group" lines MUST NOT contain 1667 identification-tags that correspond to "m" lines with the port set to 1668 zero, but an extension mechanism might specify different semantics 1669 for including identification-tags that correspond to such "m=" lines. 1671 15. RTP/RTCP extensions for identification-tag transport 1673 SDP Offerers and Answerers [RFC3264] can associate identification- 1674 tags with "m=" sections within SDP Offers and Answers, using the 1675 procedures in [RFC5888]. Each identification-tag uniquely represents 1676 an "m=" section. 1678 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1679 used to carry identification-tags within RTCP SDES packets. This 1680 section also defines a new RTP SDES header extension [RFC7941], which 1681 is used to carry the 'MID' RTCP SDES item in RTP packets. 1683 The SDES item and RTP SDES header extension make it possible for a 1684 receiver to associate each RTP stream with a specific "m=" section, 1685 with which the receiver has associated an identification-tag, even if 1686 those "m=" sections are part of the same RTP session. The RTP SDES 1687 header extension also ensures that the media recipient gets the 1688 identification-tag upon receipt of the first decodable media and is 1689 able to associate the media with the correct application. 1691 A media recipient informs the media sender about the identification- 1692 tag associated with an "m=" section through the use of an 'mid' 1693 attribute [RFC5888]. The media sender then inserts the 1694 identification-tag in RTCP and RTP packets sent to the media 1695 recipient. 1697 NOTE: This text above defines how identification-tags are carried in 1698 SDP Offers and Answers. The usage of other signaling protocols for 1699 carrying identification-tags is not prevented, but the usage of such 1700 protocols is outside the scope of this document. 1702 [RFC3550] defines general procedures regarding the RTCP transmission 1703 interval. The RTCP MID SDES item SHOULD be sent in the first few 1704 RTCP packets sent after joining the session, and SHOULD be sent 1705 regularly thereafter. The exact number of RTCP packets in which this 1706 SDES item is sent is intentionally not specified here, as it will 1707 depend on the expected packet loss rate, the RTCP reporting interval, 1708 and the allowable overhead. 1710 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1711 be included in some RTP packets at the start of the session and 1712 whenever the SSRC changes. It might also be useful to include the 1713 header extension in RTP packets that comprise access points in the 1714 media (e.g., with video I-frames). The exact number of RTP packets 1715 in which this header extension is sent is intentionally not specified 1716 here, as it will depend on expected packet loss rate and loss 1717 patterns, the overhead the application can tolerate, and the 1718 importance of immediate receipt of the identification-tag. 1720 For robustness, endpoints need to be prepared for situations where 1721 the reception of the identification-tag is delayed, and SHOULD NOT 1722 terminate sessions in such cases, as the identification-tag is likely 1723 to arrive soon. 1725 15.1. RTCP MID SDES Item 1727 0 1 2 3 1728 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 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | MID=TBD | length | identification-tag ... 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP. 1735 The identification-tag is not zero terminated. 1737 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1738 identifier value.] 1740 15.2. RTP SDES Header Extension For MID 1742 The payload, containing the identification-tag, of the RTP SDES 1743 header extension element can be encoded using either the one-byte or 1744 two-byte header [RFC7941]. The identification-tag payload is UTF-8 1745 encoded, as in SDP. 1747 The identification-tag is not zero terminated. Note, that the set of 1748 header extensions included in the packet needs to be padded to the 1749 next 32-bit boundary using zero bytes [RFC8285]. 1751 As the identification-tag is included in either an RTCP SDES item or 1752 an RTP SDES header extension, or both, there needs to be some 1753 consideration about the packet expansion caused by the 1754 identification-tag. To avoid Maximum Transmission Unit (MTU) issues 1755 for the RTP packets, the header extension's size needs to be taken 1756 into account when encoding the media. 1758 It is recommended that the identification-tag is kept short. Due to 1759 the properties of the RTP header extension mechanism, when using the 1760 one-byte header, a tag that is 1-3 bytes will result in a minimal 1761 number of 32-bit words used for the RTP SDES header extension, in 1762 case no other header extensions are included at the same time. Note, 1763 do take into account that some single characters when UTF-8 encoded 1764 will result in multiple octets. The identification-tag MUST NOT 1765 contain any user information, and applications SHALL avoid generating 1766 the identification-tag using a pattern that enables user- or 1767 application identification. 1769 16. IANA Considerations 1771 16.1. New SDES item 1773 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1774 document.] 1776 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1777 identifier value.] 1779 This document adds the MID SDES item to the IANA "RTP SDES item 1780 types" registry as follows: 1782 Value: TBD 1783 Abbrev.: MID 1784 Name: Media Identification 1785 Reference: RFCXXXX 1787 16.2. New RTP SDES Header Extension URI 1789 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1790 document.] 1792 This document defines a new extension URI in the RTP SDES Compact 1793 Header Extensions sub-registry of the RTP Compact Header Extensions 1794 registry sub-registry, according to the following data: 1796 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1797 Description: Media identification 1798 Contact: IESG (iesg@ietf.org) 1799 Reference: RFCXXXX 1801 The SDES item does not reveal privacy information about the users. 1802 It is simply used to associate RTP-based media with the correct SDP 1803 media description ("m=" section) in the SDP used to negotiate the 1804 media. 1806 The purpose of the extension is for the offerer to be able to 1807 associate received multiplexed RTP-based media before the offerer 1808 receives the associated SDP answer. 1810 16.3. New SDP Attribute 1812 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1813 document.] 1815 This document defines a new SDP media-level attribute, 'bundle-only', 1816 according to the following data: 1818 Attribute name: bundle-only 1819 Type of attribute: media 1820 Subject to charset: No 1821 Purpose: Request a media description to be accepted 1822 in the answer only if kept within a BUNDLE 1823 group by the answerer. 1824 Appropriate values: N/A 1825 Contact name: IESG 1826 Contact e-mail: iesg@ietf.org 1827 Reference: RFCXXXX 1828 Mux category: NORMAL 1830 16.4. New SDP Group Semantics 1832 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1833 document.] 1835 This document registers the following semantics with IANA in the 1836 "Semantics for the "group" SDP Attribute" subregistry (under the 1837 "Session Description Protocol (SDP) Parameters" registry: 1839 Semantics Token Reference 1840 ------------------------------------- ------ --------- 1841 Media bundling BUNDLE [RFCXXXX] 1843 Mux category: NORMAL 1845 17. Security Considerations 1847 The security considerations defined in [RFC3264] and [RFC5888] apply 1848 to the BUNDLE extension. Bundle does not change which information, 1849 e.g., RTP streams, flows over the network, with the exception of the 1850 usage of the MID SDES item as discussed below. Primarily it changes 1851 which addresses and ports, and thus in which (RTP) sessions the 1852 information is flowing. This affects the security contexts being 1853 used and can cause previously separated information flows to share 1854 the same security context. This has very little impact on the 1855 performance of the security mechanism of the RTP sessions. In cases 1856 where one would have applied different security policies on the 1857 different RTP streams being bundled, or where the parties having 1858 access to the security contexts would have differed between the RTP 1859 streams, additional analysis of the implications are needed before 1860 selecting to apply BUNDLE. 1862 The identification-tag, independent of transport, RTCP SDES packet or 1863 RTP header extension, can expose the value to parties beyond the 1864 signaling chain. Therefore, the identification-tag values MUST be 1865 generated in a fashion that does not leak user information, e.g., 1866 randomly or using a per-bundle group counter, and SHOULD be 3 bytes 1867 or less, to allow them to efficiently fit into the MID RTP header 1868 extension. Note that if implementations use different methods for 1869 generating identification-tags this could enable fingerprinting of 1870 the implementation making it vulnerable to targeted attacks. The 1871 identification-tag is exposed on the RTP stream level when included 1872 in the RTP header extensions, however what it reveals of the RTP 1873 media stream structure of the endpoint and application was already 1874 possible to deduce from the RTP streams without the MID SDES header 1875 extensions. As the identification-tag is also used to route the 1876 media stream to the right application functionality it is important 1877 that the value received is the one intended by the sender, thus 1878 integrity and the authenticity of the source are important to prevent 1879 denial of service on the application. Existing SRTP configurations 1880 and other security mechanisms protecting the whole RTP/RTCP packets 1881 will provide the necessary protection. 1883 When the BUNDLE extension is used, the set of configurations of the 1884 security mechanism used in all the bundled media descriptions will 1885 need to be compatible so that they can be used simultaneously, at 1886 least per direction or endpoint. When using SRTP this will be the 1887 case, at least for the IETF defined key-management solutions due to 1888 their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their 1889 classification in [I-D.ietf-mmusic-sdp-mux-attributes]. 1891 The security considerations of "RTP Header Extension for the RTP 1892 Control Protocol (RTCP) Source Description Items" [RFC7941] requires 1893 that when RTCP is confidentiality protected, then any SDES RTP header 1894 extension carrying an SDES item, such as the MID RTP header 1895 extension, is also protected using commensurate strength algorithms. 1896 However, assuming the above requirements and recommendations are 1897 followed, there are no known significant security risks with leaving 1898 the MID RTP header extension without confidentiality protection. 1899 Therefore, this specification updates RFC 7941 by adding the 1900 exception that this requirement MAY be ignored for the MID RTP header 1901 extension. Security mechanisms for RTP/RTCP are discussed in Options 1902 for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can 1903 provide the necessary security functions of ensuring the integrity 1904 and source authenticity. 1906 18. Examples 1908 18.1. Example: Tagged m= Section Selections 1910 The example below shows: 1912 o An initial BUNDLE offer, in which the offerer wants to negotiate a 1913 BUNDLE group, and indicates the audio m= section as the suggested 1914 offerer tagged "m=" section. 1916 o An initial BUNDLE answer, in which the answerer accepts the 1917 creation of the BUNDLE group, selects the audio m= section in the 1918 offer as the offerer tagged "m=" section, selects the audio "m=" 1919 section in the answer as the answerer tagged "m=" section and 1920 assigns the answerer BUNDLE address:port to that "m=" section. 1922 SDP Offer (1) 1924 v=0 1925 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1926 s= 1927 c=IN IP6 2001:db8::3 1928 t=0 0 1929 a=group:BUNDLE foo bar 1931 m=audio 10000 RTP/AVP 0 8 97 1932 b=AS:200 1933 a=mid:foo 1934 a=rtcp-mux 1935 a=rtpmap:0 PCMU/8000 1936 a=rtpmap:8 PCMA/8000 1937 a=rtpmap:97 iLBC/8000 1938 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1940 m=video 10002 RTP/AVP 31 32 1941 b=AS:1000 1942 a=mid:bar 1943 a=rtcp-mux 1944 a=rtpmap:31 H261/90000 1945 a=rtpmap:32 MPV/90000 1946 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1948 SDP Answer (2) 1950 v=0 1951 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1952 s= 1953 c=IN IP6 2001:db8::1 1954 t=0 0 1955 a=group:BUNDLE foo bar 1957 m=audio 20000 RTP/AVP 0 1958 b=AS:200 1959 a=mid:foo 1960 a=rtcp-mux 1961 a=rtpmap:0 PCMU/8000 1962 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1964 m=video 0 RTP/AVP 32 1965 b=AS:1000 1966 a=mid:bar 1967 a=bundle-only 1968 a=rtpmap:32 MPV/90000 1969 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1971 18.2. Example: BUNDLE Group Rejected 1973 The example below shows: 1975 o An initial BUNDLE offer, in which the offerer wants to negotiate a 1976 BUNDLE group, and indicates the audio m= section as the suggested 1977 offerer tagged "m=" section. 1979 o An initial BUNDLE answer, in which the answerer rejects the 1980 creation of the BUNDLE group, generates a normal answer and 1981 assigns a unique address:port to each "m=" section in the answer. 1983 SDP Offer (1) 1985 v=0 1986 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1987 s= 1988 c=IN IP6 2001:db8::3 1989 t=0 0 1990 a=group:BUNDLE foo bar 1992 m=audio 10000 RTP/AVP 0 8 97 1993 b=AS:200 1994 a=mid:foo 1995 a=rtcp-mux 1996 a=rtpmap:0 PCMU/8000 1997 a=rtpmap:8 PCMA/8000 1998 a=rtpmap:97 iLBC/8000 1999 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2001 m=video 10002 RTP/AVP 31 32 2002 b=AS:1000 2003 a=mid:bar 2004 a=rtcp-mux 2005 a=rtpmap:31 H261/90000 2006 a=rtpmap:32 MPV/90000 2007 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2009 SDP Answer (2) 2011 v=0 2012 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2013 s= 2014 c=IN IP6 2001:db8::1 2015 t=0 0 2017 m=audio 20000 RTP/AVP 0 2018 b=AS:200 2019 a=rtcp-mux 2020 a=rtpmap:0 PCMU/8000 2022 m=video 30000 RTP/AVP 32 2023 b=AS:1000 2024 a=rtcp-mux 2025 a=rtpmap:32 MPV/90000 2027 18.3. Example: Offerer Adds a Media Description to a BUNDLE Group 2029 The example below shows: 2031 o A subsequent offer, in which the offerer adds a new bundled "m=" 2032 section (video), indicated by the "zen" identification-tag, to a 2033 previously negotiated BUNDLE group, indicates the new "m=" section 2034 as the offerer tagged "m=" section and assigns the offerer BUNDLE 2035 address:port to that "m=" section. 2037 o A subsequent answer, in which the answerer indicates the new video 2038 "m=" section in the answer as the answerer tagged "m=" section and 2039 assigns the answerer BUNDLE address:port to that "m=" section. 2041 SDP Offer (1) 2043 v=0 2044 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2045 s= 2046 c=IN IP6 2001:db8::3 2047 t=0 0 2048 a=group:BUNDLE zen foo bar 2050 m=audio 0 RTP/AVP 0 8 97 2051 b=AS:200 2052 a=mid:foo 2053 a=bundle-only 2054 a=rtpmap:0 PCMU/8000 2055 a=rtpmap:8 PCMA/8000 2056 a=rtpmap:97 iLBC/8000 2057 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2059 m=video 0 RTP/AVP 31 32 2060 b=AS:1000 2061 a=mid:bar 2062 a=bundle-only 2063 a=rtpmap:31 H261/90000 2064 a=rtpmap:32 MPV/90000 2065 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2067 m=video 10000 RTP/AVP 66 2068 b=AS:1000 2069 a=mid:zen 2070 a=rtcp-mux 2071 a=rtpmap:66 H261/90000 2072 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2074 SDP Answer (2) 2076 v=0 2077 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2078 s= 2079 c=IN IP6 2001:db8::1 2080 t=0 0 2081 a=group:BUNDLE zen foo bar 2083 m=audio 0 RTP/AVP 0 2084 b=AS:200 2085 a=mid:foo 2086 a=bundle-only 2087 a=rtpmap:0 PCMU/8000 2088 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2090 m=video 0 RTP/AVP 32 2091 b=AS:1000 2092 a=mid:bar 2093 a=bundle-only 2094 a=rtpmap:32 MPV/90000 2095 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2097 m=video 20000 RTP/AVP 66 2098 b=AS:1000 2099 a=mid:zen 2100 a=rtcp-mux 2101 a=rtpmap:66 H261/90000 2102 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2104 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 2106 The example below shows: 2108 o A subsequent offer, in which the offerer removes a "m=" section 2109 (video), indicated by the "zen" identification-tag, from a 2110 previously negotiated BUNDLE group, indicates one of the bundled 2111 "m=" sections (audio) remaining in the BUNDLE group as the offerer 2112 tagged "m=" section and assigns the offerer BUNDLE address:port to 2113 that "m=" section. 2115 o A subsequent answer, in which the answerer removes the "m=" 2116 section from the BUNDLE group, indicates the audio "m=" section in 2117 the answer as the answerer tagged "m=" section and assigns the 2118 answerer BUNDLE address:port to that "m=" section. 2120 SDP Offer (1) 2122 v=0 2123 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2124 s= 2125 c=IN IP6 2001:db8::3 2126 t=0 0 2127 a=group:BUNDLE foo bar 2129 m=audio 10000 RTP/AVP 0 8 97 2130 b=AS:200 2131 a=mid:foo 2132 a=rtcp-mux 2133 a=rtpmap:0 PCMU/8000 2134 a=rtpmap:8 PCMA/8000 2135 a=rtpmap:97 iLBC/8000 2136 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2138 m=video 0 RTP/AVP 31 32 2139 b=AS:1000 2140 a=mid:bar 2141 a=bundle-only 2142 a=rtpmap:31 H261/90000 2143 a=rtpmap:32 MPV/90000 2144 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2146 m=video 50000 RTP/AVP 66 2147 b=AS:1000 2148 a=mid:zen 2149 a=rtcp-mux 2150 a=rtpmap:66 H261/90000 2152 SDP Answer (2) 2154 v=0 2155 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2156 s= 2157 c=IN IP6 2001:db8::1 2158 t=0 0 2159 a=group:BUNDLE foo bar 2161 m=audio 20000 RTP/AVP 0 2162 b=AS:200 2163 a=mid:foo 2164 a=rtcp-mux 2165 a=rtpmap:0 PCMU/8000 2166 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2167 m=video 0 RTP/AVP 32 2168 b=AS:1000 2169 a=mid:bar 2170 a=bundle-only 2171 a=rtpmap:32 MPV/90000 2172 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2174 m=video 60000 RTP/AVP 66 2175 b=AS:1000 2176 a=mid:zen 2177 a=rtcp-mux 2178 a=rtpmap:66 H261/90000 2180 18.5. Example: Offerer Disables a Media Description Within a BUNDLE 2181 Group 2183 The example below shows: 2185 o A subsequent offer, in which the offerer disables (by assigning a 2186 zero port value) a "m=" section (video), indicated by the "zen" 2187 identification-tag, from a previously negotiated BUNDLE group, 2188 indicates one of the bundled "m=" sections (audio) remaining 2189 active in the BUNDLE group as the offerer tagged "m=" section and 2190 assigns the offerer BUNDLE address:port to that "m=" section. 2192 o A subsequent answer, in which the answerer disables the "m=" 2193 section, indicates the audio "m=" section in the answer as the 2194 answerer tagged "m=" section and assigns the answerer BUNDLE 2195 address:port to that "m=" section. 2197 SDP Offer (1) 2199 v=0 2200 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2201 s= 2202 t=0 0 2203 a=group:BUNDLE foo bar 2205 m=audio 10000 RTP/AVP 0 8 97 2206 c=IN IP6 2001:db8::3 2207 b=AS:200 2208 a=mid:foo 2209 a=rtcp-mux 2210 a=rtpmap:0 PCMU/8000 2211 a=rtpmap:8 PCMA/8000 2212 a=rtpmap:97 iLBC/8000 2213 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2215 m=video 0 RTP/AVP 31 32 2216 c=IN IP6 2001:db8::3 2217 b=AS:1000 2218 a=mid:bar 2219 a=bundle-only 2220 a=rtpmap:31 H261/90000 2221 a=rtpmap:32 MPV/90000 2222 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2224 m=video 0 RTP/AVP 66 2225 a=mid:zen 2226 a=rtpmap:66 H261/90000 2228 SDP Answer (2) 2230 v=0 2231 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2232 s= 2233 t=0 0 2234 a=group:BUNDLE foo bar 2236 m=audio 20000 RTP/AVP 0 2237 c=IN IP6 2001:db8::1 2238 b=AS:200 2239 a=mid:foo 2240 a=rtcp-mux 2241 a=rtpmap:0 PCMU/8000 2242 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2244 m=video 0 RTP/AVP 32 2245 c=IN IP6 2001:db8::1 2246 b=AS:1000 2247 a=mid:bar 2248 a=bundle-only 2249 a=rtpmap:32 MPV/90000 2250 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2252 m=video 0 RTP/AVP 66 2253 a=mid:zen 2254 a=rtpmap:66 H261/90000 2256 19. Acknowledgements 2258 The usage of the SDP grouping extension for negotiating bundled media 2259 is based on similar alternatives proposed by Harald Alvestrand and 2260 Cullen Jennings. The BUNDLE extension described in this document is 2261 based on the different alternative proposals, and text (e.g., SDP 2262 examples) have been borrowed (and, in some cases, modified) from 2263 those alternative proposals. 2265 The SDP examples are also modified versions from the ones in the 2266 Alvestrand proposal. 2268 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 2269 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 2270 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin 2271 Uberti, Taylor Brandstetter, Byron Campen and Eric Rescorla for 2272 reading the text, and providing useful feedback. 2274 Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus 2275 Westerlund for providing the text for the section on RTP/RTCP stream 2276 association. 2278 Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for 2279 providing help and text on the RTP/RTCP procedures. 2281 Thanks to Charlie Kaufman for performing the Sec-Dir review. 2283 Thanks to Linda Dunbar for performing the Gen-ART review. 2285 Thanks to Spotify for providing music for the countless hours of 2286 document editing. 2288 20. Change Log 2290 [RFC EDITOR NOTE: Please remove this section when publishing] 2292 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-51 2294 o Changes based on IESG reviews. 2296 o - Clarification of 'initial offer' terminology. 2298 o - Merging of tagged m- section selection sections. 2300 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-50 2302 o Changes based on IESG reviews. 2304 o - Adding of tagged m- section concept. 2306 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-49 2308 o Changes based on IESG reviews. 2310 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-48 2312 o Changes based on Sec-Dir review by Charlie Kaufman. 2314 o - s/unique address/unique address:port 2316 o Changes based on Gen-ART review by Linda Dunbar. 2318 o Mux category for group:BUNDLE attribute added. 2320 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-47 2322 o Changes based on AD review by Ben Campbell. 2324 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-46 2326 o Pre-RFC5378 disclaimer removed put back. 2328 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-45 2330 o Mux category for SDP 'group:BUNDLE' attribute added. 2332 o https://github.com/cdh4u/draft-sdp-bundle/pull/54 2334 o Pre-RFC5378 disclaimer removed. 2336 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-44 2338 o Minor editorial nits based on pull request by Colin P. 2340 o https://github.com/cdh4u/draft-sdp-bundle/pull/53 2342 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-43 2344 o Changes based on WG chairs review. 2346 o Text added in order to close GitHub issues by Taylor B. 2348 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-42 2350 o Changes based on final WG review. 2352 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-41 2354 o Update to section 6 o RFC 3264: 2356 o https://github.com/cdh4u/draft-sdp-bundle/pull/47 2358 o Editorial clarification on BUNDLE address selection: 2360 o https://github.com/cdh4u/draft-sdp-bundle/pull/46 2362 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40 2364 o Editorial changes and technical restrictions in order to make the 2365 specification more understandable: 2367 o https://github.com/cdh4u/draft-sdp-bundle/pull/45 2369 o - BUNDLE address is only assigned to m- section indicated by 2370 BUNDLE-tag. 2372 o - bundle-only attribute also used in answers and subsequent 2373 offers. 2375 o - Answerer cannot reject, or remove, the bundled m- section that 2376 contains the BUNDLE address. 2378 o - ICE Offer/Answer sections removed, due to duplicated 2379 information. 2381 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39 2383 o Editorial terminology changes. 2385 o RFC 5285 reference replaced by reference to RFC 8285. 2387 o https://github.com/cdh4u/draft-sdp-bundle/pull/44 2389 o - Clarify that an m- section can not be moved between BUNDLE 2390 groups without first moving the m- section out of a BUNDLE group. 2392 o https://github.com/cdh4u/draft-sdp-bundle/pull/41 2394 o - Addition of BUNDLE transport concept. 2396 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38 2398 o Changes to RTP streaming mapping section based on text from Colin 2399 Perkins. 2401 o The following GitHub pull requests were merged: 2403 o https://github.com/cdh4u/draft-sdp-bundle/pull/34 2405 o - Proposed updates to RTP processing 2407 o https://github.com/cdh4u/draft-sdp-bundle/pull/35 2409 o - fixed reference to receiver-id section 2411 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-37 2413 o The following GitHub pull request was merged: 2415 o https://github.com/cdh4u/draft-sdp-bundle/pull/33 2417 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36 2419 o The following GitHub pull requests were merged: 2421 o https://github.com/cdh4u/draft-sdp-bundle/pull/32 2423 o - extmap handling in BUNDLE. 2425 o https://github.com/cdh4u/draft-sdp-bundle/pull/31 2427 o - Additional Acknowledgement text added. 2429 o https://github.com/cdh4u/draft-sdp-bundle/pull/30 2431 o - MID SDES item security procedures updated 2433 o https://github.com/cdh4u/draft-sdp-bundle/pull/29 2435 o - Appendix B of JSEP moved into BUNDLE. 2437 o - Associating RTP/RTCP packets with SDP m- lines. 2439 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35 2441 o Editorial changes on RTP streaming mapping section based on 2442 comments from Colin Perkins. 2444 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34 2446 o RTP streams, instead of RTP packets, are associated with m- lines. 2448 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 2449 o Editorial changes based on comments from Eric Rescorla and Cullen 2450 Jennings: 2452 o - Changes regarding usage of RTP/RTCP multiplexing attributes. 2454 o - Additional text regarding associating RTP/RTCP packets with SDP 2455 m- lines. 2457 o - Reference correction. 2459 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32 2461 o Editorial changes based on comments from Eric Rescorla and Cullen 2462 Jennings: 2464 o - Justification for mechanism added to Introduction. 2466 o - Clarify that the order of m- lines in the group:BUNDLE attribute 2467 does not have to be the same as the order in which the m- lines 2468 are listed in the SDP. 2470 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31 2472 o Editorial changes based on GitHub Pull requests by Martin Thomson: 2474 o - https://github.com/cdh4u/draft-sdp-bundle/pull/2 2476 o - https://github.com/cdh4u/draft-sdp-bundle/pull/1 2478 o Editorial change based on comment from Diederick Huijbers (9th 2479 July 2016). 2481 o Changes based on comments from Flemming Andreasen (21st June 2482 2016): 2484 o - Mux category for SDP bundle-only attribute added. 2486 o - Mux category considerations editorial clarification. 2488 o - Editorial changes. 2490 o RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext. 2492 o Note whether Design Considerations appendix is to be kept removed: 2494 o - Appendix is kept within document. 2496 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30 2497 o Indicating in the Abstract and Introduction that the document 2498 updates RFC 3264. 2500 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29 2502 o Change based on WGLC comment from Colin Perkins. 2504 o - Clarify that SSRC can be reused by another source after a delay 2505 of 5 RTCP reporting intervals. 2507 o Change based on WGLC comment from Alissa Cooper. 2509 o - IANA registry name fix. 2511 o - Additional IANA registration information added. 2513 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28 2515 o - Alignment with exclusive mux procedures. 2517 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 2519 o - Yet another terminology change. 2521 o - Mux category considerations added. 2523 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 2525 o - ICE considerations modified: ICE-related SDP attributes only 2526 added to the bundled m- line representing the selected BUNDLE 2527 address. 2529 o - Reference to draft-ietf-mmusic-ice-sip-sdp added. 2531 o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- 2532 rfc5245bis. 2534 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 2536 o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux 2537 considerations. 2539 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 2541 o - Reference and procedures associated with exclusive RTP/RTCP mux 2542 added 2544 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 2545 o - RTCP-MUX mandatory for bundled RTP m- lines 2547 o - Editorial fixes based on comments from Flemming Andreasen 2549 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 2551 o - Correction of Ari's family name 2553 o - Editorial fixes based on comments from Thomas Stach 2555 o - RTP/RTCP correction based on comment from Magnus Westerlund 2557 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2558 msg14861.html 2560 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 2562 o - Correct based on comment from Paul Kyzivat 2564 o -- 'received packets' replaced with 'received data' 2566 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 2568 o - Clarification based on comment from James Guballa 2570 o - Clarification based on comment from Flemming Andreasen 2572 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 2574 o - DTLS Considerations section added. 2576 o - BUNDLE semantics added to the IANA Considerations 2578 o - Changes based on WGLC comments from Adam Roach 2580 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2581 msg14673.html 2583 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 2585 o - Changes based on agreements at IETF#92 2587 o -- BAS Offer removed, based on agreement at IETF#92. 2589 o -- Procedures regarding usage of SDP "b=" line is replaced with a 2590 reference to to draft-ietf-mmusic-sdp-mux-attributes. 2592 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 2593 o - Editorial changes based on comments from Magnus Westerlund. 2595 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 2597 o - Modification of RTP/RTCP multiplexing section, based on comments 2598 from Magnus Westerlund. 2600 o - Reference updates. 2602 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 2604 o - Editorial fix. 2606 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 2608 o - Editorial changes. 2610 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 2612 o Changes to allow a newly suggested offerer BUNDLE address to be 2613 assigned to each bundled m- line. 2615 o Changes based on WGLC comments from Paul Kyzivat 2617 o - Editorial fixes 2619 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 2621 o Usage of SDP 'extmap' attribute added 2623 o SDP 'bundle-only' attribute scoped with "m=" lines with a zero 2624 port value 2626 o Changes based on WGLC comments from Thomas Stach 2628 o - ICE candidates not assigned to bundle-only m- lines with a zero 2629 port value 2631 o - Editorial changes 2633 o Changes based on WGLC comments from Colin Perkins 2635 o - Editorial changes: 2637 o -- "RTP SDES item" -> "RTCP SDES item" 2639 o -- "RTP MID SDES item" -> "RTCP MID SDES item" 2640 o - Changes in section 10.1.1: 2642 o -- "SHOULD NOT" -> "MUST NOT" 2644 o -- Additional text added to the Note 2646 o - Change to section 13.2: 2648 o -- Clarify that mid value is not zero terminated 2650 o - Change to section 13.3: 2652 o -- Clarify that mid value is not zero terminated 2654 o -- Clarify padding 2656 o Changes based on WGLC comments from Paul Kyzivat 2658 o - Editorial changes: 2660 o Changes based on WGLC comments from Jonathan Lennox 2662 o - Editorial changes: 2664 o - Defintion of SDP bundle-only attribute alligned with structure 2665 in 4566bis draft 2667 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 2669 o Editorial corrections based on comments from Harald Alvestrand. 2671 o Editorial corrections based on comments from Cullen Jennings. 2673 o Reference update (RFC 7160). 2675 o Clarification about RTCP packet sending when RTP/RTCP multiplexing 2676 is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ 2677 msg13765.html). 2679 o Additional text added to the Security Considerations. 2681 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 2683 o SDP bundle-only attribute added to IANA Considerations. 2685 o SDES item and RTP header extension added to Abstract and 2686 Introduction. 2688 o Modification to text updating section 8.2 of RFC 3264. 2690 o Reference corrections. 2692 o Editorial corrections. 2694 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 2696 o Terminology change: "bundle-only attribute assigned to m= line" to 2697 "bundle-only attribute associated with m= line". 2699 o Editorial corrections. 2701 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 2703 o Editorial corrections. 2705 o - "of"->"if" (8.3.2.5). 2707 o - "optional"->"OPTIONAL" (9.1). 2709 o - Syntax/ABNF for 'bundle-only' attribute added. 2711 o - SDP Offer/Answer sections merged. 2713 o - 'Request new offerer BUNDLE address' section added 2715 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 2717 o OPEN ISSUE regarding Receiver-ID closed. 2719 o - RTP MID SDES Item. 2721 o - RTP MID Header Extension. 2723 o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers 2724 closed. 2726 o - Indicating that, when rtcp-mux is used, the answerer MUST NOT 2727 include an 'rtcp' attribute in the answer, based on the procedures 2728 in section 5.1.3 of RFC 5761. 2730 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 2732 o Draft title changed. 2734 o Added "SDP" to section names containing "Offer" or "Answer". 2736 o Editorial fixes based on comments from Paul Kyzivat 2737 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2738 msg13314.html). 2740 o Editorial fixed based on comments from Colin Perkins 2741 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2742 msg13318.html). 2744 o - Removed text about extending BUNDLE to allow multiple RTP 2745 sessions within a BUNDLE group. 2747 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 2749 o Major re-structure of SDP Offer/Answer sections, to align with RFC 2750 3264 structure. 2752 o Additional definitions added. 2754 o - Shared address. 2756 o - Bundled "m=" line. 2758 o - Bundle-only "m=" line. 2760 o - Offerer suggested BUNDLE mid. 2762 o - Answerer selected BUNDLE mid. 2764 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 2765 to multiple "m=" lines until it has received an SDP Answer 2766 indicating support of the BUNDLE extension. 2768 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 2769 Answerer supports the BUNDLE extension, assign a zero port value 2770 to a 'bundle-only' "m=" line. 2772 o SDP 'bundle-only' attribute section added. 2774 o Connection data nettype/addrtype restrictions added. 2776 o RFC 3264 update section added. 2778 o Indicating that a specific payload type value can be used in 2779 multiple "m=" lines, if the value represents the same codec 2780 configuration in each "m=" line. 2782 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 2783 o Updated Offerer procedures (http://www.ietf.org/mail- 2784 archive/web/mmusic/current/msg12293.html). 2786 o Updated Answerer procedures (http://www.ietf.org/mail- 2787 archive/web/mmusic/current/msg12333.html). 2789 o Usage of SDP 'bundle-only' attribute added. 2791 o Reference to Trickle ICE document added. 2793 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 2795 o Mechanism modified, to be based on usage of SDP Offers with both 2796 different and identical port number values, depending on whether 2797 it is known if the remote endpoint supports the extension. 2799 o Cullen Jennings added as co-author. 2801 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 2803 o No changes. New version due to expiration. 2805 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 2807 o No changes. New version due to expiration. 2809 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 2811 o Draft name changed. 2813 o Harald Alvestrand added as co-author. 2815 o "Multiplex" terminology changed to "bundle". 2817 o Added text about single versus multiple RTP Sessions. 2819 o Added reference to RFC 3550. 2821 21. References 2823 21.1. Normative References 2825 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2826 Requirement Levels", BCP 14, RFC 2119, 2827 DOI 10.17487/RFC2119, March 1997, . 2830 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2831 with Session Description Protocol (SDP)", RFC 3264, 2832 DOI 10.17487/RFC3264, June 2002, . 2835 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2836 Jacobson, "RTP: A Transport Protocol for Real-Time 2837 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2838 July 2003, . 2840 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2841 in Session Description Protocol (SDP)", RFC 3605, 2842 DOI 10.17487/RFC3605, October 2003, . 2845 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2846 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2847 2003, . 2849 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2850 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2851 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2852 . 2854 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2855 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2856 July 2006, . 2858 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2859 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2860 . 2862 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2863 Control Packets on a Single Port", RFC 5761, 2864 DOI 10.17487/RFC5761, April 2010, . 2867 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2868 Security (DTLS) Extension to Establish Keys for the Secure 2869 Real-time Transport Protocol (SRTP)", RFC 5764, 2870 DOI 10.17487/RFC5764, May 2010, . 2873 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2874 Protocol (SDP) Grouping Framework", RFC 5888, 2875 DOI 10.17487/RFC5888, June 2010, . 2878 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2879 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2880 January 2012, . 2882 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2883 Header Extension for the RTP Control Protocol (RTCP) 2884 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2885 August 2016, . 2887 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2888 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2889 May 2017, . 2891 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 2892 Mechanism for RTP Header Extensions", RFC 8285, 2893 DOI 10.17487/RFC8285, October 2017, . 2896 [I-D.ietf-ice-rfc5245bis] 2897 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2898 Connectivity Establishment (ICE): A Protocol for Network 2899 Address Translator (NAT) Traversal", draft-ietf-ice- 2900 rfc5245bis-20 (work in progress), March 2018. 2902 [I-D.ietf-mmusic-sdp-mux-attributes] 2903 Nandakumar, S., "A Framework for SDP Attributes when 2904 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 2905 (work in progress), December 2016. 2907 [I-D.ietf-mmusic-mux-exclusive] 2908 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 2909 Multiplexing using SDP", draft-ietf-mmusic-mux- 2910 exclusive-12 (work in progress), May 2017. 2912 [I-D.ietf-mmusic-ice-sip-sdp] 2913 Petit-Huguenin, M., Nandakumar, S., and A. Keranen, 2914 "Session Description Protocol (SDP) Offer/Answer 2915 procedures for Interactive Connectivity Establishment 2916 (ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in 2917 progress), April 2018. 2919 [I-D.ietf-mmusic-trickle-ice-sip] 2920 Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 2921 Session Initiation Protocol (SIP) Usage for Trickle ICE", 2922 draft-ietf-mmusic-trickle-ice-sip-14 (work in progress), 2923 February 2018. 2925 21.2. Informative References 2927 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2928 A., Peterson, J., Sparks, R., Handley, M., and E. 2929 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2930 DOI 10.17487/RFC3261, June 2002, . 2933 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2934 "RTP Control Protocol Extended Reports (RTCP XR)", 2935 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2936 . 2938 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2939 "Codec Control Messages in the RTP Audio-Visual Profile 2940 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 2941 February 2008, . 2943 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2944 "Extended RTP Profile for Real-time Transport Control 2945 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2946 DOI 10.17487/RFC4585, July 2006, . 2949 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2950 Media Attributes in the Session Description Protocol 2951 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2952 . 2954 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2955 Clock Rates in an RTP Session", RFC 7160, 2956 DOI 10.17487/RFC7160, April 2014, . 2959 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2960 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2961 . 2963 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2964 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2965 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2966 DOI 10.17487/RFC7656, November 2015, . 2969 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 2970 (Diffserv) and Real-Time Communication", RFC 7657, 2971 DOI 10.17487/RFC7657, November 2015, . 2974 [I-D.ietf-ice-trickle] 2975 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 2976 "Trickle ICE: Incremental Provisioning of Candidates for 2977 the Interactive Connectivity Establishment (ICE) 2978 Protocol", draft-ietf-ice-trickle-21 (work in progress), 2979 April 2018. 2981 [I-D.ietf-avtext-lrr] 2982 Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 2983 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 2984 Message", draft-ietf-avtext-lrr-07 (work in progress), 2985 July 2017. 2987 Appendix A. Design Considerations 2989 One of the main issues regarding the BUNDLE grouping extensions has 2990 been whether, in SDP Offers and SDP Answers, the same port value can 2991 be inserted in "m=" lines associated with a BUNDLE group, as the 2992 purpose of the extension is to negotiate the usage of a single 2993 transport for media specified by the "m=" sections. Issues with both 2994 approaches, discussed in the Appendix have been raised. The outcome 2995 was to specify a mechanism which uses SDP Offers with both different 2996 and identical port values. 2998 Below are the primary issues that have been considered when defining 2999 the "BUNDLE" grouping extension: 3001 o 1) Interoperability with existing UAs. 3003 o 2) Interoperability with intermediary Back to Back User Agent 3004 (B2BUA) and proxy entities. 3006 o 3) Time to gather, and the number of, ICE candidates. 3008 o 4) Different error scenarios, and when they occur. 3010 o 5) SDP Offer/Answer impacts, including usage of port number value 3011 zero. 3013 A.1. UA Interoperability 3015 Consider the following SDP Offer/Answer exchange, where Alice sends 3016 an SDP Offer to Bob: 3018 SDP Offer 3020 v=0 3021 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 3022 s= 3023 c=IN IP4 atlanta.example.com 3024 t=0 0 3026 m=audio 10000 RTP/AVP 97 3027 a=rtpmap:97 iLBC/8000 3028 m=video 10002 RTP/AVP 97 3029 a=rtpmap:97 H261/90000 3031 SDP Answer 3033 v=0 3034 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 3035 s= 3036 c=IN IP4 biloxi.example.com 3037 t=0 0 3039 m=audio 20000 RTP/AVP 97 3040 a=rtpmap:97 iLBC/8000 3041 m=video 20002 RTP/AVP 97 3042 a=rtpmap:97 H261/90000 3044 RFC 4961 specifies a way of doing symmetric RTP but that is a later 3045 extension to RTP and Bob can not assume that Alice supports RFC 4961. 3046 This means that Alice may be sending RTP from a different port than 3047 10000 or 10002 - some implementations simply send the RTP from an 3048 ephemeral port. When Bob's endpoint receives an RTP packet, the only 3049 way that Bob knows if the packet is to be passed to the video or 3050 audio codec is by looking at the port it was received on. This led 3051 some SDP implementations to use the fact that each "m=" section had a 3052 different port number to use that port number as an index to find the 3053 correct m line in the SDP. As a result, some implementations that do 3054 support symmetric RTP and ICE still use an SDP data structure where 3055 SDP with "m=" sections with the same port such as: 3057 SDP Offer 3059 v=0 3060 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 3061 s= 3062 c=IN IP4 atlanta.example.com 3063 t=0 0 3065 m=audio 10000 RTP/AVP 97 3066 a=rtpmap:97 iLBC/8000 3067 m=video 10000 RTP/AVP 98 3068 a=rtpmap:98 H261/90000 3070 will result in the second "m=" section being considered an SDP error 3071 because it has the same port as the first line. 3073 A.2. Usage of Port Number Value Zero 3075 In an SDP Offer or SDP Answer, the media specified by an "m=" section 3076 can be disabled/rejected by setting the port number value to zero. 3077 This is different from e.g., using the SDP direction attributes, 3078 where RTCP traffic will continue even if the SDP "inactive" attribute 3079 is indicated for the associated "m=" section. 3081 If each "m=" section associated with a BUNDLE group would contain 3082 different port values, and one of those port values would be used for 3083 a BUNDLE address:port associated with the BUNDLE group, problems 3084 would occur if an endpoint wants to disable/reject the "m=" section 3085 associated with that port, by setting the port value to zero. After 3086 that, no "m=" section would contain the port value which is used for 3087 the BUNDLE address:port. In addition, it is unclear what would 3088 happen to the ICE candidates associated with the "m=" section, as 3089 they are also used for the BUNDLE address:port. 3091 A.3. B2BUA And Proxy Interoperability 3093 Some back to back user agents may be configured in a mode where if 3094 the incoming call leg contains an SDP attribute the B2BUA does not 3095 understand, the B2BUA still generates that SDP attribute in the Offer 3096 for the outgoing call leg. Consider a B2BUA that did not understand 3097 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 3098 Further assume that the B2BUA was configured to tear down any call 3099 where it did not see any RTCP for 5 minutes. In this case, if the 3100 B2BUA received an Offer like: 3102 SDP Offer 3104 v=0 3105 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 3106 s= 3107 c=IN IP4 atlanta.example.com 3108 t=0 0 3110 m=audio 49170 RTP/AVP 0 3111 a=rtcp:53020 3113 It would be looking for RTCP on port 49171 but would not see any 3114 because the RTCP would be on port 53020 and after five minutes, it 3115 would tear down the call. Similarly, a B2BUA that did not understand 3116 BUNDLE yet put BUNDLE in its offer may be looking for media on the 3117 wrong port and tear down the call. It is worth noting that a B2BUA 3118 that generated an Offer with capabilities it does not understand is 3119 not compliant with the specifications. 3121 A.3.1. Traffic Policing 3123 Sometimes intermediaries do not act as B2BUAs, in the sense that they 3124 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 3125 however, they may use SDP information (e.g., IP address and port) in 3126 order to control traffic gating functions, and to set traffic 3127 policing rules. There might be rules which will trigger a session to 3128 be terminated in case media is not sent or received on the ports 3129 retrieved from the SDP. This typically occurs once the session is 3130 already established and ongoing. 3132 A.3.2. Bandwidth Allocation 3134 Sometimes intermediaries do not act as B2BUAs, in the sense that they 3135 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 3136 however, they may use SDP information (e.g., codecs and media types) 3137 in order to control bandwidth allocation functions. The bandwidth 3138 allocation is done per "m=" section, which means that it might not be 3139 enough if media specified by all "m=" sections try to use that 3140 bandwidth. That may either simply lead to bad user experience, or to 3141 termination of the call. 3143 A.4. Candidate Gathering 3145 When using ICE, a candidate needs to be gathered for each port. This 3146 takes approximately 20 ms extra for each extra "m=" section due to 3147 the NAT pacing requirements. All of this gathering can be overlapped 3148 with other things while e.g., a web-page is loading to minimize the 3149 impact. If the client only wants to generate TURN or STUN ICE 3150 candidates for one of the "m=" lines and then use trickle ICE 3151 [I-D.ietf-ice-trickle] to get the non host ICE candidates for the 3152 rest of the "m=" sections, it MAY do that and will not need any 3153 additional gathering time. 3155 Some people have suggested a TURN extension to get a bunch of TURN 3156 allocations at once. This would only provide a single STUN result so 3157 in cases where the other end did not support BUNDLE, it may cause 3158 more use of the TURN server but would be quick in the cases where 3159 both sides supported BUNDLE and would fall back to a successful call 3160 in the other cases. 3162 Authors' Addresses 3164 Christer Holmberg 3165 Ericsson 3166 Hirsalantie 11 3167 Jorvas 02420 3168 Finland 3170 Email: christer.holmberg@ericsson.com 3172 Harald Tveit Alvestrand 3173 Google 3174 Kungsbron 2 3175 Stockholm 11122 3176 Sweden 3178 Email: harald@alvestrand.no 3180 Cullen Jennings 3181 Cisco 3182 400 3rd Avenue SW, Suite 350 3183 Calgary, AB T2P 4H2 3184 Canada 3186 Email: fluffy@iii.ca