idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-40.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3264, updated by this document, for RFC5378 checks: 2002-01-31) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 20, 2017) is 2348 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 1558 == Missing Reference: 'RFCXXXX' is mentioned on line 1740, 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-15 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-14 == Outdated reference: A later version (-21) exists of draft-ietf-ice-trickle-15 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Updates: 3264 (if approved) H. Alvestrand 5 Intended status: Standards Track Google 6 Expires: May 24, 2018 C. Jennings 7 Cisco 8 November 20, 2017 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-40.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 To assist endpoints in negotiating the use of bundle this 26 specification defines a new SDP attribute, 'bundle-only', which can 27 be used to request that specific media is only used if bundled. The 28 specification also updates RFC 3264, to allow assigning a zero port 29 value to a "m= section without meaning that the media described by 30 the "m=" section is disabled or rejected. 32 When RTP-based media is used, there are multiple ways to correlate 33 bundled RTP packets with the appropriate "m=" section. This 34 specification defines a new Real-time Transport Protocol (RTP) source 35 description (SDES) item and a new RTP header extension that provides 36 an additional way to do this correlation by using them to carry a 37 value that associates the RTP/RTCP packets with a specific "m=" 38 section. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on May 24, 2018. 57 Copyright Notice 59 Copyright (c) 2017 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 This document may contain material from IETF Documents or IETF 73 Contributions published or made publicly available before November 74 10, 2008. The person(s) controlling the copyright in some of this 75 material may not have granted the IETF Trust the right to allow 76 modifications of such material outside the IETF Standards Process. 77 Without obtaining an adequate license from the person(s) controlling 78 the copyright in such materials, this document may not be modified 79 outside the IETF Standards Process, and derivative works of it may 80 not be created outside the IETF Standards Process, except to format 81 it for publication as an RFC or to translate it into languages other 82 than English. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 87 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 88 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 89 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 90 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7 91 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 8 92 7. SDP Information Considerations . . . . . . . . . . . . . . . 9 93 7.1. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9 94 7.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9 95 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9 96 8.1. Mux Category Considerations . . . . . . . . . . . . . . . 10 97 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 11 98 8.2.1. Suggesting the offerer BUNDLE address . . . . . . . . 11 99 8.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 12 100 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 12 101 8.3.1. Answerer Selection of Offerer Bundle Address . . . . 13 102 8.3.2. Answerer Selection of Answerer BUNDLE Address . . . . 14 103 8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 14 104 8.3.4. Rejecting A Media Description In A BUNDLE Group . . . 15 105 8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 15 106 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 16 107 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 16 108 8.5.1. Suggesting a new offerer BUNDLE address . . . . . . . 17 109 8.5.2. Adding a media description to a BUNDLE group . . . . 17 110 8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 18 111 8.5.4. Disabling A Media Description In A BUNDLE Group . . . 19 112 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 19 113 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19 114 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 20 115 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 20 116 10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 21 117 10.2. Associating RTP/RTCP Streams With Correct SDP Media 118 Description . . . . . . . . . . . . . . . . . . . . . . 21 119 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 27 120 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 27 121 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 29 122 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 30 123 11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 31 124 11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 31 125 11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 31 126 11.1.4. Modifying the Session . . . . . . . . . . . . . . . 31 127 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 31 128 13. RTP Header Extensions Consideration . . . . . . . . . . . . . 32 129 14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 32 130 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 32 131 14.2. New text replacing section 5.1 (2nd paragraph) of RFC 132 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 133 14.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 33 134 14.4. New text replacing section 8.2 (2nd paragraph) of RFC 135 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 136 14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 33 137 14.6. New text replacing section 8.4 (6th paragraph) of RFC 138 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 139 15. RTP/RTCP extensions for identification-tag transport . . . . 34 140 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 35 141 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 35 142 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 143 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 36 144 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 36 145 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 37 146 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 37 147 17. Security Considerations . . . . . . . . . . . . . . . . . . . 38 148 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39 149 18.1. Example: Bundle Address Selection . . . . . . . . . . . 39 150 18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 41 151 18.3. Example: Offerer Adds A Media Description To A BUNDLE 152 Group . . . . . . . . . . . . . . . . . . . . . . . . . 42 153 18.4. Example: Offerer Moves A Media Description Out Of A 154 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 44 155 18.5. Example: Offerer Disables A Media Description Within A 156 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46 157 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 158 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 48 159 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 160 21.1. Normative References . . . . . . . . . . . . . . . . . . 57 161 21.2. Informative References . . . . . . . . . . . . . . . . . 59 162 Appendix A. Design Considerations . . . . . . . . . . . . . . . 60 163 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 61 164 A.2. Usage of port number value zero . . . . . . . . . . . . . 62 165 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 62 166 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 63 167 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 63 168 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 63 169 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 171 1. Introduction 173 When multimedia communications are established, each transport 174 (5-tuple) reserved for an individual media stream consume additional 175 resources (especially when Interactive Connectivity Establishment 176 (ICE) [I-D.ietf-ice-rfc5245bis] is used). For this reason, it is 177 attractive to use a single transport for multiple media streams. 179 This specification defines a way to use a single transport (BUNDLE 180 transport) for sending and receiving media (bundled media) described 181 by multiple SDP media descriptions ("m=" sections). The same BUNDLE 182 transport is used for sending and receiving bundled media, which 183 means that the symmetric RTP mechanism [RFC4961] is always used for 184 RTP-based bundled media. 186 This specification defines a new SDP Grouping Framework [RFC5888] 187 extension called 'BUNDLE'. The extension can be used with the 188 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 189 to negotiate which "m=" sections will become part of a BUNDLE group. 190 Within a BUNDLE group, each "m=" section will use a BUNDLE transport 191 for sending and receiving bundled media. 193 Within a BUNDLE group, each endpoint uses a single address:port 194 combination for sending and receiving bundled media. The 195 address:port combination is referred to as BUNDLE address. In 196 addition to negotiating the BUNDLE group, the offerer and answerer 197 [RFC3264] use the BUNDLE extension to negotiate the BUNDLE addresses, 198 one for the offerer (offerer BUNDLE address) and one for the answerer 199 (answerer BUNDLE address). Once the offerer and the answerer have 200 negotiated the BUNDLE addresses, and a BUNDLE group has been formed, 201 they assign their respective BUNDLE address to each "m=" section 202 within the BUNDLE group. The endpoints then use the BUNDLE addresses 203 for sending and receiving the bundled media associated with the 204 BUNDLE group. 206 The use of a BUNDLE transport also allows the usage of a single set 207 of Interactive Connectivity Establishment (ICE) 208 [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group. 210 This specification also defines a new SDP attribute, 'bundle-only', 211 which can be used to request that specific media is only used if the 212 "m=" section describing the media is kept within a BUNDLE group. The 213 specification also updates RFC 3264, to allow usage of zero port 214 values without meaning that media is rejected. 216 As defined in RFC 4566 [RFC4566], the semantics of assigning the same 217 transport address (IP address and port) to multiple "m=" sections are 218 undefined, and there is no grouping defined by such means. Instead, 219 an explicit grouping mechanism needs to be used to express the 220 intended semantics. This specification provides such an extension. 222 This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 223 [RFC3264]. The update allows an answerer to assign a non-zero port 224 value to an "m=" section in an SDP answer, even if the "m=" section 225 in the associated SDP offer contained a zero port value. 227 This specification also defines a new Real-time Transport Protocol 228 (RTP) [RFC3550] source description (SDES) item, 'MID', and a new RTP 229 SDES header extension that can be used to associate RTP streams with 230 "m=" sections. 232 SDP bodies can contain multiple BUNDLE groups. A given BUNDLE 233 address MUST only be associated with a single BUNDLE group. The 234 procedures in this specification apply independently to a given 235 BUNDLE group. All RTP based media flows described by a single BUNDLE 236 group belong to a single RTP session [RFC3550]. 238 The BUNDLE extension is backward compatible. Endpoints that do not 239 support the extension are expected to generate offers and answers 240 without an SDP 'group:BUNDLE' attribute, and are expected to assign a 241 unique address to each "m=" section within an offer and answer, 242 according to the procedures in [RFC4566] and [RFC3264] 244 2. Terminology 246 "m=" section: SDP bodies contain one or more media descriptions, 247 referred to as "m=" sections. Each "m=" section is represented by an 248 SDP "m=" line, and zero or more SDP attributes associated with the 249 "m=" line. An local address:port combination is assigned to each 250 "m=" section. 252 5-tuple: A collection of the following values: source address, source 253 port, destination address, destination port, and transport-layer 254 protocol. 256 Unique address: An address:port combination that is assigned to only 257 one "m=" section in an offer or answer. 259 Shared address: An address:port combination that is assigned to 260 multiple "m=" sections within an offer or answer. 262 Offerer BUNDLE-tag: The first identification-tag in a given SDP 263 'group:BUNDLE' attribute identification-tag list in an offer. 265 Answerer BUNDLE-tag: The first identification-tag in a given SDP 266 'group:BUNDLE' attribute identification-tag list in an answer. 268 Offerer BUNDLE address: Within a given BUNDLE group, an address:port 269 combination used by an offerer to receive all media described by each 270 "m=" section within the BUNDLE group. 272 Answerer BUNDLE address: Within a given BUNDLE group, an address:port 273 combination used by an answerer to receive all media described by 274 each "m=" section within the BUNDLE group. 276 BUNDLE transport: The transport (5-tuple) used by all media described 277 by the "m=" sections within a BUNDLE group. 279 BUNDLE group: A set of "m=" sections, created using an SDP Offer/ 280 Answer exchange, which uses a single BUNDLE transport for sending and 281 receiving all media described by the set of "m=" sections. The same 282 BUNDLE transport is used for sending and receiving media. 284 Bundled "m=" section: An "m=" section, whose identification-tag is 285 placed in an SDP 'group:BUNDLE' attribute identification-tag list in 286 an offer or answer. 288 Bundle-only "m=" section: A bundled "m=" section that contains an SDP 289 'bundle-only' attribute. 291 Bundled media: All media specified by a given BUNDLE group. 293 Initial offer: The first offer, within an SDP session (e.g. a SIP 294 dialog when the Session Initiation Protocol (SIP) [RFC3261] is used 295 to carry SDP), in which the offerer indicates that it wants to create 296 a given BUNDLE group. 298 Subsequent offer: An offer which contains a BUNDLE group that has 299 been created as part of a previous offer/answer exchange. 301 Identification-tag: A unique token value that is used to identify an 302 "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" section 303 carries the unique identification-tag assigned to that "m=" section. 304 The session-level SDP 'group' attribute [RFC5888] carries a list of 305 identification-tags, identifying the "m=" sections associated with 306 that particular 'group' attribute. 308 3. Conventions 310 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 311 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 312 document are to be interpreted as described in BCP 14, RFC 2119 313 [RFC2119]. 315 4. Applicability Statement 317 The mechanism in this specification only applies to the Session 318 Description Protocol (SDP) [RFC4566], when used together with the SDP 319 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 320 scope of this document, and is thus undefined. 322 5. SDP Grouping Framework BUNDLE Extension 324 This section defines a new SDP Grouping Framework [RFC5888] 325 extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP 326 Offer/Answer mechanism to negotiate a set of "m=" sections that will 327 become part of a BUNDLE group. Within a BUNDLE group, each "m=" 328 section will use a BUNDLE transport for sending and receiving bundled 329 media. Each endpoint use a single address:port combination for 330 sending receiving the bundled media. 332 The BUNDLE extension is indicated using an SDP 'group' attribute with 333 a "BUNDLE" semantics value [RFC5888]. An identification-tag is 334 assigned to each bundled "m=" section, and each identification-tag is 335 listed in the SDP 'group:BUNDLE' attribute identification-tag list. 337 Each "m=" section whose identification-tag is listed in the 338 identification-tag list is associated with a given BUNDLE group. 340 SDP bodies can contain multiple BUNDLE groups. Any given bundled 341 "m=" section MUST NOT be associated with more than one BUNDLE group 342 at any given time. 344 NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' 345 attribute identification-tag list does not have to be the same as the 346 order in which the "m=" sections occur in the SDP. 348 Section 8 defines the detailed SDP Offer/Answer procedures for the 349 BUNDLE extension. 351 6. SDP 'bundle-only' Attribute 353 This section defines a new SDP media-level attribute [RFC4566], 354 'bundle-only'. 'bundle-only' is a property attribute [RFC4566], and 355 hence has no value. 357 Name: bundle-only 359 Value: N/A 361 Usage Level: media 363 Charset Dependent: no 365 Example: 367 a=bundle-only 369 In order to ensure that an answerer that does not support the BUNDLE 370 extension always rejects a bundled "m=" section, the offerer can 371 assign a zero port value to the "m=" section. According to [RFC3264] 372 an answerer will reject such "m=" section. By including an SDP 373 'bundle-only' attribute in such "m=" section, the offerer can request 374 that the answerer accepts the "m=" section if the answerer supports 375 the Bundle extension, and if the answerer keeps the "m=" section 376 within the associated BUNDLE group. 378 NOTE: Once the offerer BUNDLE address has been selected, the offerer 379 does not need to include the 'bundle-only' attribute in subsequent 380 offers. By assigning the offerer BUNDLE address to an "m=" section 381 of a subsequent offer, the offerer will ensure that the answerer will 382 either keep the "m=" section within the BUNDLE group, or the answerer 383 will have to reject the "m=" section. 385 The usage of the 'bundle-only' attribute is only defined for a 386 bundled "m=" section with a zero port value, within an offer. Other 387 usage is unspecified. 389 Section 8 defines the detailed SDP Offer/Answer procedures for the 390 'bundle-only' attribute. 392 7. SDP Information Considerations 394 This section describes restrictions associated with the usage of SDP 395 parameters within a BUNDLE group. It also describes, when parameter 396 and attribute values have been assigned to each bundled "m=" section, 397 how to calculate a value for the whole BUNDLE group. 399 7.1. Connection Data (c=) 401 The "c=" line nettype value [RFC4566] associated with a bundled "m=" 402 section MUST be 'IN'. 404 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" 405 section MUST be 'IP4' or 'IP6'. The same value MUST be associated 406 with each "m=" section. 408 NOTE: Extensions to this specification can specify usage of the 409 BUNDLE mechanism for other nettype and addrtype values than the ones 410 listed above. 412 7.2. Bandwidth (b=) 414 An offerer and answerer MUST use the rules and restrictions defined 415 in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP 416 bandwidth (b=) line with bundled "m=" section. 418 8. SDP Offer/Answer Procedures 420 This section describes the SDP Offer/Answer [RFC3264] procedures for: 422 o Negotiating and creating a BUNDLE group; and 424 o Selecting the BUNDLE addresses (offerer BUNDLE address and 425 answerer BUNDLE address); and 427 o Adding an "m=" section to a BUNDLE group; and 429 o Moving an "m=" section out of a BUNDLE group; and 430 o Disabling an "m=" section within a BUNDLE group. 432 The generic rules and procedures defined in [RFC3264] and [RFC5888] 433 also apply to the BUNDLE extension. For example, if an offer is 434 rejected by the answerer, the previously negotiated SDP parameters 435 and characteristics (including those associated with a BUNDLE group) 436 apply. Hence, if an offerer generates an offer in which the offerer 437 wants to create a BUNDLE group, and the answerer rejects the offer, 438 the BUNDLE group is not created. 440 The procedures in this section are independent of the media type or 441 "m=" line proto value assigned to a bundled "m=" section. Section 10 442 defines additional considerations for RTP based media. Section 6 443 defines additional considerations for the usage of the SDP 'bundle- 444 only' attribute. Section 11 defines additional considerations for 445 the usage of Interactive Connectivity Establishment (ICE) 446 [I-D.ietf-ice-rfc5245bis] mechanism. 448 SDP offers and answers can contain multiple BUNDLE groups. The 449 procedures in this section apply independently to a given BUNDLE 450 group. 452 8.1. Mux Category Considerations 454 When an offerer or answerer includes SDP attributes in a bundled "m=" 455 section (including any bundle-only "m=" section) to which a shared 456 address has been assigned, IDENTICAL and TRANSPORT mux category SDP 457 attributes [I-D.ietf-mmusic-sdp-mux-attributes] are included in the 458 "m=" section only if the "m=" section is also associated with the 459 offerer/answerer BUNDLE-tag. Otherwise the offerer/answerer MUST NOT 460 include such SDP attributes in the "m=" section. The rule above does 461 not apply to a bundled "m=" section to which a unique address has 462 been assigned. 464 NOTE: As bundled "m=" section (including any bundle-only "m=" 465 section) to which a shared address has been assigned will share the 466 same IDENTICAL and TRANSPORT mux category SDP attributes, and 467 attribute values, there is no need to include such SDP attributes in 468 each "m=" section. The attributes and attribute values are 469 implicitly included and applied to each "m=" section. 471 The semantics of some SDP attributes only apply to specific types of 472 media. For example, the semantics of the SDP 'rtcp-mux' and SDP 473 'rtcp-mux-only' attributes only apply to "m=" sections describing 474 RTP-based media. However, as described in Section 8.1, there are 475 cases where IDENTICAL and TRANSPORT mux category SDP attributes are 476 only included in the "m=" sections associated with the BUNDLE-tag. 477 That means that media-specific IDENTICAL and TRANSPORT mux category 478 attributes can be included in an "m=" section associated with another 479 type of media. 481 8.2. Generating the Initial SDP Offer 483 When an offerer generates an initial offer, in order to create a 484 BUNDLE group, it MUST: 486 o Assign a unique address to each "m=" section within the offer, 487 following the procedures in [RFC3264], unless the media line is a 488 'bundle-only' "m=" section (see below); and 490 o Include an SDP 'group:BUNDLE' attribute in the offer; and 492 o Place the identification-tag of each bundled "m=" section in the 493 SDP 'group:BUNDLE' attribute identification-tag list; and 495 o Indicate which unique address the offerer suggests as the offerer 496 BUNDLE address [Section 8.2.1]. 498 If the offerer wants to request that the answerer accepts a given 499 bundled "m=" section only if the answerer keeps the "m=" section 500 within the BUNDLE group, the offerer MUST: 502 o Include an SDP 'bundle-only' attribute [Section 8.2.1] in the "m=" 503 secction; and 505 o Assign a zero port value to the "m=" section. 507 NOTE: If the offerer assigns a zero port value to an "m=" section, 508 but does not also include an SDP 'bundle-only' attribute in the "m=" 509 section, it is an indication that the offerer wants to disable the 510 "m=" section [Section 8.5.4]. 512 [Section 18.1] shows an example of an initial offer. 514 8.2.1. Suggesting the offerer BUNDLE address 516 In the offer, the address:port combination assigned to the "m=" 517 section associated with the offerer BUNDLE-tag indicates the 518 address:port combination that the offerer suggests as the offerer 519 BUNDLE address. 521 The offerer MUST NOT assign a zero port value, or an SDP 'bundle- 522 only' attribute, to the "m=" section associated with the offerer 523 BUNDLE-tag. 525 8.2.2. Example: Initial SDP Offer 527 The example shows an initial SDP offer. The offer includes two "m=" 528 section in the SDP, and suggests that both are included in a BUNDLE 529 group. The audio "m=" section is associated with the offerer BUNDLE- 530 tag (placed first in the SDP group:BUNDLE attribute identification-id 531 list). 533 SDP Offer 535 v=0 536 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 537 s= 538 c=IN IP4 atlanta.example.com 539 t=0 0 540 a=group:BUNDLE foo bar 541 m=audio 10000 RTP/AVP 0 8 97 542 b=AS:200 543 a=mid:foo 544 a=rtcp-mux 545 a=rtpmap:0 PCMU/8000 546 a=rtpmap:8 PCMA/8000 547 a=rtpmap:97 iLBC/8000 548 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 549 m=video 10002 RTP/AVP 31 32 550 b=AS:1000 551 a=mid:bar 552 a=rtpmap:31 H261/90000 553 a=rtpmap:32 MPV/90000 554 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 556 8.3. Generating the SDP Answer 558 When an answerer generates an answer that contains a BUNDLE group, 559 the following general SDP grouping framework restrictions, defined in 560 [RFC5888], also apply to the BUNDLE group: 562 o The answerer MUST NOT include a BUNDLE group in the answer, unless 563 the offerer requested the BUNDLE group to be created in the 564 corresponding offer; and 566 o The answerer MUST NOT include an "m=" section within a BUNDLE 567 group, unless the offerer requested the "m=" section to be within 568 that BUNDLE group in the corresponding offer. 570 o If the answer contains multiple BUNDLE groups, the answerer MUST 571 NOT move an "m=" section from one BUNDLE group to another. 573 If the answer contains a BUNDLE group, the answerer MUST: 575 o Select an Offerer BUNDLE Address [Section 8.3.1]; and 577 o Select an Answerer BUNDLE Address [Section 8.3.2]; 579 The answerer is allowed to select a new Answerer BUNDLE address each 580 time it generates an answer to an offer. 582 If the answerer does not want to keep an "m=" section within a BUNDLE 583 group, it MUST: 585 o Move the "m=" section out of the BUNDLE group [Section 8.3.3]; or 587 o Reject the "m=" section [Section 8.3.4]; 589 If the answerer keeps a bundle-only "m=" section within the BUNDLE 590 group, it follows the procedures (assigns the answerer BUNDLE address 591 to the "m=" section etc) for any other "m=" section kept within the 592 BUNDLE group. 594 If the answerer does not want to keep a bundle-only "m=" section 595 within the BUNDLE group, it MUST reject the "m=" section 596 [Section 8.3.4]. 598 The answerer MUST NOT include an SDP 'bundle-only' attribute in any 599 "m=" section in an answer. 601 NOTE: If a bundled "m=" section in an offer contains a zero port 602 value, but the "m=" section does not contain an SDP 'bundle-only' 603 attribute, it is an indication that the offerer wants to disable the 604 "m=" section [Section 8.5.4]. 606 8.3.1. Answerer Selection of Offerer Bundle Address 608 In an offer, the address (unique or shared) assigned to the bundled 609 "m=" section associated with the offerer BUNDLE-tag indicates the 610 address that the offerer suggests as the offerer BUNDLE address 611 [Section 8.2.1]. The answerer MUST check whether that "m=" section 612 fulfils the following criteria: 614 o The answerer will not move the "m=" section out of the BUNDLE 615 group [Section 8.3.3]; and 617 o The answerer will not reject the "m=" section [Section 8.3.4]; and 618 o The "m=" section does not contain a zero port value. 620 If all of the criteria above are fulfilled, the answerer MUST select 621 the address assigned to the "m=" section as the offerer BUNDLE 622 address. In the answer, the answerer BUNDLE-tag represents the "m=" 623 section, and the address assigned to the "m=" section in the offer 624 becomes the offerer BUNDLE address. 626 If one or more of the criteria are not fulfilled, the answerer MUST 627 select the next identification-tag in the identification-tag list, 628 and perform the same criteria check for the "m=" section associated 629 with that identification-tag. If there are no more identification- 630 tags in the identification-tag list, the answerer MUST NOT create the 631 BUNDLE group. In addition, unless the answerer rejects the whole 632 offer, the answerer MUST apply the answerer procedures for moving an 633 "m=" section out of a BUNDLE group [Section 8.3.3] to each bundled 634 "m=" section in the offer when creating the answer. 636 [Section 18.1] shows an example of an offerer BUNDLE address 637 selection. 639 8.3.2. Answerer Selection of Answerer BUNDLE Address 641 When the answerer selects a BUNDLE address for itself, referred to as 642 the answerer BUNDLE address, it MUST assign that address to each 643 bundled "m=" section within the created BUNDLE group in the answer. 645 The answerer MUST NOT assign the answerer BUNDLE address to an "m=" 646 section that is not within the BUNDLE group, or to an "m=" section 647 that is within another BUNDLE group. 649 [Section 18.1] shows an example of an answerer BUNDLE address 650 selection. 652 8.3.3. Moving A Media Description Out Of A BUNDLE Group 654 When an answerer wants to move an "m=" section out of a BUNDLE group, 655 it MUST first check the following criteria: 657 o In the corresponding offer, a shared address (e.g. a previously 658 selected offerer BUNDLE address) has been assigned to the "m=" 659 section; or 661 o In the corresponding offer, the "m=" section contains an SDP 662 'bundle-only' attribute, and the "m=" section contains a zero port 663 value. 665 An answerer MUST NOT move an "m=" section from one BUNDLE group to 666 another within an answer. If the answerer wants to move an "m=" 667 section from one BUNDLE group to another it MUST first move the 668 BUNDLE group out of the current BUNDLE group, and then generate an 669 offer where the "m=" section is added to another BUNDLE group 670 [Section 8.5.2]. 672 If either criteria above is fulfilled, the answerer MUST reject the 673 "m=" section [Section 8.3.4]. 675 Otherwise, if a unique address has been assigned to the "m=" section 676 in the corresponding offer, the answerer MUST assign a unique address 677 to the "m=" section in the answer (the answerer does not reject the 678 "m=" section). 680 In addition, in either case above, the answerer MUST NOT place the 681 identification-tag, associated with the moved "m=" section, in the 682 SDP 'group' attribute identification-tag list associated with the 683 BUNDLE group. 685 8.3.4. Rejecting A Media Description In A BUNDLE Group 687 When an answerer rejects an "m=" section, it MUST assign a zero port 688 value to "m=" section in the answer, according to the procedures in 689 [RFC3264]. 691 In addition, the answerer MUST NOT place the identification-tag 692 associated with the rejected "m=" section in the SDP 'group' 693 attribute identification-tag list associated with the BUNDLE group. 695 8.3.5. Example: SDP Answer 697 The example shows an SDP answer, based on the SDP offer in 698 [Section 8.2.2]. The answers accepts both "m=" sections within the 699 BUNDLE group. 701 SDP Answer 703 v=0 704 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 705 s= 706 c=IN IP4 biloxi.example.com 707 t=0 0 708 a=group:BUNDLE foo bar 709 m=audio 20000 RTP/AVP 0 710 b=AS:200 711 a=mid:foo 712 a=rtcp-mux 713 a=rtpmap:0 PCMU/8000 714 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 715 m=video 20000 RTP/AVP 32 716 b=AS:1000 717 a=mid:bar 718 a=rtpmap:32 MPV/90000 719 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 721 8.4. Offerer Processing of the SDP Answer 723 When an offerer receives an answer, if the answer contains a BUNDLE 724 group, the offerer MUST check that any bundled "m=" section in the 725 answer was indicated as bundled in the corresponding offer. If there 726 is no mismatch, the offerer MUST use the offerer BUNDLE address, 727 selected by the answerer [Section 8.3.1], as the address for each 728 bundled "m=" section. 730 NOTE: As the answerer might reject one or more bundled "m=" sections, 731 or move a bundled "m=" section out of a BUNDLE group, each bundled 732 "m=" section in the offer might not be indicated as bundled in the 733 answer. 735 If the answer does not contain a BUNDLE group, the offerer MUST 736 process the answer as a normal answer. 738 8.5. Modifying the Session 740 When an offerer generates a subsequent offer, it MUST assign the 741 previously selected offerer BUNDLE address [Section 8.3.1] to each 742 bundled "m=" section (including any bundle-only "m=" section), except 743 if: 745 o The offerer suggests a new offerer BUNDLE address [Section 8.5.1]; 746 or 748 o The offerer wants to add a bundled "m=" section to the BUNDLE 749 group [Section 8.5.2]; or 751 o The offerer wants to move a bundled "m=" section out of the BUNDLE 752 group [Section 8.5.3]; or 754 o The offerer wants to disable the bundled "m=" section 755 [Section 8.5.4]. 757 In addition, the offerer MUST select an offerer BUNDLE-tag 758 [Section 8.2.1] associated with the previously selected offerer 759 BUNDLE address, unless the offerer suggests a new offerer BUNDLE 760 address. 762 8.5.1. Suggesting a new offerer BUNDLE address 764 When an offerer generates an offer, in which it suggests a new 765 offerer BUNDLE address [Section 8.2.1], the offerer MUST: 767 o Assign the address (shared address) to each "m=" section within 768 the BUNDLE group; or 770 o Assign the address (unique address) to one bundled "m=" section. 772 In addition, the offerer MUST indicate that the address is the new 773 suggested offerer BUNDLE address [Section 8.2.1]. 775 NOTE: Unless the offerer assigns the new suggested offerer BUNDLE 776 address to each bundled "m=" section, it can assign unique addresses 777 to any number of bundled "m=" sections (and the previously selected 778 offerer BUNDLE address to any remaining bundled "m=" section) if it 779 wants to suggest multiple alternatives for the new offerer BUNDLE 780 address. 782 8.5.2. Adding a media description to a BUNDLE group 784 When an offerer generates an offer, in which it wants to add a 785 bundled "m=" section to a BUNDLE group, the offerer MUST: 787 o Assign a unique address to the added "m=" section; or 789 o Assign the previously selected offerer BUNDLE address to the added 790 "m=" section; or 792 o If the offerer assigns a new (shared address) suggested offerer 793 BUNDLE address to each bundled "m=" section [Section 8.5.1], also 794 assigns that address to the added "m=" section. 796 In addition, the offerer MUST place the identification-tag associated 797 with the added "m=" section in the SDP 'group:BUNDLE' attribute 798 identification-tag list associated with the BUNDLE group 799 [Section 8.2.1]. 801 NOTE: Assigning a unique address to the "m=" section allows the 802 answerer to move the "m=" section out of the BUNDLE group 803 [Section 8.3.3], without having to reject the "m=" section. 805 If the offerer assigns a unique address to the added "m=" section, 806 and if the offerer suggests that address as the new offerer BUNDLE 807 address [Section 8.5.1], the offerer BUNDLE-tag MUST represent the 808 added "m=" section [Section 8.2.1]. 810 If the offerer associates a new suggested offerer BUNDLE address with 811 each bundled "m=" section [Section 8.5.1], including the added "m=" 812 section, the offerer BUNDLE-tag MAY represent the added "m=" section 813 [Section 8.2.1]. 815 [Section 18.3] shows an example where an offerer sends an offer in 816 order to add a bundled "m=" section to a BUNDLE group. 818 8.5.3. Moving A Media Description Out Of A BUNDLE Group 820 When an offerer generates an offer, in which it wants to move a 821 bundled "m=" section out of a BUNDLE group it was added to in a 822 previous offer/answer transaction, the offerer: 824 o MUST assign a unique address to the "m=" section; and 826 o MUST NOT place the identification-tag associated with the "m=" 827 section in the SDP 'group:BUNDLE' attribute identification-tag 828 list associated with the BUNDLE group. 830 NOTE: If the removed "m=" section is associated with the previously 831 selected BUNDLE-tag, the offerer needs to suggest a new BUNDLE-tag 832 [Section 8.2.1]. 834 NOTE: If an "m=" section, when being moved out of a BUNDLE group, is 835 added to another BUNDLE group, the offerer applies the procedures in 836 [Section 8.5.2] to the "m=" section. 838 An offerer MUST NOT move an "m=" section from one BUNDLE group to 839 another within a single offer. If the offerer wants to move an "m=" 840 section from one BUNDLE group to another it MUST first move the 841 BUNDLE group out of the current BUNDLE group, and then generate a 842 second offer where the "m=" section is added to another BUNDLE group 843 [Section 8.5.2]. 845 [Section 18.4] shows an example of an offer for moving an "m=" 846 section out of a BUNDLE group. 848 8.5.4. Disabling A Media Description In A BUNDLE Group 850 When an offerer generates an offer, in which it wants to disable a 851 bundled "m=" section (added to the BUNDLE group in a previous offer/ 852 answer transaction), the offerer: 854 o MUST assign an address with a zero port value to the "m=" section, 855 following the procedures in [RFC4566]; and 857 o MUST NOT place the identification-tag associated with the "m=" 858 section in the SDP 'group:BUNDLE' attribute identification-tag 859 list associated with the BUNDLE group. 861 [Section 18.5] shows an example of an offer for disabling an "m=" 862 section within a BUNDLE group. 864 9. Protocol Identification 866 Each "m=" section within a BUNDLE group MUST use the same transport- 867 layer protocol. If bundled "m=" sections use different protocols on 868 top of the transport-layer protocol, there MUST exist a publicly 869 available specification which describes a mechanism, for this 870 particular protocol combination, how to associate received data with 871 the correct protocol. 873 In addition, if received data can be associated with more than one 874 bundled "m=" section, there MUST exist a publicly available 875 specification which describes a mechanism for associating the 876 received data with the correct "m=" section. 878 This document describes a mechanism to identify the protocol of 879 received data among the STUN, DTLS and SRTP protocols (in any 880 combination), when UDP is used as transport-layer protocol, but does 881 not describe how to identify different protocols transported on DTLS. 882 While the mechanism is generally applicable to other protocols and 883 transport-layer protocols, any such use requires further 884 specification around how to multiplex multiple protocols on a given 885 transport-layer protocol, and how to associate received data with the 886 correct protocols. 888 9.1. STUN, DTLS, SRTP 890 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 891 protocol of a received packet among the STUN, Datagram Transport 892 Layer Security (DTLS) and SRTP protocols (in any combination). If an 893 offer or answer includes bundled "m=" section that represent these 894 protocols, the offerer or answerer MUST support the mechanism 895 described in [RFC5764], and no explicit negotiation is required in 896 order to indicate support and usage of the mechanism. 898 [RFC5764] does not describe how to identify different protocols 899 transported on DTLS, only how to identify the DTLS protocol itself. 900 If multiple protocols are transported on DTLS, there MUST exist a 901 specification describing a mechanism for identifying each individual 902 protocol. In addition, if a received DTLS packet can be associated 903 with more than one "m=" section, there MUST exist a specification 904 which describes a mechanism for associating the received DTLS packet 905 with the correct "m=" section. 907 [Section 10.2] describes how to associate the packets in a received 908 SRTP stream with the correct "m=" section. 910 10. RTP Considerations 912 10.1. Single RTP Session 914 All RTP-based media within a single BUNDLE group belong to a single 915 RTP session [RFC3550]. 917 Since a single BUNDLE transport is used for sending and receiving 918 bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for 919 RTP-based bundled media. 921 Since a single RTP session is used for each BUNDLE group, all "m=" 922 sections representing RTP-based media within a BUNDLE group will 923 share a single SSRC numbering space [RFC3550]. 925 The following rules and restrictions apply for a single RTP session: 927 o A specific payload type value can be used in multiple bundled "m=" 928 sections only if each codec associated with the payload type 929 number shares an identical codec configuration [Section 10.1.1]. 931 o The proto value in each bundled RTP-based "m=" section MUST be 932 identical (e.g. RTP/AVPF). 934 o The RTP MID header extension MUST be enabled, by including an SDP 935 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 936 hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section 937 in every offer and answer. 939 o A given SSRC MUST NOT transmit RTP packets using payload types 940 that originate from different bundled "m=" sections. 942 NOTE: The last bullet above is to avoid sending multiple media types 943 from the same SSRC. If transmission of multiple media types are done 944 with time overlap, RTP and RTCP fail to function. Even if done in 945 proper sequence this causes RTP Timestamp rate switching issues 946 [RFC7160]. However, once an SSRC has left the RTP session (by 947 sending an RTCP BYE packet), that SSRC can be reused by another 948 source (possibly associated with a different bundled "m=" section) 949 after a delay of 5 RTCP reporting intervals (the delay is to ensure 950 the SSRC has timed out, in case the RTCP BYE packet was lost 951 [RFC3550]). 953 10.1.1. Payload Type (PT) Value Reuse 955 Multiple bundled "m=" section might describe RTP based media. As all 956 RTP based media associated with a BUNDLE group belong to the same RTP 957 session, in order for a given payload type value to be used inside 958 more than one bundled "m=" section, all codecs associated with the 959 payload type number MUST share an identical codec configuration. 960 This means that the codecs MUST share the same media type, encoding 961 name, clock rate and any parameter that can affect the codec 962 configuration and packetization. 963 [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose 964 attribute values must be identical for all codecs that use the same 965 payload type value. 967 10.2. Associating RTP/RTCP Streams With Correct SDP Media Description 969 NOTE: The text in this section is copied from Appendix B of JSEP. 970 The community has not yet agreed on the text. 972 As described in [RFC3550], RTP packets are associated with RTP 973 streams [RFC7656]. Each RTP stream is identified by an SSRC value, 974 and each RTP packet includes an SSRC field that is used to associate 975 the packet with the correct RTP stream. RTCP packets also use SSRCs 976 to identify which RTP streams the packet relates to. However, a RTCP 977 packet can contain multiple SSRC fields, in the course of providing 978 feedback or reports on different RTP streams, and therefore can be 979 associated with multiple such streams. 981 In order to be able to process received RTP/RTCP packets correctly, 982 it must be possible to associate an RTP stream with the correct "m=" 983 section, as the "m=" section and SDP attributes associated with the 984 "m=" section contains information needed to process the packets. 986 As all RTP streams associated with a BUNDLE group use the same 987 transport for sending and receiving RTP/RTCP packets, the local 988 address:port combination part of the transport cannot be used to 989 associate an RTP stream with the correct "m=" section. In addition, 990 multiple RTP streams might be associated with the same "m=" section. 992 An offerer and answerer can inform each other which SSRC values they 993 will use for an RTP stream by using the SDP 'ssrc' attribute 994 [RFC5576]. However, an offerer will not know which SSRC values the 995 answerer will use until the offerer has received the answer providing 996 that information. Due to this, before the offerer has received the 997 answer, the offerer will not be able to associate an RTP stream with 998 the correct "m=" section using the SSRC value associated with the RTP 999 stream. In addition, the offerer and answerer may start using new 1000 SSRC values mid-session, without informing each other using the SDP 1001 'ssrc' attribute. 1003 In order for an offerer and answerer to always be able to associate 1004 an RTP stream with the correct "m=" section, the offerer and answerer 1005 using the BUNDLE extension MUST support the mechanism defined in 1006 Section 15, where the offerer and answerer insert the identification- 1007 tag associated with an "m=" section (provided by the remote peer) 1008 into RTP and RTCP packets associated with a BUNDLE group. 1010 When using this mechanism, the mapping from an SSRC to an 1011 identification-tag is carried in RTP header extensions or RTCP SDES 1012 packets, as specified in Section 15. Since a compound RTCP packet 1013 can contain multiple RTCP SDES packets, and each RTCP SDES packet can 1014 contain multiple chunks, a single RTCP packet can contain several 1015 SSRC to identification-tag mappings. The offerer and answerer 1016 maintain tables used for routing that are updated each time an RTP/ 1017 RTCP packet contains new information that affects how packets should 1018 be routed. 1020 However, some implementations of may not include this identification- 1021 tag in their RTP and RTCP traffic when using the BUNDLE mechanism, 1022 and instead use a payload type based mechanism to associate RTP 1023 streams with SDP "m=" sections. In this situation, each "m=" section 1024 MUST use unique payload type values, in order for the payload type to 1025 be a reliable indicator of the relevant "m=" section for the RTP 1026 stream. Note that when using the payload type to associate RTP 1027 streams with "m=" sections an RTP stream, identified by SSRC, will be 1028 mapped to an "m=" section when the first packet of that RTP stream is 1029 received, and the mapping will not be changed even if the payload 1030 type used by that RTP stream changes. In other words, the SSRC 1031 cannot to "move" to a different "m=" section simply by changing the 1032 payload type. 1034 Applications can implement RTP stacks in many different ways. The 1035 algorithm below details one way that RTP streams can be associated 1036 with "m=" sections, but is not meant to be prescriptive about exactly 1037 how an RTP stack needs to be implemented. Applications MAY use any 1038 algorithm that achieves equivalent results to those described in the 1039 algorithm below. 1041 To prepare to associate RTP streams with the correct "m=" section, 1042 the following steps MUST be followed for each BUNDLE group. 1044 Construct a table mapping MID to "m=" section for each "m=" 1045 section in this BUNDLE group. Note that an "m=" section may only 1046 have one MID. 1048 Construct a table mapping SSRCs of incoming RTP streams to "m=" 1049 section for each "m=" section in this BUNDLE group and for each 1050 SSRC configured for receiving in that "m=" section. 1052 Construct a table mapping the SSRC of each outgoing RTP stream to 1053 "m=" section for each "m=" section in this BUNDLE group and for 1054 each SSRC configured for sending in that "m=" section. 1056 Construct a table mapping payload type to "m=" section for each 1057 "m=" section in the BUNDLE group and for each payload type 1058 configured for receiving in that "m=" section. If any payload 1059 type is configured for receiving in more than one "m=" section in 1060 the BUNDLE group, do not it include it in the table, as it cannot 1061 be used to uniquely identify a "m=" section. 1063 Note that for each of these tables, there can only be one mapping 1064 for any given key (MID, SSRC, or PT). In other words, the tables 1065 are not multimaps. 1067 As "m=" sections are added or removed from the BUNDLE groups, or 1068 their configurations are changed, the tables above MUST also be 1069 updated. 1071 When an RTP packet is received, it MUST be delivered to the RTP 1072 stream corresponding to its SSRC. That RTP stream MUST then be 1073 associated with the correct "m=" section within a BUNDLE group, for 1074 additional processing, according to the following steps. 1076 If the MID associated with the RTP stream is not in the table 1077 mapping MID to "m=" section, then the RTP stream is not decoded 1078 and the payload data is discarded. 1080 If the packet has a MID, and the packet's extended sequence number 1081 is greater than that of the last MID update, as discussed in 1082 [RFC7941], Section 4.2.6, update the MID associated with the RTP 1083 stream to match the MID carried in the RTP packet, then update the 1084 mapping tables to include an entry that maps the SSRC of that RTP 1085 stream to the "m=" section for that MID. 1087 If the SSRC of the RTP stream is in the incoming SSRC mapping 1088 table, check that the payload type used by the RTP stream matches 1089 a payload type included on the matching "m=" section. If so, 1090 associate the RTP stream with that "m=" section. Otherwise, the 1091 RTP stream is not decoded and the payload data is discarded. 1093 If the payload type used by the RTP stream is in the payload type 1094 table, update the incoming SSRC mapping table to include an entry 1095 that maps the RTP stream's SSRC to the "m=" section for that 1096 payload type. Associate the RTP stream with the corresponding 1097 "m=" section. 1099 Otherwise, mark the RTP stream as not for decoding and discard the 1100 payload. 1102 If the RTP packet contains one of more contributing source (CSRC) 1103 identifiers, then each CSRC is looked up in the incoming SSRC table 1104 and a copy of the RTP packet is associated with the corresponding 1105 "m=" section for additional processing. 1107 For each RTCP packet received (including each RTCP packet that is 1108 part of a compound RTCP packet), the packet is processed as usual by 1109 the RTP layer, then is passed to the "m=" sections corresponding to 1110 the RTP streams it contains information about for additional 1111 processing. This routing is type-dependent, as each kind of RTCP 1112 packet has its own mechanism for associating it with the relevant RTP 1113 streams. 1115 RTCP packets for which no appropriate "m=" section can be identified 1116 MUST be processed as usual by the RTP layer, updating the metadata 1117 associated with the corresponding RTP streams, but are not passed to 1118 any "m=" section. This situation can occur with certain multiparty 1119 RTP topologies, or when RTCP packets are sent containing a subset of 1120 the SDES information. 1122 Rules for additional processing of the various types of RTCP packets 1123 are explained below. 1125 If the RTCP packet is of type SDES, for each chunk in the packet 1126 whose SSRC is found in the incoming SSRC table, deliver a copy of 1127 the SDES packet to the "m=" section associated with that SSRC. In 1128 addition, for any SDES MID items contained in these chunks, if the 1129 MID is found in the table mapping MID to "m=" section, update the 1130 incoming SSRC table to include an entry that maps the RTP stream 1131 associated with chunk's SSRC to the "m=" section associated with 1132 that MID, unless the packet is older than the packet that most 1133 recently updated the mapping for this SSRC, as discussed in 1134 [RFC7941], Section 4.2.6. 1136 Note that if an SDES packet is received as part of a compound RTCP 1137 packet, the SSRC to "m=" section mapping may not exist until the 1138 SDES packet is handled (e.g., in the case where RTCP for a source 1139 is received before any RTP packets). Therefore, when processing a 1140 compound packet, any contained SDES packet MUST be handled first. 1141 Note that this is a backwards change from [RFC3550] Section 6.1, 1142 which states that "Each individual RTCP packet in the compound 1143 packet may be processed independently with no requirements upon 1144 the order or combination of packets". 1146 If the RTCP packet is of type BYE, it indicates that the RTP 1147 streams referenced in the packet are ending. Therefore, for each 1148 SSRC indicated in the packet that is found in the incoming SSRC 1149 table, first deliver a copy of the BYE packet to the "m=" section 1150 associated with that SSRC, but then remove the entry for that SSRC 1151 from the incoming SSRC table after an appropriate delay to account 1152 for "straggler packets", as specified in [RFC3550], Section 6.2.1. 1154 If the RTCP packet is of type SR or RR, for each report block in 1155 the report whose "SSRC of source" is found in the outgoing SSRC 1156 table, deliver a copy of the SR or RR packet to the "m=" section 1157 associated with that SSRC. In addition, if the packet is of type 1158 SR, and the sender SSRC for the packet is found in the incoming 1159 SSRC table, deliver a copy of the SR packet to the "m=" section 1160 associated with that SSRC. 1162 If the implementation supports RTCP XR and the packet is of type 1163 XR, as defined in [RFC3611], for each report block in the report 1164 whose "SSRC of source" is is found in the outgoing SSRC table, 1165 deliver a copy of the XR packet to the "m=" section associated 1166 with that SSRC. In addition, if the sender SSRC for the packet is 1167 found in the incoming SSRC table, deliver a copy of the XR packet 1168 to the "m=" section associated with that SSRC. 1170 If the RTCP packet is a feedback message of type RTPFB or PSFB, as 1171 defined in [RFC4585], it will contain a media source SSRC, and 1172 this SSRC is used for routing certain subtypes of feedback 1173 messages. However, several subtypes of PSFB messages include 1174 target SSRC(s) in a section called Feedback Control Information 1175 (FCI). For these messages, the target SSRC(s) are used for 1176 routing. 1178 If the RTCP packet is a feedback packet that does not include 1179 target SSRCs in its FCI section, and the media source SSRC is 1180 found in the outgoing SSRC table, deliver the feedback packet to 1181 the "m=" section associated with that SSRC. RTPFB and PSFB types 1182 that are handled in this way include: 1184 Generic NACK: [RFC4585] (PT=RTPFB, FMT=1). 1186 Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1). 1188 Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2). 1190 Reference Picture Selection Indication (RPSI): [RFC4585] 1191 (PT=PSFB, FMT=3). 1193 If the RTCP packet is a feedback message that does include target 1194 SSRC(s) in its FCI section, it can either be a request or a 1195 notification. Requests reference a RTP stream that is being sent 1196 by the message recipient, whereas notifications are responses to 1197 an earlier request, and therefore reference a RTP stream that is 1198 being received by the message recipient. 1200 If the RTCP packet is a feedback request that includes target 1201 SSRC(s), for each target SSRC that is found in the outgoing SSRC 1202 table, deliver a copy of the RTCP packet to the "m=" section 1203 associated with that SSRC. PSFB types that are handled in this 1204 way include: 1206 Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). 1208 Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, 1209 FMT=5). 1211 H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, 1212 FMT=7). 1214 Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, 1215 FMT=TBD). 1217 If the RTCP packet is a feedback notification that include target 1218 SSRC(s), for each target SSRC that is found in the incoming SSRC 1219 table, deliver a copy of the RTCP packet to the "m=" section 1220 associated with the RTP stream with matching SSRC. PSFB types 1221 that are handled in this way include: 1223 Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] 1224 (PT=PSFB, FMT=6). This message is a notification in response 1225 to a prior TSTR. 1227 If the RTCP packet is of type APP, then it is handled in an 1228 application specific manner. If the application does not 1229 recognise the APP packet, then it MUST be discarded. 1231 10.3. RTP/RTCP Multiplexing 1233 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 1234 multiplexing [RFC5761] for the RTP-based media specified by the 1235 BUNDLE group. 1237 When RTP/RTCP multiplexing is enabled, the same transport will be 1238 used for both RTP packets and RTCP packets associated with the BUNDLE 1239 group. 1241 10.3.1. SDP Offer/Answer Procedures 1243 This section describes how an offerer and answerer use the SDP 'rtcp- 1244 mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute 1245 [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP 1246 multiplexing for RTP-based media associated with a BUNDLE group. 1248 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] of the SDP 1249 'rtcp-mux' and 'rtcp-mux-only' attributes is IDENTICAL. Section 8.1 1250 describes the details regarding which bundled "m=" sections an 1251 offerer and answerer associates the attributes with. 1253 RTP/RTCP multiplexing only applies to RTP-based media. However, as 1254 described in Section 8.1, within a BUNDLE group the SDP 'rtcp-mux' 1255 and SDP 'rtcp-mux-only' attributes might be included in a non-RTP- 1256 based bundled "m=" section. 1258 10.3.1.1. Generating the Initial SDP Offer 1260 When an offerer generates an initial offer, if the offer contains one 1261 or more RTP-based bundled "m=" sections (or, if there is a chance 1262 that RTP-based "m=" sections will later be added to the BUNDLE 1263 group), the offerer MUST include an SDP 'rtcp-mux' attribute 1264 [RFC5761] in one or more "m=" sections, following the procedures for 1265 IDENTICAL mux category attributes in Section 8.1. In addition, the 1266 offerer MAY include an SDP 'rtcp-mux-only' attribute 1267 [I-D.ietf-mmusic-mux-exclusive] in the same "m=" section. 1269 NOTE: Whether the offerer associates the SDP 'rtcp-mux-only' 1270 attribute depends on whether the offerer supports fallback to usage 1271 of a separate port for RTCP in case the answerer moves one or more 1272 RTP-based "m=" section out of the BUNDLE group in the answer. 1274 NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in one or 1275 more bundled "m=" sections, but does not include an SDP 'rtcp-mux- 1276 only' attribute, the offerer can also include an SDP 'rtcp' attribute 1277 [RFC3605] in one or more RTP-based "m=" sections in order to provide 1278 a fallback port for RTCP, as described in [RFC5761]. However, the 1279 fallback port will only be used for RTP-based "m=" sections moved out 1280 of the BUNDLE group by the answerer. 1282 In the initial offer, the address:port combination for RTCP MUST be 1283 unique in each bundled RTP-based "m=" section (excluding a bundle- 1284 only "m=" section), similar to RTP. 1286 10.3.1.2. Generating the SDP Answer 1288 When an answerer generates an answer, if the answerer supports RTP- 1289 based media, and if a bundled "m=" section in the offer contained an 1290 SDP 'rtcp-mux' attribute, the answerer MUST enable usage of RTP/RTCP 1291 multiplexing, even if there currently are no RTP-based "m=" sections 1292 within the BUNDLE group. The answerer MUST include an SDP 'rtcp-mux' 1293 attribute in "m=" sections within the BUNDLE group in the answer 1294 following the procedures for IDENTICAL mux category attributes in 1295 Section 8.1. In addition, if the "m=" section in the offer contained 1296 an an SDP "rtcp-mux-only" attribute, the answerer MUST include an SDP 1297 "rtcp-mux-only" attribute to the "m=" section in the answer. 1299 If the "m=" section associated with the offerer BUNDLE-tag in the 1300 offer contained an SDP 'rtcp-mux-only' attribute, and if the answerer 1301 moves an RTP-based "m=" section out of the BUNDLE group in the answer 1302 Section 8.3.3, the answerer MUST either include the attribute with in 1303 moved "m=" section (and enable RTP/RTCP multiplexing for the media 1304 associated with the "m=" section), or reject the "m=" section 1305 Section 8.3.4. 1307 The answerer MUST NOT include an SDP 'rtcp' attribute in any "m=" 1308 section within the BUNDLE group in the answer. The answerer will use 1309 the port value of the selected offerer BUNDLE address for sending RTP 1310 and RTCP packets associated with each RTP-based bundled "m=" section 1311 towards the offerer. 1313 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1314 negotiated in a previous offer/answer transaction, the answerer MUST 1315 include an SDP 'rtcp-mux' attribute in the "m=" section associated 1316 with the answerer BUNDLE-tag in the answer. It is not possible to 1317 disable RTP/RTCP multiplexing within a BUNDLE group. 1319 10.3.1.3. Offerer Processing of the SDP Answer 1321 When an offerer receives an answer, if the answerer has accepted the 1322 usage of RTP/RTCP multiplexing (see Section 10.3.1.2), the answerer 1323 follows the procedures for RTP/RTCP multiplexing defined in 1324 [RFC5761]. The offerer will use the port value associated with the 1325 answerer BUNDLE address for sending RTP and RTCP packets associated 1326 with each RTP-based bundled "m=" section towards the answerer. 1328 NOTE: It is considered a protocol error if the answerer has not 1329 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" 1330 sections that the answerer included in the BUNDLE group. 1332 10.3.1.4. Modifying the Session 1334 When an offerer generates a subsequent offer, the offerer MUST 1335 include an SDP 'rtcp-mux' attribute in a bundled "m=" section, 1336 following the procedures for IDENTICAL mux category attributes in 1337 Section 8.1. 1339 If the offerer wants to add a bundled RTP-based "m=" section to the 1340 BUNDLE group, it MAY also include an SDP 'rtcp-mux-only' attribute in 1341 a bundled "m=" section, following the procedures for IDENTICAL mux 1342 category attributes in Section 8.1. This allows the offerer to 1343 mandate RTP/RTCP multiplexing for the added "m=" section (or the "m=" 1344 section to be rejected by the answerer) even if the answerer does not 1345 accept the "m=" section within the BUNDLE group. 1347 11. ICE Considerations 1349 This section describes how to use the BUNDLE grouping extension 1350 together with the Interactive Connectivity Establishment (ICE) 1351 mechanism [I-D.ietf-ice-rfc5245bis]. 1353 The generic procedures for negotiating usage of ICE using SDP, 1354 defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE 1355 with BUNDLE, with the following exceptions: 1357 o When the BUNDLE transport has been established, ICE connectivity 1358 checks and keep-alives only need to be performed for the BUNDLE 1359 transport, instead of per individual "m=" section within the 1360 BUNDLE group. 1362 o Among bundled "m=" sections (including any bundle-only "m=" 1363 section) to which the offerer has assigned a shared address, the 1364 offerer only includes ICE-related media-level SDP attributes in 1365 the "m=" section associated with the offerer BUNDLE-tag, following 1366 the procedures in Section 8.1. 1368 o Among "m=" sections within a BUNDLE group, to which the answerer 1369 has assigned a shared address within, the answerer only includes 1370 ICE-related media-level SDP attributes in the "m=" section 1371 associated with the answerer BUNDLE-tag, following the procedures 1372 in Section 8.1. 1374 Initially, before ICE has produced a candidate pair that will be used 1375 for media, there might by multiple transports established (if 1376 multiple candidate pairs are tested). Once ICE has produced a 1377 transport that will be used for media, that becomes the BUNDLE 1378 transport. 1380 Support and usage of ICE mechanism together with the BUNDLE extension 1381 is OPTIONAL. 1383 11.1. SDP Offer/Answer Procedures 1385 When an offerer assigns a unique address to a bundled "m=" section 1386 (excluding any bundle-only "m=" section), the offerer MUST include 1387 SDP 'candidate' attributes (and other applicable ICE-related media- 1388 level SDP attributes), containing unique ICE properties (candidates 1389 etc), in the "m=" section according to the procedures in 1390 [I-D.ietf-mmusic-ice-sip-sdp]. 1392 When an offerer assigns a shared address to a bundled "m=" section, 1393 the offerer MUST include SDP 'candidate' attributes (and other 1394 applicable ICE-related media-level SDP attributes) in the "m=" 1395 section following the procedures in Section 8.1. 1397 When an answerer assigns a shared address to an "m=" section within a 1398 BUNDLE group, the answerer MUST include SDP 'candidate' attributes 1399 (and other applicable ICE-related media-level SDP attributes) in the 1400 "m=" section following the procedures in Section 8.1. 1402 NOTE: As most ICE-related media-level SDP attributes belong to the 1403 TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the 1404 offerer and answerer follow the procedures in Section 8.1 when 1405 deciding whether to include an attribute in a bundled "m=" section. 1406 However, in the case of ICE-related media-level attributes, the rules 1407 apply to all attributes (see note below), even if they belong to a 1408 different mux category. 1410 NOTE: The following ICE-related media-level SDP attributes are 1411 defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote- 1412 candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- 1413 pacing'. 1415 11.1.1. Generating the Initial SDP Offer 1417 When an offerer generates an initial offer, the offerer MUST include 1418 ICE-related media-level SDP attributes in bundled "m=" sections 1419 following the procedures in [Section 11.1]. 1421 11.1.2. Generating the SDP Answer 1423 When an answerer generates an answer that contains a BUNDLE group, 1424 the answer MUST include ICE-related SDP attributes in "m=" sections 1425 within the BUNDLE group according to [Section 11.1]. 1427 11.1.3. Offerer Processing of the SDP Answer 1429 When an offerer receives an answer, if the answerer supports and uses 1430 the ICE mechanism and the BUNDLE extension, the offerer MUST apply 1431 the ICE properties associated with the offerer BUNDLE address, 1432 selected by the answerer [Section 8.3.1], to each bundled "m=" 1433 section. 1435 11.1.4. Modifying the Session 1437 When an offerer generates a subsequent offer, it MUST include ICE- 1438 related SDP attributes in a bundled "m=" section following the 1439 procedures in [Section 11.1]. 1441 12. DTLS Considerations 1443 One or more media streams within a BUNDLE group might use the 1444 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1445 to encrypt the data, or to negotiate encryption keys if another 1446 encryption mechanism is used to encrypt media. 1448 When DTLS is used within a BUNDLE group, the following rules apply: 1450 o There can only be one DTLS association [RFC6347] associated with 1451 the BUNDLE group; and 1453 o Each usage of the DTLS association within the BUNDLE group MUST 1454 use the same mechanism for determining which endpoints (the 1455 offerer or answerer) become DTLS client and DTLS server; and 1457 o Each usage of the DTLS association within the Bundle group MUST 1458 use the same mechanism for determining whether an offer or answer 1459 will trigger the establishment of a new DTLS association, or 1460 whether an existing DTLS association will be used; and 1462 o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include 1463 the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message 1464 [RFC5764], The client MUST include the extension even if the usage 1465 of DTLS-SRTP is not negotiated as part of the multimedia session 1466 (e.g., SIP session [RFC3261]. 1468 NOTE: The inclusion of the 'use_srtp' extension during the initial 1469 DTLS handshake ensures that a DTLS renegotiation will not be required 1470 in order to include the extension, in case DTLS-SRTP encrypted media 1471 is added to the BUNDLE group later during the multimedia session. 1473 13. RTP Header Extensions Consideration 1475 When [RFC8285] RTP header extensions are used in the context of this 1476 specification, the identifier used for a given extension MUST 1477 identify the same extension across all the bundled media 1478 descriptions. 1480 14. Update to RFC 3264 1482 This section replaces the text of the following sections of RFC 3264: 1484 o Section 5.1 (Unicast Streams). 1486 o Section 8.2 (Removing a Media Stream). 1488 o Section 8.4 (Putting a Unicast Media Stream on Hold). 1490 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 1492 For recvonly and sendrecv streams, the port number and address in the 1493 offer indicate where the offerer would like to receive the media 1494 stream. For sendonly RTP streams, the address and port number 1495 indirectly indicate where the offerer wants to receive RTCP reports. 1496 Unless there is an explicit indication otherwise, reports are sent to 1497 the port number one higher than the number indicated. The IP address 1498 and port present in the offer indicate nothing about the source IP 1499 address and source port of RTP and RTCP packets that will be sent by 1500 the offerer. A port number of zero in the offer indicates that the 1501 stream is offered but MUST NOT be used. This has no useful semantics 1502 in an initial offer, but is allowed for reasons of completeness, 1503 since the answer can contain a zero port indicating a rejected stream 1504 (Section 6). Furthermore, existing streams can be terminated by 1505 setting the port to zero (Section 8). In general, a port number of 1506 zero indicates that the media stream is not wanted. 1508 14.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 1510 For recvonly and sendrecv streams, the port number and address in the 1511 offer indicate where the offerer would like to receive the media 1512 stream. For sendonly RTP streams, the address and port number 1513 indirectly indicate where the offerer wants to receive RTCP reports. 1514 Unless there is an explicit indication otherwise, reports are sent to 1515 the port number one higher than the number indicated. The IP address 1516 and port present in the offer indicate nothing about the source IP 1517 address and source port of RTP and RTCP packets that will be sent by 1518 the offerer. A port number of zero in the offer by default indicates 1519 that the stream is offered but MUST NOT be used, but an extension 1520 mechanism might specify different semantics for the usage of a zero 1521 port value. Furthermore, existing streams can be terminated by 1522 setting the port to zero (Section 8). In general, a port number of 1523 zero by default indicates that the media stream is not wanted. 1525 14.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 1527 A stream that is offered with a port of zero MUST be marked with port 1528 zero in the answer. Like the offer, the answer MAY omit all 1529 attributes present previously, and MAY list just a single media 1530 format from amongst those in the offer. 1532 14.4. New text replacing section 8.2 (2nd paragraph) of RFC 3264 1534 A stream that is offered with a port of zero MUST by default be 1535 marked with port zero in the answer, unless an extension mechanism, 1536 which specifies semantics for the usage of a non-zero port value, is 1537 used. If the stream is marked with port zero in the answer, the 1538 answer MAY omit all attributes present previously, and MAY list just 1539 a single media format from amongst those in the offer." 1541 14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 1543 RFC 2543 [10] specified that placing a user on hold was accomplished 1544 by setting the connection address to 0.0.0.0. Its usage for putting 1545 a call on hold is no longer recommended, since it doesn't allow for 1546 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1547 with connection oriented media. However, it can be useful in an 1548 initial offer when the offerer knows it wants to use a particular set 1549 of media streams and formats, but doesn't know the addresses and 1550 ports at the time of the offer. Of course, when used, the port 1551 number MUST NOT be zero, which would specify that the stream has been 1552 disabled. An agent MUST be capable of receiving SDP with a 1553 connection address of 0.0.0.0, in which case it means that neither 1554 RTP nor RTCP should be sent to the peer. 1556 14.6. New text replacing section 8.4 (6th paragraph) of RFC 3264 1558 RFC 2543 [10] specified that placing a user on hold was accomplished 1559 by setting the connection address to 0.0.0.0. Its usage for putting 1560 a call on hold is no longer recommended, since it doesn't allow for 1561 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1562 with connection oriented media. However, it can be useful in an 1563 initial offer when the offerer knows it wants to use a particular set 1564 of media streams and formats, but doesn't know the addresses and 1565 ports at the time of the offer. Of course, when used, the port 1566 number MUST NOT be zero, if it would specify that the stream has been 1567 disabled. However, an extension mechanism might specify different 1568 semantics of the zero port number usage. An agent MUST be capable of 1569 receiving SDP with a connection address of 0.0.0.0, in which case it 1570 means that neither RTP nor RTCP should be sent to the peer. 1572 15. RTP/RTCP extensions for identification-tag transport 1574 SDP Offerers and Answerers [RFC3264] can associate identification- 1575 tags with "m=" sections within SDP Offers and Answers, using the 1576 procedures in [RFC5888]. Each identification-tag uniquely represents 1577 an "m=" section. 1579 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1580 used to carry identification-tags within RTCP SDES packets. This 1581 section also defines a new RTP SDES header extension [RFC7941], which 1582 is used to carry the 'MID' RTCP SDES item in RTP packets. 1584 The SDES item and RTP SDES header extension make it possible for a 1585 receiver to associate each RTP stream with with a specific "m=" 1586 section, with which the receiver has associated an identification- 1587 tag, even if those "m=" sections are part of the same RTP session. 1588 The RTP SDES header extension also ensures that the media recipient 1589 gets the identification-tag upon receipt of the first decodable media 1590 and is able to associate the media with the correct application. 1592 A media recipient informs the media sender about the identification- 1593 tag associated with an "m=" section through the use of an 'mid' 1594 attribute [RFC5888]. The media sender then inserts the 1595 identification-tag in RTCP and RTP packets sent to the media 1596 recipient. 1598 NOTE: This text above defines how identification-tags are carried in 1599 SDP Offers and Answers. The usage of other signalling protocols for 1600 carrying identification-tags is not prevented, but the usage of such 1601 protocols is outside the scope of this document. 1603 [RFC3550] defines general procedures regarding the RTCP transmission 1604 interval. The RTCP MID SDES item SHOULD be sent in the first few 1605 RTCP packets sent after joining the session, and SHOULD be sent 1606 regularly thereafter. The exact number of RTCP packets in which this 1607 SDES item is sent is intentionally not specified here, as it will 1608 depend on the expected packet loss rate, the RTCP reporting interval, 1609 and the allowable overhead. 1611 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1612 be included in some RTP packets at the start of the session and 1613 whenever the SSRC changes. It might also be useful to include the 1614 header extension in RTP packets that comprise access points in the 1615 media (e.g., with video I-frames). The exact number of RTP packets 1616 in which this header extension is sent is intentionally not specified 1617 here, as it will depend on expected packet loss rate and loss 1618 patterns, the overhead the application can tolerate, and the 1619 importance of immediate receipt of the identification-tag. 1621 For robustness purpose, endpoints need to be prepared for situations 1622 where the reception of the identification-tag is delayed, and SHOULD 1623 NOT terminate sessions in such cases, as the identification-tag is 1624 likely to arrive soon. 1626 15.1. RTCP MID SDES Item 1628 0 1 2 3 1629 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 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | MID=TBD | length | identification-tag ... 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 The identification-tag payload is UTF-8 encoded, as in SDP. 1636 The identification-tag is not zero terminated. 1638 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1639 identifier value.] 1641 15.2. RTP SDES Header Extension For MID 1643 The payload, containing the identification-tag, of the RTP SDES 1644 header extension element can be encoded using either the one-byte or 1645 two-byte header [RFC7941]. The identification-tag payload is UTF-8 1646 encoded, as in SDP. 1648 The identification-tag is not zero terminated. Note, that the set of 1649 header extensions included in the packet needs to be padded to the 1650 next 32-bit boundary using zero bytes [RFC8285]. 1652 As the identification-tag is included in either an RTCP SDES item or 1653 an RTP SDES header extension, or both, there should be some 1654 consideration about the packet expansion caused by the 1655 identification-tag. To avoid Maximum Transmission Unit (MTU) issues 1656 for the RTP packets, the header extension's size needs to be taken 1657 into account when encoding the media. 1659 It is recommended that the identification-tag is kept short. Due to 1660 the properties of the RTP header extension mechanism, when using the 1661 one-byte header, a tag that is 1-3 bytes will result in a minimal 1662 number of 32-bit words used for the RTP SDES header extension, in 1663 case no other header extensions are included at the same time. Note, 1664 do take into account that some single characters when UTF-8 encoded 1665 will result in multiple octets. The identification-tag MUST NOT 1666 contain any user information, and applications SHALL avoid generating 1667 the identification-tag using a pattern that enables application 1668 identification. 1670 16. IANA Considerations 1672 16.1. New SDES item 1674 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1675 document.] 1677 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1678 identifier value.] 1680 This document adds the MID SDES item to the IANA "RTP SDES item 1681 types" registry as follows: 1683 Value: TBD 1684 Abbrev.: MID 1685 Name: Media Identification 1686 Reference: RFCXXXX 1688 16.2. New RTP SDES Header Extension URI 1690 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1691 document.] 1692 This document defines a new extension URI in the RTP SDES Compact 1693 Header Extensions sub-registry of the RTP Compact Header Extensions 1694 registry sub-registry, according to the following data: 1696 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1697 Description: Media identification 1698 Contact: christer.holmberg@ericsson.com 1699 Reference: RFCXXXX 1701 The SDES item does not reveal privacy information about the users. 1702 It is simply used to associate RTP-based media with the correct SDP 1703 media description ("m=" section) in the SDP used to negotiate the 1704 media. 1706 The purpose of the extension is for the offerer to be able to 1707 associate received multiplexed RTP-based media before the offerer 1708 receives the associated SDP answer. 1710 16.3. New SDP Attribute 1712 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1713 document.] 1715 This document defines a new SDP media-level attribute, 'bundle-only', 1716 according to the following data: 1718 Attribute name: bundle-only 1719 Type of attribute: media 1720 Subject to charset: No 1721 Purpose: Request a media description to be accepted 1722 in the answer only if kept within a BUNDLE 1723 group by the answerer. 1724 Appropriate values: N/A 1725 Contact name: Christer Holmberg 1726 Contact e-mail: christer.holmberg@ericsson.com 1727 Reference: RFCXXXX 1728 Mux category: NORMAL 1730 16.4. New SDP Group Semantics 1732 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1733 document.] 1734 This document registers the following semantics with IANA in the 1735 "Semantics for the "group" SDP Attribute" subregistry (under the 1736 "Session Description Protocol (SDP) Parameters" registry: 1738 Semantics Token Reference 1739 ------------------------------------- ------ --------- 1740 Media bundling BUNDLE [RFCXXXX] 1742 17. Security Considerations 1744 The security considerations defined in [RFC3264] and [RFC5888] apply 1745 to the BUNDLE extension. Bundle does not change which information, 1746 e.g., RTP streams, flows over the network, with the exception of the 1747 usage of the MID SDES item as discussed below. Primarily it changes 1748 which addresses and ports, and thus in which (RTP) sessions that the 1749 information is flowing in. This affects the security contexts being 1750 used and can cause previously separated information flows to share 1751 the same security context. This has very little impact on the 1752 performance of the security mechanism of the RTP sessions. In cases 1753 where one would have applied different security policies on the 1754 different RTP streams being bundled, or where the parties having 1755 access to the security contexts would have differed between the RTP 1756 stream, additional analysis of the implications are needed before 1757 selecting to apply BUNDLE. 1759 The identification-tag, independent of transport, RTCP SDES packet or 1760 RTP header extension, can expose the value to parties beyond the 1761 signaling chain. Therefore, the identification-tag values MUST be 1762 generated in a fashion that does not leak user information, e.g., 1763 randomly or using a per-bundle group counter, and SHOULD be 3 bytes 1764 or less, to allow them to efficiently fit into the MID RTP header 1765 extension. Note that if implementations use different methods for 1766 generating identification-tags this could enable fingerprinting of 1767 the implementation making it vulnerable to targeted attacks. The 1768 identification-tag is exposed on the RTP stream level when included 1769 in the RTP header extensions, however what it reveals of the RTP 1770 media stream structure of the endpoint and application was already 1771 possible to deduce from the RTP streams without the MID SDES header 1772 extensions. As the identification-tag is also used to route the 1773 media stream to the right application functionality it is also 1774 important that the value received is the one intended by the sender, 1775 thus integrity and the authenticity of the source are important to 1776 prevent denial of service on the application. Existing SRTP 1777 configurations and other security mechanisms protecting the whole 1778 RTP/RTCP packets will provide the necessary protection. 1780 When the BUNDLE extension is used, the set of configurations of the 1781 security mechanism used in all the bundled media descriptions will 1782 need to be compatible so that they can simultaneously used in 1783 parallel, at least per direction or endpoint. When using SRTP this 1784 will be the case, at least for the IETF defined key-management 1785 solutions due to their SDP attributes (a=crypto, a=fingerprint, 1786 a=mikey) and their classification in 1787 [I-D.ietf-mmusic-sdp-mux-attributes]. 1789 The security considerations of "RTP Header Extension for the RTP 1790 Control Protocol (RTCP) Source Description Items" [RFC7941] requires 1791 that when RTCP is confidentiality protected that any SDES RTP header 1792 extension carrying an SDES item, such as the MID RTP header 1793 extension, is also protected using commensurate strength algorithms. 1794 However, assuming the above requirements and recommendations are 1795 followed there are no known significant security risks with leaving 1796 the MID RTP header extension without confidentiality protection. 1797 Thus, the requirements in RFC 7941 MAY be ignored for the MID RTP 1798 header extension. Security mechanisms for RTP/RTCP are discussed in 1799 Options for Securing RTP Sessions [RFC7201], for example SRTP 1800 [RFC3711] can provide the necessary security functions of ensuring 1801 the integrity and source authenticity. 1803 18. Examples 1805 18.1. Example: Bundle Address Selection 1807 The example below shows: 1809 o An offer, in which the offerer assigns a unique address to each 1810 bundled "m=" section within the BUNDLE group. 1812 o An answer, in which the answerer selects the offerer BUNDLE 1813 address, and then selects its own BUNDLE address (the answerer 1814 BUNDLE address) and assigns it to each bundled "m=" section within 1815 the BUNDLE group. 1817 SDP Offer (1) 1819 v=0 1820 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1821 s= 1822 c=IN IP4 atlanta.example.com 1823 t=0 0 1824 a=group:BUNDLE foo bar 1825 m=audio 10000 RTP/AVP 0 8 97 1826 b=AS:200 1827 a=mid:foo 1828 a=rtcp-mux 1829 a=rtpmap:0 PCMU/8000 1830 a=rtpmap:8 PCMA/8000 1831 a=rtpmap:97 iLBC/8000 1832 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1833 m=video 10002 RTP/AVP 31 32 1834 b=AS:1000 1835 a=mid:bar 1836 a=rtcp-mux 1837 a=rtpmap:31 H261/90000 1838 a=rtpmap:32 MPV/90000 1839 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1841 SDP Answer (2) 1843 v=0 1844 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1845 s= 1846 c=IN IP4 biloxi.example.com 1847 t=0 0 1848 a=group:BUNDLE foo bar 1849 m=audio 20000 RTP/AVP 0 1850 b=AS:200 1851 a=mid:foo 1852 a=rtcp-mux 1853 a=rtpmap:0 PCMU/8000 1854 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1855 m=video 20000 RTP/AVP 32 1856 b=AS:1000 1857 a=mid:bar 1858 a=rtpmap:32 MPV/90000 1859 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1861 18.2. Example: BUNDLE Extension Rejected 1863 The example below shows: 1865 o An offer, in which the offerer assigns a unique address to each 1866 bundled "m=" section within the BUNDLE group. 1868 o An answer, in which the answerer rejects the offered BUNDLE group, 1869 and assigns a unique address to each "m=" section (following 1870 normal RFC 3264 procedures). 1872 SDP Offer (1) 1874 v=0 1875 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1876 s= 1877 c=IN IP4 atlanta.example.com 1878 t=0 0 1879 a=group:BUNDLE foo bar 1880 m=audio 10000 RTP/AVP 0 8 97 1881 b=AS:200 1882 a=mid:foo 1883 a=rtcp-mux 1884 a=rtpmap:0 PCMU/8000 1885 a=rtpmap:8 PCMA/8000 1886 a=rtpmap:97 iLBC/8000 1887 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1888 m=video 10002 RTP/AVP 31 32 1889 b=AS:1000 1890 a=mid:bar 1891 a=rtcp-mux 1892 a=rtpmap:31 H261/90000 1893 a=rtpmap:32 MPV/90000 1894 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1896 SDP Answer (2) 1898 v=0 1899 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1900 s= 1901 c=IN IP4 biloxi.example.com 1902 t=0 0 1903 m=audio 20000 RTP/AVP 0 1904 b=AS:200 1905 a=rtcp-mux 1906 a=rtpmap:0 PCMU/8000 1907 m=video 30000 RTP/AVP 32 1908 b=AS:1000 1909 a=rtcp-mux 1910 a=rtpmap:32 MPV/90000 1912 18.3. Example: Offerer Adds A Media Description To A BUNDLE Group 1914 The example below shows: 1916 o A subsequent offer (the BUNDLE group has been created as part of a 1917 previous offer/answer exchange), in which the offerer adds a new 1918 "m=" section, represented by the "zen" identification-tag, to a 1919 previously negotiated BUNDLE group, associates a unique address 1920 with the added "m=" section, and assigns the previously selected 1921 offerer BUNDLE address to each of the other bundled "m=" sections 1922 within the BUNDLE group. 1924 o An answer, in which the answerer assigns the answerer BUNDLE 1925 address to each bundled "m=" section (including the newly added 1926 "m=" section) within the BUNDLE group. 1928 SDP Offer (1) 1930 v=0 1931 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1932 s= 1933 c=IN IP4 atlanta.example.com 1934 t=0 0 1935 a=group:BUNDLE foo bar zen 1936 m=audio 10000 RTP/AVP 0 8 97 1937 b=AS:200 1938 a=mid:foo 1939 a=rtcp-mux 1940 a=rtpmap:0 PCMU/8000 1941 a=rtpmap:8 PCMA/8000 1942 a=rtpmap:97 iLBC/8000 1943 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1944 m=video 10000 RTP/AVP 31 32 1945 b=AS:1000 1946 a=mid:bar 1947 a=rtpmap:31 H261/90000 1948 a=rtpmap:32 MPV/90000 1949 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1950 m=video 20000 RTP/AVP 66 1951 b=AS:1000 1952 a=mid:zen 1953 a=rtcp-mux 1954 a=rtpmap:66 H261/90000 1955 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1957 SDP Answer (2) 1959 v=0 1960 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1961 s= 1962 c=IN IP4 biloxi.example.com 1963 t=0 0 1964 a=group:BUNDLE foo bar zen 1965 m=audio 20000 RTP/AVP 0 1966 b=AS:200 1967 a=mid:foo 1968 a=rtcp-mux 1969 a=rtpmap:0 PCMU/8000 1970 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1971 m=video 20000 RTP/AVP 32 1972 b=AS:1000 1973 a=mid:bar 1974 a=rtpmap:32 MPV/90000 1975 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1976 m=video 20000 RTP/AVP 66 1977 b=AS:1000 1978 a=mid:zen 1979 a=rtpmap:66 H261/90000 1980 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1982 18.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 1984 The example below shows: 1986 o A subsequent offer (the BUNDLE group has been created as part of a 1987 previous offer/answer transaction), in which the offerer moves a 1988 bundled "m=" section out of a BUNDLE group, assigns a unique 1989 address to the moved "m=" section, and assigns the offerer BUNDLE 1990 address to each other bundled "m=" section within the BUNDLE 1991 group. 1993 o An answer, in which the answerer moves the "m=" section out of the 1994 BUNDLE group, assigns a unique address to the moved "m=" section, 1995 and assigns the answerer BUNDLE address to each of the remaining 1996 bundled "m=" sections within the BUNDLE group. 1998 SDP Offer (1) 2000 v=0 2001 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2002 s= 2003 c=IN IP4 atlanta.example.com 2004 t=0 0 2005 a=group:BUNDLE foo bar 2006 m=audio 10000 RTP/AVP 0 8 97 2007 b=AS:200 2008 a=mid:foo 2009 a=rtcp-mux 2010 a=rtpmap:0 PCMU/8000 2011 a=rtpmap:8 PCMA/8000 2012 a=rtpmap:97 iLBC/8000 2013 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2014 m=video 10000 RTP/AVP 31 32 2015 b=AS:1000 2016 a=mid:bar 2017 a=rtpmap:31 H261/90000 2018 a=rtpmap:32 MPV/90000 2019 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2020 m=video 50000 RTP/AVP 66 2021 b=AS:1000 2022 a=mid:zen 2023 a=rtcp-mux 2024 a=rtpmap:66 H261/90000 2026 SDP Answer (2) 2028 v=0 2029 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2030 s= 2031 c=IN IP4 biloxi.example.com 2032 t=0 0 2033 a=group:BUNDLE foo bar 2034 m=audio 20000 RTP/AVP 0 2035 b=AS:200 2036 a=mid:foo 2037 a=rtcp-mux 2038 a=rtpmap:0 PCMU/8000 2039 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2040 m=video 20000 RTP/AVP 32 2041 b=AS:1000 2042 a=mid:bar 2043 a=rtpmap:32 MPV/90000 2044 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2045 m=video 60000 RTP/AVP 66 2046 b=AS:1000 2047 a=mid:zen 2048 a=rtcp-mux 2049 a=rtpmap:66 H261/90000 2051 18.5. Example: Offerer Disables A Media Description Within A BUNDLE 2052 Group 2054 The example below shows: 2056 o A subsequent offer (the BUNDLE group has been created as part of a 2057 previous offer/answer transaction), in which the offerer disables 2058 a bundled "m=" section within a BUNDLE group, assigns a zero port 2059 number to the disabled "m=" section, and assigns the offerer 2060 BUNDLE address to each of the other bundled "m=" sections within 2061 the BUNDLE group. 2063 o An answer, in which the answerer moves the disabled "m=" sections 2064 out of the BUNDLE group, assigns a zero port value to the disabled 2065 "m=" section, and assigns the answerer BUNDLE address to each of 2066 the remaining bundled "m=" sections within the BUNDLE group. 2068 SDP Offer (1) 2070 v=0 2071 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2072 s= 2073 c=IN IP4 atlanta.example.com 2074 t=0 0 2075 a=group:BUNDLE foo bar 2076 m=audio 10000 RTP/AVP 0 8 97 2077 b=AS:200 2078 a=mid:foo 2079 a=rtcp-mux 2080 a=rtpmap:0 PCMU/8000 2081 a=rtpmap:8 PCMA/8000 2082 a=rtpmap:97 iLBC/8000 2083 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2084 m=video 10000 RTP/AVP 31 32 2085 b=AS:1000 2086 a=mid:bar 2087 a=rtpmap:31 H261/90000 2088 a=rtpmap:32 MPV/90000 2089 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2090 m=video 0 RTP/AVP 66 2091 a=mid:zen 2092 a=rtpmap:66 H261/90000 2094 SDP Answer (2) 2096 v=0 2097 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2098 s= 2099 c=IN IP4 biloxi.example.com 2100 t=0 0 2101 a=group:BUNDLE foo bar 2102 m=audio 20000 RTP/AVP 0 2103 b=AS:200 2104 a=mid:foo 2105 a=rtcp-mux 2106 a=rtpmap:0 PCMU/8000 2107 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2108 m=video 20000 RTP/AVP 32 2109 b=AS:1000 2110 a=mid:bar 2111 a=rtpmap:32 MPV/90000 2112 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2113 m=video 0 RTP/AVP 66 2114 a=mid:zen 2115 a=rtpmap:66 H261/90000 2117 19. Acknowledgements 2119 The usage of the SDP grouping extension for negotiating bundled media 2120 is based on a similar alternatives proposed by Harald Alvestrand and 2121 Cullen Jennings. The BUNDLE extension described in this document is 2122 based on the different alternative proposals, and text (e.g., SDP 2123 examples) have been borrowed (and, in some cases, modified) from 2124 those alternative proposals. 2126 The SDP examples are also modified versions from the ones in the 2127 Alvestrand proposal. 2129 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 2130 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 2131 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin 2132 Uberti, Taylor Brandstetter, Byron Campen and Eric Rescorla for 2133 reading the text, and providing useful feedback. 2135 Thanks to Bernard Aboba, Cullen Jennings, Peter Thatcher, Justin 2136 Uberti, and Magnus Westerlund for providing the text for the section 2137 on RTP/RTCP stream association. 2139 Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for 2140 providing help and text on the RTP/RTCP procedures. 2142 Thanks to Spotify for providing music for the countless hours of 2143 document editing. 2145 20. Change Log 2147 [RFC EDITOR NOTE: Please remove this section when publishing] 2149 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39 2151 o Editorial terminology changes. 2153 o RFC 5285 reference replaced by reference to RFC 8285. 2155 o https://github.com/cdh4u/draft-sdp-bundle/pull/44 2157 o - Clarify that an m- section can not be moved between BUNDLE 2158 groups without first moving the m- section out of a BUNDLE group. 2160 o https://github.com/cdh4u/draft-sdp-bundle/pull/41 2162 o - Addition of BUNDLE transport concept. 2164 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38 2166 o Changes to RTP streaming mapping section based on text from Colin 2167 Perkins. 2169 o The following GitHub pull requests were merged: 2171 o https://github.com/cdh4u/draft-sdp-bundle/pull/34 2173 o - Proposed updates to RTP processing 2175 o https://github.com/cdh4u/draft-sdp-bundle/pull/35 2177 o - fixed reference to receiver-id section 2179 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-37 2181 o The following GitHub pull request was merged: 2183 o https://github.com/cdh4u/draft-sdp-bundle/pull/33 2185 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36 2187 o The following GitHub pull requests were merged: 2189 o https://github.com/cdh4u/draft-sdp-bundle/pull/32 2190 o - extmap handling in BUNDLE. 2192 o https://github.com/cdh4u/draft-sdp-bundle/pull/31 2194 o - Additional Acknowledgement text added. 2196 o https://github.com/cdh4u/draft-sdp-bundle/pull/30 2198 o - MID SDES item security procedures updated 2200 o https://github.com/cdh4u/draft-sdp-bundle/pull/29 2202 o - Appendix B of JSEP moved into BUNDLE. 2204 o - Associating RTP/RTCP packets with SDP m- lines. 2206 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35 2208 o Editorial changes on RTP streaming mapping section based on 2209 comments from Colin Perkins. 2211 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34 2213 o RTP streams, instead of RTP packets, are associated with m- lines. 2215 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 2217 o Editorial changes based on comments from Eric Rescorla and Cullen 2218 Jennings: 2220 o - Changes regarding usage of RTP/RTCP multiplexing attributes. 2222 o - Additional text regarding associating RTP/RTCP packets with SDP 2223 m- lines. 2225 o - Reference correction. 2227 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32 2229 o Editorial changes based on comments from Eric Rescorla and Cullen 2230 Jennings: 2232 o - Justification for mechanism added to Introduction. 2234 o - Clarify that the order of m- lines in the group:BUNDLE attribute 2235 does not have to be the same as the order in which the m- lines 2236 are listed in the SDP. 2238 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31 2240 o Editorial changes based on GitHub Pull requests by Martin Thomson: 2242 o - https://github.com/cdh4u/draft-sdp-bundle/pull/2 2244 o - https://github.com/cdh4u/draft-sdp-bundle/pull/1 2246 o Editorial change based on comment from Diederick Huijbers (9th 2247 July 2016). 2249 o Changes based on comments from Flemming Andreasen (21st June 2250 2016): 2252 o - Mux category for SDP bundle-only attribute added. 2254 o - Mux category considerations editorial clarification. 2256 o - Editorial changes. 2258 o RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext. 2260 o Note whether Design Considerations appendix is to be kept removed: 2262 o - Appendix is kept within document. 2264 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30 2266 o Indicating in the Abstract and Introduction that the document 2267 updates RFC 3264. 2269 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29 2271 o Change based on WGLC comment from Colin Perkins. 2273 o - Clarify that SSRC can be reused by another source after a delay 2274 of 5 RTCP reporting intervals. 2276 o Change based on WGLC comment from Alissa Cooper. 2278 o - IANA registry name fix. 2280 o - Additional IANA registration information added. 2282 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28 2284 o - Alignment with exclusive mux procedures. 2286 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 2288 o - Yet another terminology change. 2290 o - Mux category considerations added. 2292 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 2294 o - ICE considerations modified: ICE-related SDP attributes only 2295 added to the bundled m- line representing the selected BUNDLE 2296 address. 2298 o - Reference to draft-ietf-mmusic-ice-sip-sdp added. 2300 o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- 2301 rfc5245bis. 2303 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 2305 o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux 2306 considerations. 2308 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 2310 o - Reference and procedures associated with exclusive RTP/RTCP mux 2311 added 2313 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 2315 o - RTCP-MUX mandatory for bundled RTP m- lines 2317 o - Editorial fixes based on comments from Flemming Andreasen 2319 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 2321 o - Correction of Ari's family name 2323 o - Editorial fixes based on comments from Thomas Stach 2325 o - RTP/RTCP correction based on comment from Magnus Westerlund 2327 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2328 msg14861.html 2330 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 2332 o - Correct based on comment from Paul Kyzivat 2333 o -- 'received packets' replaced with 'received data' 2335 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 2337 o - Clarification based on comment from James Guballa 2339 o - Clarification based on comment from Flemming Andreasen 2341 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 2343 o - DTLS Considerations section added. 2345 o - BUNDLE semantics added to the IANA Considerations 2347 o - Changes based on WGLC comments from Adam Roach 2349 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2350 msg14673.html 2352 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 2354 o - Changes based on agreements at IETF#92 2356 o -- BAS Offer removed, based on agreement at IETF#92. 2358 o -- Procedures regarding usage of SDP "b=" line is replaced with a 2359 reference to to draft-ietf-mmusic-sdp-mux-attributes. 2361 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 2363 o - Editorial changes based on comments from Magnus Westerlund. 2365 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 2367 o - Modification of RTP/RTCP multiplexing section, based on comments 2368 from Magnus Westerlund. 2370 o - Reference updates. 2372 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 2374 o - Editorial fix. 2376 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 2378 o - Editorial changes. 2380 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 2381 o Changes to allow a new suggested offerer BUNDLE address to be 2382 assigned to each bundled m- line. 2384 o Changes based on WGLC comments from Paul Kyzivat 2386 o - Editorial fixes 2388 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 2390 o Usage of SDP 'extmap' attribute added 2392 o SDP 'bundle-only' attribute scoped with "m=" lines with a zero 2393 port value 2395 o Changes based on WGLC comments from Thomas Stach 2397 o - ICE candidates not assigned to bundle-only m- lines with a zero 2398 port value 2400 o - Editorial changes 2402 o Changes based on WGLC comments from Colin Perkins 2404 o - Editorial changes: 2406 o -- "RTP SDES item" -> "RTCP SDES item" 2408 o -- "RTP MID SDES item" -> "RTCP MID SDES item" 2410 o - Changes in section 10.1.1: 2412 o -- "SHOULD NOT" -> "MUST NOT" 2414 o -- Additional text added to the Note 2416 o - Change to section 13.2: 2418 o -- Clarify that mid value is not zero terminated 2420 o - Change to section 13.3: 2422 o -- Clarify that mid value is not zero terminated 2424 o -- Clarify padding 2426 o Changes based on WGLC comments from Paul Kyzivat 2428 o - Editorial changes: 2430 o Changes based on WGLC comments from Jonathan Lennox 2432 o - Editorial changes: 2434 o - Defintion of SDP bundle-only attribute alligned with structure 2435 in 4566bis draft 2437 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 2439 o Editorial corrections based on comments from Harald Alvestrand. 2441 o Editorial corrections based on comments from Cullen Jennings. 2443 o Reference update (RFC 7160). 2445 o Clarification about RTCP packet sending when RTP/RTCP multiplexing 2446 is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ 2447 msg13765.html). 2449 o Additional text added to the Security Considerations. 2451 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 2453 o SDP bundle-only attribute added to IANA Considerations. 2455 o SDES item and RTP header extension added to Abstract and 2456 Introduction. 2458 o Modification to text updating section 8.2 of RFC 3264. 2460 o Reference corrections. 2462 o Editorial corrections. 2464 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 2466 o Terminology change: "bundle-only attribute assigned to m= line" to 2467 "bundle-only attribute associated with m= line". 2469 o Editorial corrections. 2471 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 2473 o Editorial corrections. 2475 o - "of"->"if" (8.3.2.5). 2477 o - "optional"->"OPTIONAL" (9.1). 2479 o - Syntax/ABNF for 'bundle-only' attribute added. 2481 o - SDP Offer/Answer sections merged. 2483 o - 'Request new offerer BUNDLE address' section added 2485 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 2487 o OPEN ISSUE regarding Receiver-ID closed. 2489 o - RTP MID SDES Item. 2491 o - RTP MID Header Extension. 2493 o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers 2494 closed. 2496 o - Indicating that, when rtcp-mux is used, the answerer MUST NOT 2497 include an 'rtcp' attribute in the answer, based on the procedures 2498 in section 5.1.3 of RFC 5761. 2500 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 2502 o Draft title changed. 2504 o Added "SDP" to section names containing "Offer" or "Answer". 2506 o Editorial fixes based on comments from Paul Kyzivat 2507 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2508 msg13314.html). 2510 o Editorial fixed based on comments from Colin Perkins 2511 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2512 msg13318.html). 2514 o - Removed text about extending BUNDLE to allow multiple RTP 2515 sessions within a BUNDLE group. 2517 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 2519 o Major re-structure of SDP Offer/Answer sections, to align with RFC 2520 3264 structure. 2522 o Additional definitions added. 2524 o - Shared address. 2526 o - Bundled "m=" line. 2528 o - Bundle-only "m=" line. 2530 o - Offerer suggested BUNDLE mid. 2532 o - Answerer selected BUNDLE mid. 2534 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 2535 to multiple "m=" lines until it has received an SDP Answer 2536 indicating support of the BUNDLE extension. 2538 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 2539 Answerer supports the BUNDLE extension, assign a zero port value 2540 to a 'bundle-only' "m=" line. 2542 o SDP 'bundle-only' attribute section added. 2544 o Connection data nettype/addrtype restrictions added. 2546 o RFC 3264 update section added. 2548 o Indicating that a specific payload type value can be used in 2549 multiple "m=" lines, if the value represents the same codec 2550 configuration in each "m=" line. 2552 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 2554 o Updated Offerer procedures (http://www.ietf.org/mail- 2555 archive/web/mmusic/current/msg12293.html). 2557 o Updated Answerer procedures (http://www.ietf.org/mail- 2558 archive/web/mmusic/current/msg12333.html). 2560 o Usage of SDP 'bundle-only' attribute added. 2562 o Reference to Trickle ICE document added. 2564 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 2566 o Mechanism modified, to be based on usage of SDP Offers with both 2567 different and identical port number values, depending on whether 2568 it is known if the remote endpoint supports the extension. 2570 o Cullen Jennings added as co-author. 2572 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 2574 o No changes. New version due to expiration. 2576 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 2578 o No changes. New version due to expiration. 2580 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 2582 o Draft name changed. 2584 o Harald Alvestrand added as co-author. 2586 o "Multiplex" terminology changed to "bundle". 2588 o Added text about single versus multiple RTP Sessions. 2590 o Added reference to RFC 3550. 2592 21. References 2594 21.1. Normative References 2596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2597 Requirement Levels", BCP 14, RFC 2119, 2598 DOI 10.17487/RFC2119, March 1997, . 2601 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2602 with Session Description Protocol (SDP)", RFC 3264, 2603 DOI 10.17487/RFC3264, June 2002, . 2606 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2607 Jacobson, "RTP: A Transport Protocol for Real-Time 2608 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2609 July 2003, . 2611 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2612 in Session Description Protocol (SDP)", RFC 3605, 2613 DOI 10.17487/RFC3605, October 2003, . 2616 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2617 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2618 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2619 . 2621 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2622 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2623 July 2006, . 2625 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2626 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2627 . 2629 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2630 Control Packets on a Single Port", RFC 5761, 2631 DOI 10.17487/RFC5761, April 2010, . 2634 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2635 Security (DTLS) Extension to Establish Keys for the Secure 2636 Real-time Transport Protocol (SRTP)", RFC 5764, 2637 DOI 10.17487/RFC5764, May 2010, . 2640 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2641 Protocol (SDP) Grouping Framework", RFC 5888, 2642 DOI 10.17487/RFC5888, June 2010, . 2645 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2646 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2647 January 2012, . 2649 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2650 Header Extension for the RTP Control Protocol (RTCP) 2651 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2652 August 2016, . 2654 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 2655 Mechanism for RTP Header Extensions", RFC 8285, 2656 DOI 10.17487/RFC8285, October 2017, . 2659 [I-D.ietf-ice-rfc5245bis] 2660 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2661 Connectivity Establishment (ICE): A Protocol for Network 2662 Address Translator (NAT) Traversal", draft-ietf-ice- 2663 rfc5245bis-15 (work in progress), November 2017. 2665 [I-D.ietf-mmusic-sdp-mux-attributes] 2666 Nandakumar, S., "A Framework for SDP Attributes when 2667 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 2668 (work in progress), December 2016. 2670 [I-D.ietf-mmusic-mux-exclusive] 2671 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 2672 Multiplexing using SDP", draft-ietf-mmusic-mux- 2673 exclusive-12 (work in progress), May 2017. 2675 [I-D.ietf-mmusic-ice-sip-sdp] 2676 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, 2677 "Session Description Protocol (SDP) Offer/Answer 2678 procedures for Interactive Connectivity Establishment 2679 (ICE)", draft-ietf-mmusic-ice-sip-sdp-14 (work in 2680 progress), October 2017. 2682 21.2. Informative References 2684 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2685 A., Peterson, J., Sparks, R., Handley, M., and E. 2686 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2687 DOI 10.17487/RFC3261, June 2002, . 2690 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2691 "RTP Control Protocol Extended Reports (RTCP XR)", 2692 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2693 . 2695 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2696 "Codec Control Messages in the RTP Audio-Visual Profile 2697 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 2698 February 2008, . 2700 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2701 "Extended RTP Profile for Real-time Transport Control 2702 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2703 DOI 10.17487/RFC4585, July 2006, . 2706 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2707 Media Attributes in the Session Description Protocol 2708 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2709 . 2711 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2712 Clock Rates in an RTP Session", RFC 7160, 2713 DOI 10.17487/RFC7160, April 2014, . 2716 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2717 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2718 . 2720 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2721 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2722 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2723 DOI 10.17487/RFC7656, November 2015, . 2726 [I-D.ietf-ice-trickle] 2727 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 2728 "Trickle ICE: Incremental Provisioning of Candidates for 2729 the Interactive Connectivity Establishment (ICE) 2730 Protocol", draft-ietf-ice-trickle-15 (work in progress), 2731 November 2017. 2733 [I-D.ietf-avtext-lrr] 2734 Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 2735 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 2736 Message", draft-ietf-avtext-lrr-07 (work in progress), 2737 July 2017. 2739 Appendix A. Design Considerations 2741 One of the main issues regarding the BUNDLE grouping extensions has 2742 been whether, in SDP Offers and SDP Answers, the same port value 2743 should be inserted in "m=" lines associated with a BUNDLE group, as 2744 the purpose of the extension is to negotiate the usage of a single 2745 transport for media specified by the "m=" sections. Issues with both 2746 approaches, discussed in the Appendix have been raised. The outcome 2747 was to specify a mechanism which uses SDP Offers with both different 2748 and identical port values. 2750 Below are the primary issues that have been considered when defining 2751 the "BUNDLE" grouping extension: 2753 o 1) Interoperability with existing UAs. 2755 o 2) Interoperability with intermediary B2BUA- and proxy entities. 2757 o 3) Time to gather, and the number of, ICE candidates. 2759 o 4) Different error scenarios, and when they occur. 2761 o 5) SDP Offer/Answer impacts, including usage of port number value 2762 zero. 2764 A.1. UA Interoperability 2766 Consider the following SDP Offer/Answer exchange, where Alice sends 2767 an SDP Offer to Bob: 2769 SDP Offer 2771 v=0 2772 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2773 s= 2774 c=IN IP4 atlanta.example.com 2775 t=0 0 2776 m=audio 10000 RTP/AVP 97 2777 a=rtpmap:97 iLBC/8000 2778 m=video 10002 RTP/AVP 97 2779 a=rtpmap:97 H261/90000 2781 SDP Answer 2783 v=0 2784 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2785 s= 2786 c=IN IP4 biloxi.example.com 2787 t=0 0 2788 m=audio 20000 RTP/AVP 97 2789 a=rtpmap:97 iLBC/8000 2790 m=video 20002 RTP/AVP 97 2791 a=rtpmap:97 H261/90000 2793 RFC 4961 specifies a way of doing symmetric RTP but that is an a 2794 later invention to RTP and Bob can not assume that Alice supports RFC 2795 4961. This means that Alice may be sending RTP from a different port 2796 than 10000 or 10002 - some implementation simply send the RTP from an 2797 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2798 way that Bob knows if it should be passed to the video or audio codec 2799 is by looking at the port it was received on. This lead some SDP 2800 implementations to use the fact that each "m=" section had a 2801 different port number to use that port number as an index to find the 2802 correct m line in the SDP. As a result, some implementations that do 2803 support symmetric RTP and ICE still use a SDP data structure where 2804 SDP with "m=" sections with the same port such as: 2806 SDP Offer 2808 v=0 2809 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2810 s= 2811 c=IN IP4 atlanta.example.com 2812 t=0 0 2813 m=audio 10000 RTP/AVP 97 2814 a=rtpmap:97 iLBC/8000 2815 m=video 10000 RTP/AVP 98 2816 a=rtpmap:98 H261/90000 2818 will result in the second "m=" section being considered an SDP error 2819 because it has the same port as the first line. 2821 A.2. Usage of port number value zero 2823 In an SDP Offer or SDP Answer, the media specified by an "m=" section 2824 can be disabled/rejected by setting the port number value to zero. 2825 This is different from e.g., using the SDP direction attributes, 2826 where RTCP traffic will continue even if the SDP "inactive" attribute 2827 is indicated for the associated "m=" section. 2829 If each "m=" section associated with a BUNDLE group would contain 2830 different port values, and one of those port values would be used for 2831 a BUNDLE address associated with the BUNDLE group, problems would 2832 occur if an endpoint wants to disable/reject the "m=" sectcion 2833 associated with that port, by setting the port value to zero. After 2834 that, no "m=" section would contain the port value which is used for 2835 the BUNDLE address. In addition, it is unclear what would happen to 2836 the ICE candidates associated with the "m=" section, as they are also 2837 used for the BUNDLE address. 2839 A.3. B2BUA And Proxy Interoperability 2841 Some back to back user agents may be configured in a mode where if 2842 the incoming call leg contains an SDP attribute the B2BUA does not 2843 understand, the B2BUA still generates that SDP attribute in the Offer 2844 for the outgoing call leg. Consider a B2BUA that did not understand 2845 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 2846 Further assume that the B2BUA was configured to tear down any call 2847 where it did not see any RTCP for 5 minutes. In this case, if the 2848 B2BUA received an Offer like: 2850 SDP Offer 2852 v=0 2853 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2854 s= 2855 c=IN IP4 atlanta.example.com 2856 t=0 0 2857 m=audio 49170 RTP/AVP 0 2858 a=rtcp:53020 2860 It would be looking for RTCP on port 49172 but would not see any 2861 because the RTCP would be on port 53020 and after five minutes, it 2862 would tear down the call. Similarly, a B2BUA that did not understand 2863 BUNDLE yet put BUNDLE in it's offer may be looking for media on the 2864 wrong port and tear down the call. It is worth noting that a B2BUA 2865 that generated an Offer with capabilities it does not understand is 2866 not compliant with the specifications. 2868 A.3.1. Traffic Policing 2870 Sometimes intermediaries do not act as B2BUA, in the sense that they 2871 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2872 however, they may use SDP information (e.g., IP address and port) in 2873 order to control traffic gating functions, and to set traffic 2874 policing rules. There might be rules which will trigger a session to 2875 be terminated in case media is not sent or received on the ports 2876 retrieved from the SDP. This typically occurs once the session is 2877 already established and ongoing. 2879 A.3.2. Bandwidth Allocation 2881 Sometimes intermediaries do not act as B2BUA, in the sense that they 2882 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2883 however, they may use SDP information (e.g., codecs and media types) 2884 in order to control bandwidth allocation functions. The bandwidth 2885 allocation is done per "m=" section, which means that it might not be 2886 enough if media specified by all "m=" sections try to use that 2887 bandwidth. That may either simply lead to bad user experience, or to 2888 termination of the call. 2890 A.4. Candidate Gathering 2892 When using ICE, a candidate needs to be gathered for each port. This 2893 takes approximately 20 ms extra for each extra "m=" section due to 2894 the NAT pacing requirements. All of this gather can be overlapped 2895 with other things while for exampe a web-page is loading to minimize 2896 the impact. If the client only wants to generate TURN or STUN ICE 2897 candidates for one of the "m=" lines and then use trickle ICE 2898 [I-D.ietf-ice-trickle] to get the non host ICE candidates for the 2899 rest of the "m=" sections, it MAY do that and will not need any 2900 additional gathering time. 2902 Some people have suggested a TURN extension to get a bunch of TURN 2903 allocations at once. This would only provide a single STUN result so 2904 in cases where the other end did not support BUNDLE, may cause more 2905 use of the TURN server but would be quick in the cases where both 2906 sides supported BUNDLE and would fall back to a successful call in 2907 the other cases. 2909 Authors' Addresses 2911 Christer Holmberg 2912 Ericsson 2913 Hirsalantie 11 2914 Jorvas 02420 2915 Finland 2917 Email: christer.holmberg@ericsson.com 2919 Harald Tveit Alvestrand 2920 Google 2921 Kungsbron 2 2922 Stockholm 11122 2923 Sweden 2925 Email: harald@alvestrand.no 2927 Cullen Jennings 2928 Cisco 2929 400 3rd Avenue SW, Suite 350 2930 Calgary, AB T2P 4H2 2931 Canada 2933 Email: fluffy@iii.ca