idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-50.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 (April 24, 2018) is 2187 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 1586 == Missing Reference: 'RFCXXXX' is mentioned on line 1770, 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: October 26, 2018 C. Jennings 7 Cisco 8 April 24, 2018 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-50.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 allow assigning a zero port 26 value to a "m=" section also 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 http://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 October 26, 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 (http://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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 87 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 88 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 89 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7 90 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 8 91 7. SDP Information Considerations . . . . . . . . . . . . . . . 9 92 7.1. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9 93 7.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9 94 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9 95 8.1. Multiplexing Category Considerations . . . . . . . . . . 10 96 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 11 97 8.2.1. Suggesting the Offerer BUNDLE Address:Port . . . . . 11 98 8.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 12 99 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 13 100 8.3.1. Answerer Selection of Offerer BUNDLE Address:Port . . 14 101 8.3.2. Answerer Selection of Answerer BUNDLE Address:Port . 14 102 8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 15 103 8.3.4. Rejecting a Media Description in a BUNDLE Group . . . 15 104 8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 16 105 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 17 106 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 17 107 8.5.1. Suggesting a New Offerer BUNDLE Address:Port . . . . 18 108 8.5.2. Adding a Media Description to a BUNDLE group . . . . 18 109 8.5.3. Moving a Media Description Out of a BUNDLE Group . . 19 110 8.5.4. Disabling a Media Description in a BUNDLE Group . . . 19 111 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 20 112 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 20 113 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 21 114 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 21 115 10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 22 116 10.2. Associating RTP/RTCP Streams with the Correct SDP Media 117 Description . . . . . . . . . . . . . . . . . . . . . . 22 118 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 28 119 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 28 120 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 30 121 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 31 122 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 32 123 13. RTP Header Extensions Consideration . . . . . . . . . . . . . 33 124 14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 33 125 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 33 126 14.2. New text replacing section 5.1 (2nd paragraph) of RFC 127 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 128 14.3. Original text of section 8.4 (6th paragraph) of RFC 3264 34 129 14.4. New text replacing section 8.4 (6th paragraph) of RFC 130 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 131 15. RTP/RTCP extensions for identification-tag transport . . . . 35 132 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 36 133 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 36 134 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 135 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 37 136 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 37 137 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 38 138 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 38 139 17. Security Considerations . . . . . . . . . . . . . . . . . . . 39 140 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40 141 18.1. Example: BUNDLE Address:Port Selection . . . . . . . . . 40 142 18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 41 143 18.3. Example: Offerer Adds a Media Description to a BUNDLE 144 Group . . . . . . . . . . . . . . . . . . . . . . . . . 44 146 18.4. Example: Offerer Moves a Media Description Out of a 147 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 45 148 18.5. Example: Offerer Disables a Media Description Within a 149 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 47 150 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 151 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 50 152 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 153 21.1. Normative References . . . . . . . . . . . . . . . . . . 60 154 21.2. Informative References . . . . . . . . . . . . . . . . . 63 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 When the SDP offer/answer mechanism [RFC3264] is used to negotiate 167 the establishment of multimedia communication sessions, if separate 168 transports (5-tuples) are negotiated for each individual media 169 stream, each transport consumes additional resources (especially when 170 Interactive Connectivity Establishment (ICE) 171 [I-D.ietf-ice-rfc5245bis] is used). For this reason, it is 172 attractive to use a single transport for multiple media streams. 174 This specification defines a way to use a single transport (BUNDLE 175 transport) for sending and receiving media (bundled media) described 176 by multiple SDP media descriptions ("m=" sections). The same BUNDLE 177 transport is used for sending and receiving bundled media, which 178 means that the symmetric Real-time Transport Protocol (RTP) mechanism 179 [RFC4961] is always used for RTP-based bundled media. 181 This specification defines a new SDP Grouping Framework [RFC5888] 182 extension called 'BUNDLE'. The extension can be used with the 183 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 184 to negotiate which "m=" sections will become part of a BUNDLE group. 185 Within a BUNDLE group, each "m=" section will use a BUNDLE transport 186 for sending and receiving bundled media. 188 Within a BUNDLE group, each endpoint uses a single address:port 189 combination for sending and receiving bundled media. The 190 address:port combination is referred to as the BUNDLE address:port. 191 In addition to negotiating the BUNDLE group, the offerer and answerer 192 [RFC3264] use the BUNDLE extension to negotiate the BUNDLE 193 addresses:ports, one for the offerer (offerer BUNDLE address:port) 194 and one for the answerer (answerer BUNDLE address:port). Once the 195 offerer and the answerer have negotiated the BUNDLE addresses:ports, 196 and a BUNDLE group has been formed, they assign their respective 197 BUNDLE address:port to each "m=" section within the BUNDLE group. 198 The endpoints then use the BUNDLE addresses:ports for sending and 199 receiving the bundled media associated with the BUNDLE group. 201 The use of a BUNDLE transport allows the usage of a single set of 202 Interactive Connectivity Establishment (ICE) 203 [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group. 205 This specification defines a new SDP attribute, 'bundle-only', which 206 can be used to request that specific media is only used if the "m=" 207 section describing the media is kept within a BUNDLE group. 209 This specification updates RFC 3264 [RFC3264], to allow assigning a 210 zero port value to a "m=" section also in cases where the media 211 described by the "m=" section is not disabled or rejected. 213 This specification defines a new RTP Control Protocol (RTCP) 214 [RFC3550] source description (SDES) item, 'MID', and a new RTP SDES 215 header extension that can be used to associate RTP streams with "m=" 216 sections. 218 This specification updates [RFC7941], by adding an exception, for the 219 MID RTP header extension, to the requirement regarding protection of 220 an SDES RTP header extension carrying an SDES item for the MID RTP 221 header extension. 223 A given BUNDLE address:port MUST only be associated with a single 224 BUNDLE group. If an SDP offer or answer contains multiple BUNDLE 225 groups, the procedures in this specification apply to each group 226 independently. All RTP based media flows described by a single 227 BUNDLE group belong to a single RTP session [RFC3550]. 229 The BUNDLE extension is backward compatible. Endpoints that do not 230 support the extension are expected to generate offers and answers 231 without an SDP 'group:BUNDLE' attribute, and are expected to assign a 232 unique address:port to each "m=" section within an offer and answer, 233 according to the procedures in [RFC4566] and [RFC3264]. 235 2. Terminology 237 o "m=" section: SDP bodies contain one or more media descriptions, 238 referred to as "m=" sections. Each "m=" section is represented by 239 an SDP "m=" line, and zero or more SDP attributes associated with 240 the "m=" line. A local address:port combination is assigned to 241 each "m=" section. 243 o 5-tuple: A collection of the following values: source address, 244 source port, destination address, destination port, and transport- 245 layer protocol. 247 o Unique address:port: An address:port combination that is assigned 248 to only one "m=" section in an offer or answer. 250 o Offerer BUNDLE-tag: The first identification-tag in a given SDP 251 'group:BUNDLE' attribute identification-tag list in an offer. 253 o Answerer BUNDLE-tag: The first identification-tag in a given SDP 254 'group:BUNDLE' attribute identification-tag list in an answer. 256 o BUNDLE address:port: An address:port combination that an endpoint 257 uses for sending and receiving bundled media. 259 o Offerer BUNDLE address:port: the address:port combination used by 260 the offerer for sending and receiving media. 262 o Suggested Offerer BUNDLE address:port: before an offerer BUNDLE 263 address:port has been selected by the answerer, or when the 264 offerer wants to change a previously selected offerer BUNDLE 265 address:port, the address:port combination that the offerer wants 266 to use for sending and receiving media. While suggested by the 267 offerer, the selection of the offerer BUNDLE address:port is done 268 by the answerer. 270 o Answerer BUNDLE address:port: the address:port combination used by 271 the answerer for sending and receiving media. 273 o BUNDLE transport: The transport (5-tuple) used by all media 274 described by the "m=" sections within a BUNDLE group. 276 o BUNDLE group: A set of "m=" sections, created using an SDP Offer/ 277 Answer exchange, which uses a single BUNDLE transport for sending 278 and receiving all media (bundled media) described by the set of 279 "m=" sections. The same BUNDLE transport is used for sending and 280 receiving bundled media. 282 o Bundled "m=" section: An "m=" section, whose identification-tag is 283 placed in an SDP 'group:BUNDLE' attribute identification-tag list 284 in an offer or answer. 286 o Bundle-only "m=" section: A bundled "m=" section that contains an 287 SDP 'bundle-only' attribute. 289 o Bundled media: All media associated with a given BUNDLE group. 291 o Initial offer: The first offer, within an SDP session (e.g. a SIP 292 dialog when the Session Initiation Protocol (SIP) [RFC3261] is 293 used to carry SDP), in which the offerer indicates that it wants 294 to create a given BUNDLE group. 296 o Subsequent offer: An offer which contains a BUNDLE group that has 297 been created as part of a previous offer/answer exchange. 299 o Identification-tag: A unique token value that is used to identify 300 an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" 301 section carries the unique identification-tag assigned to that 302 "m=" section. The session-level SDP 'group' attribute [RFC5888] 303 carries a list of identification-tags, identifying the "m=" 304 sections associated with that particular 'group' attribute. 306 3. Conventions 308 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 309 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 310 "OPTIONAL" in this document are to be interpreted as described in BCP 311 14 [RFC2119] [RFC8174] when, and only when, they appear in all 312 capitals, as shown here. 314 4. Applicability Statement 316 The mechanism in this specification only applies to the Session 317 Description Protocol (SDP) [RFC4566], when used together with the SDP 318 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 319 scope of this document, and is thus undefined. 321 5. SDP Grouping Framework BUNDLE Extension 323 This section defines a new SDP Grouping Framework [RFC5888] 324 extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP 325 Offer/Answer mechanism to negotiate a set of "m=" sections that will 326 become part of a BUNDLE group. Within a BUNDLE group, each "m=" 327 section uses a BUNDLE transport for sending and receiving bundled 328 media. Each endpoint uses a single address:port combination for 329 sending and receiving the bundled media. 331 The BUNDLE extension is indicated using an SDP 'group' attribute with 332 a semantics value [RFC5888] of "BUNDLE". An identification-tag is 333 assigned to each bundled "m=" section, and each identification-tag is 334 listed in the SDP 'group:BUNDLE' attribute identification-tag list. 335 Each "m=" section whose identification-tag is listed in the 336 identification-tag list is associated with a given BUNDLE group. 338 SDP bodies can contain multiple BUNDLE groups. Any given bundled 339 "m=" section MUST NOT be associated with more than one BUNDLE group 340 at any given time. 342 NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' 343 attribute identification-tag list does not have to be the same as the 344 order in which the "m=" sections occur in the SDP. 346 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 347 'group:BUNDLE' attribute is 'NORMAL'. 349 Section 8 defines the detailed SDP Offer/Answer procedures for the 350 BUNDLE extension. 352 6. SDP 'bundle-only' Attribute 354 This section defines a new SDP media-level attribute [RFC4566], 355 'bundle-only'. 'bundle-only' is a property attribute [RFC4566], and 356 hence has no value. 358 In order to ensure that an answerer that does not support the BUNDLE 359 extension always rejects a bundled "m=" section, the offerer can 360 assign a zero port value to the "m=" section. According to [RFC3264] 361 an answerer will reject such an "m=" section. By including an SDP 362 'bundle-only' attribute in such an "m=" section, the offerer can 363 request that the answerer accepts the "m=" section if the answerer 364 supports the BUNDLE extension, and if the answerer keeps the "m=" 365 section within the associated BUNDLE group. 367 Name: bundle-only 369 Value: N/A 371 Usage Level: media 373 Charset Dependent: no 375 Example: 377 a=bundle-only 379 Once the offerer and answerer BUNDLE addresses:ports have been 380 selected, an offerer and answerer only assign the BUNDLE address:port 381 to one bundled "m=" section. The offerer and answerer assign a zero 382 port value and include an SDP 'bundle-only' attribute to every other 383 bundled "m=" section. 385 The usage of the 'bundle-only' attribute is only defined for a 386 bundled "m=" section with a zero port value. Other usage is 387 unspecified. 389 Section 8 defines the detailed SDP Offer/Answer procedures for the 390 'bundle-only' attribute. 392 7. SDP Information Considerations 394 This section describes restrictions associated with the usage of SDP 395 parameters within a BUNDLE group. It also describes how to calculate 396 a value for the whole BUNDLE group, when parameter and attribute 397 values have been assigned to each bundled "m=" section. 399 7.1. Connection Data (c=) 401 The "c=" line nettype value [RFC4566] associated with a bundled "m=" 402 section MUST be 'IN'. 404 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" 405 section MUST be 'IP4' or 'IP6'. The same value MUST be associated 406 with each "m=" section. 408 NOTE: Extensions to this specification can specify usage of the 409 BUNDLE mechanism for other nettype and addrtype values than the ones 410 listed above. 412 7.2. Bandwidth (b=) 414 An offerer and answerer MUST use the rules and restrictions defined 415 in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP 416 bandwidth (b=) line with bundled "m=" sections. 418 8. SDP Offer/Answer Procedures 420 This section describes the SDP Offer/Answer [RFC3264] procedures for: 422 o Negotiating a BUNDLE group; and 424 o Selecting the BUNDLE addresses:ports (offerer BUNDLE address:port 425 and answerer BUNDLE address:port); and 427 o Adding an "m=" section to a BUNDLE group; and 429 o Moving an "m=" section out of a BUNDLE group; and 431 o Disabling an "m=" section within a BUNDLE group. 433 The generic rules and procedures defined in [RFC3264] and [RFC5888] 434 also apply to the BUNDLE extension. For example, if an offer is 435 rejected by the answerer, the previously negotiated SDP parameters 436 and characteristics (including those associated with a BUNDLE group) 437 apply. Hence, if an offerer generates an offer in which the offerer 438 wants to create a BUNDLE group, and the answerer rejects the offer, 439 the BUNDLE group is not created. 441 The procedures in this section are independent of the media type or 442 "m=" line proto value assigned to a bundled "m=" section. Section 10 443 defines additional considerations for RTP based media. Section 6 444 defines additional considerations for the usage of the SDP 'bundle- 445 only' attribute. Section 11 defines additional considerations for 446 the usage of Interactive Connectivity Establishment (ICE) 447 [I-D.ietf-ice-rfc5245bis] mechanism. 449 SDP offers and answers can contain multiple BUNDLE groups. The 450 procedures in this section apply independently to a given BUNDLE 451 group. 453 8.1. Multiplexing Category Considerations 455 When a BUNDLE group is initially negotiated, and a unique 456 address:port is assigned to each bundled "m=" section (excluding any 457 bundle-only "m=" section) in the initial offer [Section 8.2], any 458 IDENTICAL and TRANSPORT multiplexing category SDP attributes included 459 in the BUNDLE group MUST explicitly be included in each bundled "m=" 460 section (excluding any bundle-only "m=" sections). 462 When an offerer or answerer includes SDP attributes in bundled "m=" 463 sections within a BUNDLE group, IDENTICAL and TRANSPORT multiplexing 464 category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are only 465 included in the "m=" section indicated by the BUNDLE-tag in the offer 466 or answer. The SDP attribute values are implicitly applied to each 467 bundled "m=" section (including any bundle-only "m=" section). The 468 offerer and answerer MUST NOT include such SDP attributes in any 469 other bundled "m=" section. 471 One consequence of these rules is that media-specific IDENTICAL and 472 TRANSPORT multiplexing category SDP attributes which are appropriate 473 only to some other bundled "m=" sections within the BUNDLE group 474 might appear in the "m=" section indicated by the BUNDLE-tag. For 475 instance, the "m=" section indicated by the BUNDLE-tag might contain 476 an SDP 'rtcp-mux' attribute even if the "m=" section does not 477 describe RTP-based media, but another "m=" section within the BUNDLE 478 group does describe RTP-based media. 480 8.2. Generating the Initial SDP Offer 482 When an offerer generates an initial offer, in order to negotiate a 483 BUNDLE group, it MUST: 485 o Assign a unique address:port to each "m=" section within the 486 offer, following the procedures in [RFC3264], excluding any 487 bundle-only "m=" sections (see below); and 489 o Include an SDP 'group:BUNDLE' attribute in the offer; and 491 o Place the identification-tag of each bundled "m=" section in the 492 SDP 'group:BUNDLE' attribute identification-tag list; and 494 o Indicate which unique address:port the offerer suggests as the 495 offerer BUNDLE address:port [Section 8.2.1]. 497 NOTE: When the offerer assigns unique addresses:ports to multiple 498 bundled "m=" sections, the offerer needs to be prepared to receive 499 bundled media on each unique address:port, until it receives the 500 associated answer and finds out which address:port combination has 501 been selected as the offerer BUNDLE-address. 503 If the offerer wants to request that the answerer accepts a given 504 bundled "m=" section only if the answerer keeps the "m=" section 505 within the BUNDLE group, the offerer MUST: 507 o Assign a zero port value to the "m=" section; and 509 o Include an SDP 'bundle-only' attribute [Section 8.2.1] in the "m=" 510 section. 512 NOTE: If the offerer assigns a zero port value to an "m=" section, 513 but does not include an SDP 'bundle-only' attribute in the "m=" 514 section, it is an indication that the offerer wants to disable the 515 "m=" section [Section 8.5.4]. 517 [Section 8.2.2] and [Section 18.1] show an example of an initial 518 offer. 520 8.2.1. Suggesting the Offerer BUNDLE Address:Port 522 In the offer, the address:port combination assigned to the "m=" 523 section indicated by the offerer BUNDLE-tag indicates the offerer 524 BUNDLE address:port, i.e., the address:port combination that the 525 offerer suggests for sending and receiving bundled media. 527 The offerer BUNDLE-tag MUST NOT represent a bundle-only "m=" section. 528 Hence, the offer MUST contain at least one bundled "m=" section with 529 a unique address:port (and a non-zero port value). 531 It is RECOMMENDED that the offerer assigns the suggested offerer 532 BUNDLE address:port to a bundled "m=" section that the offerer 533 believes it is unlikely that the answerer will reject, or move out of 534 the BUNDLE group. How such assumption is made is outside the scope 535 of this document. 537 8.2.2. Example: Initial SDP Offer 539 The example shows an initial SDP offer. The offer includes two "m=" 540 sections in the SDP, and suggests that both are included in a BUNDLE 541 group. The audio "m=" section is indicated by the offerer BUNDLE-tag 542 (placed first in the SDP group:BUNDLE attribute identification-id 543 list). 545 SDP Offer 547 v=0 548 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 549 s= 550 c=IN IP6 2001:db8::3 551 t=0 0 552 a=group:BUNDLE foo bar 554 m=audio 10000 RTP/AVP 0 8 97 555 b=AS:200 556 a=mid:foo 557 a=rtcp-mux 558 a=rtpmap:0 PCMU/8000 559 a=rtpmap:8 PCMA/8000 560 a=rtpmap:97 iLBC/8000 561 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 563 m=video 10002 RTP/AVP 31 32 564 b=AS:1000 565 a=mid:bar 566 a=rtcp-mux 567 a=rtpmap:31 H261/90000 568 a=rtpmap:32 MPV/90000 569 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 571 8.3. Generating the SDP Answer 573 When an answerer generates an answer that contains a BUNDLE group the 574 following general SDP grouping framework restrictions, defined in 575 [RFC5888], also apply to the BUNDLE group: 577 o The answerer is only allowed to include a BUNDLE group in the 578 answer if the offerer requested the BUNDLE group to be negotiated 579 in the corresponding offer; and 581 o The answerer is only allowed to include an "m=" section within a 582 BUNDLE group if the offerer requested the "m=" section to be 583 within that same BUNDLE group in the corresponding offer. 585 If the answer contains a BUNDLE group, the answerer MUST: 587 o Select an offerer BUNDLE address:port [Section 8.3.1]; and 589 o Select an answerer BUNDLE address:port [Section 8.3.2]. 591 The answerer is allowed to select a new answerer BUNDLE address:port 592 each time it generates an answer to an offer. 594 If the answerer does not want to keep an "m=" section within a BUNDLE 595 group, it MUST: 597 o Move the "m=" section out of the BUNDLE group [Section 8.3.3]; or 599 o Reject the "m=" section [Section 8.3.4]. 601 When the answerer creates the answer, it selects the offerer BUNDLE 602 address:port [Section 8.3.1] and the answerer BUNDLE address:port 603 [Section 8.3.2]. The answerer then assigns the answerer BUNDLE 604 address:port to the bundled "m=" section indicated by the answerer 605 BUNDLE-tag. In every other bundled "m=" section the answerer 606 includes an SDP 'bundle-only' attribute and assigns a zero port value 607 to the "m=" section. 609 If the answerer does not want to keep a bundle-only "m=" section 610 within the BUNDLE group, it MUST reject the "m=" section 611 [Section 8.3.4]. 613 NOTE: If a bundled "m=" section in an offer contains a zero port 614 value, but the "m=" section does not contain an SDP 'bundle-only' 615 attribute, it is an indication that the offerer wants to disable the 616 "m=" section [Section 8.5.4]. 618 8.3.1. Answerer Selection of Offerer BUNDLE Address:Port 620 In an offer, the bundled "m=" section indicated by the offerer 621 BUNDLE-tag contains the suggested offerer BUNDLE address:port, i.e, 622 the address:port combination that the offerer wants to use for 623 sending and receiving bundled media [Section 8.2.1]. The answerer 624 MUST check whether that "m=" section fulfils the following criteria: 626 o The answerer will not move the "m=" section out of the BUNDLE 627 group [Section 8.3.3]; and 629 o The answerer will not reject the "m=" section [Section 8.3.4]; and 631 o The "m=" section does not contain a zero port value. 633 If all of the criteria above are fulfilled, the answerer MUST select 634 the suggested offerer BUNDLE address:port. 636 If one or more of the criteria are not fulfilled, the answerer MUST 637 pick the next identification-tag in the identification-tag list in 638 the offer, and perform the same criteria check for the "m=" section 639 indicated by that identification-tag. If there are no more 640 identification-tags in the identification-tag list, the answerer MUST 641 NOT create the BUNDLE group. Unless the answerer rejects the whole 642 offer, the answerer MUST apply the answerer procedures for moving an 643 "m=" section out of a BUNDLE group [Section 8.3.3] or rejecting an 644 "m=" section within a BUNDLE group [Section 8.3.4] to every bundled 645 "m=" section in the offer when creating the answer. 647 [Section 18.1] shows an example of an offerer BUNDLE address:port 648 selection. 650 8.3.2. Answerer Selection of Answerer BUNDLE Address:Port 652 When the answerer selects a BUNDLE address:port for itself (answerer 653 BUNDLE address:port), the answerer MUST assign the answerer BUNDLE 654 address:port to the "m=" section that contains the selected offerer 655 BUNDLE address:port in the corresponding offer. The answerer BUNDLE- 656 tag represents that "m=" section in the answer. To every other 657 bundled "m=" section the answerer MUST assign a zero port value and 658 include an SDP 'bundle-only' attribute. 660 The answerer MUST NOT assign an answerer BUNDLE address:port to an 661 "m=" section that is not within the BUNDLE group, or to an "m=" 662 section that is within another BUNDLE group. 664 [Section 8.3.5] and [Section 18.1] show an example of an answerer 665 BUNDLE address:port selection. 667 8.3.3. Moving A Media Description Out Of A BUNDLE Group 669 When an answerer wants to move a bundled "m=" section out of a BUNDLE 670 group in an answer, it MUST first check the following criteria: 672 o In the corresponding offer, an offerer BUNDLE address:port 673 (previously selected [Section 8.3.1] or newly suggested 674 [Section 8.5.1]) has been assigned to the "m=" section by the 675 offerer; or 677 o In the corresponding offer, the "m=" section contains an SDP 678 'bundle-only' attribute and a zero port value. 680 If either criterium above is fulfilled the answerer can not move the 681 "m=" section out of the BUNDLE group in the answer. The answerer can 682 either reject the whole offer, reject each bundled "m=" section 683 within the BUNDLE group [Section 8.3.4], or keep the "m=" section 684 within the BUNDLE group in the answer and later create an offer where 685 the "m=" section is moved out of the BUNDLE group [Section 8.5.3]. 687 When the answerer generates an answer, in which it moves a bundled 688 "m=" section out of a BUNDLE group, the answerer: 690 o MUST assign a unique address:port to the "m=" section; and 692 o MUST NOT place the identification-tag associated with the "m=" 693 section in the SDP 'group:BUNDLE' attribute identification-tag 694 list associated with the BUNDLE group; and 696 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 697 section. 699 Because an answerer is not allowed to move an "m=" section from one 700 BUNDLE group to another within an answer [Section 8.3], if the 701 answerer wants to move an "m=" section from one BUNDLE group to 702 another it MUST first move the "m=" section out of the current BUNDLE 703 group, and then generate an offer where the "m=" section is added to 704 another BUNDLE group [Section 8.5.2]. 706 8.3.4. Rejecting a Media Description in a BUNDLE Group 708 When an answerer wants to reject a bundled "m=" section in an answer, 709 it MUST first check the following criterium: 711 o In the corresponding offer, an offerer BUNDLE address:port 712 (previously selected [Section 8.3.1] or newly suggested 713 [Section 8.5.1]) has been assigned to the "m=" section by the 714 offerer. 716 If the criterium above is fulfilled the answerer can not reject the 717 "m=" section in the answer (unless the answerer rejects each bundled 718 "m=" section within the BUNDLE group). The answerer can either 719 reject the whole offer, reject each bundled "m=" section within the 720 BUNDLE group, or keep the "m=" section within the BUNDLE group in the 721 answer and later create an offer where the "m=" section is disabled 722 within the BUNDLE group [Section 8.5.4]. 724 When an answerer generates an answer, in which it rejects a bundled 725 "m=" section, the answerer: 727 o MUST assign a zero port value to the "m=" section, according to 728 the procedures in [RFC3264]; and 730 o MUST NOT place the identification-tag associated with the "m=" 731 section in the SDP 'group:BUNDLE' attribute identification-tag 732 list associated with the BUNDLE group; and 734 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 735 section. 737 8.3.5. Example: SDP Answer 739 The example below shows an SDP answer, based on the SDP offer in 740 [Section 8.2.2]. The answerer accepts both "m=" sections within the 741 BUNDLE group. The answerer assigns the answerer BUNDLE address:port 742 to the "m=" section indicated by the answerer BUNDLE-tag. The 743 answerer assigns a zero port value and an SDP 'bundle-only' attribute 744 to the other bundled "m=" section. 746 SDP Answer 748 v=0 749 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 750 s= 751 c=IN IP6 2001:db8::1 752 t=0 0 753 a=group:BUNDLE foo bar 755 m=audio 20000 RTP/AVP 0 756 b=AS:200 757 a=mid:foo 758 a=rtcp-mux 759 a=rtpmap:0 PCMU/8000 760 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 762 m=video 0 RTP/AVP 32 763 b=AS:1000 764 a=mid:bar 765 a=bundle-only 766 a=rtpmap:32 MPV/90000 767 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 769 8.4. Offerer Processing of the SDP Answer 771 When an offerer receives an answer, if the answer contains a BUNDLE 772 group, the offerer MUST check that any bundled "m=" section in the 773 answer was indicated as bundled in the corresponding offer. If there 774 is no mismatch, the offerer MUST use the offerer BUNDLE address:port, 775 selected by the answerer [Section 8.3.1], as the address for each 776 bundled "m=" section. 778 NOTE: As the answerer might reject one or more bundled "m=" sections, 779 or move a bundled "m=" section out of a BUNDLE group, a given bundled 780 "m=" section in the offer might not be indicated as bundled in the 781 corresponding answer. 783 If the answer does not contain a BUNDLE group, the offerer MUST 784 process the answer as a normal answer. 786 8.5. Modifying the Session 788 When an offerer generates a subsequent offer (i.e., a BUNDLE group 789 has previously been negotiated), it MUST assign the previously 790 selected offerer BUNDLE address:port [Section 8.3.1], or a newly 791 suggested offerer BUNDLE address:port [Section 8.5.1], to exactly one 792 "m=" section within the BUNDLE group. 794 The offerer MUST NOT assign an offerer BUNDLE address:port 795 (previously selected [Section 8.3.1] or newly suggested 796 [Section 8.5.1]) to a bundled "m=" section if: 798 o The offerer wants to move the bundled "m=" section out of the 799 BUNDLE group [Section 8.5.3]; or 801 o The offerer wants to disable the bundled "m=" section 802 [Section 8.5.4]. 804 To every other "m=" section within the BUNDLE group, the offerer MUST 805 assign a zero port value and an SDP 'bundle-only' attribute. 807 When the offerer generates a subsequent offer, the offerer BUNDLE-tag 808 MUST represent the bundled "m=" section to which the offerer BUNDLE 809 address:port (previously negotiated or newly suggested) has been 810 assigned. 812 8.5.1. Suggesting a New Offerer BUNDLE Address:Port 814 When an offerer generates an offer, in which it suggests a new 815 offerer BUNDLE address:port [Section 8.2.1], the offerer MUST: 817 o Assign the newly suggested offerer BUNDLE address:port to exactly 818 one "m=" section within the BUNDLE group; and 820 o Assign a zero port value and an SDP 'bundle-only' attribute to 821 every other "m=" section within the BUNDLE group. 823 8.5.2. Adding a Media Description to a BUNDLE group 825 When an offerer generates an offer, in which it wants to add a new 826 bundled "m=" section, the offerer MUST: 828 o Assign the offerer BUNDLE address:port (previously selected 829 [Section 8.3.1] or newly suggested [Section 8.5.1]) to the added 830 "m=" section; or 832 o Assign a zero port value and an SDP 'bundle-only' attribute to the 833 added "m=" section (in this case the offerer BUNDLE address:port 834 is assigned to another "m=" section within the BUNDLE group). 836 In addition, the offerer MUST place the identification-tag associated 837 with the added "m=" section in the SDP 'group:BUNDLE' attribute 838 identification-tag list associated with the BUNDLE group 839 [Section 8.2.1]. 841 NOTE: If the offerer also wants to suggest a new offerer BUNDLE 842 address:port to the BUNDLE group, the offerer can assign the newly 843 suggested offerer BUNDLE address:port either to the added "m=" 844 section, or to some other "m=" section within the BUNDLE group 845 [Section 8.5.1]. To all the other "m=" sections within the BUNDLE 846 group the offerer will assign an SDP 'bundle-only' attribute and a 847 zero port value [Section 8.5.1]. 849 [Section 18.3] shows an example where an offerer sends an offer in 850 order to add a bundled "m=" section to a BUNDLE group. 852 8.5.3. Moving a Media Description Out of a BUNDLE Group 854 When an offerer generates an offer, in which it wants to move a 855 bundled "m=" section out of a BUNDLE group, the offerer: 857 o MUST assign a unique address:port to the "m=" section; and 859 o MUST NOT place the identification-tag associated with the "m=" 860 section in the SDP 'group:BUNDLE' attribute identification-tag 861 list associated with the BUNDLE group; and 863 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 864 section. 866 An offerer MUST NOT move an "m=" section from one BUNDLE group to 867 another within a single offer. If the offerer wants to move an "m=" 868 section from one BUNDLE group to another it MUST first move the 869 BUNDLE group out of the current BUNDLE group, and then generate a 870 second offer where the "m=" section is added to another BUNDLE group 871 [Section 8.5.2]. 873 [Section 18.4] shows an example of an offer for moving an "m=" 874 section out of a BUNDLE group. 876 8.5.4. Disabling a Media Description in a BUNDLE Group 878 When an offerer generates an offer, in which it wants to disable a 879 bundled "m=" section, the offerer: 881 o MUST assign a zero port value to the "m=" section, following the 882 procedures in [RFC4566]; and 884 o MUST NOT place the identification-tag associated with the "m=" 885 section in the SDP 'group:BUNDLE' attribute identification-tag 886 list associated with the BUNDLE group; and 888 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 889 section. 891 [Section 18.5] shows an example of an offer and answer for disabling 892 an "m=" section within a BUNDLE group. 894 9. Protocol Identification 896 Each "m=" section within a BUNDLE group MUST use the same transport- 897 layer protocol. If bundled "m=" sections use different upper-layer 898 protocols on top of the transport-layer protocol, there MUST exist a 899 publicly available specification which describes a mechanism how to 900 associate received data with the correct protocol for this particular 901 protocol combination. 903 In addition, if received data can be associated with more than one 904 bundled "m=" section, there MUST exist a publicly available 905 specification which describes a mechanism for associating the 906 received data with the correct "m=" section. 908 This document describes a mechanism to identify the protocol of 909 received data among the STUN, DTLS and SRTP protocols (in any 910 combination), when UDP is used as transport-layer protocol, but it 911 does not describe how to identify different protocols transported on 912 DTLS. While the mechanism is generally applicable to other protocols 913 and transport-layer protocols, any such use requires further 914 specification around how to multiplex multiple protocols on a given 915 transport-layer protocol, and how to associate received data with the 916 correct protocols. 918 9.1. STUN, DTLS, SRTP 920 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 921 protocol of a received packet among the STUN, DTLS and SRTP protocols 922 (in any combination). If an offer or answer includes a bundled "m=" 923 section that represents these protocols, the offerer or answerer MUST 924 support the mechanism described in [RFC5764], and no explicit 925 negotiation is required in order to indicate support and usage of the 926 mechanism. 928 [RFC5764] does not describe how to identify different protocols 929 transported on DTLS, only how to identify the DTLS protocol itself. 930 If multiple protocols are transported on DTLS, there MUST exist a 931 specification describing a mechanism for identifying each individual 932 protocol. In addition, if a received DTLS packet can be associated 933 with more than one "m=" section, there MUST exist a specification 934 which describes a mechanism for associating the received DTLS packets 935 with the correct "m=" section. 937 [Section 10.2] describes how to associate the packets in a received 938 SRTP stream with the correct "m=" section. 940 10. RTP Considerations 942 10.1. Single RTP Session 944 All RTP-based media within a single BUNDLE group belong to a single 945 RTP session [RFC3550]. 947 Since a single BUNDLE transport is used for sending and receiving 948 bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for 949 RTP-based bundled media. 951 Since a single RTP session is used for each BUNDLE group, all "m=" 952 sections representing RTP-based media within a BUNDLE group will 953 share a single SSRC numbering space [RFC3550]. 955 The following rules and restrictions apply for a single RTP session: 957 o A specific payload type value can be used in multiple bundled "m=" 958 sections only if each codec associated with the payload type 959 number shares an identical codec configuration [Section 10.1.1]. 961 o The proto value in each bundled RTP-based "m=" section MUST be 962 identical (e.g., RTP/AVPF). 964 o The RTP MID header extension MUST be enabled, by including an SDP 965 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 966 hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section 967 in every offer and answer. 969 o A given SSRC MUST NOT transmit RTP packets using payload types 970 that originate from different bundled "m=" sections. 972 NOTE: The last bullet above is to avoid sending multiple media types 973 from the same SSRC. If transmission of multiple media types are done 974 with time overlap, RTP and RTCP fail to function. Even if done in 975 proper sequence this causes RTP Timestamp rate switching issues 976 [RFC7160]. However, once an SSRC has left the RTP session (by 977 sending an RTCP BYE packet), that SSRC can be reused by another 978 source (possibly associated with a different bundled "m=" section) 979 after a delay of 5 RTCP reporting intervals (the delay is to ensure 980 the SSRC has timed out, in case the RTCP BYE packet was lost 981 [RFC3550]). 983 [RFC7657] defines Differentiated Services (Diffserv) considerations 984 for RTP-based bundled media sent using a mixture of Diffserv 985 Codepoints. 987 10.1.1. Payload Type (PT) Value Reuse 989 Multiple bundled "m=" sections might describe RTP based media. As 990 all RTP based media associated with a BUNDLE group belong to the same 991 RTP session, in order for a given payload type value to be used 992 inside more than one bundled "m=" section, all codecs associated with 993 the payload type number MUST share an identical codec configuration. 994 This means that the codecs MUST share the same media type, encoding 995 name, clock rate and any parameter that can affect the codec 996 configuration and packetization. 997 [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose 998 attribute values are required to be identical for all codecs that use 999 the same payload type value. 1001 10.2. Associating RTP/RTCP Streams with the Correct SDP Media 1002 Description 1004 As described in [RFC3550], RTP packets are associated with RTP 1005 streams [RFC7656]. Each RTP stream is identified by an SSRC value, 1006 and each RTP packet includes an SSRC field that is used to associate 1007 the packet with the correct RTP stream. RTCP packets also use SSRCs 1008 to identify which RTP streams the packet relates to. However, a RTCP 1009 packet can contain multiple SSRC fields, in the course of providing 1010 feedback or reports on different RTP streams, and therefore can be 1011 associated with multiple such streams. 1013 In order to be able to process received RTP/RTCP packets correctly, 1014 it MUST be possible to associate an RTP stream with the correct "m=" 1015 section, as the "m=" section and SDP attributes associated with the 1016 "m=" section contains information needed to process the packets. 1018 As all RTP streams associated with a BUNDLE group use the same 1019 transport for sending and receiving RTP/RTCP packets, the local 1020 address:port combination part of the transport cannot be used to 1021 associate an RTP stream with the correct "m=" section. In addition, 1022 multiple RTP streams might be associated with the same "m=" section. 1024 An offerer and answerer can inform each other which SSRC values they 1025 will use for an RTP stream by using the SDP 'ssrc' attribute 1026 [RFC5576]. However, an offerer will not know which SSRC values the 1027 answerer will use until the offerer has received the answer providing 1028 that information. Due to this, before the offerer has received the 1029 answer, the offerer will not be able to associate an RTP stream with 1030 the correct "m=" section using the SSRC value associated with the RTP 1031 stream. In addition, the offerer and answerer may start using new 1032 SSRC values mid-session, without informing each other using the SDP 1033 'ssrc' attribute. 1035 In order for an offerer and answerer to always be able to associate 1036 an RTP stream with the correct "m=" section, the offerer and answerer 1037 using the BUNDLE extension MUST support the mechanism defined in 1038 Section 15, where the offerer and answerer insert the identification- 1039 tag associated with an "m=" section (provided by the remote peer) 1040 into RTP and RTCP packets associated with a BUNDLE group. 1042 When using this mechanism, the mapping from an SSRC to an 1043 identification-tag is carried in RTP header extensions or RTCP SDES 1044 packets, as specified in Section 15. Since a compound RTCP packet 1045 can contain multiple RTCP SDES packets, and each RTCP SDES packet can 1046 contain multiple chunks, a single RTCP packet can contain several 1047 SSRC to identification-tag mappings. The offerer and answerer 1048 maintain tables used for routing that are updated each time an RTP/ 1049 RTCP packet contains new information that affects how packets are to 1050 be routed. 1052 However, some legacy implementations may not include this 1053 identification-tag in their RTP and RTCP traffic when using the 1054 BUNDLE mechanism, and instead use a payload type based mechanism to 1055 associate RTP streams with SDP "m=" sections. In this situation, 1056 each "m=" section needs to use unique payload type values, in order 1057 for the payload type to be a reliable indicator of the relevant "m=" 1058 section for the RTP stream. If an implementation fails to ensure 1059 unique payload type values it will be impossible to associate the RTP 1060 stream using that payload type value to a particular "m=" section. 1061 Note that when using the payload type to associate RTP streams with 1062 "m=" sections an RTP stream, identified by its SSRC, will be mapped 1063 to an "m=" section when the first packet of that RTP stream is 1064 received, and the mapping will not be changed even if the payload 1065 type used by that RTP stream changes. In other words, the SSRC 1066 cannot "move" to a different "m=" section simply by changing the 1067 payload type. 1069 Applications can implement RTP stacks in many different ways. The 1070 algorithm below details one way that RTP streams can be associated 1071 with "m=" sections, but is not meant to be prescriptive about exactly 1072 how an RTP stack needs to be implemented. Applications MAY use any 1073 algorithm that achieves equivalent results to those described in the 1074 algorithm below. 1076 To prepare to associate RTP streams with the correct "m=" section, 1077 the following steps MUST be followed for each BUNDLE group: 1079 Construct a table mapping MID to "m=" section for each "m=" 1080 section in this BUNDLE group. Note that an "m=" section may only 1081 have one MID. 1083 Construct a table mapping SSRCs of incoming RTP streams to "m=" 1084 section for each "m=" section in this BUNDLE group and for each 1085 SSRC configured for receiving in that "m=" section. 1087 Construct a table mapping the SSRC of each outgoing RTP stream to 1088 "m=" section for each "m=" section in this BUNDLE group and for 1089 each SSRC configured for sending in that "m=" section. 1091 Construct a table mapping payload type to "m=" section for each 1092 "m=" section in the BUNDLE group and for each payload type 1093 configured for receiving in that "m=" section. If any payload 1094 type is configured for receiving in more than one "m=" section in 1095 the BUNDLE group, do not include it in the table, as it cannot be 1096 used to uniquely identify an "m=" section. 1098 Note that for each of these tables, there can only be one mapping 1099 for any given key (MID, SSRC, or PT). In other words, the tables 1100 are not multimaps. 1102 As "m=" sections are added or removed from the BUNDLE groups, or 1103 their configurations are changed, the tables above MUST also be 1104 updated. 1106 When an RTP packet is received, it MUST be delivered to the RTP 1107 stream corresponding to its SSRC. That RTP stream MUST then be 1108 associated with the correct "m=" section within a BUNDLE group, for 1109 additional processing, according to the following steps: 1111 If the MID associated with the RTP stream is not in the table 1112 mapping MID to "m=" section, then the RTP stream is not decoded 1113 and the payload data is discarded. 1115 If the packet has a MID, and the packet's extended sequence number 1116 is greater than that of the last MID update, as discussed in 1117 [RFC7941], Section 4.2.6, update the MID associated with the RTP 1118 stream to match the MID carried in the RTP packet, then update the 1119 mapping tables to include an entry that maps the SSRC of that RTP 1120 stream to the "m=" section for that MID. 1122 If the SSRC of the RTP stream is in the incoming SSRC mapping 1123 table, check that the payload type used by the RTP stream matches 1124 a payload type included on the matching "m=" section. If so, 1125 associate the RTP stream with that "m=" section. Otherwise, the 1126 RTP stream is not decoded and the payload data is discarded. 1128 If the payload type used by the RTP stream is in the payload type 1129 table, update the incoming SSRC mapping table to include an entry 1130 that maps the RTP stream's SSRC to the "m=" section for that 1131 payload type. Associate the RTP stream with the corresponding 1132 "m=" section. 1134 Otherwise, mark the RTP stream as not for decoding and discard the 1135 payload. 1137 If the RTP packet contains one or more contributing source (CSRC) 1138 identifiers, then each CSRC is looked up in the incoming SSRC table 1139 and a copy of the RTP packet is associated with the corresponding 1140 "m=" section for additional processing. 1142 For each RTCP packet received (including each RTCP packet that is 1143 part of a compound RTCP packet), the packet is processed as usual by 1144 the RTP layer, then associated with the appropriate "m=" sections, 1145 and processed for the RTP streams represented by those "m=" sections. 1146 This routing is type-dependent, as each kind of RTCP packet has its 1147 own mechanism for associating it with the relevant RTP streams. 1149 RTCP packets that cannot be associated with an appropriate "m=" 1150 section MUST still be processed as usual by the RTP layer, updating 1151 the metadata associated with the corresponding RTP streams. This 1152 situation can occur with certain multiparty RTP topologies, or when 1153 RTCP packets are sent containing a subset of the SDES information. 1155 Additional rules for processing various types of RTCP packets are 1156 explained below. 1158 If the RTCP packet is of type SDES, for each chunk in the packet 1159 whose SSRC is found in the incoming SSRC table, deliver a copy of 1160 the SDES packet to the "m=" section associated with that SSRC. In 1161 addition, for any SDES MID items contained in these chunks, if the 1162 MID is found in the table mapping MID to "m=" section, update the 1163 incoming SSRC table to include an entry that maps the RTP stream 1164 associated with the chunk's SSRC to the "m=" section associated 1165 with that MID, unless the packet is older than the packet that 1166 most recently updated the mapping for this SSRC, as discussed in 1167 [RFC7941], Section 4.2.6. 1169 Note that if an SDES packet is received as part of a compound RTCP 1170 packet, the SSRC to "m=" section mapping might not exist until the 1171 SDES packet is handled (e.g., in the case where RTCP for a source 1172 is received before any RTP packets). Therefore, it can be 1173 beneficial for an implementation to delay RTCP packet routing, 1174 such that it either prioritizes processing of the SDES item to 1175 generate or update the mapping, or buffers the RTCP information 1176 that needs to be routed until the SDES item(s) has been processed. 1177 If the implementation is unable to follow this recommendation, the 1178 consequence could be that some RTCP information from this 1179 particular RTCP compound packet is not provided to higher layers. 1180 The impact from this is likely minor, when this information 1181 relates to a future incoming RTP stream. 1183 If the RTCP packet is of type BYE, it indicates that the RTP 1184 streams referenced in the packet are ending. Therefore, for each 1185 SSRC indicated in the packet that is found in the incoming SSRC 1186 table, first deliver a copy of the BYE packet to the "m=" section 1187 associated with that SSRC, then remove the entry for that SSRC 1188 from the incoming SSRC table after an appropriate delay to account 1189 for "straggler packets", as specified in [RFC3550], Section 6.2.1. 1191 If the RTCP packet is of type SR or RR, for each report block in 1192 the report whose "SSRC of source" is found in the outgoing SSRC 1193 table, deliver a copy of the SR or RR packet to the "m=" section 1194 associated with that SSRC. In addition, if the packet is of type 1195 SR, and the sender SSRC for the packet is found in the incoming 1196 SSRC table, deliver a copy of the SR packet to the "m=" section 1197 associated with that SSRC. 1199 If the implementation supports RTCP XR and the packet is of type 1200 XR, as defined in [RFC3611], for each report block in the report 1201 whose "SSRC of source" is found in the outgoing SSRC table, 1202 deliver a copy of the XR packet to the "m=" section associated 1203 with that SSRC. In addition, if the sender SSRC for the packet is 1204 found in the incoming SSRC table, deliver a copy of the XR packet 1205 to the "m=" section associated with that SSRC. 1207 If the RTCP packet is a feedback message of type RTPFB or PSFB, as 1208 defined in [RFC4585], it will contain a media source SSRC, and 1209 this SSRC is used for routing certain subtypes of feedback 1210 messages. However, several subtypes of PSFB and RTPFB messages 1211 include target SSRC(s) in a section called Feedback Control 1212 Information (FCI). For these messages, the target SSRC(s) are 1213 used for routing. 1215 If the RTCP packet is a feedback packet that does not include 1216 target SSRCs in its FCI section, and the media source SSRC is 1217 found in the outgoing SSRC table, deliver the feedback packet to 1218 the "m=" section associated with that SSRC. RTPFB and PSFB types 1219 that are handled in this way include: 1221 Generic NACK: [RFC4585] (PT=RTPFB, FMT=1). 1223 Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1). 1225 Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2). 1227 Reference Picture Selection Indication (RPSI): [RFC4585] 1228 (PT=PSFB, FMT=3). 1230 If the RTCP packet is a feedback message that does include target 1231 SSRC(s) in its FCI section, it can either be a request or a 1232 notification. Requests reference a RTP stream that is being sent 1233 by the message recipient, whereas notifications are responses to 1234 an earlier request, and therefore reference a RTP stream that is 1235 being received by the message recipient. 1237 If the RTCP packet is a feedback request that includes target 1238 SSRC(s), for each target SSRC that is found in the outgoing SSRC 1239 table, deliver a copy of the RTCP packet to the "m=" section 1240 associated with that SSRC. PSFB and RTPFB types that are handled 1241 in this way include: 1243 Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). 1245 Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, 1246 FMT=5). 1248 H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, 1249 FMT=7). 1251 Temporary Maximum Media Bit Rate Request (TMMBR): [RFC5104] 1252 (PT=RTPFB, FMT=3). 1254 Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, 1255 FMT=10). 1257 If the RTCP packet is a feedback notification that includes target 1258 SSRC(s), for each target SSRC that is found in the incoming SSRC 1259 table, deliver a copy of the RTCP packet to the "m=" section 1260 associated with the RTP stream with matching SSRC. PSFB and RTPFB 1261 types that are handled in this way include: 1263 Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] 1264 (PT=PSFB, FMT=6). This message is a notification in response 1265 to a prior TSTR. 1267 Temporary Maximum Media Bit Rate Notification (TMMBN): [RFC5104] 1268 (PT=RTPFB, FMT=4). This message is a notification in response 1269 to a prior TMMBR, but can also be sent unsolicited. 1271 If the RTCP packet is of type APP, then it is handled in an 1272 application specific manner. If the application does not 1273 recognise the APP packet, then it MUST be discarded. 1275 10.3. RTP/RTCP Multiplexing 1277 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 1278 multiplexing [RFC5761] for the RTP-based media specified by the 1279 BUNDLE group. In addition, the offerer and answerer MUST support the 1280 SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive]. 1282 When RTP/RTCP multiplexing is enabled, the same transport will be 1283 used for both RTP packets and RTCP packets associated with the BUNDLE 1284 group. 1286 10.3.1. SDP Offer/Answer Procedures 1288 This section describes how an offerer and answerer use the SDP 'rtcp- 1289 mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute 1290 [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP 1291 multiplexing for RTP-based media associated with a BUNDLE group. 1293 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] of the SDP 1294 'rtcp-mux' and 'rtcp-mux-only' attributes is IDENTICAL. Section 8.1 1295 describes the details regarding which bundled "m=" sections an 1296 offerer and answerer associates the attributes with. 1298 RTP/RTCP multiplexing only applies to RTP-based media. However, as 1299 described in Section 8.1, within a BUNDLE group the SDP 'rtcp-mux' 1300 and SDP 'rtcp-mux-only' attributes might be included in a non-RTP- 1301 based bundled "m=" section (if such "m=" line is indicated by a 1302 BUNDLE-tag). 1304 NOTE: The offer in which the offerer indicates that it wants to 1305 create a BUNDLE group can be the initial offer of the session, or a 1306 subsequent offer within the session. As defined in Section 2, within 1307 the scope of this document the initial offer always refers to the 1308 offer in which the offerer indicates that it wants to create a BUNDLE 1309 group, no matter whether that offer is the initial offer, or a 1310 subsequent offer, within the session. 1312 10.3.1.1. Generating the Initial SDP Offer 1314 When an offerer generates an initial offer, if the offer contains one 1315 or more RTP-based bundled "m=" sections (or, if there is a chance 1316 that RTP-based "m=" sections will later be added to the BUNDLE 1317 group), the offerer MUST include an SDP 'rtcp-mux' attribute 1318 [RFC5761] in each bundled "m=" section (excluding any bundle-only 1319 "m=" sections), following the procedures for IDENTICAL mux category 1320 attributes in Section 8.1. In addition, the offerer MAY include an 1321 SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] in a 1322 RTP-based bundled "m=" section. 1324 NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute 1325 depends on whether the offerer supports fallback to usage of a 1326 separate port for RTCP in case the answerer moves one or more RTP- 1327 based "m=" section out of the BUNDLE group in the answer. 1329 NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the 1330 bundled "m=" sections, but does not include an SDP 'rtcp-mux-only' 1331 attribute, the offerer can also include an SDP 'rtcp' attribute 1332 [RFC3605] in one or more RTP-based bundled "m=" sections in order to 1333 provide a fallback port for RTCP, as described in [RFC5761]. 1334 However, the fallback port will only be used for RTP-based "m=" 1335 sections moved out of the BUNDLE group by the answerer. 1337 In the initial offer, the address:port combination for RTCP MUST be 1338 unique in each bundled RTP-based "m=" section (excluding a bundle- 1339 only "m=" section), similar to RTP. 1341 10.3.1.2. Generating the SDP Answer 1343 When an answerer generates an answer, if the answerer supports RTP- 1344 based media, and if a bundled "m=" section in the offer contained an 1345 SDP 'rtcp-mux' attribute, the answerer MUST enable usage of RTP/RTCP 1346 multiplexing, even if there currently are no RTP-based "m=" sections 1347 within the BUNDLE group. The answerer MUST include an SDP 'rtcp-mux' 1348 attribute in the bundled "m=" section indicated by the answerer 1349 BUNDLE-tag, following the procedures for IDENTICAL mux category 1350 attributes in Section 8.1. In addition, if the "m=" section in the 1351 offer contained an SDP "rtcp-mux-only" attribute, the answerer MUST 1352 include an SDP "rtcp-mux-only" attribute in the bundled "m=" section 1353 indicated by the answerer BUNDLE-tag in the answer. 1355 If the "m=" section indicated by the offerer BUNDLE-tag in the offer 1356 contained an SDP 'rtcp-mux-only' attribute, and if the answerer moves 1357 an RTP-based "m=" section out of the BUNDLE group in the answer 1358 [Section 8.3.3], the answerer MUST either include the attribute in 1359 the moved "m=" section (and enable RTP/RTCP multiplexing for the 1360 media associated with the "m=" section), or reject the "m=" section 1361 [Section 8.3.4]. 1363 The answerer MUST NOT include an SDP 'rtcp' attribute in any "m=" 1364 section within the BUNDLE group in the answer. The answerer will use 1365 the port value of the selected offerer BUNDLE address:port for 1366 sending RTP and RTCP packets associated with each RTP-based bundled 1367 "m=" section towards the offerer. 1369 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1370 negotiated in a previous offer/answer exchange, the answerer MUST 1371 include an SDP 'rtcp-mux' attribute in the "m=" section associated 1372 with the answerer BUNDLE-tag in the answer. It is not possible to 1373 disable RTP/RTCP multiplexing within a BUNDLE group. 1375 10.3.1.3. Offerer Processing of the SDP Answer 1377 When an offerer receives an answer, if the answerer has accepted the 1378 usage of RTP/RTCP multiplexing (see Section 10.3.1.2), the answerer 1379 follows the procedures for RTP/RTCP multiplexing defined in 1380 [RFC5761]. The offerer will use the port value associated with the 1381 answerer BUNDLE address:port for sending RTP and RTCP packets 1382 associated with each RTP-based bundled "m=" section towards the 1383 answerer. 1385 NOTE: It is considered a protocol error if the answerer has not 1386 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" 1387 sections that the answerer included in the BUNDLE group. 1389 10.3.1.4. Modifying the Session 1391 When an offerer generates a subsequent offer, the offerer MUST 1392 include an SDP 'rtcp-mux' attribute in the bundled "m=" section 1393 indicated by the offerer BUNDLE-tag, following the procedures for 1394 IDENTICAL mux category attributes in Section 8.1. 1396 11. ICE Considerations 1398 This section describes how to use the BUNDLE grouping extension 1399 together with the Interactive Connectivity Establishment (ICE) 1400 mechanism [I-D.ietf-ice-rfc5245bis]. 1402 The generic procedures for negotiating usage of ICE using SDP, 1403 defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE 1404 with BUNDLE, with the following exceptions: 1406 o When the BUNDLE transport has been established, ICE connectivity 1407 checks and keep-alives only need to be performed for the BUNDLE 1408 transport, instead of per individual "m=" section within the 1409 BUNDLE group. 1411 o In an offer, if the offer assigns a unique address:port to one or 1412 more bundled "m=" sections (excluding any bundle-only "m=" 1413 sections), the offerer MUST include ICE-related media-level 1414 attributes in each of those "m=" sections. If the offerer assigns 1415 an offerer BUNDLE address:port (previously selected 1416 [Section 8.3.1] or newly suggested [Section 8.5.1]) to a bundled 1417 "m=" section (the "m=" section indicated by the offerer BUNDLE- 1418 tag), the offerer only includes ICE-related media-level SDP 1419 attributes in that "m=" section, following the procedures in 1420 Section 8.1. 1422 o In an answer, the answerer only includes ICE-related media-level 1423 SDP attributes in the bundled "m=" section to which the answerer 1424 has assigned the answerer BUNDLE address:port (the "m=" section 1425 indicated by the answerer BUNDLE-tag), following the procedures in 1426 Section 8.1. 1428 Initially, before ICE has produced a candidate pair that will be used 1429 for media, there might be multiple transports established (if 1430 multiple candidate pairs are tested). Once ICE has produced a 1431 transport that will be used for media, that becomes the BUNDLE 1432 transport. 1434 Support and usage of ICE mechanism together with the BUNDLE extension 1435 is OPTIONAL, and the procedures in this section only apply when the 1436 ICE mechanism is used. Note that applications might mandate usage of 1437 the ICE mechanism even if the BUNDLE extension is not used. 1439 11.1. SDP Offer/Answer Procedures 1441 When an offerer assigns a unique address:port to one or more bundled 1442 "m=" sections (excluding any bundle-only "m=" section), the offerer 1443 MUST include SDP 'candidate' attributes (and other applicable ICE- 1444 related media-level SDP attributes), containing unique ICE properties 1445 (candidates etc), in each of those "m=" sections, following the 1446 procedures in [I-D.ietf-mmusic-ice-sip-sdp]. 1448 When an offerer assigns a BUNDLE address:port (previously selected or 1449 newly suggested) to a bundled "m=" section, (the "m=" section 1450 indicated by the offerer BUNDLE-tag) the offerer MUST only include 1451 SDP 'candidate' attributes (and other applicable ICE-related media- 1452 level SDP attributes) in that "m=" section, following the procedures 1453 in Section 8.1. 1455 When an answerer assigns a BUNDLE address to an "m=" section within a 1456 BUNDLE group (the "m=" section represented by the answerer BUNDLE- 1457 tag), the answerer only includes SDP 'candidate' attributes (and 1458 other applicable ICE-related media-level SDP attributes) in that "m=" 1459 section, following the procedures in Section 8.1. The answerer MUST 1460 NOT include ICE-related media-level SDP attributes in any other "m=" 1461 sections. 1463 NOTE: If the trickle ICE mechanism [I-D.ietf-mmusic-trickle-ice-sip] 1464 is used, an offerer and answerer might assign a port value of '9', 1465 and an IPv4 address of '0.0.0.0' (or, the IPv6 equivalent '::') to 1466 multiple "m=" sections. As far as the procedures in this 1467 specification are concerned, before a BUNDLE group has been 1468 negotiated, those addresses:ports are processed as unique 1469 addresses:ports. 1471 NOTE: As most ICE-related media-level SDP attributes belong to the 1472 TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the 1473 offerer and answerer follow the procedures in Section 8.1 when 1474 deciding whether to include an attribute in a bundled "m=" section. 1475 However, in the case of ICE-related media-level attributes, the rules 1476 apply to all attributes (see note below), even if they belong to a 1477 different mux category. 1479 NOTE: The following ICE-related media-level SDP attributes are 1480 defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidate', 'remote- 1481 candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- 1482 pacing'. 1484 12. DTLS Considerations 1486 One or more media streams within a BUNDLE group might use the 1487 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1488 to encrypt the data, or to negotiate encryption keys if another 1489 encryption mechanism is used to encrypt media. 1491 When DTLS is used within a BUNDLE group, the following rules apply: 1493 o There can only be one DTLS association [RFC6347] associated with 1494 the BUNDLE group; and 1496 o Each usage of the DTLS association within the BUNDLE group MUST 1497 use the same mechanism for determining which endpoints (the 1498 offerer or answerer) become DTLS client and DTLS server; and 1500 o Each usage of the DTLS association within the BUNDLE group MUST 1501 use the same mechanism for determining whether an offer or answer 1502 will trigger the establishment of a new DTLS association, or 1503 whether an existing DTLS association will be used; and 1505 o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include 1506 the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message 1507 [RFC5764]. The client MUST include the extension even if the 1508 usage of DTLS-SRTP is not negotiated as part of the multimedia 1509 session (e.g., SIP session [RFC3261]). 1511 NOTE: The inclusion of the 'use_srtp' extension during the initial 1512 DTLS handshake ensures that a DTLS renegotiation will not be required 1513 in order to include the extension, in case DTLS-SRTP encrypted media 1514 is added to the BUNDLE group later during the multimedia session. 1516 13. RTP Header Extensions Consideration 1518 When [RFC8285] RTP header extensions are used in the context of this 1519 specification, the identifier used for a given extension MUST 1520 identify the same extension across all the bundled media 1521 descriptions. 1523 14. Update to RFC 3264 1525 This section updates RFC 3264, in order to allow extensions to define 1526 the usage of a zero port value in offers and answers for other 1527 purposes than removing or disabling media streams. The following 1528 sections of RFC 3264 are updated: 1530 o Section 5.1 (Unicast Streams). 1532 o Section 8.4 (Putting a Unicast Media Stream on Hold). 1534 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 1536 For recvonly and sendrecv streams, the port number and address in the 1537 offer indicate where the offerer would like to receive the media 1538 stream. For sendonly RTP streams, the address and port number 1539 indirectly indicate where the offerer wants to receive RTCP reports. 1540 Unless there is an explicit indication otherwise, reports are sent to 1541 the port number one higher than the number indicated. The IP address 1542 and port present in the offer indicate nothing about the source IP 1543 address and source port of RTP and RTCP packets that will be sent by 1544 the offerer. A port number of zero in the offer indicates that the 1545 stream is offered but MUST NOT be used. This has no useful semantics 1546 in an initial offer, but is allowed for reasons of completeness, 1547 since the answer can contain a zero port indicating a rejected stream 1548 (Section 6). Furthermore, existing streams can be terminated by 1549 setting the port to zero (Section 8). In general, a port number of 1550 zero indicates that the media stream is not wanted. 1552 14.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 1554 For recvonly and sendrecv streams, the port number and address in the 1555 offer indicate where the offerer would like to receive the media 1556 stream. For sendonly RTP streams, the address and port number 1557 indirectly indicate where the offerer wants to receive RTCP reports. 1558 Unless there is an explicit indication otherwise, reports are sent to 1559 the port number one higher than the number indicated. The IP address 1560 and port present in the offer indicate nothing about the source IP 1561 address and source port of RTP and RTCP packets that will be sent by 1562 the offerer. A port number of zero in the offer by default indicates 1563 that the stream is offered but MUST NOT be used, but an extension 1564 mechanism might specify different semantics for the usage of a zero 1565 port value. Furthermore, existing streams can be terminated by 1566 setting the port to zero (Section 8). In general, a port number of 1567 zero by default indicates that the media stream is not wanted. 1569 14.3. Original text of section 8.4 (6th paragraph) of RFC 3264 1571 RFC 2543 [10] specified that placing a user on hold was accomplished 1572 by setting the connection address to 0.0.0.0. Its usage for putting 1573 a call on hold is no longer recommended, since it doesn't allow for 1574 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1575 with connection oriented media. However, it can be useful in an 1576 initial offer when the offerer knows it wants to use a particular set 1577 of media streams and formats, but doesn't know the addresses and 1578 ports at the time of the offer. Of course, when used, the port 1579 number MUST NOT be zero, which would specify that the stream has been 1580 disabled. An agent MUST be capable of receiving SDP with a 1581 connection address of 0.0.0.0, in which case it means that neither 1582 RTP nor RTCP is to be sent to the peer. 1584 14.4. New text replacing section 8.4 (6th paragraph) of RFC 3264 1586 RFC 2543 [10] specified that placing a user on hold was accomplished 1587 by setting the connection address to 0.0.0.0. Its usage for putting 1588 a call on hold is no longer recommended, since it doesn't allow for 1589 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1590 with connection oriented media. However, it can be useful in an 1591 initial offer when the offerer knows it wants to use a particular set 1592 of media streams and formats, but doesn't know the addresses and 1593 ports at the time of the offer. Of course, when used, the port 1594 number MUST NOT be zero, if it would specify that the stream has been 1595 disabled. However, an extension mechanism might specify different 1596 semantics of the zero port number usage. An agent MUST be capable of 1597 receiving SDP with a connection address of 0.0.0.0, in which case it 1598 means that neither RTP nor RTCP is to be sent to the peer. 1600 15. RTP/RTCP extensions for identification-tag transport 1602 SDP Offerers and Answerers [RFC3264] can associate identification- 1603 tags with "m=" sections within SDP Offers and Answers, using the 1604 procedures in [RFC5888]. Each identification-tag uniquely represents 1605 an "m=" section. 1607 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1608 used to carry identification-tags within RTCP SDES packets. This 1609 section also defines a new RTP SDES header extension [RFC7941], which 1610 is used to carry the 'MID' RTCP SDES item in RTP packets. 1612 The SDES item and RTP SDES header extension make it possible for a 1613 receiver to associate each RTP stream with a specific "m=" section, 1614 with which the receiver has associated an identification-tag, even if 1615 those "m=" sections are part of the same RTP session. The RTP SDES 1616 header extension also ensures that the media recipient gets the 1617 identification-tag upon receipt of the first decodable media and is 1618 able to associate the media with the correct application. 1620 A media recipient informs the media sender about the identification- 1621 tag associated with an "m=" section through the use of an 'mid' 1622 attribute [RFC5888]. The media sender then inserts the 1623 identification-tag in RTCP and RTP packets sent to the media 1624 recipient. 1626 NOTE: This text above defines how identification-tags are carried in 1627 SDP Offers and Answers. The usage of other signaling protocols for 1628 carrying identification-tags is not prevented, but the usage of such 1629 protocols is outside the scope of this document. 1631 [RFC3550] defines general procedures regarding the RTCP transmission 1632 interval. The RTCP MID SDES item SHOULD be sent in the first few 1633 RTCP packets sent after joining the session, and SHOULD be sent 1634 regularly thereafter. The exact number of RTCP packets in which this 1635 SDES item is sent is intentionally not specified here, as it will 1636 depend on the expected packet loss rate, the RTCP reporting interval, 1637 and the allowable overhead. 1639 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1640 be included in some RTP packets at the start of the session and 1641 whenever the SSRC changes. It might also be useful to include the 1642 header extension in RTP packets that comprise access points in the 1643 media (e.g., with video I-frames). The exact number of RTP packets 1644 in which this header extension is sent is intentionally not specified 1645 here, as it will depend on expected packet loss rate and loss 1646 patterns, the overhead the application can tolerate, and the 1647 importance of immediate receipt of the identification-tag. 1649 For robustness, endpoints need to be prepared for situations where 1650 the reception of the identification-tag is delayed, and SHOULD NOT 1651 terminate sessions in such cases, as the identification-tag is likely 1652 to arrive soon. 1654 15.1. RTCP MID SDES Item 1656 0 1 2 3 1657 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 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 | MID=TBD | length | identification-tag ... 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP. 1664 The identification-tag is not zero terminated. 1666 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1667 identifier value.] 1669 15.2. RTP SDES Header Extension For MID 1671 The payload, containing the identification-tag, of the RTP SDES 1672 header extension element can be encoded using either the one-byte or 1673 two-byte header [RFC7941]. The identification-tag payload is UTF-8 1674 encoded, as in SDP. 1676 The identification-tag is not zero terminated. Note, that the set of 1677 header extensions included in the packet needs to be padded to the 1678 next 32-bit boundary using zero bytes [RFC8285]. 1680 As the identification-tag is included in either an RTCP SDES item or 1681 an RTP SDES header extension, or both, there needs to be some 1682 consideration about the packet expansion caused by the 1683 identification-tag. To avoid Maximum Transmission Unit (MTU) issues 1684 for the RTP packets, the header extension's size needs to be taken 1685 into account when encoding the media. 1687 It is recommended that the identification-tag is kept short. Due to 1688 the properties of the RTP header extension mechanism, when using the 1689 one-byte header, a tag that is 1-3 bytes will result in a minimal 1690 number of 32-bit words used for the RTP SDES header extension, in 1691 case no other header extensions are included at the same time. Note, 1692 do take into account that some single characters when UTF-8 encoded 1693 will result in multiple octets. The identification-tag MUST NOT 1694 contain any user information, and applications SHALL avoid generating 1695 the identification-tag using a pattern that enables user- or 1696 application identification. 1698 16. IANA Considerations 1700 16.1. New SDES item 1702 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1703 document.] 1705 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1706 identifier value.] 1708 This document adds the MID SDES item to the IANA "RTP SDES item 1709 types" registry as follows: 1711 Value: TBD 1712 Abbrev.: MID 1713 Name: Media Identification 1714 Reference: RFCXXXX 1716 16.2. New RTP SDES Header Extension URI 1718 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1719 document.] 1721 This document defines a new extension URI in the RTP SDES Compact 1722 Header Extensions sub-registry of the RTP Compact Header Extensions 1723 registry sub-registry, according to the following data: 1725 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1726 Description: Media identification 1727 Contact: IESG (iesg@ietf.org) 1728 Reference: RFCXXXX 1730 The SDES item does not reveal privacy information about the users. 1731 It is simply used to associate RTP-based media with the correct SDP 1732 media description ("m=" section) in the SDP used to negotiate the 1733 media. 1735 The purpose of the extension is for the offerer to be able to 1736 associate received multiplexed RTP-based media before the offerer 1737 receives the associated SDP answer. 1739 16.3. New SDP Attribute 1741 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1742 document.] 1744 This document defines a new SDP media-level attribute, 'bundle-only', 1745 according to the following data: 1747 Attribute name: bundle-only 1748 Type of attribute: media 1749 Subject to charset: No 1750 Purpose: Request a media description to be accepted 1751 in the answer only if kept within a BUNDLE 1752 group by the answerer. 1753 Appropriate values: N/A 1754 Contact name: IESG 1755 Contact e-mail: iesg@ietf.org 1756 Reference: RFCXXXX 1757 Mux category: NORMAL 1759 16.4. New SDP Group Semantics 1761 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1762 document.] 1764 This document registers the following semantics with IANA in the 1765 "Semantics for the "group" SDP Attribute" subregistry (under the 1766 "Session Description Protocol (SDP) Parameters" registry: 1768 Semantics Token Reference 1769 ------------------------------------- ------ --------- 1770 Media bundling BUNDLE [RFCXXXX] 1772 Mux category: NORMAL 1774 17. Security Considerations 1776 The security considerations defined in [RFC3264] and [RFC5888] apply 1777 to the BUNDLE extension. Bundle does not change which information, 1778 e.g., RTP streams, flows over the network, with the exception of the 1779 usage of the MID SDES item as discussed below. Primarily it changes 1780 which addresses and ports, and thus in which (RTP) sessions the 1781 information is flowing. This affects the security contexts being 1782 used and can cause previously separated information flows to share 1783 the same security context. This has very little impact on the 1784 performance of the security mechanism of the RTP sessions. In cases 1785 where one would have applied different security policies on the 1786 different RTP streams being bundled, or where the parties having 1787 access to the security contexts would have differed between the RTP 1788 streams, additional analysis of the implications are needed before 1789 selecting to apply BUNDLE. 1791 The identification-tag, independent of transport, RTCP SDES packet or 1792 RTP header extension, can expose the value to parties beyond the 1793 signaling chain. Therefore, the identification-tag values MUST be 1794 generated in a fashion that does not leak user information, e.g., 1795 randomly or using a per-bundle group counter, and SHOULD be 3 bytes 1796 or less, to allow them to efficiently fit into the MID RTP header 1797 extension. Note that if implementations use different methods for 1798 generating identification-tags this could enable fingerprinting of 1799 the implementation making it vulnerable to targeted attacks. The 1800 identification-tag is exposed on the RTP stream level when included 1801 in the RTP header extensions, however what it reveals of the RTP 1802 media stream structure of the endpoint and application was already 1803 possible to deduce from the RTP streams without the MID SDES header 1804 extensions. As the identification-tag is also used to route the 1805 media stream to the right application functionality it is important 1806 that the value received is the one intended by the sender, thus 1807 integrity and the authenticity of the source are important to prevent 1808 denial of service on the application. Existing SRTP configurations 1809 and other security mechanisms protecting the whole RTP/RTCP packets 1810 will provide the necessary protection. 1812 When the BUNDLE extension is used, the set of configurations of the 1813 security mechanism used in all the bundled media descriptions will 1814 need to be compatible so that they can be used simultaneously, at 1815 least per direction or endpoint. When using SRTP this will be the 1816 case, at least for the IETF defined key-management solutions due to 1817 their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their 1818 classification in [I-D.ietf-mmusic-sdp-mux-attributes]. 1820 The security considerations of "RTP Header Extension for the RTP 1821 Control Protocol (RTCP) Source Description Items" [RFC7941] requires 1822 that when RTCP is confidentiality protected, then any SDES RTP header 1823 extension carrying an SDES item, such as the MID RTP header 1824 extension, is also protected using commensurate strength algorithms. 1825 However, assuming the above requirements and recommendations are 1826 followed, there are no known significant security risks with leaving 1827 the MID RTP header extension without confidentiality protection. 1828 Therefore, this specification updates RFC 7941 by adding the 1829 exception that this requirement MAY be ignored for the MID RTP header 1830 extension. Security mechanisms for RTP/RTCP are discussed in Options 1831 for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can 1832 provide the necessary security functions of ensuring the integrity 1833 and source authenticity. 1835 18. Examples 1837 18.1. Example: BUNDLE Address:Port Selection 1839 The example below shows: 1841 o An offer, in which the offerer assigns a unique address:port to 1842 each bundled "m=" section within the BUNDLE group. 1844 o An answer, in which the answerer selects the offerer BUNDLE 1845 address:port, and then selects its own BUNDLE address (the 1846 answerer BUNDLE address:port) and assigns it to the bundled "m=" 1847 section indicated by the answerer BUNDLE-tag. 1849 SDP Offer (1) 1851 v=0 1852 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1853 s= 1854 c=IN IP6 2001:db8::3 1855 t=0 0 1856 a=group:BUNDLE foo bar 1858 m=audio 10000 RTP/AVP 0 8 97 1859 b=AS:200 1860 a=mid:foo 1861 a=rtcp-mux 1862 a=rtpmap:0 PCMU/8000 1863 a=rtpmap:8 PCMA/8000 1864 a=rtpmap:97 iLBC/8000 1865 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1867 m=video 10002 RTP/AVP 31 32 1868 b=AS:1000 1869 a=mid:bar 1870 a=rtcp-mux 1871 a=rtpmap:31 H261/90000 1872 a=rtpmap:32 MPV/90000 1873 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1875 SDP Answer (2) 1877 v=0 1878 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1879 s= 1880 c=IN IP6 2001:db8::1 1881 t=0 0 1882 a=group:BUNDLE foo bar 1884 m=audio 20000 RTP/AVP 0 1885 b=AS:200 1886 a=mid:foo 1887 a=rtcp-mux 1888 a=rtpmap:0 PCMU/8000 1889 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1891 m=video 0 RTP/AVP 32 1892 b=AS:1000 1893 a=mid:bar 1894 a=bundle-only 1895 a=rtpmap:32 MPV/90000 1896 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1898 18.2. Example: BUNDLE Extension Rejected 1900 The example below shows: 1902 o An offer, in which the offerer assigns a unique address:port to 1903 each bundled "m=" section within the BUNDLE group. 1905 o An answer, in which the answerer rejects the offered BUNDLE group, 1906 and assigns a unique address:port to each "m=" section (following 1907 normal RFC 3264 procedures). 1909 SDP Offer (1) 1911 v=0 1912 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1913 s= 1914 c=IN IP6 2001:db8::3 1915 t=0 0 1916 a=group:BUNDLE foo bar 1918 m=audio 10000 RTP/AVP 0 8 97 1919 b=AS:200 1920 a=mid:foo 1921 a=rtcp-mux 1922 a=rtpmap:0 PCMU/8000 1923 a=rtpmap:8 PCMA/8000 1924 a=rtpmap:97 iLBC/8000 1925 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1927 m=video 10002 RTP/AVP 31 32 1928 b=AS:1000 1929 a=mid:bar 1930 a=rtcp-mux 1931 a=rtpmap:31 H261/90000 1932 a=rtpmap:32 MPV/90000 1933 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1935 SDP Answer (2) 1937 v=0 1938 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1939 s= 1940 c=IN IP6 2001:db8::1 1941 t=0 0 1943 m=audio 20000 RTP/AVP 0 1944 b=AS:200 1945 a=rtcp-mux 1946 a=rtpmap:0 PCMU/8000 1948 m=video 30000 RTP/AVP 32 1949 b=AS:1000 1950 a=rtcp-mux 1951 a=rtpmap:32 MPV/90000 1953 18.3. Example: Offerer Adds a Media Description to a BUNDLE Group 1955 The example below shows: 1957 o A subsequent offer (the BUNDLE group has been created as part of a 1958 previous offer/answer exchange), in which the offerer adds a new 1959 "m=" section, indicated by the "zen" identification-tag, to a 1960 previously negotiated BUNDLE group, assigns the previously 1961 selected offerer BUNDLE address:port to the added "m=" section, 1962 indicated by the offerer BUNDLE-tag. To every other bundled "m=" 1963 section the offerer assigns a zero port value and includes an SDP 1964 'bundle-only' attribute. 1966 o An answer, in which the answerer assigns the answerer BUNDLE 1967 address:port to the bundled "m=" section indicated by the answerer 1968 BUNDLE-tag. To every other bundled "m=" section the answerer 1969 assigns a zero port value and includes an SDP 'bundle-only' 1970 attribute. 1972 SDP Offer (1) 1974 v=0 1975 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1976 s= 1977 c=IN IP6 2001:db8::3 1978 t=0 0 1979 a=group:BUNDLE zen foo bar 1981 m=audio 0 RTP/AVP 0 8 97 1982 b=AS:200 1983 a=mid:foo 1984 a=bundle-only 1985 a=rtpmap:0 PCMU/8000 1986 a=rtpmap:8 PCMA/8000 1987 a=rtpmap:97 iLBC/8000 1988 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1990 m=video 0 RTP/AVP 31 32 1991 b=AS:1000 1992 a=mid:bar 1993 a=bundle-only 1994 a=rtpmap:31 H261/90000 1995 a=rtpmap:32 MPV/90000 1996 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1998 m=video 10000 RTP/AVP 66 1999 b=AS:1000 2000 a=mid:zen 2001 a=rtcp-mux 2002 a=rtpmap:66 H261/90000 2003 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2005 SDP Answer (2) 2007 v=0 2008 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2009 s= 2010 c=IN IP6 2001:db8::1 2011 t=0 0 2012 a=group:BUNDLE zen foo bar 2014 m=audio 0 RTP/AVP 0 2015 b=AS:200 2016 a=mid:foo 2017 a=bundle-only 2018 a=rtpmap:0 PCMU/8000 2019 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2021 m=video 0 RTP/AVP 32 2022 b=AS:1000 2023 a=mid:bar 2024 a=bundle-only 2025 a=rtpmap:32 MPV/90000 2026 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2028 m=video 20000 RTP/AVP 66 2029 b=AS:1000 2030 a=mid:zen 2031 a=rtcp-mux 2032 a=rtpmap:66 H261/90000 2033 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2035 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 2037 The example below shows: 2039 o A subsequent offer (the BUNDLE group has been created as part of a 2040 previous offer/answer transaction), in which the offerer moves a 2041 bundled "m=" section, indicated by the "zen" identification-tag, 2042 out of a BUNDLE group, assigns a unique address:port to the moved 2043 "m=" section, and assigns the previously selected offerer BUNDLE 2044 address:port to another bundled "m=" section, indicated by the 2045 offerer BUNDLE-tag. To every other bundled "m=" section the 2046 offerer assigns a zero port value and includes an SDP 'bundle- 2047 only' attribute. 2049 o An answer, in which the answerer moves the "m=" section out of the 2050 BUNDLE group, assigns a unique address:port to the moved "m=" 2051 section, and assigns the answerer BUNDLE address:port to the 2052 bundled "m=" section indicated by the answerer BUNDLE-tag. To 2053 every other bundled "m=" section the answerer assigns a zero port 2054 value and includes an SDP 'bundle-only' attribute. 2056 SDP Offer (1) 2058 v=0 2059 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2060 s= 2061 c=IN IP6 2001:db8::3 2062 t=0 0 2063 a=group:BUNDLE foo bar 2065 m=audio 10000 RTP/AVP 0 8 97 2066 b=AS:200 2067 a=mid:foo 2068 a=rtcp-mux 2069 a=rtpmap:0 PCMU/8000 2070 a=rtpmap:8 PCMA/8000 2071 a=rtpmap:97 iLBC/8000 2072 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2074 m=video 0 RTP/AVP 31 32 2075 b=AS:1000 2076 a=mid:bar 2077 a=bundle-only 2078 a=rtpmap:31 H261/90000 2079 a=rtpmap:32 MPV/90000 2080 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2082 m=video 50000 RTP/AVP 66 2083 b=AS:1000 2084 a=mid:zen 2085 a=rtcp-mux 2086 a=rtpmap:66 H261/90000 2088 SDP Answer (2) 2090 v=0 2091 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2092 s= 2093 c=IN IP6 2001:db8::1 2094 t=0 0 2095 a=group:BUNDLE foo bar 2097 m=audio 20000 RTP/AVP 0 2098 b=AS:200 2099 a=mid:foo 2100 a=rtcp-mux 2101 a=rtpmap:0 PCMU/8000 2102 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2104 m=video 0 RTP/AVP 32 2105 b=AS:1000 2106 a=mid:bar 2107 a=bundle-only 2108 a=rtpmap:32 MPV/90000 2109 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2111 m=video 60000 RTP/AVP 66 2112 b=AS:1000 2113 a=mid:zen 2114 a=rtcp-mux 2115 a=rtpmap:66 H261/90000 2117 18.5. Example: Offerer Disables a Media Description Within a BUNDLE 2118 Group 2120 The example below shows: 2122 o A subsequent offer (the BUNDLE group has been created as part of a 2123 previous offer/answer transaction), in which the offerer disables 2124 a bundled "m=" section indicated by the "zen" identification-tag, 2125 within a BUNDLE group, assigns a zero port number to the disabled 2126 "m=" section, and assigns the offerer BUNDLE address:port to 2127 another bundled "m=" section, indicated by the offerer BUNDLE-tag. 2128 To every other bundled "m=" section the offerer assigns a zero 2129 port value and includes an SDP 'bundle-only' attribute. 2131 o An answer, in which the answerer moves the disabled "m=" sections 2132 out of the BUNDLE group, assigns a zero port value to the disabled 2133 "m=" section, and assigns the answerer BUNDLE address:port to the 2134 bundled "m=" section indicated by the answerer BUNDLE-tag. To 2135 every other bundled "m=" section the answerer assigns a zero port 2136 value and includes an SDP 'bundle-only' attribute. 2138 SDP Offer (1) 2140 v=0 2141 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2142 s= 2143 t=0 0 2144 a=group:BUNDLE foo bar 2146 m=audio 10000 RTP/AVP 0 8 97 2147 c=IN IP6 2001:db8::3 2148 b=AS:200 2149 a=mid:foo 2150 a=rtcp-mux 2151 a=rtpmap:0 PCMU/8000 2152 a=rtpmap:8 PCMA/8000 2153 a=rtpmap:97 iLBC/8000 2154 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2156 m=video 0 RTP/AVP 31 32 2157 c=IN IP6 2001:db8::3 2158 b=AS:1000 2159 a=mid:bar 2160 a=bundle-only 2161 a=rtpmap:31 H261/90000 2162 a=rtpmap:32 MPV/90000 2163 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2165 m=video 0 RTP/AVP 66 2166 a=mid:zen 2167 a=rtpmap:66 H261/90000 2169 SDP Answer (2) 2171 v=0 2172 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2173 s= 2174 t=0 0 2175 a=group:BUNDLE foo bar 2177 m=audio 20000 RTP/AVP 0 2178 c=IN IP6 2001:db8::1 2179 b=AS:200 2180 a=mid:foo 2181 a=rtcp-mux 2182 a=rtpmap:0 PCMU/8000 2183 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2184 m=video 0 RTP/AVP 32 2185 c=IN IP6 2001:db8::1 2186 b=AS:1000 2187 a=mid:bar 2188 a=bundle-only 2189 a=rtpmap:32 MPV/90000 2190 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2192 m=video 0 RTP/AVP 66 2193 a=mid:zen 2194 a=rtpmap:66 H261/90000 2196 19. Acknowledgements 2198 The usage of the SDP grouping extension for negotiating bundled media 2199 is based on similar alternatives proposed by Harald Alvestrand and 2200 Cullen Jennings. The BUNDLE extension described in this document is 2201 based on the different alternative proposals, and text (e.g., SDP 2202 examples) have been borrowed (and, in some cases, modified) from 2203 those alternative proposals. 2205 The SDP examples are also modified versions from the ones in the 2206 Alvestrand proposal. 2208 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 2209 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 2210 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin 2211 Uberti, Taylor Brandstetter, Byron Campen and Eric Rescorla for 2212 reading the text, and providing useful feedback. 2214 Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus 2215 Westerlund for providing the text for the section on RTP/RTCP stream 2216 association. 2218 Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for 2219 providing help and text on the RTP/RTCP procedures. 2221 Thanks to Charlie Kaufman for performing the Sec-Dir review. 2223 Thanks to Linda Dunbar for performing the Gen-ART review. 2225 Thanks to Spotify for providing music for the countless hours of 2226 document editing. 2228 20. Change Log 2230 [RFC EDITOR NOTE: Please remove this section when publishing] 2232 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-49 2234 o Changes based on IESG reviews. 2236 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-48 2238 o Changes based on Sec-Dir review by Charlie Kaufman. 2240 o - s/unique address/unique address:port 2242 o Changes based on Gen-ART review by Linda Dunbar. 2244 o Mux category for group:BUNDLE attribute added. 2246 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-47 2248 o Changes based on AD review by Ben Campbell. 2250 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-46 2252 o Pre-RFC5378 disclaimer removed put back. 2254 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-45 2256 o Mux category for SDP 'group:BUNDLE' attribute added. 2258 o https://github.com/cdh4u/draft-sdp-bundle/pull/54 2260 o Pre-RFC5378 disclaimer removed. 2262 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-44 2264 o Minor editorial nits based on pull request by Colin P. 2266 o https://github.com/cdh4u/draft-sdp-bundle/pull/53 2268 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-43 2270 o Changes based on WG chairs review. 2272 o Text added in order to close GitHub issues by Taylor B. 2274 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-42 2275 o Changes based on final WG review. 2277 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-41 2279 o Update to section 6 o RFC 3264: 2281 o https://github.com/cdh4u/draft-sdp-bundle/pull/47 2283 o Editorial clarification on BUNDLE address selection: 2285 o https://github.com/cdh4u/draft-sdp-bundle/pull/46 2287 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40 2289 o Editorial changes and technical restrictions in order to make the 2290 specification more understandable: 2292 o https://github.com/cdh4u/draft-sdp-bundle/pull/45 2294 o - BUNDLE address is only assigned to m- section indicated by 2295 BUNDLE-tag. 2297 o - bundle-only attribute also used in answers and subsequent 2298 offers. 2300 o - Answerer cannot reject, or remove, the bundled m- section that 2301 contains the BUNDLE address. 2303 o - ICE Offer/Answer sections removed, due to duplicated 2304 information. 2306 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39 2308 o Editorial terminology changes. 2310 o RFC 5285 reference replaced by reference to RFC 8285. 2312 o https://github.com/cdh4u/draft-sdp-bundle/pull/44 2314 o - Clarify that an m- section can not be moved between BUNDLE 2315 groups without first moving the m- section out of a BUNDLE group. 2317 o https://github.com/cdh4u/draft-sdp-bundle/pull/41 2319 o - Addition of BUNDLE transport concept. 2321 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38 2322 o Changes to RTP streaming mapping section based on text from Colin 2323 Perkins. 2325 o The following GitHub pull requests were merged: 2327 o https://github.com/cdh4u/draft-sdp-bundle/pull/34 2329 o - Proposed updates to RTP processing 2331 o https://github.com/cdh4u/draft-sdp-bundle/pull/35 2333 o - fixed reference to receiver-id section 2335 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-37 2337 o The following GitHub pull request was merged: 2339 o https://github.com/cdh4u/draft-sdp-bundle/pull/33 2341 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36 2343 o The following GitHub pull requests were merged: 2345 o https://github.com/cdh4u/draft-sdp-bundle/pull/32 2347 o - extmap handling in BUNDLE. 2349 o https://github.com/cdh4u/draft-sdp-bundle/pull/31 2351 o - Additional Acknowledgement text added. 2353 o https://github.com/cdh4u/draft-sdp-bundle/pull/30 2355 o - MID SDES item security procedures updated 2357 o https://github.com/cdh4u/draft-sdp-bundle/pull/29 2359 o - Appendix B of JSEP moved into BUNDLE. 2361 o - Associating RTP/RTCP packets with SDP m- lines. 2363 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35 2365 o Editorial changes on RTP streaming mapping section based on 2366 comments from Colin Perkins. 2368 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34 2369 o RTP streams, instead of RTP packets, are associated with m- lines. 2371 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 2373 o Editorial changes based on comments from Eric Rescorla and Cullen 2374 Jennings: 2376 o - Changes regarding usage of RTP/RTCP multiplexing attributes. 2378 o - Additional text regarding associating RTP/RTCP packets with SDP 2379 m- lines. 2381 o - Reference correction. 2383 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32 2385 o Editorial changes based on comments from Eric Rescorla and Cullen 2386 Jennings: 2388 o - Justification for mechanism added to Introduction. 2390 o - Clarify that the order of m- lines in the group:BUNDLE attribute 2391 does not have to be the same as the order in which the m- lines 2392 are listed in the SDP. 2394 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31 2396 o Editorial changes based on GitHub Pull requests by Martin Thomson: 2398 o - https://github.com/cdh4u/draft-sdp-bundle/pull/2 2400 o - https://github.com/cdh4u/draft-sdp-bundle/pull/1 2402 o Editorial change based on comment from Diederick Huijbers (9th 2403 July 2016). 2405 o Changes based on comments from Flemming Andreasen (21st June 2406 2016): 2408 o - Mux category for SDP bundle-only attribute added. 2410 o - Mux category considerations editorial clarification. 2412 o - Editorial changes. 2414 o RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext. 2416 o Note whether Design Considerations appendix is to be kept removed: 2418 o - Appendix is kept within document. 2420 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30 2422 o Indicating in the Abstract and Introduction that the document 2423 updates RFC 3264. 2425 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29 2427 o Change based on WGLC comment from Colin Perkins. 2429 o - Clarify that SSRC can be reused by another source after a delay 2430 of 5 RTCP reporting intervals. 2432 o Change based on WGLC comment from Alissa Cooper. 2434 o - IANA registry name fix. 2436 o - Additional IANA registration information added. 2438 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28 2440 o - Alignment with exclusive mux procedures. 2442 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 2444 o - Yet another terminology change. 2446 o - Mux category considerations added. 2448 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 2450 o - ICE considerations modified: ICE-related SDP attributes only 2451 added to the bundled m- line representing the selected BUNDLE 2452 address. 2454 o - Reference to draft-ietf-mmusic-ice-sip-sdp added. 2456 o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- 2457 rfc5245bis. 2459 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 2461 o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux 2462 considerations. 2464 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 2465 o - Reference and procedures associated with exclusive RTP/RTCP mux 2466 added 2468 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 2470 o - RTCP-MUX mandatory for bundled RTP m- lines 2472 o - Editorial fixes based on comments from Flemming Andreasen 2474 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 2476 o - Correction of Ari's family name 2478 o - Editorial fixes based on comments from Thomas Stach 2480 o - RTP/RTCP correction based on comment from Magnus Westerlund 2482 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2483 msg14861.html 2485 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 2487 o - Correct based on comment from Paul Kyzivat 2489 o -- 'received packets' replaced with 'received data' 2491 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 2493 o - Clarification based on comment from James Guballa 2495 o - Clarification based on comment from Flemming Andreasen 2497 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 2499 o - DTLS Considerations section added. 2501 o - BUNDLE semantics added to the IANA Considerations 2503 o - Changes based on WGLC comments from Adam Roach 2505 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2506 msg14673.html 2508 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 2510 o - Changes based on agreements at IETF#92 2512 o -- BAS Offer removed, based on agreement at IETF#92. 2514 o -- Procedures regarding usage of SDP "b=" line is replaced with a 2515 reference to to draft-ietf-mmusic-sdp-mux-attributes. 2517 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 2519 o - Editorial changes based on comments from Magnus Westerlund. 2521 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 2523 o - Modification of RTP/RTCP multiplexing section, based on comments 2524 from Magnus Westerlund. 2526 o - Reference updates. 2528 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 2530 o - Editorial fix. 2532 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 2534 o - Editorial changes. 2536 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 2538 o Changes to allow a newly suggested offerer BUNDLE address to be 2539 assigned to each bundled m- line. 2541 o Changes based on WGLC comments from Paul Kyzivat 2543 o - Editorial fixes 2545 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 2547 o Usage of SDP 'extmap' attribute added 2549 o SDP 'bundle-only' attribute scoped with "m=" lines with a zero 2550 port value 2552 o Changes based on WGLC comments from Thomas Stach 2554 o - ICE candidates not assigned to bundle-only m- lines with a zero 2555 port value 2557 o - Editorial changes 2559 o Changes based on WGLC comments from Colin Perkins 2561 o - Editorial changes: 2563 o -- "RTP SDES item" -> "RTCP SDES item" 2565 o -- "RTP MID SDES item" -> "RTCP MID SDES item" 2567 o - Changes in section 10.1.1: 2569 o -- "SHOULD NOT" -> "MUST NOT" 2571 o -- Additional text added to the Note 2573 o - Change to section 13.2: 2575 o -- Clarify that mid value is not zero terminated 2577 o - Change to section 13.3: 2579 o -- Clarify that mid value is not zero terminated 2581 o -- Clarify padding 2583 o Changes based on WGLC comments from Paul Kyzivat 2585 o - Editorial changes: 2587 o Changes based on WGLC comments from Jonathan Lennox 2589 o - Editorial changes: 2591 o - Defintion of SDP bundle-only attribute alligned with structure 2592 in 4566bis draft 2594 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 2596 o Editorial corrections based on comments from Harald Alvestrand. 2598 o Editorial corrections based on comments from Cullen Jennings. 2600 o Reference update (RFC 7160). 2602 o Clarification about RTCP packet sending when RTP/RTCP multiplexing 2603 is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ 2604 msg13765.html). 2606 o Additional text added to the Security Considerations. 2608 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 2610 o SDP bundle-only attribute added to IANA Considerations. 2612 o SDES item and RTP header extension added to Abstract and 2613 Introduction. 2615 o Modification to text updating section 8.2 of RFC 3264. 2617 o Reference corrections. 2619 o Editorial corrections. 2621 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 2623 o Terminology change: "bundle-only attribute assigned to m= line" to 2624 "bundle-only attribute associated with m= line". 2626 o Editorial corrections. 2628 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 2630 o Editorial corrections. 2632 o - "of"->"if" (8.3.2.5). 2634 o - "optional"->"OPTIONAL" (9.1). 2636 o - Syntax/ABNF for 'bundle-only' attribute added. 2638 o - SDP Offer/Answer sections merged. 2640 o - 'Request new offerer BUNDLE address' section added 2642 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 2644 o OPEN ISSUE regarding Receiver-ID closed. 2646 o - RTP MID SDES Item. 2648 o - RTP MID Header Extension. 2650 o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers 2651 closed. 2653 o - Indicating that, when rtcp-mux is used, the answerer MUST NOT 2654 include an 'rtcp' attribute in the answer, based on the procedures 2655 in section 5.1.3 of RFC 5761. 2657 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 2659 o Draft title changed. 2661 o Added "SDP" to section names containing "Offer" or "Answer". 2663 o Editorial fixes based on comments from Paul Kyzivat 2664 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2665 msg13314.html). 2667 o Editorial fixed based on comments from Colin Perkins 2668 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2669 msg13318.html). 2671 o - Removed text about extending BUNDLE to allow multiple RTP 2672 sessions within a BUNDLE group. 2674 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 2676 o Major re-structure of SDP Offer/Answer sections, to align with RFC 2677 3264 structure. 2679 o Additional definitions added. 2681 o - Shared address. 2683 o - Bundled "m=" line. 2685 o - Bundle-only "m=" line. 2687 o - Offerer suggested BUNDLE mid. 2689 o - Answerer selected BUNDLE mid. 2691 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 2692 to multiple "m=" lines until it has received an SDP Answer 2693 indicating support of the BUNDLE extension. 2695 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 2696 Answerer supports the BUNDLE extension, assign a zero port value 2697 to a 'bundle-only' "m=" line. 2699 o SDP 'bundle-only' attribute section added. 2701 o Connection data nettype/addrtype restrictions added. 2703 o RFC 3264 update section added. 2705 o Indicating that a specific payload type value can be used in 2706 multiple "m=" lines, if the value represents the same codec 2707 configuration in each "m=" line. 2709 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 2711 o Updated Offerer procedures (http://www.ietf.org/mail- 2712 archive/web/mmusic/current/msg12293.html). 2714 o Updated Answerer procedures (http://www.ietf.org/mail- 2715 archive/web/mmusic/current/msg12333.html). 2717 o Usage of SDP 'bundle-only' attribute added. 2719 o Reference to Trickle ICE document added. 2721 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 2723 o Mechanism modified, to be based on usage of SDP Offers with both 2724 different and identical port number values, depending on whether 2725 it is known if the remote endpoint supports the extension. 2727 o Cullen Jennings added as co-author. 2729 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 2731 o No changes. New version due to expiration. 2733 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 2735 o No changes. New version due to expiration. 2737 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 2739 o Draft name changed. 2741 o Harald Alvestrand added as co-author. 2743 o "Multiplex" terminology changed to "bundle". 2745 o Added text about single versus multiple RTP Sessions. 2747 o Added reference to RFC 3550. 2749 21. References 2751 21.1. Normative References 2753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2754 Requirement Levels", BCP 14, RFC 2119, 2755 DOI 10.17487/RFC2119, March 1997, . 2758 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2759 with Session Description Protocol (SDP)", RFC 3264, 2760 DOI 10.17487/RFC3264, June 2002, . 2763 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2764 Jacobson, "RTP: A Transport Protocol for Real-Time 2765 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2766 July 2003, . 2768 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2769 in Session Description Protocol (SDP)", RFC 3605, 2770 DOI 10.17487/RFC3605, October 2003, . 2773 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2774 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2775 2003, . 2777 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2778 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2779 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2780 . 2782 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2783 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2784 July 2006, . 2786 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2787 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2788 . 2790 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2791 Control Packets on a Single Port", RFC 5761, 2792 DOI 10.17487/RFC5761, April 2010, . 2795 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2796 Security (DTLS) Extension to Establish Keys for the Secure 2797 Real-time Transport Protocol (SRTP)", RFC 5764, 2798 DOI 10.17487/RFC5764, May 2010, . 2801 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2802 Protocol (SDP) Grouping Framework", RFC 5888, 2803 DOI 10.17487/RFC5888, June 2010, . 2806 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2807 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2808 January 2012, . 2810 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2811 Header Extension for the RTP Control Protocol (RTCP) 2812 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2813 August 2016, . 2815 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2816 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2817 May 2017, . 2819 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 2820 Mechanism for RTP Header Extensions", RFC 8285, 2821 DOI 10.17487/RFC8285, October 2017, . 2824 [I-D.ietf-ice-rfc5245bis] 2825 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2826 Connectivity Establishment (ICE): A Protocol for Network 2827 Address Translator (NAT) Traversal", draft-ietf-ice- 2828 rfc5245bis-20 (work in progress), March 2018. 2830 [I-D.ietf-mmusic-sdp-mux-attributes] 2831 Nandakumar, S., "A Framework for SDP Attributes when 2832 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 2833 (work in progress), December 2016. 2835 [I-D.ietf-mmusic-mux-exclusive] 2836 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 2837 Multiplexing using SDP", draft-ietf-mmusic-mux- 2838 exclusive-12 (work in progress), May 2017. 2840 [I-D.ietf-mmusic-ice-sip-sdp] 2841 Petit-Huguenin, M., Nandakumar, S., and A. Keranen, 2842 "Session Description Protocol (SDP) Offer/Answer 2843 procedures for Interactive Connectivity Establishment 2844 (ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in 2845 progress), April 2018. 2847 [I-D.ietf-mmusic-trickle-ice-sip] 2848 Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 2849 Session Initiation Protocol (SIP) Usage for Trickle ICE", 2850 draft-ietf-mmusic-trickle-ice-sip-14 (work in progress), 2851 February 2018. 2853 21.2. Informative References 2855 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2856 A., Peterson, J., Sparks, R., Handley, M., and E. 2857 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2858 DOI 10.17487/RFC3261, June 2002, . 2861 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2862 "RTP Control Protocol Extended Reports (RTCP XR)", 2863 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2864 . 2866 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2867 "Codec Control Messages in the RTP Audio-Visual Profile 2868 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 2869 February 2008, . 2871 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2872 "Extended RTP Profile for Real-time Transport Control 2873 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2874 DOI 10.17487/RFC4585, July 2006, . 2877 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2878 Media Attributes in the Session Description Protocol 2879 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2880 . 2882 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2883 Clock Rates in an RTP Session", RFC 7160, 2884 DOI 10.17487/RFC7160, April 2014, . 2887 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2888 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2889 . 2891 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2892 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2893 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2894 DOI 10.17487/RFC7656, November 2015, . 2897 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 2898 (Diffserv) and Real-Time Communication", RFC 7657, 2899 DOI 10.17487/RFC7657, November 2015, . 2902 [I-D.ietf-ice-trickle] 2903 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 2904 "Trickle ICE: Incremental Provisioning of Candidates for 2905 the Interactive Connectivity Establishment (ICE) 2906 Protocol", draft-ietf-ice-trickle-21 (work in progress), 2907 April 2018. 2909 [I-D.ietf-avtext-lrr] 2910 Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 2911 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 2912 Message", draft-ietf-avtext-lrr-07 (work in progress), 2913 July 2017. 2915 Appendix A. Design Considerations 2917 One of the main issues regarding the BUNDLE grouping extensions has 2918 been whether, in SDP Offers and SDP Answers, the same port value can 2919 be inserted in "m=" lines associated with a BUNDLE group, as the 2920 purpose of the extension is to negotiate the usage of a single 2921 transport for media specified by the "m=" sections. Issues with both 2922 approaches, discussed in the Appendix have been raised. The outcome 2923 was to specify a mechanism which uses SDP Offers with both different 2924 and identical port values. 2926 Below are the primary issues that have been considered when defining 2927 the "BUNDLE" grouping extension: 2929 o 1) Interoperability with existing UAs. 2931 o 2) Interoperability with intermediary Back to Back User Agent 2932 (B2BUA) and proxy entities. 2934 o 3) Time to gather, and the number of, ICE candidates. 2936 o 4) Different error scenarios, and when they occur. 2938 o 5) SDP Offer/Answer impacts, including usage of port number value 2939 zero. 2941 A.1. UA Interoperability 2943 Consider the following SDP Offer/Answer exchange, where Alice sends 2944 an SDP Offer to Bob: 2946 SDP Offer 2948 v=0 2949 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2950 s= 2951 c=IN IP4 atlanta.example.com 2952 t=0 0 2954 m=audio 10000 RTP/AVP 97 2955 a=rtpmap:97 iLBC/8000 2956 m=video 10002 RTP/AVP 97 2957 a=rtpmap:97 H261/90000 2959 SDP Answer 2961 v=0 2962 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2963 s= 2964 c=IN IP4 biloxi.example.com 2965 t=0 0 2967 m=audio 20000 RTP/AVP 97 2968 a=rtpmap:97 iLBC/8000 2969 m=video 20002 RTP/AVP 97 2970 a=rtpmap:97 H261/90000 2972 RFC 4961 specifies a way of doing symmetric RTP but that is a later 2973 extension to RTP and Bob can not assume that Alice supports RFC 4961. 2974 This means that Alice may be sending RTP from a different port than 2975 10000 or 10002 - some implementations simply send the RTP from an 2976 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2977 way that Bob knows if the packet is to be passed to the video or 2978 audio codec is by looking at the port it was received on. This led 2979 some SDP implementations to use the fact that each "m=" section had a 2980 different port number to use that port number as an index to find the 2981 correct m line in the SDP. As a result, some implementations that do 2982 support symmetric RTP and ICE still use an SDP data structure where 2983 SDP with "m=" sections with the same port such as: 2985 SDP Offer 2987 v=0 2988 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2989 s= 2990 c=IN IP4 atlanta.example.com 2991 t=0 0 2993 m=audio 10000 RTP/AVP 97 2994 a=rtpmap:97 iLBC/8000 2995 m=video 10000 RTP/AVP 98 2996 a=rtpmap:98 H261/90000 2998 will result in the second "m=" section being considered an SDP error 2999 because it has the same port as the first line. 3001 A.2. Usage of Port Number Value Zero 3003 In an SDP Offer or SDP Answer, the media specified by an "m=" section 3004 can be disabled/rejected by setting the port number value to zero. 3005 This is different from e.g., using the SDP direction attributes, 3006 where RTCP traffic will continue even if the SDP "inactive" attribute 3007 is indicated for the associated "m=" section. 3009 If each "m=" section associated with a BUNDLE group would contain 3010 different port values, and one of those port values would be used for 3011 a BUNDLE address:port associated with the BUNDLE group, problems 3012 would occur if an endpoint wants to disable/reject the "m=" section 3013 associated with that port, by setting the port value to zero. After 3014 that, no "m=" section would contain the port value which is used for 3015 the BUNDLE address:port. In addition, it is unclear what would 3016 happen to the ICE candidates associated with the "m=" section, as 3017 they are also used for the BUNDLE address:port. 3019 A.3. B2BUA And Proxy Interoperability 3021 Some back to back user agents may be configured in a mode where if 3022 the incoming call leg contains an SDP attribute the B2BUA does not 3023 understand, the B2BUA still generates that SDP attribute in the Offer 3024 for the outgoing call leg. Consider a B2BUA that did not understand 3025 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 3026 Further assume that the B2BUA was configured to tear down any call 3027 where it did not see any RTCP for 5 minutes. In this case, if the 3028 B2BUA received an Offer like: 3030 SDP Offer 3032 v=0 3033 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 3034 s= 3035 c=IN IP4 atlanta.example.com 3036 t=0 0 3038 m=audio 49170 RTP/AVP 0 3039 a=rtcp:53020 3041 It would be looking for RTCP on port 49171 but would not see any 3042 because the RTCP would be on port 53020 and after five minutes, it 3043 would tear down the call. Similarly, a B2BUA that did not understand 3044 BUNDLE yet put BUNDLE in its offer may be looking for media on the 3045 wrong port and tear down the call. It is worth noting that a B2BUA 3046 that generated an Offer with capabilities it does not understand is 3047 not compliant with the specifications. 3049 A.3.1. Traffic Policing 3051 Sometimes intermediaries do not act as B2BUAs, in the sense that they 3052 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 3053 however, they may use SDP information (e.g., IP address and port) in 3054 order to control traffic gating functions, and to set traffic 3055 policing rules. There might be rules which will trigger a session to 3056 be terminated in case media is not sent or received on the ports 3057 retrieved from the SDP. This typically occurs once the session is 3058 already established and ongoing. 3060 A.3.2. Bandwidth Allocation 3062 Sometimes intermediaries do not act as B2BUAs, in the sense that they 3063 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 3064 however, they may use SDP information (e.g., codecs and media types) 3065 in order to control bandwidth allocation functions. The bandwidth 3066 allocation is done per "m=" section, which means that it might not be 3067 enough if media specified by all "m=" sections try to use that 3068 bandwidth. That may either simply lead to bad user experience, or to 3069 termination of the call. 3071 A.4. Candidate Gathering 3073 When using ICE, a candidate needs to be gathered for each port. This 3074 takes approximately 20 ms extra for each extra "m=" section due to 3075 the NAT pacing requirements. All of this gathering can be overlapped 3076 with other things while e.g., a web-page is loading to minimize the 3077 impact. If the client only wants to generate TURN or STUN ICE 3078 candidates for one of the "m=" lines and then use trickle ICE 3079 [I-D.ietf-ice-trickle] to get the non host ICE candidates for the 3080 rest of the "m=" sections, it MAY do that and will not need any 3081 additional gathering time. 3083 Some people have suggested a TURN extension to get a bunch of TURN 3084 allocations at once. This would only provide a single STUN result so 3085 in cases where the other end did not support BUNDLE, it may cause 3086 more use of the TURN server but would be quick in the cases where 3087 both sides supported BUNDLE and would fall back to a successful call 3088 in the other cases. 3090 Authors' Addresses 3092 Christer Holmberg 3093 Ericsson 3094 Hirsalantie 11 3095 Jorvas 02420 3096 Finland 3098 Email: christer.holmberg@ericsson.com 3100 Harald Tveit Alvestrand 3101 Google 3102 Kungsbron 2 3103 Stockholm 11122 3104 Sweden 3106 Email: harald@alvestrand.no 3108 Cullen Jennings 3109 Cisco 3110 400 3rd Avenue SW, Suite 350 3111 Calgary, AB T2P 4H2 3112 Canada 3114 Email: fluffy@iii.ca