idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-43.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 (December 8, 2017) is 2331 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 1569 == Missing Reference: 'RFCXXXX' is mentioned on line 1753, 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-16 == 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: June 11, 2018 C. Jennings 7 Cisco 8 December 8, 2017 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-43.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 June 11, 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 . . . . . . . . . . . . . . . . . 16 106 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 17 107 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 17 108 8.5.1. Suggesting a new offerer BUNDLE address . . . . . . . 17 109 8.5.2. Adding a media description to a BUNDLE group . . . . 18 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 . . . . . . . . . . . . . . . . . . . . 20 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 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 31 124 13. RTP Header Extensions Consideration . . . . . . . . . . . . . 31 125 14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 32 126 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 32 127 14.2. New text replacing section 5.1 (2nd paragraph) of RFC 128 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 32 129 14.3. Original text of section 6 (4th paragraph) of RFC 3264 . 33 130 14.4. New text replacing section 6 (4th paragraph) of RFC 3264 33 131 14.5. Original text of section 8.2 (2nd paragraph) of RFC 3264 33 132 14.6. New text replacing section 8.2 (2nd paragraph) of RFC 133 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 134 14.7. Original text of section 8.4 (6th paragraph) of RFC 3264 33 135 14.8. New text replacing section 8.4 (6th paragraph) of RFC 136 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 137 15. RTP/RTCP extensions for identification-tag transport . . . . 34 138 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 35 139 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 35 140 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 141 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 36 142 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 37 143 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 37 144 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 38 145 17. Security Considerations . . . . . . . . . . . . . . . . . . . 38 146 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39 147 18.1. Example: Bundle Address Selection . . . . . . . . . . . 39 148 18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 41 149 18.3. Example: Offerer Adds A Media Description To A BUNDLE 150 Group . . . . . . . . . . . . . . . . . . . . . . . . . 42 151 18.4. Example: Offerer Moves A Media Description Out Of A 152 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 44 153 18.5. Example: Offerer Disables A Media Description Within A 154 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46 155 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 156 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 48 157 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 158 21.1. Normative References . . . . . . . . . . . . . . . . . . 58 159 21.2. Informative References . . . . . . . . . . . . . . . . . 60 160 Appendix A. Design Considerations . . . . . . . . . . . . . . . 61 161 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 62 162 A.2. Usage of port number value zero . . . . . . . . . . . . . 63 163 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 64 164 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 64 165 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 64 166 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 65 167 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 169 1. Introduction 171 When multimedia communications are established, each transport 172 (5-tuple) reserved for an individual media stream consume additional 173 resources (especially when Interactive Connectivity Establishment 174 (ICE) [I-D.ietf-ice-rfc5245bis] is used). For this reason, it is 175 attractive to use a single transport for multiple media streams. 177 This specification defines a way to use a single transport (BUNDLE 178 transport) for sending and receiving media (bundled media) described 179 by multiple SDP media descriptions ("m=" sections). The same BUNDLE 180 transport is used for sending and receiving bundled media, which 181 means that the symmetric RTP mechanism [RFC4961] is always used for 182 RTP-based bundled media. 184 This specification defines a new SDP Grouping Framework [RFC5888] 185 extension called 'BUNDLE'. The extension can be used with the 186 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 187 to negotiate which "m=" sections will become part of a BUNDLE group. 188 Within a BUNDLE group, each "m=" section will use a BUNDLE transport 189 for sending and receiving bundled media. 191 Within a BUNDLE group, each endpoint uses a single address:port 192 combination for sending and receiving bundled media. The 193 address:port combination is referred to as BUNDLE address. In 194 addition to negotiating the BUNDLE group, the offerer and answerer 195 [RFC3264] use the BUNDLE extension to negotiate the BUNDLE addresses, 196 one for the offerer (offerer BUNDLE address) and one for the answerer 197 (answerer BUNDLE address). Once the offerer and the answerer have 198 negotiated the BUNDLE addresses, and a BUNDLE group has been formed, 199 they assign their respective BUNDLE address to each "m=" section 200 within the BUNDLE group. The endpoints then use the BUNDLE addresses 201 for sending and receiving the bundled media associated with the 202 BUNDLE group. 204 The use of a BUNDLE transport also allows the usage of a single set 205 of Interactive Connectivity Establishment (ICE) 206 [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group. 208 This specification also defines a new SDP attribute, 'bundle-only', 209 which can be used to request that specific media is only used if the 210 "m=" section describing the media is kept within a BUNDLE group. The 211 specification also updates RFC 3264, to allow usage of zero port 212 values without meaning that media is rejected. 214 As defined in RFC 4566 [RFC4566], the semantics of assigning the same 215 transport address (IP address and port) to multiple "m=" sections are 216 undefined, and there is no grouping defined by such means. Instead, 217 an explicit grouping mechanism needs to be used to express the 218 intended semantics. This specification provides such an extension. 220 This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 221 [RFC3264]. The update allows an answerer to assign a non-zero port 222 value to an "m=" section in an SDP answer, even if the "m=" section 223 in the associated SDP offer contained a zero port value. 225 This specification also defines a new Real-time Transport Protocol 226 (RTP) [RFC3550] source description (SDES) item, 'MID', and a new RTP 227 SDES header extension that can be used to associate RTP streams with 228 "m=" sections. 230 SDP bodies can contain multiple BUNDLE groups. A given BUNDLE 231 address MUST only be associated with a single BUNDLE group. The 232 procedures in this specification apply independently to a given 233 BUNDLE group. All RTP based media flows described by a single BUNDLE 234 group belong to a single RTP session [RFC3550]. 236 The BUNDLE extension is backward compatible. Endpoints that do not 237 support the extension are expected to generate offers and answers 238 without an SDP 'group:BUNDLE' attribute, and are expected to assign a 239 unique address to each "m=" section within an offer and answer, 240 according to the procedures in [RFC4566] and [RFC3264] 242 2. Terminology 244 "m=" section: SDP bodies contain one or more media descriptions, 245 referred to as "m=" sections. Each "m=" section is represented by an 246 SDP "m=" line, and zero or more SDP attributes associated with the 247 "m=" line. An local address:port combination is assigned to each 248 "m=" section. 250 5-tuple: A collection of the following values: source address, source 251 port, destination address, destination port, and transport-layer 252 protocol. 254 Unique address: An address:port combination that is assigned to only 255 one "m=" section in an offer or answer. 257 Offerer BUNDLE-tag: The first identification-tag in a given SDP 258 'group:BUNDLE' attribute identification-tag list in an offer. 260 Answerer BUNDLE-tag: The first identification-tag in a given SDP 261 'group:BUNDLE' attribute identification-tag list in an answer. 263 BUNDLE address: An address:port combination that an endpoint uses for 264 sending and receiving bundled media. 266 Offerer BUNDLE address: the address:port combination used by the 267 offerer for sending and receiving media. 269 Suggested Offerer BUNDLE address: before an offerer BUNDLE address 270 has been selected by the answerer, or when the offerer wants to 271 change a previously selected offerer BUNDLE address, the address:port 272 combination that the offerer wants to use for sending and receiving 273 media. While suggested by the offerer, the selection of the offerer 274 BUNDLE address is done by the answerer. 276 Answerer BUNDLE address: the address:port combination used by the 277 answerer for sending and receiving media. 279 BUNDLE transport: The transport (5-tuple) used by all media described 280 by the "m=" sections within a BUNDLE group. 282 BUNDLE group: A set of "m=" sections, created using an SDP Offer/ 283 Answer exchange, which uses a single BUNDLE transport for sending and 284 receiving all media (bundled media) described by the set of "m=" 285 sections. The same BUNDLE transport is used for sending and 286 receiving bundled media. 288 Bundled "m=" section: An "m=" section, whose identification-tag is 289 placed in an SDP 'group:BUNDLE' attribute identification-tag list in 290 an offer or answer. 292 Bundle-only "m=" section: A bundled "m=" section that contains an SDP 293 'bundle-only' attribute. 295 Bundled media: All media associated with a given BUNDLE group. 297 Initial offer: The first offer, within an SDP session (e.g. a SIP 298 dialog when the Session Initiation Protocol (SIP) [RFC3261] is used 299 to carry SDP), in which the offerer indicates that it wants to create 300 a given BUNDLE group. 302 Subsequent offer: An offer which contains a BUNDLE group that has 303 been created as part of a previous offer/answer exchange. 305 Identification-tag: A unique token value that is used to identify an 306 "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" section 307 carries the unique identification-tag assigned to that "m=" section. 308 The session-level SDP 'group' attribute [RFC5888] carries a list of 309 identification-tags, identifying the "m=" sections associated with 310 that particular 'group' attribute. 312 3. Conventions 314 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 315 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 316 document are to be interpreted as described in BCP 14, RFC 2119 317 [RFC2119]. 319 4. Applicability Statement 321 The mechanism in this specification only applies to the Session 322 Description Protocol (SDP) [RFC4566], when used together with the SDP 323 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 324 scope of this document, and is thus undefined. 326 5. SDP Grouping Framework BUNDLE Extension 328 This section defines a new SDP Grouping Framework [RFC5888] 329 extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP 330 Offer/Answer mechanism to negotiate a set of "m=" sections that will 331 become part of a BUNDLE group. Within a BUNDLE group, each "m=" 332 section will use a BUNDLE transport for sending and receiving bundled 333 media. Each endpoint use a single address:port combination for 334 sending receiving the bundled media. 336 The BUNDLE extension is indicated using an SDP 'group' attribute with 337 a "BUNDLE" semantics value [RFC5888]. An identification-tag is 338 assigned to each bundled "m=" section, and each identification-tag is 339 listed in the SDP 'group:BUNDLE' attribute identification-tag list. 340 Each "m=" section whose identification-tag is listed in the 341 identification-tag list is associated with a given BUNDLE group. 343 SDP bodies can contain multiple BUNDLE groups. Any given bundled 344 "m=" section MUST NOT be associated with more than one BUNDLE group 345 at any given time. 347 NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' 348 attribute identification-tag list does not have to be the same as the 349 order in which the "m=" sections occur in the SDP. 351 Section 8 defines the detailed SDP Offer/Answer procedures for the 352 BUNDLE extension. 354 6. SDP 'bundle-only' Attribute 356 This section defines a new SDP media-level attribute [RFC4566], 357 'bundle-only'. 'bundle-only' is a property attribute [RFC4566], and 358 hence has no value. 360 Name: bundle-only 362 Value: N/A 364 Usage Level: media 366 Charset Dependent: no 368 Example: 370 a=bundle-only 372 In order to ensure that an answerer that does not support the BUNDLE 373 extension always rejects a bundled "m=" section, the offerer can 374 assign a zero port value to the "m=" section. According to [RFC3264] 375 an answerer will reject such "m=" section. By including an SDP 376 'bundle-only' attribute in such "m=" section, the offerer can request 377 that the answerer accepts the "m=" section if the answerer supports 378 the Bundle extension, and if the answerer keeps the "m=" section 379 within the associated BUNDLE group. 381 Once the offerer and answerer BUNDLE addresses have been selected, an 382 offerer and answerer only assigns the BUNDLE address to one bundled 383 "m=" section. To every other bundled "m=" section the offerer and 384 answerer assigns a zero port value and includes an SDP 'bundle-only' 385 attribute. 387 The usage of the 'bundle-only' attribute is only defined for a 388 bundled "m=" section with a zero port value, within an offer or 389 answer. Other usage is unspecified. 391 Section 8 defines the detailed SDP Offer/Answer procedures for the 392 'bundle-only' attribute. 394 7. SDP Information Considerations 396 This section describes restrictions associated with the usage of SDP 397 parameters within a BUNDLE group. It also describes, when parameter 398 and attribute values have been assigned to each bundled "m=" section, 399 how to calculate a value for the whole BUNDLE group. 401 7.1. Connection Data (c=) 403 The "c=" line nettype value [RFC4566] associated with a bundled "m=" 404 section MUST be 'IN'. 406 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" 407 section MUST be 'IP4' or 'IP6'. The same value MUST be associated 408 with each "m=" section. 410 NOTE: Extensions to this specification can specify usage of the 411 BUNDLE mechanism for other nettype and addrtype values than the ones 412 listed above. 414 7.2. Bandwidth (b=) 416 An offerer and answerer MUST use the rules and restrictions defined 417 in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP 418 bandwidth (b=) line with bundled "m=" section. 420 8. SDP Offer/Answer Procedures 422 This section describes the SDP Offer/Answer [RFC3264] procedures for: 424 o Negotiating a BUNDLE group; and 426 o Selecting the BUNDLE addresses (offerer BUNDLE address and 427 answerer BUNDLE address); and 429 o Adding an "m=" section to a BUNDLE group; and 431 o Moving an "m=" section out of a BUNDLE group; and 433 o Disabling an "m=" section within a BUNDLE group. 435 The generic rules and procedures defined in [RFC3264] and [RFC5888] 436 also apply to the BUNDLE extension. For example, if an offer is 437 rejected by the answerer, the previously negotiated SDP parameters 438 and characteristics (including those associated with a BUNDLE group) 439 apply. Hence, if an offerer generates an offer in which the offerer 440 wants to create a BUNDLE group, and the answerer rejects the offer, 441 the BUNDLE group is not created. 443 The procedures in this section are independent of the media type or 444 "m=" line proto value assigned to a bundled "m=" section. Section 10 445 defines additional considerations for RTP based media. Section 6 446 defines additional considerations for the usage of the SDP 'bundle- 447 only' attribute. Section 11 defines additional considerations for 448 the usage of Interactive Connectivity Establishment (ICE) 449 [I-D.ietf-ice-rfc5245bis] mechanism. 451 SDP offers and answers can contain multiple BUNDLE groups. The 452 procedures in this section apply independently to a given BUNDLE 453 group. 455 8.1. Mux Category Considerations 457 When a BUNDLE group is initially negotiated, and a unique address is 458 assigned to each bundled "m=" section (excluding any bundle-only "m=" 459 section) in the initial offer Section 8.2, IDENTICAL and TRANSPORT 460 mux category SDP attributes MUST explicitly included in each bundled 461 "m=" section (excluding any bundle-only "m=" secctions). 463 When an offerer or answerer includes SDP attributes in bundled "m=" 464 sections within a BUNDLE group for which the offerer and answerer 465 BUNDLE addresses have been selected, IDENTICAL and TRANSPORT mux 466 category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are only 467 included in the "m=" section represented by the BUNDLE-tag in the 468 offer or answer. The SDP attribute values are implicitly applied to 469 each bundled "m=" section (including any bundle-only "m=" section). 470 The offerer and answerer MUST NOT include such SDP attributes in any 471 other bundled "m=" section. 473 The semantics of some SDP attributes only apply to specific types of 474 media. For example, the semantics of the SDP 'rtcp-mux' and SDP 475 'rtcp-mux-only' attributes only apply to "m=" sections describing 476 RTP-based media. However, as described in Section 8.1, there are 477 cases where IDENTICAL and TRANSPORT mux category SDP attributes are 478 only included in the "m=" sections represented by the BUNDLE-tag. 479 That means that media-specific IDENTICAL and TRANSPORT mux category 480 attributes can be included in an "m=" section associated with another 481 type of media. 483 8.2. Generating the Initial SDP Offer 485 When an offerer generates an initial offer, in order to negotiate a 486 BUNDLE group, it MUST: 488 o Assign a unique address to each "m=" section within the offer, 489 following the procedures in [RFC3264], excluding any bundle-only 490 "m=" sections (see below); and 492 o Include an SDP 'group:BUNDLE' attribute in the offer; and 494 o Place the identification-tag of each bundled "m=" section in the 495 SDP 'group:BUNDLE' attribute identification-tag list; and 497 o Indicate which unique address the offerer suggests as the offerer 498 BUNDLE address [Section 8.2.1]. 500 If the offerer wants to request that the answerer accepts a given 501 bundled "m=" section only if the answerer keeps the "m=" section 502 within the BUNDLE group, the offerer MUST: 504 o Include an SDP 'bundle-only' attribute [Section 8.2.1] in the "m=" 505 secction; and 507 o Assign a zero port value to the "m=" section. 509 NOTE: If the offerer assigns a zero port value to an "m=" section, 510 but does not include an SDP 'bundle-only' attribute in the "m=" 511 section, it is an indication that the offerer wants to disable the 512 "m=" section [Section 8.5.4]. 514 [Section 18.1] shows an example of an initial offer. 516 8.2.1. Suggesting the offerer BUNDLE address 518 In the offer, the address:port combination assigned to the "m=" 519 section represented by the offerer BUNDLE-tag indicates offerer 520 BUNDLE address, i.e., the address:port combination that the offerer 521 suggests for sending and receiving bundled media. 523 The offerer BUNDLE-tag MUST NOT represent a bundle-only "m=" section. 524 Hence, the offer MUST contain at least one bundle "m=" section with a 525 unique address (and a non-zero port value). 527 8.2.2. Example: Initial SDP Offer 529 The example shows an initial SDP offer. The offer includes two "m=" 530 section in the SDP, and suggests that both are included in a BUNDLE 531 group. The audio "m=" section is associated with the offerer BUNDLE- 532 tag (placed first in the SDP group:BUNDLE attribute identification-id 533 list). 535 SDP Offer 537 v=0 538 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 539 s= 540 c=IN IP4 atlanta.example.com 541 t=0 0 542 a=group:BUNDLE foo bar 543 m=audio 10000 RTP/AVP 0 8 97 544 b=AS:200 545 a=mid:foo 546 a=rtcp-mux 547 a=rtpmap:0 PCMU/8000 548 a=rtpmap:8 PCMA/8000 549 a=rtpmap:97 iLBC/8000 550 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 551 m=video 10002 RTP/AVP 31 32 552 b=AS:1000 553 a=mid:bar 554 a=rtpmap:31 H261/90000 555 a=rtpmap:32 MPV/90000 556 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 558 8.3. Generating the SDP Answer 560 When an answerer generates an answer that contains a BUNDLE group, 561 the following general SDP grouping framework restrictions, defined in 562 [RFC5888], also apply to the BUNDLE group: 564 o The answerer MUST NOT include a BUNDLE group in the answer, unless 565 the offerer requested the BUNDLE group to be negotiated in the 566 corresponding offer; and 568 o The answerer MUST NOT include an "m=" section within a BUNDLE 569 group, unless the offerer requested the "m=" section to be within 570 that BUNDLE group in the corresponding offer. 572 o If the answer contains multiple BUNDLE groups, the answerer MUST 573 NOT move an "m=" section from one BUNDLE group to another. 575 If the answer contains a BUNDLE group, the answerer MUST: 577 o Select an offerer BUNDLE Address [Section 8.3.1]; and 579 o Select an answerer BUNDLE Address [Section 8.3.2]; 581 The answerer is allowed to select a new answerer BUNDLE address each 582 time it generates an answer to an offer. 584 If the answerer does not want to keep an "m=" section within a BUNDLE 585 group, it MUST: 587 o Move the "m=" section out of the BUNDLE group [Section 8.3.3]; or 589 o Reject the "m=" section [Section 8.3.4]; 591 When the answerer creates the answer, it selects the offerer BUNDLE 592 address [Section 8.3.1] and the answerer BUNDLE address 593 [Section 8.3.2]. The answerer then assigns the answerer BUNDLE 594 address to the bundled "m=" section represented by the answerer 595 BUNDLE-tag. In every other bundled "m=" section the answerer 596 includes an SDP 'bundle-only' attribute and assigns a zero port value 597 to the "m=" section. 599 If the answerer does not want to keep a bundle-only "m=" section 600 within the BUNDLE group, it MUST reject the "m=" section 601 [Section 8.3.4]. 603 NOTE: If a bundled "m=" section in an offer contains a zero port 604 value, but the "m=" section does not contain an SDP 'bundle-only' 605 attribute, it is an indication that the offerer wants to disable the 606 "m=" section [Section 8.5.4]. 608 8.3.1. Answerer Selection of Offerer Bundle Address 610 In an offer, the bundled "m=" section represented by the offerer 611 BUNDLE-tag contains the suggested offerer BUNDLE address, i.e, the 612 address:port combination that the offerer wants to use for sending 613 and receiving bundled media [Section 8.2.1]. The answerer MUST check 614 whether that "m=" section fulfils the following criteria: 616 o The answerer will not move the "m=" section out of the BUNDLE 617 group [Section 8.3.3]; and 619 o The answerer will not reject the "m=" section [Section 8.3.4]; and 621 o The "m=" section does not contain a zero port value. 623 If all of the criteria above are fulfilled, the answerer MUST select 624 the suggested offerer BUNDLE address. 626 If one or more of the criteria are not fulfilled, the answerer MUST 627 pick the next identification-tag in the identification-tag list in 628 the offer, and perform the same criteria check for the "m=" section 629 represented by that identification-tag. If there are no more 630 identification-tags in the identification-tag list, the answerer MUST 631 NOT create the BUNDLE group. 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] or rejecting an 634 "m=" section within a BUNDLE group [Section 8.3.4] to every bundled 635 "m=" section in the offer when creating the answer. 637 [Section 18.1] shows an example of an offerer BUNDLE address 638 selection. 640 8.3.2. Answerer Selection of Answerer BUNDLE Address 642 When the answerer selects a BUNDLE address for itself (answerer 643 BUNDLE address), the answerer MUST assign the answerer BUNDLE address 644 to the "m=" section that contains the selected offerer BUNDLE address 645 in the corresponding offer. The answerer BUNDLE-tag represents that 646 "m=" section in the answer. To every other bundled "m=" section the 647 answerer MUST assign a zero port value and include an SDP 'bundle- 648 only' attribute. 650 The answerer MUST NOT assign an answerer BUNDLE address to an "m=" 651 section that is not within the BUNDLE group, or to an "m=" section 652 that is within another BUNDLE group. 654 [Section 18.1] shows an example of an answerer BUNDLE address 655 selection. 657 8.3.3. Moving A Media Description Out Of A BUNDLE Group 659 When an answerer wants to move a bundled "m=" section out of a BUNDLE 660 group in an answer, it MUST first check the following criteria: 662 o In the corresponding offer, an offerer BUNDLE address (previously 663 selected [Section 8.3.1] or new suggested [Section 8.5.1]) has 664 been assigned to the "m=" section by the offerer; or 666 o In the corresponding offer, the "m=" section contains an SDP 667 'bundle-only' attribute and a zero port value. 669 If either criteria above is fulfilled, the answerer can not not move 670 the "m=" section out of the BUNDLE group in the answer. The answerer 671 can either reject the whole offer, or keep the "m=" section within 672 the BUNDLE group in the answer and later create an offer where the 673 "m=" section is moved out of the BUNDLE group [Section 8.5.3] 675 When the answerer generates an answer, in which it removes a bundled 676 "m=" section out of a BUNDLE group, the answerer: 678 o MUST assign a unique address to the "m=" section; and 680 o MUST NOT place the identification-tag associated with the "m=" 681 section in the SDP 'group:BUNDLE' attribute identification-tag 682 list associated with the BUNDLE group; and 684 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 685 section. 687 An answerer MUST NOT move an "m=" section from one BUNDLE group to 688 another within an answer. If the answerer wants to move an "m=" 689 section from one BUNDLE group to another it MUST first move the 690 BUNDLE group out of the current BUNDLE group, and then generate an 691 offer where the "m=" section is added to another BUNDLE group 692 [Section 8.5.2]. 694 8.3.4. Rejecting A Media Description In A BUNDLE Group 696 When an answerer wants to reject a bundled "m=" section in an answer, 697 it MUST first check the following criteria: 699 o In the corresponding offer, an offerer BUNDLE address (previously 700 selected [Section 8.3.1] or new suggested [Section 8.5.1]) has 701 been assigned to the "m=" section by the offerer. 703 If either criteria above is fulfilled, the answerer can not not 704 reject the "m=" section in the answer. The answerer can either 705 reject the whole offer, or keep the "m=" section within the BUNDLE 706 group in the answer and later create an offer where the "m=" section 707 is disabled of the BUNDLE group [Section 8.5.4] 708 When an answerer generates an answer, in which it rejects a bundled 709 "m=" section, the answerer: 711 o MUST assign a zero port value to the "m=" section, according to 712 the procedures in [RFC3264]; and 714 o MUST NOT place the identification-tag associated with the "m=" 715 section in the SDP 'group:BUNDLE' attribute identification-tag 716 list associated with the BUNDLE group; and 718 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 719 section. 721 8.3.5. Example: SDP Answer 723 The example shows an SDP answer, based on the SDP offer in 724 [Section 8.2.2]. The answers accepts both "m=" sections within the 725 BUNDLE group. The answerer assigns the answerer BUNDLE address to 726 the "m=" section represented by the answerer BUNDLE-tag. The 727 answerer assigns a zero port value and an SDP 'bundle-only' attribute 728 to the other bundled "m=" section. 730 SDP Answer 732 v=0 733 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 734 s= 735 c=IN IP4 biloxi.example.com 736 t=0 0 737 a=group:BUNDLE foo bar 738 m=audio 20000 RTP/AVP 0 739 b=AS:200 740 a=mid:foo 741 a=rtcp-mux 742 a=rtpmap:0 PCMU/8000 743 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 744 m=video 0 RTP/AVP 32 745 b=AS:1000 746 a=mid:bar 747 a=bundle-only 748 a=rtpmap:32 MPV/90000 749 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 751 8.4. Offerer Processing of the SDP Answer 753 When an offerer receives an answer, if the answer contains a BUNDLE 754 group, the offerer MUST check that any bundled "m=" section in the 755 answer was indicated as bundled in the corresponding offer. If there 756 is no mismatch, the offerer MUST use the offerer BUNDLE address, 757 selected by the answerer [Section 8.3.1], as the address for each 758 bundled "m=" section. 760 NOTE: As the answerer might reject one or more bundled "m=" sections, 761 or move a bundled "m=" section out of a BUNDLE group, each bundled 762 "m=" section in the offer might not be indicated as bundled in the 763 answer. 765 If the answer does not contain a BUNDLE group, the offerer MUST 766 process the answer as a normal answer. 768 8.5. Modifying the Session 770 When an offerer generates a subsequent offer (i.e., a BUNDLE group 771 has previously been negotiated), it MUST assign the previously 772 selected offer BUNDLE address [Section 8.3.1], or a new suggested 773 offerer BUNDLE address [Section 8.5.1], to exactly one "m=" section 774 within the BUNDLE group. 776 The offerer MUST NOT assign an offerer BUNDLE address (previously 777 selected [Section 8.3.1] or new suggested [Section 8.5.1]) to a 778 bundled "m=" section if: 780 o The offerer wants to move the bundled "m=" section out of the 781 BUNDLE group [Section 8.5.3]; or 783 o The offerer wants to disable the bundled "m=" section 784 [Section 8.5.4]. 786 To every other "m=" section within the BUNDLE group, the offerer MUST 787 assign a zero port value and an SDP 'bundle-only' attribute. 789 When the offerer generates a subsequent offer, the offerer BUNDLE-tag 790 MUST represent the bundled "m=" section to which the offerer BUNDLE 791 address (previously negotiated or new suggested) has been assigned. 793 8.5.1. Suggesting a new offerer BUNDLE address 795 When an offerer generates an offer, in which it suggests a new 796 offerer BUNDLE address [Section 8.2.1], the offerer MUST: 798 o Assign the new suggested offerer BUNDLE address to exactly one 799 "m=" section within the BUNDLE group; and 801 o Assign a zero port value and an SDP 'bundle-only' attribute to 802 every other "m=" section within the BUNDLE group. 804 8.5.2. Adding a media description to a BUNDLE group 806 When an offerer generates an offer, in which it wants to add a 807 bundled "m=" section, the offerer MUST: 809 o Assign the offerer BUNDLE address (previously selected 810 [Section 8.3.1] or new suggested [Section 8.5.1]) to the added 811 "m=" section; or 813 o Assign a zero port value and an SDP 'bundle-only' attribute to the 814 added "m=" section (in this case the offerer BUNDLE address is 815 assigned to another "m=" section within the BUNDLE group). 817 In addition, the offerer MUST place the identification-tag associated 818 with the added "m=" section in the SDP 'group:BUNDLE' attribute 819 identification-tag list associated with the BUNDLE group 820 [Section 8.2.1]. 822 NOTE: If the offerer also wants to suggest a new offerer BUNDLE 823 address to the BUNDLE group, the offerer can assign the new suggested 824 offerer BUNDLE address either to the added "m=" section, or to some 825 other "m=" section within the BUNDLE group [Section 8.5.1]. 827 [Section 18.3] shows an example where an offerer sends an offer in 828 order to add a bundled "m=" section to a BUNDLE group. 830 8.5.3. Moving A Media Description Out Of A BUNDLE Group 832 When an offerer generates an offer, in which it wants to move a 833 bundled "m=" section out of a BUNDLE group, the offerer: 835 o MUST assign a unique address to the "m=" section; and 837 o MUST NOT place the identification-tag associated with the "m=" 838 section in the SDP 'group:BUNDLE' attribute identification-tag 839 list associated with the BUNDLE group; and 841 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 842 section. 844 An offerer MUST NOT move an "m=" section from one BUNDLE group to 845 another within a single offer. If the offerer wants to move an "m=" 846 section from one BUNDLE group to another it MUST first move the 847 BUNDLE group out of the current BUNDLE group, and then generate a 848 second offer where the "m=" section is added to another BUNDLE group 849 [Section 8.5.2]. 851 [Section 18.4] shows an example of an offer for moving an "m=" 852 section out of a BUNDLE group. 854 8.5.4. Disabling A Media Description In A BUNDLE Group 856 When an offerer generates an offer, in which it wants to disable a 857 bundled "m=" section, the offerer: 859 o MUST assign a zero port value to the "m=" section, following the 860 procedures in [RFC4566]; and 862 o MUST NOT place the identification-tag associated with the "m=" 863 section in the SDP 'group:BUNDLE' attribute identification-tag 864 list associated with the BUNDLE group; and 866 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 867 section. 869 [Section 18.5] shows an example of an offer for disabling an "m=" 870 section within a BUNDLE group. 872 9. Protocol Identification 874 Each "m=" section within a BUNDLE group MUST use the same transport- 875 layer protocol. If bundled "m=" sections use different protocols on 876 top of the transport-layer protocol, there MUST exist a publicly 877 available specification which describes a mechanism, for this 878 particular protocol combination, how to associate received data with 879 the correct protocol. 881 In addition, if received data can be associated with more than one 882 bundled "m=" section, there MUST exist a publicly available 883 specification which describes a mechanism for associating the 884 received data with the correct "m=" section. 886 This document describes a mechanism to identify the protocol of 887 received data among the STUN, DTLS and SRTP protocols (in any 888 combination), when UDP is used as transport-layer protocol, but does 889 not describe how to identify different protocols transported on DTLS. 890 While the mechanism is generally applicable to other protocols and 891 transport-layer protocols, any such use requires further 892 specification around how to multiplex multiple protocols on a given 893 transport-layer protocol, and how to associate received data with the 894 correct protocols. 896 9.1. STUN, DTLS, SRTP 898 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 899 protocol of a received packet among the STUN, Datagram Transport 900 Layer Security (DTLS) and SRTP protocols (in any combination). If an 901 offer or answer includes bundled "m=" section that represent these 902 protocols, the offerer or answerer MUST support the mechanism 903 described in [RFC5764], and no explicit negotiation is required in 904 order to indicate support and usage of the mechanism. 906 [RFC5764] does not describe how to identify different protocols 907 transported on DTLS, only how to identify the DTLS protocol itself. 908 If multiple protocols are transported on DTLS, there MUST exist a 909 specification describing a mechanism for identifying each individual 910 protocol. In addition, if a received DTLS packet can be associated 911 with more than one "m=" section, there MUST exist a specification 912 which describes a mechanism for associating the received DTLS packet 913 with the correct "m=" section. 915 [Section 10.2] describes how to associate the packets in a received 916 SRTP stream with the correct "m=" section. 918 10. RTP Considerations 920 10.1. Single RTP Session 922 All RTP-based media within a single BUNDLE group belong to a single 923 RTP session [RFC3550]. 925 Since a single BUNDLE transport is used for sending and receiving 926 bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for 927 RTP-based bundled media. 929 Since a single RTP session is used for each BUNDLE group, all "m=" 930 sections representing RTP-based media within a BUNDLE group will 931 share a single SSRC numbering space [RFC3550]. 933 The following rules and restrictions apply for a single RTP session: 935 o A specific payload type value can be used in multiple bundled "m=" 936 sections only if each codec associated with the payload type 937 number shares an identical codec configuration [Section 10.1.1]. 939 o The proto value in each bundled RTP-based "m=" section MUST be 940 identical (e.g. RTP/AVPF). 942 o The RTP MID header extension MUST be enabled, by including an SDP 943 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 944 hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section 945 in every offer and answer. 947 o A given SSRC MUST NOT transmit RTP packets using payload types 948 that originate from different bundled "m=" sections. 950 NOTE: The last bullet above is to avoid sending multiple media types 951 from the same SSRC. If transmission of multiple media types are done 952 with time overlap, RTP and RTCP fail to function. Even if done in 953 proper sequence this causes RTP Timestamp rate switching issues 954 [RFC7160]. However, once an SSRC has left the RTP session (by 955 sending an RTCP BYE packet), that SSRC can be reused by another 956 source (possibly associated with a different bundled "m=" section) 957 after a delay of 5 RTCP reporting intervals (the delay is to ensure 958 the SSRC has timed out, in case the RTCP BYE packet was lost 959 [RFC3550]). 961 10.1.1. Payload Type (PT) Value Reuse 963 Multiple bundled "m=" section might describe RTP based media. As all 964 RTP based media associated with a BUNDLE group belong to the same RTP 965 session, in order for a given payload type value to be used inside 966 more than one bundled "m=" section, all codecs associated with the 967 payload type number MUST share an identical codec configuration. 968 This means that the codecs MUST share the same media type, encoding 969 name, clock rate and any parameter that can affect the codec 970 configuration and packetization. 971 [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose 972 attribute values must be identical for all codecs that use the same 973 payload type value. 975 10.2. Associating RTP/RTCP Streams With Correct SDP Media Description 977 NOTE: The text in this section is copied from Appendix B of JSEP. 978 The community has not yet agreed on the text. 980 As described in [RFC3550], RTP packets are associated with RTP 981 streams [RFC7656]. Each RTP stream is identified by an SSRC value, 982 and each RTP packet includes an SSRC field that is used to associate 983 the packet with the correct RTP stream. RTCP packets also use SSRCs 984 to identify which RTP streams the packet relates to. However, a RTCP 985 packet can contain multiple SSRC fields, in the course of providing 986 feedback or reports on different RTP streams, and therefore can be 987 associated with multiple such streams. 989 In order to be able to process received RTP/RTCP packets correctly, 990 it must be possible to associate an RTP stream with the correct "m=" 991 section, as the "m=" section and SDP attributes associated with the 992 "m=" section contains information needed to process the packets. 994 As all RTP streams associated with a BUNDLE group use the same 995 transport for sending and receiving RTP/RTCP packets, the local 996 address:port combination part of the transport cannot be used to 997 associate an RTP stream with the correct "m=" section. In addition, 998 multiple RTP streams might be associated with the same "m=" section. 1000 An offerer and answerer can inform each other which SSRC values they 1001 will use for an RTP stream by using the SDP 'ssrc' attribute 1002 [RFC5576]. However, an offerer will not know which SSRC values the 1003 answerer will use until the offerer has received the answer providing 1004 that information. Due to this, before the offerer has received the 1005 answer, the offerer will not be able to associate an RTP stream with 1006 the correct "m=" section using the SSRC value associated with the RTP 1007 stream. In addition, the offerer and answerer may start using new 1008 SSRC values mid-session, without informing each other using the SDP 1009 'ssrc' attribute. 1011 In order for an offerer and answerer to always be able to associate 1012 an RTP stream with the correct "m=" section, the offerer and answerer 1013 using the BUNDLE extension MUST support the mechanism defined in 1014 Section 15, where the offerer and answerer insert the identification- 1015 tag associated with an "m=" section (provided by the remote peer) 1016 into RTP and RTCP packets associated with a BUNDLE group. 1018 When using this mechanism, the mapping from an SSRC to an 1019 identification-tag is carried in RTP header extensions or RTCP SDES 1020 packets, as specified in Section 15. Since a compound RTCP packet 1021 can contain multiple RTCP SDES packets, and each RTCP SDES packet can 1022 contain multiple chunks, a single RTCP packet can contain several 1023 SSRC to identification-tag mappings. The offerer and answerer 1024 maintain tables used for routing that are updated each time an RTP/ 1025 RTCP packet contains new information that affects how packets should 1026 be routed. 1028 However, some implementations of may not include this identification- 1029 tag in their RTP and RTCP traffic when using the BUNDLE mechanism, 1030 and instead use a payload type based mechanism to associate RTP 1031 streams with SDP "m=" sections. In this situation, each "m=" section 1032 MUST use unique payload type values, in order for the payload type to 1033 be a reliable indicator of the relevant "m=" section for the RTP 1034 stream. Note that when using the payload type to associate RTP 1035 streams with "m=" sections an RTP stream, identified by SSRC, will be 1036 mapped to an "m=" section when the first packet of that RTP stream is 1037 received, and the mapping will not be changed even if the payload 1038 type used by that RTP stream changes. In other words, the SSRC 1039 cannot to "move" to a different "m=" section simply by changing the 1040 payload type. 1042 Applications can implement RTP stacks in many different ways. The 1043 algorithm below details one way that RTP streams can be associated 1044 with "m=" sections, but is not meant to be prescriptive about exactly 1045 how an RTP stack needs to be implemented. Applications MAY use any 1046 algorithm that achieves equivalent results to those described in the 1047 algorithm below. 1049 To prepare to associate RTP streams with the correct "m=" section, 1050 the following steps MUST be followed for each BUNDLE group. 1052 Construct a table mapping MID to "m=" section for each "m=" 1053 section in this BUNDLE group. Note that an "m=" section may only 1054 have one MID. 1056 Construct a table mapping SSRCs of incoming RTP streams to "m=" 1057 section for each "m=" section in this BUNDLE group and for each 1058 SSRC configured for receiving in that "m=" section. 1060 Construct a table mapping the SSRC of each outgoing RTP stream to 1061 "m=" section for each "m=" section in this BUNDLE group and for 1062 each SSRC configured for sending in that "m=" section. 1064 Construct a table mapping payload type to "m=" section for each 1065 "m=" section in the BUNDLE group and for each payload type 1066 configured for receiving in that "m=" section. If any payload 1067 type is configured for receiving in more than one "m=" section in 1068 the BUNDLE group, do not it include it in the table, as it cannot 1069 be used to uniquely identify a "m=" section. 1071 Note that for each of these tables, there can only be one mapping 1072 for any given key (MID, SSRC, or PT). In other words, the tables 1073 are not multimaps. 1075 As "m=" sections are added or removed from the BUNDLE groups, or 1076 their configurations are changed, the tables above MUST also be 1077 updated. 1079 When an RTP packet is received, it MUST be delivered to the RTP 1080 stream corresponding to its SSRC. That RTP stream MUST then be 1081 associated with the correct "m=" section within a BUNDLE group, for 1082 additional processing, according to the following steps. 1084 If the MID associated with the RTP stream is not in the table 1085 mapping MID to "m=" section, then the RTP stream is not decoded 1086 and the payload data is discarded. 1088 If the packet has a MID, and the packet's extended sequence number 1089 is greater than that of the last MID update, as discussed in 1090 [RFC7941], Section 4.2.6, update the MID associated with the RTP 1091 stream to match the MID carried in the RTP packet, then update the 1092 mapping tables to include an entry that maps the SSRC of that RTP 1093 stream to the "m=" section for that MID. 1095 If the SSRC of the RTP stream is in the incoming SSRC mapping 1096 table, check that the payload type used by the RTP stream matches 1097 a payload type included on the matching "m=" section. If so, 1098 associate the RTP stream with that "m=" section. Otherwise, the 1099 RTP stream is not decoded and the payload data is discarded. 1101 If the payload type used by the RTP stream is in the payload type 1102 table, update the incoming SSRC mapping table to include an entry 1103 that maps the RTP stream's SSRC to the "m=" section for that 1104 payload type. Associate the RTP stream with the corresponding 1105 "m=" section. 1107 Otherwise, mark the RTP stream as not for decoding and discard the 1108 payload. 1110 If the RTP packet contains one of more contributing source (CSRC) 1111 identifiers, then each CSRC is looked up in the incoming SSRC table 1112 and a copy of the RTP packet is associated with the corresponding 1113 "m=" section for additional processing. 1115 For each RTCP packet received (including each RTCP packet that is 1116 part of a compound RTCP packet), the packet is processed as usual by 1117 the RTP layer, then is passed to the "m=" sections corresponding to 1118 the RTP streams it contains information about for additional 1119 processing. This routing is type-dependent, as each kind of RTCP 1120 packet has its own mechanism for associating it with the relevant RTP 1121 streams. 1123 RTCP packets for which no appropriate "m=" section can be identified 1124 MUST be processed as usual by the RTP layer, updating the metadata 1125 associated with the corresponding RTP streams, but are not passed to 1126 any "m=" section. This situation can occur with certain multiparty 1127 RTP topologies, or when RTCP packets are sent containing a subset of 1128 the SDES information. 1130 Rules for additional processing of the various types of RTCP packets 1131 are explained below. 1133 If the RTCP packet is of type SDES, for each chunk in the packet 1134 whose SSRC is found in the incoming SSRC table, deliver a copy of 1135 the SDES packet to the "m=" section associated with that SSRC. In 1136 addition, for any SDES MID items contained in these chunks, if the 1137 MID is found in the table mapping MID to "m=" section, update the 1138 incoming SSRC table to include an entry that maps the RTP stream 1139 associated with chunk's SSRC to the "m=" section associated with 1140 that MID, unless the packet is older than the packet that most 1141 recently updated the mapping for this SSRC, as discussed in 1142 [RFC7941], Section 4.2.6. 1144 Note that if an SDES packet is received as part of a compound RTCP 1145 packet, the SSRC to "m=" section mapping may not exist until the 1146 SDES packet is handled (e.g., in the case where RTCP for a source 1147 is received before any RTP packets). Therefore, when processing a 1148 compound packet, any contained SDES packet MUST be handled first. 1149 Note that this is a backwards change from [RFC3550] Section 6.1, 1150 which states that "Each individual RTCP packet in the compound 1151 packet may be processed independently with no requirements upon 1152 the order or combination of packets". 1154 If the RTCP packet is of type BYE, it indicates that the RTP 1155 streams referenced in the packet are ending. Therefore, for each 1156 SSRC indicated in the packet that is found in the incoming SSRC 1157 table, first deliver a copy of the BYE packet to the "m=" section 1158 associated with that SSRC, but then remove the entry for that SSRC 1159 from the incoming SSRC table after an appropriate delay to account 1160 for "straggler packets", as specified in [RFC3550], Section 6.2.1. 1162 If the RTCP packet is of type SR or RR, for each report block in 1163 the report whose "SSRC of source" is found in the outgoing SSRC 1164 table, deliver a copy of the SR or RR packet to the "m=" section 1165 associated with that SSRC. In addition, if the packet is of type 1166 SR, and the sender SSRC for the packet is found in the incoming 1167 SSRC table, deliver a copy of the SR packet to the "m=" section 1168 associated with that SSRC. 1170 If the implementation supports RTCP XR and the packet is of type 1171 XR, as defined in [RFC3611], for each report block in the report 1172 whose "SSRC of source" is is found in the outgoing SSRC table, 1173 deliver a copy of the XR packet to the "m=" section associated 1174 with that SSRC. In addition, if the sender SSRC for the packet is 1175 found in the incoming SSRC table, deliver a copy of the XR packet 1176 to the "m=" section associated with that SSRC. 1178 If the RTCP packet is a feedback message of type RTPFB or PSFB, as 1179 defined in [RFC4585], it will contain a media source SSRC, and 1180 this SSRC is used for routing certain subtypes of feedback 1181 messages. However, several subtypes of PSFB messages include 1182 target SSRC(s) in a section called Feedback Control Information 1183 (FCI). For these messages, the target SSRC(s) are used for 1184 routing. 1186 If the RTCP packet is a feedback packet that does not include 1187 target SSRCs in its FCI section, and the media source SSRC is 1188 found in the outgoing SSRC table, deliver the feedback packet to 1189 the "m=" section associated with that SSRC. RTPFB and PSFB types 1190 that are handled in this way include: 1192 Generic NACK: [RFC4585] (PT=RTPFB, FMT=1). 1194 Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1). 1196 Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2). 1198 Reference Picture Selection Indication (RPSI): [RFC4585] 1199 (PT=PSFB, FMT=3). 1201 If the RTCP packet is a feedback message that does include target 1202 SSRC(s) in its FCI section, it can either be a request or a 1203 notification. Requests reference a RTP stream that is being sent 1204 by the message recipient, whereas notifications are responses to 1205 an earlier request, and therefore reference a RTP stream that is 1206 being received by the message recipient. 1208 If the RTCP packet is a feedback request that includes target 1209 SSRC(s), for each target SSRC that is found in the outgoing SSRC 1210 table, deliver a copy of the RTCP packet to the "m=" section 1211 associated with that SSRC. PSFB types that are handled in this 1212 way include: 1214 Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). 1216 Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, 1217 FMT=5). 1219 H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, 1220 FMT=7). 1222 Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, 1223 FMT=TBD). 1225 If the RTCP packet is a feedback notification that include target 1226 SSRC(s), for each target SSRC that is found in the incoming SSRC 1227 table, deliver a copy of the RTCP packet to the "m=" section 1228 associated with the RTP stream with matching SSRC. PSFB types 1229 that are handled in this way include: 1231 Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] 1232 (PT=PSFB, FMT=6). This message is a notification in response 1233 to a prior TSTR. 1235 If the RTCP packet is of type APP, then it is handled in an 1236 application specific manner. If the application does not 1237 recognise the APP packet, then it MUST be discarded. 1239 10.3. RTP/RTCP Multiplexing 1241 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 1242 multiplexing [RFC5761] for the RTP-based media specified by the 1243 BUNDLE group. 1245 When RTP/RTCP multiplexing is enabled, the same transport will be 1246 used for both RTP packets and RTCP packets associated with the BUNDLE 1247 group. 1249 10.3.1. SDP Offer/Answer Procedures 1251 This section describes how an offerer and answerer use the SDP 'rtcp- 1252 mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute 1253 [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP 1254 multiplexing for RTP-based media associated with a BUNDLE group. 1256 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] of the SDP 1257 'rtcp-mux' and 'rtcp-mux-only' attributes is IDENTICAL. Section 8.1 1258 describes the details regarding which bundled "m=" sections an 1259 offerer and answerer associates the attributes with. 1261 RTP/RTCP multiplexing only applies to RTP-based media. However, as 1262 described in Section 8.1, within a BUNDLE group the SDP 'rtcp-mux' 1263 and SDP 'rtcp-mux-only' attributes might be included in a non-RTP- 1264 based bundled "m=" section. 1266 10.3.1.1. Generating the Initial SDP Offer 1268 When an offerer generates an initial offer, if the offer contains one 1269 or more RTP-based bundled "m=" sections (or, if there is a chance 1270 that RTP-based "m=" sections will later be added to the BUNDLE 1271 group), the offerer MUST include an SDP 'rtcp-mux' attribute 1272 [RFC5761] in one or more "m=" sections, following the procedures for 1273 IDENTICAL mux category attributes in Section 8.1. In addition, the 1274 offerer MAY include an SDP 'rtcp-mux-only' attribute 1275 [I-D.ietf-mmusic-mux-exclusive] in the same "m=" section. 1277 NOTE: Whether the offerer associates the SDP 'rtcp-mux-only' 1278 attribute depends on whether the offerer supports fallback to usage 1279 of a separate port for RTCP in case the answerer moves one or more 1280 RTP-based "m=" section out of the BUNDLE group in the answer. 1282 NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in one or 1283 more bundled "m=" sections, but does not include an SDP 'rtcp-mux- 1284 only' attribute, the offerer can also include an SDP 'rtcp' attribute 1285 [RFC3605] in one or more RTP-based "m=" sections in order to provide 1286 a fallback port for RTCP, as described in [RFC5761]. However, the 1287 fallback port will only be used for RTP-based "m=" sections moved out 1288 of the BUNDLE group by the answerer. 1290 In the initial offer, the address:port combination for RTCP MUST be 1291 unique in each bundled RTP-based "m=" section (excluding a bundle- 1292 only "m=" section), similar to RTP. 1294 10.3.1.2. Generating the SDP Answer 1296 When an answerer generates an answer, if the answerer supports RTP- 1297 based media, and if a bundled "m=" section in the offer contained an 1298 SDP 'rtcp-mux' attribute, the answerer MUST enable usage of RTP/RTCP 1299 multiplexing, even if there currently are no RTP-based "m=" sections 1300 within the BUNDLE group. The answerer MUST include an SDP 'rtcp-mux' 1301 attribute in "m=" sections within the BUNDLE group in the answer 1302 following the procedures for IDENTICAL mux category attributes in 1303 Section 8.1. In addition, if the "m=" section in the offer contained 1304 an an SDP "rtcp-mux-only" attribute, the answerer MUST include an SDP 1305 "rtcp-mux-only" attribute to the "m=" section in the answer. 1307 If the "m=" section associated with the offerer BUNDLE-tag in the 1308 offer contained an SDP 'rtcp-mux-only' attribute, and if the answerer 1309 moves an RTP-based "m=" section out of the BUNDLE group in the answer 1310 Section 8.3.3, the answerer MUST either include the attribute with in 1311 moved "m=" section (and enable RTP/RTCP multiplexing for the media 1312 associated with the "m=" section), or reject the "m=" section 1313 Section 8.3.4. 1315 The answerer MUST NOT include an SDP 'rtcp' attribute in any "m=" 1316 section within the BUNDLE group in the answer. The answerer will use 1317 the port value of the selected offerer BUNDLE address for sending RTP 1318 and RTCP packets associated with each RTP-based bundled "m=" section 1319 towards the offerer. 1321 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1322 negotiated in a previous offer/answer transaction, the answerer MUST 1323 include an SDP 'rtcp-mux' attribute in the "m=" section associated 1324 with the answerer BUNDLE-tag in the answer. It is not possible to 1325 disable RTP/RTCP multiplexing within a BUNDLE group. 1327 10.3.1.3. Offerer Processing of the SDP Answer 1329 When an offerer receives an answer, if the answerer has accepted the 1330 usage of RTP/RTCP multiplexing (see Section 10.3.1.2), the answerer 1331 follows the procedures for RTP/RTCP multiplexing defined in 1332 [RFC5761]. The offerer will use the port value associated with the 1333 answerer BUNDLE address for sending RTP and RTCP packets associated 1334 with each RTP-based bundled "m=" section towards the answerer. 1336 NOTE: It is considered a protocol error if the answerer has not 1337 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" 1338 sections that the answerer included in the BUNDLE group. 1340 10.3.1.4. Modifying the Session 1342 When an offerer generates a subsequent offer, the offerer MUST 1343 include an SDP 'rtcp-mux' attribute in a bundled "m=" section, 1344 following the procedures for IDENTICAL mux category attributes in 1345 Section 8.1. 1347 If the offerer wants to add a bundled RTP-based "m=" section to the 1348 BUNDLE group, it MAY also include an SDP 'rtcp-mux-only' attribute in 1349 a bundled "m=" section, following the procedures for IDENTICAL mux 1350 category attributes in Section 8.1. This allows the offerer to 1351 mandate RTP/RTCP multiplexing for the added "m=" section (or the "m=" 1352 section to be rejected by the answerer) even if the answerer does not 1353 accept the "m=" section within the BUNDLE group. 1355 11. ICE Considerations 1357 This section describes how to use the BUNDLE grouping extension 1358 together with the Interactive Connectivity Establishment (ICE) 1359 mechanism [I-D.ietf-ice-rfc5245bis]. 1361 The generic procedures for negotiating usage of ICE using SDP, 1362 defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE 1363 with BUNDLE, with the following exceptions: 1365 o When the BUNDLE transport has been established, ICE connectivity 1366 checks and keep-alives only need to be performed for the BUNDLE 1367 transport, instead of per individual "m=" section within the 1368 BUNDLE group. 1370 o In an offer, if the offer assigns a unique address to one or more 1371 bundled "m=" sections (excluding any bundle-only "m=" section), 1372 the offerer MUST include ICE-related media-level attributes in 1373 each of those "m=" sections. If the offerer assigns an offerer 1374 BUNDLE address (previously selected [Section 8.3.1] or new 1375 suggested [Section 8.5.1]) to a bundled "m=" section (the "m=" 1376 section represented by the offerer BUNDLE-tag), the offerer only 1377 includes ICE-related media-level SDP attributes in that "m=" 1378 section, following the procedures in Section 8.1. 1380 o In an answer, the answerer only includes ICE-related media-level 1381 SDP attributes in the bundled "m=" section to which the answerer 1382 has assigned the answerer BUNDLE address (the "m=" section 1383 represented by the answerer BUNDLE-tag), following the procedures 1384 in Section 8.1. 1386 Initially, before ICE has produced a candidate pair that will be used 1387 for media, there might by multiple transports established (if 1388 multiple candidate pairs are tested). Once ICE has produced a 1389 transport that will be used for media, that becomes the BUNDLE 1390 transport. 1392 Support and usage of ICE mechanism together with the BUNDLE extension 1393 is OPTIONAL. 1395 11.1. SDP Offer/Answer Procedures 1397 When an offerer assigns a unique address to one or more bundled "m=" 1398 sections (excluding any bundle-only "m=" section), the offerer MUST 1399 include SDP 'candidate' attributes (and other applicable ICE-related 1400 media-level SDP attributes), containing unique ICE properties 1401 (candidates etc), in each of those "m=" sections, follwoing the 1402 procedures in [I-D.ietf-mmusic-ice-sip-sdp]. 1404 When an offerer assigns a BUNDLE address (previously selected or new 1405 suggested) to a bundled "m=" section, (the "m=" section represented 1406 by the offerer BUNDLE-tag) the offerer MUST only include SDP 1407 'candidate' attributes (and other applicable ICE-related media-level 1408 SDP attributes) in that "m=" section, following the procedures in 1409 Section 8.1. 1411 When an answerer assigns a BUNDLE address to an "m=" section within a 1412 BUNDLE group (the "m=" section represented by the answerer BUNDLE- 1413 tag), the answerer MUST only include SDP 'candidate' attributes (and 1414 other applicable ICE-related media-level SDP attributes) in that "m=" 1415 section, following the procedures in Section 8.1. 1417 NOTE: As most ICE-related media-level SDP attributes belong to the 1418 TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the 1419 offerer and answerer follow the procedures in Section 8.1 when 1420 deciding whether to include an attribute in a bundled "m=" section. 1421 However, in the case of ICE-related media-level attributes, the rules 1422 apply to all attributes (see note below), even if they belong to a 1423 different mux category. 1425 NOTE: The following ICE-related media-level SDP attributes are 1426 defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote- 1427 candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- 1428 pacing'. 1430 12. DTLS Considerations 1432 One or more media streams within a BUNDLE group might use the 1433 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1434 to encrypt the data, or to negotiate encryption keys if another 1435 encryption mechanism is used to encrypt media. 1437 When DTLS is used within a BUNDLE group, the following rules apply: 1439 o There can only be one DTLS association [RFC6347] associated with 1440 the BUNDLE group; and 1442 o Each usage of the DTLS association within the BUNDLE group MUST 1443 use the same mechanism for determining which endpoints (the 1444 offerer or answerer) become DTLS client and DTLS server; and 1446 o Each usage of the DTLS association within the Bundle group MUST 1447 use the same mechanism for determining whether an offer or answer 1448 will trigger the establishment of a new DTLS association, or 1449 whether an existing DTLS association will be used; and 1451 o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include 1452 the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message 1453 [RFC5764], The client MUST include the extension even if the usage 1454 of DTLS-SRTP is not negotiated as part of the multimedia session 1455 (e.g., SIP session [RFC3261]. 1457 NOTE: The inclusion of the 'use_srtp' extension during the initial 1458 DTLS handshake ensures that a DTLS renegotiation will not be required 1459 in order to include the extension, in case DTLS-SRTP encrypted media 1460 is added to the BUNDLE group later during the multimedia session. 1462 13. RTP Header Extensions Consideration 1464 When [RFC8285] RTP header extensions are used in the context of this 1465 specification, the identifier used for a given extension MUST 1466 identify the same extension across all the bundled media 1467 descriptions. 1469 14. Update to RFC 3264 1471 This section replaces the text of the following sections of RFC 3264: 1473 o Section 5.1 (Unicast Streams). 1475 o Section 6 (Generating the Answer). 1477 o Section 8.2 (Removing a Media Stream). 1479 o Section 8.4 (Putting a Unicast Media Stream on Hold). 1481 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 1483 For recvonly and sendrecv streams, the port number and address in the 1484 offer indicate where the offerer would like to receive the media 1485 stream. For sendonly RTP streams, the address and port number 1486 indirectly indicate where the offerer wants to receive RTCP reports. 1487 Unless there is an explicit indication otherwise, reports are sent to 1488 the port number one higher than the number indicated. The IP address 1489 and port present in the offer indicate nothing about the source IP 1490 address and source port of RTP and RTCP packets that will be sent by 1491 the offerer. A port number of zero in the offer indicates that the 1492 stream is offered but MUST NOT be used. This has no useful semantics 1493 in an initial offer, but is allowed for reasons of completeness, 1494 since the answer can contain a zero port indicating a rejected stream 1495 (Section 6). Furthermore, existing streams can be terminated by 1496 setting the port to zero (Section 8). In general, a port number of 1497 zero indicates that the media stream is not wanted. 1499 14.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 1501 For recvonly and sendrecv streams, the port number and address in the 1502 offer indicate where the offerer would like to receive the media 1503 stream. For sendonly RTP streams, the address and port number 1504 indirectly indicate where the offerer wants to receive RTCP reports. 1505 Unless there is an explicit indication otherwise, reports are sent to 1506 the port number one higher than the number indicated. The IP address 1507 and port present in the offer indicate nothing about the source IP 1508 address and source port of RTP and RTCP packets that will be sent by 1509 the offerer. A port number of zero in the offer by default indicates 1510 that the stream is offered but MUST NOT be used, but an extension 1511 mechanism might specify different semantics for the usage of a zero 1512 port value. Furthermore, existing streams can be terminated by 1513 setting the port to zero (Section 8). In general, a port number of 1514 zero by default indicates that the media stream is not wanted. 1516 14.3. Original text of section 6 (4th paragraph) of RFC 3264 1518 An offered stream MAY be rejected in the answer, for any reason. If 1519 a stream is rejected, the offerer and answerer MUST NOT generate 1520 media (or RTCP packets) for that stream. To reject an offered 1521 stream, the port number in the corresponding stream in the answer 1522 MUST be set to zero. Any media formats listed are ignored. At least 1523 one MUST be present, as specified by SDP. 1525 14.4. New text replacing section 6 (4th paragraph) of RFC 3264 1527 An offered stream MAY be rejected in the answer, for any reason. If 1528 a stream is rejected, the offerer and answerer MUST NOT generate 1529 media (or RTCP packets) for that stream. A port number of zero in 1530 the answer by default indicates that the offered stream is rejected, 1531 but an extension mechanism might specify different semantics for the 1532 usage of a zero port value. If a stream is rejected, any media 1533 formats listed are ignored. At least one MUST be present, as 1534 specified by SDP. 1536 14.5. Original text of section 8.2 (2nd paragraph) of RFC 3264 1538 A stream that is offered with a port of zero MUST be marked with port 1539 zero in the answer. Like the offer, the answer MAY omit all 1540 attributes present previously, and MAY list just a single media 1541 format from amongst those in the offer. 1543 14.6. New text replacing section 8.2 (2nd paragraph) of RFC 3264 1545 A stream that is offered with a port of zero MUST by default be 1546 marked with port zero in the answer, unless an extension mechanism, 1547 which specifies semantics for the usage of a non-zero port value, is 1548 used. If the stream is marked with port zero in the answer, the 1549 answer MAY omit all attributes present previously, and MAY list just 1550 a single media format from amongst those in the offer." 1552 14.7. Original text of section 8.4 (6th paragraph) of RFC 3264 1554 RFC 2543 [10] specified that placing a user on hold was accomplished 1555 by setting the connection address to 0.0.0.0. Its usage for putting 1556 a call on hold is no longer recommended, since it doesn't allow for 1557 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1558 with connection oriented media. However, it can be useful in an 1559 initial offer when the offerer knows it wants to use a particular set 1560 of media streams and formats, but doesn't know the addresses and 1561 ports at the time of the offer. Of course, when used, the port 1562 number MUST NOT be zero, which would specify that the stream has been 1563 disabled. An agent MUST be capable of receiving SDP with a 1564 connection address of 0.0.0.0, in which case it means that neither 1565 RTP nor RTCP should be sent to the peer. 1567 14.8. New text replacing section 8.4 (6th paragraph) of RFC 3264 1569 RFC 2543 [10] specified that placing a user on hold was accomplished 1570 by setting the connection address to 0.0.0.0. Its usage for putting 1571 a call on hold is no longer recommended, since it doesn't allow for 1572 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1573 with connection oriented media. However, it can be useful in an 1574 initial offer when the offerer knows it wants to use a particular set 1575 of media streams and formats, but doesn't know the addresses and 1576 ports at the time of the offer. Of course, when used, the port 1577 number MUST NOT be zero, if it would specify that the stream has been 1578 disabled. However, an extension mechanism might specify different 1579 semantics of the zero port number usage. An agent MUST be capable of 1580 receiving SDP with a connection address of 0.0.0.0, in which case it 1581 means that neither RTP nor RTCP should be sent to the peer. 1583 15. RTP/RTCP extensions for identification-tag transport 1585 SDP Offerers and Answerers [RFC3264] can associate identification- 1586 tags with "m=" sections within SDP Offers and Answers, using the 1587 procedures in [RFC5888]. Each identification-tag uniquely represents 1588 an "m=" section. 1590 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1591 used to carry identification-tags within RTCP SDES packets. This 1592 section also defines a new RTP SDES header extension [RFC7941], which 1593 is used to carry the 'MID' RTCP SDES item in RTP packets. 1595 The SDES item and RTP SDES header extension make it possible for a 1596 receiver to associate each RTP stream with with a specific "m=" 1597 section, with which the receiver has associated an identification- 1598 tag, even if those "m=" sections are part of the same RTP session. 1599 The RTP SDES header extension also ensures that the media recipient 1600 gets the identification-tag upon receipt of the first decodable media 1601 and is able to associate the media with the correct application. 1603 A media recipient informs the media sender about the identification- 1604 tag associated with an "m=" section through the use of an 'mid' 1605 attribute [RFC5888]. The media sender then inserts the 1606 identification-tag in RTCP and RTP packets sent to the media 1607 recipient. 1609 NOTE: This text above defines how identification-tags are carried in 1610 SDP Offers and Answers. The usage of other signalling protocols for 1611 carrying identification-tags is not prevented, but the usage of such 1612 protocols is outside the scope of this document. 1614 [RFC3550] defines general procedures regarding the RTCP transmission 1615 interval. The RTCP MID SDES item SHOULD be sent in the first few 1616 RTCP packets sent after joining the session, and SHOULD be sent 1617 regularly thereafter. The exact number of RTCP packets in which this 1618 SDES item is sent is intentionally not specified here, as it will 1619 depend on the expected packet loss rate, the RTCP reporting interval, 1620 and the allowable overhead. 1622 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1623 be included in some RTP packets at the start of the session and 1624 whenever the SSRC changes. It might also be useful to include the 1625 header extension in RTP packets that comprise access points in the 1626 media (e.g., with video I-frames). The exact number of RTP packets 1627 in which this header extension is sent is intentionally not specified 1628 here, as it will depend on expected packet loss rate and loss 1629 patterns, the overhead the application can tolerate, and the 1630 importance of immediate receipt of the identification-tag. 1632 For robustness purpose, endpoints need to be prepared for situations 1633 where the reception of the identification-tag is delayed, and SHOULD 1634 NOT terminate sessions in such cases, as the identification-tag is 1635 likely to arrive soon. 1637 15.1. RTCP MID SDES Item 1639 0 1 2 3 1640 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 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | MID=TBD | length | identification-tag ... 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 The identification-tag payload is UTF-8 encoded, as in SDP. 1647 The identification-tag is not zero terminated. 1649 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1650 identifier value.] 1652 15.2. RTP SDES Header Extension For MID 1654 The payload, containing the identification-tag, of the RTP SDES 1655 header extension element can be encoded using either the one-byte or 1656 two-byte header [RFC7941]. The identification-tag payload is UTF-8 1657 encoded, as in SDP. 1659 The identification-tag is not zero terminated. Note, that the set of 1660 header extensions included in the packet needs to be padded to the 1661 next 32-bit boundary using zero bytes [RFC8285]. 1663 As the identification-tag is included in either an RTCP SDES item or 1664 an RTP SDES header extension, or both, there should be some 1665 consideration about the packet expansion caused by the 1666 identification-tag. To avoid Maximum Transmission Unit (MTU) issues 1667 for the RTP packets, the header extension's size needs to be taken 1668 into account when encoding the media. 1670 It is recommended that the identification-tag is kept short. Due to 1671 the properties of the RTP header extension mechanism, when using the 1672 one-byte header, a tag that is 1-3 bytes will result in a minimal 1673 number of 32-bit words used for the RTP SDES header extension, in 1674 case no other header extensions are included at the same time. Note, 1675 do take into account that some single characters when UTF-8 encoded 1676 will result in multiple octets. The identification-tag MUST NOT 1677 contain any user information, and applications SHALL avoid generating 1678 the identification-tag using a pattern that enables application 1679 identification. 1681 16. IANA Considerations 1683 16.1. New SDES item 1685 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1686 document.] 1688 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1689 identifier value.] 1691 This document adds the MID SDES item to the IANA "RTP SDES item 1692 types" registry as follows: 1694 Value: TBD 1695 Abbrev.: MID 1696 Name: Media Identification 1697 Reference: RFCXXXX 1699 16.2. New RTP SDES Header Extension URI 1701 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1702 document.] 1704 This document defines a new extension URI in the RTP SDES Compact 1705 Header Extensions sub-registry of the RTP Compact Header Extensions 1706 registry sub-registry, according to the following data: 1708 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1709 Description: Media identification 1710 Contact: christer.holmberg@ericsson.com 1711 Reference: RFCXXXX 1713 The SDES item does not reveal privacy information about the users. 1714 It is simply used to associate RTP-based media with the correct SDP 1715 media description ("m=" section) in the SDP used to negotiate the 1716 media. 1718 The purpose of the extension is for the offerer to be able to 1719 associate received multiplexed RTP-based media before the offerer 1720 receives the associated SDP answer. 1722 16.3. New SDP Attribute 1724 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1725 document.] 1727 This document defines a new SDP media-level attribute, 'bundle-only', 1728 according to the following data: 1730 Attribute name: bundle-only 1731 Type of attribute: media 1732 Subject to charset: No 1733 Purpose: Request a media description to be accepted 1734 in the answer only if kept within a BUNDLE 1735 group by the answerer. 1736 Appropriate values: N/A 1737 Contact name: Christer Holmberg 1738 Contact e-mail: christer.holmberg@ericsson.com 1739 Reference: RFCXXXX 1740 Mux category: NORMAL 1742 16.4. New SDP Group Semantics 1744 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1745 document.] 1747 This document registers the following semantics with IANA in the 1748 "Semantics for the "group" SDP Attribute" subregistry (under the 1749 "Session Description Protocol (SDP) Parameters" registry: 1751 Semantics Token Reference 1752 ------------------------------------- ------ --------- 1753 Media bundling BUNDLE [RFCXXXX] 1755 17. Security Considerations 1757 The security considerations defined in [RFC3264] and [RFC5888] apply 1758 to the BUNDLE extension. Bundle does not change which information, 1759 e.g., RTP streams, flows over the network, with the exception of the 1760 usage of the MID SDES item as discussed below. Primarily it changes 1761 which addresses and ports, and thus in which (RTP) sessions that the 1762 information is flowing in. This affects the security contexts being 1763 used and can cause previously separated information flows to share 1764 the same security context. This has very little impact on the 1765 performance of the security mechanism of the RTP sessions. In cases 1766 where one would have applied different security policies on the 1767 different RTP streams being bundled, or where the parties having 1768 access to the security contexts would have differed between the RTP 1769 stream, additional analysis of the implications are needed before 1770 selecting to apply BUNDLE. 1772 The identification-tag, independent of transport, RTCP SDES packet or 1773 RTP header extension, can expose the value to parties beyond the 1774 signaling chain. Therefore, the identification-tag values MUST be 1775 generated in a fashion that does not leak user information, e.g., 1776 randomly or using a per-bundle group counter, and SHOULD be 3 bytes 1777 or less, to allow them to efficiently fit into the MID RTP header 1778 extension. Note that if implementations use different methods for 1779 generating identification-tags this could enable fingerprinting of 1780 the implementation making it vulnerable to targeted attacks. The 1781 identification-tag is exposed on the RTP stream level when included 1782 in the RTP header extensions, however what it reveals of the RTP 1783 media stream structure of the endpoint and application was already 1784 possible to deduce from the RTP streams without the MID SDES header 1785 extensions. As the identification-tag is also used to route the 1786 media stream to the right application functionality it is also 1787 important that the value received is the one intended by the sender, 1788 thus integrity and the authenticity of the source are important to 1789 prevent denial of service on the application. Existing SRTP 1790 configurations and other security mechanisms protecting the whole 1791 RTP/RTCP packets will provide the necessary protection. 1793 When the BUNDLE extension is used, the set of configurations of the 1794 security mechanism used in all the bundled media descriptions will 1795 need to be compatible so that they can simultaneously used in 1796 parallel, at least per direction or endpoint. When using SRTP this 1797 will be the case, at least for the IETF defined key-management 1798 solutions due to their SDP attributes (a=crypto, a=fingerprint, 1799 a=mikey) and their classification in 1800 [I-D.ietf-mmusic-sdp-mux-attributes]. 1802 The security considerations of "RTP Header Extension for the RTP 1803 Control Protocol (RTCP) Source Description Items" [RFC7941] requires 1804 that when RTCP is confidentiality protected that any SDES RTP header 1805 extension carrying an SDES item, such as the MID RTP header 1806 extension, is also protected using commensurate strength algorithms. 1807 However, assuming the above requirements and recommendations are 1808 followed there are no known significant security risks with leaving 1809 the MID RTP header extension without confidentiality protection. 1810 Thus, the requirements in RFC 7941 MAY be ignored for the MID RTP 1811 header extension. Security mechanisms for RTP/RTCP are discussed in 1812 Options for Securing RTP Sessions [RFC7201], for example SRTP 1813 [RFC3711] can provide the necessary security functions of ensuring 1814 the integrity and source authenticity. 1816 18. Examples 1818 18.1. Example: Bundle Address Selection 1820 The example below shows: 1822 o An offer, in which the offerer assigns a unique address to each 1823 bundled "m=" section within the BUNDLE group. 1825 o An answer, in which the answerer selects the offerer BUNDLE 1826 address, and then selects its own BUNDLE address (the answerer 1827 BUNDLE address) and assigns it to the bundled "m=" section 1828 represented by the answerer BUNDLE-tag. 1830 SDP Offer (1) 1832 v=0 1833 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1834 s= 1835 c=IN IP4 atlanta.example.com 1836 t=0 0 1837 a=group:BUNDLE foo bar 1838 m=audio 10000 RTP/AVP 0 8 97 1839 b=AS:200 1840 a=mid:foo 1841 a=rtcp-mux 1842 a=rtpmap:0 PCMU/8000 1843 a=rtpmap:8 PCMA/8000 1844 a=rtpmap:97 iLBC/8000 1845 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1846 m=video 10002 RTP/AVP 31 32 1847 b=AS:1000 1848 a=mid:bar 1849 a=rtcp-mux 1850 a=rtpmap:31 H261/90000 1851 a=rtpmap:32 MPV/90000 1852 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1854 SDP Answer (2) 1856 v=0 1857 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1858 s= 1859 c=IN IP4 biloxi.example.com 1860 t=0 0 1861 a=group:BUNDLE foo bar 1862 m=audio 20000 RTP/AVP 0 1863 b=AS:200 1864 a=mid:foo 1865 a=rtcp-mux 1866 a=rtpmap:0 PCMU/8000 1867 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1868 m=video 0 RTP/AVP 32 1869 b=AS:1000 1870 a=mid:bar 1871 a=bundle-only 1872 a=rtpmap:32 MPV/90000 1873 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1875 18.2. Example: BUNDLE Extension Rejected 1877 The example below shows: 1879 o An offer, in which the offerer assigns a unique address to each 1880 bundled "m=" section within the BUNDLE group. 1882 o An answer, in which the answerer rejects the offered BUNDLE group, 1883 and assigns a unique address to each "m=" section (following 1884 normal RFC 3264 procedures). 1886 SDP Offer (1) 1888 v=0 1889 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1890 s= 1891 c=IN IP4 atlanta.example.com 1892 t=0 0 1893 a=group:BUNDLE foo bar 1894 m=audio 10000 RTP/AVP 0 8 97 1895 b=AS:200 1896 a=mid:foo 1897 a=rtcp-mux 1898 a=rtpmap:0 PCMU/8000 1899 a=rtpmap:8 PCMA/8000 1900 a=rtpmap:97 iLBC/8000 1901 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1902 m=video 10002 RTP/AVP 31 32 1903 b=AS:1000 1904 a=mid:bar 1905 a=rtcp-mux 1906 a=rtpmap:31 H261/90000 1907 a=rtpmap:32 MPV/90000 1908 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1910 SDP Answer (2) 1912 v=0 1913 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1914 s= 1915 c=IN IP4 biloxi.example.com 1916 t=0 0 1917 m=audio 20000 RTP/AVP 0 1918 b=AS:200 1919 a=rtcp-mux 1920 a=rtpmap:0 PCMU/8000 1921 m=video 30000 RTP/AVP 32 1922 b=AS:1000 1923 a=rtcp-mux 1924 a=rtpmap:32 MPV/90000 1926 18.3. Example: Offerer Adds A Media Description To A BUNDLE Group 1928 The example below shows: 1930 o A subsequent offer (the BUNDLE group has been created as part of a 1931 previous offer/answer exchange), in which the offerer adds a new 1932 "m=" section, represented by the "zen" identification-tag, to a 1933 previously negotiated BUNDLE group, assigns the previously 1934 selected offerer BUNDLE address to the added "m=" section, 1935 represented by the offerer BUNDLE-tag. To every other bundled 1936 "m=" section the offerer assigns a zero port value and includes an 1937 SDP 'bundle-only' attribute. 1939 o An answer, in which the answerer assigns the answerer BUNDLE 1940 address to the bundled "m=" section represented by the answerer 1941 BUNDLE-tag. To every other bundled "m=S section the answerer 1942 assigns a zero port value and includes an SDP 'bundle-only' 1943 attribute. 1945 SDP Offer (1) 1947 v=0 1948 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1949 s= 1950 c=IN IP4 atlanta.example.com 1951 t=0 0 1952 a=group:BUNDLE zen foo bar 1953 m=audio 0 RTP/AVP 0 8 97 1954 b=AS:200 1955 a=mid:foo 1956 a=bundle-only 1957 a=rtcp-mux 1958 a=rtpmap:0 PCMU/8000 1959 a=rtpmap:8 PCMA/8000 1960 a=rtpmap:97 iLBC/8000 1961 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1962 m=video 0 RTP/AVP 31 32 1963 b=AS:1000 1964 a=mid:bar 1965 a=rtpmap:31 H261/90000 1966 a=rtpmap:32 MPV/90000 1967 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1968 m=video 10000 RTP/AVP 66 1969 b=AS:1000 1970 a=mid:zen 1971 a=bundle-only 1972 a=rtcp-mux 1973 a=rtpmap:66 H261/90000 1974 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1976 SDP Answer (2) 1978 v=0 1979 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1980 s= 1981 c=IN IP4 biloxi.example.com 1982 t=0 0 1983 a=group:BUNDLE zen foo bar 1984 m=audio 0 RTP/AVP 0 1985 b=AS:200 1986 a=mid:foo 1987 a=bundle-only 1988 a=rtcp-mux 1989 a=rtpmap:0 PCMU/8000 1990 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1991 m=video 0 RTP/AVP 32 1992 b=AS:1000 1993 a=mid:bar 1994 a=bundle-only 1995 a=rtpmap:32 MPV/90000 1996 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1997 m=video 20000 RTP/AVP 66 1998 b=AS:1000 1999 a=mid:zen 2000 a=rtpmap:66 H261/90000 2001 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2003 18.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 2005 The example below shows: 2007 o A subsequent offer (the BUNDLE group has been created as part of a 2008 previous offer/answer transaction), in which the offerer moves a 2009 bundled "m=" section, represented by the "zen" identification-tag, 2010 out of a BUNDLE group, assigns a unique address to the moved "m=" 2011 section, and assigns the previously selected offerer BUNDLE 2012 address to another bundled "m=" section, represented by the 2013 offerer BUNDLE-tag. To every other bundled "m=" section the 2014 offerer assigns a zero port value and includes an SDP 'bundle- 2015 only' attribute. 2017 o An answer, in which the answerer moves the "m=" section out of the 2018 BUNDLE group, assigns a unique address to the moved "m=" section, 2019 and assigns the answerer BUNDLE address to the bundled "m=" 2020 section represented by the answerer BUNDLE-tag. To every other 2021 bundled "m=" section the answerer assigns a zero port value and 2022 includes an SDP 'bundle-only' attribute. 2024 SDP Offer (1) 2026 v=0 2027 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2028 s= 2029 c=IN IP4 atlanta.example.com 2030 t=0 0 2031 a=group:BUNDLE foo bar 2032 m=audio 10000 RTP/AVP 0 8 97 2033 b=AS:200 2034 a=mid:foo 2035 a=rtcp-mux 2036 a=rtpmap:0 PCMU/8000 2037 a=rtpmap:8 PCMA/8000 2038 a=rtpmap:97 iLBC/8000 2039 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2040 m=video 0 RTP/AVP 31 32 2041 b=AS:1000 2042 a=mid:bar 2043 a=bundle-only 2044 a=rtpmap:31 H261/90000 2045 a=rtpmap:32 MPV/90000 2046 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2047 m=video 50000 RTP/AVP 66 2048 b=AS:1000 2049 a=mid:zen 2050 a=rtcp-mux 2051 a=rtpmap:66 H261/90000 2053 SDP Answer (2) 2055 v=0 2056 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2057 s= 2058 c=IN IP4 biloxi.example.com 2059 t=0 0 2060 a=group:BUNDLE foo bar 2061 m=audio 20000 RTP/AVP 0 2062 b=AS:200 2063 a=mid:foo 2064 a=rtcp-mux 2065 a=rtpmap:0 PCMU/8000 2066 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2067 m=video 0 RTP/AVP 32 2068 b=AS:1000 2069 a=mid:bar 2070 a=bundle-only 2071 a=rtpmap:32 MPV/90000 2072 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2073 m=video 60000 RTP/AVP 66 2074 b=AS:1000 2075 a=mid:zen 2076 a=rtcp-mux 2077 a=rtpmap:66 H261/90000 2079 18.5. Example: Offerer Disables A Media Description Within A BUNDLE 2080 Group 2082 The example below shows: 2084 o A subsequent offer (the BUNDLE group has been created as part of a 2085 previous offer/answer transaction), in which the offerer disables 2086 a bundled "m=" section represented by the "zen" identification- 2087 tag, within a BUNDLE group, assigns a zero port number to the 2088 disabled "m=" section, and assigns the offerer BUNDLE address to 2089 another bundled "m=" section, represented by the offerer BUNDLE- 2090 tag. To every other bundled "m=" section the offerer assigns a 2091 zero port value and includes an SDP 'bundle-only' attribute. 2093 o An answer, in which the answerer moves the disabled "m=" sections 2094 out of the BUNDLE group, assigns a zero port value to the disabled 2095 "m=" section, and assigns the answerer BUNDLE address to the 2096 bundled "m=" section represented by the answerer BUNDLE-tag. To 2097 every other bundled "m=" section the answerer assigns a zero port 2098 value and includes an SDP 'bundle-only' attribute. 2100 SDP Offer (1) 2102 v=0 2103 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2104 s= 2105 c=IN IP4 atlanta.example.com 2106 t=0 0 2107 a=group:BUNDLE foo bar 2108 m=audio 10000 RTP/AVP 0 8 97 2109 b=AS:200 2110 a=mid:foo 2111 a=rtcp-mux 2112 a=rtpmap:0 PCMU/8000 2113 a=rtpmap:8 PCMA/8000 2114 a=rtpmap:97 iLBC/8000 2115 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2116 m=video 0 RTP/AVP 31 32 2117 b=AS:1000 2118 a=mid:bar 2119 a=bundle-only 2120 a=rtpmap:31 H261/90000 2121 a=rtpmap:32 MPV/90000 2122 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2123 m=video 0 RTP/AVP 66 2124 a=mid:zen 2125 a=rtpmap:66 H261/90000 2127 SDP Answer (2) 2129 v=0 2130 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2131 s= 2132 c=IN IP4 biloxi.example.com 2133 t=0 0 2134 a=group:BUNDLE foo bar 2135 m=audio 20000 RTP/AVP 0 2136 b=AS:200 2137 a=mid:foo 2138 a=rtcp-mux 2139 a=rtpmap:0 PCMU/8000 2140 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2141 m=video 0 RTP/AVP 32 2142 b=AS:1000 2143 a=mid:bar 2144 a=bundle-only 2145 a=rtpmap:32 MPV/90000 2146 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2147 m=video 0 RTP/AVP 66 2148 a=mid:zen 2149 a=rtpmap:66 H261/90000 2151 19. Acknowledgements 2153 The usage of the SDP grouping extension for negotiating bundled media 2154 is based on a similar alternatives proposed by Harald Alvestrand and 2155 Cullen Jennings. The BUNDLE extension described in this document is 2156 based on the different alternative proposals, and text (e.g., SDP 2157 examples) have been borrowed (and, in some cases, modified) from 2158 those alternative proposals. 2160 The SDP examples are also modified versions from the ones in the 2161 Alvestrand proposal. 2163 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 2164 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 2165 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin 2166 Uberti, Taylor Brandstetter, Byron Campen and Eric Rescorla for 2167 reading the text, and providing useful feedback. 2169 Thanks to Bernard Aboba, Cullen Jennings, Peter Thatcher, Justin 2170 Uberti, and Magnus Westerlund for providing the text for the section 2171 on RTP/RTCP stream association. 2173 Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for 2174 providing help and text on the RTP/RTCP procedures. 2176 Thanks to Spotify for providing music for the countless hours of 2177 document editing. 2179 20. Change Log 2181 [RFC EDITOR NOTE: Please remove this section when publishing] 2183 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-42 2185 o Changes based on final WG review. 2187 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-41 2189 o Update to section 6 o RFC 3264: 2191 o https://github.com/cdh4u/draft-sdp-bundle/pull/47 2193 o Editorial clarification on BUNDLE address selection: 2195 o https://github.com/cdh4u/draft-sdp-bundle/pull/46 2197 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40 2199 o Editorial changes and technical restrictions in order to make the 2200 specification more understandable: 2202 o https://github.com/cdh4u/draft-sdp-bundle/pull/45 2203 o - BUNDLE address is only assigned to m- section represented by 2204 BUNDLE-tag. 2206 o - bundle-only attribute also used in answers and subsequent 2207 offers. 2209 o - Answerer cannot reject, or remove, the bundled m- section that 2210 contains the BUNDLE address. 2212 o - ICE Offer/Answer sections removed, due to duplicated 2213 information. 2215 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39 2217 o Editorial terminology changes. 2219 o RFC 5285 reference replaced by reference to RFC 8285. 2221 o https://github.com/cdh4u/draft-sdp-bundle/pull/44 2223 o - Clarify that an m- section can not be moved between BUNDLE 2224 groups without first moving the m- section out of a BUNDLE group. 2226 o https://github.com/cdh4u/draft-sdp-bundle/pull/41 2228 o - Addition of BUNDLE transport concept. 2230 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38 2232 o Changes to RTP streaming mapping section based on text from Colin 2233 Perkins. 2235 o The following GitHub pull requests were merged: 2237 o https://github.com/cdh4u/draft-sdp-bundle/pull/34 2239 o - Proposed updates to RTP processing 2241 o https://github.com/cdh4u/draft-sdp-bundle/pull/35 2243 o - fixed reference to receiver-id section 2245 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-37 2247 o The following GitHub pull request was merged: 2249 o https://github.com/cdh4u/draft-sdp-bundle/pull/33 2250 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36 2252 o The following GitHub pull requests were merged: 2254 o https://github.com/cdh4u/draft-sdp-bundle/pull/32 2256 o - extmap handling in BUNDLE. 2258 o https://github.com/cdh4u/draft-sdp-bundle/pull/31 2260 o - Additional Acknowledgement text added. 2262 o https://github.com/cdh4u/draft-sdp-bundle/pull/30 2264 o - MID SDES item security procedures updated 2266 o https://github.com/cdh4u/draft-sdp-bundle/pull/29 2268 o - Appendix B of JSEP moved into BUNDLE. 2270 o - Associating RTP/RTCP packets with SDP m- lines. 2272 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35 2274 o Editorial changes on RTP streaming mapping section based on 2275 comments from Colin Perkins. 2277 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34 2279 o RTP streams, instead of RTP packets, are associated with m- lines. 2281 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 2283 o Editorial changes based on comments from Eric Rescorla and Cullen 2284 Jennings: 2286 o - Changes regarding usage of RTP/RTCP multiplexing attributes. 2288 o - Additional text regarding associating RTP/RTCP packets with SDP 2289 m- lines. 2291 o - Reference correction. 2293 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32 2295 o Editorial changes based on comments from Eric Rescorla and Cullen 2296 Jennings: 2298 o - Justification for mechanism added to Introduction. 2300 o - Clarify that the order of m- lines in the group:BUNDLE attribute 2301 does not have to be the same as the order in which the m- lines 2302 are listed in the SDP. 2304 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31 2306 o Editorial changes based on GitHub Pull requests by Martin Thomson: 2308 o - https://github.com/cdh4u/draft-sdp-bundle/pull/2 2310 o - https://github.com/cdh4u/draft-sdp-bundle/pull/1 2312 o Editorial change based on comment from Diederick Huijbers (9th 2313 July 2016). 2315 o Changes based on comments from Flemming Andreasen (21st June 2316 2016): 2318 o - Mux category for SDP bundle-only attribute added. 2320 o - Mux category considerations editorial clarification. 2322 o - Editorial changes. 2324 o RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext. 2326 o Note whether Design Considerations appendix is to be kept removed: 2328 o - Appendix is kept within document. 2330 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30 2332 o Indicating in the Abstract and Introduction that the document 2333 updates RFC 3264. 2335 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29 2337 o Change based on WGLC comment from Colin Perkins. 2339 o - Clarify that SSRC can be reused by another source after a delay 2340 of 5 RTCP reporting intervals. 2342 o Change based on WGLC comment from Alissa Cooper. 2344 o - IANA registry name fix. 2346 o - Additional IANA registration information added. 2348 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28 2350 o - Alignment with exclusive mux procedures. 2352 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 2354 o - Yet another terminology change. 2356 o - Mux category considerations added. 2358 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 2360 o - ICE considerations modified: ICE-related SDP attributes only 2361 added to the bundled m- line representing the selected BUNDLE 2362 address. 2364 o - Reference to draft-ietf-mmusic-ice-sip-sdp added. 2366 o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- 2367 rfc5245bis. 2369 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 2371 o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux 2372 considerations. 2374 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 2376 o - Reference and procedures associated with exclusive RTP/RTCP mux 2377 added 2379 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 2381 o - RTCP-MUX mandatory for bundled RTP m- lines 2383 o - Editorial fixes based on comments from Flemming Andreasen 2385 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 2387 o - Correction of Ari's family name 2389 o - Editorial fixes based on comments from Thomas Stach 2391 o - RTP/RTCP correction based on comment from Magnus Westerlund 2392 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2393 msg14861.html 2395 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 2397 o - Correct based on comment from Paul Kyzivat 2399 o -- 'received packets' replaced with 'received data' 2401 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 2403 o - Clarification based on comment from James Guballa 2405 o - Clarification based on comment from Flemming Andreasen 2407 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 2409 o - DTLS Considerations section added. 2411 o - BUNDLE semantics added to the IANA Considerations 2413 o - Changes based on WGLC comments from Adam Roach 2415 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2416 msg14673.html 2418 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 2420 o - Changes based on agreements at IETF#92 2422 o -- BAS Offer removed, based on agreement at IETF#92. 2424 o -- Procedures regarding usage of SDP "b=" line is replaced with a 2425 reference to to draft-ietf-mmusic-sdp-mux-attributes. 2427 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 2429 o - Editorial changes based on comments from Magnus Westerlund. 2431 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 2433 o - Modification of RTP/RTCP multiplexing section, based on comments 2434 from Magnus Westerlund. 2436 o - Reference updates. 2438 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 2439 o - Editorial fix. 2441 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 2443 o - Editorial changes. 2445 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 2447 o Changes to allow a new suggested offerer BUNDLE address to be 2448 assigned to each bundled m- line. 2450 o Changes based on WGLC comments from Paul Kyzivat 2452 o - Editorial fixes 2454 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 2456 o Usage of SDP 'extmap' attribute added 2458 o SDP 'bundle-only' attribute scoped with "m=" lines with a zero 2459 port value 2461 o Changes based on WGLC comments from Thomas Stach 2463 o - ICE candidates not assigned to bundle-only m- lines with a zero 2464 port value 2466 o - Editorial changes 2468 o Changes based on WGLC comments from Colin Perkins 2470 o - Editorial changes: 2472 o -- "RTP SDES item" -> "RTCP SDES item" 2474 o -- "RTP MID SDES item" -> "RTCP MID SDES item" 2476 o - Changes in section 10.1.1: 2478 o -- "SHOULD NOT" -> "MUST NOT" 2480 o -- Additional text added to the Note 2482 o - Change to section 13.2: 2484 o -- Clarify that mid value is not zero terminated 2486 o - Change to section 13.3: 2488 o -- Clarify that mid value is not zero terminated 2490 o -- Clarify padding 2492 o Changes based on WGLC comments from Paul Kyzivat 2494 o - Editorial changes: 2496 o Changes based on WGLC comments from Jonathan Lennox 2498 o - Editorial changes: 2500 o - Defintion of SDP bundle-only attribute alligned with structure 2501 in 4566bis draft 2503 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 2505 o Editorial corrections based on comments from Harald Alvestrand. 2507 o Editorial corrections based on comments from Cullen Jennings. 2509 o Reference update (RFC 7160). 2511 o Clarification about RTCP packet sending when RTP/RTCP multiplexing 2512 is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ 2513 msg13765.html). 2515 o Additional text added to the Security Considerations. 2517 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 2519 o SDP bundle-only attribute added to IANA Considerations. 2521 o SDES item and RTP header extension added to Abstract and 2522 Introduction. 2524 o Modification to text updating section 8.2 of RFC 3264. 2526 o Reference corrections. 2528 o Editorial corrections. 2530 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 2532 o Terminology change: "bundle-only attribute assigned to m= line" to 2533 "bundle-only attribute associated with m= line". 2535 o Editorial corrections. 2537 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 2539 o Editorial corrections. 2541 o - "of"->"if" (8.3.2.5). 2543 o - "optional"->"OPTIONAL" (9.1). 2545 o - Syntax/ABNF for 'bundle-only' attribute added. 2547 o - SDP Offer/Answer sections merged. 2549 o - 'Request new offerer BUNDLE address' section added 2551 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 2553 o OPEN ISSUE regarding Receiver-ID closed. 2555 o - RTP MID SDES Item. 2557 o - RTP MID Header Extension. 2559 o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers 2560 closed. 2562 o - Indicating that, when rtcp-mux is used, the answerer MUST NOT 2563 include an 'rtcp' attribute in the answer, based on the procedures 2564 in section 5.1.3 of RFC 5761. 2566 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 2568 o Draft title changed. 2570 o Added "SDP" to section names containing "Offer" or "Answer". 2572 o Editorial fixes based on comments from Paul Kyzivat 2573 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2574 msg13314.html). 2576 o Editorial fixed based on comments from Colin Perkins 2577 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2578 msg13318.html). 2580 o - Removed text about extending BUNDLE to allow multiple RTP 2581 sessions within a BUNDLE group. 2583 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 2584 o Major re-structure of SDP Offer/Answer sections, to align with RFC 2585 3264 structure. 2587 o Additional definitions added. 2589 o - Shared address. 2591 o - Bundled "m=" line. 2593 o - Bundle-only "m=" line. 2595 o - Offerer suggested BUNDLE mid. 2597 o - Answerer selected BUNDLE mid. 2599 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 2600 to multiple "m=" lines until it has received an SDP Answer 2601 indicating support of the BUNDLE extension. 2603 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 2604 Answerer supports the BUNDLE extension, assign a zero port value 2605 to a 'bundle-only' "m=" line. 2607 o SDP 'bundle-only' attribute section added. 2609 o Connection data nettype/addrtype restrictions added. 2611 o RFC 3264 update section added. 2613 o Indicating that a specific payload type value can be used in 2614 multiple "m=" lines, if the value represents the same codec 2615 configuration in each "m=" line. 2617 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 2619 o Updated Offerer procedures (http://www.ietf.org/mail- 2620 archive/web/mmusic/current/msg12293.html). 2622 o Updated Answerer procedures (http://www.ietf.org/mail- 2623 archive/web/mmusic/current/msg12333.html). 2625 o Usage of SDP 'bundle-only' attribute added. 2627 o Reference to Trickle ICE document added. 2629 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 2630 o Mechanism modified, to be based on usage of SDP Offers with both 2631 different and identical port number values, depending on whether 2632 it is known if the remote endpoint supports the extension. 2634 o Cullen Jennings added as co-author. 2636 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 2638 o No changes. New version due to expiration. 2640 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 2642 o No changes. New version due to expiration. 2644 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 2646 o Draft name changed. 2648 o Harald Alvestrand added as co-author. 2650 o "Multiplex" terminology changed to "bundle". 2652 o Added text about single versus multiple RTP Sessions. 2654 o Added reference to RFC 3550. 2656 21. References 2658 21.1. Normative References 2660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2661 Requirement Levels", BCP 14, RFC 2119, 2662 DOI 10.17487/RFC2119, March 1997, . 2665 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2666 with Session Description Protocol (SDP)", RFC 3264, 2667 DOI 10.17487/RFC3264, June 2002, . 2670 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2671 Jacobson, "RTP: A Transport Protocol for Real-Time 2672 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2673 July 2003, . 2675 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2676 in Session Description Protocol (SDP)", RFC 3605, 2677 DOI 10.17487/RFC3605, October 2003, . 2680 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2681 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2682 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2683 . 2685 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2686 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2687 July 2006, . 2689 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2690 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2691 . 2693 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2694 Control Packets on a Single Port", RFC 5761, 2695 DOI 10.17487/RFC5761, April 2010, . 2698 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2699 Security (DTLS) Extension to Establish Keys for the Secure 2700 Real-time Transport Protocol (SRTP)", RFC 5764, 2701 DOI 10.17487/RFC5764, May 2010, . 2704 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2705 Protocol (SDP) Grouping Framework", RFC 5888, 2706 DOI 10.17487/RFC5888, June 2010, . 2709 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2710 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2711 January 2012, . 2713 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2714 Header Extension for the RTP Control Protocol (RTCP) 2715 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2716 August 2016, . 2718 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 2719 Mechanism for RTP Header Extensions", RFC 8285, 2720 DOI 10.17487/RFC8285, October 2017, . 2723 [I-D.ietf-ice-rfc5245bis] 2724 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2725 Connectivity Establishment (ICE): A Protocol for Network 2726 Address Translator (NAT) Traversal", draft-ietf-ice- 2727 rfc5245bis-15 (work in progress), November 2017. 2729 [I-D.ietf-mmusic-sdp-mux-attributes] 2730 Nandakumar, S., "A Framework for SDP Attributes when 2731 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 2732 (work in progress), December 2016. 2734 [I-D.ietf-mmusic-mux-exclusive] 2735 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 2736 Multiplexing using SDP", draft-ietf-mmusic-mux- 2737 exclusive-12 (work in progress), May 2017. 2739 [I-D.ietf-mmusic-ice-sip-sdp] 2740 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, 2741 "Session Description Protocol (SDP) Offer/Answer 2742 procedures for Interactive Connectivity Establishment 2743 (ICE)", draft-ietf-mmusic-ice-sip-sdp-16 (work in 2744 progress), November 2017. 2746 21.2. Informative References 2748 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2749 A., Peterson, J., Sparks, R., Handley, M., and E. 2750 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2751 DOI 10.17487/RFC3261, June 2002, . 2754 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2755 "RTP Control Protocol Extended Reports (RTCP XR)", 2756 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2757 . 2759 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2760 "Codec Control Messages in the RTP Audio-Visual Profile 2761 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 2762 February 2008, . 2764 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2765 "Extended RTP Profile for Real-time Transport Control 2766 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2767 DOI 10.17487/RFC4585, July 2006, . 2770 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2771 Media Attributes in the Session Description Protocol 2772 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2773 . 2775 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2776 Clock Rates in an RTP Session", RFC 7160, 2777 DOI 10.17487/RFC7160, April 2014, . 2780 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2781 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2782 . 2784 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2785 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2786 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2787 DOI 10.17487/RFC7656, November 2015, . 2790 [I-D.ietf-ice-trickle] 2791 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 2792 "Trickle ICE: Incremental Provisioning of Candidates for 2793 the Interactive Connectivity Establishment (ICE) 2794 Protocol", draft-ietf-ice-trickle-15 (work in progress), 2795 November 2017. 2797 [I-D.ietf-avtext-lrr] 2798 Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 2799 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 2800 Message", draft-ietf-avtext-lrr-07 (work in progress), 2801 July 2017. 2803 Appendix A. Design Considerations 2805 One of the main issues regarding the BUNDLE grouping extensions has 2806 been whether, in SDP Offers and SDP Answers, the same port value 2807 should be inserted in "m=" lines associated with a BUNDLE group, as 2808 the purpose of the extension is to negotiate the usage of a single 2809 transport for media specified by the "m=" sections. Issues with both 2810 approaches, discussed in the Appendix have been raised. The outcome 2811 was to specify a mechanism which uses SDP Offers with both different 2812 and identical port values. 2814 Below are the primary issues that have been considered when defining 2815 the "BUNDLE" grouping extension: 2817 o 1) Interoperability with existing UAs. 2819 o 2) Interoperability with intermediary B2BUA- and proxy entities. 2821 o 3) Time to gather, and the number of, ICE candidates. 2823 o 4) Different error scenarios, and when they occur. 2825 o 5) SDP Offer/Answer impacts, including usage of port number value 2826 zero. 2828 A.1. UA Interoperability 2830 Consider the following SDP Offer/Answer exchange, where Alice sends 2831 an SDP Offer to Bob: 2833 SDP Offer 2835 v=0 2836 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2837 s= 2838 c=IN IP4 atlanta.example.com 2839 t=0 0 2840 m=audio 10000 RTP/AVP 97 2841 a=rtpmap:97 iLBC/8000 2842 m=video 10002 RTP/AVP 97 2843 a=rtpmap:97 H261/90000 2845 SDP Answer 2847 v=0 2848 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2849 s= 2850 c=IN IP4 biloxi.example.com 2851 t=0 0 2852 m=audio 20000 RTP/AVP 97 2853 a=rtpmap:97 iLBC/8000 2854 m=video 20002 RTP/AVP 97 2855 a=rtpmap:97 H261/90000 2857 RFC 4961 specifies a way of doing symmetric RTP but that is an a 2858 later invention to RTP and Bob can not assume that Alice supports RFC 2859 4961. This means that Alice may be sending RTP from a different port 2860 than 10000 or 10002 - some implementation simply send the RTP from an 2861 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2862 way that Bob knows if it should be passed to the video or audio codec 2863 is by looking at the port it was received on. This lead some SDP 2864 implementations to use the fact that each "m=" section had a 2865 different port number to use that port number as an index to find the 2866 correct m line in the SDP. As a result, some implementations that do 2867 support symmetric RTP and ICE still use a SDP data structure where 2868 SDP with "m=" sections with the same port such as: 2870 SDP Offer 2872 v=0 2873 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2874 s= 2875 c=IN IP4 atlanta.example.com 2876 t=0 0 2877 m=audio 10000 RTP/AVP 97 2878 a=rtpmap:97 iLBC/8000 2879 m=video 10000 RTP/AVP 98 2880 a=rtpmap:98 H261/90000 2882 will result in the second "m=" section being considered an SDP error 2883 because it has the same port as the first line. 2885 A.2. Usage of port number value zero 2887 In an SDP Offer or SDP Answer, the media specified by an "m=" section 2888 can be disabled/rejected by setting the port number value to zero. 2889 This is different from e.g., using the SDP direction attributes, 2890 where RTCP traffic will continue even if the SDP "inactive" attribute 2891 is indicated for the associated "m=" section. 2893 If each "m=" section associated with a BUNDLE group would contain 2894 different port values, and one of those port values would be used for 2895 a BUNDLE address associated with the BUNDLE group, problems would 2896 occur if an endpoint wants to disable/reject the "m=" sectcion 2897 associated with that port, by setting the port value to zero. After 2898 that, no "m=" section would contain the port value which is used for 2899 the BUNDLE address. In addition, it is unclear what would happen to 2900 the ICE candidates associated with the "m=" section, as they are also 2901 used for the BUNDLE address. 2903 A.3. B2BUA And Proxy Interoperability 2905 Some back to back user agents may be configured in a mode where if 2906 the incoming call leg contains an SDP attribute the B2BUA does not 2907 understand, the B2BUA still generates that SDP attribute in the Offer 2908 for the outgoing call leg. Consider a B2BUA that did not understand 2909 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 2910 Further assume that the B2BUA was configured to tear down any call 2911 where it did not see any RTCP for 5 minutes. In this case, if the 2912 B2BUA received an Offer like: 2914 SDP Offer 2916 v=0 2917 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2918 s= 2919 c=IN IP4 atlanta.example.com 2920 t=0 0 2921 m=audio 49170 RTP/AVP 0 2922 a=rtcp:53020 2924 It would be looking for RTCP on port 49172 but would not see any 2925 because the RTCP would be on port 53020 and after five minutes, it 2926 would tear down the call. Similarly, a B2BUA that did not understand 2927 BUNDLE yet put BUNDLE in it's offer may be looking for media on the 2928 wrong port and tear down the call. It is worth noting that a B2BUA 2929 that generated an Offer with capabilities it does not understand is 2930 not compliant with the specifications. 2932 A.3.1. Traffic Policing 2934 Sometimes intermediaries do not act as B2BUA, in the sense that they 2935 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2936 however, they may use SDP information (e.g., IP address and port) in 2937 order to control traffic gating functions, and to set traffic 2938 policing rules. There might be rules which will trigger a session to 2939 be terminated in case media is not sent or received on the ports 2940 retrieved from the SDP. This typically occurs once the session is 2941 already established and ongoing. 2943 A.3.2. Bandwidth Allocation 2945 Sometimes intermediaries do not act as B2BUA, in the sense that they 2946 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2947 however, they may use SDP information (e.g., codecs and media types) 2948 in order to control bandwidth allocation functions. The bandwidth 2949 allocation is done per "m=" section, which means that it might not be 2950 enough if media specified by all "m=" sections try to use that 2951 bandwidth. That may either simply lead to bad user experience, or to 2952 termination of the call. 2954 A.4. Candidate Gathering 2956 When using ICE, a candidate needs to be gathered for each port. This 2957 takes approximately 20 ms extra for each extra "m=" section due to 2958 the NAT pacing requirements. All of this gather can be overlapped 2959 with other things while for exampe a web-page is loading to minimize 2960 the impact. If the client only wants to generate TURN or STUN ICE 2961 candidates for one of the "m=" lines and then use trickle ICE 2962 [I-D.ietf-ice-trickle] to get the non host ICE candidates for the 2963 rest of the "m=" sections, it MAY do that and will not need any 2964 additional gathering time. 2966 Some people have suggested a TURN extension to get a bunch of TURN 2967 allocations at once. This would only provide a single STUN result so 2968 in cases where the other end did not support BUNDLE, may cause more 2969 use of the TURN server but would be quick in the cases where both 2970 sides supported BUNDLE and would fall back to a successful call in 2971 the other cases. 2973 Authors' Addresses 2975 Christer Holmberg 2976 Ericsson 2977 Hirsalantie 11 2978 Jorvas 02420 2979 Finland 2981 Email: christer.holmberg@ericsson.com 2983 Harald Tveit Alvestrand 2984 Google 2985 Kungsbron 2 2986 Stockholm 11122 2987 Sweden 2989 Email: harald@alvestrand.no 2990 Cullen Jennings 2991 Cisco 2992 400 3rd Avenue SW, Suite 350 2993 Calgary, AB T2P 4H2 2994 Canada 2996 Email: fluffy@iii.ca