idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-48.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7941, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3264, updated by this document, for RFC5378 checks: 2002-01-31) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 31, 2018) is 2277 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 1587 == Missing Reference: 'RFCXXXX' is mentioned on line 1771, 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 (-20) exists of draft-ietf-ice-rfc5245bis-16 == 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-16 == Outdated reference: A later version (-21) exists of draft-ietf-ice-trickle-15 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 4 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: August 4, 2018 C. Jennings 7 Cisco 8 January 31, 2018 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-48.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 without meaning that the media described by 27 the "m=" section is 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 van be 31 used to correlate bundled RTP/RTCP packets with their appropriate 32 "m=" section. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 4, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 83 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7 84 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 8 85 7. SDP Information Considerations . . . . . . . . . . . . . . . 9 86 7.1. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9 87 7.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9 88 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9 89 8.1. Multiplex Category Considerations . . . . . . . . . . . . 10 90 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 11 91 8.2.1. Suggesting the Offerer BUNDLE Address:Port . . . . . 11 92 8.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 12 93 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 13 94 8.3.1. Answerer Selection of Offerer BUNDLE Address:Port . . 14 95 8.3.2. Answerer Selection of Answerer BUNDLE Address:Port . 14 96 8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 15 97 8.3.4. Rejecting a Media Description in a BUNDLE Group . . . 15 98 8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 16 99 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 17 100 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 17 101 8.5.1. Suggesting a New Offerer BUNDLE Address:Port . . . . 18 102 8.5.2. Adding a Media Description to a BUNDLE group . . . . 18 103 8.5.3. Moving a Media Description Out of a BUNDLE Group . . 19 104 8.5.4. Disabling a Media Description in a BUNDLE Group . . . 19 105 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 20 106 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 20 107 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 21 108 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 21 109 10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 21 110 10.2. Associating RTP/RTCP Streams with Correct SDP Media 111 Description . . . . . . . . . . . . . . . . . . . . . . 22 112 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 27 113 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 28 114 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 30 115 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 31 116 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 32 117 13. RTP Header Extensions Consideration . . . . . . . . . . . . . 32 118 14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 33 119 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 33 120 14.2. New text replacing section 5.1 (2nd paragraph) of RFC 121 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 122 14.3. Original text of section 6 (4th paragraph) of RFC 3264 . 34 123 14.4. New text replacing section 6 (4th paragraph) of RFC 3264 34 124 14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 34 125 14.6. New text replacing section 8.4 (6th paragraph) of RFC 126 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 127 15. RTP/RTCP extensions for identification-tag transport . . . . 35 128 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 36 129 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 36 130 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 131 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 37 132 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 37 133 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 38 134 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 38 135 17. Security Considerations . . . . . . . . . . . . . . . . . . . 39 136 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40 137 18.1. Example: BUNDLE Address:Port Selection . . . . . . . . . 40 138 18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 42 139 18.3. Example: Offerer Adds a Media Description to a BUNDLE 140 Group . . . . . . . . . . . . . . . . . . . . . . . . . 43 141 18.4. Example: Offerer Moves a Media Description Out of a 142 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 45 143 18.5. Example: Offerer Disables a Media Description Within a 144 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 47 145 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 146 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 49 147 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 148 21.1. Normative References . . . . . . . . . . . . . . . . . . 60 149 21.2. Informative References . . . . . . . . . . . . . . . . . 61 150 Appendix A. Design Considerations . . . . . . . . . . . . . . . 63 151 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 63 152 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 65 153 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 65 154 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 66 155 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 66 156 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 66 157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 159 1. Introduction 161 When the SDP offer/answer mechanism [RFC3264] is used to negotiate 162 the establishment of multimedia communication sessions, if separate 163 transports (5-tuples) are negotiated for each individual media 164 stream, each transport consumes additional resources (especially when 165 Interactive Connectivity Establishment (ICE) 166 [I-D.ietf-ice-rfc5245bis] is used). For this reason, it is 167 attractive to use a single transport for multiple media streams. 169 This specification defines a way to use a single transport (BUNDLE 170 transport) for sending and receiving media (bundled media) described 171 by multiple SDP media descriptions ("m=" sections). The same BUNDLE 172 transport is used for sending and receiving bundled media, which 173 means that the symmetric Real-time Transport Protocol (RTP) mechanism 174 [RFC4961] is always used for RTP-based bundled media. 176 This specification defines a new SDP Grouping Framework [RFC5888] 177 extension called 'BUNDLE'. The extension can be used with the 178 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 179 to negotiate which "m=" sections will become part of a BUNDLE group. 180 Within a BUNDLE group, each "m=" section will use a BUNDLE transport 181 for sending and receiving bundled media. 183 Within a BUNDLE group, each endpoint uses a single address:port 184 combination for sending and receiving bundled media. The 185 address:port combination is referred to as the BUNDLE address:port. 186 In addition to negotiating the BUNDLE group, the offerer and answerer 187 [RFC3264] use the BUNDLE extension to negotiate the BUNDLE 188 addresses:ports, one for the offerer (offerer BUNDLE address) and one 189 for the answerer (answerer BUNDLE address:port). Once the offerer 190 and the answerer have negotiated the BUNDLE addresses:ports, and a 191 BUNDLE group has been formed, they assign their respective BUNDLE 192 address:port to each "m=" section within the BUNDLE group. The 193 endpoints then use the BUNDLE addresses:ports for sending and 194 receiving the bundled media associated with the BUNDLE group. 196 The use of a BUNDLE transport allows the usage of a single set of 197 Interactive Connectivity Establishment (ICE) 198 [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group. 200 This specification defines a new SDP attribute, 'bundle-only', which 201 can be used to request that specific media is only used if the "m=" 202 section describing the media is kept within a BUNDLE group. 204 This specification updates RFC 3264 [RFC3264], to allow assigning a 205 zero port value to a "m=" section without meaning that the media 206 described by the "m=" section is disabled or rejected. 208 As defined in RFC 4566 [RFC4566], the semantics of assigning the same 209 transport address (IP address and port) to multiple "m=" sections are 210 undefined, and there is no grouping defined by such means. Instead, 211 an explicit grouping mechanism needs to be used to express the 212 intended semantics. This specification provides such an extension. 214 This specification defines a new RTP Control Protocol (RTCP) 215 [RFC3550] source description (SDES) item, 'MID', and a new RTP SDES 216 header extension that can be used to associate RTP streams with "m=" 217 sections. 219 A given BUNDLE address:port MUST only be associated with a single 220 BUNDLE group. If an SDP offer or answer contains multiple BUNDLE 221 groups, the procedures in this specification apply to each group 222 independently. All RTP based media flows described by a single 223 BUNDLE group belong to a single RTP session [RFC3550]. 225 The BUNDLE extension is backward compatible. Endpoints that do not 226 support the extension are expected to generate offers and answers 227 without an SDP 'group:BUNDLE' attribute, and are expected to assign a 228 unique address to each "m=" section within an offer and answer, 229 according to the procedures in [RFC4566] and [RFC3264]. 231 2. Terminology 233 "m=" section: SDP bodies contain one or more media descriptions, 234 referred to as "m=" sections. Each "m=" section is represented by an 235 SDP "m=" line, and zero or more SDP attributes associated with the 236 "m=" line. A local address:port combination is assigned to each "m=" 237 section. 239 o 5-tuple: A collection of the following values: source address, 240 source port, destination address, destination port, and transport- 241 layer protocol. 243 o Unique address: An address:port combination that is assigned to 244 only one "m=" section in an offer or answer. 246 o Offerer BUNDLE-tag: The first identification-tag in a given SDP 247 'group:BUNDLE' attribute identification-tag list in an offer. 249 o Answerer BUNDLE-tag: The first identification-tag in a given SDP 250 'group:BUNDLE' attribute identification-tag list in an answer. 252 o BUNDLE address:port: An address:port combination that an endpoint 253 uses for sending and receiving bundled media. 255 o Offerer BUNDLE address:port: the address:port combination used by 256 the offerer for sending and receiving media. 258 o Suggested Offerer BUNDLE address:port: before an offerer BUNDLE 259 address:port has been selected by the answerer, or when the 260 offerer wants to change a previously selected offerer BUNDLE 261 address:port, the address:port combination that the offerer wants 262 to use for sending and receiving media. While suggested by the 263 offerer, the selection of the offerer BUNDLE address:port is done 264 by the answerer. 266 o Answerer BUNDLE address:port: the address:port combination used by 267 the answerer for sending and receiving media. 269 o BUNDLE transport: The transport (5-tuple) used by all media 270 described by the "m=" sections within a BUNDLE group. 272 o BUNDLE group: A set of "m=" sections, created using an SDP Offer/ 273 Answer exchange, which uses a single BUNDLE transport for sending 274 and receiving all media (bundled media) described by the set of 275 "m=" sections. The same BUNDLE transport is used for sending and 276 receiving bundled media. 278 o Bundled "m=" section: An "m=" section, whose identification-tag is 279 placed in an SDP 'group:BUNDLE' attribute identification-tag list 280 in an offer or answer. 282 o Bundle-only "m=" section: A bundled "m=" section that contains an 283 SDP 'bundle-only' attribute. 285 o Bundled media: All media associated with a given BUNDLE group. 287 o Initial offer: The first offer, within an SDP session (e.g. a SIP 288 dialog when the Session Initiation Protocol (SIP) [RFC3261] is 289 used to carry SDP), in which the offerer indicates that it wants 290 to create a given BUNDLE group. 292 o Subsequent offer: An offer which contains a BUNDLE group that has 293 been created as part of a previous offer/answer exchange. 295 o Identification-tag: A unique token value that is used to identify 296 an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" 297 section carries the unique identification-tag assigned to that 298 "m=" section. The session-level SDP 'group' attribute [RFC5888] 299 carries a list of identification-tags, identifying the "m=" 300 sections associated with that particular 'group' attribute. 302 3. Conventions 304 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 305 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 306 document are to be interpreted as described in BCP 14, RFC 2119 307 [RFC2119]. 309 4. Applicability Statement 311 The mechanism in this specification only applies to the Session 312 Description Protocol (SDP) [RFC4566], when used together with the SDP 313 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 314 scope of this document, and is thus undefined. 316 5. SDP Grouping Framework BUNDLE Extension 318 This section defines a new SDP Grouping Framework [RFC5888] 319 extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP 320 Offer/Answer mechanism to negotiate a set of "m=" sections that will 321 become part of a BUNDLE group. Within a BUNDLE group, each "m=" 322 section uses a BUNDLE transport for sending and receiving bundled 323 media. Each endpoint uses a single address:port combination for 324 sending and receiving the bundled media. 326 The BUNDLE extension is indicated using an SDP 'group' attribute with 327 a semantics value [RFC5888] of "BUNDLE". An identification-tag is 328 assigned to each bundled "m=" section, and each identification-tag is 329 listed in the SDP 'group:BUNDLE' attribute identification-tag list. 330 Each "m=" section whose identification-tag is listed in the 331 identification-tag list is associated with a given BUNDLE group. 333 SDP bodies can contain multiple BUNDLE groups. Any given bundled 334 "m=" section MUST NOT be associated with more than one BUNDLE group 335 at any given time. 337 NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' 338 attribute identification-tag list does not have to be the same as the 339 order in which the "m=" sections occur in the SDP. 341 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 342 'group:BUNDLE' attribute is 'NORMAL'. 344 Section 8 defines the detailed SDP Offer/Answer procedures for the 345 BUNDLE extension. 347 6. SDP 'bundle-only' Attribute 349 This section defines a new SDP media-level attribute [RFC4566], 350 'bundle-only'. 'bundle-only' is a property attribute [RFC4566], and 351 hence has no value. 353 Name: bundle-only 355 Value: N/A 357 Usage Level: media 359 Charset Dependent: no 361 Example: 363 a=bundle-only 365 In order to ensure that an answerer that does not support the BUNDLE 366 extension always rejects a bundled "m=" section, the offerer can 367 assign a zero port value to the "m=" section. According to [RFC3264] 368 an answerer will reject such an "m=" section. By including an SDP 369 'bundle-only' attribute in such an "m=" section, the offerer can 370 request that the answerer accepts the "m=" section if the answerer 371 supports the BUNDLE extension, and if the answerer keeps the "m=" 372 section within the associated BUNDLE group. 374 Once the offerer and answerer BUNDLE addresses:ports have been 375 selected, an offerer and answerer only assign the BUNDLE address:port 376 to one bundled "m=" section. The offerer and answerer assign a zero 377 port value and includes an SDP 'bundle-only' attribute to every other 378 bundled "m=" section. 380 The usage of the 'bundle-only' attribute is only defined for a 381 bundled "m=" section with a zero port value. Other usage is 382 unspecified. 384 Section 8 defines the detailed SDP Offer/Answer procedures for the 385 'bundle-only' attribute. 387 7. SDP Information Considerations 389 This section describes restrictions associated with the usage of SDP 390 parameters within a BUNDLE group. It also describes how to calculate 391 a value for the whole BUNDLE group, when parameter and attribute 392 values have been assigned to each bundled "m=" section. 394 7.1. Connection Data (c=) 396 The "c=" line nettype value [RFC4566] associated with a bundled "m=" 397 section MUST be 'IN'. 399 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" 400 section MUST be 'IP4' or 'IP6'. The same value MUST be associated 401 with each "m=" section. 403 NOTE: Extensions to this specification can specify usage of the 404 BUNDLE mechanism for other nettype and addrtype values than the ones 405 listed above. 407 7.2. Bandwidth (b=) 409 An offerer and answerer MUST use the rules and restrictions defined 410 in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP 411 bandwidth (b=) line with bundled "m=" sections. 413 8. SDP Offer/Answer Procedures 415 This section describes the SDP Offer/Answer [RFC3264] procedures for: 417 o Negotiating a BUNDLE group; and 419 o Selecting the BUNDLE addresses:ports (offerer BUNDLE address:port 420 and answerer BUNDLE address:port); and 422 o Adding an "m=" section to a BUNDLE group; and 424 o Moving an "m=" section out of a BUNDLE group; and 426 o Disabling an "m=" section within a BUNDLE group. 428 The generic rules and procedures defined in [RFC3264] and [RFC5888] 429 also apply to the BUNDLE extension. For example, if an offer is 430 rejected by the answerer, the previously negotiated SDP parameters 431 and characteristics (including those associated with a BUNDLE group) 432 apply. Hence, if an offerer generates an offer in which the offerer 433 wants to create a BUNDLE group, and the answerer rejects the offer, 434 the BUNDLE group is not created. 436 The procedures in this section are independent of the media type or 437 "m=" line proto value assigned to a bundled "m=" section. Section 10 438 defines additional considerations for RTP based media. Section 6 439 defines additional considerations for the usage of the SDP 'bundle- 440 only' attribute. Section 11 defines additional considerations for 441 the usage of Interactive Connectivity Establishment (ICE) 442 [I-D.ietf-ice-rfc5245bis] mechanism. 444 SDP offers and answers can contain multiple BUNDLE groups. The 445 procedures in this section apply independently to a given BUNDLE 446 group. 448 8.1. Multiplex Category Considerations 450 When a BUNDLE group is initially negotiated, and a unique address is 451 assigned to each bundled "m=" section (excluding any bundle-only "m=" 452 section) in the initial offer [Section 8.2], any IDENTICAL and 453 TRANSPORT mux category SDP attributes included in the BUNDLE group 454 MUST explicitly be included in each bundled "m=a€œ section 455 (excluding any bundle-only "m=" sections). 457 When an offerer or answerer includes SDP attributes in bundled "m=" 458 sections within a BUNDLE group for which the offerer and answerer 459 BUNDLE addresses:ports have been selected, IDENTICAL and TRANSPORT 460 mux category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are 461 only included in the "m=" section indicated by the BUNDLE-tag in the 462 offer or answer. The SDP attribute values are implicitly applied to 463 each bundled "m=" section (including any bundle-only "m=" section). 464 The offerer and answerer MUST NOT include such SDP attributes in any 465 other bundled "m=" section. 467 The semantics of some SDP attributes only apply to specific types of 468 media. For example, the semantics of the SDP 'rtcp-mux' and SDP 469 'rtcp-mux-only' attributes only apply to "m=" sections describing 470 RTP-based media. However, as described in Section 8.1, there are 471 cases where IDENTICAL and TRANSPORT mux category SDP attributes are 472 only included in the "m=" sections indicated by the BUNDLE-tag. That 473 means that media-specific IDENTICAL and TRANSPORT mux category 474 attributes can be included in an "m=" section associated with another 475 type of media. 477 8.2. Generating the Initial SDP Offer 479 When an offerer generates an initial offer, to negotiate a BUNDLE 480 group, it MUST: 482 o Assign a unique address to each "m=" section within the offer, 483 following the procedures in [RFC3264], excluding any bundle-only 484 "m=" sections (see below); and 486 o Include an SDP 'group:BUNDLE' attribute in the offer; and 488 o Place the identification-tag of each bundled "m=" section in the 489 SDP 'group:BUNDLE' attribute identification-tag list; and 491 o Indicate which unique address the offerer suggests as the offerer 492 BUNDLE address:port [Section 8.2.1]. 494 If the offerer wants to request that the answerer accepts a given 495 bundled "m=" section only if the answerer keeps the "m=" section 496 within the BUNDLE group, the offerer MUST: 498 o Include an SDP 'bundle-only' attribute [Section 8.2.1] in the "m=" 499 section; and 501 o Assign a zero port value to the "m=" section. 503 NOTE: If the offerer assigns a zero port value to an "m=" section, 504 but does not include an SDP 'bundle-only' attribute in the "m=" 505 section, it is an indication that the offerer wants to disable the 506 "m=" section [Section 8.5.4]. 508 NOTE: If the offerer assigns unique addresses to multiple bundled 509 "m=" sections, the offerer needs to be prepared to receive bundled 510 media on each unique address, until it receives the associated answer 511 and finds out which address:port combination has been selected as the 512 offerer BUNDLE-address. 514 [Section 8.2.2] and [Section 18.1] show an example of an initial 515 offer. 517 8.2.1. Suggesting the Offerer BUNDLE Address:Port 519 In the offer, the address:port combination assigned to the "m=" 520 section indicated by the offerer BUNDLE-tag indicates the offerer 521 BUNDLE address:port, i.e., the address:port combination that the 522 offerer suggests for sending and receiving bundled media. 524 The offerer BUNDLE-tag MUST NOT represent a bundle-only "m=" section. 525 Hence, the offer MUST contain at least one bundled "m=" section with 526 a unique address (and a non-zero port value). 528 It is RECOMMENDED that the offerer assigns the suggested offerer 529 BUNDLE address:port to a bundled "m=" section that the offerer 530 assumes it is unlikely that the answerer will reject, or move out of 531 the BUNDLE group. How such assumption is made is outside the scope 532 of this document. 534 8.2.2. Example: Initial SDP Offer 536 The example shows an initial SDP offer. The offer includes two "m=" 537 sections in the SDP, and suggests that both are included in a BUNDLE 538 group. The audio "m=" section is indicated by the offerer BUNDLE-tag 539 (placed first in the SDP group:BUNDLE attribute identification-id 540 list). 542 SDP Offer 544 v=0 545 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 546 s= 547 c=IN IP6 2001:db8::3 548 t=0 0 549 a=group:BUNDLE foo bar 550 m=audio 10000 RTP/AVP 0 8 97 551 b=AS:200 552 a=mid:foo 553 a=rtcp-mux 554 a=rtpmap:0 PCMU/8000 555 a=rtpmap:8 PCMA/8000 556 a=rtpmap:97 iLBC/8000 557 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 558 m=video 10002 RTP/AVP 31 32 559 b=AS:1000 560 a=mid:bar 561 a=rtcp-mux 562 a=rtpmap:31 H261/90000 563 a=rtpmap:32 MPV/90000 564 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 566 8.3. Generating the SDP Answer 568 When an answerer generates an answer that contains a BUNDLE group, 569 the following general SDP grouping framework restrictions, defined in 570 [RFC5888], also apply to the BUNDLE group: 572 o The answerer MUST NOT include a BUNDLE group in the answer, unless 573 the offerer requested the BUNDLE group to be negotiated in the 574 corresponding offer; and 576 o The answerer MUST NOT include an "m=" section within a BUNDLE 577 group, unless the offerer requested the "m=" section to be within 578 that BUNDLE group in the corresponding offer. 580 o If the answer contains multiple BUNDLE groups, the answerer MUST 581 NOT move an "m=" section from one BUNDLE group to another. 583 If the answer contains a BUNDLE group, the answerer MUST: 585 o Select an offerer BUNDLE address:port [Section 8.3.1]; and 587 o Select an answerer BUNDLE address:port [Section 8.3.2]. 589 The answerer is allowed to select a new answerer BUNDLE address:port 590 each time it generates an answer to an offer. 592 If the answerer does not want to keep an "m=" section within a BUNDLE 593 group, it MUST: 595 o Move the "m=" section out of the BUNDLE group [Section 8.3.3]; or 597 o Reject the "m=" section [Section 8.3.4]. 599 When the answerer creates the answer, it selects the offerer BUNDLE 600 address:port [Section 8.3.1] and the answerer BUNDLE address:port 601 [Section 8.3.2]. The answerer then assigns the answerer BUNDLE 602 address:port to the bundled "m=" section indicated by the answerer 603 BUNDLE-tag. In every other bundled "m=" section the answerer 604 includes an SDP 'bundle-only' attribute and assigns a zero port value 605 to the "m=" section. 607 If the answerer does not want to keep a bundle-only "m=" section 608 within the BUNDLE group, it MUST reject the "m=" section 609 [Section 8.3.4]. 611 NOTE: If a bundled "m=" section in an offer contains a zero port 612 value, but the "m=" section does not contain an SDP 'bundle-only' 613 attribute, it is an indication that the offerer wants to disable the 614 "m=" section [Section 8.5.4]. 616 8.3.1. Answerer Selection of Offerer BUNDLE Address:Port 618 In an offer, the bundled "m=" section indicated by the offerer 619 BUNDLE-tag contains the suggested offerer BUNDLE address:port, i.e, 620 the address:port combination that the offerer wants to use for 621 sending and receiving bundled media [Section 8.2.1]. The answerer 622 MUST check whether that "m=" section fulfils the following criteria: 624 o The answerer will not move the "m=" section out of the BUNDLE 625 group [Section 8.3.3]; and 627 o The answerer will not reject the "m=" section [Section 8.3.4]; and 629 o The "m=" section does not contain a zero port value. 631 If all of the criteria above are fulfilled, the answerer MUST select 632 the suggested offerer BUNDLE address:port. 634 If one or more of the criteria are not fulfilled, the answerer MUST 635 pick the next identification-tag in the identification-tag list in 636 the offer, and perform the same criteria check for the "m=" section 637 indicated by that identification-tag. If there are no more 638 identification-tags in the identification-tag list, the answerer MUST 639 NOT create the BUNDLE group. Unless the answerer rejects the whole 640 offer, the answerer MUST apply the answerer procedures for moving an 641 "m=" section out of a BUNDLE group [Section 8.3.3] or rejecting an 642 "m=" section within a BUNDLE group [Section 8.3.4] to every bundled 643 "m=" section in the offer when creating the answer. 645 [Section 18.1] shows an example of an offerer BUNDLE address:port 646 selection. 648 8.3.2. Answerer Selection of Answerer BUNDLE Address:Port 650 When the answerer selects a BUNDLE address:port for itself (answerer 651 BUNDLE address:port), the answerer MUST assign the answerer BUNDLE 652 address:port to the "m=" section that contains the selected offerer 653 BUNDLE address:port in the corresponding offer. The answerer BUNDLE- 654 tag represents that "m=" section in the answer. To every other 655 bundled "m=" section the answerer MUST assign a zero port value and 656 include an SDP 'bundle-only' attribute. 658 The answerer MUST NOT assign an answerer BUNDLE address:port to an 659 "m=" section that is not within the BUNDLE group, or to an "m=" 660 section that is within another BUNDLE group. 662 [Section 8.3.5] and [Section 18.1] show an example of an answerer 663 BUNDLE address:port selection. 665 8.3.3. Moving A Media Description Out Of A BUNDLE Group 667 When an answerer wants to move a bundled "m=" section out of a BUNDLE 668 group in an answer, it MUST first check the following criteria: 670 o In the corresponding offer, an offerer BUNDLE address:port 671 (previously selected [Section 8.3.1] or newly suggested 672 [Section 8.5.1]) has been assigned to the "m=" section by the 673 offerer; or 675 o In the corresponding offer, the "m=" section contains an SDP 676 'bundle-only' attribute and a zero port value. 678 If either criteria above is fulfilled, the answerer can not move the 679 "m=" section out of the BUNDLE group in the answer. The answerer can 680 either reject the whole offer, reject each bundled "m=" section 681 within the BUNDLE group [Section 8.3.4], or keep the "m=" section 682 within the BUNDLE group in the answer and later create an offer where 683 the "m=" section is moved out of the BUNDLE group [Section 8.5.3]. 685 When the answerer generates an answer, in which it moves a bundled 686 "m=" section out of a BUNDLE group, the answerer: 688 o MUST assign a unique address to the "m=" section; and 690 o MUST NOT place the identification-tag associated with the "m=" 691 section in the SDP 'group:BUNDLE' attribute identification-tag 692 list associated with the BUNDLE group; and 694 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 695 section. 697 An answerer MUST NOT move an "m=" section from one BUNDLE group to 698 another within an answer. If the answerer wants to move an "m=" 699 section from one BUNDLE group to another it MUST first move the "m=" 700 section out of the current BUNDLE group, and then generate an offer 701 where the "m=" section is added to another BUNDLE group 702 [Section 8.5.2]. 704 8.3.4. Rejecting a Media Description in a BUNDLE Group 706 When an answerer wants to reject a bundled "m=" section in an answer, 707 it MUST first check the following criteria: 709 o In the corresponding offer, an offerer BUNDLE address:port 710 (previously selected [Section 8.3.1] or newly suggested 711 [Section 8.5.1]) has been assigned to the "m=" section by the 712 offerer. 714 If the criteria above is fulfilled, the answerer can not reject the 715 "m=" section in the answer (unless the answerer rejects each bundled 716 "m=" section within the BUNDLE group). The answerer can either 717 reject the whole offer, reject each bundled "m=" section within the 718 BUNDLE group, or keep the "m=" section within the BUNDLE group in the 719 answer and later create an offer where the "m=" section is disabled 720 within the BUNDLE group [Section 8.5.4]. 722 When an answerer generates an answer, in which it rejects a bundled 723 "m=" section, the answerer: 725 o MUST assign a zero port value to the "m=" section, according to 726 the procedures in [RFC3264]; and 728 o MUST NOT place the identification-tag associated with the "m=" 729 section in the SDP 'group:BUNDLE' attribute identification-tag 730 list associated with the BUNDLE group; and 732 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 733 section. 735 8.3.5. Example: SDP Answer 737 The example below shows an SDP answer, based on the SDP offer in 738 [Section 8.2.2]. The answerer accepts both "m=" sections within the 739 BUNDLE group. The answerer assigns the answerer BUNDLE address:port 740 to the "m=" section indicated by the answerer BUNDLE-tag. The 741 answerer assigns a zero port value and an SDP 'bundle-only' attribute 742 to the other bundled "m=" section. 744 SDP Answer 746 v=0 747 o=bob 2808844564 2808844564 IN IP6 2001:db8::3 748 s= 749 c=IN IP6 2001:db8::3 750 t=0 0 751 a=group:BUNDLE foo bar 752 m=audio 20000 RTP/AVP 0 753 b=AS:200 754 a=mid:foo 755 a=rtcp-mux 756 a=rtpmap:0 PCMU/8000 757 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 758 m=video 0 RTP/AVP 32 759 b=AS:1000 760 a=mid:bar 761 a=bundle-only 762 a=rtpmap:32 MPV/90000 763 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 765 8.4. Offerer Processing of the SDP Answer 767 When an offerer receives an answer, if the answer contains a BUNDLE 768 group, the offerer MUST check that any bundled "m=" section in the 769 answer was indicated as bundled in the corresponding offer. If there 770 is no mismatch, the offerer MUST use the offerer BUNDLE address:port, 771 selected by the answerer [Section 8.3.1], as the address for each 772 bundled "m=" section. 774 NOTE: As the answerer might reject one or more bundled "m=" sections, 775 or move a bundled "m=" section out of a BUNDLE group, each bundled 776 "m=" section in the offer might not be indicated as bundled in the 777 answer. 779 If the answer does not contain a BUNDLE group, the offerer MUST 780 process the answer as a normal answer. 782 8.5. Modifying the Session 784 When an offerer generates a subsequent offer (i.e., a BUNDLE group 785 has previously been negotiated), it MUST assign the previously 786 selected offerer BUNDLE address:port [Section 8.3.1], or a newly 787 suggested offerer BUNDLE address:port [Section 8.5.1], to exactly one 788 "m=" section within the BUNDLE group. 790 The offerer MUST NOT assign an offerer BUNDLE address:port 791 (previously selected [Section 8.3.1] or newly suggested 792 [Section 8.5.1]) to a bundled "m=" section if: 794 o The offerer wants to move the bundled "m=" section out of the 795 BUNDLE group [Section 8.5.3]; or 797 o The offerer wants to disable the bundled "m=" section 798 [Section 8.5.4]. 800 To every other "m=" section within the BUNDLE group, the offerer MUST 801 assign a zero port value and an SDP 'bundle-only' attribute. 803 When the offerer generates a subsequent offer, the offerer BUNDLE-tag 804 MUST represent the bundled "m=" section to which the offerer BUNDLE 805 address:port (previously negotiated or newly suggested) has been 806 assigned. 808 8.5.1. Suggesting a New Offerer BUNDLE Address:Port 810 When an offerer generates an offer, in which it suggests a new 811 offerer BUNDLE address:port [Section 8.2.1], the offerer MUST: 813 o Assign the newly suggested offerer BUNDLE address:port to exactly 814 one "m=" section within the BUNDLE group; and 816 o Assign a zero port value and an SDP 'bundle-only' attribute to 817 every other "m=" section within the BUNDLE group. 819 8.5.2. Adding a Media Description to a BUNDLE group 821 When an offerer generates an offer, in which it wants to add a new 822 bundled "m=" section, the offerer MUST: 824 o Assign the offerer BUNDLE address:port (previously selected 825 [Section 8.3.1] or newly suggested [Section 8.5.1]) to the added 826 "m=" section; or 828 o Assign a zero port value and an SDP 'bundle-only' attribute to the 829 added "m=" section (in this case the offerer BUNDLE address:port 830 is assigned to another "m=" section within the BUNDLE group). 832 In addition, the offerer MUST place the identification-tag associated 833 with the added "m=" section in the SDP 'group:BUNDLE' attribute 834 identification-tag list associated with the BUNDLE group 835 [Section 8.2.1]. 837 NOTE: If the offerer also wants to suggest a new offerer BUNDLE 838 address:port to the BUNDLE group, the offerer can assign the newly 839 suggested offerer BUNDLE address:port either to the added "m=" 840 section, or to some other "m=" section within the BUNDLE group 841 [Section 8.5.1]. 843 [Section 18.3] shows an example where an offerer sends an offer in 844 order to add a bundled "m=" section to a BUNDLE group. 846 8.5.3. Moving a Media Description Out of a BUNDLE Group 848 When an offerer generates an offer, in which it wants to move a 849 bundled "m=" section out of a BUNDLE group, the offerer: 851 o MUST assign a unique address to the "m=" section; and 853 o MUST NOT place the identification-tag associated with the "m=" 854 section in the SDP 'group:BUNDLE' attribute identification-tag 855 list associated with the BUNDLE group; and 857 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 858 section. 860 An offerer MUST NOT move an "m=" section from one BUNDLE group to 861 another within a single offer. If the offerer wants to move an "m=" 862 section from one BUNDLE group to another it MUST first move the 863 BUNDLE group out of the current BUNDLE group, and then generate a 864 second offer where the "m=" section is added to another BUNDLE group 865 [Section 8.5.2]. 867 [Section 18.4] shows an example of an offer for moving an "m=" 868 section out of a BUNDLE group. 870 8.5.4. Disabling a Media Description in a BUNDLE Group 872 When an offerer generates an offer, in which it wants to disable a 873 bundled "m=" section, the offerer: 875 o MUST assign a zero port value to the "m=" section, following the 876 procedures in [RFC4566]; and 878 o MUST NOT place the identification-tag associated with the "m=" 879 section in the SDP 'group:BUNDLE' attribute identification-tag 880 list associated with the BUNDLE group; and 882 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 883 section. 885 [Section 18.5] shows an example of an offer and answer for disabling 886 an "m=" section within a BUNDLE group. 888 9. Protocol Identification 890 Each "m=" section within a BUNDLE group MUST use the same transport- 891 layer protocol. If bundled "m=" sections use different upper-layer 892 protocols on top of the transport-layer protocol, there MUST exist a 893 publicly available specification which describes a mechanism how to 894 associate received data with the correct protocol for this particular 895 protocol combination. 897 In addition, if received data can be associated with more than one 898 bundled "m=" section, there MUST exist a publicly available 899 specification which describes a mechanism for associating the 900 received data with the correct "m=" section. 902 This document describes a mechanism to identify the protocol of 903 received data among the STUN, DTLS and SRTP protocols (in any 904 combination), when UDP is used as transport-layer protocol, but it 905 does not describe how to identify different protocols transported on 906 DTLS. While the mechanism is generally applicable to other protocols 907 and transport-layer protocols, any such use requires further 908 specification around how to multiplex multiple protocols on a given 909 transport-layer protocol, and how to associate received data with the 910 correct protocols. 912 9.1. STUN, DTLS, SRTP 914 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 915 protocol of a received packet among the STUN, DTLS and SRTP protocols 916 (in any combination). If an offer or answer includes a bundled "m=" 917 section that represents these protocols, the offerer or answerer MUST 918 support the mechanism described in [RFC5764], and no explicit 919 negotiation is required in order to indicate support and usage of the 920 mechanism. 922 [RFC5764] does not describe how to identify different protocols 923 transported on DTLS, only how to identify the DTLS protocol itself. 924 If multiple protocols are transported on DTLS, there MUST exist a 925 specification describing a mechanism for identifying each individual 926 protocol. In addition, if a received DTLS packet can be associated 927 with more than one "m=" section, there MUST exist a specification 928 which describes a mechanism for associating the received DTLS packets 929 with the correct "m=" section. 931 [Section 10.2] describes how to associate the packets in a received 932 SRTP stream with the correct "m=" section. 934 10. RTP Considerations 936 10.1. Single RTP Session 938 All RTP-based media within a single BUNDLE group belong to a single 939 RTP session [RFC3550]. 941 Since a single BUNDLE transport is used for sending and receiving 942 bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for 943 RTP-based bundled media. 945 Since a single RTP session is used for each BUNDLE group, all "m=" 946 sections representing RTP-based media within a BUNDLE group will 947 share a single SSRC numbering space [RFC3550]. 949 The following rules and restrictions apply for a single RTP session: 951 o A specific payload type value can be used in multiple bundled "m=" 952 sections only if each codec associated with the payload type 953 number shares an identical codec configuration [Section 10.1.1]. 955 o The proto value in each bundled RTP-based "m=" section MUST be 956 identical (e.g., RTP/AVPF). 958 o The RTP MID header extension MUST be enabled, by including an SDP 959 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 960 hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section 961 in every offer and answer. 963 o A given SSRC MUST NOT transmit RTP packets using payload types 964 that originate from different bundled "m=" sections. 966 NOTE: The last bullet above is to avoid sending multiple media types 967 from the same SSRC. If transmission of multiple media types are done 968 with time overlap, RTP and RTCP fail to function. Even if done in 969 proper sequence this causes RTP Timestamp rate switching issues 970 [RFC7160]. However, once an SSRC has left the RTP session (by 971 sending an RTCP BYE packet), that SSRC can be reused by another 972 source (possibly associated with a different bundled "m=" section) 973 after a delay of 5 RTCP reporting intervals (the delay is to ensure 974 the SSRC has timed out, in case the RTCP BYE packet was lost 975 [RFC3550]). 977 10.1.1. Payload Type (PT) Value Reuse 979 Multiple bundled "m=" sections might describe RTP based media. As 980 all RTP based media associated with a BUNDLE group belong to the same 981 RTP session, in order for a given payload type value to be used 982 inside more than one bundled "m=" section, all codecs associated with 983 the payload type number MUST share an identical codec configuration. 984 This means that the codecs MUST share the same media type, encoding 985 name, clock rate and any parameter that can affect the codec 986 configuration and packetization. 987 [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose 988 attribute values are required to be identical for all codecs that use 989 the same payload type value. 991 10.2. Associating RTP/RTCP Streams with Correct SDP Media Description 993 As described in [RFC3550], RTP packets are associated with RTP 994 streams [RFC7656]. Each RTP stream is identified by an SSRC value, 995 and each RTP packet includes an SSRC field that is used to associate 996 the packet with the correct RTP stream. RTCP packets also use SSRCs 997 to identify which RTP streams the packet relates to. However, a RTCP 998 packet can contain multiple SSRC fields, in the course of providing 999 feedback or reports on different RTP streams, and therefore can be 1000 associated with multiple such streams. 1002 In order to be able to process received RTP/RTCP packets correctly, 1003 it MUST be possible to associate an RTP stream with the correct "m=" 1004 section, as the "m=" section and SDP attributes associated with the 1005 "m=" section contains information needed to process the packets. 1007 As all RTP streams associated with a BUNDLE group use the same 1008 transport for sending and receiving RTP/RTCP packets, the local 1009 address:port combination part of the transport cannot be used to 1010 associate an RTP stream with the correct "m=" section. In addition, 1011 multiple RTP streams might be associated with the same "m=" section. 1013 An offerer and answerer can inform each other which SSRC values they 1014 will use for an RTP stream by using the SDP 'ssrc' attribute 1015 [RFC5576]. However, an offerer will not know which SSRC values the 1016 answerer will use until the offerer has received the answer providing 1017 that information. Due to this, before the offerer has received the 1018 answer, the offerer will not be able to associate an RTP stream with 1019 the correct "m=" section using the SSRC value associated with the RTP 1020 stream. In addition, the offerer and answerer may start using new 1021 SSRC values mid-session, without informing each other using the SDP 1022 'ssrc' attribute. 1024 In order for an offerer and answerer to always be able to associate 1025 an RTP stream with the correct "m=" section, the offerer and answerer 1026 using the BUNDLE extension MUST support the mechanism defined in 1027 Section 15, where the offerer and answerer insert the identification- 1028 tag associated with an "m=" section (provided by the remote peer) 1029 into RTP and RTCP packets associated with a BUNDLE group. 1031 When using this mechanism, the mapping from an SSRC to an 1032 identification-tag is carried in RTP header extensions or RTCP SDES 1033 packets, as specified in Section 15. Since a compound RTCP packet 1034 can contain multiple RTCP SDES packets, and each RTCP SDES packet can 1035 contain multiple chunks, a single RTCP packet can contain several 1036 SSRC to identification-tag mappings. The offerer and answerer 1037 maintain tables used for routing that are updated each time an RTP/ 1038 RTCP packet contains new information that affects how packets are to 1039 be routed. 1041 However, some legacy implementations may not include this 1042 identification-tag in their RTP and RTCP traffic when using the 1043 BUNDLE mechanism, and instead use a payload type based mechanism to 1044 associate RTP streams with SDP "m=" sections. In this situation, 1045 each "m=" section needs to use unique payload type values, in order 1046 for the payload type to be a reliable indicator of the relevant "m=" 1047 section for the RTP stream. If an implementation fails to ensure 1048 unique payload type values it will be impossible to associate the RTP 1049 stream using that payload type value to a particular "m=" section. 1050 Note that when using the payload type to associate RTP streams with 1051 "m=" sections an RTP stream, identified by its SSRC, will be mapped 1052 to an "m=" section when the first packet of that RTP stream is 1053 received, and the mapping will not be changed even if the payload 1054 type used by that RTP stream changes. In other words, the SSRC 1055 cannot "move" to a different "m=" section simply by changing the 1056 payload type. 1058 Applications can implement RTP stacks in many different ways. The 1059 algorithm below details one way that RTP streams can be associated 1060 with "m=" sections, but is not meant to be prescriptive about exactly 1061 how an RTP stack needs to be implemented. Applications MAY use any 1062 algorithm that achieves equivalent results to those described in the 1063 algorithm below. 1065 To prepare to associate RTP streams with the correct "m=" section, 1066 the following steps MUST be followed for each BUNDLE group: 1068 Construct a table mapping MID to "m=" section for each "m=" 1069 section in this BUNDLE group. Note that an "m=" section may only 1070 have one MID. 1072 Construct a table mapping SSRCs of incoming RTP streams to "m=" 1073 section for each "m=" section in this BUNDLE group and for each 1074 SSRC configured for receiving in that "m=" section. 1076 Construct a table mapping the SSRC of each outgoing RTP stream to 1077 "m=" section for each "m=" section in this BUNDLE group and for 1078 each SSRC configured for sending in that "m=" section. 1080 Construct a table mapping payload type to "m=" section for each 1081 "m=" section in the BUNDLE group and for each payload type 1082 configured for receiving in that "m=" section. If any payload 1083 type is configured for receiving in more than one "m=" section in 1084 the BUNDLE group, do not include it in the table, as it cannot be 1085 used to uniquely identify an "m=" section. 1087 Note that for each of these tables, there can only be one mapping 1088 for any given key (MID, SSRC, or PT). In other words, the tables 1089 are not multimaps. 1091 As "m=" sections are added or removed from the BUNDLE groups, or 1092 their configurations are changed, the tables above MUST also be 1093 updated. 1095 When an RTP packet is received, it MUST be delivered to the RTP 1096 stream corresponding to its SSRC. That RTP stream MUST then be 1097 associated with the correct "m=" section within a BUNDLE group, for 1098 additional processing, according to the following steps: 1100 If the MID associated with the RTP stream is not in the table 1101 mapping MID to "m=" section, then the RTP stream is not decoded 1102 and the payload data is discarded. 1104 If the packet has a MID, and the packet's extended sequence number 1105 is greater than that of the last MID update, as discussed in 1106 [RFC7941], Section 4.2.6, update the MID associated with the RTP 1107 stream to match the MID carried in the RTP packet, then update the 1108 mapping tables to include an entry that maps the SSRC of that RTP 1109 stream to the "m=" section for that MID. 1111 If the SSRC of the RTP stream is in the incoming SSRC mapping 1112 table, check that the payload type used by the RTP stream matches 1113 a payload type included on the matching "m=" section. If so, 1114 associate the RTP stream with that "m=" section. Otherwise, the 1115 RTP stream is not decoded and the payload data is discarded. 1117 If the payload type used by the RTP stream is in the payload type 1118 table, update the incoming SSRC mapping table to include an entry 1119 that maps the RTP stream's SSRC to the "m=" section for that 1120 payload type. Associate the RTP stream with the corresponding 1121 "m=" section. 1123 Otherwise, mark the RTP stream as not for decoding and discard the 1124 payload. 1126 If the RTP packet contains one or more contributing source (CSRC) 1127 identifiers, then each CSRC is looked up in the incoming SSRC table 1128 and a copy of the RTP packet is associated with the corresponding 1129 "m=" section for additional processing. 1131 For each RTCP packet received (including each RTCP packet that is 1132 part of a compound RTCP packet), the packet is processed as usual by 1133 the RTP layer, then associated with the appropriate "m=" sections, 1134 and processed for the RTP streams represented by those "m=" sections. 1135 This routing is type-dependent, as each kind of RTCP packet has its 1136 own mechanism for associating it with the relevant RTP streams. 1138 RTCP packets that cannot be associated with an appropriate "m=" 1139 section MUST still be processed as usual by the RTP layer, updating 1140 the metadata associated with the corresponding RTP streams. This 1141 situation can occur with certain multiparty RTP topologies, or when 1142 RTCP packets are sent containing a subset of the SDES information. 1144 Additional rules for processing various types of RTCP packets are 1145 explained below. 1147 If the RTCP packet is of type SDES, for each chunk in the packet 1148 whose SSRC is found in the incoming SSRC table, deliver a copy of 1149 the SDES packet to the "m=" section associated with that SSRC. In 1150 addition, for any SDES MID items contained in these chunks, if the 1151 MID is found in the table mapping MID to "m=" section, update the 1152 incoming SSRC table to include an entry that maps the RTP stream 1153 associated with the chunk's SSRC to the "m=" section associated 1154 with that MID, unless the packet is older than the packet that 1155 most recently updated the mapping for this SSRC, as discussed in 1156 [RFC7941], Section 4.2.6. 1158 Note that if an SDES packet is received as part of a compound RTCP 1159 packet, the SSRC to "m=" section mapping might not exist until the 1160 SDES packet is handled (e.g., in the case where RTCP for a source 1161 is received before any RTP packets). Therefore, it can be 1162 beneficial for an implementation to delay RTCP packet routing, 1163 such that it either prioritizes processing of the SDES item to 1164 generate or update the mapping, or buffers the RTCP information 1165 that needs to be routed until the SDES item(s) has been processed. 1166 If the implementation is unable to follow this recommendation, the 1167 consequence could be that some RTCP information from this 1168 particular RTCP compound packet is not provided to higher layers. 1169 The impact from this is likely minor, when this information 1170 relates to a future incoming RTP stream. 1172 If the RTCP packet is of type BYE, it indicates that the RTP 1173 streams referenced in the packet are ending. Therefore, for each 1174 SSRC indicated in the packet that is found in the incoming SSRC 1175 table, first deliver a copy of the BYE packet to the "m=" section 1176 associated with that SSRC, then remove the entry for that SSRC 1177 from the incoming SSRC table after an appropriate delay to account 1178 for "straggler packets", as specified in [RFC3550], Section 6.2.1. 1180 If the RTCP packet is of type SR or RR, for each report block in 1181 the report whose "SSRC of source" is found in the outgoing SSRC 1182 table, deliver a copy of the SR or RR packet to the "m=" section 1183 associated with that SSRC. In addition, if the packet is of type 1184 SR, and the sender SSRC for the packet is found in the incoming 1185 SSRC table, deliver a copy of the SR packet to the "m=" section 1186 associated with that SSRC. 1188 If the implementation supports RTCP XR and the packet is of type 1189 XR, as defined in [RFC3611], for each report block in the report 1190 whose "SSRC of source" is found in the outgoing SSRC table, 1191 deliver a copy of the XR packet to the "m=" section associated 1192 with that SSRC. In addition, if the sender SSRC for the packet is 1193 found in the incoming SSRC table, deliver a copy of the XR packet 1194 to the "m=" section associated with that SSRC. 1196 If the RTCP packet is a feedback message of type RTPFB or PSFB, as 1197 defined in [RFC4585], it will contain a media source SSRC, and 1198 this SSRC is used for routing certain subtypes of feedback 1199 messages. However, several subtypes of PSFB and RTPFB messages 1200 include target SSRC(s) in a section called Feedback Control 1201 Information (FCI). For these messages, the target SSRC(s) are 1202 used for routing. 1204 If the RTCP packet is a feedback packet that does not include 1205 target SSRCs in its FCI section, and the media source SSRC is 1206 found in the outgoing SSRC table, deliver the feedback packet to 1207 the "m=" section associated with that SSRC. RTPFB and PSFB types 1208 that are handled in this way include: 1210 Generic NACK: [RFC4585] (PT=RTPFB, FMT=1). 1212 Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1). 1214 Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2). 1216 Reference Picture Selection Indication (RPSI): [RFC4585] 1217 (PT=PSFB, FMT=3). 1219 If the RTCP packet is a feedback message that does include target 1220 SSRC(s) in its FCI section, it can either be a request or a 1221 notification. Requests reference a RTP stream that is being sent 1222 by the message recipient, whereas notifications are responses to 1223 an earlier request, and therefore reference a RTP stream that is 1224 being received by the message recipient. 1226 If the RTCP packet is a feedback request that includes target 1227 SSRC(s), for each target SSRC that is found in the outgoing SSRC 1228 table, deliver a copy of the RTCP packet to the "m=" section 1229 associated with that SSRC. PSFB and RTPFB types that are handled 1230 in this way include: 1232 Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). 1234 Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, 1235 FMT=5). 1237 H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, 1238 FMT=7). 1240 Temporary Maximum Media Bit Rate Request (TMMBR): [RFC5104] 1241 (PT=RTPFB, FMT=3). 1243 Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, 1244 FMT=TBD). 1246 If the RTCP packet is a feedback notification that includes target 1247 SSRC(s), for each target SSRC that is found in the incoming SSRC 1248 table, deliver a copy of the RTCP packet to the "m=" section 1249 associated with the RTP stream with matching SSRC. PSFB and RTPFB 1250 types that are handled in this way include: 1252 Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] 1253 (PT=PSFB, FMT=6). This message is a notification in response 1254 to a prior TSTR. 1256 Temporary Maximum Media Bit Rate Notification (TMMBN): [RFC5104] 1257 (PT=RTPFB, FMT=4). This message is a notification in response 1258 to a prior TMMBR, but can also be sent unsolicited. 1260 If the RTCP packet is of type APP, then it is handled in an 1261 application specific manner. If the application does not 1262 recognise the APP packet, then it MUST be discarded. 1264 10.3. RTP/RTCP Multiplexing 1266 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 1267 multiplexing [RFC5761] for the RTP-based media specified by the 1268 BUNDLE group. 1270 When RTP/RTCP multiplexing is enabled, the same transport will be 1271 used for both RTP packets and RTCP packets associated with the BUNDLE 1272 group. 1274 10.3.1. SDP Offer/Answer Procedures 1276 This section describes how an offerer and answerer use the SDP 'rtcp- 1277 mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute 1278 [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP 1279 multiplexing for RTP-based media associated with a BUNDLE group. 1281 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] of the SDP 1282 'rtcp-mux' and 'rtcp-mux-only' attributes is IDENTICAL. Section 8.1 1283 describes the details regarding which bundled "m=" sections an 1284 offerer and answerer associates the attributes with. 1286 RTP/RTCP multiplexing only applies to RTP-based media. However, as 1287 described in Section 8.1, within a BUNDLE group the SDP 'rtcp-mux' 1288 and SDP 'rtcp-mux-only' attributes might be included in a non-RTP- 1289 based bundled "m=" section (if such "m=" line is indicated by a 1290 BUNDLE-tag). 1292 NOTE: The offer in which the offerer indicates that it wants to 1293 create a BUNDLE group can be the initial offer of the session, or a 1294 subsequent offer within the session. As defined in Section 2, within 1295 the scope of this document the initial offer always refers to the 1296 offer in which the offerer indicates that it wants to create a BUNDLE 1297 group, no matter whether that offer is the initial offer, or a 1298 subsequent offer, within the session. 1300 10.3.1.1. Generating the Initial SDP Offer 1302 When an offerer generates an initial offer, if the offer contains one 1303 or more RTP-based bundled "m=" sections (or, if there is a chance 1304 that RTP-based "m=" sections will later be added to the BUNDLE 1305 group), the offerer MUST include an SDP 'rtcp-mux' attribute 1306 [RFC5761] in each bundled "m=" section (excluding any bundle-only 1307 "m=" sections), following the procedures for IDENTICAL mux category 1308 attributes in Section 8.1. In addition, the offerer MAY include an 1309 SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] in a 1310 RTP-based bundled "m=" section. 1312 NOTE: Whether the offerer associates the SDP 'rtcp-mux-only' 1313 attribute depends on whether the offerer supports fallback to usage 1314 of a separate port for RTCP in case the answerer moves one or more 1315 RTP-based "m=" section out of the BUNDLE group in the answer. 1317 NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the 1318 bundled "m=" sections, but does not include an SDP 'rtcp-mux-only' 1319 attribute, the offerer can also include an SDP 'rtcp' attribute 1320 [RFC3605] in one or more RTP-based bundled "m=" sections in order to 1321 provide a fallback port for RTCP, as described in [RFC5761]. 1322 However, the fallback port will only be used for RTP-based "m=" 1323 sections moved out of the BUNDLE group by the answerer. 1325 In the initial offer, the address:port combination for RTCP MUST be 1326 unique in each bundled RTP-based "m=" section (excluding a bundle- 1327 only "m=" section), similar to RTP. 1329 10.3.1.2. Generating the SDP Answer 1331 When an answerer generates an answer, if the answerer supports RTP- 1332 based media, and if a bundled "m=" section in the offer contained an 1333 SDP 'rtcp-mux' attribute, the answerer MUST enable usage of RTP/RTCP 1334 multiplexing, even if there currently are no RTP-based "m=" sections 1335 within the BUNDLE group. The answerer MUST include an SDP 'rtcp-mux' 1336 attribute in the bundled "m=" section indicated by the answerer 1337 BUNDLE-tag, following the procedures for IDENTICAL mux category 1338 attributes in Section 8.1. In addition, if the "m=" section in the 1339 offer contained an SDP "rtcp-mux-only" attribute, the answerer MUST 1340 include an SDP "rtcp-mux-only" attribute in the bundled "m=" section 1341 indicated by the answerer BUNDLE-tag in the answer. 1343 If the "m=" section indicated by the offerer BUNDLE-tag in the offer 1344 contained an SDP 'rtcp-mux-only' attribute, and if the answerer moves 1345 an RTP-based "m=" section out of the BUNDLE group in the answer 1346 [Section 8.3.3], the answerer MUST either include the attribute in 1347 the moved "m=" section (and enable RTP/RTCP multiplexing for the 1348 media associated with the "m=" section), or reject the "m=" section 1349 [Section 8.3.4]. 1351 The answerer MUST NOT include an SDP 'rtcp' attribute in any "m=" 1352 section within the BUNDLE group in the answer. The answerer will use 1353 the port value of the selected offerer BUNDLE address:port for 1354 sending RTP and RTCP packets associated with each RTP-based bundled 1355 "m=" section towards the offerer. 1357 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1358 negotiated in a previous offer/answer exchange, the answerer MUST 1359 include an SDP 'rtcp-mux' attribute in the "m=" section associated 1360 with the answerer BUNDLE-tag in the answer. It is not possible to 1361 disable RTP/RTCP multiplexing within a BUNDLE group. 1363 10.3.1.3. Offerer Processing of the SDP Answer 1365 When an offerer receives an answer, if the answerer has accepted the 1366 usage of RTP/RTCP multiplexing (see Section 10.3.1.2), the answerer 1367 follows the procedures for RTP/RTCP multiplexing defined in 1368 [RFC5761]. The offerer will use the port value associated with the 1369 answerer BUNDLE address:port for sending RTP and RTCP packets 1370 associated with each RTP-based bundled "m=" section towards the 1371 answerer. 1373 NOTE: It is considered a protocol error if the answerer has not 1374 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" 1375 sections that the answerer included in the BUNDLE group. 1377 10.3.1.4. Modifying the Session 1379 When an offerer generates a subsequent offer, the offerer MUST 1380 include an SDP 'rtcp-mux' attribute in the bundled "m=" section 1381 indicated by the offerer BUNDLE-tag, following the procedures for 1382 IDENTICAL mux category attributes in Section 8.1. 1384 11. ICE Considerations 1386 This section describes how to use the BUNDLE grouping extension 1387 together with the Interactive Connectivity Establishment (ICE) 1388 mechanism [I-D.ietf-ice-rfc5245bis]. 1390 The generic procedures for negotiating usage of ICE using SDP, 1391 defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE 1392 with BUNDLE, with the following exceptions: 1394 o When the BUNDLE transport has been established, ICE connectivity 1395 checks and keep-alives only need to be performed for the BUNDLE 1396 transport, instead of per individual "m=" section within the 1397 BUNDLE group. 1399 o In an offer, if the offer assigns a unique address to one or more 1400 bundled "m=" sections (excluding any bundle-only "m=" sections), 1401 the offerer MUST include ICE-related media-level attributes in 1402 each of those "m=" sections. If the offerer assigns an offerer 1403 BUNDLE address:port (previously selected [Section 8.3.1] or newly 1404 suggested [Section 8.5.1]) to a bundled "m=" section (the "m=" 1405 section indicated by the offerer BUNDLE-tag), the offerer only 1406 includes ICE-related media-level SDP attributes in that "m=" 1407 section, following the procedures in Section 8.1. 1409 o In an answer, the answerer only includes ICE-related media-level 1410 SDP attributes in the bundled "m=" section to which the answerer 1411 has assigned the answerer BUNDLE address:port (the "m=" section 1412 indicated by the answerer BUNDLE-tag), following the procedures in 1413 Section 8.1. 1415 Initially, before ICE has produced a candidate pair that will be used 1416 for media, there might be multiple transports established (if 1417 multiple candidate pairs are tested). Once ICE has produced a 1418 transport that will be used for media, that becomes the BUNDLE 1419 transport. 1421 Support and usage of ICE mechanism together with the BUNDLE extension 1422 is OPTIONAL, and the procedures in this section only apply when the 1423 ICE mechanism is used. Note that applications might mandate usage of 1424 the ICE mechanism even if the BUNDLE extension is not used. 1426 11.1. SDP Offer/Answer Procedures 1428 When an offerer assigns a unique address to one or more bundled "m=" 1429 sections (excluding any bundle-only "m=" section), the offerer MUST 1430 include SDP 'candidate' attributes (and other applicable ICE-related 1431 media-level SDP attributes), containing unique ICE properties 1432 (candidates etc), in each of those "m=" sections, following the 1433 procedures in [I-D.ietf-mmusic-ice-sip-sdp]. 1435 When an offerer assigns a BUNDLE address:port (previously selected or 1436 newly suggested) to a bundled "m=" section, (the "m=" section 1437 indicated by the offerer BUNDLE-tag) the offerer MUST only include 1438 SDP 'candidate' attributes (and other applicable ICE-related media- 1439 level SDP attributes) in that "m=" section, following the procedures 1440 in Section 8.1. 1442 When an answerer assigns a BUNDLE address to an "m=" section within a 1443 BUNDLE group (the "m=" section represented by the answerer BUNDLE- 1444 tag), the answerer onlys include SDP 'candidate' attributes (and 1445 other applicable ICE-related media-level SDP attributes) in that "m=" 1446 section, following the procedures in Section 8.1. The answerer MUST 1447 NOT include ICE-related media-level SDP attributes in any other "m=" 1448 sections. 1450 NOTE: As most ICE-related media-level SDP attributes belong to the 1451 TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the 1452 offerer and answerer follow the procedures in Section 8.1 when 1453 deciding whether to include an attribute in a bundled "m=" section. 1454 However, in the case of ICE-related media-level attributes, the rules 1455 apply to all attributes (see note below), even if they belong to a 1456 different mux category. 1458 NOTE: The following ICE-related media-level SDP attributes are 1459 defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidate', 'remote- 1460 candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- 1461 pacing'. 1463 12. DTLS Considerations 1465 One or more media streams within a BUNDLE group might use the 1466 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1467 to encrypt the data, or to negotiate encryption keys if another 1468 encryption mechanism is used to encrypt media. 1470 When DTLS is used within a BUNDLE group, the following rules apply: 1472 o There can only be one DTLS association [RFC6347] associated with 1473 the BUNDLE group; and 1475 o Each usage of the DTLS association within the BUNDLE group MUST 1476 use the same mechanism for determining which endpoints (the 1477 offerer or answerer) become DTLS client and DTLS server; and 1479 o Each usage of the DTLS association within the BUNDLE group MUST 1480 use the same mechanism for determining whether an offer or answer 1481 will trigger the establishment of a new DTLS association, or 1482 whether an existing DTLS association will be used; and 1484 o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include 1485 the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message 1486 [RFC5764]. The client MUST include the extension even if the 1487 usage of DTLS-SRTP is not negotiated as part of the multimedia 1488 session (e.g., SIP session [RFC3261]. 1490 NOTE: The inclusion of the 'use_srtp' extension during the initial 1491 DTLS handshake ensures that a DTLS renegotiation will not be required 1492 in order to include the extension, in case DTLS-SRTP encrypted media 1493 is added to the BUNDLE group later during the multimedia session. 1495 13. RTP Header Extensions Consideration 1497 When [RFC8285] RTP header extensions are used in the context of this 1498 specification, the identifier used for a given extension MUST 1499 identify the same extension across all the bundled media 1500 descriptions. 1502 14. Update to RFC 3264 1504 This section updates RFC 3264, in order to allow extensions to define 1505 the usage of a zero port value in offers and answers for other 1506 purposes than removing or disabling media streams. The following 1507 sections of RFC 3264 are updated: 1509 o Section 5.1 (Unicast Streams). 1511 o Section 6 (Generating the Answer). 1513 o Section 8.4 (Putting a Unicast Media Stream on Hold). 1515 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 1517 For recvonly and sendrecv streams, the port number and address in the 1518 offer indicate where the offerer would like to receive the media 1519 stream. For sendonly RTP streams, the address and port number 1520 indirectly indicate where the offerer wants to receive RTCP reports. 1521 Unless there is an explicit indication otherwise, reports are sent to 1522 the port number one higher than the number indicated. The IP address 1523 and port present in the offer indicate nothing about the source IP 1524 address and source port of RTP and RTCP packets that will be sent by 1525 the offerer. A port number of zero in the offer indicates that the 1526 stream is offered but MUST NOT be used. This has no useful semantics 1527 in an initial offer, but is allowed for reasons of completeness, 1528 since the answer can contain a zero port indicating a rejected stream 1529 (Section 6). Furthermore, existing streams can be terminated by 1530 setting the port to zero (Section 8). In general, a port number of 1531 zero indicates that the media stream is not wanted. 1533 14.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 1535 For recvonly and sendrecv streams, the port number and address in the 1536 offer indicate where the offerer would like to receive the media 1537 stream. For sendonly RTP streams, the address and port number 1538 indirectly indicate where the offerer wants to receive RTCP reports. 1539 Unless there is an explicit indication otherwise, reports are sent to 1540 the port number one higher than the number indicated. The IP address 1541 and port present in the offer indicate nothing about the source IP 1542 address and source port of RTP and RTCP packets that will be sent by 1543 the offerer. A port number of zero in the offer by default indicates 1544 that the stream is offered but MUST NOT be used, but an extension 1545 mechanism might specify different semantics for the usage of a zero 1546 port value. Furthermore, existing streams can be terminated by 1547 setting the port to zero (Section 8). In general, a port number of 1548 zero by default indicates that the media stream is not wanted. 1550 14.3. Original text of section 6 (4th paragraph) of RFC 3264 1552 An offered stream MAY be rejected in the answer, for any reason. If 1553 a stream is rejected, the offerer and answerer MUST NOT generate 1554 media (or RTCP packets) for that stream. To reject an offered 1555 stream, the port number in the corresponding stream in the answer 1556 MUST be set to zero. Any media formats listed are ignored. At least 1557 one MUST be present, as specified by SDP. 1559 14.4. New text replacing section 6 (4th paragraph) of RFC 3264 1561 An offered stream MAY be rejected in the answer, for any reason. If 1562 a stream is rejected, the offerer and answerer MUST NOT generate 1563 media (or RTCP packets) for that stream. A port number of zero in 1564 the answer by default indicates that the offered stream is rejected, 1565 but an extension mechanism might specify different semantics for the 1566 usage of a zero port value. If a stream is rejected, any media 1567 formats listed are ignored. At least one MUST be present, as 1568 specified by SDP. 1570 14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 1572 RFC 2543 [10] specified that placing a user on hold was accomplished 1573 by setting the connection address to 0.0.0.0. Its usage for putting 1574 a call on hold is no longer recommended, since it doesn't allow for 1575 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1576 with connection oriented media. However, it can be useful in an 1577 initial offer when the offerer knows it wants to use a particular set 1578 of media streams and formats, but doesn't know the addresses and 1579 ports at the time of the offer. Of course, when used, the port 1580 number MUST NOT be zero, which would specify that the stream has been 1581 disabled. An agent MUST be capable of receiving SDP with a 1582 connection address of 0.0.0.0, in which case it means that neither 1583 RTP nor RTCP is to be sent to the peer. 1585 14.6. New text replacing section 8.4 (6th paragraph) of RFC 3264 1587 RFC 2543 [10] specified that placing a user on hold was accomplished 1588 by setting the connection address to 0.0.0.0. Its usage for putting 1589 a call on hold is no longer recommended, since it doesn't allow for 1590 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1591 with connection oriented media. However, it can be useful in an 1592 initial offer when the offerer knows it wants to use a particular set 1593 of media streams and formats, but doesn't know the addresses and 1594 ports at the time of the offer. Of course, when used, the port 1595 number MUST NOT be zero, if it would specify that the stream has been 1596 disabled. However, an extension mechanism might specify different 1597 semantics of the zero port number usage. An agent MUST be capable of 1598 receiving SDP with a connection address of 0.0.0.0, in which case it 1599 means that neither RTP nor RTCP is to be sent to the peer. 1601 15. RTP/RTCP extensions for identification-tag transport 1603 SDP Offerers and Answerers [RFC3264] can associate identification- 1604 tags with "m=" sections within SDP Offers and Answers, using the 1605 procedures in [RFC5888]. Each identification-tag uniquely represents 1606 an "m=" section. 1608 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1609 used to carry identification-tags within RTCP SDES packets. This 1610 section also defines a new RTP SDES header extension [RFC7941], which 1611 is used to carry the 'MID' RTCP SDES item in RTP packets. 1613 The SDES item and RTP SDES header extension make it possible for a 1614 receiver to associate each RTP stream with a specific "m=" section, 1615 with which the receiver has associated an identification-tag, even if 1616 those "m=" sections are part of the same RTP session. The RTP SDES 1617 header extension also ensures that the media recipient gets the 1618 identification-tag upon receipt of the first decodable media and is 1619 able to associate the media with the correct application. 1621 A media recipient informs the media sender about the identification- 1622 tag associated with an "m=" section through the use of an 'mid' 1623 attribute [RFC5888]. The media sender then inserts the 1624 identification-tag in RTCP and RTP packets sent to the media 1625 recipient. 1627 NOTE: This text above defines how identification-tags are carried in 1628 SDP Offers and Answers. The usage of other signaling protocols for 1629 carrying identification-tags is not prevented, but the usage of such 1630 protocols is outside the scope of this document. 1632 [RFC3550] defines general procedures regarding the RTCP transmission 1633 interval. The RTCP MID SDES item SHOULD be sent in the first few 1634 RTCP packets sent after joining the session, and SHOULD be sent 1635 regularly thereafter. The exact number of RTCP packets in which this 1636 SDES item is sent is intentionally not specified here, as it will 1637 depend on the expected packet loss rate, the RTCP reporting interval, 1638 and the allowable overhead. 1640 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1641 be included in some RTP packets at the start of the session and 1642 whenever the SSRC changes. It might also be useful to include the 1643 header extension in RTP packets that comprise access points in the 1644 media (e.g., with video I-frames). The exact number of RTP packets 1645 in which this header extension is sent is intentionally not specified 1646 here, as it will depend on expected packet loss rate and loss 1647 patterns, the overhead the application can tolerate, and the 1648 importance of immediate receipt of the identification-tag. 1650 For robustness, endpoints need to be prepared for situations where 1651 the reception of the identification-tag is delayed, and SHOULD NOT 1652 terminate sessions in such cases, as the identification-tag is likely 1653 to arrive soon. 1655 15.1. RTCP MID SDES Item 1657 0 1 2 3 1658 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 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | MID=TBD | length | identification-tag ... 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 The identification-tag payload is UTF-8 encoded, as in SDP. 1665 The identification-tag is not zero terminated. 1667 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1668 identifier value.] 1670 15.2. RTP SDES Header Extension For MID 1672 The payload, containing the identification-tag, of the RTP SDES 1673 header extension element can be encoded using either the one-byte or 1674 two-byte header [RFC7941]. The identification-tag payload is UTF-8 1675 encoded, as in SDP. 1677 The identification-tag is not zero terminated. Note, that the set of 1678 header extensions included in the packet needs to be padded to the 1679 next 32-bit boundary using zero bytes [RFC8285]. 1681 As the identification-tag is included in either an RTCP SDES item or 1682 an RTP SDES header extension, or both, there needs to be some 1683 consideration about the packet expansion caused by the 1684 identification-tag. To avoid Maximum Transmission Unit (MTU) issues 1685 for the RTP packets, the header extension's size needs to be taken 1686 into account when encoding the media. 1688 It is recommended that the identification-tag is kept short. Due to 1689 the properties of the RTP header extension mechanism, when using the 1690 one-byte header, a tag that is 1-3 bytes will result in a minimal 1691 number of 32-bit words used for the RTP SDES header extension, in 1692 case no other header extensions are included at the same time. Note, 1693 do take into account that some single characters when UTF-8 encoded 1694 will result in multiple octets. The identification-tag MUST NOT 1695 contain any user information, and applications SHALL avoid generating 1696 the identification-tag using a pattern that enables user- or 1697 application identification. 1699 16. IANA Considerations 1701 16.1. New SDES item 1703 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1704 document.] 1706 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1707 identifier value.] 1709 This document adds the MID SDES item to the IANA "RTP SDES item 1710 types" registry as follows: 1712 Value: TBD 1713 Abbrev.: MID 1714 Name: Media Identification 1715 Reference: RFCXXXX 1717 16.2. New RTP SDES Header Extension URI 1719 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1720 document.] 1722 This document defines a new extension URI in the RTP SDES Compact 1723 Header Extensions sub-registry of the RTP Compact Header Extensions 1724 registry sub-registry, according to the following data: 1726 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1727 Description: Media identification 1728 Contact: IESG (iesg@ietf.org) 1729 Reference: RFCXXXX 1731 The SDES item does not reveal privacy information about the users. 1732 It is simply used to associate RTP-based media with the correct SDP 1733 media description ("m=" section) in the SDP used to negotiate the 1734 media. 1736 The purpose of the extension is for the offerer to be able to 1737 associate received multiplexed RTP-based media before the offerer 1738 receives the associated SDP answer. 1740 16.3. New SDP Attribute 1742 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1743 document.] 1745 This document defines a new SDP media-level attribute, 'bundle-only', 1746 according to the following data: 1748 Attribute name: bundle-only 1749 Type of attribute: media 1750 Subject to charset: No 1751 Purpose: Request a media description to be accepted 1752 in the answer only if kept within a BUNDLE 1753 group by the answerer. 1754 Appropriate values: N/A 1755 Contact name: IESG 1756 Contact e-mail: iesg@ietf.org 1757 Reference: RFCXXXX 1758 Mux category: NORMAL 1760 16.4. New SDP Group Semantics 1762 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1763 document.] 1765 This document registers the following semantics with IANA in the 1766 "Semantics for the "group" SDP Attribute" subregistry (under the 1767 "Session Description Protocol (SDP) Parameters" registry: 1769 Semantics Token Reference 1770 ------------------------------------- ------ --------- 1771 Media bundling BUNDLE [RFCXXXX] 1773 17. Security Considerations 1775 The security considerations defined in [RFC3264] and [RFC5888] apply 1776 to the BUNDLE extension. Bundle does not change which information, 1777 e.g., RTP streams, flows over the network, with the exception of the 1778 usage of the MID SDES item as discussed below. Primarily it changes 1779 which addresses and ports, and thus in which (RTP) sessions the 1780 information is flowing. This affects the security contexts being 1781 used and can cause previously separated information flows to share 1782 the same security context. This has very little impact on the 1783 performance of the security mechanism of the RTP sessions. In cases 1784 where one would have applied different security policies on the 1785 different RTP streams being bundled, or where the parties having 1786 access to the security contexts would have differed between the RTP 1787 streams, additional analysis of the implications are needed before 1788 selecting to apply BUNDLE. 1790 The identification-tag, independent of transport, RTCP SDES packet or 1791 RTP header extension, can expose the value to parties beyond the 1792 signaling chain. Therefore, the identification-tag values MUST be 1793 generated in a fashion that does not leak user information, e.g., 1794 randomly or using a per-bundle group counter, and SHOULD be 3 bytes 1795 or less, to allow them to efficiently fit into the MID RTP header 1796 extension. Note that if implementations use different methods for 1797 generating identification-tags this could enable fingerprinting of 1798 the implementation making it vulnerable to targeted attacks. The 1799 identification-tag is exposed on the RTP stream level when included 1800 in the RTP header extensions, however what it reveals of the RTP 1801 media stream structure of the endpoint and application was already 1802 possible to deduce from the RTP streams without the MID SDES header 1803 extensions. As the identification-tag is also used to route the 1804 media stream to the right application functionality it is important 1805 that the value received is the one intended by the sender, thus 1806 integrity and the authenticity of the source are important to prevent 1807 denial of service on the application. Existing SRTP configurations 1808 and other security mechanisms protecting the whole RTP/RTCP packets 1809 will provide the necessary protection. 1811 When the BUNDLE extension is used, the set of configurations of the 1812 security mechanism used in all the bundled media descriptions will 1813 need to be compatible so that they can be used simultaneously, at 1814 least per direction or endpoint. When using SRTP this will be the 1815 case, at least for the IETF defined key-management solutions due to 1816 their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their 1817 classification in [I-D.ietf-mmusic-sdp-mux-attributes]. 1819 The security considerations of "RTP Header Extension for the RTP 1820 Control Protocol (RTCP) Source Description Items" [RFC7941] requires 1821 that when RTCP is confidentiality protected, and that any SDES RTP 1822 header extension carrying an SDES item, such as the MID RTP header 1823 extension, is also protected using commensurate strength algorithms. 1824 However, assuming the above requirements and recommendations are 1825 followed, there are no known significant security risks with leaving 1826 the MID RTP header extension without confidentiality protection. 1827 Therefore, this specification updates RFC 7941 by adding the 1828 exception that this requirement MAY be ignored for the MID RTP header 1829 extension. Security mechanisms for RTP/RTCP are discussed in Options 1830 for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can 1831 provide the necessary security functions of ensuring the integrity 1832 and source authenticity. 1834 18. Examples 1836 18.1. Example: BUNDLE Address:Port Selection 1838 The example below shows: 1840 o An offer, in which the offerer assigns a unique address to each 1841 bundled "m=" section within the BUNDLE group. 1843 o An answer, in which the answerer selects the offerer BUNDLE 1844 address:port, and then selects its own BUNDLE address (the 1845 answerer BUNDLE address:port) and assigns it to the bundled "m=" 1846 section indicated by the answerer BUNDLE-tag. 1848 SDP Offer (1) 1850 v=0 1851 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1852 s= 1853 c=IN IP6 2001:db8::3 1854 t=0 0 1855 a=group:BUNDLE foo bar 1856 m=audio 10000 RTP/AVP 0 8 97 1857 b=AS:200 1858 a=mid:foo 1859 a=rtcp-mux 1860 a=rtpmap:0 PCMU/8000 1861 a=rtpmap:8 PCMA/8000 1862 a=rtpmap:97 iLBC/8000 1863 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1864 m=video 10002 RTP/AVP 31 32 1865 b=AS:1000 1866 a=mid:bar 1867 a=rtcp-mux 1868 a=rtpmap:31 H261/90000 1869 a=rtpmap:32 MPV/90000 1870 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1872 SDP Answer (2) 1874 v=0 1875 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1876 s= 1877 c=IN IP6 2001:db8::1 1878 t=0 0 1879 a=group:BUNDLE foo bar 1880 m=audio 20000 RTP/AVP 0 1881 b=AS:200 1882 a=mid:foo 1883 a=rtcp-mux 1884 a=rtpmap:0 PCMU/8000 1885 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1886 m=video 0 RTP/AVP 32 1887 b=AS:1000 1888 a=mid:bar 1889 a=bundle-only 1890 a=rtpmap:32 MPV/90000 1891 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1893 18.2. Example: BUNDLE Extension Rejected 1895 The example below shows: 1897 o An offer, in which the offerer assigns a unique address to each 1898 bundled "m=" section within the BUNDLE group. 1900 o An answer, in which the answerer rejects the offered BUNDLE group, 1901 and assigns a unique address to each "m=" section (following 1902 normal RFC 3264 procedures). 1904 SDP Offer (1) 1906 v=0 1907 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1908 s= 1909 c=IN IP6 2001:db8::3 1910 t=0 0 1911 a=group:BUNDLE foo bar 1912 m=audio 10000 RTP/AVP 0 8 97 1913 b=AS:200 1914 a=mid:foo 1915 a=rtcp-mux 1916 a=rtpmap:0 PCMU/8000 1917 a=rtpmap:8 PCMA/8000 1918 a=rtpmap:97 iLBC/8000 1919 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1920 m=video 10002 RTP/AVP 31 32 1921 b=AS:1000 1922 a=mid:bar 1923 a=rtcp-mux 1924 a=rtpmap:31 H261/90000 1925 a=rtpmap:32 MPV/90000 1926 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1928 SDP Answer (2) 1930 v=0 1931 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1932 s= 1933 c=IN IP6 2001:db8::1 1934 t=0 0 1935 m=audio 20000 RTP/AVP 0 1936 b=AS:200 1937 a=rtcp-mux 1938 a=rtpmap:0 PCMU/8000 1939 m=video 30000 RTP/AVP 32 1940 b=AS:1000 1941 a=rtcp-mux 1942 a=rtpmap:32 MPV/90000 1944 18.3. Example: Offerer Adds a Media Description to a BUNDLE Group 1946 The example below shows: 1948 o A subsequent offer (the BUNDLE group has been created as part of a 1949 previous offer/answer exchange), in which the offerer adds a new 1950 "m=" section, indicated by the "zen" identification-tag, to a 1951 previously negotiated BUNDLE group, assigns the previously 1952 selected offerer BUNDLE address:port to the added "m=" section, 1953 indicated by the offerer BUNDLE-tag. To every other bundled "m=" 1954 section the offerer assigns a zero port value and includes an SDP 1955 'bundle-only' attribute. 1957 o An answer, in which the answerer assigns the answerer BUNDLE 1958 address:port to the bundled "m=" section indicated by the answerer 1959 BUNDLE-tag. To every other bundled "m=" section the answerer 1960 assigns a zero port value and includes an SDP 'bundle-only' 1961 attribute. 1963 SDP Offer (1) 1965 v=0 1966 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1967 s= 1968 c=IN IP6 2001:db8::3 1969 t=0 0 1970 a=group:BUNDLE zen foo bar 1971 m=audio 0 RTP/AVP 0 8 97 1972 b=AS:200 1973 a=mid:foo 1974 a=bundle-only 1975 a=rtpmap:0 PCMU/8000 1976 a=rtpmap:8 PCMA/8000 1977 a=rtpmap:97 iLBC/8000 1978 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1979 m=video 0 RTP/AVP 31 32 1980 b=AS:1000 1981 a=mid:bar 1982 a=bundle-only 1983 a=rtpmap:31 H261/90000 1984 a=rtpmap:32 MPV/90000 1985 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1986 m=video 10000 RTP/AVP 66 1987 b=AS:1000 1988 a=mid:zen 1989 a=rtcp-mux 1990 a=rtpmap:66 H261/90000 1991 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1993 SDP Answer (2) 1994 v=0 1995 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1996 s= 1997 c=IN IP6 2001:db8::1 1998 t=0 0 1999 a=group:BUNDLE zen foo bar 2000 m=audio 0 RTP/AVP 0 2001 b=AS:200 2002 a=mid:foo 2003 a=bundle-only 2004 a=rtpmap:0 PCMU/8000 2005 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2006 m=video 0 RTP/AVP 32 2007 b=AS:1000 2008 a=mid:bar 2009 a=bundle-only 2010 a=rtpmap:32 MPV/90000 2011 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2012 m=video 20000 RTP/AVP 66 2013 b=AS:1000 2014 a=mid:zen 2015 a=rtcp-mux 2016 a=rtpmap:66 H261/90000 2017 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2019 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 2021 The example below shows: 2023 o A subsequent offer (the BUNDLE group has been created as part of a 2024 previous offer/answer transaction), in which the offerer moves a 2025 bundled "m=" section, indicated by the "zen" identification-tag, 2026 out of a BUNDLE group, assigns a unique address to the moved "m=" 2027 section, and assigns the previously selected offerer BUNDLE 2028 address:port to another bundled "m=" section, indicated by the 2029 offerer BUNDLE-tag. To every other bundled "m=" section the 2030 offerer assigns a zero port value and includes an SDP 'bundle- 2031 only' attribute. 2033 o An answer, in which the answerer moves the "m=" section out of the 2034 BUNDLE group, assigns a unique address to the moved "m=" section, 2035 and assigns the answerer BUNDLE address:port to the bundled "m=" 2036 section indicated by the answerer BUNDLE-tag. To every other 2037 bundled "m=" section the answerer assigns a zero port value and 2038 includes an SDP 'bundle-only' attribute. 2040 SDP Offer (1) 2042 v=0 2043 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2044 s= 2045 c=IN IP6 2001:db8::3 2046 t=0 0 2047 a=group:BUNDLE foo bar 2048 m=audio 10000 RTP/AVP 0 8 97 2049 b=AS:200 2050 a=mid:foo 2051 a=rtcp-mux 2052 a=rtpmap:0 PCMU/8000 2053 a=rtpmap:8 PCMA/8000 2054 a=rtpmap:97 iLBC/8000 2055 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2056 m=video 0 RTP/AVP 31 32 2057 b=AS:1000 2058 a=mid:bar 2059 a=bundle-only 2060 a=rtpmap:31 H261/90000 2061 a=rtpmap:32 MPV/90000 2062 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2063 m=video 50000 RTP/AVP 66 2064 b=AS:1000 2065 a=mid:zen 2066 a=rtcp-mux 2067 a=rtpmap:66 H261/90000 2069 SDP Answer (2) 2071 v=0 2072 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2073 s= 2074 c=IN IP6 2001:db8::1 2075 t=0 0 2076 a=group:BUNDLE foo bar 2077 m=audio 20000 RTP/AVP 0 2078 b=AS:200 2079 a=mid:foo 2080 a=rtcp-mux 2081 a=rtpmap:0 PCMU/8000 2082 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2083 m=video 0 RTP/AVP 32 2084 b=AS:1000 2085 a=mid:bar 2086 a=bundle-only 2087 a=rtpmap:32 MPV/90000 2088 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2089 m=video 60000 RTP/AVP 66 2090 b=AS:1000 2091 a=mid:zen 2092 a=rtcp-mux 2093 a=rtpmap:66 H261/90000 2095 18.5. Example: Offerer Disables a Media Description Within a BUNDLE 2096 Group 2098 The example below shows: 2100 o A subsequent offer (the BUNDLE group has been created as part of a 2101 previous offer/answer transaction), in which the offerer disables 2102 a bundled "m=" section indicated by the "zen" identification-tag, 2103 within a BUNDLE group, assigns a zero port number to the disabled 2104 "m=" section, and assigns the offerer BUNDLE address:port to 2105 another bundled "m=" section, indicated by the offerer BUNDLE-tag. 2106 To every other bundled "m=" section the offerer assigns a zero 2107 port value and includes an SDP 'bundle-only' attribute. 2109 o An answer, in which the answerer moves the disabled "m=" sections 2110 out of the BUNDLE group, assigns a zero port value to the disabled 2111 "m=" section, and assigns the answerer BUNDLE address:port to the 2112 bundled "m=" section indicated by the answerer BUNDLE-tag. To 2113 every other bundled "m=" section the answerer assigns a zero port 2114 value and includes an SDP 'bundle-only' attribute. 2116 SDP Offer (1) 2118 v=0 2119 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2120 s= 2121 t=0 0 2122 a=group:BUNDLE foo bar 2123 m=audio 10000 RTP/AVP 0 8 97 2124 c=IN IP6 2001:db8::3 2125 b=AS:200 2126 a=mid:foo 2127 a=rtcp-mux 2128 a=rtpmap:0 PCMU/8000 2129 a=rtpmap:8 PCMA/8000 2130 a=rtpmap:97 iLBC/8000 2131 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2132 m=video 0 RTP/AVP 31 32 2133 c=IN IP6 2001:db8::3 2134 b=AS:1000 2135 a=mid:bar 2136 a=bundle-only 2137 a=rtpmap:31 H261/90000 2138 a=rtpmap:32 MPV/90000 2139 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2140 m=video 0 RTP/AVP 66 2141 a=mid:zen 2142 a=rtpmap:66 H261/90000 2144 SDP Answer (2) 2146 v=0 2147 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2148 s= 2149 t=0 0 2150 a=group:BUNDLE foo bar 2151 m=audio 20000 RTP/AVP 0 2152 c=IN IP6 2001:db8::1 2153 b=AS:200 2154 a=mid:foo 2155 a=rtcp-mux 2156 a=rtpmap:0 PCMU/8000 2157 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2158 m=video 0 RTP/AVP 32 2159 c=IN IP6 2001:db8::1 2160 b=AS:1000 2161 a=mid:bar 2162 a=bundle-only 2163 a=rtpmap:32 MPV/90000 2164 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 19. Acknowledgements 2171 The usage of the SDP grouping extension for negotiating bundled media 2172 is based on similar alternatives proposed by Harald Alvestrand and 2173 Cullen Jennings. The BUNDLE extension described in this document is 2174 based on the different alternative proposals, and text (e.g., SDP 2175 examples) have been borrowed (and, in some cases, modified) from 2176 those alternative proposals. 2178 The SDP examples are also modified versions from the ones in the 2179 Alvestrand proposal. 2181 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 2182 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 2183 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin 2184 Uberti, Taylor Brandstetter, Byron Campen and Eric Rescorla for 2185 reading the text, and providing useful feedback. 2187 Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus 2188 Westerlund for providing the text for the section on RTP/RTCP stream 2189 association. 2191 Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for 2192 providing help and text on the RTP/RTCP procedures. 2194 Thanks to Spotify for providing music for the countless hours of 2195 document editing. 2197 20. Change Log 2199 [RFC EDITOR NOTE: Please remove this section when publishing] 2201 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-47 2203 o Changes based on AD review by Ben Campbell. 2205 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-46 2207 o Pre-RFC5378 disclaimer removed put back. 2209 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-45 2211 o Mux category for SDP 'group:BUNDLE' attribute added. 2213 o https://github.com/cdh4u/draft-sdp-bundle/pull/54 2215 o Pre-RFC5378 disclaimer removed. 2217 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-44 2219 o Minor editorial nits based on pull request by Colin P. 2221 o https://github.com/cdh4u/draft-sdp-bundle/pull/53 2223 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-43 2225 o Changes based on WG chairs review. 2227 o Text added in order to close GitHub issues by Taylor B. 2229 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-42 2231 o Changes based on final WG review. 2233 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-41 2235 o Update to section 6 o RFC 3264: 2237 o https://github.com/cdh4u/draft-sdp-bundle/pull/47 2239 o Editorial clarification on BUNDLE address selection: 2241 o https://github.com/cdh4u/draft-sdp-bundle/pull/46 2243 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40 2245 o Editorial changes and technical restrictions in order to make the 2246 specification more understandable: 2248 o https://github.com/cdh4u/draft-sdp-bundle/pull/45 2250 o - BUNDLE address is only assigned to m- section indicated by 2251 BUNDLE-tag. 2253 o - bundle-only attribute also used in answers and subsequent 2254 offers. 2256 o - Answerer cannot reject, or remove, the bundled m- section that 2257 contains the BUNDLE address. 2259 o - ICE Offer/Answer sections removed, due to duplicated 2260 information. 2262 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39 2264 o Editorial terminology changes. 2266 o RFC 5285 reference replaced by reference to RFC 8285. 2268 o https://github.com/cdh4u/draft-sdp-bundle/pull/44 2270 o - Clarify that an m- section can not be moved between BUNDLE 2271 groups without first moving the m- section out of a BUNDLE group. 2273 o https://github.com/cdh4u/draft-sdp-bundle/pull/41 2274 o - Addition of BUNDLE transport concept. 2276 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38 2278 o Changes to RTP streaming mapping section based on text from Colin 2279 Perkins. 2281 o The following GitHub pull requests were merged: 2283 o https://github.com/cdh4u/draft-sdp-bundle/pull/34 2285 o - Proposed updates to RTP processing 2287 o https://github.com/cdh4u/draft-sdp-bundle/pull/35 2289 o - fixed reference to receiver-id section 2291 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-37 2293 o The following GitHub pull request was merged: 2295 o https://github.com/cdh4u/draft-sdp-bundle/pull/33 2297 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36 2299 o The following GitHub pull requests were merged: 2301 o https://github.com/cdh4u/draft-sdp-bundle/pull/32 2303 o - extmap handling in BUNDLE. 2305 o https://github.com/cdh4u/draft-sdp-bundle/pull/31 2307 o - Additional Acknowledgement text added. 2309 o https://github.com/cdh4u/draft-sdp-bundle/pull/30 2311 o - MID SDES item security procedures updated 2313 o https://github.com/cdh4u/draft-sdp-bundle/pull/29 2315 o - Appendix B of JSEP moved into BUNDLE. 2317 o - Associating RTP/RTCP packets with SDP m- lines. 2319 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35 2320 o Editorial changes on RTP streaming mapping section based on 2321 comments from Colin Perkins. 2323 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34 2325 o RTP streams, instead of RTP packets, are associated with m- lines. 2327 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 2329 o Editorial changes based on comments from Eric Rescorla and Cullen 2330 Jennings: 2332 o - Changes regarding usage of RTP/RTCP multiplexing attributes. 2334 o - Additional text regarding associating RTP/RTCP packets with SDP 2335 m- lines. 2337 o - Reference correction. 2339 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32 2341 o Editorial changes based on comments from Eric Rescorla and Cullen 2342 Jennings: 2344 o - Justification for mechanism added to Introduction. 2346 o - Clarify that the order of m- lines in the group:BUNDLE attribute 2347 does not have to be the same as the order in which the m- lines 2348 are listed in the SDP. 2350 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31 2352 o Editorial changes based on GitHub Pull requests by Martin Thomson: 2354 o - https://github.com/cdh4u/draft-sdp-bundle/pull/2 2356 o - https://github.com/cdh4u/draft-sdp-bundle/pull/1 2358 o Editorial change based on comment from Diederick Huijbers (9th 2359 July 2016). 2361 o Changes based on comments from Flemming Andreasen (21st June 2362 2016): 2364 o - Mux category for SDP bundle-only attribute added. 2366 o - Mux category considerations editorial clarification. 2368 o - Editorial changes. 2370 o RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext. 2372 o Note whether Design Considerations appendix is to be kept removed: 2374 o - Appendix is kept within document. 2376 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30 2378 o Indicating in the Abstract and Introduction that the document 2379 updates RFC 3264. 2381 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29 2383 o Change based on WGLC comment from Colin Perkins. 2385 o - Clarify that SSRC can be reused by another source after a delay 2386 of 5 RTCP reporting intervals. 2388 o Change based on WGLC comment from Alissa Cooper. 2390 o - IANA registry name fix. 2392 o - Additional IANA registration information added. 2394 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28 2396 o - Alignment with exclusive mux procedures. 2398 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 2400 o - Yet another terminology change. 2402 o - Mux category considerations added. 2404 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 2406 o - ICE considerations modified: ICE-related SDP attributes only 2407 added to the bundled m- line representing the selected BUNDLE 2408 address. 2410 o - Reference to draft-ietf-mmusic-ice-sip-sdp added. 2412 o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- 2413 rfc5245bis. 2415 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 2416 o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux 2417 considerations. 2419 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 2421 o - Reference and procedures associated with exclusive RTP/RTCP mux 2422 added 2424 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 2426 o - RTCP-MUX mandatory for bundled RTP m- lines 2428 o - Editorial fixes based on comments from Flemming Andreasen 2430 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 2432 o - Correction of Ari's family name 2434 o - Editorial fixes based on comments from Thomas Stach 2436 o - RTP/RTCP correction based on comment from Magnus Westerlund 2438 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2439 msg14861.html 2441 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 2443 o - Correct based on comment from Paul Kyzivat 2445 o -- 'received packets' replaced with 'received data' 2447 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 2449 o - Clarification based on comment from James Guballa 2451 o - Clarification based on comment from Flemming Andreasen 2453 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 2455 o - DTLS Considerations section added. 2457 o - BUNDLE semantics added to the IANA Considerations 2459 o - Changes based on WGLC comments from Adam Roach 2461 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2462 msg14673.html 2464 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 2466 o - Changes based on agreements at IETF#92 2468 o -- BAS Offer removed, based on agreement at IETF#92. 2470 o -- Procedures regarding usage of SDP "b=" line is replaced with a 2471 reference to to draft-ietf-mmusic-sdp-mux-attributes. 2473 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 2475 o - Editorial changes based on comments from Magnus Westerlund. 2477 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 2479 o - Modification of RTP/RTCP multiplexing section, based on comments 2480 from Magnus Westerlund. 2482 o - Reference updates. 2484 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 2486 o - Editorial fix. 2488 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 2490 o - Editorial changes. 2492 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 2494 o Changes to allow a newly suggested offerer BUNDLE address to be 2495 assigned to each bundled m- line. 2497 o Changes based on WGLC comments from Paul Kyzivat 2499 o - Editorial fixes 2501 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 2503 o Usage of SDP 'extmap' attribute added 2505 o SDP 'bundle-only' attribute scoped with "m=" lines with a zero 2506 port value 2508 o Changes based on WGLC comments from Thomas Stach 2510 o - ICE candidates not assigned to bundle-only m- lines with a zero 2511 port value 2513 o - Editorial changes 2515 o Changes based on WGLC comments from Colin Perkins 2517 o - Editorial changes: 2519 o -- "RTP SDES item" -> "RTCP SDES item" 2521 o -- "RTP MID SDES item" -> "RTCP MID SDES item" 2523 o - Changes in section 10.1.1: 2525 o -- "SHOULD NOT" -> "MUST NOT" 2527 o -- Additional text added to the Note 2529 o - Change to section 13.2: 2531 o -- Clarify that mid value is not zero terminated 2533 o - Change to section 13.3: 2535 o -- Clarify that mid value is not zero terminated 2537 o -- Clarify padding 2539 o Changes based on WGLC comments from Paul Kyzivat 2541 o - Editorial changes: 2543 o Changes based on WGLC comments from Jonathan Lennox 2545 o - Editorial changes: 2547 o - Defintion of SDP bundle-only attribute alligned with structure 2548 in 4566bis draft 2550 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 2552 o Editorial corrections based on comments from Harald Alvestrand. 2554 o Editorial corrections based on comments from Cullen Jennings. 2556 o Reference update (RFC 7160). 2558 o Clarification about RTCP packet sending when RTP/RTCP multiplexing 2559 is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ 2560 msg13765.html). 2562 o Additional text added to the Security Considerations. 2564 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 2566 o SDP bundle-only attribute added to IANA Considerations. 2568 o SDES item and RTP header extension added to Abstract and 2569 Introduction. 2571 o Modification to text updating section 8.2 of RFC 3264. 2573 o Reference corrections. 2575 o Editorial corrections. 2577 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 2579 o Terminology change: "bundle-only attribute assigned to m= line" to 2580 "bundle-only attribute associated with m= line". 2582 o Editorial corrections. 2584 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 2586 o Editorial corrections. 2588 o - "of"->"if" (8.3.2.5). 2590 o - "optional"->"OPTIONAL" (9.1). 2592 o - Syntax/ABNF for 'bundle-only' attribute added. 2594 o - SDP Offer/Answer sections merged. 2596 o - 'Request new offerer BUNDLE address' section added 2598 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 2600 o OPEN ISSUE regarding Receiver-ID closed. 2602 o - RTP MID SDES Item. 2604 o - RTP MID Header Extension. 2606 o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers 2607 closed. 2609 o - Indicating that, when rtcp-mux is used, the answerer MUST NOT 2610 include an 'rtcp' attribute in the answer, based on the procedures 2611 in section 5.1.3 of RFC 5761. 2613 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 2615 o Draft title changed. 2617 o Added "SDP" to section names containing "Offer" or "Answer". 2619 o Editorial fixes based on comments from Paul Kyzivat 2620 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2621 msg13314.html). 2623 o Editorial fixed based on comments from Colin Perkins 2624 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2625 msg13318.html). 2627 o - Removed text about extending BUNDLE to allow multiple RTP 2628 sessions within a BUNDLE group. 2630 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 2632 o Major re-structure of SDP Offer/Answer sections, to align with RFC 2633 3264 structure. 2635 o Additional definitions added. 2637 o - Shared address. 2639 o - Bundled "m=" line. 2641 o - Bundle-only "m=" line. 2643 o - Offerer suggested BUNDLE mid. 2645 o - Answerer selected BUNDLE mid. 2647 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 2648 to multiple "m=" lines until it has received an SDP Answer 2649 indicating support of the BUNDLE extension. 2651 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 2652 Answerer supports the BUNDLE extension, assign a zero port value 2653 to a 'bundle-only' "m=" line. 2655 o SDP 'bundle-only' attribute section added. 2657 o Connection data nettype/addrtype restrictions added. 2659 o RFC 3264 update section added. 2661 o Indicating that a specific payload type value can be used in 2662 multiple "m=" lines, if the value represents the same codec 2663 configuration in each "m=" line. 2665 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 2667 o Updated Offerer procedures (http://www.ietf.org/mail- 2668 archive/web/mmusic/current/msg12293.html). 2670 o Updated Answerer procedures (http://www.ietf.org/mail- 2671 archive/web/mmusic/current/msg12333.html). 2673 o Usage of SDP 'bundle-only' attribute added. 2675 o Reference to Trickle ICE document added. 2677 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 2679 o Mechanism modified, to be based on usage of SDP Offers with both 2680 different and identical port number values, depending on whether 2681 it is known if the remote endpoint supports the extension. 2683 o Cullen Jennings added as co-author. 2685 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 2687 o No changes. New version due to expiration. 2689 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 2691 o No changes. New version due to expiration. 2693 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 2695 o Draft name changed. 2697 o Harald Alvestrand added as co-author. 2699 o "Multiplex" terminology changed to "bundle". 2701 o Added text about single versus multiple RTP Sessions. 2703 o Added reference to RFC 3550. 2705 21. References 2707 21.1. Normative References 2709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2710 Requirement Levels", BCP 14, RFC 2119, 2711 DOI 10.17487/RFC2119, March 1997, 2712 . 2714 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2715 with Session Description Protocol (SDP)", RFC 3264, 2716 DOI 10.17487/RFC3264, June 2002, 2717 . 2719 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2720 Jacobson, "RTP: A Transport Protocol for Real-Time 2721 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2722 July 2003, . 2724 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2725 in Session Description Protocol (SDP)", RFC 3605, 2726 DOI 10.17487/RFC3605, October 2003, 2727 . 2729 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2730 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2731 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2732 . 2734 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2735 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2736 July 2006, . 2738 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2739 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2740 . 2742 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2743 Control Packets on a Single Port", RFC 5761, 2744 DOI 10.17487/RFC5761, April 2010, 2745 . 2747 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2748 Security (DTLS) Extension to Establish Keys for the Secure 2749 Real-time Transport Protocol (SRTP)", RFC 5764, 2750 DOI 10.17487/RFC5764, May 2010, 2751 . 2753 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2754 Protocol (SDP) Grouping Framework", RFC 5888, 2755 DOI 10.17487/RFC5888, June 2010, 2756 . 2758 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2759 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2760 January 2012, . 2762 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2763 Header Extension for the RTP Control Protocol (RTCP) 2764 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2765 August 2016, . 2767 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 2768 Mechanism for RTP Header Extensions", RFC 8285, 2769 DOI 10.17487/RFC8285, October 2017, 2770 . 2772 [I-D.ietf-ice-rfc5245bis] 2773 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2774 Connectivity Establishment (ICE): A Protocol for Network 2775 Address Translator (NAT) Traversal", draft-ietf-ice- 2776 rfc5245bis-16 (work in progress), January 2018. 2778 [I-D.ietf-mmusic-sdp-mux-attributes] 2779 Nandakumar, S., "A Framework for SDP Attributes when 2780 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 2781 (work in progress), December 2016. 2783 [I-D.ietf-mmusic-mux-exclusive] 2784 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 2785 Multiplexing using SDP", draft-ietf-mmusic-mux- 2786 exclusive-12 (work in progress), May 2017. 2788 [I-D.ietf-mmusic-ice-sip-sdp] 2789 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, 2790 "Session Description Protocol (SDP) Offer/Answer 2791 procedures for Interactive Connectivity Establishment 2792 (ICE)", draft-ietf-mmusic-ice-sip-sdp-16 (work in 2793 progress), November 2017. 2795 21.2. Informative References 2797 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2798 A., Peterson, J., Sparks, R., Handley, M., and E. 2799 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2800 DOI 10.17487/RFC3261, June 2002, 2801 . 2803 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2804 "RTP Control Protocol Extended Reports (RTCP XR)", 2805 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2806 . 2808 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2809 "Codec Control Messages in the RTP Audio-Visual Profile 2810 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 2811 February 2008, . 2813 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2814 "Extended RTP Profile for Real-time Transport Control 2815 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2816 DOI 10.17487/RFC4585, July 2006, 2817 . 2819 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2820 Media Attributes in the Session Description Protocol 2821 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2822 . 2824 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2825 Clock Rates in an RTP Session", RFC 7160, 2826 DOI 10.17487/RFC7160, April 2014, 2827 . 2829 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2830 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2831 . 2833 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2834 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2835 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2836 DOI 10.17487/RFC7656, November 2015, 2837 . 2839 [I-D.ietf-ice-trickle] 2840 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 2841 "Trickle ICE: Incremental Provisioning of Candidates for 2842 the Interactive Connectivity Establishment (ICE) 2843 Protocol", draft-ietf-ice-trickle-15 (work in progress), 2844 November 2017. 2846 [I-D.ietf-avtext-lrr] 2847 Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 2848 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 2849 Message", draft-ietf-avtext-lrr-07 (work in progress), 2850 July 2017. 2852 Appendix A. Design Considerations 2854 One of the main issues regarding the BUNDLE grouping extensions has 2855 been whether, in SDP Offers and SDP Answers, the same port value can 2856 be inserted in "m=" lines associated with a BUNDLE group, as the 2857 purpose of the extension is to negotiate the usage of a single 2858 transport for media specified by the "m=" sections. Issues with both 2859 approaches, discussed in the Appendix have been raised. The outcome 2860 was to specify a mechanism which uses SDP Offers with both different 2861 and identical port values. 2863 Below are the primary issues that have been considered when defining 2864 the "BUNDLE" grouping extension: 2866 o 1) Interoperability with existing UAs. 2868 o 2) Interoperability with intermediary Back to Back User Agent 2869 (B2BUA) and proxy entities. 2871 o 3) Time to gather, and the number of, ICE candidates. 2873 o 4) Different error scenarios, and when they occur. 2875 o 5) SDP Offer/Answer impacts, including usage of port number value 2876 zero. 2878 A.1. UA Interoperability 2880 Consider the following SDP Offer/Answer exchange, where Alice sends 2881 an SDP Offer to Bob: 2883 SDP Offer 2885 v=0 2886 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2887 s= 2888 c=IN IP4 atlanta.example.com 2889 t=0 0 2890 m=audio 10000 RTP/AVP 97 2891 a=rtpmap:97 iLBC/8000 2892 m=video 10002 RTP/AVP 97 2893 a=rtpmap:97 H261/90000 2895 SDP Answer 2897 v=0 2898 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2899 s= 2900 c=IN IP4 biloxi.example.com 2901 t=0 0 2902 m=audio 20000 RTP/AVP 97 2903 a=rtpmap:97 iLBC/8000 2904 m=video 20002 RTP/AVP 97 2905 a=rtpmap:97 H261/90000 2907 RFC 4961 specifies a way of doing symmetric RTP but that is a later 2908 extension to RTP and Bob can not assume that Alice supports RFC 4961. 2909 This means that Alice may be sending RTP from a different port than 2910 10000 or 10002 - some implementations simply send the RTP from an 2911 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2912 way that Bob knows if the packet is to be passed to the video or 2913 audio codec is by looking at the port it was received on. This led 2914 some SDP implementations to use the fact that each "m=" section had a 2915 different port number to use that port number as an index to find the 2916 correct m line in the SDP. As a result, some implementations that do 2917 support symmetric RTP and ICE still use an SDP data structure where 2918 SDP with "m=" sections with the same port such as: 2920 SDP Offer 2922 v=0 2923 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2924 s= 2925 c=IN IP4 atlanta.example.com 2926 t=0 0 2927 m=audio 10000 RTP/AVP 97 2928 a=rtpmap:97 iLBC/8000 2929 m=video 10000 RTP/AVP 98 2930 a=rtpmap:98 H261/90000 2932 will result in the second "m=" section being considered an SDP error 2933 because it has the same port as the first line. 2935 A.2. Usage of Port Number Value Zero 2937 In an SDP Offer or SDP Answer, the media specified by an "m=" section 2938 can be disabled/rejected by setting the port number value to zero. 2939 This is different from e.g., using the SDP direction attributes, 2940 where RTCP traffic will continue even if the SDP "inactive" attribute 2941 is indicated for the associated "m=" section. 2943 If each "m=" section associated with a BUNDLE group would contain 2944 different port values, and one of those port values would be used for 2945 a BUNDLE address:port associated with the BUNDLE group, problems 2946 would occur if an endpoint wants to disable/reject the "m=" section 2947 associated with that port, by setting the port value to zero. After 2948 that, no "m=" section would contain the port value which is used for 2949 the BUNDLE address:port. In addition, it is unclear what would 2950 happen to the ICE candidates associated with the "m=" section, as 2951 they are also used for the BUNDLE address:port. 2953 A.3. B2BUA And Proxy Interoperability 2955 Some back to back user agents may be configured in a mode where if 2956 the incoming call leg contains an SDP attribute the B2BUA does not 2957 understand, the B2BUA still generates that SDP attribute in the Offer 2958 for the outgoing call leg. Consider a B2BUA that did not understand 2959 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 2960 Further assume that the B2BUA was configured to tear down any call 2961 where it did not see any RTCP for 5 minutes. In this case, if the 2962 B2BUA received an Offer like: 2964 SDP Offer 2966 v=0 2967 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2968 s= 2969 c=IN IP4 atlanta.example.com 2970 t=0 0 2971 m=audio 49170 RTP/AVP 0 2972 a=rtcp:53020 2974 It would be looking for RTCP on port 49171 but would not see any 2975 because the RTCP would be on port 53020 and after five minutes, it 2976 would tear down the call. Similarly, a B2BUA that did not understand 2977 BUNDLE yet put BUNDLE in its offer may be looking for media on the 2978 wrong port and tear down the call. It is worth noting that a B2BUA 2979 that generated an Offer with capabilities it does not understand is 2980 not compliant with the specifications. 2982 A.3.1. Traffic Policing 2984 Sometimes intermediaries do not act as B2BUAs, in the sense that they 2985 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2986 however, they may use SDP information (e.g., IP address and port) in 2987 order to control traffic gating functions, and to set traffic 2988 policing rules. There might be rules which will trigger a session to 2989 be terminated in case media is not sent or received on the ports 2990 retrieved from the SDP. This typically occurs once the session is 2991 already established and ongoing. 2993 A.3.2. Bandwidth Allocation 2995 Sometimes intermediaries do not act as B2BUAs, in the sense that they 2996 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2997 however, they may use SDP information (e.g., codecs and media types) 2998 in order to control bandwidth allocation functions. The bandwidth 2999 allocation is done per "m=" section, which means that it might not be 3000 enough if media specified by all "m=" sections try to use that 3001 bandwidth. That may either simply lead to bad user experience, or to 3002 termination of the call. 3004 A.4. Candidate Gathering 3006 When using ICE, a candidate needs to be gathered for each port. This 3007 takes approximately 20 ms extra for each extra "m=" section due to 3008 the NAT pacing requirements. All of this gathering can be overlapped 3009 with other things while e.g., a web-page is loading to minimize the 3010 impact. If the client only wants to generate TURN or STUN ICE 3011 candidates for one of the "m=" lines and then use trickle ICE 3012 [I-D.ietf-ice-trickle] to get the non host ICE candidates for the 3013 rest of the "m=" sections, it MAY do that and will not need any 3014 additional gathering time. 3016 Some people have suggested a TURN extension to get a bunch of TURN 3017 allocations at once. This would only provide a single STUN result so 3018 in cases where the other end did not support BUNDLE, it may cause 3019 more use of the TURN server but would be quick in the cases where 3020 both sides supported BUNDLE and would fall back to a successful call 3021 in the other cases. 3023 Authors' Addresses 3025 Christer Holmberg 3026 Ericsson 3027 Hirsalantie 11 3028 Jorvas 02420 3029 Finland 3031 Email: christer.holmberg@ericsson.com 3033 Harald Tveit Alvestrand 3034 Google 3035 Kungsbron 2 3036 Stockholm 11122 3037 Sweden 3039 Email: harald@alvestrand.no 3041 Cullen Jennings 3042 Cisco 3043 400 3rd Avenue SW, Suite 350 3044 Calgary, AB T2P 4H2 3045 Canada 3047 Email: fluffy@iii.ca