idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-49.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 (March 3, 2018) is 2246 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 1588 == Missing Reference: 'RFCXXXX' is mentioned on line 1772, 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-18 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-17 == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-16 == Outdated reference: A later version (-21) exists of draft-ietf-ice-trickle-17 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: September 4, 2018 C. Jennings 7 Cisco 8 March 3, 2018 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-49.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 can 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 September 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 . . . . . . . . . . . . . . . . . 62 150 Appendix A. Design Considerations . . . . . . . . . . . . . . . 63 151 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 64 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:port 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:port: An address:port combination that is assigned 244 to 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 451 address:port is assigned to each bundled "m=" section (excluding any 452 bundle-only "m=" section) in the initial offer [Section 8.2], any 453 IDENTICAL and TRANSPORT mux category SDP attributes included in the 454 BUNDLE group MUST explicitly be included in each bundled 455 "m=a€œ section (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:port to each "m=" section within the 483 offer, following the procedures in [RFC3264], excluding any 484 bundle-only "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:port the offerer suggests as the 492 offerer 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:ports to multiple 509 bundled "m=" sections, the offerer needs to be prepared to receive 510 bundled media on each unique address:port, until it receives the 511 associated answer and finds out which address:port combination has 512 been selected as the 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:port (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:port 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:port 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:port to one or 1400 more bundled "m=" sections (excluding any bundle-only "m=" 1401 sections), the offerer MUST include ICE-related media-level 1402 attributes in each of those "m=" sections. If the offerer assigns 1403 an offerer BUNDLE address:port (previously selected 1404 [Section 8.3.1] or newly suggested [Section 8.5.1]) to a bundled 1405 "m=" section (the "m=" section indicated by the offerer BUNDLE- 1406 tag), the offerer only includes ICE-related media-level SDP 1407 attributes in that "m=" section, following the procedures in 1408 Section 8.1. 1410 o In an answer, the answerer only includes ICE-related media-level 1411 SDP attributes in the bundled "m=" section to which the answerer 1412 has assigned the answerer BUNDLE address:port (the "m=" section 1413 indicated by the answerer BUNDLE-tag), following the procedures in 1414 Section 8.1. 1416 Initially, before ICE has produced a candidate pair that will be used 1417 for media, there might be multiple transports established (if 1418 multiple candidate pairs are tested). Once ICE has produced a 1419 transport that will be used for media, that becomes the BUNDLE 1420 transport. 1422 Support and usage of ICE mechanism together with the BUNDLE extension 1423 is OPTIONAL, and the procedures in this section only apply when the 1424 ICE mechanism is used. Note that applications might mandate usage of 1425 the ICE mechanism even if the BUNDLE extension is not used. 1427 11.1. SDP Offer/Answer Procedures 1429 When an offerer assigns a unique address:port to one or more bundled 1430 "m=" sections (excluding any bundle-only "m=" section), the offerer 1431 MUST include SDP 'candidate' attributes (and other applicable ICE- 1432 related media-level SDP attributes), containing unique ICE properties 1433 (candidates etc), in each of those "m=" sections, following the 1434 procedures in [I-D.ietf-mmusic-ice-sip-sdp]. 1436 When an offerer assigns a BUNDLE address:port (previously selected or 1437 newly suggested) to a bundled "m=" section, (the "m=" section 1438 indicated by the offerer BUNDLE-tag) the offerer MUST only include 1439 SDP 'candidate' attributes (and other applicable ICE-related media- 1440 level SDP attributes) in that "m=" section, following the procedures 1441 in Section 8.1. 1443 When an answerer assigns a BUNDLE address to an "m=" section within a 1444 BUNDLE group (the "m=" section represented by the answerer BUNDLE- 1445 tag), the answerer onlys include SDP 'candidate' attributes (and 1446 other applicable ICE-related media-level SDP attributes) in that "m=" 1447 section, following the procedures in Section 8.1. The answerer MUST 1448 NOT include ICE-related media-level SDP attributes in any other "m=" 1449 sections. 1451 NOTE: As most ICE-related media-level SDP attributes belong to the 1452 TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the 1453 offerer and answerer follow the procedures in Section 8.1 when 1454 deciding whether to include an attribute in a bundled "m=" section. 1455 However, in the case of ICE-related media-level attributes, the rules 1456 apply to all attributes (see note below), even if they belong to a 1457 different mux category. 1459 NOTE: The following ICE-related media-level SDP attributes are 1460 defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidate', 'remote- 1461 candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- 1462 pacing'. 1464 12. DTLS Considerations 1466 One or more media streams within a BUNDLE group might use the 1467 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1468 to encrypt the data, or to negotiate encryption keys if another 1469 encryption mechanism is used to encrypt media. 1471 When DTLS is used within a BUNDLE group, the following rules apply: 1473 o There can only be one DTLS association [RFC6347] associated with 1474 the BUNDLE group; and 1476 o Each usage of the DTLS association within the BUNDLE group MUST 1477 use the same mechanism for determining which endpoints (the 1478 offerer or answerer) become DTLS client and DTLS server; and 1480 o Each usage of the DTLS association within the BUNDLE group MUST 1481 use the same mechanism for determining whether an offer or answer 1482 will trigger the establishment of a new DTLS association, or 1483 whether an existing DTLS association will be used; and 1485 o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include 1486 the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message 1487 [RFC5764]. The client MUST include the extension even if the 1488 usage of DTLS-SRTP is not negotiated as part of the multimedia 1489 session (e.g., SIP session [RFC3261]. 1491 NOTE: The inclusion of the 'use_srtp' extension during the initial 1492 DTLS handshake ensures that a DTLS renegotiation will not be required 1493 in order to include the extension, in case DTLS-SRTP encrypted media 1494 is added to the BUNDLE group later during the multimedia session. 1496 13. RTP Header Extensions Consideration 1498 When [RFC8285] RTP header extensions are used in the context of this 1499 specification, the identifier used for a given extension MUST 1500 identify the same extension across all the bundled media 1501 descriptions. 1503 14. Update to RFC 3264 1505 This section updates RFC 3264, in order to allow extensions to define 1506 the usage of a zero port value in offers and answers for other 1507 purposes than removing or disabling media streams. The following 1508 sections of RFC 3264 are updated: 1510 o Section 5.1 (Unicast Streams). 1512 o Section 6 (Generating the Answer). 1514 o Section 8.4 (Putting a Unicast Media Stream on Hold). 1516 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 1518 For recvonly and sendrecv streams, the port number and address in the 1519 offer indicate where the offerer would like to receive the media 1520 stream. For sendonly RTP streams, the address and port number 1521 indirectly indicate where the offerer wants to receive RTCP reports. 1522 Unless there is an explicit indication otherwise, reports are sent to 1523 the port number one higher than the number indicated. The IP address 1524 and port present in the offer indicate nothing about the source IP 1525 address and source port of RTP and RTCP packets that will be sent by 1526 the offerer. A port number of zero in the offer indicates that the 1527 stream is offered but MUST NOT be used. This has no useful semantics 1528 in an initial offer, but is allowed for reasons of completeness, 1529 since the answer can contain a zero port indicating a rejected stream 1530 (Section 6). Furthermore, existing streams can be terminated by 1531 setting the port to zero (Section 8). In general, a port number of 1532 zero indicates that the media stream is not wanted. 1534 14.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 1536 For recvonly and sendrecv streams, the port number and address in the 1537 offer indicate where the offerer would like to receive the media 1538 stream. For sendonly RTP streams, the address and port number 1539 indirectly indicate where the offerer wants to receive RTCP reports. 1540 Unless there is an explicit indication otherwise, reports are sent to 1541 the port number one higher than the number indicated. The IP address 1542 and port present in the offer indicate nothing about the source IP 1543 address and source port of RTP and RTCP packets that will be sent by 1544 the offerer. A port number of zero in the offer by default indicates 1545 that the stream is offered but MUST NOT be used, but an extension 1546 mechanism might specify different semantics for the usage of a zero 1547 port value. Furthermore, existing streams can be terminated by 1548 setting the port to zero (Section 8). In general, a port number of 1549 zero by default indicates that the media stream is not wanted. 1551 14.3. Original text of section 6 (4th paragraph) of RFC 3264 1553 An offered stream MAY be rejected in the answer, for any reason. If 1554 a stream is rejected, the offerer and answerer MUST NOT generate 1555 media (or RTCP packets) for that stream. To reject an offered 1556 stream, the port number in the corresponding stream in the answer 1557 MUST be set to zero. Any media formats listed are ignored. At least 1558 one MUST be present, as specified by SDP. 1560 14.4. New text replacing section 6 (4th paragraph) of RFC 3264 1562 An offered stream MAY be rejected in the answer, for any reason. If 1563 a stream is rejected, the offerer and answerer MUST NOT generate 1564 media (or RTCP packets) for that stream. A port number of zero in 1565 the answer by default indicates that the offered stream is rejected, 1566 but an extension mechanism might specify different semantics for the 1567 usage of a zero port value. If a stream is rejected, any media 1568 formats listed are ignored. At least one MUST be present, as 1569 specified by SDP. 1571 14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 1573 RFC 2543 [10] specified that placing a user on hold was accomplished 1574 by setting the connection address to 0.0.0.0. Its usage for putting 1575 a call on hold is no longer recommended, since it doesn't allow for 1576 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1577 with connection oriented media. However, it can be useful in an 1578 initial offer when the offerer knows it wants to use a particular set 1579 of media streams and formats, but doesn't know the addresses and 1580 ports at the time of the offer. Of course, when used, the port 1581 number MUST NOT be zero, which would specify that the stream has been 1582 disabled. An agent MUST be capable of receiving SDP with a 1583 connection address of 0.0.0.0, in which case it means that neither 1584 RTP nor RTCP is to be sent to the peer. 1586 14.6. New text replacing section 8.4 (6th paragraph) of RFC 3264 1588 RFC 2543 [10] specified that placing a user on hold was accomplished 1589 by setting the connection address to 0.0.0.0. Its usage for putting 1590 a call on hold is no longer recommended, since it doesn't allow for 1591 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1592 with connection oriented media. However, it can be useful in an 1593 initial offer when the offerer knows it wants to use a particular set 1594 of media streams and formats, but doesn't know the addresses and 1595 ports at the time of the offer. Of course, when used, the port 1596 number MUST NOT be zero, if it would specify that the stream has been 1597 disabled. However, an extension mechanism might specify different 1598 semantics of the zero port number usage. An agent MUST be capable of 1599 receiving SDP with a connection address of 0.0.0.0, in which case it 1600 means that neither RTP nor RTCP is to be sent to the peer. 1602 15. RTP/RTCP extensions for identification-tag transport 1604 SDP Offerers and Answerers [RFC3264] can associate identification- 1605 tags with "m=" sections within SDP Offers and Answers, using the 1606 procedures in [RFC5888]. Each identification-tag uniquely represents 1607 an "m=" section. 1609 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1610 used to carry identification-tags within RTCP SDES packets. This 1611 section also defines a new RTP SDES header extension [RFC7941], which 1612 is used to carry the 'MID' RTCP SDES item in RTP packets. 1614 The SDES item and RTP SDES header extension make it possible for a 1615 receiver to associate each RTP stream with a specific "m=" section, 1616 with which the receiver has associated an identification-tag, even if 1617 those "m=" sections are part of the same RTP session. The RTP SDES 1618 header extension also ensures that the media recipient gets the 1619 identification-tag upon receipt of the first decodable media and is 1620 able to associate the media with the correct application. 1622 A media recipient informs the media sender about the identification- 1623 tag associated with an "m=" section through the use of an 'mid' 1624 attribute [RFC5888]. The media sender then inserts the 1625 identification-tag in RTCP and RTP packets sent to the media 1626 recipient. 1628 NOTE: This text above defines how identification-tags are carried in 1629 SDP Offers and Answers. The usage of other signaling protocols for 1630 carrying identification-tags is not prevented, but the usage of such 1631 protocols is outside the scope of this document. 1633 [RFC3550] defines general procedures regarding the RTCP transmission 1634 interval. The RTCP MID SDES item SHOULD be sent in the first few 1635 RTCP packets sent after joining the session, and SHOULD be sent 1636 regularly thereafter. The exact number of RTCP packets in which this 1637 SDES item is sent is intentionally not specified here, as it will 1638 depend on the expected packet loss rate, the RTCP reporting interval, 1639 and the allowable overhead. 1641 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1642 be included in some RTP packets at the start of the session and 1643 whenever the SSRC changes. It might also be useful to include the 1644 header extension in RTP packets that comprise access points in the 1645 media (e.g., with video I-frames). The exact number of RTP packets 1646 in which this header extension is sent is intentionally not specified 1647 here, as it will depend on expected packet loss rate and loss 1648 patterns, the overhead the application can tolerate, and the 1649 importance of immediate receipt of the identification-tag. 1651 For robustness, endpoints need to be prepared for situations where 1652 the reception of the identification-tag is delayed, and SHOULD NOT 1653 terminate sessions in such cases, as the identification-tag is likely 1654 to arrive soon. 1656 15.1. RTCP MID SDES Item 1658 0 1 2 3 1659 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 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 | MID=TBD | length | identification-tag ... 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 The identification-tag payload is UTF-8 encoded, as in SDP. 1666 The identification-tag is not zero terminated. 1668 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1669 identifier value.] 1671 15.2. RTP SDES Header Extension For MID 1673 The payload, containing the identification-tag, of the RTP SDES 1674 header extension element can be encoded using either the one-byte or 1675 two-byte header [RFC7941]. The identification-tag payload is UTF-8 1676 encoded, as in SDP. 1678 The identification-tag is not zero terminated. Note, that the set of 1679 header extensions included in the packet needs to be padded to the 1680 next 32-bit boundary using zero bytes [RFC8285]. 1682 As the identification-tag is included in either an RTCP SDES item or 1683 an RTP SDES header extension, or both, there needs to be some 1684 consideration about the packet expansion caused by the 1685 identification-tag. To avoid Maximum Transmission Unit (MTU) issues 1686 for the RTP packets, the header extension's size needs to be taken 1687 into account when encoding the media. 1689 It is recommended that the identification-tag is kept short. Due to 1690 the properties of the RTP header extension mechanism, when using the 1691 one-byte header, a tag that is 1-3 bytes will result in a minimal 1692 number of 32-bit words used for the RTP SDES header extension, in 1693 case no other header extensions are included at the same time. Note, 1694 do take into account that some single characters when UTF-8 encoded 1695 will result in multiple octets. The identification-tag MUST NOT 1696 contain any user information, and applications SHALL avoid generating 1697 the identification-tag using a pattern that enables user- or 1698 application identification. 1700 16. IANA Considerations 1702 16.1. New SDES item 1704 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1705 document.] 1707 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1708 identifier value.] 1710 This document adds the MID SDES item to the IANA "RTP SDES item 1711 types" registry as follows: 1713 Value: TBD 1714 Abbrev.: MID 1715 Name: Media Identification 1716 Reference: RFCXXXX 1718 16.2. New RTP SDES Header Extension URI 1720 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1721 document.] 1723 This document defines a new extension URI in the RTP SDES Compact 1724 Header Extensions sub-registry of the RTP Compact Header Extensions 1725 registry sub-registry, according to the following data: 1727 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1728 Description: Media identification 1729 Contact: IESG (iesg@ietf.org) 1730 Reference: RFCXXXX 1732 The SDES item does not reveal privacy information about the users. 1733 It is simply used to associate RTP-based media with the correct SDP 1734 media description ("m=" section) in the SDP used to negotiate the 1735 media. 1737 The purpose of the extension is for the offerer to be able to 1738 associate received multiplexed RTP-based media before the offerer 1739 receives the associated SDP answer. 1741 16.3. New SDP Attribute 1743 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1744 document.] 1746 This document defines a new SDP media-level attribute, 'bundle-only', 1747 according to the following data: 1749 Attribute name: bundle-only 1750 Type of attribute: media 1751 Subject to charset: No 1752 Purpose: Request a media description to be accepted 1753 in the answer only if kept within a BUNDLE 1754 group by the answerer. 1755 Appropriate values: N/A 1756 Contact name: IESG 1757 Contact e-mail: iesg@ietf.org 1758 Reference: RFCXXXX 1759 Mux category: NORMAL 1761 16.4. New SDP Group Semantics 1763 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1764 document.] 1766 This document registers the following semantics with IANA in the 1767 "Semantics for the "group" SDP Attribute" subregistry (under the 1768 "Session Description Protocol (SDP) Parameters" registry: 1770 Semantics Token Reference 1771 ------------------------------------- ------ --------- 1772 Media bundling BUNDLE [RFCXXXX] 1774 Mux category: NORMAL 1776 17. Security Considerations 1778 The security considerations defined in [RFC3264] and [RFC5888] apply 1779 to the BUNDLE extension. Bundle does not change which information, 1780 e.g., RTP streams, flows over the network, with the exception of the 1781 usage of the MID SDES item as discussed below. Primarily it changes 1782 which addresses and ports, and thus in which (RTP) sessions the 1783 information is flowing. This affects the security contexts being 1784 used and can cause previously separated information flows to share 1785 the same security context. This has very little impact on the 1786 performance of the security mechanism of the RTP sessions. In cases 1787 where one would have applied different security policies on the 1788 different RTP streams being bundled, or where the parties having 1789 access to the security contexts would have differed between the RTP 1790 streams, additional analysis of the implications are needed before 1791 selecting to apply BUNDLE. 1793 The identification-tag, independent of transport, RTCP SDES packet or 1794 RTP header extension, can expose the value to parties beyond the 1795 signaling chain. Therefore, the identification-tag values MUST be 1796 generated in a fashion that does not leak user information, e.g., 1797 randomly or using a per-bundle group counter, and SHOULD be 3 bytes 1798 or less, to allow them to efficiently fit into the MID RTP header 1799 extension. Note that if implementations use different methods for 1800 generating identification-tags this could enable fingerprinting of 1801 the implementation making it vulnerable to targeted attacks. The 1802 identification-tag is exposed on the RTP stream level when included 1803 in the RTP header extensions, however what it reveals of the RTP 1804 media stream structure of the endpoint and application was already 1805 possible to deduce from the RTP streams without the MID SDES header 1806 extensions. As the identification-tag is also used to route the 1807 media stream to the right application functionality it is important 1808 that the value received is the one intended by the sender, thus 1809 integrity and the authenticity of the source are important to prevent 1810 denial of service on the application. Existing SRTP configurations 1811 and other security mechanisms protecting the whole RTP/RTCP packets 1812 will provide the necessary protection. 1814 When the BUNDLE extension is used, the set of configurations of the 1815 security mechanism used in all the bundled media descriptions will 1816 need to be compatible so that they can be used simultaneously, at 1817 least per direction or endpoint. When using SRTP this will be the 1818 case, at least for the IETF defined key-management solutions due to 1819 their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their 1820 classification in [I-D.ietf-mmusic-sdp-mux-attributes]. 1822 The security considerations of "RTP Header Extension for the RTP 1823 Control Protocol (RTCP) Source Description Items" [RFC7941] requires 1824 that when RTCP is confidentiality protected, and that any SDES RTP 1825 header extension carrying an SDES item, such as the MID RTP header 1826 extension, is also protected using commensurate strength algorithms. 1827 However, assuming the above requirements and recommendations are 1828 followed, there are no known significant security risks with leaving 1829 the MID RTP header extension without confidentiality protection. 1830 Therefore, this specification updates RFC 7941 by adding the 1831 exception that this requirement MAY be ignored for the MID RTP header 1832 extension. Security mechanisms for RTP/RTCP are discussed in Options 1833 for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can 1834 provide the necessary security functions of ensuring the integrity 1835 and source authenticity. 1837 18. Examples 1839 18.1. Example: BUNDLE Address:Port Selection 1841 The example below shows: 1843 o An offer, in which the offerer assigns a unique address:port to 1844 each bundled "m=" section within the BUNDLE group. 1846 o An answer, in which the answerer selects the offerer BUNDLE 1847 address:port, and then selects its own BUNDLE address (the 1848 answerer BUNDLE address:port) and assigns it to the bundled "m=" 1849 section indicated by the answerer BUNDLE-tag. 1851 SDP Offer (1) 1853 v=0 1854 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1855 s= 1856 c=IN IP6 2001:db8::3 1857 t=0 0 1858 a=group:BUNDLE foo bar 1859 m=audio 10000 RTP/AVP 0 8 97 1860 b=AS:200 1861 a=mid:foo 1862 a=rtcp-mux 1863 a=rtpmap:0 PCMU/8000 1864 a=rtpmap:8 PCMA/8000 1865 a=rtpmap:97 iLBC/8000 1866 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1867 m=video 10002 RTP/AVP 31 32 1868 b=AS:1000 1869 a=mid:bar 1870 a=rtcp-mux 1871 a=rtpmap:31 H261/90000 1872 a=rtpmap:32 MPV/90000 1873 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1875 SDP Answer (2) 1877 v=0 1878 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1879 s= 1880 c=IN IP6 2001:db8::1 1881 t=0 0 1882 a=group:BUNDLE foo bar 1883 m=audio 20000 RTP/AVP 0 1884 b=AS:200 1885 a=mid:foo 1886 a=rtcp-mux 1887 a=rtpmap:0 PCMU/8000 1888 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1889 m=video 0 RTP/AVP 32 1890 b=AS:1000 1891 a=mid:bar 1892 a=bundle-only 1893 a=rtpmap:32 MPV/90000 1894 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1896 18.2. Example: BUNDLE Extension Rejected 1898 The example below shows: 1900 o An offer, in which the offerer assigns a unique address:port to 1901 each bundled "m=" section within the BUNDLE group. 1903 o An answer, in which the answerer rejects the offered BUNDLE group, 1904 and assigns a unique address:port to each "m=" section (following 1905 normal RFC 3264 procedures). 1907 SDP Offer (1) 1909 v=0 1910 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1911 s= 1912 c=IN IP6 2001:db8::3 1913 t=0 0 1914 a=group:BUNDLE foo bar 1915 m=audio 10000 RTP/AVP 0 8 97 1916 b=AS:200 1917 a=mid:foo 1918 a=rtcp-mux 1919 a=rtpmap:0 PCMU/8000 1920 a=rtpmap:8 PCMA/8000 1921 a=rtpmap:97 iLBC/8000 1922 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1923 m=video 10002 RTP/AVP 31 32 1924 b=AS:1000 1925 a=mid:bar 1926 a=rtcp-mux 1927 a=rtpmap:31 H261/90000 1928 a=rtpmap:32 MPV/90000 1929 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1931 SDP Answer (2) 1933 v=0 1934 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1935 s= 1936 c=IN IP6 2001:db8::1 1937 t=0 0 1938 m=audio 20000 RTP/AVP 0 1939 b=AS:200 1940 a=rtcp-mux 1941 a=rtpmap:0 PCMU/8000 1942 m=video 30000 RTP/AVP 32 1943 b=AS:1000 1944 a=rtcp-mux 1945 a=rtpmap:32 MPV/90000 1947 18.3. Example: Offerer Adds a Media Description to a BUNDLE Group 1949 The example below shows: 1951 o A subsequent offer (the BUNDLE group has been created as part of a 1952 previous offer/answer exchange), in which the offerer adds a new 1953 "m=" section, indicated by the "zen" identification-tag, to a 1954 previously negotiated BUNDLE group, assigns the previously 1955 selected offerer BUNDLE address:port to the added "m=" section, 1956 indicated by the offerer BUNDLE-tag. To every other bundled "m=" 1957 section the offerer assigns a zero port value and includes an SDP 1958 'bundle-only' attribute. 1960 o An answer, in which the answerer assigns the answerer BUNDLE 1961 address:port to the bundled "m=" section indicated by the answerer 1962 BUNDLE-tag. To every other bundled "m=" section the answerer 1963 assigns a zero port value and includes an SDP 'bundle-only' 1964 attribute. 1966 SDP Offer (1) 1968 v=0 1969 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 1970 s= 1971 c=IN IP6 2001:db8::3 1972 t=0 0 1973 a=group:BUNDLE zen foo bar 1974 m=audio 0 RTP/AVP 0 8 97 1975 b=AS:200 1976 a=mid:foo 1977 a=bundle-only 1978 a=rtpmap:0 PCMU/8000 1979 a=rtpmap:8 PCMA/8000 1980 a=rtpmap:97 iLBC/8000 1981 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1982 m=video 0 RTP/AVP 31 32 1983 b=AS:1000 1984 a=mid:bar 1985 a=bundle-only 1986 a=rtpmap:31 H261/90000 1987 a=rtpmap:32 MPV/90000 1988 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1989 m=video 10000 RTP/AVP 66 1990 b=AS:1000 1991 a=mid:zen 1992 a=rtcp-mux 1993 a=rtpmap:66 H261/90000 1994 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1996 SDP Answer (2) 1997 v=0 1998 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 1999 s= 2000 c=IN IP6 2001:db8::1 2001 t=0 0 2002 a=group:BUNDLE zen foo bar 2003 m=audio 0 RTP/AVP 0 2004 b=AS:200 2005 a=mid:foo 2006 a=bundle-only 2007 a=rtpmap:0 PCMU/8000 2008 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2009 m=video 0 RTP/AVP 32 2010 b=AS:1000 2011 a=mid:bar 2012 a=bundle-only 2013 a=rtpmap:32 MPV/90000 2014 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2015 m=video 20000 RTP/AVP 66 2016 b=AS:1000 2017 a=mid:zen 2018 a=rtcp-mux 2019 a=rtpmap:66 H261/90000 2020 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2022 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 2024 The example below shows: 2026 o A subsequent offer (the BUNDLE group has been created as part of a 2027 previous offer/answer transaction), in which the offerer moves a 2028 bundled "m=" section, indicated by the "zen" identification-tag, 2029 out of a BUNDLE group, assigns a unique address:port to the moved 2030 "m=" section, and assigns the previously selected offerer BUNDLE 2031 address:port to another bundled "m=" section, indicated by the 2032 offerer BUNDLE-tag. To every other bundled "m=" section the 2033 offerer assigns a zero port value and includes an SDP 'bundle- 2034 only' attribute. 2036 o An answer, in which the answerer moves the "m=" section out of the 2037 BUNDLE group, assigns a unique address:port to the moved "m=" 2038 section, and assigns the answerer BUNDLE address:port to the 2039 bundled "m=" section indicated by the answerer BUNDLE-tag. To 2040 every other bundled "m=" section the answerer assigns a zero port 2041 value and includes an SDP 'bundle-only' attribute. 2043 SDP Offer (1) 2045 v=0 2046 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2047 s= 2048 c=IN IP6 2001:db8::3 2049 t=0 0 2050 a=group:BUNDLE foo bar 2051 m=audio 10000 RTP/AVP 0 8 97 2052 b=AS:200 2053 a=mid:foo 2054 a=rtcp-mux 2055 a=rtpmap:0 PCMU/8000 2056 a=rtpmap:8 PCMA/8000 2057 a=rtpmap:97 iLBC/8000 2058 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2059 m=video 0 RTP/AVP 31 32 2060 b=AS:1000 2061 a=mid:bar 2062 a=bundle-only 2063 a=rtpmap:31 H261/90000 2064 a=rtpmap:32 MPV/90000 2065 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2066 m=video 50000 RTP/AVP 66 2067 b=AS:1000 2068 a=mid:zen 2069 a=rtcp-mux 2070 a=rtpmap:66 H261/90000 2072 SDP Answer (2) 2074 v=0 2075 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2076 s= 2077 c=IN IP6 2001:db8::1 2078 t=0 0 2079 a=group:BUNDLE foo bar 2080 m=audio 20000 RTP/AVP 0 2081 b=AS:200 2082 a=mid:foo 2083 a=rtcp-mux 2084 a=rtpmap:0 PCMU/8000 2085 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2086 m=video 0 RTP/AVP 32 2087 b=AS:1000 2088 a=mid:bar 2089 a=bundle-only 2090 a=rtpmap:32 MPV/90000 2091 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2092 m=video 60000 RTP/AVP 66 2093 b=AS:1000 2094 a=mid:zen 2095 a=rtcp-mux 2096 a=rtpmap:66 H261/90000 2098 18.5. Example: Offerer Disables a Media Description Within a BUNDLE 2099 Group 2101 The example below shows: 2103 o A subsequent offer (the BUNDLE group has been created as part of a 2104 previous offer/answer transaction), in which the offerer disables 2105 a bundled "m=" section indicated by the "zen" identification-tag, 2106 within a BUNDLE group, assigns a zero port number to the disabled 2107 "m=" section, and assigns the offerer BUNDLE address:port to 2108 another bundled "m=" section, indicated by the offerer BUNDLE-tag. 2109 To every other bundled "m=" section the offerer assigns a zero 2110 port value and includes an SDP 'bundle-only' attribute. 2112 o An answer, in which the answerer moves the disabled "m=" sections 2113 out of the BUNDLE group, assigns a zero port value to the disabled 2114 "m=" section, and assigns the answerer BUNDLE address:port to the 2115 bundled "m=" section indicated by the answerer BUNDLE-tag. To 2116 every other bundled "m=" section the answerer assigns a zero port 2117 value and includes an SDP 'bundle-only' attribute. 2119 SDP Offer (1) 2121 v=0 2122 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 2123 s= 2124 t=0 0 2125 a=group:BUNDLE foo bar 2126 m=audio 10000 RTP/AVP 0 8 97 2127 c=IN IP6 2001:db8::3 2128 b=AS:200 2129 a=mid:foo 2130 a=rtcp-mux 2131 a=rtpmap:0 PCMU/8000 2132 a=rtpmap:8 PCMA/8000 2133 a=rtpmap:97 iLBC/8000 2134 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2135 m=video 0 RTP/AVP 31 32 2136 c=IN IP6 2001:db8::3 2137 b=AS:1000 2138 a=mid:bar 2139 a=bundle-only 2140 a=rtpmap:31 H261/90000 2141 a=rtpmap:32 MPV/90000 2142 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2143 m=video 0 RTP/AVP 66 2144 a=mid:zen 2145 a=rtpmap:66 H261/90000 2147 SDP Answer (2) 2149 v=0 2150 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 2151 s= 2152 t=0 0 2153 a=group:BUNDLE foo bar 2154 m=audio 20000 RTP/AVP 0 2155 c=IN IP6 2001:db8::1 2156 b=AS:200 2157 a=mid:foo 2158 a=rtcp-mux 2159 a=rtpmap:0 PCMU/8000 2160 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2161 m=video 0 RTP/AVP 32 2162 c=IN IP6 2001:db8::1 2163 b=AS:1000 2164 a=mid:bar 2165 a=bundle-only 2166 a=rtpmap:32 MPV/90000 2167 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2168 m=video 0 RTP/AVP 66 2169 a=mid:zen 2170 a=rtpmap:66 H261/90000 2172 19. Acknowledgements 2174 The usage of the SDP grouping extension for negotiating bundled media 2175 is based on similar alternatives proposed by Harald Alvestrand and 2176 Cullen Jennings. The BUNDLE extension described in this document is 2177 based on the different alternative proposals, and text (e.g., SDP 2178 examples) have been borrowed (and, in some cases, modified) from 2179 those alternative proposals. 2181 The SDP examples are also modified versions from the ones in the 2182 Alvestrand proposal. 2184 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 2185 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 2186 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin 2187 Uberti, Taylor Brandstetter, Byron Campen and Eric Rescorla for 2188 reading the text, and providing useful feedback. 2190 Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus 2191 Westerlund for providing the text for the section on RTP/RTCP stream 2192 association. 2194 Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for 2195 providing help and text on the RTP/RTCP procedures. 2197 Thanks to Charlie Kaufman for performing the Sec-Dir review. 2199 Thanks to Linda Dunbar for performing the Gen-ART review. 2201 Thanks to Spotify for providing music for the countless hours of 2202 document editing. 2204 20. Change Log 2206 [RFC EDITOR NOTE: Please remove this section when publishing] 2208 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-48 2210 o Changes based on Sec-Dir review by Charlie Kaufman. 2212 o - s/unique address/unique address:port 2214 o Changes based on Gen-ART review by Linda Dunbar. 2216 o Mux category for group:BUNDLE attribute added. 2218 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-47 2220 o Changes based on AD review by Ben Campbell. 2222 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-46 2224 o Pre-RFC5378 disclaimer removed put back. 2226 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-45 2228 o Mux category for SDP 'group:BUNDLE' attribute added. 2230 o https://github.com/cdh4u/draft-sdp-bundle/pull/54 2232 o Pre-RFC5378 disclaimer removed. 2234 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-44 2236 o Minor editorial nits based on pull request by Colin P. 2238 o https://github.com/cdh4u/draft-sdp-bundle/pull/53 2240 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-43 2242 o Changes based on WG chairs review. 2244 o Text added in order to close GitHub issues by Taylor B. 2246 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-42 2248 o Changes based on final WG review. 2250 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-41 2252 o Update to section 6 o RFC 3264: 2254 o https://github.com/cdh4u/draft-sdp-bundle/pull/47 2256 o Editorial clarification on BUNDLE address selection: 2258 o https://github.com/cdh4u/draft-sdp-bundle/pull/46 2260 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40 2262 o Editorial changes and technical restrictions in order to make the 2263 specification more understandable: 2265 o https://github.com/cdh4u/draft-sdp-bundle/pull/45 2267 o - BUNDLE address is only assigned to m- section indicated by 2268 BUNDLE-tag. 2270 o - bundle-only attribute also used in answers and subsequent 2271 offers. 2273 o - Answerer cannot reject, or remove, the bundled m- section that 2274 contains the BUNDLE address. 2276 o - ICE Offer/Answer sections removed, due to duplicated 2277 information. 2279 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39 2281 o Editorial terminology changes. 2283 o RFC 5285 reference replaced by reference to RFC 8285. 2285 o https://github.com/cdh4u/draft-sdp-bundle/pull/44 2287 o - Clarify that an m- section can not be moved between BUNDLE 2288 groups without first moving the m- section out of a BUNDLE group. 2290 o https://github.com/cdh4u/draft-sdp-bundle/pull/41 2292 o - Addition of BUNDLE transport concept. 2294 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38 2296 o Changes to RTP streaming mapping section based on text from Colin 2297 Perkins. 2299 o The following GitHub pull requests were merged: 2301 o https://github.com/cdh4u/draft-sdp-bundle/pull/34 2303 o - Proposed updates to RTP processing 2305 o https://github.com/cdh4u/draft-sdp-bundle/pull/35 2307 o - fixed reference to receiver-id section 2309 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-37 2311 o The following GitHub pull request was merged: 2313 o https://github.com/cdh4u/draft-sdp-bundle/pull/33 2315 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36 2317 o The following GitHub pull requests were merged: 2319 o https://github.com/cdh4u/draft-sdp-bundle/pull/32 2321 o - extmap handling in BUNDLE. 2323 o https://github.com/cdh4u/draft-sdp-bundle/pull/31 2325 o - Additional Acknowledgement text added. 2327 o https://github.com/cdh4u/draft-sdp-bundle/pull/30 2329 o - MID SDES item security procedures updated 2331 o https://github.com/cdh4u/draft-sdp-bundle/pull/29 2333 o - Appendix B of JSEP moved into BUNDLE. 2335 o - Associating RTP/RTCP packets with SDP m- lines. 2337 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35 2339 o Editorial changes on RTP streaming mapping section based on 2340 comments from Colin Perkins. 2342 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34 2344 o RTP streams, instead of RTP packets, are associated with m- lines. 2346 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 2348 o Editorial changes based on comments from Eric Rescorla and Cullen 2349 Jennings: 2351 o - Changes regarding usage of RTP/RTCP multiplexing attributes. 2353 o - Additional text regarding associating RTP/RTCP packets with SDP 2354 m- lines. 2356 o - Reference correction. 2358 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32 2360 o Editorial changes based on comments from Eric Rescorla and Cullen 2361 Jennings: 2363 o - Justification for mechanism added to Introduction. 2365 o - Clarify that the order of m- lines in the group:BUNDLE attribute 2366 does not have to be the same as the order in which the m- lines 2367 are listed in the SDP. 2369 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31 2371 o Editorial changes based on GitHub Pull requests by Martin Thomson: 2373 o - https://github.com/cdh4u/draft-sdp-bundle/pull/2 2374 o - https://github.com/cdh4u/draft-sdp-bundle/pull/1 2376 o Editorial change based on comment from Diederick Huijbers (9th 2377 July 2016). 2379 o Changes based on comments from Flemming Andreasen (21st June 2380 2016): 2382 o - Mux category for SDP bundle-only attribute added. 2384 o - Mux category considerations editorial clarification. 2386 o - Editorial changes. 2388 o RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext. 2390 o Note whether Design Considerations appendix is to be kept removed: 2392 o - Appendix is kept within document. 2394 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30 2396 o Indicating in the Abstract and Introduction that the document 2397 updates RFC 3264. 2399 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29 2401 o Change based on WGLC comment from Colin Perkins. 2403 o - Clarify that SSRC can be reused by another source after a delay 2404 of 5 RTCP reporting intervals. 2406 o Change based on WGLC comment from Alissa Cooper. 2408 o - IANA registry name fix. 2410 o - Additional IANA registration information added. 2412 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28 2414 o - Alignment with exclusive mux procedures. 2416 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 2418 o - Yet another terminology change. 2420 o - Mux category considerations added. 2422 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 2424 o - ICE considerations modified: ICE-related SDP attributes only 2425 added to the bundled m- line representing the selected BUNDLE 2426 address. 2428 o - Reference to draft-ietf-mmusic-ice-sip-sdp added. 2430 o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- 2431 rfc5245bis. 2433 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 2435 o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux 2436 considerations. 2438 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 2440 o - Reference and procedures associated with exclusive RTP/RTCP mux 2441 added 2443 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 2445 o - RTCP-MUX mandatory for bundled RTP m- lines 2447 o - Editorial fixes based on comments from Flemming Andreasen 2449 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 2451 o - Correction of Ari's family name 2453 o - Editorial fixes based on comments from Thomas Stach 2455 o - RTP/RTCP correction based on comment from Magnus Westerlund 2457 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2458 msg14861.html 2460 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 2462 o - Correct based on comment from Paul Kyzivat 2464 o -- 'received packets' replaced with 'received data' 2466 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 2468 o - Clarification based on comment from James Guballa 2469 o - Clarification based on comment from Flemming Andreasen 2471 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 2473 o - DTLS Considerations section added. 2475 o - BUNDLE semantics added to the IANA Considerations 2477 o - Changes based on WGLC comments from Adam Roach 2479 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2480 msg14673.html 2482 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 2484 o - Changes based on agreements at IETF#92 2486 o -- BAS Offer removed, based on agreement at IETF#92. 2488 o -- Procedures regarding usage of SDP "b=" line is replaced with a 2489 reference to to draft-ietf-mmusic-sdp-mux-attributes. 2491 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 2493 o - Editorial changes based on comments from Magnus Westerlund. 2495 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 2497 o - Modification of RTP/RTCP multiplexing section, based on comments 2498 from Magnus Westerlund. 2500 o - Reference updates. 2502 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 2504 o - Editorial fix. 2506 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 2508 o - Editorial changes. 2510 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 2512 o Changes to allow a newly suggested offerer BUNDLE address to be 2513 assigned to each bundled m- line. 2515 o Changes based on WGLC comments from Paul Kyzivat 2516 o - Editorial fixes 2518 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 2520 o Usage of SDP 'extmap' attribute added 2522 o SDP 'bundle-only' attribute scoped with "m=" lines with a zero 2523 port value 2525 o Changes based on WGLC comments from Thomas Stach 2527 o - ICE candidates not assigned to bundle-only m- lines with a zero 2528 port value 2530 o - Editorial changes 2532 o Changes based on WGLC comments from Colin Perkins 2534 o - Editorial changes: 2536 o -- "RTP SDES item" -> "RTCP SDES item" 2538 o -- "RTP MID SDES item" -> "RTCP MID SDES item" 2540 o - Changes in section 10.1.1: 2542 o -- "SHOULD NOT" -> "MUST NOT" 2544 o -- Additional text added to the Note 2546 o - Change to section 13.2: 2548 o -- Clarify that mid value is not zero terminated 2550 o - Change to section 13.3: 2552 o -- Clarify that mid value is not zero terminated 2554 o -- Clarify padding 2556 o Changes based on WGLC comments from Paul Kyzivat 2558 o - Editorial changes: 2560 o Changes based on WGLC comments from Jonathan Lennox 2562 o - Editorial changes: 2564 o - Defintion of SDP bundle-only attribute alligned with structure 2565 in 4566bis draft 2567 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 2569 o Editorial corrections based on comments from Harald Alvestrand. 2571 o Editorial corrections based on comments from Cullen Jennings. 2573 o Reference update (RFC 7160). 2575 o Clarification about RTCP packet sending when RTP/RTCP multiplexing 2576 is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ 2577 msg13765.html). 2579 o Additional text added to the Security Considerations. 2581 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 2583 o SDP bundle-only attribute added to IANA Considerations. 2585 o SDES item and RTP header extension added to Abstract and 2586 Introduction. 2588 o Modification to text updating section 8.2 of RFC 3264. 2590 o Reference corrections. 2592 o Editorial corrections. 2594 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 2596 o Terminology change: "bundle-only attribute assigned to m= line" to 2597 "bundle-only attribute associated with m= line". 2599 o Editorial corrections. 2601 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 2603 o Editorial corrections. 2605 o - "of"->"if" (8.3.2.5). 2607 o - "optional"->"OPTIONAL" (9.1). 2609 o - Syntax/ABNF for 'bundle-only' attribute added. 2611 o - SDP Offer/Answer sections merged. 2613 o - 'Request new offerer BUNDLE address' section added 2615 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 2617 o OPEN ISSUE regarding Receiver-ID closed. 2619 o - RTP MID SDES Item. 2621 o - RTP MID Header Extension. 2623 o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers 2624 closed. 2626 o - Indicating that, when rtcp-mux is used, the answerer MUST NOT 2627 include an 'rtcp' attribute in the answer, based on the procedures 2628 in section 5.1.3 of RFC 5761. 2630 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 2632 o Draft title changed. 2634 o Added "SDP" to section names containing "Offer" or "Answer". 2636 o Editorial fixes based on comments from Paul Kyzivat 2637 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2638 msg13314.html). 2640 o Editorial fixed based on comments from Colin Perkins 2641 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2642 msg13318.html). 2644 o - Removed text about extending BUNDLE to allow multiple RTP 2645 sessions within a BUNDLE group. 2647 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 2649 o Major re-structure of SDP Offer/Answer sections, to align with RFC 2650 3264 structure. 2652 o Additional definitions added. 2654 o - Shared address. 2656 o - Bundled "m=" line. 2658 o - Bundle-only "m=" line. 2660 o - Offerer suggested BUNDLE mid. 2662 o - Answerer selected BUNDLE mid. 2664 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 2665 to multiple "m=" lines until it has received an SDP Answer 2666 indicating support of the BUNDLE extension. 2668 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 2669 Answerer supports the BUNDLE extension, assign a zero port value 2670 to a 'bundle-only' "m=" line. 2672 o SDP 'bundle-only' attribute section added. 2674 o Connection data nettype/addrtype restrictions added. 2676 o RFC 3264 update section added. 2678 o Indicating that a specific payload type value can be used in 2679 multiple "m=" lines, if the value represents the same codec 2680 configuration in each "m=" line. 2682 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 2684 o Updated Offerer procedures (http://www.ietf.org/mail- 2685 archive/web/mmusic/current/msg12293.html). 2687 o Updated Answerer procedures (http://www.ietf.org/mail- 2688 archive/web/mmusic/current/msg12333.html). 2690 o Usage of SDP 'bundle-only' attribute added. 2692 o Reference to Trickle ICE document added. 2694 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 2696 o Mechanism modified, to be based on usage of SDP Offers with both 2697 different and identical port number values, depending on whether 2698 it is known if the remote endpoint supports the extension. 2700 o Cullen Jennings added as co-author. 2702 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 2704 o No changes. New version due to expiration. 2706 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 2708 o No changes. New version due to expiration. 2710 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 2712 o Draft name changed. 2714 o Harald Alvestrand added as co-author. 2716 o "Multiplex" terminology changed to "bundle". 2718 o Added text about single versus multiple RTP Sessions. 2720 o Added reference to RFC 3550. 2722 21. References 2724 21.1. Normative References 2726 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2727 Requirement Levels", BCP 14, RFC 2119, 2728 DOI 10.17487/RFC2119, March 1997, 2729 . 2731 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2732 with Session Description Protocol (SDP)", RFC 3264, 2733 DOI 10.17487/RFC3264, June 2002, 2734 . 2736 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2737 Jacobson, "RTP: A Transport Protocol for Real-Time 2738 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2739 July 2003, . 2741 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2742 in Session Description Protocol (SDP)", RFC 3605, 2743 DOI 10.17487/RFC3605, October 2003, 2744 . 2746 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2747 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2748 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2749 . 2751 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2752 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2753 July 2006, . 2755 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2756 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2757 . 2759 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2760 Control Packets on a Single Port", RFC 5761, 2761 DOI 10.17487/RFC5761, April 2010, 2762 . 2764 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2765 Security (DTLS) Extension to Establish Keys for the Secure 2766 Real-time Transport Protocol (SRTP)", RFC 5764, 2767 DOI 10.17487/RFC5764, May 2010, 2768 . 2770 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2771 Protocol (SDP) Grouping Framework", RFC 5888, 2772 DOI 10.17487/RFC5888, June 2010, 2773 . 2775 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2776 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2777 January 2012, . 2779 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2780 Header Extension for the RTP Control Protocol (RTCP) 2781 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2782 August 2016, . 2784 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 2785 Mechanism for RTP Header Extensions", RFC 8285, 2786 DOI 10.17487/RFC8285, October 2017, 2787 . 2789 [I-D.ietf-ice-rfc5245bis] 2790 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2791 Connectivity Establishment (ICE): A Protocol for Network 2792 Address Translator (NAT) Traversal", draft-ietf-ice- 2793 rfc5245bis-18 (work in progress), February 2018. 2795 [I-D.ietf-mmusic-sdp-mux-attributes] 2796 Nandakumar, S., "A Framework for SDP Attributes when 2797 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 2798 (work in progress), February 2018. 2800 [I-D.ietf-mmusic-mux-exclusive] 2801 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 2802 Multiplexing using SDP", draft-ietf-mmusic-mux- 2803 exclusive-12 (work in progress), May 2017. 2805 [I-D.ietf-mmusic-ice-sip-sdp] 2806 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, 2807 "Session Description Protocol (SDP) Offer/Answer 2808 procedures for Interactive Connectivity Establishment 2809 (ICE)", draft-ietf-mmusic-ice-sip-sdp-16 (work in 2810 progress), November 2017. 2812 21.2. Informative References 2814 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2815 A., Peterson, J., Sparks, R., Handley, M., and E. 2816 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2817 DOI 10.17487/RFC3261, June 2002, 2818 . 2820 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2821 "RTP Control Protocol Extended Reports (RTCP XR)", 2822 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2823 . 2825 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2826 "Codec Control Messages in the RTP Audio-Visual Profile 2827 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 2828 February 2008, . 2830 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2831 "Extended RTP Profile for Real-time Transport Control 2832 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2833 DOI 10.17487/RFC4585, July 2006, 2834 . 2836 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2837 Media Attributes in the Session Description Protocol 2838 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2839 . 2841 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2842 Clock Rates in an RTP Session", RFC 7160, 2843 DOI 10.17487/RFC7160, April 2014, 2844 . 2846 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2847 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2848 . 2850 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2851 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2852 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2853 DOI 10.17487/RFC7656, November 2015, 2854 . 2856 [I-D.ietf-ice-trickle] 2857 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 2858 "Trickle ICE: Incremental Provisioning of Candidates for 2859 the Interactive Connectivity Establishment (ICE) 2860 Protocol", draft-ietf-ice-trickle-17 (work in progress), 2861 February 2018. 2863 [I-D.ietf-avtext-lrr] 2864 Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 2865 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 2866 Message", draft-ietf-avtext-lrr-07 (work in progress), 2867 July 2017. 2869 Appendix A. Design Considerations 2871 One of the main issues regarding the BUNDLE grouping extensions has 2872 been whether, in SDP Offers and SDP Answers, the same port value can 2873 be inserted in "m=" lines associated with a BUNDLE group, as the 2874 purpose of the extension is to negotiate the usage of a single 2875 transport for media specified by the "m=" sections. Issues with both 2876 approaches, discussed in the Appendix have been raised. The outcome 2877 was to specify a mechanism which uses SDP Offers with both different 2878 and identical port values. 2880 Below are the primary issues that have been considered when defining 2881 the "BUNDLE" grouping extension: 2883 o 1) Interoperability with existing UAs. 2885 o 2) Interoperability with intermediary Back to Back User Agent 2886 (B2BUA) and proxy entities. 2888 o 3) Time to gather, and the number of, ICE candidates. 2890 o 4) Different error scenarios, and when they occur. 2892 o 5) SDP Offer/Answer impacts, including usage of port number value 2893 zero. 2895 A.1. UA Interoperability 2897 Consider the following SDP Offer/Answer exchange, where Alice sends 2898 an SDP Offer to Bob: 2900 SDP Offer 2902 v=0 2903 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2904 s= 2905 c=IN IP4 atlanta.example.com 2906 t=0 0 2907 m=audio 10000 RTP/AVP 97 2908 a=rtpmap:97 iLBC/8000 2909 m=video 10002 RTP/AVP 97 2910 a=rtpmap:97 H261/90000 2912 SDP Answer 2914 v=0 2915 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2916 s= 2917 c=IN IP4 biloxi.example.com 2918 t=0 0 2919 m=audio 20000 RTP/AVP 97 2920 a=rtpmap:97 iLBC/8000 2921 m=video 20002 RTP/AVP 97 2922 a=rtpmap:97 H261/90000 2924 RFC 4961 specifies a way of doing symmetric RTP but that is a later 2925 extension to RTP and Bob can not assume that Alice supports RFC 4961. 2926 This means that Alice may be sending RTP from a different port than 2927 10000 or 10002 - some implementations simply send the RTP from an 2928 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2929 way that Bob knows if the packet is to be passed to the video or 2930 audio codec is by looking at the port it was received on. This led 2931 some SDP implementations to use the fact that each "m=" section had a 2932 different port number to use that port number as an index to find the 2933 correct m line in the SDP. As a result, some implementations that do 2934 support symmetric RTP and ICE still use an SDP data structure where 2935 SDP with "m=" sections with the same port such as: 2937 SDP Offer 2939 v=0 2940 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2941 s= 2942 c=IN IP4 atlanta.example.com 2943 t=0 0 2944 m=audio 10000 RTP/AVP 97 2945 a=rtpmap:97 iLBC/8000 2946 m=video 10000 RTP/AVP 98 2947 a=rtpmap:98 H261/90000 2949 will result in the second "m=" section being considered an SDP error 2950 because it has the same port as the first line. 2952 A.2. Usage of Port Number Value Zero 2954 In an SDP Offer or SDP Answer, the media specified by an "m=" section 2955 can be disabled/rejected by setting the port number value to zero. 2956 This is different from e.g., using the SDP direction attributes, 2957 where RTCP traffic will continue even if the SDP "inactive" attribute 2958 is indicated for the associated "m=" section. 2960 If each "m=" section associated with a BUNDLE group would contain 2961 different port values, and one of those port values would be used for 2962 a BUNDLE address:port associated with the BUNDLE group, problems 2963 would occur if an endpoint wants to disable/reject the "m=" section 2964 associated with that port, by setting the port value to zero. After 2965 that, no "m=" section would contain the port value which is used for 2966 the BUNDLE address:port. In addition, it is unclear what would 2967 happen to the ICE candidates associated with the "m=" section, as 2968 they are also used for the BUNDLE address:port. 2970 A.3. B2BUA And Proxy Interoperability 2972 Some back to back user agents may be configured in a mode where if 2973 the incoming call leg contains an SDP attribute the B2BUA does not 2974 understand, the B2BUA still generates that SDP attribute in the Offer 2975 for the outgoing call leg. Consider a B2BUA that did not understand 2976 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 2977 Further assume that the B2BUA was configured to tear down any call 2978 where it did not see any RTCP for 5 minutes. In this case, if the 2979 B2BUA received an Offer like: 2981 SDP Offer 2983 v=0 2984 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2985 s= 2986 c=IN IP4 atlanta.example.com 2987 t=0 0 2988 m=audio 49170 RTP/AVP 0 2989 a=rtcp:53020 2991 It would be looking for RTCP on port 49171 but would not see any 2992 because the RTCP would be on port 53020 and after five minutes, it 2993 would tear down the call. Similarly, a B2BUA that did not understand 2994 BUNDLE yet put BUNDLE in its offer may be looking for media on the 2995 wrong port and tear down the call. It is worth noting that a B2BUA 2996 that generated an Offer with capabilities it does not understand is 2997 not compliant with the specifications. 2999 A.3.1. Traffic Policing 3001 Sometimes intermediaries do not act as B2BUAs, in the sense that they 3002 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 3003 however, they may use SDP information (e.g., IP address and port) in 3004 order to control traffic gating functions, and to set traffic 3005 policing rules. There might be rules which will trigger a session to 3006 be terminated in case media is not sent or received on the ports 3007 retrieved from the SDP. This typically occurs once the session is 3008 already established and ongoing. 3010 A.3.2. Bandwidth Allocation 3012 Sometimes intermediaries do not act as B2BUAs, in the sense that they 3013 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 3014 however, they may use SDP information (e.g., codecs and media types) 3015 in order to control bandwidth allocation functions. The bandwidth 3016 allocation is done per "m=" section, which means that it might not be 3017 enough if media specified by all "m=" sections try to use that 3018 bandwidth. That may either simply lead to bad user experience, or to 3019 termination of the call. 3021 A.4. Candidate Gathering 3023 When using ICE, a candidate needs to be gathered for each port. This 3024 takes approximately 20 ms extra for each extra "m=" section due to 3025 the NAT pacing requirements. All of this gathering can be overlapped 3026 with other things while e.g., a web-page is loading to minimize the 3027 impact. If the client only wants to generate TURN or STUN ICE 3028 candidates for one of the "m=" lines and then use trickle ICE 3029 [I-D.ietf-ice-trickle] to get the non host ICE candidates for the 3030 rest of the "m=" sections, it MAY do that and will not need any 3031 additional gathering time. 3033 Some people have suggested a TURN extension to get a bunch of TURN 3034 allocations at once. This would only provide a single STUN result so 3035 in cases where the other end did not support BUNDLE, it may cause 3036 more use of the TURN server but would be quick in the cases where 3037 both sides supported BUNDLE and would fall back to a successful call 3038 in the other cases. 3040 Authors' Addresses 3042 Christer Holmberg 3043 Ericsson 3044 Hirsalantie 11 3045 Jorvas 02420 3046 Finland 3048 Email: christer.holmberg@ericsson.com 3050 Harald Tveit Alvestrand 3051 Google 3052 Kungsbron 2 3053 Stockholm 11122 3054 Sweden 3056 Email: harald@alvestrand.no 3058 Cullen Jennings 3059 Cisco 3060 400 3rd Avenue SW, Suite 350 3061 Calgary, AB T2P 4H2 3062 Canada 3064 Email: fluffy@iii.ca