idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-51.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 (May 2, 2018) is 2179 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 1616 == Missing Reference: 'RFCXXXX' is mentioned on line 1800, 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-16 == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-20 == Outdated reference: A later version (-18) exists of draft-ietf-mmusic-trickle-ice-sip-14 Summary: 2 errors (**), 0 flaws (~~), 5 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: November 3, 2018 C. Jennings 7 Cisco 8 May 2, 2018 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-51.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 November 3, 2018. 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 Offerer tagged 'm=' section . . 16 104 7.3.2. Answerer Selection of Answerer tagged 'm=' section . 16 105 7.3.3. Moving A Media Description Out Of A BUNDLE Group . . 16 106 7.3.4. Rejecting a Media Description in a BUNDLE Group . . . 17 107 7.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 18 108 7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 19 109 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 19 110 7.5.1. Adding a Media Description to a BUNDLE group . . . . 20 111 7.5.2. Moving a Media Description Out of a BUNDLE Group . . 21 112 7.5.3. Disabling a Media Description in a BUNDLE Group . . . 21 113 8. Protocol Identification . . . . . . . . . . . . . . . . . . . 22 114 8.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 22 115 9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 23 116 9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 23 117 9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 24 118 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 119 Description . . . . . . . . . . . . . . . . . . . . . . . 24 120 9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 30 121 9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 30 122 10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 32 123 11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 33 124 12. RTP Header Extensions Consideration . . . . . . . . . . . . . 34 125 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 34 126 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 34 127 13.2. New text replacing section 5.1 (2nd paragraph) of RFC 128 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 129 13.3. Original text of section 8.4 (6th paragraph) of RFC 3264 35 130 13.4. New text replacing section 8.4 (6th paragraph) of RFC 131 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 132 14. RTP/RTCP extensions for identification-tag transport . . . . 36 133 14.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 37 134 14.2. RTP SDES Header Extension For MID . . . . . . . . . . . 37 135 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 136 15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 38 137 15.2. New RTP SDES Header Extension URI . . . . . . . . . . . 38 138 15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 39 139 15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 39 140 16. Security Considerations . . . . . . . . . . . . . . . . . . . 39 141 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41 142 17.1. Example: Tagged m= Section Selections . . . . . . . . . 41 143 17.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 42 144 17.3. Example: Offerer Adds a Media Description to a BUNDLE 145 Group . . . . . . . . . . . . . . . . . . . . . . . . . 44 146 17.4. Example: Offerer Moves a Media Description Out of a 147 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 45 148 17.5. Example: Offerer Disables a Media Description Within a 149 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 47 150 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 151 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 49 152 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 153 20.1. Normative References . . . . . . . . . . . . . . . . . . 60 154 20.2. Informative References . . . . . . . . . . . . . . . . . 62 155 Appendix A. Design Considerations . . . . . . . . . . . . . . . 64 156 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 64 157 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 66 158 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 66 159 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 67 160 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 67 161 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 67 162 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 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) 173 [I-D.ietf-ice-rfc5245bis] is used). For this reason, it is 174 attractive to use a single transport for multiple media streams. 176 1.2. BUNDLE Mechanism 178 This specification defines a way to use a single transport (BUNDLE 179 transport) for sending and receiving media (bundled media) described 180 by multiple SDP media descriptions ("m=" sections). The address:port 181 combination used by an endpoint for sending and receiving bundled 182 media is referred to as the BUNDLE address:port. The set of SDP 183 attributes that are applied to each "m=" section within a BUNDLE 184 group is referred to as BUNDLE attributes. The same BUNDLE transport 185 is used for sending and receiving bundled media, which means that the 186 symmetric Real-time Transport Protocol (RTP) mechanism [RFC4961] is 187 always used for RTP-based bundled media. 189 This specification defines a new SDP Grouping Framework [RFC5888] 190 extension called 'BUNDLE'. The extension can be used with the 191 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 192 to negotiate which "m=" sections will become part of a BUNDLE group. 194 In addition, the offerer and answerer [RFC3264] use the BUNDLE 195 extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE 196 address:port and answerer BUNDLE address:port) and the set of BUNDLE 197 attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) 198 that will be applied to each "m=" section within the BUNDLE group. 200 The use of a BUNDLE transport allows the usage of a single set of 201 Interactive Connectivity Establishment (ICE) 202 [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group. 204 A given BUNDLE address:port MUST only be associated with a single 205 BUNDLE group. If an SDP offer or answer contains multiple BUNDLE 206 groups, the procedures in this specification apply to each group 207 independently. All RTP-based bundled media associated with a given 208 BUNDLE group belong to a single RTP session [RFC3550]. 210 The BUNDLE extension is backward compatible. Endpoints that do not 211 support the extension are expected to generate offers and answers 212 without an SDP 'group:BUNDLE' attribute, and are expected to assign a 213 unique address:port to each "m=" section within an offer and answer, 214 according to the procedures in [RFC4566] and [RFC3264]. 216 1.3. Protocol Extensions 218 In addition to defining the new SDP Grouping Framework extension, 219 this specification defines the following protocol extensions and RFC 220 updates: 222 o The specification defines a new SDP attribute, 'bundle-only', 223 which can be used to request that a specific "m=" section (and the 224 associated media) is used only used if kept within a BUNDLE group. 226 o The specification updates RFC 3264 [RFC3264], to also allow 227 assigning a zero port value to a "m=" section in cases where the 228 media described by the "m=" section is not disabled or rejected. 230 o The specification defines a new RTP Control Protocol (RTCP) 231 [RFC3550] source description (SDES) item, 'MID', and a new RTP 232 SDES header extension that can be used to associate RTP streams 233 with "m=" sections. 235 o The specification updates [RFC7941], by adding an exception, for 236 the MID RTP header extension, to the requirement regarding 237 protection of an SDES RTP header extension carrying an SDES item 238 for the MID RTP header extension. 240 2. Terminology 242 o "m=" section: SDP bodies contain one or more media descriptions, 243 referred to as "m=" sections. Each "m=" section is represented by 244 an SDP "m=" line, and zero or more SDP attributes associated with 245 the "m=" line. A local address:port combination is assigned to 246 each "m=" section. 248 o 5-tuple: A collection of the following values: source address, 249 source port, destination address, destination port, and transport- 250 layer protocol. 252 o Unique address:port: An address:port combination that is assigned 253 to only one "m=" section in an offer or answer. 255 o Offerer BUNDLE-tag: The first identification-tag in a given SDP 256 'group:BUNDLE' attribute identification-tag list in an offer. 258 o Answerer BUNDLE-tag: The first identification-tag in a given SDP 259 'group:BUNDLE' attribute identification-tag list in an answer. 261 o Suggested offerer tagged "m=" section: The bundled "m=" section 262 identified by the offerer BUNDLE-tag in an initial offer, before a 263 BUNDLE group has been negotiated. 265 o Offerer tagged "m=" section: The bundled "m=" section identified 266 by the offerer BUNDLE-tag in a subsequent offer. The "m=" section 267 contains characteristics (offerer BUNDLE address:port and offerer 268 BUNDLE attributes) applied to each "m=" section within the BUNDLE 269 group. 271 o Answerer tagged "m=" section: The bundled "m=" section identified 272 by the answerer BUNDLE-tag in an answer (initial or subsequent). 273 The "m=" section contains characteristics (answerer BUNDLE 274 address:port and answerer BUNDLE attributes) applied to each "m=" 275 section within the BUNDLE group. 277 o BUNDLE address:port: An address:port combination that an endpoint 278 uses for sending and receiving bundled media. 280 o Offerer BUNDLE address:port: the address:port combination used by 281 the offerer for sending and receiving media. 283 o Answerer BUNDLE address:port: the address:port combination used by 284 the answerer for sending and receiving media. 286 o BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category 287 SDP attributes. Once a BUNDLE group has been created, the 288 attribute values apply to each bundled "m=" section within the 289 BUNDLE group. 291 o Offerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing 292 category SDP attributes included in the offerer tagged "m=" 293 section. 295 o Answerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing 296 category SDP attributes included in the answerer tagged "m=" 297 section. 299 o BUNDLE transport: The transport (5-tuple) used by all media 300 described by the "m=" sections within a BUNDLE group. 302 o BUNDLE group: A set of bundled "m=" sections, created using an SDP 303 Offer/Answer exchange, which uses a single BUNDLE transport, and a 304 single set of BUNDLE attributes, for sending and receiving all 305 media (bundled media) described by the set of "m=" sections. The 306 same BUNDLE transport is used for sending and receiving bundled 307 media. 309 o Bundled "m=" section: An "m=" section, whose identification-tag is 310 placed in an SDP 'group:BUNDLE' attribute identification-tag list 311 in an offer or answer. 313 o Bundle-only "m=" section: A bundled "m=" section that contains an 314 SDP 'bundle-only' attribute. 316 o Bundled media: All media associated with a given BUNDLE group. 318 o Initial offer: The first offer, within an SDP session (e.g. a SIP 319 dialog when the Session Initiation Protocol (SIP) [RFC3261] is 320 used to carry SDP), in which the offerer indicates that it wants 321 to negotiate a given BUNDLE group. 323 o Initial answer: The answer to an initial offer in which the 324 offerer indicates that it wants to negotiate a BUNDLE group, and 325 where the answerer accepts the creation of the BUNDLE group. The 326 BUNDLE group is created once the answerer sends the initial 327 answer. 329 o Subsequent offer: An offer which contains a BUNDLE group that has 330 been created as part of a previous offer/answer exchange. 332 o Subsequent answer: An answer to a subsequent offer. 334 o Identification-tag: A unique token value that is used to identify 335 an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" 336 section carries the unique identification-tag assigned to that 337 "m=" section. The session-level SDP 'group' attribute [RFC5888] 338 carries a list of identification-tags, identifying the "m=" 339 sections associated with that particular 'group' attribute. 341 3. Conventions 343 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 344 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 345 "OPTIONAL" in this document are to be interpreted as described in BCP 346 14 [RFC2119] [RFC8174] when, and only when, they appear in all 347 capitals, as shown here. 349 4. Applicability Statement 351 The mechanism in this specification only applies to the Session 352 Description Protocol (SDP) [RFC4566], when used together with the SDP 353 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 354 scope of this document, and is thus undefined. 356 5. SDP Grouping Framework BUNDLE Extension 358 This section defines a new SDP Grouping Framework [RFC5888] 359 extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP 360 Offer/Answer mechanism to negotiate a set of "m=" sections that will 361 become part of a BUNDLE group. Within a BUNDLE group, each "m=" 362 section uses a BUNDLE transport for sending and receiving bundled 363 media. Each endpoint uses a single address:port combination for 364 sending and receiving the bundled media. 366 The BUNDLE extension is indicated using an SDP 'group' attribute with 367 a semantics value [RFC5888] of "BUNDLE". An identification-tag is 368 assigned to each bundled "m=" section, and each identification-tag is 369 listed in the SDP 'group:BUNDLE' attribute identification-tag list. 370 Each "m=" section whose identification-tag is listed in the 371 identification-tag list is associated with a given BUNDLE group. 373 SDP bodies can contain multiple BUNDLE groups. Any given bundled 374 "m=" section MUST NOT be associated with more than one BUNDLE group 375 at any given time. 377 NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' 378 attribute identification-tag list does not have to be the same as the 379 order in which the "m=" sections occur in the SDP. 381 The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] for 382 the 'group:BUNDLE' attribute is 'NORMAL'. 384 Section 7 defines the detailed SDP Offer/Answer procedures for the 385 BUNDLE extension. 387 6. SDP 'bundle-only' Attribute 389 This section defines a new SDP media-level attribute [RFC4566], 390 'bundle-only'. 'bundle-only' is a property attribute [RFC4566], and 391 hence has no value. 393 In order to ensure that an answerer that does not support the BUNDLE 394 extension always rejects a bundled "m=" section in an offer, the 395 offerer can assign a zero port value to the "m=" section. According 396 to [RFC3264] an answerer will reject such an "m=" section. By 397 including an SDP 'bundle-only' attribute in a bundled "m=" section, 398 the offerer can request that the answerer accepts the "m=" section 399 only if the answerer supports the BUNDLE extension, and if the 400 answerer keeps the "m=" section within the associated BUNDLE group. 402 Name: bundle-only 404 Value: N/A 406 Usage Level: media 408 Charset Dependent: no 410 Example: 412 a=bundle-only 414 Once the offerer tagged "m=" section and the answerer tagged "m=" 415 section have been selected, an offerer and answerer will include an 416 SDP 'bundle-only' attribute in, and assign a zero port value to, 417 every other bundled "m=" section. 419 The usage of the 'bundle-only' attribute is only defined for a 420 bundled "m=" section with a zero port value. Other usage is 421 unspecified. 423 Section 7 defines the detailed SDP Offer/Answer procedures for the 424 'bundle-only' attribute. 426 7. SDP Offer/Answer Procedures 428 This section describes the SDP Offer/Answer [RFC3264] procedures for: 430 o Negotiating a BUNDLE group; and 432 o Suggesting and selecting the tagged "m=" sections (offerer tagged 433 "m=" section and answerer tagged "m=" section); and 435 o Adding an "m=" section to a BUNDLE group; and 437 o Moving an "m=" section out of a BUNDLE group; and 439 o Disabling an "m=" section within a BUNDLE group. 441 The generic rules and procedures defined in [RFC3264] and [RFC5888] 442 also apply to the BUNDLE extension. For example, if an offer is 443 rejected by the answerer, the previously negotiated addresses:ports, 444 SDP parameters and characteristics (including those associated with a 445 BUNDLE group) apply. Hence, if an offerer generates an offer in 446 order to negotiate a BUNDLE group, and the answerer rejects the 447 offer, the BUNDLE group is not created. 449 The procedures in this section are independent of the media type or 450 "m=" line proto value assigned to a bundled "m=" section. Section 9 451 defines additional considerations for RTP based media. Section 6 452 defines additional considerations for the usage of the SDP 'bundle- 453 only' attribute. Section 10 defines additional considerations for 454 the usage of Interactive Connectivity Establishment (ICE) 455 [I-D.ietf-ice-rfc5245bis] mechanism. 457 Offers and answers can contain multiple BUNDLE groups. The 458 procedures in this section apply independently to a given BUNDLE 459 group. 461 7.1. Generic SDP Considerations 463 This section describes generic restrictions associated with the usage 464 of SDP parameters within a BUNDLE group. It also describes how to 465 calculate a value for the whole BUNDLE group, when parameter and 466 attribute values have been assigned to each bundled "m=" section. 468 7.1.1. Connection Data (c=) 470 The "c=" line nettype value [RFC4566] associated with a bundled "m=" 471 section MUST be 'IN'. 473 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" 474 section MUST be 'IP4' or 'IP6'. The same value MUST be associated 475 with each "m=" section. 477 NOTE: Extensions to this specification can specify usage of the 478 BUNDLE mechanism for other nettype and addrtype values than the ones 479 listed above. 481 7.1.2. Bandwidth (b=) 483 An offerer and answerer MUST use the rules and restrictions defined 484 in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP 485 bandwidth (b=) line with bundled "m=" sections. 487 7.1.3. Attributes (a=) 489 An offerer and answerer MUST include SDP attributes in every bundled 490 "m=" section where applicable, following the normal offer/answer 491 procedures for each attribute, with the following exceptions: 493 o In the initial offerer, the offerer MUST NOT include IDENTICAL and 494 TRANSPORT multiplexing category SDP attributes (BUNDLE attributes) 495 in bundle-only "m=" sections. The offerer MUST included such 496 attributes in all other bundled "m=" sections. In the initial 497 offer each bundled "m=" line can contain a different set of BUNDLE 498 attributes, and attribute values. Once the offerer tagged "m=" 499 section has been selected, the BUNDLE attributes contained in the 500 offerer tagged "m=" section will apply to each bundled "m=" 501 section within the BUNDLE group. 503 o In a subsequent offer, or in an answer (initial of subsequent), 504 the offerer and answerer MUST include IDENTICAL and TRANSPORT 505 multiplexing category SDP attributes (BUNDLE attributes) only in 506 the tagged "m=" section (offerer tagged "m=" section or answerer 507 tagged "m=" section). The offerer and answerer MUST NOT include 508 such attributes in any other bundled "m=" section. The BUNDLE 509 attributes contained in the tagged "m=" section will apply to each 510 bundled "m=" section within the BUNDLE group. 512 o In an offer (initial or subsequent), or in an answer (initial or 513 subsequent), the offerer and answerer MUST include SDP attributes 514 of other categories than IDENTICAL and TRANSPORT in each bundled 515 "m=" section that a given attribute applies to. Each bundled "m=" 516 line can contain a different set of such attributes, and attribute 517 values, as such attributes only apply to the given bundled "m=" 518 section in which they are 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 When an offerer generates an initial offer, in order to negotiate a 532 BUNDLE group, it MUST: 534 o Assign a unique address:port to each bundled "m=" section, 535 following the procedures in [RFC3264], excluding any bundle-only 536 "m=" sections (see below); and 538 o Pick a bundled "m=" section as the suggested offerer tagged "m=" 539 section [Section 7.2.1]; and 541 o Include SDP attributes in the bundled "m=" sections following the 542 rules in [Section 7.1.3]; and 544 o Include an SDP 'group:BUNDLE' attribute in the offer; and 546 o Place the identification-tag of each bundled "m=" section in the 547 SDP 'group:BUNDLE' attribute identification-tag list. The offerer 548 BUNDLE-tag indicates the suggested offerer tagged "m=" section. 550 NOTE: When the offerer assigns unique addresses:ports to multiple 551 bundled "m=" sections, the offerer needs to be prepared to receive 552 bundled media on each unique address:port, until it receives the 553 associated answer and finds out which bundled "m=" section (and 554 associated address:port combination) the answerer has selected as the 555 offerer tagged "m=" section. 557 If the offerer wants to request that the answerer accepts a given 558 bundled "m=" section only if the answerer keeps the "m=" section 559 within the negotiated BUNDLE group, the offerer MUST: 561 o Include an SDP 'bundle-only' attribute [Section 7.2.1] in the "m=" 562 section; and 564 o Assign a zero port value to the "m=" section. 566 NOTE: If the offerer assigns a zero port value to a bundled "m=" 567 section, but does not include an SDP 'bundle-only' attribute in the 568 "m=" section, it is an indication that the offerer wants to disable 569 the "m=" section [Section 7.5.3]. 571 [Section 7.2.2] and [Section 17.1] show an example of an initial 572 offer. 574 7.2.1. Suggesting the Offerer tagged 'm=' section 576 In the initial offer, the bundled "m=" section indicated by the 577 offerer BUNDLE-tag is the suggested offerer tagged "m=" section. The 578 address:port combination associated with the "m=" section will be 579 used by the offerer for sending and receiving bundled media if the 580 answerer selects the "m=" section as the offerer tagged "m=" section 581 [Section 7.3.1]. In addition, if the answerer selects the "m=" 582 section as the offerer tagged "m=" section, the BUNDLE attributes 583 included in the "m=" section will be applied to each "m=" section 584 within the negotiated BUNDLE group. 586 The offerer MUST NOT suggest a bundle-only "m=" section as the 587 offerer tagged "m=" section. 589 It is RECOMMENDED that the suggested offerer tagged "m=" section is a 590 bundled "m=" section that the offerer believes it is unlikely that 591 the answerer will reject, or move out of the BUNDLE group. How such 592 assumption is made is outside the scope of this document. 594 7.2.2. Example: Initial SDP Offer 596 The example shows an initial offer. The offer includes two "m=" 597 sections in the offer, and suggests that both "m=" sections are 598 included in a BUNDLE group. The audio "m=" section is the suggested 599 offerer tagged "m=" section, indicated by placing the identification- 600 tag associated with the "m=" section (offerer BUNDLE-tag) first in 601 the SDP group:BUNDLE attribute identification-id list. 603 SDP Offer 605 v=0 606 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 607 s= 608 c=IN IP6 2001:db8::3 609 t=0 0 610 a=group:BUNDLE foo bar 612 m=audio 10000 RTP/AVP 0 8 97 613 b=AS:200 614 a=mid:foo 615 a=rtcp-mux 616 a=rtpmap:0 PCMU/8000 617 a=rtpmap:8 PCMA/8000 618 a=rtpmap:97 iLBC/8000 619 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 621 m=video 10002 RTP/AVP 31 32 622 b=AS:1000 623 a=mid:bar 624 a=rtcp-mux 625 a=rtpmap:31 H261/90000 626 a=rtpmap:32 MPV/90000 627 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 629 7.3. Generating the SDP Answer 631 When an answerer generates an answer (initial or subsequent) that 632 contains a BUNDLE group the following general SDP grouping framework 633 restrictions, defined in [RFC5888], also apply to the BUNDLE group: 635 o The answerer is only allowed to include a BUNDLE group in an 636 initial answer if the offerer requested the BUNDLE group to be 637 created in the corresponding initial offer; and 639 o The answerer is only allowed to include a BUNDLE group in a 640 subsequent answer if the corresponding subsequent offer contains a 641 previously negotiated BUNDLE group; and 643 o The answerer is only allowed to include a bundled "m=" section in 644 an answer if the "m=" section was indicated as bundled in the 645 corresponding offer; and 647 o The answerer is only allowed to include a bundled "m=" section in 648 the same BUNDLE group as the bundled "m=" line in the 649 corresponding offer. 651 In addition, when an answerer generates an answer (initial or 652 subsequent) that contains a BUNDLE group, the answerer MUST: 654 o In case of an initial answer, select the offerer tagged "m=" 655 section using the procedures in Section 7.3.1. In case of a 656 subsequent answer, the offerer tagged "m=" section is indicated in 657 the corresponding subsequent offer, and MUST NOT be changed by the 658 answerer; and 660 o Select the answerer tagged "m=" section [Section 7.3.2]; and 662 o Assign the answerer BUNDLE address:port to the answerer tagged 663 "m=" section; and 665 o Include an SDP 'bundle-only' attribute in, and assign a zero port 666 value to, every other bundled "m=" section within the BUNDLE 667 group; and 669 o Include SDP attributes in the bundled "m=" sections following the 670 rules in [Section 7.1.3]; and 672 o Include an SDP 'group:BUNDLE' attribute in the answer; and 674 o Place the identification-tag of each bundled "m=" section in the 675 SDP 'group:BUNDLE' attribute identification-tag list. The 676 answerer BUNDLE-tag indicates the answerer tagged "m=" section 677 [Section 7.3.2]. 679 If the answerer does not want to keep an "m=" section within a BUNDLE 680 group, it MUST: 682 o Move the "m=" section out of the BUNDLE group [Section 7.3.3]; or 684 o Reject the "m=" section [Section 7.3.4]. 686 The answerer can modify the answerer BUNDLE address:port, add and 687 remove SDP attributes, or modify SDP attribute values, in a 688 subsequent answer. Changes to the answerer BUNDLE address:port and 689 the answerer BUNDLE attributes will be applied to each bundled "m=" 690 section within the BUNDLE group. 692 NOTE: If a bundled "m=" section in an offer contains a zero port 693 value, but the "m=" section does not contain an SDP 'bundle-only' 694 attribute, it is an indication that the offerer wants to disable the 695 "m=" section [Section 7.5.3]. 697 7.3.1. Answerer Selection of Offerer tagged 'm=' section 699 When the answerer selects the offerer tagged "m=" section, it first 700 checks the suggested offerer tagged "m=" section [Section 7.2.1]. 701 The answerer MUST check whether the "m=" section fulfils the 702 following criteria: 704 o The answerer will not move the "m=" section out of the BUNDLE 705 group [Section 7.3.3]; and 707 o The answerer will not reject the "m=" section [Section 7.3.4]; and 709 o The "m=" section does not contain a zero port value. 711 If all of the criteria above are fulfilled, the answerer MUST select 712 the "m=" section as the offerer tagged "m=" section. 714 If one or more of the criteria are not fulfilled, the answerer MUST 715 pick the next identification-tag in the identification-tag list in 716 the offer, and perform the same criteria check for the "m=" section 717 indicated by that identification-tag. If there are no more 718 identification-tags in the identification-tag list, the answerer MUST 719 NOT create the BUNDLE group. Unless the answerer rejects the whole 720 offer, the answerer MUST apply the answerer procedures for moving an 721 "m=" section out of a BUNDLE group [Section 7.3.3] or rejecting an 722 "m=" section within a BUNDLE group [Section 7.3.4] to every bundled 723 "m=" section in the offer when creating the answer. 725 [Section 17.1] shows an example of an offerer BUNDLE address:port 726 selection. 728 7.3.2. Answerer Selection of Answerer tagged 'm=' section 730 The answerer MUST select the "m=" section in that corresponds to the 731 selected offerer tagged "m=" section in the corresponding offer 732 [Section 7.3.1] as the answerer tagged "m=" section. In the answer 733 the answerer BUNDLE-tag indicates the answerer tagged "m=" section. 735 [Section 7.3.5] and [Section 17.1] show an example of an answerer 736 tagged "m=" section selection. 738 7.3.3. Moving A Media Description Out Of A BUNDLE Group 740 When an answerer generates the answer, if the answerer wants to move 741 a bundled "m=" section out of the negotiated BUNDLE group, the 742 answerer MUST first check the following criteria: 744 o In the corresponding offer, the "m=" section is within a 745 previously negotiated BUNDLE group; and 747 o In the corresponding offer, the "m=" section contains an SDP 748 'bundle-only' attribute. 750 If either criterium above is fulfilled the answerer can not move the 751 "m=" section out of the BUNDLE group in the answer. The answerer can 752 either reject the whole offer, reject each bundled "m=" section 753 within the BUNDLE group [Section 7.3.4], or keep the "m=" section 754 within the BUNDLE group in the answer and later create an offer where 755 the "m=" section is moved out of the BUNDLE group [Section 7.5.2]. 757 NOTE: One consequence of the rules above is that, once a BUNDLE group 758 has been negotiated, a bundled "m=" section can not be moved out of 759 the BUNDLE group in an answer. Instead an offer is needed. 761 When the answerer generates an answer, in which it moves a bundled 762 "m=" section out of a BUNDLE group, the answerer: 764 o MUST assign a unique address:port to the "m=" section; and 766 o MUST include any applicable SDP attribute in the "m=" section, 767 using the normal offer/answer procedures for the each Attributes; 768 and 770 o MUST NOT place the identification-tag associated with the "m=" 771 section in the SDP 'group:BUNDLE' attribute identification-tag 772 list associated with the BUNDLE group. 774 o MUST NOT include an SDP 'bundle-only' attribute to the "m=" 775 section; and 777 Because an answerer is not allowed to move an "m=" section from one 778 BUNDLE group to another within an answer [Section 7.3], if the 779 answerer wants to move an "m=" section from one BUNDLE group to 780 another it MUST first move the "m=" section out of the current BUNDLE 781 group, and then generate an offer where the "m=" section is added to 782 another BUNDLE group [Section 7.5.1]. 784 7.3.4. Rejecting a Media Description in a BUNDLE Group 786 When an answerer wants to reject a bundled "m=" section in an answer, 787 it MUST first check the following criterium: 789 o In the corresponding offer, the "m=" section is the offerer tagged 790 "m=" section. 792 If the criterium above is fulfilled the answerer can not reject the 793 "m=" section in the answer. The answerer can either reject the whole 794 offer, reject each bundled "m=" section within the BUNDLE group, or 795 keep the "m=" section within the BUNDLE group in the answer and later 796 create an offer where the "m=" section is disabled within the BUNDLE 797 group [Section 7.5.3]. 799 When an answerer generates an answer, in which it rejects a bundled 800 "m=" section, the answerer: 802 o MUST assign a zero port value to the "m=" section, according to 803 the procedures in [RFC3264]; and 805 o MUST NOT place the identification-tag associated with the "m=" 806 section in the SDP 'group:BUNDLE' attribute identification-tag 807 list associated with the BUNDLE group; and 809 o MUST NOT include an SDP 'bundle-only' attribute in the "m=" 810 section. 812 7.3.5. Example: SDP Answer 814 The example below shows an answer, based on the corresponding offer 815 in [Section 7.2.2]. The answerer accepts both bundled "m=" sections 816 within the created BUNDLE group. The audio "m=" section is the 817 answerer tagged "m=" section, indicated by placing the 818 identification-tag associated with the "m=" section (answerer BUNDLE- 819 tag) first in the SDP group;BUNDLE attribute identification-id list. 820 The answerer includes an SDP 'bundle-only' attribute in, and assigns 821 a zero port value to, the video "m=" section. 823 SDP Answer 825 v=0 826 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 827 s= 828 c=IN IP6 2001:db8::1 829 t=0 0 830 a=group:BUNDLE foo bar 832 m=audio 20000 RTP/AVP 0 833 b=AS:200 834 a=mid:foo 835 a=rtcp-mux 836 a=rtpmap:0 PCMU/8000 837 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 839 m=video 0 RTP/AVP 32 840 b=AS:1000 841 a=mid:bar 842 a=bundle-only 843 a=rtpmap:32 MPV/90000 844 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 846 7.4. Offerer Processing of the SDP Answer 848 When an offerer receives an answer, if the answer contains a BUNDLE 849 group, the offerer MUST check that any bundled "m=" section in the 850 answer was indicated as bundled in the corresponding offer. If there 851 is no mismatch, the offerer MUST apply the properties (BUNDLE 852 address:port, BUNDLE attributes etc) of the offerer tagged "m=" 853 section (selected by the answerer [Section 7.3.1]) to each bundled 854 "m=" section within the BUNDLE group. 856 NOTE: As the answerer might reject one or more bundled "m=" sections 857 in an initial offer, or move a bundled "m=" section out of a BUNDLE 858 group, a given bundled "m=" section in the offer might not be 859 indicated as bundled in the corresponding answer. 861 If the answer does not contain a BUNDLE group, the offerer MUST 862 process the answer as a normal answer. 864 7.5. Modifying the Session 866 When a BUNDLE group has previously been negotiated, and an offerer 867 generates a subsequent offer, the offerer MUST: 869 o Pick one bundled "m=" section as the offerer tagged "m=" section. 870 The offerer can either pick the "m=" section that was previously 871 selected by the answerer as the offerer tagged "m=" section, or 872 pick another bundled "m=" section within the BUNDLE group; and 874 o Assign a BUNDLE address:port (previously negotiated or newly 875 suggest) to the offerer tagged "m=" section; and 877 o Include an SDP 'bundle-only' attribute in, and assign a zero port 878 value to, every other bundled "m=" section within the BUNDLE 879 group; and 881 o Include SDP attributes in the bundled "m=" sections following the 882 rules in [Section 7.1.3]; and 884 o Include an SDP 'group:BUNDLE' attribute in the offer; and 886 o Place the identification-tag of each bundled "m=" section in the 887 SDP 'group:BUNDLE' attribute identification-tag list. The offerer 888 BUNDLE-tag indicates the offerer tagged "m=" section. 890 The offerer MUST NOT pick a given bundled "m=" section as the offerer 891 tagged "m=" section if: 893 o The offerer wants to move the "m=" section out of the BUNDLE group 894 [Section 7.5.2]; or 896 o The offerer wants to disable the "m=" section [Section 7.5.3]. 898 The offerer can modify the offerer BUNDLE address:port, add and 899 remove SDP attributes, or modify SDP attribute values, in the 900 subsequent offer. Changes to the offerer BUNDLE address:port and the 901 offerer BUNDLE attributes will (if the offer is accepted by the 902 answerer) be applied to each bundled "m=" section within the BUNDLE 903 group. 905 7.5.1. Adding a Media Description to a BUNDLE group 907 When an offerer generates a subsequent offer, in which it wants to 908 add a bundled "m=" section to a previously negotiated BUNDLE group, 909 the offerer follows the procedures in [Section 7.5]. The offerer 910 either picks the added "m=" section, or an "m=" section previously 911 added to the BUNDLE group, as the offerer tagged "m=" section. 913 7.5.2. Moving a Media Description Out of a BUNDLE Group 915 When an offerer generates a subsequent offer, in which it want to 916 remove a bundled "m=" section from a BUNDLE group, the offerer: 918 o MUST assign a unique address:port to the "m=" section; and 920 o MUST include SDP attributes in the "m=" section following the 921 normal offer/answer rules for each attribute; and 923 o MUST NOT place the identification-tag associated with the "m=" 924 section in the SDP 'group:BUNDLE' attribute identification-tag 925 list associated with the BUNDLE group; and 927 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 928 section. 930 For the other bundled "m=" sections within the BUNDLE group, the 931 offerer follows the procedures in [Section 7.5]. 933 An offerer MUST NOT move an "m=" section from one BUNDLE group to 934 another within a single offer. If the offerer wants to move an "m=" 935 section from one BUNDLE group to another it MUST first move the 936 BUNDLE group out of the current BUNDLE group, and then generate a 937 second offer where the "m=" section is added to another BUNDLE group 938 [Section 7.5.1]. 940 [Section 17.4] shows an example of an offer for moving an "m=" 941 section out of a BUNDLE group. 943 7.5.3. Disabling a Media Description in a BUNDLE Group 945 When an offerer generates a subsequent offer, in which it want to 946 disable a bundled "m=" section from a BUNDLE group, the offerer: 948 o MUST assign a zero port value to the "m=" section, following the 949 procedures in [RFC4566]; and 951 o MUST NOT place the identification-tag associated with the "m=" 952 section in the SDP 'group:BUNDLE' attribute identification-tag 953 list associated with the BUNDLE group; and 955 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 956 section. 958 For the other bundled "m=" sections within the BUNDLE group, the 959 offerer follows the procedures in [Section 7.5]. 961 [Section 17.5] shows an example of an offer and answer for disabling 962 an "m=" section within a BUNDLE group. 964 8. Protocol Identification 966 Each "m=" section within a BUNDLE group MUST use the same transport- 967 layer protocol. If bundled "m=" sections use different upper-layer 968 protocols on top of the transport-layer protocol, there MUST exist a 969 publicly available specification which describes a mechanism how to 970 associate received data with the correct protocol for this particular 971 protocol combination. 973 In addition, if received data can be associated with more than one 974 bundled "m=" section, there MUST exist a publicly available 975 specification which describes a mechanism for associating the 976 received data with the correct "m=" section. 978 This document describes a mechanism to identify the protocol of 979 received data among the STUN, DTLS and SRTP protocols (in any 980 combination), when UDP is used as transport-layer protocol, but it 981 does not describe how to identify different protocols transported on 982 DTLS. While the mechanism is generally applicable to other protocols 983 and transport-layer protocols, any such use requires further 984 specification around how to multiplex multiple protocols on a given 985 transport-layer protocol, and how to associate received data with the 986 correct protocols. 988 8.1. STUN, DTLS, SRTP 990 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 991 protocol of a received packet among the STUN, DTLS and SRTP protocols 992 (in any combination). If an offer or answer includes a bundled "m=" 993 section that represents these protocols, the offerer or answerer MUST 994 support the mechanism described in [RFC5764], and no explicit 995 negotiation is required in order to indicate support and usage of the 996 mechanism. 998 [RFC5764] does not describe how to identify different protocols 999 transported on DTLS, only how to identify the DTLS protocol itself. 1000 If multiple protocols are transported on DTLS, there MUST exist a 1001 specification describing a mechanism for identifying each individual 1002 protocol. In addition, if a received DTLS packet can be associated 1003 with more than one "m=" section, there MUST exist a specification 1004 which describes a mechanism for associating the received DTLS packets 1005 with the correct "m=" section. 1007 [Section 9.2] describes how to associate the packets in a received 1008 SRTP stream with the correct "m=" section. 1010 9. RTP Considerations 1012 9.1. Single RTP Session 1014 All RTP-based media within a single BUNDLE group belong to a single 1015 RTP session [RFC3550]. 1017 Since a single BUNDLE transport is used for sending and receiving 1018 bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for 1019 RTP-based bundled media. 1021 Since a single RTP session is used for each BUNDLE group, all "m=" 1022 sections representing RTP-based media within a BUNDLE group will 1023 share a single SSRC numbering space [RFC3550]. 1025 The following rules and restrictions apply for a single RTP session: 1027 o A specific payload type value can be used in multiple bundled "m=" 1028 sections only if each codec associated with the payload type 1029 number shares an identical codec configuration [Section 9.1.1]. 1031 o The proto value in each bundled RTP-based "m=" section MUST be 1032 identical (e.g., RTP/AVPF). 1034 o The RTP MID header extension MUST be enabled, by including an SDP 1035 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 1036 hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section 1037 in every offer and answer. 1039 o A given SSRC MUST NOT transmit RTP packets using payload types 1040 that originate from different bundled "m=" sections. 1042 NOTE: The last bullet above is to avoid sending multiple media types 1043 from the same SSRC. If transmission of multiple media types are done 1044 with time overlap, RTP and RTCP fail to function. Even if done in 1045 proper sequence this causes RTP Timestamp rate switching issues 1046 [RFC7160]. However, once an SSRC has left the RTP session (by 1047 sending an RTCP BYE packet), that SSRC can be reused by another 1048 source (possibly associated with a different bundled "m=" section) 1049 after a delay of 5 RTCP reporting intervals (the delay is to ensure 1050 the SSRC has timed out, in case the RTCP BYE packet was lost 1051 [RFC3550]). 1053 [RFC7657] defines Differentiated Services (Diffserv) considerations 1054 for RTP-based bundled media sent using a mixture of Diffserv 1055 Codepoints. 1057 9.1.1. Payload Type (PT) Value Reuse 1059 Multiple bundled "m=" sections might describe RTP based media. As 1060 all RTP based media associated with a BUNDLE group belong to the same 1061 RTP session, in order for a given payload type value to be used 1062 inside more than one bundled "m=" section, all codecs associated with 1063 the payload type number MUST share an identical codec configuration. 1064 This means that the codecs MUST share the same media type, encoding 1065 name, clock rate and any parameter that can affect the codec 1066 configuration and packetization. 1067 [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose 1068 attribute values are required to be identical for all codecs that use 1069 the same payload type value. 1071 9.2. Associating RTP/RTCP Streams with the Correct SDP Media 1072 Description 1074 As described in [RFC3550], RTP packets are associated with RTP 1075 streams [RFC7656]. Each RTP stream is identified by an SSRC value, 1076 and each RTP packet includes an SSRC field that is used to associate 1077 the packet with the correct RTP stream. RTCP packets also use SSRCs 1078 to identify which RTP streams the packet relates to. However, a RTCP 1079 packet can contain multiple SSRC fields, in the course of providing 1080 feedback or reports on different RTP streams, and therefore can be 1081 associated with multiple such streams. 1083 In order to be able to process received RTP/RTCP packets correctly, 1084 it MUST be possible to associate an RTP stream with the correct "m=" 1085 section, as the "m=" section and SDP attributes associated with the 1086 "m=" section contains information needed to process the packets. 1088 As all RTP streams associated with a BUNDLE group use the same 1089 transport for sending and receiving RTP/RTCP packets, the local 1090 address:port combination part of the transport cannot be used to 1091 associate an RTP stream with the correct "m=" section. In addition, 1092 multiple RTP streams might be associated with the same "m=" section. 1094 An offerer and answerer can inform each other which SSRC values they 1095 will use for an RTP stream by using the SDP 'ssrc' attribute 1096 [RFC5576]. However, an offerer will not know which SSRC values the 1097 answerer will use until the offerer has received the answer providing 1098 that information. Due to this, before the offerer has received the 1099 answer, the offerer will not be able to associate an RTP stream with 1100 the correct "m=" section using the SSRC value associated with the RTP 1101 stream. In addition, the offerer and answerer may start using new 1102 SSRC values mid-session, without informing each other using the SDP 1103 'ssrc' attribute. 1105 In order for an offerer and answerer to always be able to associate 1106 an RTP stream with the correct "m=" section, the offerer and answerer 1107 using the BUNDLE extension MUST support the mechanism defined in 1108 Section 14, where the offerer and answerer insert the identification- 1109 tag associated with an "m=" section (provided by the remote peer) 1110 into RTP and RTCP packets associated with a BUNDLE group. 1112 When using this mechanism, the mapping from an SSRC to an 1113 identification-tag is carried in RTP header extensions or RTCP SDES 1114 packets, as specified in Section 14. Since a compound RTCP packet 1115 can contain multiple RTCP SDES packets, and each RTCP SDES packet can 1116 contain multiple chunks, a single RTCP packet can contain several 1117 SSRC to identification-tag mappings. The offerer and answerer 1118 maintain tables used for routing that are updated each time an RTP/ 1119 RTCP packet contains new information that affects how packets are to 1120 be routed. 1122 However, some legacy implementations may not include this 1123 identification-tag in their RTP and RTCP traffic when using the 1124 BUNDLE mechanism, and instead use a payload type based mechanism to 1125 associate RTP streams with SDP "m=" sections. In this situation, 1126 each "m=" section needs to use unique payload type values, in order 1127 for the payload type to be a reliable indicator of the relevant "m=" 1128 section for the RTP stream. If an implementation fails to ensure 1129 unique payload type values it will be impossible to associate the RTP 1130 stream using that payload type value to a particular "m=" section. 1131 Note that when using the payload type to associate RTP streams with 1132 "m=" sections an RTP stream, identified by its SSRC, will be mapped 1133 to an "m=" section when the first packet of that RTP stream is 1134 received, and the mapping will not be changed even if the payload 1135 type used by that RTP stream changes. In other words, the SSRC 1136 cannot "move" to a different "m=" section simply by changing the 1137 payload type. 1139 Applications can implement RTP stacks in many different ways. The 1140 algorithm below details one way that RTP streams can be associated 1141 with "m=" sections, but is not meant to be prescriptive about exactly 1142 how an RTP stack needs to be implemented. Applications MAY use any 1143 algorithm that achieves equivalent results to those described in the 1144 algorithm below. 1146 To prepare to associate RTP streams with the correct "m=" section, 1147 the following steps MUST be followed for each BUNDLE group: 1149 Construct a table mapping MID to "m=" section for each "m=" 1150 section in this BUNDLE group. Note that an "m=" section may only 1151 have one MID. 1153 Construct a table mapping SSRCs of incoming RTP streams to "m=" 1154 section for each "m=" section in this BUNDLE group and for each 1155 SSRC configured for receiving in that "m=" section. 1157 Construct a table mapping the SSRC of each outgoing RTP stream to 1158 "m=" section for each "m=" section in this BUNDLE group and for 1159 each SSRC configured for sending in that "m=" section. 1161 Construct a table mapping payload type to "m=" section for each 1162 "m=" section in the BUNDLE group and for each payload type 1163 configured for receiving in that "m=" section. If any payload 1164 type is configured for receiving in more than one "m=" section in 1165 the BUNDLE group, do not include it in the table, as it cannot be 1166 used to uniquely identify an "m=" section. 1168 Note that for each of these tables, there can only be one mapping 1169 for any given key (MID, SSRC, or PT). In other words, the tables 1170 are not multimaps. 1172 As "m=" sections are added or removed from the BUNDLE groups, or 1173 their configurations are changed, the tables above MUST also be 1174 updated. 1176 When an RTP packet is received, it MUST be delivered to the RTP 1177 stream corresponding to its SSRC. That RTP stream MUST then be 1178 associated with the correct "m=" section within a BUNDLE group, for 1179 additional processing, according to the following steps: 1181 If the MID associated with the RTP stream is not in the table 1182 mapping MID to "m=" section, then the RTP stream is not decoded 1183 and the payload data is discarded. 1185 If the packet has a MID, and the packet's extended sequence number 1186 is greater than that of the last MID update, as discussed in 1187 [RFC7941], Section 4.2.6, update the MID associated with the RTP 1188 stream to match the MID carried in the RTP packet, then update the 1189 mapping tables to include an entry that maps the SSRC of that RTP 1190 stream to the "m=" section for that MID. 1192 If the SSRC of the RTP stream is in the incoming SSRC mapping 1193 table, check that the payload type used by the RTP stream matches 1194 a payload type included on the matching "m=" section. If so, 1195 associate the RTP stream with that "m=" section. Otherwise, the 1196 RTP stream is not decoded and the payload data is discarded. 1198 If the payload type used by the RTP stream is in the payload type 1199 table, update the incoming SSRC mapping table to include an entry 1200 that maps the RTP stream's SSRC to the "m=" section for that 1201 payload type. Associate the RTP stream with the corresponding 1202 "m=" section. 1204 Otherwise, mark the RTP stream as not for decoding and discard the 1205 payload. 1207 If the RTP packet contains one or more contributing source (CSRC) 1208 identifiers, then each CSRC is looked up in the incoming SSRC table 1209 and a copy of the RTP packet is associated with the corresponding 1210 "m=" section for additional processing. 1212 For each RTCP packet received (including each RTCP packet that is 1213 part of a compound RTCP packet), the packet is processed as usual by 1214 the RTP layer, then associated with the appropriate "m=" sections, 1215 and processed for the RTP streams represented by those "m=" sections. 1216 This routing is type-dependent, as each kind of RTCP packet has its 1217 own mechanism for associating it with the relevant RTP streams. 1219 RTCP packets that cannot be associated with an appropriate "m=" 1220 section MUST still be processed as usual by the RTP layer, updating 1221 the metadata associated with the corresponding RTP streams. This 1222 situation can occur with certain multiparty RTP topologies, or when 1223 RTCP packets are sent containing a subset of the SDES information. 1225 Additional rules for processing various types of RTCP packets are 1226 explained below. 1228 If the RTCP packet is of type SDES, for each chunk in the packet 1229 whose SSRC is found in the incoming SSRC table, deliver a copy of 1230 the SDES packet to the "m=" section associated with that SSRC. In 1231 addition, for any SDES MID items contained in these chunks, if the 1232 MID is found in the table mapping MID to "m=" section, update the 1233 incoming SSRC table to include an entry that maps the RTP stream 1234 associated with the chunk's SSRC to the "m=" section associated 1235 with that MID, unless the packet is older than the packet that 1236 most recently updated the mapping for this SSRC, as discussed in 1237 [RFC7941], Section 4.2.6. 1239 Note that if an SDES packet is received as part of a compound RTCP 1240 packet, the SSRC to "m=" section mapping might not exist until the 1241 SDES packet is handled (e.g., in the case where RTCP for a source 1242 is received before any RTP packets). Therefore, it can be 1243 beneficial for an implementation to delay RTCP packet routing, 1244 such that it either prioritizes processing of the SDES item to 1245 generate or update the mapping, or buffers the RTCP information 1246 that needs to be routed until the SDES item(s) has been processed. 1247 If the implementation is unable to follow this recommendation, the 1248 consequence could be that some RTCP information from this 1249 particular RTCP compound packet is not provided to higher layers. 1250 The impact from this is likely minor, when this information 1251 relates to a future incoming RTP stream. 1253 If the RTCP packet is of type BYE, it indicates that the RTP 1254 streams referenced in the packet are ending. Therefore, for each 1255 SSRC indicated in the packet that is found in the incoming SSRC 1256 table, first deliver a copy of the BYE packet to the "m=" section 1257 associated with that SSRC, then remove the entry for that SSRC 1258 from the incoming SSRC table after an appropriate delay to account 1259 for "straggler packets", as specified in [RFC3550], Section 6.2.1. 1261 If the RTCP packet is of type SR or RR, for each report block in 1262 the report whose "SSRC of source" is found in the outgoing SSRC 1263 table, deliver a copy of the SR or RR packet to the "m=" section 1264 associated with that SSRC. In addition, if the packet is of type 1265 SR, and the sender SSRC for the packet is found in the incoming 1266 SSRC table, deliver a copy of the SR packet to the "m=" section 1267 associated with that SSRC. 1269 If the implementation supports RTCP XR and the packet is of type 1270 XR, as defined in [RFC3611], for each report block in the report 1271 whose "SSRC of source" is found in the outgoing SSRC table, 1272 deliver a copy of the XR packet to the "m=" section associated 1273 with that SSRC. In addition, if the sender SSRC for the packet is 1274 found in the incoming SSRC table, deliver a copy of the XR packet 1275 to the "m=" section associated with that SSRC. 1277 If the RTCP packet is a feedback message of type RTPFB or PSFB, as 1278 defined in [RFC4585], it will contain a media source SSRC, and 1279 this SSRC is used for routing certain subtypes of feedback 1280 messages. However, several subtypes of PSFB and RTPFB messages 1281 include target SSRC(s) in a section called Feedback Control 1282 Information (FCI). For these messages, the target SSRC(s) are 1283 used for routing. 1285 If the RTCP packet is a feedback packet that does not include 1286 target SSRCs in its FCI section, and the media source SSRC is 1287 found in the outgoing SSRC table, deliver the feedback packet to 1288 the "m=" section associated with that SSRC. RTPFB and PSFB types 1289 that are handled in this way include: 1291 Generic NACK: [RFC4585] (PT=RTPFB, FMT=1). 1293 Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1). 1295 Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2). 1297 Reference Picture Selection Indication (RPSI): [RFC4585] 1298 (PT=PSFB, FMT=3). 1300 If the RTCP packet is a feedback message that does include target 1301 SSRC(s) in its FCI section, it can either be a request or a 1302 notification. Requests reference a RTP stream that is being sent 1303 by the message recipient, whereas notifications are responses to 1304 an earlier request, and therefore reference a RTP stream that is 1305 being received by the message recipient. 1307 If the RTCP packet is a feedback request that includes target 1308 SSRC(s), for each target SSRC that is found in the outgoing SSRC 1309 table, deliver a copy of the RTCP packet to the "m=" section 1310 associated with that SSRC. PSFB and RTPFB types that are handled 1311 in this way include: 1313 Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). 1315 Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, 1316 FMT=5). 1318 H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, 1319 FMT=7). 1321 Temporary Maximum Media Bit Rate Request (TMMBR): [RFC5104] 1322 (PT=RTPFB, FMT=3). 1324 Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, 1325 FMT=10). 1327 If the RTCP packet is a feedback notification that includes target 1328 SSRC(s), for each target SSRC that is found in the incoming SSRC 1329 table, deliver a copy of the RTCP packet to the "m=" section 1330 associated with the RTP stream with matching SSRC. PSFB and RTPFB 1331 types that are handled in this way include: 1333 Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] 1334 (PT=PSFB, FMT=6). This message is a notification in response 1335 to a prior TSTR. 1337 Temporary Maximum Media Bit Rate Notification (TMMBN): [RFC5104] 1338 (PT=RTPFB, FMT=4). This message is a notification in response 1339 to a prior TMMBR, but can also be sent unsolicited. 1341 If the RTCP packet is of type APP, then it is handled in an 1342 application specific manner. If the application does not 1343 recognise the APP packet, then it MUST be discarded. 1345 9.3. RTP/RTCP Multiplexing 1347 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 1348 multiplexing [RFC5761] for the RTP-based bundled media (i.e., the 1349 same transport will be used for both RTP packets and RTCP packets). 1350 In addition, the offerer and answerer MUST support the SDP 'rtcp-mux- 1351 only' attribute [I-D.ietf-mmusic-mux-exclusive]. 1353 9.3.1. SDP Offer/Answer Procedures 1355 This section describes how an offerer and answerer use the SDP 'rtcp- 1356 mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute 1357 [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP 1358 multiplexing for RTP-based bundled media. 1360 RTP/RTCP multiplexing only applies to RTP-based media. However, as 1361 described in Section 7.1.3, within an offer or answer the SDP 'rtcp- 1362 mux' and SDP 'rtcp-mux-only' attributes might be included in a 1363 bundled "m=" section for non-RTP-based media (if such "m=" section is 1364 the offerer tagged "m=" section or answerer tagged "m=" section). 1366 9.3.1.1. Generating the Initial SDP Offer 1368 When an offerer generates an initial offer, if the offer contains one 1369 or more bundled "m=" sections for RTP-based media (or, if there is a 1370 chance that "m=" sections for RTP-based media will later be added to 1371 the BUNDLE group), the offerer MUST include an SDP 'rtcp-mux' 1372 attribute [RFC5761] in each bundled "m=" section (excluding any 1373 bundle-only "m=" sections). In addition, the offerer MAY include an 1374 SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] in one 1375 or more bundled "m=" sections for RTP-based media. 1377 NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute 1378 depends on whether the offerer supports fallback to usage of a 1379 separate port for RTCP in case the answerer moves one or more "m=" 1380 sections for RTP-based media out of the BUNDLE group in the answer. 1382 NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the 1383 bundled "m=" sections, but does not include an SDP 'rtcp-mux-only' 1384 attribute, the offerer can also include an SDP 'rtcp' attribute 1385 [RFC3605] in one or more RTP-based bundled "m=" sections in order to 1386 provide a fallback port for RTCP, as described in [RFC5761]. 1387 However, the fallback port will only be applied to "m=" sections for 1388 RTP-based media that are moved out of the BUNDLE group by the 1389 answerer. 1391 In the initial offer, the address:port combination for RTCP MUST be 1392 unique in each bundled "m=" section for RTP-based media (excluding a 1393 bundle-only "m=" section), similar to RTP. 1395 9.3.1.2. Generating the SDP Answer 1397 When an answerer generates an answer, if the answerer supports RTP- 1398 based media, and if a bundled "m=" section in the corresponding offer 1399 contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage 1400 of RTP/RTCP multiplexing, even if there currently are no bundled "m=" 1401 sections for RTP-based media within the BUNDLE group. The answerer 1402 MUST include an SDP 'rtcp-mux' attribute in the answerer tagged "m=" 1403 section, following the procedures for BUNDLE attributes 1404 [Section 7.1.3]. In addition, if the "m=" section that is selected 1405 as the offerer tagged "m=" section contained an SDP "rtcp-mux-only" 1406 attribute, the answerer MUST include an SDP "rtcp-mux-only" attribute 1407 in the answerer tagged "m=" section. 1409 In an initial offer, if the suggested offerer tagged "m=" section 1410 contained an SDP 'rtcp-mux-only' attribute, the "m=" section was for 1411 RTP-based media, and the answerer does not accept the "m=" section in 1412 the created BUNDLE group, the answerer MUST either move the "m=" 1413 section out of the BUNDLE group [Section 7.3.3], include the 1414 attribute in the moved "m=" section and enable RTP/RTCP multiplexing 1415 for the media associated with the "m=" section, or reject the "m=" 1416 section [Section 7.3.4]. 1418 The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled 1419 "m=" section in the answer. The answerer will use the port value of 1420 the tagged offerer "m=" section sending RTP and RTCP packets 1421 associated with RTP-based bundled media towards the offerer. 1423 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1424 negotiated in a previous offer/answer exchange, the answerer MUST 1425 include an SDP 'rtcp-mux' attribute in the answerer tagged "m=" 1426 section . It is not possible to disable RTP/RTCP multiplexing within 1427 a BUNDLE group. 1429 9.3.1.3. Offerer Processing of the SDP Answer 1431 When an offerer receives an answer, if the answerer has accepted the 1432 usage of RTP/RTCP multiplexing [Section 9.3.1.2], the answerer 1433 follows the procedures for RTP/RTCP multiplexing defined in 1434 [RFC5761]. The offerer will use the port value of the answerer 1435 tagged "m=" section for sending RTP and RTCP packets associated with 1436 RTP-based bundled media towards the answerer. 1438 NOTE: It is considered a protocol error if the answerer has not 1439 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" 1440 sections that the answerer included in the BUNDLE group. 1442 9.3.1.4. Modifying the Session 1444 When an offerer generates a subsequent offer, the offerer MUST 1445 include an SDP 'rtcp-mux' attribute in the offerer tagged "m=" 1446 section, following the procedures for IDENTICAL multiplexing category 1447 attributes in Section 7.1.3. 1449 10. ICE Considerations 1451 This section describes how to use the BUNDLE grouping extension 1452 together with the Interactive Connectivity Establishment (ICE) 1453 mechanism [I-D.ietf-ice-rfc5245bis]. 1455 The generic procedures for negotiating usage of ICE using SDP, 1456 defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE 1457 with BUNDLE, with the following exceptions: 1459 o When the BUNDLE transport has been established, ICE connectivity 1460 checks and keep-alives only need to be performed for the BUNDLE 1461 transport, instead of per individual bundled "m=" section within 1462 the BUNDLE group. 1464 o The generic SDP attribute offer/answer considerations 1465 [Section 7.1.3] also apply to ICE-related attributes. Therefore, 1466 when an offer sends an initial offer (in order to negotiate a 1467 BUNDLE group) the offerer include ICE-related media-level 1468 attributes in each bundled "m=" section (excluding any bundle-only 1469 "m=" section), and each "m=" section MUST contain unique ICE 1470 properties. When an answerer generates an answer (initial or 1471 subsequent) that contains a BUNDLE group, and when an offerer 1472 sends a subsequent offer that contains a BUNDLE group, ICE-related 1473 media-level attributes are only included in the tagged "m=" 1474 section (suggested offerer tagged "m=" section or answerer tagged 1475 "m=" section), and the ICE properties are applied to each bundled 1476 "m=" section within the BUNDLE group. 1478 NOTE: Most ICE-related media-level SDP attributes belong to the 1479 TRANSPORT multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes], 1480 and the generic SDP attribute offer/answer considerations for 1481 TRANSPORT multiplexing category apply to the attributes. However, in 1482 the case of ICE-related attributes, the same considerations also 1483 apply to ICE-related media-level attributes that belong to other 1484 multiplexing categories. 1486 NOTE: The following ICE-related media-level SDP attributes are 1487 defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidate', 'remote- 1488 candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- 1489 pacing'. 1491 Initially, before ICE has produced selected candidate pairs that will 1492 be used for media, there might be multiple transports established (if 1493 multiple candidate pairs are tested). Once ICE has selected 1494 candidate pairs, they form the BUNDLE transport. 1496 Support and usage of ICE mechanism together with the BUNDLE extension 1497 is OPTIONAL, and the procedures in this section only apply when the 1498 ICE mechanism is used. Note that applications might mandate usage of 1499 the ICE mechanism even if the BUNDLE extension is not used. 1501 NOTE: If the trickle ICE mechanism [I-D.ietf-mmusic-trickle-ice-sip] 1502 is used, an offerer and answerer might assign a port value of '9', 1503 and an IPv4 address of '0.0.0.0' (or, the IPv6 equivalent '::') to 1504 multiple bundled "m=" sections in the initial offer. The offerer and 1505 answerer will follow the normal procedures for generating the offers 1506 and answers, including picking a bundled "m=" section as the 1507 suggested offerer tagged "m=" section, selecting the tagged "m=" 1508 sections etc. The only difference is that media can not be sent 1509 until one or more candidates have been provided. Once a BUNDLE group 1510 has been negotiated, trickled candidates associated with a bundled 1511 "m=" section will be applied to all bundled "m=" sections within the 1512 BUNDLE group. 1514 11. DTLS Considerations 1516 One or more media streams within a BUNDLE group might use the 1517 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1518 to encrypt the data, or to negotiate encryption keys if another 1519 encryption mechanism is used to encrypt media. 1521 When DTLS is used within a BUNDLE group, the following rules apply: 1523 o There can only be one DTLS association [RFC6347] associated with 1524 the BUNDLE group; and 1526 o Each usage of the DTLS association within the BUNDLE group MUST 1527 use the same mechanism for determining which endpoints (the 1528 offerer or answerer) become DTLS client and DTLS server; and 1530 o Each usage of the DTLS association within the BUNDLE group MUST 1531 use the same mechanism for determining whether an offer or answer 1532 will trigger the establishment of a new DTLS association, or 1533 whether an existing DTLS association will be used; and 1535 o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include 1536 the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message 1537 [RFC5764]. The client MUST include the extension even if the 1538 usage of DTLS-SRTP is not negotiated as part of the multimedia 1539 session (e.g., SIP session [RFC3261]). 1541 NOTE: The inclusion of the 'use_srtp' extension during the initial 1542 DTLS handshake ensures that a DTLS renegotiation will not be required 1543 in order to include the extension, in case DTLS-SRTP encrypted media 1544 is added to the BUNDLE group later during the multimedia session. 1546 12. RTP Header Extensions Consideration 1548 When [RFC8285] RTP header extensions are used in the context of this 1549 specification, the identifier used for a given extension MUST 1550 identify the same extension across all the bundled media 1551 descriptions. 1553 13. Update to RFC 3264 1555 This section updates RFC 3264, in order to allow extensions to define 1556 the usage of a zero port value in offers and answers for other 1557 purposes than removing or disabling media streams. The following 1558 sections of RFC 3264 are updated: 1560 o Section 5.1 (Unicast Streams). 1562 o Section 8.4 (Putting a Unicast Media Stream on Hold). 1564 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 1566 For recvonly and sendrecv streams, the port number and address in the 1567 offer indicate where the offerer would like to receive the media 1568 stream. For sendonly RTP streams, the address and port number 1569 indirectly indicate where the offerer wants to receive RTCP reports. 1570 Unless there is an explicit indication otherwise, reports are sent to 1571 the port number one higher than the number indicated. The IP address 1572 and port present in the offer indicate nothing about the source IP 1573 address and source port of RTP and RTCP packets that will be sent by 1574 the offerer. A port number of zero in the offer indicates that the 1575 stream is offered but MUST NOT be used. This has no useful semantics 1576 in an initial offer, but is allowed for reasons of completeness, 1577 since the answer can contain a zero port indicating a rejected stream 1578 (Section 6). Furthermore, existing streams can be terminated by 1579 setting the port to zero (Section 8). In general, a port number of 1580 zero indicates that the media stream is not wanted. 1582 13.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 1584 For recvonly and sendrecv streams, the port number and address in the 1585 offer indicate where the offerer would like to receive the media 1586 stream. For sendonly RTP streams, the address and port number 1587 indirectly indicate where the offerer wants to receive RTCP reports. 1588 Unless there is an explicit indication otherwise, reports are sent to 1589 the port number one higher than the number indicated. The IP address 1590 and port present in the offer indicate nothing about the source IP 1591 address and source port of RTP and RTCP packets that will be sent by 1592 the offerer. A port number of zero in the offer by default indicates 1593 that the stream is offered but MUST NOT be used, but an extension 1594 mechanism might specify different semantics for the usage of a zero 1595 port value. Furthermore, existing streams can be terminated by 1596 setting the port to zero (Section 8). In general, a port number of 1597 zero by default indicates that the media stream is not wanted. 1599 13.3. Original text of section 8.4 (6th paragraph) of RFC 3264 1601 RFC 2543 [10] specified that placing a user on hold was accomplished 1602 by setting the connection address to 0.0.0.0. Its usage for putting 1603 a call on hold is no longer recommended, since it doesn't allow for 1604 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1605 with connection oriented media. However, it can be useful in an 1606 initial offer when the offerer knows it wants to use a particular set 1607 of media streams and formats, but doesn't know the addresses and 1608 ports at the time of the offer. Of course, when used, the port 1609 number MUST NOT be zero, which would specify that the stream has been 1610 disabled. An agent MUST be capable of receiving SDP with a 1611 connection address of 0.0.0.0, in which case it means that neither 1612 RTP nor RTCP is to be sent to the peer. 1614 13.4. New text replacing section 8.4 (6th paragraph) of RFC 3264 1616 RFC 2543 [10] specified that placing a user on hold was accomplished 1617 by setting the connection address to 0.0.0.0. Its usage for putting 1618 a call on hold is no longer recommended, since it doesn't allow for 1619 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1620 with connection oriented media. However, it can be useful in an 1621 initial offer when the offerer knows it wants to use a particular set 1622 of media streams and formats, but doesn't know the addresses and 1623 ports at the time of the offer. Of course, when used, the port 1624 number MUST NOT be zero, if it would specify that the stream has been 1625 disabled. However, an extension mechanism might specify different 1626 semantics of the zero port number usage. An agent MUST be capable of 1627 receiving SDP with a connection address of 0.0.0.0, in which case it 1628 means that neither RTP nor RTCP is to be sent to the peer. 1630 14. RTP/RTCP extensions for identification-tag transport 1632 SDP Offerers and Answerers [RFC3264] can associate identification- 1633 tags with "m=" sections within SDP Offers and Answers, using the 1634 procedures in [RFC5888]. Each identification-tag uniquely represents 1635 an "m=" section. 1637 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1638 used to carry identification-tags within RTCP SDES packets. This 1639 section also defines a new RTP SDES header extension [RFC7941], which 1640 is used to carry the 'MID' RTCP SDES item in RTP packets. 1642 The SDES item and RTP SDES header extension make it possible for a 1643 receiver to associate each RTP stream with a specific "m=" section, 1644 with which the receiver has associated an identification-tag, even if 1645 those "m=" sections are part of the same RTP session. The RTP SDES 1646 header extension also ensures that the media recipient gets the 1647 identification-tag upon receipt of the first decodable media and is 1648 able to associate the media with the correct application. 1650 A media recipient informs the media sender about the identification- 1651 tag associated with an "m=" section through the use of an 'mid' 1652 attribute [RFC5888]. The media sender then inserts the 1653 identification-tag in RTCP and RTP packets sent to the media 1654 recipient. 1656 NOTE: This text above defines how identification-tags are carried in 1657 SDP Offers and Answers. The usage of other signaling protocols for 1658 carrying identification-tags is not prevented, but the usage of such 1659 protocols is outside the scope of this document. 1661 [RFC3550] defines general procedures regarding the RTCP transmission 1662 interval. The RTCP MID SDES item SHOULD be sent in the first few 1663 RTCP packets sent after joining the session, and SHOULD be sent 1664 regularly thereafter. The exact number of RTCP packets in which this 1665 SDES item is sent is intentionally not specified here, as it will 1666 depend on the expected packet loss rate, the RTCP reporting interval, 1667 and the allowable overhead. 1669 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1670 be included in some RTP packets at the start of the session and 1671 whenever the SSRC changes. It might also be useful to include the 1672 header extension in RTP packets that comprise access points in the 1673 media (e.g., with video I-frames). The exact number of RTP packets 1674 in which this header extension is sent is intentionally not specified 1675 here, as it will depend on expected packet loss rate and loss 1676 patterns, the overhead the application can tolerate, and the 1677 importance of immediate receipt of the identification-tag. 1679 For robustness, endpoints need to be prepared for situations where 1680 the reception of the identification-tag is delayed, and SHOULD NOT 1681 terminate sessions in such cases, as the identification-tag is likely 1682 to arrive soon. 1684 14.1. RTCP MID SDES Item 1686 0 1 2 3 1687 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 1688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1689 | MID=TBD | length | identification-tag ... 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP. 1694 The identification-tag is not zero terminated. 1696 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1697 identifier value.] 1699 14.2. RTP SDES Header Extension For MID 1701 The payload, containing the identification-tag, of the RTP SDES 1702 header extension element can be encoded using either the one-byte or 1703 two-byte header [RFC7941]. The identification-tag payload is UTF-8 1704 encoded, as in SDP. 1706 The identification-tag is not zero terminated. Note, that the set of 1707 header extensions included in the packet needs to be padded to the 1708 next 32-bit boundary using zero bytes [RFC8285]. 1710 As the identification-tag is included in either an RTCP SDES item or 1711 an RTP SDES header extension, or both, there needs to be some 1712 consideration about the packet expansion caused by the 1713 identification-tag. To avoid Maximum Transmission Unit (MTU) issues 1714 for the RTP packets, the header extension's size needs to be taken 1715 into account when encoding the media. 1717 It is recommended that the identification-tag is kept short. Due to 1718 the properties of the RTP header extension mechanism, when using the 1719 one-byte header, a tag that is 1-3 bytes will result in a minimal 1720 number of 32-bit words used for the RTP SDES header extension, in 1721 case no other header extensions are included at the same time. Note, 1722 do take into account that some single characters when UTF-8 encoded 1723 will result in multiple octets. The identification-tag MUST NOT 1724 contain any user information, and applications SHALL avoid generating 1725 the identification-tag using a pattern that enables user- or 1726 application identification. 1728 15. IANA Considerations 1730 15.1. New SDES item 1732 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1733 document.] 1735 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1736 identifier value.] 1738 This document adds the MID SDES item to the IANA "RTP SDES item 1739 types" registry as follows: 1741 Value: TBD 1742 Abbrev.: MID 1743 Name: Media Identification 1744 Reference: RFCXXXX 1746 15.2. New RTP SDES Header Extension URI 1748 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1749 document.] 1751 This document defines a new extension URI in the RTP SDES Compact 1752 Header Extensions sub-registry of the RTP Compact Header Extensions 1753 registry sub-registry, according to the following data: 1755 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1756 Description: Media identification 1757 Contact: IESG (iesg@ietf.org) 1758 Reference: RFCXXXX 1760 The SDES item does not reveal privacy information about the users. 1761 It is simply used to associate RTP-based media with the correct SDP 1762 media description ("m=" section) in the SDP used to negotiate the 1763 media. 1765 The purpose of the extension is for the offerer to be able to 1766 associate received multiplexed RTP-based media before the offerer 1767 receives the associated SDP answer. 1769 15.3. New SDP Attribute 1771 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1772 document.] 1774 This document defines a new SDP media-level attribute, 'bundle-only', 1775 according to the following data: 1777 Attribute name: bundle-only 1778 Type of attribute: media 1779 Subject to charset: No 1780 Purpose: Request a media description to be accepted 1781 in the answer only if kept within a BUNDLE 1782 group by the answerer. 1783 Appropriate values: N/A 1784 Contact name: IESG 1785 Contact e-mail: iesg@ietf.org 1786 Reference: RFCXXXX 1787 Mux category: NORMAL 1789 15.4. New SDP Group Semantics 1791 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1792 document.] 1794 This document registers the following semantics with IANA in the 1795 "Semantics for the "group" SDP Attribute" subregistry (under the 1796 "Session Description Protocol (SDP) Parameters" registry: 1798 Semantics Token Reference 1799 ------------------------------------- ------ --------- 1800 Media bundling BUNDLE [RFCXXXX] 1802 Mux category: NORMAL 1804 16. Security Considerations 1806 The security considerations defined in [RFC3264] and [RFC5888] apply 1807 to the BUNDLE extension. Bundle does not change which information, 1808 e.g., RTP streams, flows over the network, with the exception of the 1809 usage of the MID SDES item as discussed below. Primarily it changes 1810 which addresses and ports, and thus in which (RTP) sessions the 1811 information is flowing. This affects the security contexts being 1812 used and can cause previously separated information flows to share 1813 the same security context. This has very little impact on the 1814 performance of the security mechanism of the RTP sessions. In cases 1815 where one would have applied different security policies on the 1816 different RTP streams being bundled, or where the parties having 1817 access to the security contexts would have differed between the RTP 1818 streams, additional analysis of the implications are needed before 1819 selecting to apply BUNDLE. 1821 The identification-tag, independent of transport, RTCP SDES packet or 1822 RTP header extension, can expose the value to parties beyond the 1823 signaling chain. Therefore, the identification-tag values MUST be 1824 generated in a fashion that does not leak user information, e.g., 1825 randomly or using a per-bundle group counter, and SHOULD be 3 bytes 1826 or less, to allow them to efficiently fit into the MID RTP header 1827 extension. Note that if implementations use different methods for 1828 generating identification-tags this could enable fingerprinting of 1829 the implementation making it vulnerable to targeted attacks. The 1830 identification-tag is exposed on the RTP stream level when included 1831 in the RTP header extensions, however what it reveals of the RTP 1832 media stream structure of the endpoint and application was already 1833 possible to deduce from the RTP streams without the MID SDES header 1834 extensions. As the identification-tag is also used to route the 1835 media stream to the right application functionality it is important 1836 that the value received is the one intended by the sender, thus 1837 integrity and the authenticity of the source are important to prevent 1838 denial of service on the application. Existing SRTP configurations 1839 and other security mechanisms protecting the whole RTP/RTCP packets 1840 will provide the necessary protection. 1842 When the BUNDLE extension is used, the set of configurations of the 1843 security mechanism used in all the bundled media descriptions will 1844 need to be compatible so that they can be used simultaneously, at 1845 least per direction or endpoint. When using SRTP this will be the 1846 case, at least for the IETF defined key-management solutions due to 1847 their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their 1848 classification in [I-D.ietf-mmusic-sdp-mux-attributes]. 1850 The security considerations of "RTP Header Extension for the RTP 1851 Control Protocol (RTCP) Source Description Items" [RFC7941] requires 1852 that when RTCP is confidentiality protected, then any SDES RTP header 1853 extension carrying an SDES item, such as the MID RTP header 1854 extension, is also protected using commensurate strength algorithms. 1855 However, assuming the above requirements and recommendations are 1856 followed, there are no known significant security risks with leaving 1857 the MID RTP header extension without confidentiality protection. 1858 Therefore, this specification updates RFC 7941 by adding the 1859 exception that this requirement MAY be ignored for the MID RTP header 1860 extension. Security mechanisms for RTP/RTCP are discussed in Options 1861 for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can 1862 provide the necessary security functions of ensuring the integrity 1863 and source authenticity. 1865 17. Examples 1867 17.1. Example: Tagged m= Section Selections 1869 The example below shows: 1871 o An initial offer, in which the offerer wants to negotiate a BUNDLE 1872 group, and indicates the audio m= section as the suggested offerer 1873 tagged "m=" section. 1875 o An initial answer, in which the answerer accepts the creation of 1876 the BUNDLE group, selects the audio m= section in the offer as the 1877 offerer tagged "m=" section, selects the audio "m=" section in the 1878 answer as the answerer tagged "m=" section and assigns the 1879 answerer BUNDLE address:port to that "m=" section. 1881 SDP Offer (1) 1883 v=0 1884 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1885 s= 1886 c=IN IP6 2001:db8::3 1887 t=0 0 1888 a=group:BUNDLE foo bar 1890 m=audio 10000 RTP/AVP 0 8 97 1891 b=AS:200 1892 a=mid:foo 1893 a=rtcp-mux 1894 a=rtpmap:0 PCMU/8000 1895 a=rtpmap:8 PCMA/8000 1896 a=rtpmap:97 iLBC/8000 1897 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1899 m=video 10002 RTP/AVP 31 32 1900 b=AS:1000 1901 a=mid:bar 1902 a=rtcp-mux 1903 a=rtpmap:31 H261/90000 1904 a=rtpmap:32 MPV/90000 1905 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1907 SDP Answer (2) 1909 v=0 1910 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1911 s= 1912 c=IN IP6 2001:db8::1 1913 t=0 0 1914 a=group:BUNDLE foo bar 1916 m=audio 20000 RTP/AVP 0 1917 b=AS:200 1918 a=mid:foo 1919 a=rtcp-mux 1920 a=rtpmap:0 PCMU/8000 1921 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1923 m=video 0 RTP/AVP 32 1924 b=AS:1000 1925 a=mid:bar 1926 a=bundle-only 1927 a=rtpmap:32 MPV/90000 1928 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1930 17.2. Example: BUNDLE Group Rejected 1932 The example below shows: 1934 o An initial offer, in which the offerer wants to negotiate a BUNDLE 1935 group, and indicates the audio m= section as the suggested offerer 1936 tagged "m=" section. 1938 o An initial answer, in which the answerer rejects the creation of 1939 the BUNDLE group, generates a normal answer and assigns a unique 1940 address:port to each "m=" section in the answer. 1942 SDP Offer (1) 1944 v=0 1945 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1946 s= 1947 c=IN IP6 2001:db8::3 1948 t=0 0 1949 a=group:BUNDLE foo bar 1951 m=audio 10000 RTP/AVP 0 8 97 1952 b=AS:200 1953 a=mid:foo 1954 a=rtcp-mux 1955 a=rtpmap:0 PCMU/8000 1956 a=rtpmap:8 PCMA/8000 1957 a=rtpmap:97 iLBC/8000 1958 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1960 m=video 10002 RTP/AVP 31 32 1961 b=AS:1000 1962 a=mid:bar 1963 a=rtcp-mux 1964 a=rtpmap:31 H261/90000 1965 a=rtpmap:32 MPV/90000 1966 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1968 SDP Answer (2) 1970 v=0 1971 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1972 s= 1973 c=IN IP6 2001:db8::1 1974 t=0 0 1976 m=audio 20000 RTP/AVP 0 1977 b=AS:200 1978 a=rtcp-mux 1979 a=rtpmap:0 PCMU/8000 1981 m=video 30000 RTP/AVP 32 1982 b=AS:1000 1983 a=rtcp-mux 1984 a=rtpmap:32 MPV/90000 1986 17.3. Example: Offerer Adds a Media Description to a BUNDLE Group 1988 The example below shows: 1990 o A subsequent offer, in which the offerer adds a new bundled "m=" 1991 section (video), indicated by the "zen" identification-tag, to a 1992 previously negotiated BUNDLE group, indicates the new "m=" section 1993 as the offerer tagged "m=" section and assigns the offerer BUNDLE 1994 address:port to that "m=" section. 1996 o A subsequent answer, in which the answerer indicates the new video 1997 "m=" section in the answer as the answerer tagged "m=" section and 1998 assigns the answerer BUNDLE address:port to that "m=" section. 2000 SDP Offer (1) 2002 v=0 2003 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2004 s= 2005 c=IN IP6 2001:db8::3 2006 t=0 0 2007 a=group:BUNDLE zen foo bar 2009 m=audio 0 RTP/AVP 0 8 97 2010 b=AS:200 2011 a=mid:foo 2012 a=bundle-only 2013 a=rtpmap:0 PCMU/8000 2014 a=rtpmap:8 PCMA/8000 2015 a=rtpmap:97 iLBC/8000 2016 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2018 m=video 0 RTP/AVP 31 32 2019 b=AS:1000 2020 a=mid:bar 2021 a=bundle-only 2022 a=rtpmap:31 H261/90000 2023 a=rtpmap:32 MPV/90000 2024 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2026 m=video 10000 RTP/AVP 66 2027 b=AS:1000 2028 a=mid:zen 2029 a=rtcp-mux 2030 a=rtpmap:66 H261/90000 2031 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2033 SDP Answer (2) 2035 v=0 2036 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2037 s= 2038 c=IN IP6 2001:db8::1 2039 t=0 0 2040 a=group:BUNDLE zen foo bar 2042 m=audio 0 RTP/AVP 0 2043 b=AS:200 2044 a=mid:foo 2045 a=bundle-only 2046 a=rtpmap:0 PCMU/8000 2047 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2049 m=video 0 RTP/AVP 32 2050 b=AS:1000 2051 a=mid:bar 2052 a=bundle-only 2053 a=rtpmap:32 MPV/90000 2054 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2056 m=video 20000 RTP/AVP 66 2057 b=AS:1000 2058 a=mid:zen 2059 a=rtcp-mux 2060 a=rtpmap:66 H261/90000 2061 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2063 17.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 2065 The example below shows: 2067 o A subsequent offer, in which the offerer removes a "m=" section 2068 (video), indicated by the "zen" identification-tag, from a 2069 previously negotiated BUNDLE group, indicates one of the bundled 2070 "m=" sections (audio) remaining in the BUNDLE group as the offerer 2071 tagged "m=" section and assigns the offerer BUNDLE address:port to 2072 that "m=" section. 2074 o A subsequent answer, in which the answerer removes the "m=" 2075 section from the BUNDLE group, indicates the audio "m=" section in 2076 the answer as the answerer tagged "m=" section and assigns the 2077 answerer BUNDLE address:port to that "m=" section. 2079 SDP Offer (1) 2081 v=0 2082 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2083 s= 2084 c=IN IP6 2001:db8::3 2085 t=0 0 2086 a=group:BUNDLE foo bar 2088 m=audio 10000 RTP/AVP 0 8 97 2089 b=AS:200 2090 a=mid:foo 2091 a=rtcp-mux 2092 a=rtpmap:0 PCMU/8000 2093 a=rtpmap:8 PCMA/8000 2094 a=rtpmap:97 iLBC/8000 2095 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2097 m=video 0 RTP/AVP 31 32 2098 b=AS:1000 2099 a=mid:bar 2100 a=bundle-only 2101 a=rtpmap:31 H261/90000 2102 a=rtpmap:32 MPV/90000 2103 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2105 m=video 50000 RTP/AVP 66 2106 b=AS:1000 2107 a=mid:zen 2108 a=rtcp-mux 2109 a=rtpmap:66 H261/90000 2111 SDP Answer (2) 2113 v=0 2114 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2115 s= 2116 c=IN IP6 2001:db8::1 2117 t=0 0 2118 a=group:BUNDLE foo bar 2120 m=audio 20000 RTP/AVP 0 2121 b=AS:200 2122 a=mid:foo 2123 a=rtcp-mux 2124 a=rtpmap:0 PCMU/8000 2125 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2126 m=video 0 RTP/AVP 32 2127 b=AS:1000 2128 a=mid:bar 2129 a=bundle-only 2130 a=rtpmap:32 MPV/90000 2131 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2133 m=video 60000 RTP/AVP 66 2134 b=AS:1000 2135 a=mid:zen 2136 a=rtcp-mux 2137 a=rtpmap:66 H261/90000 2139 17.5. Example: Offerer Disables a Media Description Within a BUNDLE 2140 Group 2142 The example below shows: 2144 o A subsequent offer, in which the offerer disables (by assigning a 2145 zero port value) a "m=" section (video), indicated by the "zen" 2146 identification-tag, from a previously negotiated BUNDLE group, 2147 indicates one of the bundled "m=" sections (audio) remaining 2148 active in the BUNDLE group as the offerer tagged "m=" section and 2149 assigns the offerer BUNDLE address:port to that "m=" section. 2151 o A subsequent answer, in which the answerer disables the "m=" 2152 section, indicates the audio "m=" section in the answer as the 2153 answerer tagged "m=" section and assigns the answerer BUNDLE 2154 address:port to that "m=" section. 2156 SDP Offer (1) 2158 v=0 2159 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2160 s= 2161 t=0 0 2162 a=group:BUNDLE foo bar 2164 m=audio 10000 RTP/AVP 0 8 97 2165 c=IN IP6 2001:db8::3 2166 b=AS:200 2167 a=mid:foo 2168 a=rtcp-mux 2169 a=rtpmap:0 PCMU/8000 2170 a=rtpmap:8 PCMA/8000 2171 a=rtpmap:97 iLBC/8000 2172 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2174 m=video 0 RTP/AVP 31 32 2175 c=IN IP6 2001:db8::3 2176 b=AS:1000 2177 a=mid:bar 2178 a=bundle-only 2179 a=rtpmap:31 H261/90000 2180 a=rtpmap:32 MPV/90000 2181 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2183 m=video 0 RTP/AVP 66 2184 a=mid:zen 2185 a=rtpmap:66 H261/90000 2187 SDP Answer (2) 2189 v=0 2190 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2191 s= 2192 t=0 0 2193 a=group:BUNDLE foo bar 2195 m=audio 20000 RTP/AVP 0 2196 c=IN IP6 2001:db8::1 2197 b=AS:200 2198 a=mid:foo 2199 a=rtcp-mux 2200 a=rtpmap:0 PCMU/8000 2201 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2203 m=video 0 RTP/AVP 32 2204 c=IN IP6 2001:db8::1 2205 b=AS:1000 2206 a=mid:bar 2207 a=bundle-only 2208 a=rtpmap:32 MPV/90000 2209 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2211 m=video 0 RTP/AVP 66 2212 a=mid:zen 2213 a=rtpmap:66 H261/90000 2215 18. Acknowledgements 2217 The usage of the SDP grouping extension for negotiating bundled media 2218 is based on similar alternatives proposed by Harald Alvestrand and 2219 Cullen Jennings. The BUNDLE extension described in this document is 2220 based on the different alternative proposals, and text (e.g., SDP 2221 examples) have been borrowed (and, in some cases, modified) from 2222 those alternative proposals. 2224 The SDP examples are also modified versions from the ones in the 2225 Alvestrand proposal. 2227 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 2228 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 2229 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin 2230 Uberti, Taylor Brandstetter, Byron Campen and Eric Rescorla for 2231 reading the text, and providing useful feedback. 2233 Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus 2234 Westerlund for providing the text for the section on RTP/RTCP stream 2235 association. 2237 Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for 2238 providing help and text on the RTP/RTCP procedures. 2240 Thanks to Charlie Kaufman for performing the Sec-Dir review. 2242 Thanks to Linda Dunbar for performing the Gen-ART review. 2244 Thanks to Spotify for providing music for the countless hours of 2245 document editing. 2247 19. Change Log 2249 [RFC EDITOR NOTE: Please remove this section when publishing] 2251 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-50 2253 o Changes based on IESG reviews. 2255 o - Adding of tagged m- section concept. 2257 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-49 2259 o Changes based on IESG reviews. 2261 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-48 2262 o Changes based on Sec-Dir review by Charlie Kaufman. 2264 o - s/unique address/unique address:port 2266 o Changes based on Gen-ART review by Linda Dunbar. 2268 o Mux category for group:BUNDLE attribute added. 2270 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-47 2272 o Changes based on AD review by Ben Campbell. 2274 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-46 2276 o Pre-RFC5378 disclaimer removed put back. 2278 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-45 2280 o Mux category for SDP 'group:BUNDLE' attribute added. 2282 o https://github.com/cdh4u/draft-sdp-bundle/pull/54 2284 o Pre-RFC5378 disclaimer removed. 2286 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-44 2288 o Minor editorial nits based on pull request by Colin P. 2290 o https://github.com/cdh4u/draft-sdp-bundle/pull/53 2292 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-43 2294 o Changes based on WG chairs review. 2296 o Text added in order to close GitHub issues by Taylor B. 2298 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-42 2300 o Changes based on final WG review. 2302 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-41 2304 o Update to section 6 o RFC 3264: 2306 o https://github.com/cdh4u/draft-sdp-bundle/pull/47 2308 o Editorial clarification on BUNDLE address selection: 2310 o https://github.com/cdh4u/draft-sdp-bundle/pull/46 2312 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40 2314 o Editorial changes and technical restrictions in order to make the 2315 specification more understandable: 2317 o https://github.com/cdh4u/draft-sdp-bundle/pull/45 2319 o - BUNDLE address is only assigned to m- section indicated by 2320 BUNDLE-tag. 2322 o - bundle-only attribute also used in answers and subsequent 2323 offers. 2325 o - Answerer cannot reject, or remove, the bundled m- section that 2326 contains the BUNDLE address. 2328 o - ICE Offer/Answer sections removed, due to duplicated 2329 information. 2331 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39 2333 o Editorial terminology changes. 2335 o RFC 5285 reference replaced by reference to RFC 8285. 2337 o https://github.com/cdh4u/draft-sdp-bundle/pull/44 2339 o - Clarify that an m- section can not be moved between BUNDLE 2340 groups without first moving the m- section out of a BUNDLE group. 2342 o https://github.com/cdh4u/draft-sdp-bundle/pull/41 2344 o - Addition of BUNDLE transport concept. 2346 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38 2348 o Changes to RTP streaming mapping section based on text from Colin 2349 Perkins. 2351 o The following GitHub pull requests were merged: 2353 o https://github.com/cdh4u/draft-sdp-bundle/pull/34 2355 o - Proposed updates to RTP processing 2357 o https://github.com/cdh4u/draft-sdp-bundle/pull/35 2358 o - fixed reference to receiver-id section 2360 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-37 2362 o The following GitHub pull request was merged: 2364 o https://github.com/cdh4u/draft-sdp-bundle/pull/33 2366 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36 2368 o The following GitHub pull requests were merged: 2370 o https://github.com/cdh4u/draft-sdp-bundle/pull/32 2372 o - extmap handling in BUNDLE. 2374 o https://github.com/cdh4u/draft-sdp-bundle/pull/31 2376 o - Additional Acknowledgement text added. 2378 o https://github.com/cdh4u/draft-sdp-bundle/pull/30 2380 o - MID SDES item security procedures updated 2382 o https://github.com/cdh4u/draft-sdp-bundle/pull/29 2384 o - Appendix B of JSEP moved into BUNDLE. 2386 o - Associating RTP/RTCP packets with SDP m- lines. 2388 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35 2390 o Editorial changes on RTP streaming mapping section based on 2391 comments from Colin Perkins. 2393 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34 2395 o RTP streams, instead of RTP packets, are associated with m- lines. 2397 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 2399 o Editorial changes based on comments from Eric Rescorla and Cullen 2400 Jennings: 2402 o - Changes regarding usage of RTP/RTCP multiplexing attributes. 2404 o - Additional text regarding associating RTP/RTCP packets with SDP 2405 m- lines. 2407 o - Reference correction. 2409 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32 2411 o Editorial changes based on comments from Eric Rescorla and Cullen 2412 Jennings: 2414 o - Justification for mechanism added to Introduction. 2416 o - Clarify that the order of m- lines in the group:BUNDLE attribute 2417 does not have to be the same as the order in which the m- lines 2418 are listed in the SDP. 2420 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31 2422 o Editorial changes based on GitHub Pull requests by Martin Thomson: 2424 o - https://github.com/cdh4u/draft-sdp-bundle/pull/2 2426 o - https://github.com/cdh4u/draft-sdp-bundle/pull/1 2428 o Editorial change based on comment from Diederick Huijbers (9th 2429 July 2016). 2431 o Changes based on comments from Flemming Andreasen (21st June 2432 2016): 2434 o - Mux category for SDP bundle-only attribute added. 2436 o - Mux category considerations editorial clarification. 2438 o - Editorial changes. 2440 o RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext. 2442 o Note whether Design Considerations appendix is to be kept removed: 2444 o - Appendix is kept within document. 2446 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30 2448 o Indicating in the Abstract and Introduction that the document 2449 updates RFC 3264. 2451 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29 2453 o Change based on WGLC comment from Colin Perkins. 2455 o - Clarify that SSRC can be reused by another source after a delay 2456 of 5 RTCP reporting intervals. 2458 o Change based on WGLC comment from Alissa Cooper. 2460 o - IANA registry name fix. 2462 o - Additional IANA registration information added. 2464 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28 2466 o - Alignment with exclusive mux procedures. 2468 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 2470 o - Yet another terminology change. 2472 o - Mux category considerations added. 2474 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 2476 o - ICE considerations modified: ICE-related SDP attributes only 2477 added to the bundled m- line representing the selected BUNDLE 2478 address. 2480 o - Reference to draft-ietf-mmusic-ice-sip-sdp added. 2482 o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- 2483 rfc5245bis. 2485 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 2487 o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux 2488 considerations. 2490 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 2492 o - Reference and procedures associated with exclusive RTP/RTCP mux 2493 added 2495 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 2497 o - RTCP-MUX mandatory for bundled RTP m- lines 2499 o - Editorial fixes based on comments from Flemming Andreasen 2501 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 2502 o - Correction of Ari's family name 2504 o - Editorial fixes based on comments from Thomas Stach 2506 o - RTP/RTCP correction based on comment from Magnus Westerlund 2508 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2509 msg14861.html 2511 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 2513 o - Correct based on comment from Paul Kyzivat 2515 o -- 'received packets' replaced with 'received data' 2517 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 2519 o - Clarification based on comment from James Guballa 2521 o - Clarification based on comment from Flemming Andreasen 2523 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 2525 o - DTLS Considerations section added. 2527 o - BUNDLE semantics added to the IANA Considerations 2529 o - Changes based on WGLC comments from Adam Roach 2531 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2532 msg14673.html 2534 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 2536 o - Changes based on agreements at IETF#92 2538 o -- BAS Offer removed, based on agreement at IETF#92. 2540 o -- Procedures regarding usage of SDP "b=" line is replaced with a 2541 reference to to draft-ietf-mmusic-sdp-mux-attributes. 2543 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 2545 o - Editorial changes based on comments from Magnus Westerlund. 2547 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 2548 o - Modification of RTP/RTCP multiplexing section, based on comments 2549 from Magnus Westerlund. 2551 o - Reference updates. 2553 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 2555 o - Editorial fix. 2557 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 2559 o - Editorial changes. 2561 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 2563 o Changes to allow a newly suggested offerer BUNDLE address to be 2564 assigned to each bundled m- line. 2566 o Changes based on WGLC comments from Paul Kyzivat 2568 o - Editorial fixes 2570 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 2572 o Usage of SDP 'extmap' attribute added 2574 o SDP 'bundle-only' attribute scoped with "m=" lines with a zero 2575 port value 2577 o Changes based on WGLC comments from Thomas Stach 2579 o - ICE candidates not assigned to bundle-only m- lines with a zero 2580 port value 2582 o - Editorial changes 2584 o Changes based on WGLC comments from Colin Perkins 2586 o - Editorial changes: 2588 o -- "RTP SDES item" -> "RTCP SDES item" 2590 o -- "RTP MID SDES item" -> "RTCP MID SDES item" 2592 o - Changes in section 10.1.1: 2594 o -- "SHOULD NOT" -> "MUST NOT" 2595 o -- Additional text added to the Note 2597 o - Change to section 13.2: 2599 o -- Clarify that mid value is not zero terminated 2601 o - Change to section 13.3: 2603 o -- Clarify that mid value is not zero terminated 2605 o -- Clarify padding 2607 o Changes based on WGLC comments from Paul Kyzivat 2609 o - Editorial changes: 2611 o Changes based on WGLC comments from Jonathan Lennox 2613 o - Editorial changes: 2615 o - Defintion of SDP bundle-only attribute alligned with structure 2616 in 4566bis draft 2618 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 2620 o Editorial corrections based on comments from Harald Alvestrand. 2622 o Editorial corrections based on comments from Cullen Jennings. 2624 o Reference update (RFC 7160). 2626 o Clarification about RTCP packet sending when RTP/RTCP multiplexing 2627 is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ 2628 msg13765.html). 2630 o Additional text added to the Security Considerations. 2632 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 2634 o SDP bundle-only attribute added to IANA Considerations. 2636 o SDES item and RTP header extension added to Abstract and 2637 Introduction. 2639 o Modification to text updating section 8.2 of RFC 3264. 2641 o Reference corrections. 2643 o Editorial corrections. 2645 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 2647 o Terminology change: "bundle-only attribute assigned to m= line" to 2648 "bundle-only attribute associated with m= line". 2650 o Editorial corrections. 2652 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 2654 o Editorial corrections. 2656 o - "of"->"if" (8.3.2.5). 2658 o - "optional"->"OPTIONAL" (9.1). 2660 o - Syntax/ABNF for 'bundle-only' attribute added. 2662 o - SDP Offer/Answer sections merged. 2664 o - 'Request new offerer BUNDLE address' section added 2666 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 2668 o OPEN ISSUE regarding Receiver-ID closed. 2670 o - RTP MID SDES Item. 2672 o - RTP MID Header Extension. 2674 o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers 2675 closed. 2677 o - Indicating that, when rtcp-mux is used, the answerer MUST NOT 2678 include an 'rtcp' attribute in the answer, based on the procedures 2679 in section 5.1.3 of RFC 5761. 2681 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 2683 o Draft title changed. 2685 o Added "SDP" to section names containing "Offer" or "Answer". 2687 o Editorial fixes based on comments from Paul Kyzivat 2688 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2689 msg13314.html). 2691 o Editorial fixed based on comments from Colin Perkins 2692 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2693 msg13318.html). 2695 o - Removed text about extending BUNDLE to allow multiple RTP 2696 sessions within a BUNDLE group. 2698 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 2700 o Major re-structure of SDP Offer/Answer sections, to align with RFC 2701 3264 structure. 2703 o Additional definitions added. 2705 o - Shared address. 2707 o - Bundled "m=" line. 2709 o - Bundle-only "m=" line. 2711 o - Offerer suggested BUNDLE mid. 2713 o - Answerer selected BUNDLE mid. 2715 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 2716 to multiple "m=" lines until it has received an SDP Answer 2717 indicating support of the BUNDLE extension. 2719 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 2720 Answerer supports the BUNDLE extension, assign a zero port value 2721 to a 'bundle-only' "m=" line. 2723 o SDP 'bundle-only' attribute section added. 2725 o Connection data nettype/addrtype restrictions added. 2727 o RFC 3264 update section added. 2729 o Indicating that a specific payload type value can be used in 2730 multiple "m=" lines, if the value represents the same codec 2731 configuration in each "m=" line. 2733 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 2735 o Updated Offerer procedures (http://www.ietf.org/mail- 2736 archive/web/mmusic/current/msg12293.html). 2738 o Updated Answerer procedures (http://www.ietf.org/mail- 2739 archive/web/mmusic/current/msg12333.html). 2741 o Usage of SDP 'bundle-only' attribute added. 2743 o Reference to Trickle ICE document added. 2745 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 2747 o Mechanism modified, to be based on usage of SDP Offers with both 2748 different and identical port number values, depending on whether 2749 it is known if the remote endpoint supports the extension. 2751 o Cullen Jennings added as co-author. 2753 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 2755 o No changes. New version due to expiration. 2757 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 2759 o No changes. New version due to expiration. 2761 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 2763 o Draft name changed. 2765 o Harald Alvestrand added as co-author. 2767 o "Multiplex" terminology changed to "bundle". 2769 o Added text about single versus multiple RTP Sessions. 2771 o Added reference to RFC 3550. 2773 20. References 2775 20.1. Normative References 2777 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2778 Requirement Levels", BCP 14, RFC 2119, 2779 DOI 10.17487/RFC2119, March 1997, 2780 . 2782 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2783 with Session Description Protocol (SDP)", RFC 3264, 2784 DOI 10.17487/RFC3264, June 2002, 2785 . 2787 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2788 Jacobson, "RTP: A Transport Protocol for Real-Time 2789 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2790 July 2003, . 2792 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2793 in Session Description Protocol (SDP)", RFC 3605, 2794 DOI 10.17487/RFC3605, October 2003, 2795 . 2797 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2798 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2799 2003, . 2801 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2802 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2803 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2804 . 2806 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2807 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2808 July 2006, . 2810 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2811 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2812 . 2814 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2815 Control Packets on a Single Port", RFC 5761, 2816 DOI 10.17487/RFC5761, April 2010, 2817 . 2819 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2820 Security (DTLS) Extension to Establish Keys for the Secure 2821 Real-time Transport Protocol (SRTP)", RFC 5764, 2822 DOI 10.17487/RFC5764, May 2010, 2823 . 2825 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2826 Protocol (SDP) Grouping Framework", RFC 5888, 2827 DOI 10.17487/RFC5888, June 2010, 2828 . 2830 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2831 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2832 January 2012, . 2834 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2835 Header Extension for the RTP Control Protocol (RTCP) 2836 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2837 August 2016, . 2839 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2840 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2841 May 2017, . 2843 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 2844 Mechanism for RTP Header Extensions", RFC 8285, 2845 DOI 10.17487/RFC8285, October 2017, 2846 . 2848 [I-D.ietf-ice-rfc5245bis] 2849 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2850 Connectivity Establishment (ICE): A Protocol for Network 2851 Address Translator (NAT) Traversal", draft-ietf-ice- 2852 rfc5245bis-20 (work in progress), March 2018. 2854 [I-D.ietf-mmusic-sdp-mux-attributes] 2855 Nandakumar, S., "A Framework for SDP Attributes when 2856 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 2857 (work in progress), December 2016. 2859 [I-D.ietf-mmusic-mux-exclusive] 2860 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 2861 Multiplexing using SDP", draft-ietf-mmusic-mux- 2862 exclusive-12 (work in progress), May 2017. 2864 [I-D.ietf-mmusic-ice-sip-sdp] 2865 Petit-Huguenin, M., Nandakumar, S., and A. Keranen, 2866 "Session Description Protocol (SDP) Offer/Answer 2867 procedures for Interactive Connectivity Establishment 2868 (ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in 2869 progress), April 2018. 2871 [I-D.ietf-mmusic-trickle-ice-sip] 2872 Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 2873 Session Initiation Protocol (SIP) Usage for Trickle ICE", 2874 draft-ietf-mmusic-trickle-ice-sip-14 (work in progress), 2875 February 2018. 2877 20.2. Informative References 2879 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2880 A., Peterson, J., Sparks, R., Handley, M., and E. 2881 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2882 DOI 10.17487/RFC3261, June 2002, 2883 . 2885 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2886 "RTP Control Protocol Extended Reports (RTCP XR)", 2887 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2888 . 2890 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2891 "Codec Control Messages in the RTP Audio-Visual Profile 2892 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 2893 February 2008, . 2895 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2896 "Extended RTP Profile for Real-time Transport Control 2897 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2898 DOI 10.17487/RFC4585, July 2006, 2899 . 2901 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2902 Media Attributes in the Session Description Protocol 2903 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2904 . 2906 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2907 Clock Rates in an RTP Session", RFC 7160, 2908 DOI 10.17487/RFC7160, April 2014, 2909 . 2911 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2912 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2913 . 2915 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2916 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2917 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2918 DOI 10.17487/RFC7656, November 2015, 2919 . 2921 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 2922 (Diffserv) and Real-Time Communication", RFC 7657, 2923 DOI 10.17487/RFC7657, November 2015, 2924 . 2926 [I-D.ietf-ice-trickle] 2927 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 2928 "Trickle ICE: Incremental Provisioning of Candidates for 2929 the Interactive Connectivity Establishment (ICE) 2930 Protocol", draft-ietf-ice-trickle-21 (work in progress), 2931 April 2018. 2933 [I-D.ietf-avtext-lrr] 2934 Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 2935 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 2936 Message", draft-ietf-avtext-lrr-07 (work in progress), 2937 July 2017. 2939 Appendix A. Design Considerations 2941 One of the main issues regarding the BUNDLE grouping extensions has 2942 been whether, in SDP Offers and SDP Answers, the same port value can 2943 be inserted in "m=" lines associated with a BUNDLE group, as the 2944 purpose of the extension is to negotiate the usage of a single 2945 transport for media specified by the "m=" sections. Issues with both 2946 approaches, discussed in the Appendix have been raised. The outcome 2947 was to specify a mechanism which uses SDP Offers with both different 2948 and identical port values. 2950 Below are the primary issues that have been considered when defining 2951 the "BUNDLE" grouping extension: 2953 o 1) Interoperability with existing UAs. 2955 o 2) Interoperability with intermediary Back to Back User Agent 2956 (B2BUA) and proxy entities. 2958 o 3) Time to gather, and the number of, ICE candidates. 2960 o 4) Different error scenarios, and when they occur. 2962 o 5) SDP Offer/Answer impacts, including usage of port number value 2963 zero. 2965 A.1. UA Interoperability 2967 Consider the following SDP Offer/Answer exchange, where Alice sends 2968 an SDP Offer to Bob: 2970 SDP Offer 2972 v=0 2973 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2974 s= 2975 c=IN IP4 atlanta.example.com 2976 t=0 0 2978 m=audio 10000 RTP/AVP 97 2979 a=rtpmap:97 iLBC/8000 2980 m=video 10002 RTP/AVP 97 2981 a=rtpmap:97 H261/90000 2983 SDP Answer 2985 v=0 2986 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2987 s= 2988 c=IN IP4 biloxi.example.com 2989 t=0 0 2991 m=audio 20000 RTP/AVP 97 2992 a=rtpmap:97 iLBC/8000 2993 m=video 20002 RTP/AVP 97 2994 a=rtpmap:97 H261/90000 2996 RFC 4961 specifies a way of doing symmetric RTP but that is a later 2997 extension to RTP and Bob can not assume that Alice supports RFC 4961. 2998 This means that Alice may be sending RTP from a different port than 2999 10000 or 10002 - some implementations simply send the RTP from an 3000 ephemeral port. When Bob's endpoint receives an RTP packet, the only 3001 way that Bob knows if the packet is to be passed to the video or 3002 audio codec is by looking at the port it was received on. This led 3003 some SDP implementations to use the fact that each "m=" section had a 3004 different port number to use that port number as an index to find the 3005 correct m line in the SDP. As a result, some implementations that do 3006 support symmetric RTP and ICE still use an SDP data structure where 3007 SDP with "m=" sections with the same port such as: 3009 SDP Offer 3011 v=0 3012 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 3013 s= 3014 c=IN IP4 atlanta.example.com 3015 t=0 0 3017 m=audio 10000 RTP/AVP 97 3018 a=rtpmap:97 iLBC/8000 3019 m=video 10000 RTP/AVP 98 3020 a=rtpmap:98 H261/90000 3022 will result in the second "m=" section being considered an SDP error 3023 because it has the same port as the first line. 3025 A.2. Usage of Port Number Value Zero 3027 In an SDP Offer or SDP Answer, the media specified by an "m=" section 3028 can be disabled/rejected by setting the port number value to zero. 3029 This is different from e.g., using the SDP direction attributes, 3030 where RTCP traffic will continue even if the SDP "inactive" attribute 3031 is indicated for the associated "m=" section. 3033 If each "m=" section associated with a BUNDLE group would contain 3034 different port values, and one of those port values would be used for 3035 a BUNDLE address:port associated with the BUNDLE group, problems 3036 would occur if an endpoint wants to disable/reject the "m=" section 3037 associated with that port, by setting the port value to zero. After 3038 that, no "m=" section would contain the port value which is used for 3039 the BUNDLE address:port. In addition, it is unclear what would 3040 happen to the ICE candidates associated with the "m=" section, as 3041 they are also used for the BUNDLE address:port. 3043 A.3. B2BUA And Proxy Interoperability 3045 Some back to back user agents may be configured in a mode where if 3046 the incoming call leg contains an SDP attribute the B2BUA does not 3047 understand, the B2BUA still generates that SDP attribute in the Offer 3048 for the outgoing call leg. Consider a B2BUA that did not understand 3049 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 3050 Further assume that the B2BUA was configured to tear down any call 3051 where it did not see any RTCP for 5 minutes. In this case, if the 3052 B2BUA received an Offer like: 3054 SDP Offer 3056 v=0 3057 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 3058 s= 3059 c=IN IP4 atlanta.example.com 3060 t=0 0 3062 m=audio 49170 RTP/AVP 0 3063 a=rtcp:53020 3065 It would be looking for RTCP on port 49171 but would not see any 3066 because the RTCP would be on port 53020 and after five minutes, it 3067 would tear down the call. Similarly, a B2BUA that did not understand 3068 BUNDLE yet put BUNDLE in its offer may be looking for media on the 3069 wrong port and tear down the call. It is worth noting that a B2BUA 3070 that generated an Offer with capabilities it does not understand is 3071 not compliant with the specifications. 3073 A.3.1. Traffic Policing 3075 Sometimes intermediaries do not act as B2BUAs, in the sense that they 3076 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 3077 however, they may use SDP information (e.g., IP address and port) in 3078 order to control traffic gating functions, and to set traffic 3079 policing rules. There might be rules which will trigger a session to 3080 be terminated in case media is not sent or received on the ports 3081 retrieved from the SDP. This typically occurs once the session is 3082 already established and ongoing. 3084 A.3.2. Bandwidth Allocation 3086 Sometimes intermediaries do not act as B2BUAs, in the sense that they 3087 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 3088 however, they may use SDP information (e.g., codecs and media types) 3089 in order to control bandwidth allocation functions. The bandwidth 3090 allocation is done per "m=" section, which means that it might not be 3091 enough if media specified by all "m=" sections try to use that 3092 bandwidth. That may either simply lead to bad user experience, or to 3093 termination of the call. 3095 A.4. Candidate Gathering 3097 When using ICE, a candidate needs to be gathered for each port. This 3098 takes approximately 20 ms extra for each extra "m=" section due to 3099 the NAT pacing requirements. All of this gathering can be overlapped 3100 with other things while e.g., a web-page is loading to minimize the 3101 impact. If the client only wants to generate TURN or STUN ICE 3102 candidates for one of the "m=" lines and then use trickle ICE 3103 [I-D.ietf-ice-trickle] to get the non host ICE candidates for the 3104 rest of the "m=" sections, it MAY do that and will not need any 3105 additional gathering time. 3107 Some people have suggested a TURN extension to get a bunch of TURN 3108 allocations at once. This would only provide a single STUN result so 3109 in cases where the other end did not support BUNDLE, it may cause 3110 more use of the TURN server but would be quick in the cases where 3111 both sides supported BUNDLE and would fall back to a successful call 3112 in the other cases. 3114 Authors' Addresses 3116 Christer Holmberg 3117 Ericsson 3118 Hirsalantie 11 3119 Jorvas 02420 3120 Finland 3122 Email: christer.holmberg@ericsson.com 3124 Harald Tveit Alvestrand 3125 Google 3126 Kungsbron 2 3127 Stockholm 11122 3128 Sweden 3130 Email: harald@alvestrand.no 3132 Cullen Jennings 3133 Cisco 3134 400 3rd Avenue SW, Suite 350 3135 Calgary, AB T2P 4H2 3136 Canada 3138 Email: fluffy@iii.ca