idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-53.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 (September 20, 2018) is 2043 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 1628 == Missing Reference: 'RFCXXXX' is mentioned on line 1812, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-17 == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-21 Summary: 2 errors (**), 0 flaws (~~), 4 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,7941 (if approved) H. Alvestrand 5 Intended status: Standards Track Google 6 Expires: March 24, 2019 C. Jennings 7 Cisco 8 September 20, 2018 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-53.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 defines a new RTP Control Protocol (RTCP) source 30 description (SDES) item and a new RTP header extension that can be 31 used to correlate bundled RTP/RTCP packets with their appropriate 32 "m=" section. 34 This specification updates RFC 7941, by adding an exception, for the 35 MID RTP header extension, to the requirement regarding protection of 36 an SDES RTP header extension carrying an SDES item for the MID RTP 37 header extension. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on March 24, 2019. 56 Copyright Notice 58 Copyright (c) 2018 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 This document may contain material from IETF Documents or IETF 72 Contributions published or made publicly available before November 73 10, 2008. The person(s) controlling the copyright in some of this 74 material may not have granted the IETF Trust the right to allow 75 modifications of such material outside the IETF Standards Process. 76 Without obtaining an adequate license from the person(s) controlling 77 the copyright in such materials, this document may not be modified 78 outside the IETF Standards Process, and derivative works of it may 79 not be created outside the IETF Standards Process, except to format 80 it for publication as an RFC or to translate it into languages other 81 than English. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 86 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 87 1.2. BUNDLE Mechanism . . . . . . . . . . . . . . . . . . . . 4 88 1.3. Protocol Extensions . . . . . . . . . . . . . . . . . . . 5 89 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 90 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 91 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 92 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 8 93 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 9 94 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 95 7.1. Generic SDP Considerations . . . . . . . . . . . . . . . 10 96 7.1.1. Connection Data (c=) . . . . . . . . . . . . . . . . 10 97 7.1.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . 11 98 7.1.3. Attributes (a=) . . . . . . . . . . . . . . . . . . . 11 99 7.2. Generating the Initial SDP Offer . . . . . . . . . . . . 12 100 7.2.1. Suggesting the Offerer tagged 'm=' section . . . . . 13 101 7.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 13 102 7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 14 103 7.3.1. Answerer Selection of tagged 'm=' sections . . . . . 16 104 7.3.2. Moving A Media Description Out Of A BUNDLE Group . . 16 105 7.3.3. Rejecting a Media Description in a BUNDLE Group . . . 17 106 7.3.4. Example: SDP Answer . . . . . . . . . . . . . . . . . 18 107 7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 19 108 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 19 109 7.5.1. Adding a Media Description to a BUNDLE group . . . . 20 110 7.5.2. Moving a Media Description Out of a BUNDLE Group . . 21 111 7.5.3. Disabling a Media Description in a BUNDLE Group . . . 21 112 8. Protocol Identification . . . . . . . . . . . . . . . . . . . 22 113 8.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 22 114 9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 23 115 9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 23 116 9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 24 117 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 118 Description . . . . . . . . . . . . . . . . . . . . . . . 24 119 9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 30 120 9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 30 121 10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 32 122 11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 33 123 12. RTP Header Extensions Consideration . . . . . . . . . . . . . 34 124 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 34 125 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 34 126 13.2. New text replacing section 5.1 (2nd paragraph) of RFC 127 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 128 13.3. Original text of section 8.4 (6th paragraph) of RFC 3264 35 129 13.4. New text replacing section 8.4 (6th paragraph) of RFC 130 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 131 14. RTP/RTCP extensions for identification-tag transport . . . . 36 132 14.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 37 133 14.2. RTP SDES Header Extension For MID . . . . . . . . . . . 37 134 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 135 15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 38 136 15.2. New RTP SDES Header Extension URI . . . . . . . . . . . 38 137 15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 39 138 15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 39 139 16. Security Considerations . . . . . . . . . . . . . . . . . . . 40 140 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41 141 17.1. Example: Tagged m= Section Selections . . . . . . . . . 41 142 17.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 42 143 17.3. Example: Offerer Adds a Media Description to a BUNDLE 144 Group . . . . . . . . . . . . . . . . . . . . . . . . . 45 146 17.4. Example: Offerer Moves a Media Description Out of a 147 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46 148 17.5. Example: Offerer Disables a Media Description Within a 149 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 48 150 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 151 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 50 152 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 62 153 20.1. Normative References . . . . . . . . . . . . . . . . . . 62 154 20.2. Informative References . . . . . . . . . . . . . . . . . 64 155 Appendix A. Design Considerations . . . . . . . . . . . . . . . 65 156 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 66 157 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 67 158 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 67 159 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 68 160 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 68 161 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 69 162 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 164 1. Introduction 166 1.1. Background 168 When the SDP offer/answer mechanism [RFC3264] is used to negotiate 169 the establishment of multimedia communication sessions, if separate 170 transports (5-tuples) are negotiated for each individual media 171 stream, each transport consumes additional resources (especially when 172 Interactive Connectivity Establishment (ICE) [RFC8445] is used). For 173 this reason, it is attractive to use a single transport for multiple 174 media streams. 176 1.2. BUNDLE Mechanism 178 This specification defines a way to use a single transport (BUNDLE 179 transport) for sending and receiving media (bundled media) described 180 by multiple SDP media descriptions ("m=" sections). The address:port 181 combination used by an endpoint for sending and receiving bundled 182 media is referred to as the BUNDLE address:port. The set of SDP 183 attributes that are applied to each "m=" section within a BUNDLE 184 group is referred to as BUNDLE attributes. The same BUNDLE transport 185 is used for sending and receiving bundled media, which means that the 186 symmetric Real-time Transport Protocol (RTP) mechanism [RFC4961] is 187 always used for RTP-based bundled media. 189 This specification defines a new SDP Grouping Framework [RFC5888] 190 extension called 'BUNDLE'. The extension can be used with the 191 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 192 to negotiate which "m=" sections will become part of a BUNDLE group. 193 In addition, the offerer and answerer [RFC3264] use the BUNDLE 194 extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE 195 address:port and answerer BUNDLE address:port) and the set of BUNDLE 196 attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) 197 that will be applied to each "m=" section within the BUNDLE group. 199 The use of a BUNDLE transport allows the usage of a single set of 200 Interactive Connectivity Establishment (ICE) [RFC8445] candidates for 201 the whole BUNDLE group. 203 A given BUNDLE address:port MUST only be associated with a single 204 BUNDLE group. If an SDP offer or answer contains multiple BUNDLE 205 groups, the procedures in this specification apply to each group 206 independently. All RTP-based bundled media associated with a given 207 BUNDLE group belong to a single RTP session [RFC3550]. 209 The BUNDLE extension is backward compatible. Endpoints that do not 210 support the extension are expected to generate offers and answers 211 without an SDP 'group:BUNDLE' attribute, and are expected to assign a 212 unique address:port to each "m=" section within an offer and answer, 213 according to the procedures in [RFC4566] and [RFC3264]. 215 1.3. Protocol Extensions 217 In addition to defining the new SDP Grouping Framework extension, 218 this specification defines the following protocol extensions and RFC 219 updates: 221 o The specification defines a new SDP attribute, 'bundle-only', 222 which can be used to request that a specific "m=" section (and the 223 associated media) is used only used if kept within a BUNDLE group. 225 o The specification updates RFC 3264 [RFC3264], to also allow 226 assigning a zero port value to a "m=" section in cases where the 227 media described by the "m=" section is not disabled or rejected. 229 o The specification defines a new RTP Control Protocol (RTCP) 230 [RFC3550] source description (SDES) item, 'MID', and a new RTP 231 SDES header extension that can be used to associate RTP streams 232 with "m=" sections. 234 o The specification updates [RFC7941], by adding an exception, for 235 the MID RTP header extension, to the requirement regarding 236 protection of an SDES RTP header extension carrying an SDES item 237 for the MID RTP header extension. 239 2. Terminology 241 o "m=" section: SDP bodies contain one or more media descriptions, 242 referred to as "m=" sections. Each "m=" section is represented by 243 an SDP "m=" line, and zero or more SDP attributes associated with 244 the "m=" line. A local address:port combination is assigned to 245 each "m=" section. 247 o 5-tuple: A collection of the following values: source address, 248 source port, destination address, destination port, and transport- 249 layer protocol. 251 o Unique address:port: An address:port combination that is assigned 252 to only one "m=" section in an offer or answer. 254 o Offerer BUNDLE-tag: The first identification-tag in a given SDP 255 'group:BUNDLE' attribute identification-tag list in an offer. 257 o Answerer BUNDLE-tag: The first identification-tag in a given SDP 258 'group:BUNDLE' attribute identification-tag list in an answer. 260 o Suggested offerer tagged "m=" section: The bundled "m=" section 261 identified by the offerer BUNDLE-tag in an initial BUNDLE offer, 262 before a BUNDLE group has been negotiated. 264 o Offerer tagged "m=" section: The bundled "m=" section identified 265 by the offerer BUNDLE-tag in a subsequent offer. The "m=" section 266 contains characteristics (offerer BUNDLE address:port and offerer 267 BUNDLE attributes) applied to each "m=" section within the BUNDLE 268 group. 270 o Answerer tagged "m=" section: The bundled "m=" section identified 271 by the answerer BUNDLE-tag in an answer (initial BUNDLE answer or 272 subsequent). The "m=" section contains characteristics (answerer 273 BUNDLE address:port and answerer BUNDLE attributes) applied to 274 each "m=" section within the BUNDLE group. 276 o BUNDLE address:port: An address:port combination that an endpoint 277 uses for sending and receiving bundled media. 279 o Offerer BUNDLE address:port: the address:port combination used by 280 the offerer for sending and receiving media. 282 o Answerer BUNDLE address:port: the address:port combination used by 283 the answerer for sending and receiving media. 285 o BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category 286 SDP attributes. Once a BUNDLE group has been created, the 287 attribute values apply to each bundled "m=" section within the 288 BUNDLE group. 290 o Offerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing 291 category SDP attributes included in the offerer tagged "m=" 292 section. 294 o Answerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing 295 category SDP attributes included in the answerer tagged "m=" 296 section. 298 o BUNDLE transport: The transport (5-tuple) used by all media 299 described by the "m=" sections within a BUNDLE group. 301 o BUNDLE group: A set of bundled "m=" sections, created using an SDP 302 Offer/Answer exchange, which uses a single BUNDLE transport, and a 303 single set of BUNDLE attributes, for sending and receiving all 304 media (bundled media) described by the set of "m=" sections. The 305 same BUNDLE transport is used for sending and receiving bundled 306 media. 308 o Bundled "m=" section: An "m=" section, whose identification-tag is 309 placed in an SDP 'group:BUNDLE' attribute identification-tag list 310 in an offer or answer. 312 o Bundle-only "m=" section: A bundled "m=" section that contains an 313 SDP 'bundle-only' attribute. 315 o Bundled media: All media associated with a given BUNDLE group. 317 o Initial BUNDLE offer: The first offer, within an SDP session (e.g. 318 a SIP dialog when the Session Initiation Protocol (SIP) [RFC3261] 319 is used to carry SDP), in which the offerer indicates that it 320 wants to negotiate a given BUNDLE group. 322 o Initial BUNDLE answer: The answer to an initial BUNDLE offer in 323 which the offerer indicates that it wants to negotiate a BUNDLE 324 group, and where the answerer accepts the creation of the BUNDLE 325 group. The BUNDLE group is created once the answerer sends the 326 initial BUNDLE answer. 328 o Subsequent offer: An offer which contains a BUNDLE group that has 329 been created as part of a previous offer/answer exchange. 331 o Subsequent answer: An answer to a subsequent offer. 333 o Identification-tag: A unique token value that is used to identify 334 an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" 335 section carries the unique identification-tag assigned to that 336 "m=" section. The session-level SDP 'group' attribute [RFC5888] 337 carries a list of identification-tags, identifying the "m=" 338 sections associated with that particular 'group' attribute. 340 3. Conventions 342 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 343 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 344 "OPTIONAL" in this document are to be interpreted as described in BCP 345 14 [RFC2119] [RFC8174] when, and only when, they appear in all 346 capitals, as shown here. 348 4. Applicability Statement 350 The mechanism in this specification only applies to the Session 351 Description Protocol (SDP) [RFC4566], when used together with the SDP 352 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 353 scope of this document, and is thus undefined. 355 5. SDP Grouping Framework BUNDLE Extension 357 This section defines a new SDP Grouping Framework [RFC5888] 358 extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP 359 Offer/Answer mechanism to negotiate a set of "m=" sections that will 360 become part of a BUNDLE group. Within a BUNDLE group, each "m=" 361 section uses a BUNDLE transport for sending and receiving bundled 362 media. Each endpoint uses a single address:port combination for 363 sending and receiving the bundled media. 365 The BUNDLE extension is indicated using an SDP 'group' attribute with 366 a semantics value [RFC5888] of "BUNDLE". An identification-tag is 367 assigned to each bundled "m=" section, and each identification-tag is 368 listed in the SDP 'group:BUNDLE' attribute identification-tag list. 369 Each "m=" section whose identification-tag is listed in the 370 identification-tag list is associated with a given BUNDLE group. 372 SDP bodies can contain multiple BUNDLE groups. Any given bundled 373 "m=" section MUST NOT be associated with more than one BUNDLE group 374 at any given time. 376 NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' 377 attribute identification-tag list does not have to be the same as the 378 order in which the "m=" sections occur in the SDP. 380 The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] for 381 the 'group:BUNDLE' attribute is 'NORMAL'. 383 Section 7 defines the detailed SDP Offer/Answer procedures for the 384 BUNDLE extension. 386 6. SDP 'bundle-only' Attribute 388 This section defines a new SDP media-level attribute [RFC4566], 389 'bundle-only'. 'bundle-only' is a property attribute [RFC4566], and 390 hence has no value. 392 In order to ensure that an answerer that does not support the BUNDLE 393 extension always rejects a bundled "m=" section in an offer, the 394 offerer can assign a zero port value to the "m=" section. According 395 to [RFC3264] an answerer will reject such an "m=" section. By 396 including an SDP 'bundle-only' attribute in a bundled "m=" section, 397 the offerer can request that the answerer accepts the "m=" section 398 only if the answerer supports the BUNDLE extension, and if the 399 answerer keeps the "m=" section within the associated BUNDLE group. 401 Name: bundle-only 403 Value: N/A 405 Usage Level: media 407 Charset Dependent: no 409 Example: 411 a=bundle-only 413 Once the offerer tagged "m=" section and the answerer tagged "m=" 414 section have been selected, an offerer and answerer will include an 415 SDP 'bundle-only' attribute in, and assign a zero port value to, 416 every other bundled "m=" section. 418 The usage of the 'bundle-only' attribute is only defined for a 419 bundled "m=" section with a zero port value. Other usage is 420 unspecified. 422 Section 7 defines the detailed SDP Offer/Answer procedures for the 423 'bundle-only' attribute. 425 7. SDP Offer/Answer Procedures 427 This section describes the SDP Offer/Answer [RFC3264] procedures for: 429 o Negotiating a BUNDLE group; and 431 o Suggesting and selecting the tagged "m=" sections (offerer tagged 432 "m=" section and answerer tagged "m=" section); and 434 o Adding an "m=" section to a BUNDLE group; and 436 o Moving an "m=" section out of a BUNDLE group; and 438 o Disabling an "m=" section within a BUNDLE group. 440 The generic rules and procedures defined in [RFC3264] and [RFC5888] 441 also apply to the BUNDLE extension. For example, if an offer is 442 rejected by the answerer, the previously negotiated addresses:ports, 443 SDP parameters and characteristics (including those associated with a 444 BUNDLE group) apply. Hence, if an offerer generates an offer in 445 order to negotiate a BUNDLE group, and the answerer rejects the 446 offer, the BUNDLE group is not created. 448 The procedures in this section are independent of the media type or 449 "m=" line proto value assigned to a bundled "m=" section. Section 9 450 defines additional considerations for RTP based media. Section 6 451 defines additional considerations for the usage of the SDP 'bundle- 452 only' attribute. Section 10 defines additional considerations for 453 the usage of Interactive Connectivity Establishment (ICE) [RFC8445] 454 mechanism. 456 Offers and answers can contain multiple BUNDLE groups. The 457 procedures in this section apply independently to a given BUNDLE 458 group. 460 7.1. Generic SDP Considerations 462 This section describes generic restrictions associated with the usage 463 of SDP parameters within a BUNDLE group. It also describes how to 464 calculate a value for the whole BUNDLE group, when parameter and 465 attribute values have been assigned to each bundled "m=" section. 467 7.1.1. Connection Data (c=) 469 The "c=" line nettype value [RFC4566] associated with a bundled "m=" 470 section MUST be 'IN'. 472 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" 473 section MUST be 'IP4' or 'IP6'. The same value MUST be associated 474 with each "m=" section. 476 NOTE: Extensions to this specification can specify usage of the 477 BUNDLE mechanism for other nettype and addrtype values than the ones 478 listed above. 480 7.1.2. Bandwidth (b=) 482 An offerer and answerer MUST use the rules and restrictions defined 483 in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP 484 bandwidth (b=) line with bundled "m=" sections. 486 7.1.3. Attributes (a=) 488 An offerer and answerer MUST include SDP attributes in every bundled 489 "m=" section where applicable, following the normal offer/answer 490 procedures for each attribute, with the following exceptions: 492 o In the initial BUNDLE offer, the offerer MUST NOT include 493 IDENTICAL and TRANSPORT multiplexing category SDP attributes 494 (BUNDLE attributes) in bundle-only "m=" sections. The offerer 495 MUST include such attributes in all other bundled "m=" sections. 496 In the initial BUNDLE offer each bundled "m=" line can contain a 497 different set of BUNDLE attributes, and attribute values. Once 498 the offerer tagged "m=" section has been selected, the BUNDLE 499 attributes contained in the offerer tagged "m=" section will apply 500 to each bundled "m=" section within the BUNDLE group. 502 o In a subsequent offer, or in an answer (initial of subsequent), 503 the offerer and answerer MUST include IDENTICAL and TRANSPORT 504 multiplexing category SDP attributes (BUNDLE attributes) only in 505 the tagged "m=" section (offerer tagged "m=" section or answerer 506 tagged "m=" section). The offerer and answerer MUST NOT include 507 such attributes in any other bundled "m=" section. The BUNDLE 508 attributes contained in the tagged "m=" section will apply to each 509 bundled "m=" section within the BUNDLE group. 511 o In an offer (initial BUNDLE offer or subsequent), or in an answer 512 (initial BUNDLE answer or subsequent), the offerer and answerer 513 MUST include SDP attributes of other categories than IDENTICAL and 514 TRANSPORT in each bundled "m=" section that a given attribute 515 applies to. Each bundled "m=" line can contain a different set of 516 such attributes, and attribute values, as such attributes only 517 apply to the given bundled "m=" section in which they are 518 included. 520 NOTE: A consequence of the rules above is that media-specific 521 IDENTICAL and TRANSPORT multiplexing category SDP attributes which 522 are applicable only to some of the bundled "m=" sections within the 523 BUNDLE group might appear in the tagged "m=" section for which they 524 are not applicable. For instance, the tagged "m=" section might 525 contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section 526 does not describe RTP-based media (but another bundled "m=" section 527 within the BUNDLE group does describe RTP-based media). 529 7.2. Generating the Initial SDP Offer 531 The procedures in this section apply to the first offer, within an 532 SDP session (e.g. a SIP dialog when the Session Initiation Protocol 533 (SIP) [RFC3261] is used to carry SDP), in which the offerer indicates 534 that it wants to negotiate a given BUNDLE group. This could occur in 535 the initial offer, or in a subsequent offer, of the SDP session. 537 When an offerer generates an initial BUNDLE offer, in order to 538 negotiate a BUNDLE group, it MUST: 540 o Assign a unique address:port to each bundled "m=" section, 541 following the procedures in [RFC3264], excluding any bundle-only 542 "m=" sections (see below); and 544 o Pick a bundled "m=" section as the suggested offerer tagged "m=" 545 section [Section 7.2.1]; and 547 o Include SDP attributes in the bundled "m=" sections following the 548 rules in [Section 7.1.3]; and 550 o Include an SDP 'group:BUNDLE' attribute in the offer; and 552 o Place the identification-tag of each bundled "m=" section in the 553 SDP 'group:BUNDLE' attribute identification-tag list. The offerer 554 BUNDLE-tag indicates the suggested offerer tagged "m=" section. 556 NOTE: When the offerer assigns unique addresses:ports to multiple 557 bundled "m=" sections, the offerer needs to be prepared to receive 558 bundled media on each unique address:port, until it receives the 559 associated answer and finds out which bundled "m=" section (and 560 associated address:port combination) the answerer has selected as the 561 offerer tagged "m=" section. 563 If the offerer wants to request that the answerer accepts a given 564 bundled "m=" section only if the answerer keeps the "m=" section 565 within the negotiated BUNDLE group, the offerer MUST: 567 o Include an SDP 'bundle-only' attribute [Section 7.2.1] in the "m=" 568 section; and 570 o Assign a zero port value to the "m=" section. 572 NOTE: If the offerer assigns a zero port value to a bundled "m=" 573 section, but does not include an SDP 'bundle-only' attribute in the 574 "m=" section, it is an indication that the offerer wants to disable 575 the "m=" section [Section 7.5.3]. 577 [Section 7.2.2] and [Section 17.1] show an example of an initial 578 BUNDLE offer. 580 7.2.1. Suggesting the Offerer tagged 'm=' section 582 In the initial BUNDLE offer, the bundled "m=" section indicated by 583 the offerer BUNDLE-tag is the suggested offerer tagged "m=" section. 584 The address:port combination associated with the "m=" section will be 585 used by the offerer for sending and receiving bundled media if the 586 answerer selects the "m=" section as the offerer tagged "m=" section 587 [Section 7.3.1]. In addition, if the answerer selects the "m=" 588 section as the offerer tagged "m=" section, the BUNDLE attributes 589 included in the "m=" section will be applied to each "m=" section 590 within the negotiated BUNDLE group. 592 The offerer MUST NOT suggest a bundle-only "m=" section as the 593 offerer tagged "m=" section. 595 It is RECOMMENDED that the suggested offerer tagged "m=" section is a 596 bundled "m=" section that the offerer believes it is unlikely that 597 the answerer will reject, or move out of the BUNDLE group. How such 598 assumption is made is outside the scope of this document. 600 7.2.2. Example: Initial SDP Offer 602 The example shows an initial BUNDLE offer. The offer includes two 603 "m=" sections in the offer, and suggests that both "m=" sections are 604 included in a BUNDLE group. The audio "m=" section is the suggested 605 offerer tagged "m=" section, indicated by placing the identification- 606 tag associated with the "m=" section (offerer BUNDLE-tag) first in 607 the SDP group:BUNDLE attribute identification-id list. 609 SDP Offer 611 v=0 612 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 613 s= 614 c=IN IP6 2001:db8::3 615 t=0 0 616 a=group:BUNDLE foo bar 618 m=audio 10000 RTP/AVP 0 8 97 619 b=AS:200 620 a=mid:foo 621 a=rtcp-mux 622 a=rtpmap:0 PCMU/8000 623 a=rtpmap:8 PCMA/8000 624 a=rtpmap:97 iLBC/8000 625 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 627 m=video 10002 RTP/AVP 31 32 628 b=AS:1000 629 a=mid:bar 630 a=rtcp-mux 631 a=rtpmap:31 H261/90000 632 a=rtpmap:32 MPV/90000 633 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 635 7.3. Generating the SDP Answer 637 When an answerer generates an answer (initial BUNDLE answer or 638 subsequent) that contains a BUNDLE group the following general SDP 639 grouping framework restrictions, defined in [RFC5888], also apply to 640 the BUNDLE group: 642 o The answerer is only allowed to include a BUNDLE group in an 643 initial BUNDLE answer if the offerer requested the BUNDLE group to 644 be created in the corresponding initial BUNDLE offer; and 646 o The answerer is only allowed to include a BUNDLE group in a 647 subsequent answer if the corresponding subsequent offer contains a 648 previously negotiated BUNDLE group; and 650 o The answerer is only allowed to include a bundled "m=" section in 651 an answer if the "m=" section was indicated as bundled in the 652 corresponding offer; and 654 o The answerer is only allowed to include a bundled "m=" section in 655 the same BUNDLE group as the bundled "m=" line in the 656 corresponding offer. 658 In addition, when an answerer generates an answer (initial BUNDLE 659 answer or subsequent) that contains a BUNDLE group, the answerer 660 MUST: 662 o In case of an initial BUNDLE answer, select the offerer tagged 663 "m=" section using the procedures in Section 7.3.1. In case of a 664 subsequent answer, the offerer tagged "m=" section is indicated in 665 the corresponding subsequent offer, and MUST NOT be changed by the 666 answerer; and 668 o Select the answerer tagged "m=" section [Section 7.3.1]; and 670 o Assign the answerer BUNDLE address:port to the answerer tagged 671 "m=" section; and 673 o Include an SDP 'bundle-only' attribute in, and assign a zero port 674 value to, every other bundled "m=" section within the BUNDLE 675 group; and 677 o Include SDP attributes in the bundled "m=" sections following the 678 rules in [Section 7.1.3]; and 680 o Include an SDP 'group:BUNDLE' attribute in the answer; and 682 o Place the identification-tag of each bundled "m=" section in the 683 SDP 'group:BUNDLE' attribute identification-tag list. The 684 answerer BUNDLE-tag indicates the answerer tagged "m=" section 685 [Section 7.3.1]. 687 If the answerer does not want to keep an "m=" section within a BUNDLE 688 group, it MUST: 690 o Move the "m=" section out of the BUNDLE group [Section 7.3.2]; or 692 o Reject the "m=" section [Section 7.3.3]. 694 The answerer can modify the answerer BUNDLE address:port, add and 695 remove SDP attributes, or modify SDP attribute values, in a 696 subsequent answer. Changes to the answerer BUNDLE address:port and 697 the answerer BUNDLE attributes will be applied to each bundled "m=" 698 section within the BUNDLE group. 700 NOTE: If a bundled "m=" section in an offer contains a zero port 701 value, but the "m=" section does not contain an SDP 'bundle-only' 702 attribute, it is an indication that the offerer wants to disable the 703 "m=" section [Section 7.5.3]. 705 7.3.1. Answerer Selection of tagged 'm=' sections 707 When the answerer selects the offerer tagged "m=" section, it first 708 checks the suggested offerer tagged "m=" section [Section 7.2.1]. 709 The answerer MUST check whether the "m=" section fulfils the 710 following criteria: 712 o The answerer will not move the "m=" section out of the BUNDLE 713 group [Section 7.3.2]; and 715 o The answerer will not reject the "m=" section [Section 7.3.3]; and 717 o The "m=" section does not contain a zero port value. 719 If all of the criteria above are fulfilled, the answerer MUST select 720 the "m=" section as the offerer tagged "m=" section, and MUST also 721 mark the corresponding "m=" section in the answer as the answerer 722 tagged "m=" section. In the answer the answerer BUNDLE-tag indicates 723 the answerer tagged "m=" section. 725 If one or more of the criteria are not fulfilled, the answerer MUST 726 pick the next identification-tag in the identification-tag list in 727 the offer, and perform the same criteria check for the "m=" section 728 indicated by that identification-tag. If there are no more 729 identification-tags in the identification-tag list, the answerer MUST 730 NOT create the BUNDLE group. Unless the answerer rejects the whole 731 offer, the answerer MUST apply the answerer procedures for moving an 732 "m=" section out of a BUNDLE group [Section 7.3.2] or rejecting an 733 "m=" section within a BUNDLE group [Section 7.3.3] to every bundled 734 "m=" section in the offer when creating the answer. 736 [Section 17.1] shows an example of an offerer BUNDLE address:port 737 selection. 739 [Section 7.3.4] and [Section 17.1] show an example of an answerer 740 tagged "m=" section selection. 742 7.3.2. Moving A Media Description Out Of A BUNDLE Group 744 When an answerer generates the answer, if the answerer wants to move 745 a bundled "m=" section out of the negotiated BUNDLE group, the 746 answerer MUST first check the following criteria: 748 o In the corresponding offer, the "m=" section is within a 749 previously negotiated BUNDLE group; and 751 o In the corresponding offer, the "m=" section contains an SDP 752 'bundle-only' attribute. 754 If either criterium above is fulfilled the answerer can not move the 755 "m=" section out of the BUNDLE group in the answer. The answerer can 756 either reject the whole offer, reject each bundled "m=" section 757 within the BUNDLE group [Section 7.3.3], or keep the "m=" section 758 within the BUNDLE group in the answer and later create an offer where 759 the "m=" section is moved out of the BUNDLE group [Section 7.5.2]. 761 NOTE: One consequence of the rules above is that, once a BUNDLE group 762 has been negotiated, a bundled "m=" section can not be moved out of 763 the BUNDLE group in an answer. Instead an offer is needed. 765 When the answerer generates an answer, in which it moves a bundled 766 "m=" section out of a BUNDLE group, the answerer: 768 o MUST assign a unique address:port to the "m=" section; and 770 o MUST include any applicable SDP attribute in the "m=" section, 771 using the normal offer/answer procedures for the each Attributes; 772 and 774 o MUST NOT place the identification-tag associated with the "m=" 775 section in the SDP 'group:BUNDLE' attribute identification-tag 776 list associated with the BUNDLE group. 778 o MUST NOT include an SDP 'bundle-only' attribute to the "m=" 779 section; and 781 Because an answerer is not allowed to move an "m=" section from one 782 BUNDLE group to another within an answer [Section 7.3], if the 783 answerer wants to move an "m=" section from one BUNDLE group to 784 another it MUST first move the "m=" section out of the current BUNDLE 785 group, and then generate an offer where the "m=" section is added to 786 another BUNDLE group [Section 7.5.1]. 788 7.3.3. Rejecting a Media Description in a BUNDLE Group 790 When an answerer wants to reject a bundled "m=" section in an answer, 791 it MUST first check the following criterion: 793 o In the corresponding offer, the "m=" section is the offerer tagged 794 "m=" section. 796 If the criterium above is fulfilled the answerer can not reject the 797 "m=" section in the answer. The answerer can either reject the whole 798 offer, reject each bundled "m=" section within the BUNDLE group, or 799 keep the "m=" section within the BUNDLE group in the answer and later 800 create an offer where the "m=" section is disabled within the BUNDLE 801 group [Section 7.5.3]. 803 When an answerer generates an answer, in which it rejects a bundled 804 "m=" section, the answerer: 806 o MUST assign a zero port value to the "m=" section, according to 807 the procedures in [RFC3264]; and 809 o MUST NOT place the identification-tag associated with the "m=" 810 section in the SDP 'group:BUNDLE' attribute identification-tag 811 list associated with the BUNDLE group; and 813 o MUST NOT include an SDP 'bundle-only' attribute in the "m=" 814 section. 816 7.3.4. Example: SDP Answer 818 The example below shows an answer, based on the corresponding offer 819 in [Section 7.2.2]. The answerer accepts both bundled "m=" sections 820 within the created BUNDLE group. The audio "m=" section is the 821 answerer tagged "m=" section, indicated by placing the 822 identification-tag associated with the "m=" section (answerer BUNDLE- 823 tag) first in the SDP group;BUNDLE attribute identification-id list. 824 The answerer includes an SDP 'bundle-only' attribute in, and assigns 825 a zero port value to, the video "m=" section. 827 SDP Answer 829 v=0 830 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 831 s= 832 c=IN IP6 2001:db8::1 833 t=0 0 834 a=group:BUNDLE foo bar 836 m=audio 20000 RTP/AVP 0 837 b=AS:200 838 a=mid:foo 839 a=rtcp-mux 840 a=rtpmap:0 PCMU/8000 841 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 843 m=video 0 RTP/AVP 32 844 b=AS:1000 845 a=mid:bar 846 a=bundle-only 847 a=rtpmap:32 MPV/90000 848 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 850 7.4. Offerer Processing of the SDP Answer 852 When an offerer receives an answer, if the answer contains a BUNDLE 853 group, the offerer MUST check that any bundled "m=" section in the 854 answer was indicated as bundled in the corresponding offer. If there 855 is no mismatch, the offerer MUST apply the properties (BUNDLE 856 address:port, BUNDLE attributes etc) of the offerer tagged "m=" 857 section (selected by the answerer [Section 7.3.1]) to each bundled 858 "m=" section within the BUNDLE group. 860 NOTE: As the answerer might reject one or more bundled "m=" sections 861 in an initial BUNDLE offer, or move a bundled "m=" section out of a 862 BUNDLE group, a given bundled "m=" section in the offer might not be 863 indicated as bundled in the corresponding answer. 865 If the answer does not contain a BUNDLE group, the offerer MUST 866 process the answer as a normal answer. 868 7.5. Modifying the Session 870 When a BUNDLE group has previously been negotiated, and an offerer 871 generates a subsequent offer, the offerer MUST: 873 o Pick one bundled "m=" section as the offerer tagged "m=" section. 874 The offerer can either pick the "m=" section that was previously 875 selected by the answerer as the offerer tagged "m=" section, or 876 pick another bundled "m=" section within the BUNDLE group; and 878 o Assign a BUNDLE address:port (previously negotiated or newly 879 suggest) to the offerer tagged "m=" section; and 881 o Include an SDP 'bundle-only' attribute in, and assign a zero port 882 value to, every other bundled "m=" section within the BUNDLE 883 group; and 885 o Include SDP attributes in the bundled "m=" sections following the 886 rules in [Section 7.1.3]; and 888 o Include an SDP 'group:BUNDLE' attribute in the offer; and 890 o Place the identification-tag of each bundled "m=" section in the 891 SDP 'group:BUNDLE' attribute identification-tag list. The offerer 892 BUNDLE-tag indicates the offerer tagged "m=" section. 894 The offerer MUST NOT pick a given bundled "m=" section as the offerer 895 tagged "m=" section if: 897 o The offerer wants to move the "m=" section out of the BUNDLE group 898 [Section 7.5.2]; or 900 o The offerer wants to disable the "m=" section [Section 7.5.3]. 902 The offerer can modify the offerer BUNDLE address:port, add and 903 remove SDP attributes, or modify SDP attribute values, in the 904 subsequent offer. Changes to the offerer BUNDLE address:port and the 905 offerer BUNDLE attributes will (if the offer is accepted by the 906 answerer) be applied to each bundled "m=" section within the BUNDLE 907 group. 909 7.5.1. Adding a Media Description to a BUNDLE group 911 When an offerer generates a subsequent offer, in which it wants to 912 add a bundled "m=" section to a previously negotiated BUNDLE group, 913 the offerer follows the procedures in Section 7.5. The offerer 914 either picks the added "m=" section, or an "m=" section previously 915 added to the BUNDLE group, as the offerer tagged "m=" section. 917 NOTE: As described in Section 7.3.2, the answerer can not move the 918 added "m=" section out of the BUNDLE group in its answer. If the 919 answer wants to move the "m=" section out of the BUNDLE group, it 920 will have to first accept it into the BUNDLE group in the answer, and 921 then send a subsequent offer where the "m=" section is moved out of 922 the BUNDLE group [Section 7.5.2]. 924 7.5.2. Moving a Media Description Out of a BUNDLE Group 926 When an offerer generates a subsequent offer, in which it want to 927 remove a bundled "m=" section from a BUNDLE group, the offerer: 929 o MUST assign a unique address:port to the "m=" section; and 931 o MUST include SDP attributes in the "m=" section following the 932 normal offer/answer rules for each attribute; and 934 o MUST NOT place the identification-tag associated with the "m=" 935 section in the SDP 'group:BUNDLE' attribute identification-tag 936 list associated with the BUNDLE group; and 938 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 939 section. 941 For the other bundled "m=" sections within the BUNDLE group, the 942 offerer follows the procedures in [Section 7.5]. 944 An offerer MUST NOT move an "m=" section from one BUNDLE group to 945 another within a single offer. If the offerer wants to move an "m=" 946 section from one BUNDLE group to another it MUST first move the 947 BUNDLE group out of the current BUNDLE group, and then generate a 948 second offer where the "m=" section is added to another BUNDLE group 949 [Section 7.5.1]. 951 [Section 17.4] shows an example of an offer for moving an "m=" 952 section out of a BUNDLE group. 954 7.5.3. Disabling a Media Description in a BUNDLE Group 956 When an offerer generates a subsequent offer, in which it want to 957 disable a bundled "m=" section from a BUNDLE group, the offerer: 959 o MUST assign a zero port value to the "m=" section, following the 960 procedures in [RFC4566]; and 962 o MUST NOT place the identification-tag associated with the "m=" 963 section in the SDP 'group:BUNDLE' attribute identification-tag 964 list associated with the BUNDLE group; and 966 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 967 section. 969 For the other bundled "m=" sections within the BUNDLE group, the 970 offerer follows the procedures in [Section 7.5]. 972 [Section 17.5] shows an example of an offer and answer for disabling 973 an "m=" section within a BUNDLE group. 975 8. Protocol Identification 977 Each "m=" section within a BUNDLE group MUST use the same transport- 978 layer protocol. If bundled "m=" sections use different upper-layer 979 protocols on top of the transport-layer protocol, there MUST exist a 980 publicly available specification which describes a mechanism how to 981 associate received data with the correct protocol for this particular 982 protocol combination. 984 In addition, if received data can be associated with more than one 985 bundled "m=" section, there MUST exist a publicly available 986 specification which describes a mechanism for associating the 987 received data with the correct "m=" section. 989 This document describes a mechanism to identify the protocol of 990 received data among the STUN, DTLS and SRTP protocols (in any 991 combination), when UDP is used as transport-layer protocol, but it 992 does not describe how to identify different protocols transported on 993 DTLS. While the mechanism is generally applicable to other protocols 994 and transport-layer protocols, any such use requires further 995 specification around how to multiplex multiple protocols on a given 996 transport-layer protocol, and how to associate received data with the 997 correct protocols. 999 8.1. STUN, DTLS, SRTP 1001 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 1002 protocol of a received packet among the STUN, DTLS and SRTP protocols 1003 (in any combination). If an offer or answer includes a bundled "m=" 1004 section that represents these protocols, the offerer or answerer MUST 1005 support the mechanism described in [RFC5764], and no explicit 1006 negotiation is required in order to indicate support and usage of the 1007 mechanism. 1009 [RFC5764] does not describe how to identify different protocols 1010 transported on DTLS, only how to identify the DTLS protocol itself. 1011 If multiple protocols are transported on DTLS, there MUST exist a 1012 specification describing a mechanism for identifying each individual 1013 protocol. In addition, if a received DTLS packet can be associated 1014 with more than one "m=" section, there MUST exist a specification 1015 which describes a mechanism for associating the received DTLS packets 1016 with the correct "m=" section. 1018 [Section 9.2] describes how to associate the packets in a received 1019 SRTP stream with the correct "m=" section. 1021 9. RTP Considerations 1023 9.1. Single RTP Session 1025 All RTP-based media within a single BUNDLE group belong to a single 1026 RTP session [RFC3550]. 1028 Since a single BUNDLE transport is used for sending and receiving 1029 bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for 1030 RTP-based bundled media. 1032 Since a single RTP session is used for each BUNDLE group, all "m=" 1033 sections representing RTP-based media within a BUNDLE group will 1034 share a single SSRC numbering space [RFC3550]. 1036 The following rules and restrictions apply for a single RTP session: 1038 o A specific payload type value can be used in multiple bundled "m=" 1039 sections only if each codec associated with the payload type 1040 number shares an identical codec configuration [Section 9.1.1]. 1042 o The proto value in each bundled RTP-based "m=" section MUST be 1043 identical (e.g., RTP/AVPF). 1045 o The RTP MID header extension MUST be enabled, by including an SDP 1046 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 1047 hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section 1048 in every offer and answer. 1050 o A given SSRC MUST NOT transmit RTP packets using payload types 1051 that originate from different bundled "m=" sections. 1053 NOTE: The last bullet above is to avoid sending multiple media types 1054 from the same SSRC. If transmission of multiple media types are done 1055 with time overlap, RTP and RTCP fail to function. Even if done in 1056 proper sequence this causes RTP Timestamp rate switching issues 1057 [RFC7160]. However, once an SSRC has left the RTP session (by 1058 sending an RTCP BYE packet), that SSRC can be reused by another 1059 source (possibly associated with a different bundled "m=" section) 1060 after a delay of 5 RTCP reporting intervals (the delay is to ensure 1061 the SSRC has timed out, in case the RTCP BYE packet was lost 1062 [RFC3550]). 1064 [RFC7657] defines Differentiated Services (Diffserv) considerations 1065 for RTP-based bundled media sent using a mixture of Diffserv 1066 Codepoints. 1068 9.1.1. Payload Type (PT) Value Reuse 1070 Multiple bundled "m=" sections might describe RTP based media. As 1071 all RTP based media associated with a BUNDLE group belong to the same 1072 RTP session, in order for a given payload type value to be used 1073 inside more than one bundled "m=" section, all codecs associated with 1074 the payload type number MUST share an identical codec configuration. 1075 This means that the codecs MUST share the same media type, encoding 1076 name, clock rate and any parameter that can affect the codec 1077 configuration and packetization. 1078 [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose 1079 attribute values are required to be identical for all codecs that use 1080 the same payload type value. 1082 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 1083 Description 1085 As described in [RFC3550], RTP packets are associated with RTP 1086 streams [RFC7656]. Each RTP stream is identified by an SSRC value, 1087 and each RTP packet includes an SSRC field that is used to associate 1088 the packet with the correct RTP stream. RTCP packets also use SSRCs 1089 to identify which RTP streams the packet relates to. However, a RTCP 1090 packet can contain multiple SSRC fields, in the course of providing 1091 feedback or reports on different RTP streams, and therefore can be 1092 associated with multiple such streams. 1094 In order to be able to process received RTP/RTCP packets correctly, 1095 it MUST be possible to associate an RTP stream with the correct "m=" 1096 section, as the "m=" section and SDP attributes associated with the 1097 "m=" section contains information needed to process the packets. 1099 As all RTP streams associated with a BUNDLE group use the same 1100 transport for sending and receiving RTP/RTCP packets, the local 1101 address:port combination part of the transport cannot be used to 1102 associate an RTP stream with the correct "m=" section. In addition, 1103 multiple RTP streams might be associated with the same "m=" section. 1105 An offerer and answerer can inform each other which SSRC values they 1106 will use for an RTP stream by using the SDP 'ssrc' attribute 1107 [RFC5576]. However, an offerer will not know which SSRC values the 1108 answerer will use until the offerer has received the answer providing 1109 that information. Due to this, before the offerer has received the 1110 answer, the offerer will not be able to associate an RTP stream with 1111 the correct "m=" section using the SSRC value associated with the RTP 1112 stream. In addition, the offerer and answerer may start using new 1113 SSRC values mid-session, without informing each other using the SDP 1114 'ssrc' attribute. 1116 In order for an offerer and answerer to always be able to associate 1117 an RTP stream with the correct "m=" section, the offerer and answerer 1118 using the BUNDLE extension MUST support the mechanism defined in 1119 Section 14, where the offerer and answerer insert the identification- 1120 tag associated with an "m=" section (provided by the remote peer) 1121 into RTP and RTCP packets associated with a BUNDLE group. 1123 When using this mechanism, the mapping from an SSRC to an 1124 identification-tag is carried in RTP header extensions or RTCP SDES 1125 packets, as specified in Section 14. Since a compound RTCP packet 1126 can contain multiple RTCP SDES packets, and each RTCP SDES packet can 1127 contain multiple chunks, a single RTCP packet can contain several 1128 SSRC to identification-tag mappings. The offerer and answerer 1129 maintain tables used for routing that are updated each time an RTP/ 1130 RTCP packet contains new information that affects how packets are to 1131 be routed. 1133 However, some legacy implementations may not include this 1134 identification-tag in their RTP and RTCP traffic when using the 1135 BUNDLE mechanism, and instead use a payload type based mechanism to 1136 associate RTP streams with SDP "m=" sections. In this situation, 1137 each "m=" section needs to use unique payload type values, in order 1138 for the payload type to be a reliable indicator of the relevant "m=" 1139 section for the RTP stream. If an implementation fails to ensure 1140 unique payload type values it will be impossible to associate the RTP 1141 stream using that payload type value to a particular "m=" section. 1142 Note that when using the payload type to associate RTP streams with 1143 "m=" sections an RTP stream, identified by its SSRC, will be mapped 1144 to an "m=" section when the first packet of that RTP stream is 1145 received, and the mapping will not be changed even if the payload 1146 type used by that RTP stream changes. In other words, the SSRC 1147 cannot "move" to a different "m=" section simply by changing the 1148 payload type. 1150 Applications can implement RTP stacks in many different ways. The 1151 algorithm below details one way that RTP streams can be associated 1152 with "m=" sections, but is not meant to be prescriptive about exactly 1153 how an RTP stack needs to be implemented. Applications MAY use any 1154 algorithm that achieves equivalent results to those described in the 1155 algorithm below. 1157 To prepare to associate RTP streams with the correct "m=" section, 1158 the following steps MUST be followed for each BUNDLE group: 1160 Construct a table mapping MID to "m=" section for each "m=" 1161 section in this BUNDLE group. Note that an "m=" section may only 1162 have one MID. 1164 Construct a table mapping SSRCs of incoming RTP streams to "m=" 1165 section for each "m=" section in this BUNDLE group and for each 1166 SSRC configured for receiving in that "m=" section. 1168 Construct a table mapping the SSRC of each outgoing RTP stream to 1169 "m=" section for each "m=" section in this BUNDLE group and for 1170 each SSRC configured for sending in that "m=" section. 1172 Construct a table mapping payload type to "m=" section for each 1173 "m=" section in the BUNDLE group and for each payload type 1174 configured for receiving in that "m=" section. If any payload 1175 type is configured for receiving in more than one "m=" section in 1176 the BUNDLE group, do not include it in the table, as it cannot be 1177 used to uniquely identify an "m=" section. 1179 Note that for each of these tables, there can only be one mapping 1180 for any given key (MID, SSRC, or PT). In other words, the tables 1181 are not multimaps. 1183 As "m=" sections are added or removed from the BUNDLE groups, or 1184 their configurations are changed, the tables above MUST also be 1185 updated. 1187 When an RTP packet is received, it MUST be delivered to the RTP 1188 stream corresponding to its SSRC. That RTP stream MUST then be 1189 associated with the correct "m=" section within a BUNDLE group, for 1190 additional processing, according to the following steps: 1192 If the MID associated with the RTP stream is not in the table 1193 mapping MID to "m=" section, then the RTP stream is not decoded 1194 and the payload data is discarded. 1196 If the packet has a MID, and the packet's extended sequence number 1197 is greater than that of the last MID update, as discussed in 1198 [RFC7941], Section 4.2.6, update the MID associated with the RTP 1199 stream to match the MID carried in the RTP packet, then update the 1200 mapping tables to include an entry that maps the SSRC of that RTP 1201 stream to the "m=" section for that MID. 1203 If the SSRC of the RTP stream is in the incoming SSRC mapping 1204 table, check that the payload type used by the RTP stream matches 1205 a payload type included on the matching "m=" section. If so, 1206 associate the RTP stream with that "m=" section. Otherwise, the 1207 RTP stream is not decoded and the payload data is discarded. 1209 If the payload type used by the RTP stream is in the payload type 1210 table, update the incoming SSRC mapping table to include an entry 1211 that maps the RTP stream's SSRC to the "m=" section for that 1212 payload type. Associate the RTP stream with the corresponding 1213 "m=" section. 1215 Otherwise, mark the RTP stream as not for decoding and discard the 1216 payload. 1218 If the RTP packet contains one or more contributing source (CSRC) 1219 identifiers, then each CSRC is looked up in the incoming SSRC table 1220 and a copy of the RTP packet is associated with the corresponding 1221 "m=" section for additional processing. 1223 For each RTCP packet received (including each RTCP packet that is 1224 part of a compound RTCP packet), the packet is processed as usual by 1225 the RTP layer, then associated with the appropriate "m=" sections, 1226 and processed for the RTP streams represented by those "m=" sections. 1227 This routing is type-dependent, as each kind of RTCP packet has its 1228 own mechanism for associating it with the relevant RTP streams. 1230 RTCP packets that cannot be associated with an appropriate "m=" 1231 section MUST still be processed as usual by the RTP layer, updating 1232 the metadata associated with the corresponding RTP streams. This 1233 situation can occur with certain multiparty RTP topologies, or when 1234 RTCP packets are sent containing a subset of the SDES information. 1236 Additional rules for processing various types of RTCP packets are 1237 explained below. 1239 If the RTCP packet is of type SDES, for each chunk in the packet 1240 whose SSRC is found in the incoming SSRC table, deliver a copy of 1241 the SDES packet to the "m=" section associated with that SSRC. In 1242 addition, for any SDES MID items contained in these chunks, if the 1243 MID is found in the table mapping MID to "m=" section, update the 1244 incoming SSRC table to include an entry that maps the RTP stream 1245 associated with the chunk's SSRC to the "m=" section associated 1246 with that MID, unless the packet is older than the packet that 1247 most recently updated the mapping for this SSRC, as discussed in 1248 [RFC7941], Section 4.2.6. 1250 Note that if an SDES packet is received as part of a compound RTCP 1251 packet, the SSRC to "m=" section mapping might not exist until the 1252 SDES packet is handled (e.g., in the case where RTCP for a source 1253 is received before any RTP packets). Therefore, it can be 1254 beneficial for an implementation to delay RTCP packet routing, 1255 such that it either prioritizes processing of the SDES item to 1256 generate or update the mapping, or buffers the RTCP information 1257 that needs to be routed until the SDES item(s) has been processed. 1258 If the implementation is unable to follow this recommendation, the 1259 consequence could be that some RTCP information from this 1260 particular RTCP compound packet is not provided to higher layers. 1261 The impact from this is likely minor, when this information 1262 relates to a future incoming RTP stream. 1264 If the RTCP packet is of type BYE, it indicates that the RTP 1265 streams referenced in the packet are ending. Therefore, for each 1266 SSRC indicated in the packet that is found in the incoming SSRC 1267 table, first deliver a copy of the BYE packet to the "m=" section 1268 associated with that SSRC, then remove the entry for that SSRC 1269 from the incoming SSRC table after an appropriate delay to account 1270 for "straggler packets", as specified in [RFC3550], Section 6.2.1. 1272 If the RTCP packet is of type SR or RR, for each report block in 1273 the report whose "SSRC of source" is found in the outgoing SSRC 1274 table, deliver a copy of the SR or RR packet to the "m=" section 1275 associated with that SSRC. In addition, if the packet is of type 1276 SR, and the sender SSRC for the packet is found in the incoming 1277 SSRC table, deliver a copy of the SR packet to the "m=" section 1278 associated with that SSRC. 1280 If the implementation supports RTCP XR and the packet is of type 1281 XR, as defined in [RFC3611], for each report block in the report 1282 whose "SSRC of source" is found in the outgoing SSRC table, 1283 deliver a copy of the XR packet to the "m=" section associated 1284 with that SSRC. In addition, if the sender SSRC for the packet is 1285 found in the incoming SSRC table, deliver a copy of the XR packet 1286 to the "m=" section associated with that SSRC. 1288 If the RTCP packet is a feedback message of type RTPFB or PSFB, as 1289 defined in [RFC4585], it will contain a media source SSRC, and 1290 this SSRC is used for routing certain subtypes of feedback 1291 messages. However, several subtypes of PSFB and RTPFB messages 1292 include target SSRC(s) in a section called Feedback Control 1293 Information (FCI). For these messages, the target SSRC(s) are 1294 used for routing. 1296 If the RTCP packet is a feedback packet that does not include 1297 target SSRCs in its FCI section, and the media source SSRC is 1298 found in the outgoing SSRC table, deliver the feedback packet to 1299 the "m=" section associated with that SSRC. RTPFB and PSFB types 1300 that are handled in this way include: 1302 Generic NACK: [RFC4585] (PT=RTPFB, FMT=1). 1304 Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1). 1306 Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2). 1308 Reference Picture Selection Indication (RPSI): [RFC4585] 1309 (PT=PSFB, FMT=3). 1311 If the RTCP packet is a feedback message that does include target 1312 SSRC(s) in its FCI section, it can either be a request or a 1313 notification. Requests reference a RTP stream that is being sent 1314 by the message recipient, whereas notifications are responses to 1315 an earlier request, and therefore reference a RTP stream that is 1316 being received by the message recipient. 1318 If the RTCP packet is a feedback request that includes target 1319 SSRC(s), for each target SSRC that is found in the outgoing SSRC 1320 table, deliver a copy of the RTCP packet to the "m=" section 1321 associated with that SSRC. PSFB and RTPFB types that are handled 1322 in this way include: 1324 Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). 1326 Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, 1327 FMT=5). 1329 H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, 1330 FMT=7). 1332 Temporary Maximum Media Bit Rate Request (TMMBR): [RFC5104] 1333 (PT=RTPFB, FMT=3). 1335 Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, 1336 FMT=10). 1338 If the RTCP packet is a feedback notification that includes target 1339 SSRC(s), for each target SSRC that is found in the incoming SSRC 1340 table, deliver a copy of the RTCP packet to the "m=" section 1341 associated with the RTP stream with matching SSRC. PSFB and RTPFB 1342 types that are handled in this way include: 1344 Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] 1345 (PT=PSFB, FMT=6). This message is a notification in response 1346 to a prior TSTR. 1348 Temporary Maximum Media Bit Rate Notification (TMMBN): [RFC5104] 1349 (PT=RTPFB, FMT=4). This message is a notification in response 1350 to a prior TMMBR, but can also be sent unsolicited. 1352 If the RTCP packet is of type APP, then it is handled in an 1353 application specific manner. If the application does not 1354 recognise the APP packet, then it MUST be discarded. 1356 9.3. RTP/RTCP Multiplexing 1358 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 1359 multiplexing [RFC5761] for the RTP-based bundled media (i.e., the 1360 same transport will be used for both RTP packets and RTCP packets). 1361 In addition, the offerer and answerer MUST support the SDP 'rtcp-mux- 1362 only' attribute [I-D.ietf-mmusic-mux-exclusive]. 1364 9.3.1. SDP Offer/Answer Procedures 1366 This section describes how an offerer and answerer use the SDP 'rtcp- 1367 mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute 1368 [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP 1369 multiplexing for RTP-based bundled media. 1371 RTP/RTCP multiplexing only applies to RTP-based media. However, as 1372 described in Section 7.1.3, within an offer or answer the SDP 'rtcp- 1373 mux' and SDP 'rtcp-mux-only' attributes might be included in a 1374 bundled "m=" section for non-RTP-based media (if such "m=" section is 1375 the offerer tagged "m=" section or answerer tagged "m=" section). 1377 9.3.1.1. Generating the Initial SDP BUNDLE Offer 1379 When an offerer generates an initial BUNDLE offer, if the offer 1380 contains one or more bundled "m=" sections for RTP-based media (or, 1381 if there is a chance that "m=" sections for RTP-based media will 1382 later be added to the BUNDLE group), the offerer MUST include an SDP 1383 'rtcp-mux' attribute [RFC5761] in each bundled "m=" section 1384 (excluding any bundle-only "m=" sections). In addition, the offerer 1385 MAY include an SDP 'rtcp-mux-only' attribute 1386 [I-D.ietf-mmusic-mux-exclusive] in one or more bundled "m=" sections 1387 for RTP-based media. 1389 NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute 1390 depends on whether the offerer supports fallback to usage of a 1391 separate port for RTCP in case the answerer moves one or more "m=" 1392 sections for RTP-based media out of the BUNDLE group in the answer. 1394 NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the 1395 bundled "m=" sections, but does not include an SDP 'rtcp-mux-only' 1396 attribute, the offerer can also include an SDP 'rtcp' attribute 1397 [RFC3605] in one or more RTP-based bundled "m=" sections in order to 1398 provide a fallback port for RTCP, as described in [RFC5761]. 1399 However, the fallback port will only be applied to "m=" sections for 1400 RTP-based media that are moved out of the BUNDLE group by the 1401 answerer. 1403 In the initial BUNDLE offer, the address:port combination for RTCP 1404 MUST be unique in each bundled "m=" section for RTP-based media 1405 (excluding a bundle-only "m=" section), similar to RTP. 1407 9.3.1.2. Generating the SDP Answer 1409 When an answerer generates an answer, if the answerer supports RTP- 1410 based media, and if a bundled "m=" section in the corresponding offer 1411 contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage 1412 of RTP/RTCP multiplexing, even if there currently are no bundled "m=" 1413 sections for RTP-based media within the BUNDLE group. The answerer 1414 MUST include an SDP 'rtcp-mux' attribute in the answerer tagged "m=" 1415 section, following the procedures for BUNDLE attributes 1416 [Section 7.1.3]. In addition, if the "m=" section that is selected 1417 as the offerer tagged "m=" section contained an SDP "rtcp-mux-only" 1418 attribute, the answerer MUST include an SDP "rtcp-mux-only" attribute 1419 in the answerer tagged "m=" section. 1421 In an initial BUNDLE offer, if the suggested offerer tagged "m=" 1422 section contained an SDP 'rtcp-mux-only' attribute, the "m=" section 1423 was for RTP-based media, and the answerer does not accept the "m=" 1424 section in the created BUNDLE group, the answerer MUST either move 1425 the "m=" section out of the BUNDLE group [Section 7.3.2], include the 1426 attribute in the moved "m=" section and enable RTP/RTCP multiplexing 1427 for the media associated with the "m=" section, or reject the "m=" 1428 section [Section 7.3.3]. 1430 The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled 1431 "m=" section in the answer. The answerer will use the port value of 1432 the tagged offerer "m=" section sending RTP and RTCP packets 1433 associated with RTP-based bundled media towards the offerer. 1435 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1436 negotiated in a previous offer/answer exchange, the answerer MUST 1437 include an SDP 'rtcp-mux' attribute in the answerer tagged "m=" 1438 section . It is not possible to disable RTP/RTCP multiplexing within 1439 a BUNDLE group. 1441 9.3.1.3. Offerer Processing of the SDP Answer 1443 When an offerer receives an answer, if the answerer has accepted the 1444 usage of RTP/RTCP multiplexing [Section 9.3.1.2], the answerer 1445 follows the procedures for RTP/RTCP multiplexing defined in 1446 [RFC5761]. The offerer will use the port value of the answerer 1447 tagged "m=" section for sending RTP and RTCP packets associated with 1448 RTP-based bundled media towards the answerer. 1450 NOTE: It is considered a protocol error if the answerer has not 1451 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" 1452 sections that the answerer included in the BUNDLE group. 1454 9.3.1.4. Modifying the Session 1456 When an offerer generates a subsequent offer, the offerer MUST 1457 include an SDP 'rtcp-mux' attribute in the offerer tagged "m=" 1458 section, following the procedures for IDENTICAL multiplexing category 1459 attributes in Section 7.1.3. 1461 10. ICE Considerations 1463 This section describes how to use the BUNDLE grouping extension 1464 together with the Interactive Connectivity Establishment (ICE) 1465 mechanism [RFC8445]. 1467 The generic procedures for negotiating usage of ICE using SDP, 1468 defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE 1469 with BUNDLE, with the following exceptions: 1471 o When the BUNDLE transport has been established, ICE connectivity 1472 checks and keep-alives only need to be performed for the BUNDLE 1473 transport, instead of per individual bundled "m=" section within 1474 the BUNDLE group. 1476 o The generic SDP attribute offer/answer considerations 1477 [Section 7.1.3] also apply to ICE-related attributes. Therefore, 1478 when an offer sends an initial BUNDLE offer (in order to negotiate 1479 a BUNDLE group) the offerer include ICE-related media-level 1480 attributes in each bundled "m=" section (excluding any bundle-only 1481 "m=" section), and each "m=" section MUST contain unique ICE 1482 properties. When an answerer generates an answer (initial BUNDLE 1483 answer or subsequent) that contains a BUNDLE group, and when an 1484 offerer sends a subsequent offer that contains a BUNDLE group, 1485 ICE-related media-level attributes are only included in the tagged 1486 "m=" section (suggested offerer tagged "m=" section or answerer 1487 tagged "m=" section), and the ICE properties are applied to each 1488 bundled "m=" section within the BUNDLE group. 1490 NOTE: Most ICE-related media-level SDP attributes belong to the 1491 TRANSPORT multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes], 1492 and the generic SDP attribute offer/answer considerations for 1493 TRANSPORT multiplexing category apply to the attributes. However, in 1494 the case of ICE-related attributes, the same considerations also 1495 apply to ICE-related media-level attributes that belong to other 1496 multiplexing categories. 1498 NOTE: The following ICE-related media-level SDP attributes are 1499 defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidate', 'remote- 1500 candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- 1501 pacing'. 1503 Initially, before ICE has produced selected candidate pairs that will 1504 be used for media, there might be multiple transports established (if 1505 multiple candidate pairs are tested). Once ICE has selected 1506 candidate pairs, they form the BUNDLE transport. 1508 Support and usage of ICE mechanism together with the BUNDLE extension 1509 is OPTIONAL, and the procedures in this section only apply when the 1510 ICE mechanism is used. Note that applications might mandate usage of 1511 the ICE mechanism even if the BUNDLE extension is not used. 1513 NOTE: If the trickle ICE mechanism [I-D.ietf-mmusic-trickle-ice-sip] 1514 is used, an offerer and answerer might assign a port value of '9', 1515 and an IPv4 address of '0.0.0.0' (or, the IPv6 equivalent '::') to 1516 multiple bundled "m=" sections in the initial BUNDLE offer. The 1517 offerer and answerer will follow the normal procedures for generating 1518 the offers and answers, including picking a bundled "m=" section as 1519 the suggested offerer tagged "m=" section, selecting the tagged "m=" 1520 sections etc. The only difference is that media can not be sent 1521 until one or more candidates have been provided. Once a BUNDLE group 1522 has been negotiated, trickled candidates associated with a bundled 1523 "m=" section will be applied to all bundled "m=" sections within the 1524 BUNDLE group. 1526 11. DTLS Considerations 1528 One or more media streams within a BUNDLE group might use the 1529 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1530 to encrypt the data, or to negotiate encryption keys if another 1531 encryption mechanism is used to encrypt media. 1533 When DTLS is used within a BUNDLE group, the following rules apply: 1535 o There can only be one DTLS association [RFC6347] associated with 1536 the BUNDLE group; and 1538 o Each usage of the DTLS association within the BUNDLE group MUST 1539 use the same mechanism for determining which endpoints (the 1540 offerer or answerer) become DTLS client and DTLS server; and 1542 o Each usage of the DTLS association within the BUNDLE group MUST 1543 use the same mechanism for determining whether an offer or answer 1544 will trigger the establishment of a new DTLS association, or 1545 whether an existing DTLS association will be used; and 1547 o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include 1548 the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message 1549 [RFC5764]. The client MUST include the extension even if the 1550 usage of DTLS-SRTP is not negotiated as part of the multimedia 1551 session (e.g., SIP session [RFC3261]). 1553 NOTE: The inclusion of the 'use_srtp' extension during the initial 1554 DTLS handshake ensures that a DTLS renegotiation will not be required 1555 in order to include the extension, in case DTLS-SRTP encrypted media 1556 is added to the BUNDLE group later during the multimedia session. 1558 12. RTP Header Extensions Consideration 1560 When [RFC8285] RTP header extensions are used in the context of this 1561 specification, the identifier used for a given extension MUST 1562 identify the same extension across all the bundled media 1563 descriptions. 1565 13. Update to RFC 3264 1567 This section updates RFC 3264, in order to allow extensions to define 1568 the usage of a zero port value in offers and answers for other 1569 purposes than removing or disabling media streams. The following 1570 sections of RFC 3264 are updated: 1572 o Section 5.1 (Unicast Streams). 1574 o Section 8.4 (Putting a Unicast Media Stream on Hold). 1576 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 1578 For recvonly and sendrecv streams, the port number and address in the 1579 offer indicate where the offerer would like to receive the media 1580 stream. For sendonly RTP streams, the address and port number 1581 indirectly indicate where the offerer wants to receive RTCP reports. 1582 Unless there is an explicit indication otherwise, reports are sent to 1583 the port number one higher than the number indicated. The IP address 1584 and port present in the offer indicate nothing about the source IP 1585 address and source port of RTP and RTCP packets that will be sent by 1586 the offerer. A port number of zero in the offer indicates that the 1587 stream is offered but MUST NOT be used. This has no useful semantics 1588 in an initial offer, but is allowed for reasons of completeness, 1589 since the answer can contain a zero port indicating a rejected stream 1590 (Section 6). Furthermore, existing streams can be terminated by 1591 setting the port to zero (Section 8). In general, a port number of 1592 zero indicates that the media stream is not wanted. 1594 13.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 1596 For recvonly and sendrecv streams, the port number and address in the 1597 offer indicate where the offerer would like to receive the media 1598 stream. For sendonly RTP streams, the address and port number 1599 indirectly indicate where the offerer wants to receive RTCP reports. 1600 Unless there is an explicit indication otherwise, reports are sent to 1601 the port number one higher than the number indicated. The IP address 1602 and port present in the offer indicate nothing about the source IP 1603 address and source port of RTP and RTCP packets that will be sent by 1604 the offerer. A port number of zero in the offer by default indicates 1605 that the stream is offered but MUST NOT be used, but an extension 1606 mechanism might specify different semantics for the usage of a zero 1607 port value. Furthermore, existing streams can be terminated by 1608 setting the port to zero (Section 8). In general, a port number of 1609 zero by default indicates that the media stream is not wanted. 1611 13.3. Original text of section 8.4 (6th paragraph) of RFC 3264 1613 RFC 2543 [10] specified that placing a user on hold was accomplished 1614 by setting the connection address to 0.0.0.0. Its usage for putting 1615 a call on hold is no longer recommended, since it doesn't allow for 1616 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1617 with connection oriented media. However, it can be useful in an 1618 initial offer when the offerer knows it wants to use a particular set 1619 of media streams and formats, but doesn't know the addresses and 1620 ports at the time of the offer. Of course, when used, the port 1621 number MUST NOT be zero, which would specify that the stream has been 1622 disabled. An agent MUST be capable of receiving SDP with a 1623 connection address of 0.0.0.0, in which case it means that neither 1624 RTP nor RTCP is to be sent to the peer. 1626 13.4. New text replacing section 8.4 (6th paragraph) of RFC 3264 1628 RFC 2543 [10] specified that placing a user on hold was accomplished 1629 by setting the connection address to 0.0.0.0. Its usage for putting 1630 a call on hold is no longer recommended, since it doesn't allow for 1631 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1632 with connection oriented media. However, it can be useful in an 1633 initial offer when the offerer knows it wants to use a particular set 1634 of media streams and formats, but doesn't know the addresses and 1635 ports at the time of the offer. Of course, when used, the port 1636 number MUST NOT be zero, if it would specify that the stream has been 1637 disabled. However, an extension mechanism might specify different 1638 semantics of the zero port number usage. An agent MUST be capable of 1639 receiving SDP with a connection address of 0.0.0.0, in which case it 1640 means that neither RTP nor RTCP is to be sent to the peer. 1642 14. RTP/RTCP extensions for identification-tag transport 1644 SDP Offerers and Answerers [RFC3264] can associate identification- 1645 tags with "m=" sections within SDP Offers and Answers, using the 1646 procedures in [RFC5888]. Each identification-tag uniquely represents 1647 an "m=" section. 1649 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1650 used to carry identification-tags within RTCP SDES packets. This 1651 section also defines a new RTP SDES header extension [RFC7941], which 1652 is used to carry the 'MID' RTCP SDES item in RTP packets. 1654 The SDES item and RTP SDES header extension make it possible for a 1655 receiver to associate each RTP stream with a specific "m=" section, 1656 with which the receiver has associated an identification-tag, even if 1657 those "m=" sections are part of the same RTP session. The RTP SDES 1658 header extension also ensures that the media recipient gets the 1659 identification-tag upon receipt of the first decodable media and is 1660 able to associate the media with the correct application. 1662 A media recipient informs the media sender about the identification- 1663 tag associated with an "m=" section through the use of an 'mid' 1664 attribute [RFC5888]. The media sender then inserts the 1665 identification-tag in RTCP and RTP packets sent to the media 1666 recipient. 1668 NOTE: This text above defines how identification-tags are carried in 1669 SDP Offers and Answers. The usage of other signaling protocols for 1670 carrying identification-tags is not prevented, but the usage of such 1671 protocols is outside the scope of this document. 1673 [RFC3550] defines general procedures regarding the RTCP transmission 1674 interval. The RTCP MID SDES item SHOULD be sent in the first few 1675 RTCP packets sent after joining the session, and SHOULD be sent 1676 regularly thereafter. The exact number of RTCP packets in which this 1677 SDES item is sent is intentionally not specified here, as it will 1678 depend on the expected packet loss rate, the RTCP reporting interval, 1679 and the allowable overhead. 1681 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1682 be included in some RTP packets at the start of the session and 1683 whenever the SSRC changes. It might also be useful to include the 1684 header extension in RTP packets that comprise access points in the 1685 media (e.g., with video I-frames). The exact number of RTP packets 1686 in which this header extension is sent is intentionally not specified 1687 here, as it will depend on expected packet loss rate and loss 1688 patterns, the overhead the application can tolerate, and the 1689 importance of immediate receipt of the identification-tag. 1691 For robustness, endpoints need to be prepared for situations where 1692 the reception of the identification-tag is delayed, and SHOULD NOT 1693 terminate sessions in such cases, as the identification-tag is likely 1694 to arrive soon. 1696 14.1. RTCP MID SDES Item 1698 0 1 2 3 1699 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 1700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1701 | MID=TBD | length | identification-tag ... 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP. 1706 The identification-tag is not zero terminated. 1708 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1709 identifier value.] 1711 14.2. RTP SDES Header Extension For MID 1713 The payload, containing the identification-tag, of the RTP SDES 1714 header extension element can be encoded using either the one-byte or 1715 two-byte header [RFC7941]. The identification-tag payload is UTF-8 1716 encoded, as in SDP. 1718 The identification-tag is not zero terminated. Note, that the set of 1719 header extensions included in the packet needs to be padded to the 1720 next 32-bit boundary using zero bytes [RFC8285]. 1722 As the identification-tag is included in either an RTCP SDES item or 1723 an RTP SDES header extension, or both, there needs to be some 1724 consideration about the packet expansion caused by the 1725 identification-tag. To avoid Maximum Transmission Unit (MTU) issues 1726 for the RTP packets, the header extension's size needs to be taken 1727 into account when encoding the media. 1729 It is recommended that the identification-tag is kept short. Due to 1730 the properties of the RTP header extension mechanism, when using the 1731 one-byte header, a tag that is 1-3 bytes will result in a minimal 1732 number of 32-bit words used for the RTP SDES header extension, in 1733 case no other header extensions are included at the same time. Note, 1734 do take into account that some single characters when UTF-8 encoded 1735 will result in multiple octets. The identification-tag MUST NOT 1736 contain any user information, and applications SHALL avoid generating 1737 the identification-tag using a pattern that enables user- or 1738 application identification. 1740 15. IANA Considerations 1742 15.1. New SDES item 1744 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1745 document.] 1747 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1748 identifier value.] 1750 This document adds the MID SDES item to the IANA "RTP SDES item 1751 types" registry as follows: 1753 Value: TBD 1754 Abbrev.: MID 1755 Name: Media Identification 1756 Reference: RFCXXXX 1758 15.2. New RTP SDES Header Extension URI 1760 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1761 document.] 1763 This document defines a new extension URI in the RTP SDES Compact 1764 Header Extensions sub-registry of the RTP Compact Header Extensions 1765 registry sub-registry, according to the following data: 1767 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1768 Description: Media identification 1769 Contact: IESG (iesg@ietf.org) 1770 Reference: RFCXXXX 1772 The SDES item does not reveal privacy information about the users. 1773 It is simply used to associate RTP-based media with the correct SDP 1774 media description ("m=" section) in the SDP used to negotiate the 1775 media. 1777 The purpose of the extension is for the offerer to be able to 1778 associate received multiplexed RTP-based media before the offerer 1779 receives the associated SDP answer. 1781 15.3. New SDP Attribute 1783 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1784 document.] 1786 This document defines a new SDP media-level attribute, 'bundle-only', 1787 according to the following data: 1789 Attribute name: bundle-only 1790 Type of attribute: media 1791 Subject to charset: No 1792 Purpose: Request a media description to be accepted 1793 in the answer only if kept within a BUNDLE 1794 group by the answerer. 1795 Appropriate values: N/A 1796 Contact name: IESG 1797 Contact e-mail: iesg@ietf.org 1798 Reference: RFCXXXX 1799 Mux category: NORMAL 1801 15.4. New SDP Group Semantics 1803 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1804 document.] 1806 This document registers the following semantics with IANA in the 1807 "Semantics for the "group" SDP Attribute" subregistry (under the 1808 "Session Description Protocol (SDP) Parameters" registry: 1810 Semantics Token Reference 1811 ------------------------------------- ------ --------- 1812 Media bundling BUNDLE [RFCXXXX] 1814 Mux category: NORMAL 1816 16. Security Considerations 1818 The security considerations defined in [RFC3264] and [RFC5888] apply 1819 to the BUNDLE extension. Bundle does not change which information, 1820 e.g., RTP streams, flows over the network, with the exception of the 1821 usage of the MID SDES item as discussed below. Primarily it changes 1822 which addresses and ports, and thus in which (RTP) sessions the 1823 information is flowing. This affects the security contexts being 1824 used and can cause previously separated information flows to share 1825 the same security context. This has very little impact on the 1826 performance of the security mechanism of the RTP sessions. In cases 1827 where one would have applied different security policies on the 1828 different RTP streams being bundled, or where the parties having 1829 access to the security contexts would have differed between the RTP 1830 streams, additional analysis of the implications are needed before 1831 selecting to apply BUNDLE. 1833 The identification-tag, independent of transport, RTCP SDES packet or 1834 RTP header extension, can expose the value to parties beyond the 1835 signaling chain. Therefore, the identification-tag values MUST be 1836 generated in a fashion that does not leak user information, e.g., 1837 randomly or using a per-bundle group counter, and SHOULD be 3 bytes 1838 or less, to allow them to efficiently fit into the MID RTP header 1839 extension. Note that if implementations use different methods for 1840 generating identification-tags this could enable fingerprinting of 1841 the implementation making it vulnerable to targeted attacks. The 1842 identification-tag is exposed on the RTP stream level when included 1843 in the RTP header extensions, however what it reveals of the RTP 1844 media stream structure of the endpoint and application was already 1845 possible to deduce from the RTP streams without the MID SDES header 1846 extensions. As the identification-tag is also used to route the 1847 media stream to the right application functionality it is important 1848 that the value received is the one intended by the sender, thus 1849 integrity and the authenticity of the source are important to prevent 1850 denial of service on the application. Existing SRTP configurations 1851 and other security mechanisms protecting the whole RTP/RTCP packets 1852 will provide the necessary protection. 1854 When the BUNDLE extension is used, the set of configurations of the 1855 security mechanism used in all the bundled media descriptions will 1856 need to be compatible so that they can be used simultaneously, at 1857 least per direction or endpoint. When using SRTP this will be the 1858 case, at least for the IETF defined key-management solutions due to 1859 their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their 1860 classification in [I-D.ietf-mmusic-sdp-mux-attributes]. 1862 The security considerations of "RTP Header Extension for the RTP 1863 Control Protocol (RTCP) Source Description Items" [RFC7941] requires 1864 that when RTCP is confidentiality protected, then any SDES RTP header 1865 extension carrying an SDES item, such as the MID RTP header 1866 extension, is also protected using commensurate strength algorithms. 1867 However, assuming the above requirements and recommendations are 1868 followed, there are no known significant security risks with leaving 1869 the MID RTP header extension without confidentiality protection. 1870 Therefore, this specification updates RFC 7941 by adding the 1871 exception that this requirement MAY be ignored for the MID RTP header 1872 extension. Security mechanisms for RTP/RTCP are discussed in Options 1873 for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can 1874 provide the necessary security functions of ensuring the integrity 1875 and source authenticity. 1877 17. Examples 1879 17.1. Example: Tagged m= Section Selections 1881 The example below shows: 1883 o An initial BUNDLE offer, in which the offerer wants to negotiate a 1884 BUNDLE group, and indicates the audio m= section as the suggested 1885 offerer tagged "m=" section. 1887 o An initial BUNDLE answer, in which the answerer accepts the 1888 creation of the BUNDLE group, selects the audio m= section in the 1889 offer as the offerer tagged "m=" section, selects the audio "m=" 1890 section in the answer as the answerer tagged "m=" section and 1891 assigns the answerer BUNDLE address:port to that "m=" section. 1893 SDP Offer (1) 1895 v=0 1896 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1897 s= 1898 c=IN IP6 2001:db8::3 1899 t=0 0 1900 a=group:BUNDLE foo bar 1902 m=audio 10000 RTP/AVP 0 8 97 1903 b=AS:200 1904 a=mid:foo 1905 a=rtcp-mux 1906 a=rtpmap:0 PCMU/8000 1907 a=rtpmap:8 PCMA/8000 1908 a=rtpmap:97 iLBC/8000 1909 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1911 m=video 10002 RTP/AVP 31 32 1912 b=AS:1000 1913 a=mid:bar 1914 a=rtcp-mux 1915 a=rtpmap:31 H261/90000 1916 a=rtpmap:32 MPV/90000 1917 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1919 SDP Answer (2) 1921 v=0 1922 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1923 s= 1924 c=IN IP6 2001:db8::1 1925 t=0 0 1926 a=group:BUNDLE foo bar 1928 m=audio 20000 RTP/AVP 0 1929 b=AS:200 1930 a=mid:foo 1931 a=rtcp-mux 1932 a=rtpmap:0 PCMU/8000 1933 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1935 m=video 0 RTP/AVP 32 1936 b=AS:1000 1937 a=mid:bar 1938 a=bundle-only 1939 a=rtpmap:32 MPV/90000 1940 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1942 17.2. Example: BUNDLE Group Rejected 1944 The example below shows: 1946 o An initial BUNDLE offer, in which the offerer wants to negotiate a 1947 BUNDLE group, and indicates the audio m= section as the suggested 1948 offerer tagged "m=" section. 1950 o An initial BUNDLE answer, in which the answerer rejects the 1951 creation of the BUNDLE group, generates a normal answer and 1952 assigns a unique address:port to each "m=" section in the answer. 1954 SDP Offer (1) 1956 v=0 1957 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1958 s= 1959 c=IN IP6 2001:db8::3 1960 t=0 0 1961 a=group:BUNDLE foo bar 1963 m=audio 10000 RTP/AVP 0 8 97 1964 b=AS:200 1965 a=mid:foo 1966 a=rtcp-mux 1967 a=rtpmap:0 PCMU/8000 1968 a=rtpmap:8 PCMA/8000 1969 a=rtpmap:97 iLBC/8000 1970 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1972 m=video 10002 RTP/AVP 31 32 1973 b=AS:1000 1974 a=mid:bar 1975 a=rtcp-mux 1976 a=rtpmap:31 H261/90000 1977 a=rtpmap:32 MPV/90000 1978 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 1980 SDP Answer (2) 1982 v=0 1983 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1984 s= 1985 c=IN IP6 2001:db8::1 1986 t=0 0 1988 m=audio 20000 RTP/AVP 0 1989 b=AS:200 1990 a=rtcp-mux 1991 a=rtpmap:0 PCMU/8000 1993 m=video 30000 RTP/AVP 32 1994 b=AS:1000 1995 a=rtcp-mux 1996 a=rtpmap:32 MPV/90000 1998 17.3. Example: Offerer Adds a Media Description to a BUNDLE Group 2000 The example below shows: 2002 o A subsequent offer, in which the offerer adds a new bundled "m=" 2003 section (video), indicated by the "zen" identification-tag, to a 2004 previously negotiated BUNDLE group, indicates the new "m=" section 2005 as the offerer tagged "m=" section and assigns the offerer BUNDLE 2006 address:port to that "m=" section. 2008 o A subsequent answer, in which the answerer indicates the new video 2009 "m=" section in the answer as the answerer tagged "m=" section and 2010 assigns the answerer BUNDLE address:port to that "m=" section. 2012 SDP Offer (1) 2014 v=0 2015 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2016 s= 2017 c=IN IP6 2001:db8::3 2018 t=0 0 2019 a=group:BUNDLE zen foo bar 2021 m=audio 0 RTP/AVP 0 8 97 2022 b=AS:200 2023 a=mid:foo 2024 a=bundle-only 2025 a=rtpmap:0 PCMU/8000 2026 a=rtpmap:8 PCMA/8000 2027 a=rtpmap:97 iLBC/8000 2028 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2030 m=video 0 RTP/AVP 31 32 2031 b=AS:1000 2032 a=mid:bar 2033 a=bundle-only 2034 a=rtpmap:31 H261/90000 2035 a=rtpmap:32 MPV/90000 2036 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2038 m=video 10000 RTP/AVP 66 2039 b=AS:1000 2040 a=mid:zen 2041 a=rtcp-mux 2042 a=rtpmap:66 H261/90000 2043 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2045 SDP Answer (2) 2047 v=0 2048 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2049 s= 2050 c=IN IP6 2001:db8::1 2051 t=0 0 2052 a=group:BUNDLE zen foo bar 2054 m=audio 0 RTP/AVP 0 2055 b=AS:200 2056 a=mid:foo 2057 a=bundle-only 2058 a=rtpmap:0 PCMU/8000 2059 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2061 m=video 0 RTP/AVP 32 2062 b=AS:1000 2063 a=mid:bar 2064 a=bundle-only 2065 a=rtpmap:32 MPV/90000 2066 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2068 m=video 20000 RTP/AVP 66 2069 b=AS:1000 2070 a=mid:zen 2071 a=rtcp-mux 2072 a=rtpmap:66 H261/90000 2073 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2075 17.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 2077 The example below shows: 2079 o A subsequent offer, in which the offerer removes a "m=" section 2080 (video), indicated by the "zen" identification-tag, from a 2081 previously negotiated BUNDLE group, indicates one of the bundled 2082 "m=" sections (audio) remaining in the BUNDLE group as the offerer 2083 tagged "m=" section and assigns the offerer BUNDLE address:port to 2084 that "m=" section. 2086 o A subsequent answer, in which the answerer removes the "m=" 2087 section from the BUNDLE group, indicates the audio "m=" section in 2088 the answer as the answerer tagged "m=" section and assigns the 2089 answerer BUNDLE address:port to that "m=" section. 2091 SDP Offer (1) 2093 v=0 2094 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2095 s= 2096 c=IN IP6 2001:db8::3 2097 t=0 0 2098 a=group:BUNDLE foo bar 2100 m=audio 10000 RTP/AVP 0 8 97 2101 b=AS:200 2102 a=mid:foo 2103 a=rtcp-mux 2104 a=rtpmap:0 PCMU/8000 2105 a=rtpmap:8 PCMA/8000 2106 a=rtpmap:97 iLBC/8000 2107 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2109 m=video 0 RTP/AVP 31 32 2110 b=AS:1000 2111 a=mid:bar 2112 a=bundle-only 2113 a=rtpmap:31 H261/90000 2114 a=rtpmap:32 MPV/90000 2115 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2117 m=video 50000 RTP/AVP 66 2118 b=AS:1000 2119 a=mid:zen 2120 a=rtcp-mux 2121 a=rtpmap:66 H261/90000 2123 SDP Answer (2) 2125 v=0 2126 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2127 s= 2128 c=IN IP6 2001:db8::1 2129 t=0 0 2130 a=group:BUNDLE foo bar 2132 m=audio 20000 RTP/AVP 0 2133 b=AS:200 2134 a=mid:foo 2135 a=rtcp-mux 2136 a=rtpmap:0 PCMU/8000 2137 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2138 m=video 0 RTP/AVP 32 2139 b=AS:1000 2140 a=mid:bar 2141 a=bundle-only 2142 a=rtpmap:32 MPV/90000 2143 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2145 m=video 60000 RTP/AVP 66 2146 b=AS:1000 2147 a=mid:zen 2148 a=rtcp-mux 2149 a=rtpmap:66 H261/90000 2151 17.5. Example: Offerer Disables a Media Description Within a BUNDLE 2152 Group 2154 The example below shows: 2156 o A subsequent offer, in which the offerer disables (by assigning a 2157 zero port value) a "m=" section (video), indicated by the "zen" 2158 identification-tag, from a previously negotiated BUNDLE group, 2159 indicates one of the bundled "m=" sections (audio) remaining 2160 active in the BUNDLE group as the offerer tagged "m=" section and 2161 assigns the offerer BUNDLE address:port to that "m=" section. 2163 o A subsequent answer, in which the answerer disables the "m=" 2164 section, indicates the audio "m=" section in the answer as the 2165 answerer tagged "m=" section and assigns the answerer BUNDLE 2166 address:port to that "m=" section. 2168 SDP Offer (1) 2170 v=0 2171 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2172 s= 2173 t=0 0 2174 a=group:BUNDLE foo bar 2176 m=audio 10000 RTP/AVP 0 8 97 2177 c=IN IP6 2001:db8::3 2178 b=AS:200 2179 a=mid:foo 2180 a=rtcp-mux 2181 a=rtpmap:0 PCMU/8000 2182 a=rtpmap:8 PCMA/8000 2183 a=rtpmap:97 iLBC/8000 2184 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2186 m=video 0 RTP/AVP 31 32 2187 c=IN IP6 2001:db8::3 2188 b=AS:1000 2189 a=mid:bar 2190 a=bundle-only 2191 a=rtpmap:31 H261/90000 2192 a=rtpmap:32 MPV/90000 2193 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2195 m=video 0 RTP/AVP 66 2196 a=mid:zen 2197 a=rtpmap:66 H261/90000 2199 SDP Answer (2) 2201 v=0 2202 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2203 s= 2204 t=0 0 2205 a=group:BUNDLE foo bar 2207 m=audio 20000 RTP/AVP 0 2208 c=IN IP6 2001:db8::1 2209 b=AS:200 2210 a=mid:foo 2211 a=rtcp-mux 2212 a=rtpmap:0 PCMU/8000 2213 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2215 m=video 0 RTP/AVP 32 2216 c=IN IP6 2001:db8::1 2217 b=AS:1000 2218 a=mid:bar 2219 a=bundle-only 2220 a=rtpmap:32 MPV/90000 2221 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 2223 m=video 0 RTP/AVP 66 2224 a=mid:zen 2225 a=rtpmap:66 H261/90000 2227 18. Acknowledgements 2229 The usage of the SDP grouping extension for negotiating bundled media 2230 is based on similar alternatives proposed by Harald Alvestrand and 2231 Cullen Jennings. The BUNDLE extension described in this document is 2232 based on the different alternative proposals, and text (e.g., SDP 2233 examples) have been borrowed (and, in some cases, modified) from 2234 those alternative proposals. 2236 The SDP examples are also modified versions from the ones in the 2237 Alvestrand proposal. 2239 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 2240 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 2241 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin 2242 Uberti, Taylor Brandstetter, Byron Campen and Eric Rescorla for 2243 reading the text, and providing useful feedback. 2245 Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus 2246 Westerlund for providing the text for the section on RTP/RTCP stream 2247 association. 2249 Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for 2250 providing help and text on the RTP/RTCP procedures. 2252 Thanks to Charlie Kaufman for performing the Sec-Dir review. 2254 Thanks to Linda Dunbar for performing the Gen-ART review. 2256 Thanks to Spotify for providing music for the countless hours of 2257 document editing. 2259 19. Change Log 2261 [RFC EDITOR NOTE: Please remove this section when publishing] 2263 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-52 2265 o Editorial fix: colon added to exmap attribute examples. 2267 o Reference updates. 2269 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-51 2271 o Changes based on IESG reviews. 2273 o - Clarification of 'initial offer' terminology. 2275 o - Merging of tagged m- section selection sections. 2277 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-50 2279 o Changes based on IESG reviews. 2281 o - Adding of tagged m- section concept. 2283 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-49 2285 o Changes based on IESG reviews. 2287 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-48 2289 o Changes based on Sec-Dir review by Charlie Kaufman. 2291 o - s/unique address/unique address:port 2293 o Changes based on Gen-ART review by Linda Dunbar. 2295 o Mux category for group:BUNDLE attribute added. 2297 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-47 2299 o Changes based on AD review by Ben Campbell. 2301 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-46 2303 o Pre-RFC5378 disclaimer removed put back. 2305 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-45 2307 o Mux category for SDP 'group:BUNDLE' attribute added. 2309 o https://github.com/cdh4u/draft-sdp-bundle/pull/54 2311 o Pre-RFC5378 disclaimer removed. 2313 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-44 2315 o Minor editorial nits based on pull request by Colin P. 2317 o https://github.com/cdh4u/draft-sdp-bundle/pull/53 2319 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-43 2321 o Changes based on WG chairs review. 2323 o Text added in order to close GitHub issues by Taylor B. 2325 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-42 2327 o Changes based on final WG review. 2329 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-41 2331 o Update to section 6 o RFC 3264: 2333 o https://github.com/cdh4u/draft-sdp-bundle/pull/47 2335 o Editorial clarification on BUNDLE address selection: 2337 o https://github.com/cdh4u/draft-sdp-bundle/pull/46 2339 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40 2341 o Editorial changes and technical restrictions in order to make the 2342 specification more understandable: 2344 o https://github.com/cdh4u/draft-sdp-bundle/pull/45 2346 o - BUNDLE address is only assigned to m- section indicated by 2347 BUNDLE-tag. 2349 o - bundle-only attribute also used in answers and subsequent 2350 offers. 2352 o - Answerer cannot reject, or remove, the bundled m- section that 2353 contains the BUNDLE address. 2355 o - ICE Offer/Answer sections removed, due to duplicated 2356 information. 2358 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39 2360 o Editorial terminology changes. 2362 o RFC 5285 reference replaced by reference to RFC 8285. 2364 o https://github.com/cdh4u/draft-sdp-bundle/pull/44 2366 o - Clarify that an m- section can not be moved between BUNDLE 2367 groups without first moving the m- section out of a BUNDLE group. 2369 o https://github.com/cdh4u/draft-sdp-bundle/pull/41 2370 o - Addition of BUNDLE transport concept. 2372 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38 2374 o Changes to RTP streaming mapping section based on text from Colin 2375 Perkins. 2377 o The following GitHub pull requests were merged: 2379 o https://github.com/cdh4u/draft-sdp-bundle/pull/34 2381 o - Proposed updates to RTP processing 2383 o https://github.com/cdh4u/draft-sdp-bundle/pull/35 2385 o - fixed reference to receiver-id section 2387 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-37 2389 o The following GitHub pull request was merged: 2391 o https://github.com/cdh4u/draft-sdp-bundle/pull/33 2393 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36 2395 o The following GitHub pull requests were merged: 2397 o https://github.com/cdh4u/draft-sdp-bundle/pull/32 2399 o - extmap handling in BUNDLE. 2401 o https://github.com/cdh4u/draft-sdp-bundle/pull/31 2403 o - Additional Acknowledgement text added. 2405 o https://github.com/cdh4u/draft-sdp-bundle/pull/30 2407 o - MID SDES item security procedures updated 2409 o https://github.com/cdh4u/draft-sdp-bundle/pull/29 2411 o - Appendix B of JSEP moved into BUNDLE. 2413 o - Associating RTP/RTCP packets with SDP m- lines. 2415 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35 2416 o Editorial changes on RTP streaming mapping section based on 2417 comments from Colin Perkins. 2419 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34 2421 o RTP streams, instead of RTP packets, are associated with m- lines. 2423 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 2425 o Editorial changes based on comments from Eric Rescorla and Cullen 2426 Jennings: 2428 o - Changes regarding usage of RTP/RTCP multiplexing attributes. 2430 o - Additional text regarding associating RTP/RTCP packets with SDP 2431 m- lines. 2433 o - Reference correction. 2435 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32 2437 o Editorial changes based on comments from Eric Rescorla and Cullen 2438 Jennings: 2440 o - Justification for mechanism added to Introduction. 2442 o - Clarify that the order of m- lines in the group:BUNDLE attribute 2443 does not have to be the same as the order in which the m- lines 2444 are listed in the SDP. 2446 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31 2448 o Editorial changes based on GitHub Pull requests by Martin Thomson: 2450 o - https://github.com/cdh4u/draft-sdp-bundle/pull/2 2452 o - https://github.com/cdh4u/draft-sdp-bundle/pull/1 2454 o Editorial change based on comment from Diederick Huijbers (9th 2455 July 2016). 2457 o Changes based on comments from Flemming Andreasen (21st June 2458 2016): 2460 o - Mux category for SDP bundle-only attribute added. 2462 o - Mux category considerations editorial clarification. 2464 o - Editorial changes. 2466 o RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext. 2468 o Note whether Design Considerations appendix is to be kept removed: 2470 o - Appendix is kept within document. 2472 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30 2474 o Indicating in the Abstract and Introduction that the document 2475 updates RFC 3264. 2477 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29 2479 o Change based on WGLC comment from Colin Perkins. 2481 o - Clarify that SSRC can be reused by another source after a delay 2482 of 5 RTCP reporting intervals. 2484 o Change based on WGLC comment from Alissa Cooper. 2486 o - IANA registry name fix. 2488 o - Additional IANA registration information added. 2490 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28 2492 o - Alignment with exclusive mux procedures. 2494 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 2496 o - Yet another terminology change. 2498 o - Mux category considerations added. 2500 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 2502 o - ICE considerations modified: ICE-related SDP attributes only 2503 added to the bundled m- line representing the selected BUNDLE 2504 address. 2506 o - Reference to draft-ietf-mmusic-ice-sip-sdp added. 2508 o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- 2509 rfc5245bis. 2511 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 2512 o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux 2513 considerations. 2515 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 2517 o - Reference and procedures associated with exclusive RTP/RTCP mux 2518 added 2520 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 2522 o - RTCP-MUX mandatory for bundled RTP m- lines 2524 o - Editorial fixes based on comments from Flemming Andreasen 2526 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 2528 o - Correction of Ari's family name 2530 o - Editorial fixes based on comments from Thomas Stach 2532 o - RTP/RTCP correction based on comment from Magnus Westerlund 2534 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2535 msg14861.html 2537 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 2539 o - Correct based on comment from Paul Kyzivat 2541 o -- 'received packets' replaced with 'received data' 2543 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 2545 o - Clarification based on comment from James Guballa 2547 o - Clarification based on comment from Flemming Andreasen 2549 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 2551 o - DTLS Considerations section added. 2553 o - BUNDLE semantics added to the IANA Considerations 2555 o - Changes based on WGLC comments from Adam Roach 2557 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2558 msg14673.html 2560 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 2562 o - Changes based on agreements at IETF#92 2564 o -- BAS Offer removed, based on agreement at IETF#92. 2566 o -- Procedures regarding usage of SDP "b=" line is replaced with a 2567 reference to to draft-ietf-mmusic-sdp-mux-attributes. 2569 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 2571 o - Editorial changes based on comments from Magnus Westerlund. 2573 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 2575 o - Modification of RTP/RTCP multiplexing section, based on comments 2576 from Magnus Westerlund. 2578 o - Reference updates. 2580 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 2582 o - Editorial fix. 2584 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 2586 o - Editorial changes. 2588 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 2590 o Changes to allow a newly suggested offerer BUNDLE address to be 2591 assigned to each bundled m- line. 2593 o Changes based on WGLC comments from Paul Kyzivat 2595 o - Editorial fixes 2597 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 2599 o Usage of SDP 'extmap' attribute added 2601 o SDP 'bundle-only' attribute scoped with "m=" lines with a zero 2602 port value 2604 o Changes based on WGLC comments from Thomas Stach 2606 o - ICE candidates not assigned to bundle-only m- lines with a zero 2607 port value 2609 o - Editorial changes 2611 o Changes based on WGLC comments from Colin Perkins 2613 o - Editorial changes: 2615 o -- "RTP SDES item" -> "RTCP SDES item" 2617 o -- "RTP MID SDES item" -> "RTCP MID SDES item" 2619 o - Changes in section 10.1.1: 2621 o -- "SHOULD NOT" -> "MUST NOT" 2623 o -- Additional text added to the Note 2625 o - Change to section 13.2: 2627 o -- Clarify that mid value is not zero terminated 2629 o - Change to section 13.3: 2631 o -- Clarify that mid value is not zero terminated 2633 o -- Clarify padding 2635 o Changes based on WGLC comments from Paul Kyzivat 2637 o - Editorial changes: 2639 o Changes based on WGLC comments from Jonathan Lennox 2641 o - Editorial changes: 2643 o - Defintion of SDP bundle-only attribute alligned with structure 2644 in 4566bis draft 2646 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 2648 o Editorial corrections based on comments from Harald Alvestrand. 2650 o Editorial corrections based on comments from Cullen Jennings. 2652 o Reference update (RFC 7160). 2654 o Clarification about RTCP packet sending when RTP/RTCP multiplexing 2655 is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ 2656 msg13765.html). 2658 o Additional text added to the Security Considerations. 2660 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 2662 o SDP bundle-only attribute added to IANA Considerations. 2664 o SDES item and RTP header extension added to Abstract and 2665 Introduction. 2667 o Modification to text updating section 8.2 of RFC 3264. 2669 o Reference corrections. 2671 o Editorial corrections. 2673 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 2675 o Terminology change: "bundle-only attribute assigned to m= line" to 2676 "bundle-only attribute associated with m= line". 2678 o Editorial corrections. 2680 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 2682 o Editorial corrections. 2684 o - "of"->"if" (8.3.2.5). 2686 o - "optional"->"OPTIONAL" (9.1). 2688 o - Syntax/ABNF for 'bundle-only' attribute added. 2690 o - SDP Offer/Answer sections merged. 2692 o - 'Request new offerer BUNDLE address' section added 2694 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 2696 o OPEN ISSUE regarding Receiver-ID closed. 2698 o - RTP MID SDES Item. 2700 o - RTP MID Header Extension. 2702 o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers 2703 closed. 2705 o - Indicating that, when rtcp-mux is used, the answerer MUST NOT 2706 include an 'rtcp' attribute in the answer, based on the procedures 2707 in section 5.1.3 of RFC 5761. 2709 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 2711 o Draft title changed. 2713 o Added "SDP" to section names containing "Offer" or "Answer". 2715 o Editorial fixes based on comments from Paul Kyzivat 2716 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2717 msg13314.html). 2719 o Editorial fixed based on comments from Colin Perkins 2720 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2721 msg13318.html). 2723 o - Removed text about extending BUNDLE to allow multiple RTP 2724 sessions within a BUNDLE group. 2726 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 2728 o Major re-structure of SDP Offer/Answer sections, to align with RFC 2729 3264 structure. 2731 o Additional definitions added. 2733 o - Shared address. 2735 o - Bundled "m=" line. 2737 o - Bundle-only "m=" line. 2739 o - Offerer suggested BUNDLE mid. 2741 o - Answerer selected BUNDLE mid. 2743 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 2744 to multiple "m=" lines until it has received an SDP Answer 2745 indicating support of the BUNDLE extension. 2747 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 2748 Answerer supports the BUNDLE extension, assign a zero port value 2749 to a 'bundle-only' "m=" line. 2751 o SDP 'bundle-only' attribute section added. 2753 o Connection data nettype/addrtype restrictions added. 2755 o RFC 3264 update section added. 2757 o Indicating that a specific payload type value can be used in 2758 multiple "m=" lines, if the value represents the same codec 2759 configuration in each "m=" line. 2761 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 2763 o Updated Offerer procedures (http://www.ietf.org/mail- 2764 archive/web/mmusic/current/msg12293.html). 2766 o Updated Answerer procedures (http://www.ietf.org/mail- 2767 archive/web/mmusic/current/msg12333.html). 2769 o Usage of SDP 'bundle-only' attribute added. 2771 o Reference to Trickle ICE document added. 2773 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 2775 o Mechanism modified, to be based on usage of SDP Offers with both 2776 different and identical port number values, depending on whether 2777 it is known if the remote endpoint supports the extension. 2779 o Cullen Jennings added as co-author. 2781 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 2783 o No changes. New version due to expiration. 2785 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 2787 o No changes. New version due to expiration. 2789 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 2791 o Draft name changed. 2793 o Harald Alvestrand added as co-author. 2795 o "Multiplex" terminology changed to "bundle". 2797 o Added text about single versus multiple RTP Sessions. 2799 o Added reference to RFC 3550. 2801 20. References 2803 20.1. Normative References 2805 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2806 Requirement Levels", BCP 14, RFC 2119, 2807 DOI 10.17487/RFC2119, March 1997, 2808 . 2810 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2811 with Session Description Protocol (SDP)", RFC 3264, 2812 DOI 10.17487/RFC3264, June 2002, 2813 . 2815 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2816 Jacobson, "RTP: A Transport Protocol for Real-Time 2817 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2818 July 2003, . 2820 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2821 in Session Description Protocol (SDP)", RFC 3605, 2822 DOI 10.17487/RFC3605, October 2003, 2823 . 2825 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2826 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2827 2003, . 2829 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2830 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2831 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2832 . 2834 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2835 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2836 July 2006, . 2838 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2839 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2840 . 2842 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2843 Control Packets on a Single Port", RFC 5761, 2844 DOI 10.17487/RFC5761, April 2010, 2845 . 2847 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2848 Security (DTLS) Extension to Establish Keys for the Secure 2849 Real-time Transport Protocol (SRTP)", RFC 5764, 2850 DOI 10.17487/RFC5764, May 2010, 2851 . 2853 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2854 Protocol (SDP) Grouping Framework", RFC 5888, 2855 DOI 10.17487/RFC5888, June 2010, 2856 . 2858 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2859 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2860 January 2012, . 2862 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2863 Header Extension for the RTP Control Protocol (RTCP) 2864 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2865 August 2016, . 2867 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2868 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2869 May 2017, . 2871 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 2872 Mechanism for RTP Header Extensions", RFC 8285, 2873 DOI 10.17487/RFC8285, October 2017, 2874 . 2876 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2877 Connectivity Establishment (ICE): A Protocol for Network 2878 Address Translator (NAT) Traversal", RFC 8445, 2879 DOI 10.17487/RFC8445, July 2018, 2880 . 2882 [I-D.ietf-mmusic-sdp-mux-attributes] 2883 Nandakumar, S., "A Framework for SDP Attributes when 2884 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 2885 (work in progress), February 2018. 2887 [I-D.ietf-mmusic-mux-exclusive] 2888 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 2889 Multiplexing using SDP", draft-ietf-mmusic-mux- 2890 exclusive-12 (work in progress), May 2017. 2892 [I-D.ietf-mmusic-ice-sip-sdp] 2893 Petit-Huguenin, M., Nandakumar, S., and A. Keranen, 2894 "Session Description Protocol (SDP) Offer/Answer 2895 procedures for Interactive Connectivity Establishment 2896 (ICE)", draft-ietf-mmusic-ice-sip-sdp-21 (work in 2897 progress), June 2018. 2899 [I-D.ietf-mmusic-trickle-ice-sip] 2900 Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 2901 Session Initiation Protocol (SIP) Usage for Incremental 2902 Provisioning of Candidates for the Interactive 2903 Connectivity Establishment (Trickle ICE)", draft-ietf- 2904 mmusic-trickle-ice-sip-18 (work in progress), June 2018. 2906 20.2. Informative References 2908 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2909 A., Peterson, J., Sparks, R., Handley, M., and E. 2910 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2911 DOI 10.17487/RFC3261, June 2002, 2912 . 2914 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2915 "RTP Control Protocol Extended Reports (RTCP XR)", 2916 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2917 . 2919 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2920 "Codec Control Messages in the RTP Audio-Visual Profile 2921 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 2922 February 2008, . 2924 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2925 "Extended RTP Profile for Real-time Transport Control 2926 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2927 DOI 10.17487/RFC4585, July 2006, 2928 . 2930 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2931 Media Attributes in the Session Description Protocol 2932 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2933 . 2935 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2936 Clock Rates in an RTP Session", RFC 7160, 2937 DOI 10.17487/RFC7160, April 2014, 2938 . 2940 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2941 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2942 . 2944 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2945 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2946 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2947 DOI 10.17487/RFC7656, November 2015, 2948 . 2950 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 2951 (Diffserv) and Real-Time Communication", RFC 7657, 2952 DOI 10.17487/RFC7657, November 2015, 2953 . 2955 [I-D.ietf-ice-trickle] 2956 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 2957 "Trickle ICE: Incremental Provisioning of Candidates for 2958 the Interactive Connectivity Establishment (ICE) 2959 Protocol", draft-ietf-ice-trickle-21 (work in progress), 2960 April 2018. 2962 [I-D.ietf-avtext-lrr] 2963 Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 2964 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 2965 Message", draft-ietf-avtext-lrr-07 (work in progress), 2966 July 2017. 2968 Appendix A. Design Considerations 2970 One of the main issues regarding the BUNDLE grouping extensions has 2971 been whether, in SDP Offers and SDP Answers, the same port value can 2972 be inserted in "m=" lines associated with a BUNDLE group, as the 2973 purpose of the extension is to negotiate the usage of a single 2974 transport for media specified by the "m=" sections. Issues with both 2975 approaches, discussed in the Appendix have been raised. The outcome 2976 was to specify a mechanism which uses SDP Offers with both different 2977 and identical port values. 2979 Below are the primary issues that have been considered when defining 2980 the "BUNDLE" grouping extension: 2982 o 1) Interoperability with existing UAs. 2984 o 2) Interoperability with intermediary Back to Back User Agent 2985 (B2BUA) and proxy entities. 2987 o 3) Time to gather, and the number of, ICE candidates. 2989 o 4) Different error scenarios, and when they occur. 2991 o 5) SDP Offer/Answer impacts, including usage of port number value 2992 zero. 2994 A.1. UA Interoperability 2996 Consider the following SDP Offer/Answer exchange, where Alice sends 2997 an SDP Offer to Bob: 2999 SDP Offer 3001 v=0 3002 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 3003 s= 3004 c=IN IP4 atlanta.example.com 3005 t=0 0 3007 m=audio 10000 RTP/AVP 97 3008 a=rtpmap:97 iLBC/8000 3009 m=video 10002 RTP/AVP 97 3010 a=rtpmap:97 H261/90000 3012 SDP Answer 3014 v=0 3015 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 3016 s= 3017 c=IN IP4 biloxi.example.com 3018 t=0 0 3020 m=audio 20000 RTP/AVP 97 3021 a=rtpmap:97 iLBC/8000 3022 m=video 20002 RTP/AVP 97 3023 a=rtpmap:97 H261/90000 3025 RFC 4961 specifies a way of doing symmetric RTP but that is a later 3026 extension to RTP and Bob can not assume that Alice supports RFC 4961. 3027 This means that Alice may be sending RTP from a different port than 3028 10000 or 10002 - some implementations simply send the RTP from an 3029 ephemeral port. When Bob's endpoint receives an RTP packet, the only 3030 way that Bob knows if the packet is to be passed to the video or 3031 audio codec is by looking at the port it was received on. This led 3032 some SDP implementations to use the fact that each "m=" section had a 3033 different port number to use that port number as an index to find the 3034 correct m line in the SDP. As a result, some implementations that do 3035 support symmetric RTP and ICE still use an SDP data structure where 3036 SDP with "m=" sections with the same port such as: 3038 SDP Offer 3040 v=0 3041 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 3042 s= 3043 c=IN IP4 atlanta.example.com 3044 t=0 0 3046 m=audio 10000 RTP/AVP 97 3047 a=rtpmap:97 iLBC/8000 3048 m=video 10000 RTP/AVP 98 3049 a=rtpmap:98 H261/90000 3051 will result in the second "m=" section being considered an SDP error 3052 because it has the same port as the first line. 3054 A.2. Usage of Port Number Value Zero 3056 In an SDP Offer or SDP Answer, the media specified by an "m=" section 3057 can be disabled/rejected by setting the port number value to zero. 3058 This is different from e.g., using the SDP direction attributes, 3059 where RTCP traffic will continue even if the SDP "inactive" attribute 3060 is indicated for the associated "m=" section. 3062 If each "m=" section associated with a BUNDLE group would contain 3063 different port values, and one of those port values would be used for 3064 a BUNDLE address:port associated with the BUNDLE group, problems 3065 would occur if an endpoint wants to disable/reject the "m=" section 3066 associated with that port, by setting the port value to zero. After 3067 that, no "m=" section would contain the port value which is used for 3068 the BUNDLE address:port. In addition, it is unclear what would 3069 happen to the ICE candidates associated with the "m=" section, as 3070 they are also used for the BUNDLE address:port. 3072 A.3. B2BUA And Proxy Interoperability 3074 Some back to back user agents may be configured in a mode where if 3075 the incoming call leg contains an SDP attribute the B2BUA does not 3076 understand, the B2BUA still generates that SDP attribute in the Offer 3077 for the outgoing call leg. Consider a B2BUA that did not understand 3078 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 3079 Further assume that the B2BUA was configured to tear down any call 3080 where it did not see any RTCP for 5 minutes. In this case, if the 3081 B2BUA received an Offer like: 3083 SDP Offer 3085 v=0 3086 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 3087 s= 3088 c=IN IP4 atlanta.example.com 3089 t=0 0 3091 m=audio 49170 RTP/AVP 0 3092 a=rtcp:53020 3094 It would be looking for RTCP on port 49171 but would not see any 3095 because the RTCP would be on port 53020 and after five minutes, it 3096 would tear down the call. Similarly, a B2BUA that did not understand 3097 BUNDLE yet put BUNDLE in its offer may be looking for media on the 3098 wrong port and tear down the call. It is worth noting that a B2BUA 3099 that generated an Offer with capabilities it does not understand is 3100 not compliant with the specifications. 3102 A.3.1. Traffic Policing 3104 Sometimes intermediaries do not act as B2BUAs, in the sense that they 3105 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 3106 however, they may use SDP information (e.g., IP address and port) in 3107 order to control traffic gating functions, and to set traffic 3108 policing rules. There might be rules which will trigger a session to 3109 be terminated in case media is not sent or received on the ports 3110 retrieved from the SDP. This typically occurs once the session is 3111 already established and ongoing. 3113 A.3.2. Bandwidth Allocation 3115 Sometimes intermediaries do not act as B2BUAs, in the sense that they 3116 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 3117 however, they may use SDP information (e.g., codecs and media types) 3118 in order to control bandwidth allocation functions. The bandwidth 3119 allocation is done per "m=" section, which means that it might not be 3120 enough if media specified by all "m=" sections try to use that 3121 bandwidth. That may either simply lead to bad user experience, or to 3122 termination of the call. 3124 A.4. Candidate Gathering 3126 When using ICE, a candidate needs to be gathered for each port. This 3127 takes approximately 20 ms extra for each extra "m=" section due to 3128 the NAT pacing requirements. All of this gathering can be overlapped 3129 with other things while e.g., a web-page is loading to minimize the 3130 impact. If the client only wants to generate TURN or STUN ICE 3131 candidates for one of the "m=" lines and then use trickle ICE 3132 [I-D.ietf-ice-trickle] to get the non host ICE candidates for the 3133 rest of the "m=" sections, it MAY do that and will not need any 3134 additional gathering time. 3136 Some people have suggested a TURN extension to get a bunch of TURN 3137 allocations at once. This would only provide a single STUN result so 3138 in cases where the other end did not support BUNDLE, it may cause 3139 more use of the TURN server but would be quick in the cases where 3140 both sides supported BUNDLE and would fall back to a successful call 3141 in the other cases. 3143 Authors' Addresses 3145 Christer Holmberg 3146 Ericsson 3147 Hirsalantie 11 3148 Jorvas 02420 3149 Finland 3151 Email: christer.holmberg@ericsson.com 3153 Harald Tveit Alvestrand 3154 Google 3155 Kungsbron 2 3156 Stockholm 11122 3157 Sweden 3159 Email: harald@alvestrand.no 3160 Cullen Jennings 3161 Cisco 3162 400 3rd Avenue SW, Suite 350 3163 Calgary, AB T2P 4H2 3164 Canada 3166 Email: fluffy@iii.ca