idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-41.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3264, updated by this document, for RFC5378 checks: 2002-01-31) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 27, 2017) is 2335 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 1537 == Missing Reference: 'RFCXXXX' is mentioned on line 1721, 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: May 31, 2018 C. Jennings 7 Cisco 8 November 27, 2017 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-41.txt 14 Abstract 16 This specification defines a new Session Description Protocol (SDP) 17 Grouping Framework extension, 'BUNDLE'. The extension can be used 18 with the SDP Offer/Answer mechanism to negotiate the usage of a 19 single transport (5-tuple) for sending and receiving media described 20 by multiple SDP media descriptions ("m=" sections). Such transport 21 is referred to as a BUNDLE transport, and the media is referred to as 22 bundled media. The "m=" sections that use the BUNDLE transport form 23 a BUNDLE group. 25 To assist endpoints in negotiating the use of bundle this 26 specification defines a new SDP attribute, 'bundle-only', which can 27 be used to request that specific media is only used if bundled. The 28 specification also updates RFC 3264, to allow assigning a zero port 29 value to a "m= section without meaning that the media described by 30 the "m=" section is disabled or rejected. 32 When RTP-based media is used, there are multiple ways to correlate 33 bundled RTP packets with the appropriate "m=" section. This 34 specification defines a new Real-time Transport Protocol (RTP) source 35 description (SDES) item and a new RTP header extension that provides 36 an additional way to do this correlation by using them to carry a 37 value that associates the RTP/RTCP packets with a specific "m=" 38 section. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on May 31, 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 . . . . . . . . . . 16 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 . . . . 17 110 8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 18 111 8.5.4. Disabling A Media Description In A BUNDLE Group . . . 19 112 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 19 113 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19 114 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 20 115 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 20 116 10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 21 117 10.2. Associating RTP/RTCP Streams With Correct SDP Media 118 Description . . . . . . . . . . . . . . . . . . . . . . 21 119 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 27 120 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 27 121 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 29 122 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 30 123 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 8.2 (2nd paragraph) of RFC 3264 33 130 14.4. New text replacing section 8.2 (2nd paragraph) of RFC 131 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 132 14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 33 133 14.6. New text replacing section 8.4 (6th paragraph) of RFC 134 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 135 15. RTP/RTCP extensions for identification-tag transport . . . . 34 136 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 35 137 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 35 138 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 139 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 36 140 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 36 141 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 37 142 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 37 143 17. Security Considerations . . . . . . . . . . . . . . . . . . . 37 144 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39 145 18.1. Example: Bundle Address Selection . . . . . . . . . . . 39 146 18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 41 147 18.3. Example: Offerer Adds A Media Description To A BUNDLE 148 Group . . . . . . . . . . . . . . . . . . . . . . . . . 42 149 18.4. Example: Offerer Moves A Media Description Out Of A 150 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 44 151 18.5. Example: Offerer Disables A Media Description Within A 152 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46 153 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 154 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 48 155 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 156 21.1. Normative References . . . . . . . . . . . . . . . . . . 58 157 21.2. Informative References . . . . . . . . . . . . . . . . . 60 158 Appendix A. Design Considerations . . . . . . . . . . . . . . . 61 159 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 61 160 A.2. Usage of port number value zero . . . . . . . . . . . . . 63 161 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 63 162 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 64 163 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 64 164 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 64 165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 167 1. Introduction 169 When multimedia communications are established, each transport 170 (5-tuple) reserved for an individual media stream consume additional 171 resources (especially when Interactive Connectivity Establishment 172 (ICE) [I-D.ietf-ice-rfc5245bis] is used). For this reason, it is 173 attractive to use a single transport for multiple media streams. 175 This specification defines a way to use a single transport (BUNDLE 176 transport) for sending and receiving media (bundled media) described 177 by multiple SDP media descriptions ("m=" sections). The same BUNDLE 178 transport is used for sending and receiving bundled media, which 179 means that the symmetric RTP mechanism [RFC4961] is always used for 180 RTP-based bundled media. 182 This specification defines a new SDP Grouping Framework [RFC5888] 183 extension called 'BUNDLE'. The extension can be used with the 184 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 185 to negotiate which "m=" sections will become part of a BUNDLE group. 186 Within a BUNDLE group, each "m=" section will use a BUNDLE transport 187 for sending and receiving bundled media. 189 Within a BUNDLE group, each endpoint uses a single address:port 190 combination for sending and receiving bundled media. The 191 address:port combination is referred to as BUNDLE address. In 192 addition to negotiating the BUNDLE group, the offerer and answerer 193 [RFC3264] use the BUNDLE extension to negotiate the BUNDLE addresses, 194 one for the offerer (offerer BUNDLE address) and one for the answerer 195 (answerer BUNDLE address). Once the offerer and the answerer have 196 negotiated the BUNDLE addresses, and a BUNDLE group has been formed, 197 they assign their respective BUNDLE address to each "m=" section 198 within the BUNDLE group. The endpoints then use the BUNDLE addresses 199 for sending and receiving the bundled media associated with the 200 BUNDLE group. 202 The use of a BUNDLE transport also allows the usage of a single set 203 of Interactive Connectivity Establishment (ICE) 204 [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group. 206 This specification also defines a new SDP attribute, 'bundle-only', 207 which can be used to request that specific media is only used if the 208 "m=" section describing the media is kept within a BUNDLE group. The 209 specification also updates RFC 3264, to allow usage of zero port 210 values without meaning that media is rejected. 212 As defined in RFC 4566 [RFC4566], the semantics of assigning the same 213 transport address (IP address and port) to multiple "m=" sections are 214 undefined, and there is no grouping defined by such means. Instead, 215 an explicit grouping mechanism needs to be used to express the 216 intended semantics. This specification provides such an extension. 218 This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 219 [RFC3264]. The update allows an answerer to assign a non-zero port 220 value to an "m=" section in an SDP answer, even if the "m=" section 221 in the associated SDP offer contained a zero port value. 223 This specification also defines a new Real-time Transport Protocol 224 (RTP) [RFC3550] source description (SDES) item, 'MID', and a new RTP 225 SDES header extension that can be used to associate RTP streams with 226 "m=" sections. 228 SDP bodies can contain multiple BUNDLE groups. A given BUNDLE 229 address MUST only be associated with a single BUNDLE group. The 230 procedures in this specification apply independently to a given 231 BUNDLE group. All RTP based media flows described by a single BUNDLE 232 group belong to a single RTP session [RFC3550]. 234 The BUNDLE extension is backward compatible. Endpoints that do not 235 support the extension are expected to generate offers and answers 236 without an SDP 'group:BUNDLE' attribute, and are expected to assign a 237 unique address to each "m=" section within an offer and answer, 238 according to the procedures in [RFC4566] and [RFC3264] 240 2. Terminology 242 "m=" section: SDP bodies contain one or more media descriptions, 243 referred to as "m=" sections. Each "m=" section is represented by an 244 SDP "m=" line, and zero or more SDP attributes associated with the 245 "m=" line. An local address:port combination is assigned to each 246 "m=" section. 248 5-tuple: A collection of the following values: source address, source 249 port, destination address, destination port, and transport-layer 250 protocol. 252 Unique address: An address:port combination that is assigned to only 253 one "m=" section in an offer or answer. 255 Offerer BUNDLE-tag: The first identification-tag in a given SDP 256 'group:BUNDLE' attribute identification-tag list in an offer. 258 Answerer BUNDLE-tag: The first identification-tag in a given SDP 259 'group:BUNDLE' attribute identification-tag list in an answer. 261 BUNDLE address: An address:port combination that an endpoint uses for 262 sending and receiving bundled media. 264 Offerer BUNDLE address: In an offer, the BUNDLE address of the 265 offerer. 267 Answerer BUNDLE address: In an answer, the BUNDLE address of the 268 answerer. 270 BUNDLE transport: The transport (5-tuple) used by all media described 271 by the "m=" sections within a BUNDLE group. 273 BUNDLE group: A set of "m=" sections, created using an SDP Offer/ 274 Answer exchange, which uses a single BUNDLE transport for sending and 275 receiving all media (bundled media) described by the set of "m=" 276 sections. The same BUNDLE transport is used for sending and 277 receiving bundled media. 279 Bundled "m=" section: An "m=" section, whose identification-tag is 280 placed in an SDP 'group:BUNDLE' attribute identification-tag list in 281 an offer or answer. 283 Bundle-only "m=" section: A bundled "m=" section that contains an SDP 284 'bundle-only' attribute. 286 Bundled media: All media associated with a given BUNDLE group. 288 Initial offer: The first offer, within an SDP session (e.g. a SIP 289 dialog when the Session Initiation Protocol (SIP) [RFC3261] is used 290 to carry SDP), in which the offerer indicates that it wants to create 291 a given BUNDLE group. 293 Subsequent offer: An offer which contains a BUNDLE group that has 294 been created as part of a previous offer/answer exchange. 296 Identification-tag: A unique token value that is used to identify an 297 "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" section 298 carries the unique identification-tag assigned to that "m=" section. 299 The session-level SDP 'group' attribute [RFC5888] carries a list of 300 identification-tags, identifying the "m=" sections associated with 301 that particular 'group' attribute. 303 3. Conventions 305 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 306 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 307 document are to be interpreted as described in BCP 14, RFC 2119 308 [RFC2119]. 310 4. Applicability Statement 312 The mechanism in this specification only applies to the Session 313 Description Protocol (SDP) [RFC4566], when used together with the SDP 314 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 315 scope of this document, and is thus undefined. 317 5. SDP Grouping Framework BUNDLE Extension 319 This section defines a new SDP Grouping Framework [RFC5888] 320 extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP 321 Offer/Answer mechanism to negotiate a set of "m=" sections that will 322 become part of a BUNDLE group. Within a BUNDLE group, each "m=" 323 section will use a BUNDLE transport for sending and receiving bundled 324 media. Each endpoint use a single address:port combination for 325 sending receiving the bundled media. 327 The BUNDLE extension is indicated using an SDP 'group' attribute with 328 a "BUNDLE" semantics value [RFC5888]. An identification-tag is 329 assigned to each bundled "m=" section, and each identification-tag is 330 listed in the SDP 'group:BUNDLE' attribute identification-tag list. 331 Each "m=" section whose identification-tag is listed in the 332 identification-tag list is associated with a given BUNDLE group. 334 SDP bodies can contain multiple BUNDLE groups. Any given bundled 335 "m=" section MUST NOT be associated with more than one BUNDLE group 336 at any given time. 338 NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' 339 attribute identification-tag list does not have to be the same as the 340 order in which the "m=" sections occur in the SDP. 342 Section 8 defines the detailed SDP Offer/Answer procedures for the 343 BUNDLE extension. 345 6. SDP 'bundle-only' Attribute 347 This section defines a new SDP media-level attribute [RFC4566], 348 'bundle-only'. 'bundle-only' is a property attribute [RFC4566], and 349 hence has no value. 351 Name: bundle-only 353 Value: N/A 355 Usage Level: media 357 Charset Dependent: no 359 Example: 361 a=bundle-only 363 In order to ensure that an answerer that does not support the BUNDLE 364 extension always rejects a bundled "m=" section, the offerer can 365 assign a zero port value to the "m=" section. According to [RFC3264] 366 an answerer will reject such "m=" section. By including an SDP 367 'bundle-only' attribute in such "m=" section, the offerer can request 368 that the answerer accepts the "m=" section if the answerer supports 369 the Bundle extension, and if the answerer keeps the "m=" section 370 within the associated BUNDLE group. 372 Once the offerer and answerer BUNDLE addresses have been selected, an 373 offerer and answerer only assigns the BUNDLE address to one bundled 374 "m=" section. To every other bundled "m=" section the offerer and 375 answerer assigns a zero port value and includes an SDP 'bundle-only' 376 attribute. 378 The usage of the 'bundle-only' attribute is only defined for a 379 bundled "m=" section with a zero port value, within an offer or 380 answer. Other usage is unspecified. 382 Section 8 defines the detailed SDP Offer/Answer procedures for the 383 'bundle-only' attribute. 385 7. SDP Information Considerations 387 This section describes restrictions associated with the usage of SDP 388 parameters within a BUNDLE group. It also describes, when parameter 389 and attribute values have been assigned to each bundled "m=" section, 390 how to calculate a value for the whole BUNDLE group. 392 7.1. Connection Data (c=) 394 The "c=" line nettype value [RFC4566] associated with a bundled "m=" 395 section MUST be 'IN'. 397 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" 398 section MUST be 'IP4' or 'IP6'. The same value MUST be associated 399 with each "m=" section. 401 NOTE: Extensions to this specification can specify usage of the 402 BUNDLE mechanism for other nettype and addrtype values than the ones 403 listed above. 405 7.2. Bandwidth (b=) 407 An offerer and answerer MUST use the rules and restrictions defined 408 in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP 409 bandwidth (b=) line with bundled "m=" section. 411 8. SDP Offer/Answer Procedures 413 This section describes the SDP Offer/Answer [RFC3264] procedures for: 415 o Negotiating a BUNDLE group; and 417 o Selecting the BUNDLE addresses (offerer BUNDLE address and 418 answerer BUNDLE address); and 420 o Adding an "m=" section to a BUNDLE group; and 422 o Moving an "m=" section out of a BUNDLE group; and 424 o Disabling an "m=" section within a BUNDLE group. 426 The generic rules and procedures defined in [RFC3264] and [RFC5888] 427 also apply to the BUNDLE extension. For example, if an offer is 428 rejected by the answerer, the previously negotiated SDP parameters 429 and characteristics (including those associated with a BUNDLE group) 430 apply. Hence, if an offerer generates an offer in which the offerer 431 wants to create a BUNDLE group, and the answerer rejects the offer, 432 the BUNDLE group is not created. 434 The procedures in this section are independent of the media type or 435 "m=" line proto value assigned to a bundled "m=" section. Section 10 436 defines additional considerations for RTP based media. Section 6 437 defines additional considerations for the usage of the SDP 'bundle- 438 only' attribute. Section 11 defines additional considerations for 439 the usage of Interactive Connectivity Establishment (ICE) 440 [I-D.ietf-ice-rfc5245bis] mechanism. 442 SDP offers and answers can contain multiple BUNDLE groups. The 443 procedures in this section apply independently to a given BUNDLE 444 group. 446 8.1. Mux Category Considerations 448 When a BUNDLE group is initially negotiated, and a unique address is 449 assigned to each bundled "m=" section (excluding any bundle-only "m=" 450 section) in the initial offer Section 8.2, IDENTICAL and TRANSPORT 451 mux category SDP attributes MUST explicitly included in each bundled 452 "m=" section (excluding any bundle-only "m=" secctions). 454 When an offerer or answerer includes SDP attributes in bundled "m=" 455 sections within a BUNDLE group for which the offerer and answerer 456 BUNDLE addresses have been selected, IDENTICAL and TRANSPORT mux 457 category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are only 458 included in the "m=" section represented by the BUNDLE-tag in the 459 offer or answer. The SDP attribute values are implicitly applied to 460 each bundled "m=" section (including any bundle-only "m=" section). 461 The offerer and answerer MUST NOT include such SDP attributes in any 462 other bundled "m=" section. 464 The semantics of some SDP attributes only apply to specific types of 465 media. For example, the semantics of the SDP 'rtcp-mux' and SDP 466 'rtcp-mux-only' attributes only apply to "m=" sections describing 467 RTP-based media. However, as described in Section 8.1, there are 468 cases where IDENTICAL and TRANSPORT mux category SDP attributes are 469 only included in the "m=" sections represented by the BUNDLE-tag. 470 That means that media-specific IDENTICAL and TRANSPORT mux category 471 attributes can be included in an "m=" section associated with another 472 type of media. 474 8.2. Generating the Initial SDP Offer 476 When an offerer generates an initial offer, in order to negotiate a 477 BUNDLE group, it MUST: 479 o Assign a unique address to each "m=" section within the offer, 480 following the procedures in [RFC3264], excluding any bundle-only 481 "m=" sections (see below); and 483 o Include an SDP 'group:BUNDLE' attribute in the offer; and 485 o Place the identification-tag of each bundled "m=" section in the 486 SDP 'group:BUNDLE' attribute identification-tag list; and 488 o Indicate which unique address the offerer suggests as the offerer 489 BUNDLE address [Section 8.2.1]. 491 If the offerer wants to request that the answerer accepts a given 492 bundled "m=" section only if the answerer keeps the "m=" section 493 within the BUNDLE group, the offerer MUST: 495 o Include an SDP 'bundle-only' attribute [Section 8.2.1] in the "m=" 496 secction; and 498 o Assign a zero port value to the "m=" section. 500 NOTE: If the offerer assigns a zero port value to an "m=" section, 501 but does not include an SDP 'bundle-only' attribute in the "m=" 502 section, it is an indication that the offerer wants to disable the 503 "m=" section [Section 8.5.4]. 505 [Section 18.1] shows an example of an initial offer. 507 8.2.1. Suggesting the offerer BUNDLE address 509 In the offer, the address:port combination assigned to the "m=" 510 section represented by the offerer BUNDLE-tag indicates offerer 511 BUNDLE address, i.e., the address:port combination that the offerer 512 suggests for sending and receiving bundled media. 514 The offerer BUNDLE-tag MUST NOT represent a bundle-only "m=" section. 515 Hence, the offer MUST contain at least one bundle "m=" section with a 516 unique address (and a non-zero port value). 518 8.2.2. Example: Initial SDP Offer 520 The example shows an initial SDP offer. The offer includes two "m=" 521 section in the SDP, and suggests that both are included in a BUNDLE 522 group. The audio "m=" section is associated with the offerer BUNDLE- 523 tag (placed first in the SDP group:BUNDLE attribute identification-id 524 list). 526 SDP Offer 528 v=0 529 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 530 s= 531 c=IN IP4 atlanta.example.com 532 t=0 0 533 a=group:BUNDLE foo bar 534 m=audio 10000 RTP/AVP 0 8 97 535 b=AS:200 536 a=mid:foo 537 a=rtcp-mux 538 a=rtpmap:0 PCMU/8000 539 a=rtpmap:8 PCMA/8000 540 a=rtpmap:97 iLBC/8000 541 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 542 m=video 10002 RTP/AVP 31 32 543 b=AS:1000 544 a=mid:bar 545 a=rtpmap:31 H261/90000 546 a=rtpmap:32 MPV/90000 547 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 549 8.3. Generating the SDP Answer 551 When an answerer generates an answer that contains a BUNDLE group, 552 the following general SDP grouping framework restrictions, defined in 553 [RFC5888], also apply to the BUNDLE group: 555 o The answerer MUST NOT include a BUNDLE group in the answer, unless 556 the offerer requested the BUNDLE group to be negotiated in the 557 corresponding offer; and 559 o The answerer MUST NOT include an "m=" section within a BUNDLE 560 group, unless the offerer requested the "m=" section to be within 561 that BUNDLE group in the corresponding offer. 563 o If the answer contains multiple BUNDLE groups, the answerer MUST 564 NOT move an "m=" section from one BUNDLE group to another. 566 If the answer contains a BUNDLE group, the answerer MUST: 568 o Select an offerer BUNDLE Address [Section 8.3.1]; and 570 o Select an answerer BUNDLE Address [Section 8.3.2]; 572 The answerer is allowed to select a new answerer BUNDLE address each 573 time it generates an answer to an offer. 575 If the answerer does not want to keep an "m=" section within a BUNDLE 576 group, it MUST: 578 o Move the "m=" section out of the BUNDLE group [Section 8.3.3]; or 580 o Reject the "m=" section [Section 8.3.4]; 582 When the answerer creates the answer, it selects the offerer BUNDLE 583 address [Section 8.3.1] and the answerer BUNDLE address 584 [Section 8.3.2]. The answerer then assigns the answerer BUNDLE 585 address to the bundled "m=" section represented by the answerer 586 BUNDLE-tag. In every other bundled "m=" section the answerer 587 includes an SDP 'bundle-only' attribute and assigns a zero port value 588 to the "m=" section. 590 If the answerer does not want to keep a bundle-only "m=" section 591 within the BUNDLE group, it MUST reject the "m=" section 592 [Section 8.3.4]. 594 NOTE: If a bundled "m=" section in an offer contains a zero port 595 value, but the "m=" section does not contain an SDP 'bundle-only' 596 attribute, it is an indication that the offerer wants to disable the 597 "m=" section [Section 8.5.4]. 599 8.3.1. Answerer Selection of Offerer Bundle Address 601 In an offer, the bundled "m=" section represented by the offerer 602 BUNDLE-tag contains the suggested offerer BUNDLE address, i.e, the 603 address:port combination that the offerer wants to use for sending 604 and receiving bundled media [Section 8.2.1]. The answerer MUST check 605 whether that "m=" section fulfils the following criteria: 607 o The answerer will not move the "m=" section out of the BUNDLE 608 group [Section 8.3.3]; and 610 o The answerer will not reject the "m=" section [Section 8.3.4]; and 611 o The "m=" section does not contain a zero port value. 613 If all of the criteria above are fulfilled, the answerer MUST select 614 the suggested offerer BUNDLE address as the offerer BUNDLE address. 615 In the answer, the answerer BUNDLE-tag represents the "m=" section. 617 If one or more of the criteria are not fulfilled, the answerer MUST 618 select the next identification-tag in the identification-tag list, 619 and perform the same criteria check for the "m=" section associated 620 with that identification-tag. If there are no more identification- 621 tags in the identification-tag list, the answerer MUST NOT create the 622 BUNDLE group. In addition, unless the answerer rejects the whole 623 offer, the answerer MUST apply the answerer procedures for moving an 624 "m=" section out of a BUNDLE group [Section 8.3.3] to each bundled 625 "m=" section in the offer when creating the answer. 627 [Section 18.1] shows an example of an offerer BUNDLE address 628 selection. 630 8.3.2. Answerer Selection of Answerer BUNDLE Address 632 When the answerer selects a BUNDLE address for itself (answerer 633 BUNDLE address), the answerer MUST assign the answerer BUNDLE address 634 to the "m=" section represented by the answerer BUNDLE-tag (i.e., the 635 "m=" section in the corresponding offer that contains the selected 636 offerer BUNDLE address). To every other bundled "m=" section the 637 answerer MUST assign a zero port value and include an SDP 'bundle- 638 only' attribute. 640 The answerer MUST NOT assign an answerer BUNDLE address to an "m=" 641 section that is not within the BUNDLE group, or to an "m=" section 642 that is within another BUNDLE group. 644 [Section 18.1] shows an example of an answerer BUNDLE address 645 selection. 647 8.3.3. Moving A Media Description Out Of A BUNDLE Group 649 When an answerer wants to move a bundled "m=" section out of a BUNDLE 650 group in an answer, it MUST first check the following criteria: 652 o In the corresponding offer, an offerer BUNDLE address (previously 653 selected [Section 8.3.1] or new suggested [Section 8.5.1]) has 654 been assigned to the "m=" section by the offerer; or 656 o In the corresponding offer, the "m=" section contains an SDP 657 'bundle-only' attribute and a zero port value. 659 If either criteria above is fulfilled, the answerer can not not move 660 the "m=" section out of the BUNDLE group in the answer. The answerer 661 can either reject the whole offer, or keep the "m=" section within 662 the BUNDLE group in the answer and later create an offer where the 663 "m=" section is moved out of the BUNDLE group [Section 8.5.3] 665 When the answerer generates an answer, in which it removes a bundled 666 "m=" section out of a BUNDLE group, the answerer: 668 o MUST assign a unique address to the "m=" section; and 670 o MUST NOT place the identification-tag associated with the "m=" 671 section in the SDP 'group:BUNDLE' attribute identification-tag 672 list associated with the BUNDLE group; and 674 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 675 section. 677 An answerer MUST NOT move an "m=" section from one BUNDLE group to 678 another within an answer. If the answerer wants to move an "m=" 679 section from one BUNDLE group to another it MUST first move the 680 BUNDLE group out of the current BUNDLE group, and then generate an 681 offer where the "m=" section is added to another BUNDLE group 682 [Section 8.5.2]. 684 8.3.4. Rejecting A Media Description In A BUNDLE Group 686 When an answerer wants to reject a bundled "m=" section in an answer, 687 it MUST first check the following criteria: 689 o In the corresponding offer, an offerer BUNDLE address (previously 690 selected [Section 8.3.1] or new suggested [Section 8.5.1]) has 691 been assigned to the "m=" section by the offerer. 693 If either criteria above is fulfilled, the answerer can not not 694 reject the "m=" section in the answer. The answerer can either 695 reject the whole offer, or keep the "m=" section within the BUNDLE 696 group in the answer and later create an offer where the "m=" section 697 is disabled of the BUNDLE group [Section 8.5.4] 699 When an answerer generates an answer, in which it rejects a bundled 700 "m=" section, the answerer: 702 o MUST assign a zero port value to the "m=" section, according to 703 the procedures in [RFC3264]; and 705 o MUST NOT place the identification-tag associated with the "m=" 706 section in the SDP 'group:BUNDLE' attribute identification-tag 707 list associated with the BUNDLE group; and 709 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 710 section. 712 8.3.5. Example: SDP Answer 714 The example shows an SDP answer, based on the SDP offer in 715 [Section 8.2.2]. The answers accepts both "m=" sections within the 716 BUNDLE group. The answerer assigns the answerer BUNDLE address to 717 the "m=" section represented by the answerer BUNDLE-tag. The 718 answerer assigns a zero port value and an SDP 'bundle-only' attribute 719 to the other bundled "m=" section. 721 SDP Answer 723 v=0 724 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 725 s= 726 c=IN IP4 biloxi.example.com 727 t=0 0 728 a=group:BUNDLE foo bar 729 m=audio 20000 RTP/AVP 0 730 b=AS:200 731 a=mid:foo 732 a=rtcp-mux 733 a=rtpmap:0 PCMU/8000 734 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 735 m=video 0 RTP/AVP 32 736 b=AS:1000 737 a=mid:bar 738 a=bundle-only 739 a=rtpmap:32 MPV/90000 740 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 742 8.4. Offerer Processing of the SDP Answer 744 When an offerer receives an answer, if the answer contains a BUNDLE 745 group, the offerer MUST check that any bundled "m=" section in the 746 answer was indicated as bundled in the corresponding offer. If there 747 is no mismatch, the offerer MUST use the offerer BUNDLE address, 748 selected by the answerer [Section 8.3.1], as the address for each 749 bundled "m=" section. 751 NOTE: As the answerer might reject one or more bundled "m=" sections, 752 or move a bundled "m=" section out of a BUNDLE group, each bundled 753 "m=" section in the offer might not be indicated as bundled in the 754 answer. 756 If the answer does not contain a BUNDLE group, the offerer MUST 757 process the answer as a normal answer. 759 8.5. Modifying the Session 761 When an offerer generates a subsequent offer (i.e., a BUNDLE group 762 has previously been negotiated), it MUST assign the previously 763 selected offer BUNDLE address [Section 8.3.1], or a new suggested 764 offerer BUNDLE address [Section 8.5.1], to exactly one "m=" section 765 within the BUNDLE group. 767 The offerer MUST NOT assign an offerer BUNDLE address (previously 768 negotiated or suggested new) to a bundled "m=" section if: 770 o The offerer wants to move the bundled "m=" section out of the 771 BUNDLE group [Section 8.5.3]; or 773 o The offerer wants to disable the bundled "m=" section 774 [Section 8.5.4]. 776 To every other "m=" section within the BUNDLE group, the offerer MUST 777 assign a zero port value and an SDP 'bundle-only' attribute. 779 When the offerer generates a subsequent offer, the offerer BUNDLE-tag 780 MUST represent the bundled "m=" section to which the offerer BUNDLE 781 address (previously negotiated or new suggested) has been assigned. 783 8.5.1. Suggesting a new offerer BUNDLE address 785 When an offerer generates an offer, in which it suggests a new 786 offerer BUNDLE address [Section 8.2.1], the offerer MUST: 788 o Assign the new suggested offerer BUNDLE address to exactly one 789 "m=" section within the BUNDLE group; and 791 o Assign a zero port value and an SDP 'bundle-only' attribute to 792 every other "m=" section within the BUNDLE group. 794 8.5.2. Adding a media description to a BUNDLE group 796 When an offerer generates an offer, in which it wants to add a 797 bundled "m=" section, the offerer MUST: 799 o Assign the offerer BUNDLE address (previously selected 800 [Section 8.3.1] or new suggested [Section 8.5.1]) to the added 801 "m=" section; or 803 o Assign a zero port value and an SDP 'bundle-only' attribute to the 804 added "m=" section (in this case the offerer BUNDLE address is 805 assigned to another "m=" section within the BUNDLE group). 807 In addition, the offerer MUST place the identification-tag associated 808 with the added "m=" section in the SDP 'group:BUNDLE' attribute 809 identification-tag list associated with the BUNDLE group 810 [Section 8.2.1]. 812 NOTE: If the offerer also wants to suggest a new offerer BUNDLE 813 address to the BUNDLE group, the offerer can assign the new suggested 814 offerer BUNDLE address either to the added "m=" section, or to some 815 other "m=" section within the BUNDLE group [Section 8.5.1]. 817 [Section 18.3] shows an example where an offerer sends an offer in 818 order to add a bundled "m=" section to a BUNDLE group. 820 8.5.3. Moving A Media Description Out Of A BUNDLE Group 822 When an offerer generates an offer, in which it wants to move a 823 bundled "m=" section out of a BUNDLE group, the offerer: 825 o MUST assign a unique address to the "m=" section; and 827 o MUST NOT place the identification-tag associated with the "m=" 828 section in the SDP 'group:BUNDLE' attribute identification-tag 829 list associated with the BUNDLE group; and 831 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 832 section. 834 An offerer MUST NOT move an "m=" section from one BUNDLE group to 835 another within a single offer. If the offerer wants to move an "m=" 836 section from one BUNDLE group to another it MUST first move the 837 BUNDLE group out of the current BUNDLE group, and then generate a 838 second offer where the "m=" section is added to another BUNDLE group 839 [Section 8.5.2]. 841 [Section 18.4] shows an example of an offer for moving an "m=" 842 section out of a BUNDLE group. 844 8.5.4. Disabling A Media Description In A BUNDLE Group 846 When an offerer generates an offer, in which it wants to disable a 847 bundled "m=" section, the offerer: 849 o MUST assign a zero port value to the "m=" section, following the 850 procedures in [RFC4566]; and 852 o MUST NOT place the identification-tag associated with the "m=" 853 section in the SDP 'group:BUNDLE' attribute identification-tag 854 list associated with the BUNDLE group; and 856 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 857 section. 859 [Section 18.5] shows an example of an offer for disabling an "m=" 860 section within a BUNDLE group. 862 9. Protocol Identification 864 Each "m=" section within a BUNDLE group MUST use the same transport- 865 layer protocol. If bundled "m=" sections use different protocols on 866 top of the transport-layer protocol, there MUST exist a publicly 867 available specification which describes a mechanism, for this 868 particular protocol combination, how to associate received data with 869 the correct protocol. 871 In addition, if received data can be associated with more than one 872 bundled "m=" section, there MUST exist a publicly available 873 specification which describes a mechanism for associating the 874 received data with the correct "m=" section. 876 This document describes a mechanism to identify the protocol of 877 received data among the STUN, DTLS and SRTP protocols (in any 878 combination), when UDP is used as transport-layer protocol, but does 879 not describe how to identify different protocols transported on DTLS. 880 While the mechanism is generally applicable to other protocols and 881 transport-layer protocols, any such use requires further 882 specification around how to multiplex multiple protocols on a given 883 transport-layer protocol, and how to associate received data with the 884 correct protocols. 886 9.1. STUN, DTLS, SRTP 888 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 889 protocol of a received packet among the STUN, Datagram Transport 890 Layer Security (DTLS) and SRTP protocols (in any combination). If an 891 offer or answer includes bundled "m=" section that represent these 892 protocols, the offerer or answerer MUST support the mechanism 893 described in [RFC5764], and no explicit negotiation is required in 894 order to indicate support and usage of the mechanism. 896 [RFC5764] does not describe how to identify different protocols 897 transported on DTLS, only how to identify the DTLS protocol itself. 898 If multiple protocols are transported on DTLS, there MUST exist a 899 specification describing a mechanism for identifying each individual 900 protocol. In addition, if a received DTLS packet can be associated 901 with more than one "m=" section, there MUST exist a specification 902 which describes a mechanism for associating the received DTLS packet 903 with the correct "m=" section. 905 [Section 10.2] describes how to associate the packets in a received 906 SRTP stream with the correct "m=" section. 908 10. RTP Considerations 910 10.1. Single RTP Session 912 All RTP-based media within a single BUNDLE group belong to a single 913 RTP session [RFC3550]. 915 Since a single BUNDLE transport is used for sending and receiving 916 bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for 917 RTP-based bundled media. 919 Since a single RTP session is used for each BUNDLE group, all "m=" 920 sections representing RTP-based media within a BUNDLE group will 921 share a single SSRC numbering space [RFC3550]. 923 The following rules and restrictions apply for a single RTP session: 925 o A specific payload type value can be used in multiple bundled "m=" 926 sections only if each codec associated with the payload type 927 number shares an identical codec configuration [Section 10.1.1]. 929 o The proto value in each bundled RTP-based "m=" section MUST be 930 identical (e.g. RTP/AVPF). 932 o The RTP MID header extension MUST be enabled, by including an SDP 933 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 934 hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section 935 in every offer and answer. 937 o A given SSRC MUST NOT transmit RTP packets using payload types 938 that originate from different bundled "m=" sections. 940 NOTE: The last bullet above is to avoid sending multiple media types 941 from the same SSRC. If transmission of multiple media types are done 942 with time overlap, RTP and RTCP fail to function. Even if done in 943 proper sequence this causes RTP Timestamp rate switching issues 944 [RFC7160]. However, once an SSRC has left the RTP session (by 945 sending an RTCP BYE packet), that SSRC can be reused by another 946 source (possibly associated with a different bundled "m=" section) 947 after a delay of 5 RTCP reporting intervals (the delay is to ensure 948 the SSRC has timed out, in case the RTCP BYE packet was lost 949 [RFC3550]). 951 10.1.1. Payload Type (PT) Value Reuse 953 Multiple bundled "m=" section might describe RTP based media. As all 954 RTP based media associated with a BUNDLE group belong to the same RTP 955 session, in order for a given payload type value to be used inside 956 more than one bundled "m=" section, all codecs associated with the 957 payload type number MUST share an identical codec configuration. 958 This means that the codecs MUST share the same media type, encoding 959 name, clock rate and any parameter that can affect the codec 960 configuration and packetization. 961 [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose 962 attribute values must be identical for all codecs that use the same 963 payload type value. 965 10.2. Associating RTP/RTCP Streams With Correct SDP Media Description 967 NOTE: The text in this section is copied from Appendix B of JSEP. 968 The community has not yet agreed on the text. 970 As described in [RFC3550], RTP packets are associated with RTP 971 streams [RFC7656]. Each RTP stream is identified by an SSRC value, 972 and each RTP packet includes an SSRC field that is used to associate 973 the packet with the correct RTP stream. RTCP packets also use SSRCs 974 to identify which RTP streams the packet relates to. However, a RTCP 975 packet can contain multiple SSRC fields, in the course of providing 976 feedback or reports on different RTP streams, and therefore can be 977 associated with multiple such streams. 979 In order to be able to process received RTP/RTCP packets correctly, 980 it must be possible to associate an RTP stream with the correct "m=" 981 section, as the "m=" section and SDP attributes associated with the 982 "m=" section contains information needed to process the packets. 984 As all RTP streams associated with a BUNDLE group use the same 985 transport for sending and receiving RTP/RTCP packets, the local 986 address:port combination part of the transport cannot be used to 987 associate an RTP stream with the correct "m=" section. In addition, 988 multiple RTP streams might be associated with the same "m=" section. 990 An offerer and answerer can inform each other which SSRC values they 991 will use for an RTP stream by using the SDP 'ssrc' attribute 992 [RFC5576]. However, an offerer will not know which SSRC values the 993 answerer will use until the offerer has received the answer providing 994 that information. Due to this, before the offerer has received the 995 answer, the offerer will not be able to associate an RTP stream with 996 the correct "m=" section using the SSRC value associated with the RTP 997 stream. In addition, the offerer and answerer may start using new 998 SSRC values mid-session, without informing each other using the SDP 999 'ssrc' attribute. 1001 In order for an offerer and answerer to always be able to associate 1002 an RTP stream with the correct "m=" section, the offerer and answerer 1003 using the BUNDLE extension MUST support the mechanism defined in 1004 Section 15, where the offerer and answerer insert the identification- 1005 tag associated with an "m=" section (provided by the remote peer) 1006 into RTP and RTCP packets associated with a BUNDLE group. 1008 When using this mechanism, the mapping from an SSRC to an 1009 identification-tag is carried in RTP header extensions or RTCP SDES 1010 packets, as specified in Section 15. Since a compound RTCP packet 1011 can contain multiple RTCP SDES packets, and each RTCP SDES packet can 1012 contain multiple chunks, a single RTCP packet can contain several 1013 SSRC to identification-tag mappings. The offerer and answerer 1014 maintain tables used for routing that are updated each time an RTP/ 1015 RTCP packet contains new information that affects how packets should 1016 be routed. 1018 However, some implementations of may not include this identification- 1019 tag in their RTP and RTCP traffic when using the BUNDLE mechanism, 1020 and instead use a payload type based mechanism to associate RTP 1021 streams with SDP "m=" sections. In this situation, each "m=" section 1022 MUST use unique payload type values, in order for the payload type to 1023 be a reliable indicator of the relevant "m=" section for the RTP 1024 stream. Note that when using the payload type to associate RTP 1025 streams with "m=" sections an RTP stream, identified by SSRC, will be 1026 mapped to an "m=" section when the first packet of that RTP stream is 1027 received, and the mapping will not be changed even if the payload 1028 type used by that RTP stream changes. In other words, the SSRC 1029 cannot to "move" to a different "m=" section simply by changing the 1030 payload type. 1032 Applications can implement RTP stacks in many different ways. The 1033 algorithm below details one way that RTP streams can be associated 1034 with "m=" sections, but is not meant to be prescriptive about exactly 1035 how an RTP stack needs to be implemented. Applications MAY use any 1036 algorithm that achieves equivalent results to those described in the 1037 algorithm below. 1039 To prepare to associate RTP streams with the correct "m=" section, 1040 the following steps MUST be followed for each BUNDLE group. 1042 Construct a table mapping MID to "m=" section for each "m=" 1043 section in this BUNDLE group. Note that an "m=" section may only 1044 have one MID. 1046 Construct a table mapping SSRCs of incoming RTP streams to "m=" 1047 section for each "m=" section in this BUNDLE group and for each 1048 SSRC configured for receiving in that "m=" section. 1050 Construct a table mapping the SSRC of each outgoing RTP stream to 1051 "m=" section for each "m=" section in this BUNDLE group and for 1052 each SSRC configured for sending in that "m=" section. 1054 Construct a table mapping payload type to "m=" section for each 1055 "m=" section in the BUNDLE group and for each payload type 1056 configured for receiving in that "m=" section. If any payload 1057 type is configured for receiving in more than one "m=" section in 1058 the BUNDLE group, do not it include it in the table, as it cannot 1059 be used to uniquely identify a "m=" section. 1061 Note that for each of these tables, there can only be one mapping 1062 for any given key (MID, SSRC, or PT). In other words, the tables 1063 are not multimaps. 1065 As "m=" sections are added or removed from the BUNDLE groups, or 1066 their configurations are changed, the tables above MUST also be 1067 updated. 1069 When an RTP packet is received, it MUST be delivered to the RTP 1070 stream corresponding to its SSRC. That RTP stream MUST then be 1071 associated with the correct "m=" section within a BUNDLE group, for 1072 additional processing, according to the following steps. 1074 If the MID associated with the RTP stream is not in the table 1075 mapping MID to "m=" section, then the RTP stream is not decoded 1076 and the payload data is discarded. 1078 If the packet has a MID, and the packet's extended sequence number 1079 is greater than that of the last MID update, as discussed in 1080 [RFC7941], Section 4.2.6, update the MID associated with the RTP 1081 stream to match the MID carried in the RTP packet, then update the 1082 mapping tables to include an entry that maps the SSRC of that RTP 1083 stream to the "m=" section for that MID. 1085 If the SSRC of the RTP stream is in the incoming SSRC mapping 1086 table, check that the payload type used by the RTP stream matches 1087 a payload type included on the matching "m=" section. If so, 1088 associate the RTP stream with that "m=" section. Otherwise, the 1089 RTP stream is not decoded and the payload data is discarded. 1091 If the payload type used by the RTP stream is in the payload type 1092 table, update the incoming SSRC mapping table to include an entry 1093 that maps the RTP stream's SSRC to the "m=" section for that 1094 payload type. Associate the RTP stream with the corresponding 1095 "m=" section. 1097 Otherwise, mark the RTP stream as not for decoding and discard the 1098 payload. 1100 If the RTP packet contains one of more contributing source (CSRC) 1101 identifiers, then each CSRC is looked up in the incoming SSRC table 1102 and a copy of the RTP packet is associated with the corresponding 1103 "m=" section for additional processing. 1105 For each RTCP packet received (including each RTCP packet that is 1106 part of a compound RTCP packet), the packet is processed as usual by 1107 the RTP layer, then is passed to the "m=" sections corresponding to 1108 the RTP streams it contains information about for additional 1109 processing. This routing is type-dependent, as each kind of RTCP 1110 packet has its own mechanism for associating it with the relevant RTP 1111 streams. 1113 RTCP packets for which no appropriate "m=" section can be identified 1114 MUST be processed as usual by the RTP layer, updating the metadata 1115 associated with the corresponding RTP streams, but are not passed to 1116 any "m=" section. This situation can occur with certain multiparty 1117 RTP topologies, or when RTCP packets are sent containing a subset of 1118 the SDES information. 1120 Rules for additional processing of the various types of RTCP packets 1121 are explained below. 1123 If the RTCP packet is of type SDES, for each chunk in the packet 1124 whose SSRC is found in the incoming SSRC table, deliver a copy of 1125 the SDES packet to the "m=" section associated with that SSRC. In 1126 addition, for any SDES MID items contained in these chunks, if the 1127 MID is found in the table mapping MID to "m=" section, update the 1128 incoming SSRC table to include an entry that maps the RTP stream 1129 associated with chunk's SSRC to the "m=" section associated with 1130 that MID, unless the packet is older than the packet that most 1131 recently updated the mapping for this SSRC, as discussed in 1132 [RFC7941], Section 4.2.6. 1134 Note that if an SDES packet is received as part of a compound RTCP 1135 packet, the SSRC to "m=" section mapping may not exist until the 1136 SDES packet is handled (e.g., in the case where RTCP for a source 1137 is received before any RTP packets). Therefore, when processing a 1138 compound packet, any contained SDES packet MUST be handled first. 1139 Note that this is a backwards change from [RFC3550] Section 6.1, 1140 which states that "Each individual RTCP packet in the compound 1141 packet may be processed independently with no requirements upon 1142 the order or combination of packets". 1144 If the RTCP packet is of type BYE, it indicates that the RTP 1145 streams referenced in the packet are ending. Therefore, for each 1146 SSRC indicated in the packet that is found in the incoming SSRC 1147 table, first deliver a copy of the BYE packet to the "m=" section 1148 associated with that SSRC, but then remove the entry for that SSRC 1149 from the incoming SSRC table after an appropriate delay to account 1150 for "straggler packets", as specified in [RFC3550], Section 6.2.1. 1152 If the RTCP packet is of type SR or RR, for each report block in 1153 the report whose "SSRC of source" is found in the outgoing SSRC 1154 table, deliver a copy of the SR or RR packet to the "m=" section 1155 associated with that SSRC. In addition, if the packet is of type 1156 SR, and the sender SSRC for the packet is found in the incoming 1157 SSRC table, deliver a copy of the SR packet to the "m=" section 1158 associated with that SSRC. 1160 If the implementation supports RTCP XR and the packet is of type 1161 XR, as defined in [RFC3611], for each report block in the report 1162 whose "SSRC of source" is is found in the outgoing SSRC table, 1163 deliver a copy of the XR packet to the "m=" section associated 1164 with that SSRC. In addition, if the sender SSRC for the packet is 1165 found in the incoming SSRC table, deliver a copy of the XR packet 1166 to the "m=" section associated with that SSRC. 1168 If the RTCP packet is a feedback message of type RTPFB or PSFB, as 1169 defined in [RFC4585], it will contain a media source SSRC, and 1170 this SSRC is used for routing certain subtypes of feedback 1171 messages. However, several subtypes of PSFB messages include 1172 target SSRC(s) in a section called Feedback Control Information 1173 (FCI). For these messages, the target SSRC(s) are used for 1174 routing. 1176 If the RTCP packet is a feedback packet that does not include 1177 target SSRCs in its FCI section, and the media source SSRC is 1178 found in the outgoing SSRC table, deliver the feedback packet to 1179 the "m=" section associated with that SSRC. RTPFB and PSFB types 1180 that are handled in this way include: 1182 Generic NACK: [RFC4585] (PT=RTPFB, FMT=1). 1184 Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1). 1186 Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2). 1188 Reference Picture Selection Indication (RPSI): [RFC4585] 1189 (PT=PSFB, FMT=3). 1191 If the RTCP packet is a feedback message that does include target 1192 SSRC(s) in its FCI section, it can either be a request or a 1193 notification. Requests reference a RTP stream that is being sent 1194 by the message recipient, whereas notifications are responses to 1195 an earlier request, and therefore reference a RTP stream that is 1196 being received by the message recipient. 1198 If the RTCP packet is a feedback request that includes target 1199 SSRC(s), for each target SSRC that is found in the outgoing SSRC 1200 table, deliver a copy of the RTCP packet to the "m=" section 1201 associated with that SSRC. PSFB types that are handled in this 1202 way include: 1204 Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). 1206 Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, 1207 FMT=5). 1209 H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, 1210 FMT=7). 1212 Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, 1213 FMT=TBD). 1215 If the RTCP packet is a feedback notification that include target 1216 SSRC(s), for each target SSRC that is found in the incoming SSRC 1217 table, deliver a copy of the RTCP packet to the "m=" section 1218 associated with the RTP stream with matching SSRC. PSFB types 1219 that are handled in this way include: 1221 Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] 1222 (PT=PSFB, FMT=6). This message is a notification in response 1223 to a prior TSTR. 1225 If the RTCP packet is of type APP, then it is handled in an 1226 application specific manner. If the application does not 1227 recognise the APP packet, then it MUST be discarded. 1229 10.3. RTP/RTCP Multiplexing 1231 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 1232 multiplexing [RFC5761] for the RTP-based media specified by the 1233 BUNDLE group. 1235 When RTP/RTCP multiplexing is enabled, the same transport will be 1236 used for both RTP packets and RTCP packets associated with the BUNDLE 1237 group. 1239 10.3.1. SDP Offer/Answer Procedures 1241 This section describes how an offerer and answerer use the SDP 'rtcp- 1242 mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute 1243 [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP 1244 multiplexing for RTP-based media associated with a BUNDLE group. 1246 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] of the SDP 1247 'rtcp-mux' and 'rtcp-mux-only' attributes is IDENTICAL. Section 8.1 1248 describes the details regarding which bundled "m=" sections an 1249 offerer and answerer associates the attributes with. 1251 RTP/RTCP multiplexing only applies to RTP-based media. However, as 1252 described in Section 8.1, within a BUNDLE group the SDP 'rtcp-mux' 1253 and SDP 'rtcp-mux-only' attributes might be included in a non-RTP- 1254 based bundled "m=" section. 1256 10.3.1.1. Generating the Initial SDP Offer 1258 When an offerer generates an initial offer, if the offer contains one 1259 or more RTP-based bundled "m=" sections (or, if there is a chance 1260 that RTP-based "m=" sections will later be added to the BUNDLE 1261 group), the offerer MUST include an SDP 'rtcp-mux' attribute 1262 [RFC5761] in one or more "m=" sections, following the procedures for 1263 IDENTICAL mux category attributes in Section 8.1. In addition, the 1264 offerer MAY include an SDP 'rtcp-mux-only' attribute 1265 [I-D.ietf-mmusic-mux-exclusive] in the same "m=" section. 1267 NOTE: Whether the offerer associates the SDP 'rtcp-mux-only' 1268 attribute depends on whether the offerer supports fallback to usage 1269 of a separate port for RTCP in case the answerer moves one or more 1270 RTP-based "m=" section out of the BUNDLE group in the answer. 1272 NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in one or 1273 more bundled "m=" sections, but does not include an SDP 'rtcp-mux- 1274 only' attribute, the offerer can also include an SDP 'rtcp' attribute 1275 [RFC3605] in one or more RTP-based "m=" sections in order to provide 1276 a fallback port for RTCP, as described in [RFC5761]. However, the 1277 fallback port will only be used for RTP-based "m=" sections moved out 1278 of the BUNDLE group by the answerer. 1280 In the initial offer, the address:port combination for RTCP MUST be 1281 unique in each bundled RTP-based "m=" section (excluding a bundle- 1282 only "m=" section), similar to RTP. 1284 10.3.1.2. Generating the SDP Answer 1286 When an answerer generates an answer, if the answerer supports RTP- 1287 based media, and if a bundled "m=" section in the offer contained an 1288 SDP 'rtcp-mux' attribute, the answerer MUST enable usage of RTP/RTCP 1289 multiplexing, even if there currently are no RTP-based "m=" sections 1290 within the BUNDLE group. The answerer MUST include an SDP 'rtcp-mux' 1291 attribute in "m=" sections within the BUNDLE group in the answer 1292 following the procedures for IDENTICAL mux category attributes in 1293 Section 8.1. In addition, if the "m=" section in the offer contained 1294 an an SDP "rtcp-mux-only" attribute, the answerer MUST include an SDP 1295 "rtcp-mux-only" attribute to the "m=" section in the answer. 1297 If the "m=" section associated with the offerer BUNDLE-tag in the 1298 offer contained an SDP 'rtcp-mux-only' attribute, and if the answerer 1299 moves an RTP-based "m=" section out of the BUNDLE group in the answer 1300 Section 8.3.3, the answerer MUST either include the attribute with in 1301 moved "m=" section (and enable RTP/RTCP multiplexing for the media 1302 associated with the "m=" section), or reject the "m=" section 1303 Section 8.3.4. 1305 The answerer MUST NOT include an SDP 'rtcp' attribute in any "m=" 1306 section within the BUNDLE group in the answer. The answerer will use 1307 the port value of the selected offerer BUNDLE address for sending RTP 1308 and RTCP packets associated with each RTP-based bundled "m=" section 1309 towards the offerer. 1311 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1312 negotiated in a previous offer/answer transaction, the answerer MUST 1313 include an SDP 'rtcp-mux' attribute in the "m=" section associated 1314 with the answerer BUNDLE-tag in the answer. It is not possible to 1315 disable RTP/RTCP multiplexing within a BUNDLE group. 1317 10.3.1.3. Offerer Processing of the SDP Answer 1319 When an offerer receives an answer, if the answerer has accepted the 1320 usage of RTP/RTCP multiplexing (see Section 10.3.1.2), the answerer 1321 follows the procedures for RTP/RTCP multiplexing defined in 1322 [RFC5761]. The offerer will use the port value associated with the 1323 answerer BUNDLE address for sending RTP and RTCP packets associated 1324 with each RTP-based bundled "m=" section towards the answerer. 1326 NOTE: It is considered a protocol error if the answerer has not 1327 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" 1328 sections that the answerer included in the BUNDLE group. 1330 10.3.1.4. Modifying the Session 1332 When an offerer generates a subsequent offer, the offerer MUST 1333 include an SDP 'rtcp-mux' attribute in a bundled "m=" section, 1334 following the procedures for IDENTICAL mux category attributes in 1335 Section 8.1. 1337 If the offerer wants to add a bundled RTP-based "m=" section to the 1338 BUNDLE group, it MAY also include an SDP 'rtcp-mux-only' attribute in 1339 a bundled "m=" section, following the procedures for IDENTICAL mux 1340 category attributes in Section 8.1. This allows the offerer to 1341 mandate RTP/RTCP multiplexing for the added "m=" section (or the "m=" 1342 section to be rejected by the answerer) even if the answerer does not 1343 accept the "m=" section within the BUNDLE group. 1345 11. ICE Considerations 1347 This section describes how to use the BUNDLE grouping extension 1348 together with the Interactive Connectivity Establishment (ICE) 1349 mechanism [I-D.ietf-ice-rfc5245bis]. 1351 The generic procedures for negotiating usage of ICE using SDP, 1352 defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE 1353 with BUNDLE, with the following exceptions: 1355 o When the BUNDLE transport has been established, ICE connectivity 1356 checks and keep-alives only need to be performed for the BUNDLE 1357 transport, instead of per individual "m=" section within the 1358 BUNDLE group. 1360 o In an offer, if the offer assigns a unique address to one or more 1361 bundled "m=" sections (excluding any bundle-only "m=" section), 1362 the offerer MUST include ICE-related media-level attributes in 1363 each of those "m=" sections. If the offerer assigns an offerer 1364 BUNDLE address (previously selected [Section 8.3.1] or new 1365 suggested [Section 8.5.1]) to a bundled "m=" section (the "m=" 1366 section represented by the offerer BUNDLE-tag), the offerer only 1367 includes ICE-related media-level SDP attributes in that "m=" 1368 section, following the procedures in Section 8.1. 1370 o In an answer, the answerer only includes ICE-related media-level 1371 SDP attributes in the bundled "m=" section to which the answerer 1372 has assigned the answerer BUNDLE address (the "m=" section 1373 represented by the answerer BUNDLE-tag), following the procedures 1374 in Section 8.1. 1376 Initially, before ICE has produced a candidate pair that will be used 1377 for media, there might by multiple transports established (if 1378 multiple candidate pairs are tested). Once ICE has produced a 1379 transport that will be used for media, that becomes the BUNDLE 1380 transport. 1382 Support and usage of ICE mechanism together with the BUNDLE extension 1383 is OPTIONAL. 1385 11.1. SDP Offer/Answer Procedures 1387 When an offerer assigns a unique address to one or more bundled "m=" 1388 sections (excluding any bundle-only "m=" section), the offerer MUST 1389 include SDP 'candidate' attributes (and other applicable ICE-related 1390 media-level SDP attributes), containing unique ICE properties 1391 (candidates etc), in each of those "m=" sections, follwoing the 1392 procedures in [I-D.ietf-mmusic-ice-sip-sdp]. 1394 When an offerer assigns a BUNDLE address (previously selected or new 1395 suggested) to a bundled "m=" section, (the "m=" section represented 1396 by the offerer BUNDLE-tag) the offerer MUST only include SDP 1397 'candidate' attributes (and other applicable ICE-related media-level 1398 SDP attributes) in that "m=" section, following the procedures in 1399 Section 8.1. 1401 When an answerer assigns a BUNDLE address to an "m=" section within a 1402 BUNDLE group (the "m=" section represented by the answerer BUNDLE- 1403 tag), the answerer MUST only include SDP 'candidate' attributes (and 1404 other applicable ICE-related media-level SDP attributes) in that "m=" 1405 section, following the procedures in Section 8.1. 1407 NOTE: As most ICE-related media-level SDP attributes belong to the 1408 TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the 1409 offerer and answerer follow the procedures in Section 8.1 when 1410 deciding whether to include an attribute in a bundled "m=" section. 1411 However, in the case of ICE-related media-level attributes, the rules 1412 apply to all attributes (see note below), even if they belong to a 1413 different mux category. 1415 NOTE: The following ICE-related media-level SDP attributes are 1416 defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote- 1417 candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- 1418 pacing'. 1420 12. DTLS Considerations 1422 One or more media streams within a BUNDLE group might use the 1423 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1424 to encrypt the data, or to negotiate encryption keys if another 1425 encryption mechanism is used to encrypt media. 1427 When DTLS is used within a BUNDLE group, the following rules apply: 1429 o There can only be one DTLS association [RFC6347] associated with 1430 the BUNDLE group; and 1432 o Each usage of the DTLS association within the BUNDLE group MUST 1433 use the same mechanism for determining which endpoints (the 1434 offerer or answerer) become DTLS client and DTLS server; and 1436 o Each usage of the DTLS association within the Bundle group MUST 1437 use the same mechanism for determining whether an offer or answer 1438 will trigger the establishment of a new DTLS association, or 1439 whether an existing DTLS association will be used; and 1441 o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include 1442 the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message 1443 [RFC5764], The client MUST include the extension even if the usage 1444 of DTLS-SRTP is not negotiated as part of the multimedia session 1445 (e.g., SIP session [RFC3261]. 1447 NOTE: The inclusion of the 'use_srtp' extension during the initial 1448 DTLS handshake ensures that a DTLS renegotiation will not be required 1449 in order to include the extension, in case DTLS-SRTP encrypted media 1450 is added to the BUNDLE group later during the multimedia session. 1452 13. RTP Header Extensions Consideration 1454 When [RFC8285] RTP header extensions are used in the context of this 1455 specification, the identifier used for a given extension MUST 1456 identify the same extension across all the bundled media 1457 descriptions. 1459 14. Update to RFC 3264 1461 This section replaces the text of the following sections of RFC 3264: 1463 o Section 5.1 (Unicast Streams). 1465 o Section 8.2 (Removing a Media Stream). 1467 o Section 8.4 (Putting a Unicast Media Stream on Hold). 1469 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 1471 For recvonly and sendrecv streams, the port number and address in the 1472 offer indicate where the offerer would like to receive the media 1473 stream. For sendonly RTP streams, the address and port number 1474 indirectly indicate where the offerer wants to receive RTCP reports. 1475 Unless there is an explicit indication otherwise, reports are sent to 1476 the port number one higher than the number indicated. The IP address 1477 and port present in the offer indicate nothing about the source IP 1478 address and source port of RTP and RTCP packets that will be sent by 1479 the offerer. A port number of zero in the offer indicates that the 1480 stream is offered but MUST NOT be used. This has no useful semantics 1481 in an initial offer, but is allowed for reasons of completeness, 1482 since the answer can contain a zero port indicating a rejected stream 1483 (Section 6). Furthermore, existing streams can be terminated by 1484 setting the port to zero (Section 8). In general, a port number of 1485 zero indicates that the media stream is not wanted. 1487 14.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 1489 For recvonly and sendrecv streams, the port number and address in the 1490 offer indicate where the offerer would like to receive the media 1491 stream. For sendonly RTP streams, the address and port number 1492 indirectly indicate where the offerer wants to receive RTCP reports. 1493 Unless there is an explicit indication otherwise, reports are sent to 1494 the port number one higher than the number indicated. The IP address 1495 and port present in the offer indicate nothing about the source IP 1496 address and source port of RTP and RTCP packets that will be sent by 1497 the offerer. A port number of zero in the offer by default indicates 1498 that the stream is offered but MUST NOT be used, but an extension 1499 mechanism might specify different semantics for the usage of a zero 1500 port value. Furthermore, existing streams can be terminated by 1501 setting the port to zero (Section 8). In general, a port number of 1502 zero by default indicates that the media stream is not wanted. 1504 14.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 1506 A stream that is offered with a port of zero MUST be marked with port 1507 zero in the answer. Like the offer, the answer MAY omit all 1508 attributes present previously, and MAY list just a single media 1509 format from amongst those in the offer. 1511 14.4. New text replacing section 8.2 (2nd paragraph) of RFC 3264 1513 A stream that is offered with a port of zero MUST by default be 1514 marked with port zero in the answer, unless an extension mechanism, 1515 which specifies semantics for the usage of a non-zero port value, is 1516 used. If the stream is marked with port zero in the answer, the 1517 answer MAY omit all attributes present previously, and MAY list just 1518 a single media format from amongst those in the offer." 1520 14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 1522 RFC 2543 [10] specified that placing a user on hold was accomplished 1523 by setting the connection address to 0.0.0.0. Its usage for putting 1524 a call on hold is no longer recommended, since it doesn't allow for 1525 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1526 with connection oriented media. However, it can be useful in an 1527 initial offer when the offerer knows it wants to use a particular set 1528 of media streams and formats, but doesn't know the addresses and 1529 ports at the time of the offer. Of course, when used, the port 1530 number MUST NOT be zero, which would specify that the stream has been 1531 disabled. An agent MUST be capable of receiving SDP with a 1532 connection address of 0.0.0.0, in which case it means that neither 1533 RTP nor RTCP should be sent to the peer. 1535 14.6. New text replacing section 8.4 (6th paragraph) of RFC 3264 1537 RFC 2543 [10] specified that placing a user on hold was accomplished 1538 by setting the connection address to 0.0.0.0. Its usage for putting 1539 a call on hold is no longer recommended, since it doesn't allow for 1540 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1541 with connection oriented media. However, it can be useful in an 1542 initial offer when the offerer knows it wants to use a particular set 1543 of media streams and formats, but doesn't know the addresses and 1544 ports at the time of the offer. Of course, when used, the port 1545 number MUST NOT be zero, if it would specify that the stream has been 1546 disabled. However, an extension mechanism might specify different 1547 semantics of the zero port number usage. An agent MUST be capable of 1548 receiving SDP with a connection address of 0.0.0.0, in which case it 1549 means that neither RTP nor RTCP should be sent to the peer. 1551 15. RTP/RTCP extensions for identification-tag transport 1553 SDP Offerers and Answerers [RFC3264] can associate identification- 1554 tags with "m=" sections within SDP Offers and Answers, using the 1555 procedures in [RFC5888]. Each identification-tag uniquely represents 1556 an "m=" section. 1558 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1559 used to carry identification-tags within RTCP SDES packets. This 1560 section also defines a new RTP SDES header extension [RFC7941], which 1561 is used to carry the 'MID' RTCP SDES item in RTP packets. 1563 The SDES item and RTP SDES header extension make it possible for a 1564 receiver to associate each RTP stream with with a specific "m=" 1565 section, with which the receiver has associated an identification- 1566 tag, even if those "m=" sections are part of the same RTP session. 1567 The RTP SDES header extension also ensures that the media recipient 1568 gets the identification-tag upon receipt of the first decodable media 1569 and is able to associate the media with the correct application. 1571 A media recipient informs the media sender about the identification- 1572 tag associated with an "m=" section through the use of an 'mid' 1573 attribute [RFC5888]. The media sender then inserts the 1574 identification-tag in RTCP and RTP packets sent to the media 1575 recipient. 1577 NOTE: This text above defines how identification-tags are carried in 1578 SDP Offers and Answers. The usage of other signalling protocols for 1579 carrying identification-tags is not prevented, but the usage of such 1580 protocols is outside the scope of this document. 1582 [RFC3550] defines general procedures regarding the RTCP transmission 1583 interval. The RTCP MID SDES item SHOULD be sent in the first few 1584 RTCP packets sent after joining the session, and SHOULD be sent 1585 regularly thereafter. The exact number of RTCP packets in which this 1586 SDES item is sent is intentionally not specified here, as it will 1587 depend on the expected packet loss rate, the RTCP reporting interval, 1588 and the allowable overhead. 1590 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1591 be included in some RTP packets at the start of the session and 1592 whenever the SSRC changes. It might also be useful to include the 1593 header extension in RTP packets that comprise access points in the 1594 media (e.g., with video I-frames). The exact number of RTP packets 1595 in which this header extension is sent is intentionally not specified 1596 here, as it will depend on expected packet loss rate and loss 1597 patterns, the overhead the application can tolerate, and the 1598 importance of immediate receipt of the identification-tag. 1600 For robustness purpose, endpoints need to be prepared for situations 1601 where the reception of the identification-tag is delayed, and SHOULD 1602 NOT terminate sessions in such cases, as the identification-tag is 1603 likely to arrive soon. 1605 15.1. RTCP MID SDES Item 1607 0 1 2 3 1608 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 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 | MID=TBD | length | identification-tag ... 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 The identification-tag payload is UTF-8 encoded, as in SDP. 1615 The identification-tag is not zero terminated. 1617 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1618 identifier value.] 1620 15.2. RTP SDES Header Extension For MID 1622 The payload, containing the identification-tag, of the RTP SDES 1623 header extension element can be encoded using either the one-byte or 1624 two-byte header [RFC7941]. The identification-tag payload is UTF-8 1625 encoded, as in SDP. 1627 The identification-tag is not zero terminated. Note, that the set of 1628 header extensions included in the packet needs to be padded to the 1629 next 32-bit boundary using zero bytes [RFC8285]. 1631 As the identification-tag is included in either an RTCP SDES item or 1632 an RTP SDES header extension, or both, there should be some 1633 consideration about the packet expansion caused by the 1634 identification-tag. To avoid Maximum Transmission Unit (MTU) issues 1635 for the RTP packets, the header extension's size needs to be taken 1636 into account when encoding the media. 1638 It is recommended that the identification-tag is kept short. Due to 1639 the properties of the RTP header extension mechanism, when using the 1640 one-byte header, a tag that is 1-3 bytes will result in a minimal 1641 number of 32-bit words used for the RTP SDES header extension, in 1642 case no other header extensions are included at the same time. Note, 1643 do take into account that some single characters when UTF-8 encoded 1644 will result in multiple octets. The identification-tag MUST NOT 1645 contain any user information, and applications SHALL avoid generating 1646 the identification-tag using a pattern that enables application 1647 identification. 1649 16. IANA Considerations 1651 16.1. New SDES item 1653 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1654 document.] 1656 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1657 identifier value.] 1659 This document adds the MID SDES item to the IANA "RTP SDES item 1660 types" registry as follows: 1662 Value: TBD 1663 Abbrev.: MID 1664 Name: Media Identification 1665 Reference: RFCXXXX 1667 16.2. New RTP SDES Header Extension URI 1669 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1670 document.] 1672 This document defines a new extension URI in the RTP SDES Compact 1673 Header Extensions sub-registry of the RTP Compact Header Extensions 1674 registry sub-registry, according to the following data: 1676 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1677 Description: Media identification 1678 Contact: christer.holmberg@ericsson.com 1679 Reference: RFCXXXX 1681 The SDES item does not reveal privacy information about the users. 1682 It is simply used to associate RTP-based media with the correct SDP 1683 media description ("m=" section) in the SDP used to negotiate the 1684 media. 1686 The purpose of the extension is for the offerer to be able to 1687 associate received multiplexed RTP-based media before the offerer 1688 receives the associated SDP answer. 1690 16.3. New SDP Attribute 1692 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1693 document.] 1695 This document defines a new SDP media-level attribute, 'bundle-only', 1696 according to the following data: 1698 Attribute name: bundle-only 1699 Type of attribute: media 1700 Subject to charset: No 1701 Purpose: Request a media description to be accepted 1702 in the answer only if kept within a BUNDLE 1703 group by the answerer. 1704 Appropriate values: N/A 1705 Contact name: Christer Holmberg 1706 Contact e-mail: christer.holmberg@ericsson.com 1707 Reference: RFCXXXX 1708 Mux category: NORMAL 1710 16.4. New SDP Group Semantics 1712 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1713 document.] 1715 This document registers the following semantics with IANA in the 1716 "Semantics for the "group" SDP Attribute" subregistry (under the 1717 "Session Description Protocol (SDP) Parameters" registry: 1719 Semantics Token Reference 1720 ------------------------------------- ------ --------- 1721 Media bundling BUNDLE [RFCXXXX] 1723 17. Security Considerations 1725 The security considerations defined in [RFC3264] and [RFC5888] apply 1726 to the BUNDLE extension. Bundle does not change which information, 1727 e.g., RTP streams, flows over the network, with the exception of the 1728 usage of the MID SDES item as discussed below. Primarily it changes 1729 which addresses and ports, and thus in which (RTP) sessions that the 1730 information is flowing in. This affects the security contexts being 1731 used and can cause previously separated information flows to share 1732 the same security context. This has very little impact on the 1733 performance of the security mechanism of the RTP sessions. In cases 1734 where one would have applied different security policies on the 1735 different RTP streams being bundled, or where the parties having 1736 access to the security contexts would have differed between the RTP 1737 stream, additional analysis of the implications are needed before 1738 selecting to apply BUNDLE. 1740 The identification-tag, independent of transport, RTCP SDES packet or 1741 RTP header extension, can expose the value to parties beyond the 1742 signaling chain. Therefore, the identification-tag values MUST be 1743 generated in a fashion that does not leak user information, e.g., 1744 randomly or using a per-bundle group counter, and SHOULD be 3 bytes 1745 or less, to allow them to efficiently fit into the MID RTP header 1746 extension. Note that if implementations use different methods for 1747 generating identification-tags this could enable fingerprinting of 1748 the implementation making it vulnerable to targeted attacks. The 1749 identification-tag is exposed on the RTP stream level when included 1750 in the RTP header extensions, however what it reveals of the RTP 1751 media stream structure of the endpoint and application was already 1752 possible to deduce from the RTP streams without the MID SDES header 1753 extensions. As the identification-tag is also used to route the 1754 media stream to the right application functionality it is also 1755 important that the value received is the one intended by the sender, 1756 thus integrity and the authenticity of the source are important to 1757 prevent denial of service on the application. Existing SRTP 1758 configurations and other security mechanisms protecting the whole 1759 RTP/RTCP packets will provide the necessary protection. 1761 When the BUNDLE extension is used, the set of configurations of the 1762 security mechanism used in all the bundled media descriptions will 1763 need to be compatible so that they can simultaneously used in 1764 parallel, at least per direction or endpoint. When using SRTP this 1765 will be the case, at least for the IETF defined key-management 1766 solutions due to their SDP attributes (a=crypto, a=fingerprint, 1767 a=mikey) and their classification in 1768 [I-D.ietf-mmusic-sdp-mux-attributes]. 1770 The security considerations of "RTP Header Extension for the RTP 1771 Control Protocol (RTCP) Source Description Items" [RFC7941] requires 1772 that when RTCP is confidentiality protected that any SDES RTP header 1773 extension carrying an SDES item, such as the MID RTP header 1774 extension, is also protected using commensurate strength algorithms. 1775 However, assuming the above requirements and recommendations are 1776 followed there are no known significant security risks with leaving 1777 the MID RTP header extension without confidentiality protection. 1778 Thus, the requirements in RFC 7941 MAY be ignored for the MID RTP 1779 header extension. Security mechanisms for RTP/RTCP are discussed in 1780 Options for Securing RTP Sessions [RFC7201], for example SRTP 1782 [RFC3711] can provide the necessary security functions of ensuring 1783 the integrity and source authenticity. 1785 18. Examples 1787 18.1. Example: Bundle Address Selection 1789 The example below shows: 1791 o An offer, in which the offerer assigns a unique address to each 1792 bundled "m=" section within the BUNDLE group. 1794 o An answer, in which the answerer selects the offerer BUNDLE 1795 address, and then selects its own BUNDLE address (the answerer 1796 BUNDLE address) and assigns it to the bundled "m=" section 1797 represented by the answerer BUNDLE-tag. 1799 SDP Offer (1) 1801 v=0 1802 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1803 s= 1804 c=IN IP4 atlanta.example.com 1805 t=0 0 1806 a=group:BUNDLE foo bar 1807 m=audio 10000 RTP/AVP 0 8 97 1808 b=AS:200 1809 a=mid:foo 1810 a=rtcp-mux 1811 a=rtpmap:0 PCMU/8000 1812 a=rtpmap:8 PCMA/8000 1813 a=rtpmap:97 iLBC/8000 1814 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1815 m=video 10002 RTP/AVP 31 32 1816 b=AS:1000 1817 a=mid:bar 1818 a=rtcp-mux 1819 a=rtpmap:31 H261/90000 1820 a=rtpmap:32 MPV/90000 1821 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1823 SDP Answer (2) 1825 v=0 1826 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1827 s= 1828 c=IN IP4 biloxi.example.com 1829 t=0 0 1830 a=group:BUNDLE foo bar 1831 m=audio 20000 RTP/AVP 0 1832 b=AS:200 1833 a=mid:foo 1834 a=rtcp-mux 1835 a=rtpmap:0 PCMU/8000 1836 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1837 m=video 0 RTP/AVP 32 1838 b=AS:1000 1839 a=mid:bar 1840 a=bundle-only 1841 a=rtpmap:32 MPV/90000 1842 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1844 18.2. Example: BUNDLE Extension Rejected 1846 The example below shows: 1848 o An offer, in which the offerer assigns a unique address to each 1849 bundled "m=" section within the BUNDLE group. 1851 o An answer, in which the answerer rejects the offered BUNDLE group, 1852 and assigns a unique address to each "m=" section (following 1853 normal RFC 3264 procedures). 1855 SDP Offer (1) 1857 v=0 1858 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1859 s= 1860 c=IN IP4 atlanta.example.com 1861 t=0 0 1862 a=group:BUNDLE foo bar 1863 m=audio 10000 RTP/AVP 0 8 97 1864 b=AS:200 1865 a=mid:foo 1866 a=rtcp-mux 1867 a=rtpmap:0 PCMU/8000 1868 a=rtpmap:8 PCMA/8000 1869 a=rtpmap:97 iLBC/8000 1870 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1871 m=video 10002 RTP/AVP 31 32 1872 b=AS:1000 1873 a=mid:bar 1874 a=rtcp-mux 1875 a=rtpmap:31 H261/90000 1876 a=rtpmap:32 MPV/90000 1877 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1879 SDP Answer (2) 1881 v=0 1882 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1883 s= 1884 c=IN IP4 biloxi.example.com 1885 t=0 0 1886 m=audio 20000 RTP/AVP 0 1887 b=AS:200 1888 a=rtcp-mux 1889 a=rtpmap:0 PCMU/8000 1890 m=video 30000 RTP/AVP 32 1891 b=AS:1000 1892 a=rtcp-mux 1893 a=rtpmap:32 MPV/90000 1895 18.3. Example: Offerer Adds A Media Description To A BUNDLE Group 1897 The example below shows: 1899 o A subsequent offer (the BUNDLE group has been created as part of a 1900 previous offer/answer exchange), in which the offerer adds a new 1901 "m=" section, represented by the "zen" identification-tag, to a 1902 previously negotiated BUNDLE group, assigns the previously 1903 selected offerer BUNDLE address to the added "m=" section, 1904 represented by the offerer BUNDLE-tag. To every other bundled 1905 "m=" section the offerer assigns a zero port value and includes an 1906 SDP 'bundle-only' attribute. 1908 o An answer, in which the answerer assigns the answerer BUNDLE 1909 address to the bundled "m=" section represented by the answerer 1910 BUNDLE-tag. To every other bundled "m=S section the answerer 1911 assigns a zero port value and includes an SDP 'bundle-only' 1912 attribute. 1914 SDP Offer (1) 1916 v=0 1917 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1918 s= 1919 c=IN IP4 atlanta.example.com 1920 t=0 0 1921 a=group:BUNDLE zen foo bar 1922 m=audio 0 RTP/AVP 0 8 97 1923 b=AS:200 1924 a=mid:foo 1925 a=bundle-only 1926 a=rtcp-mux 1927 a=rtpmap:0 PCMU/8000 1928 a=rtpmap:8 PCMA/8000 1929 a=rtpmap:97 iLBC/8000 1930 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1931 m=video 0 RTP/AVP 31 32 1932 b=AS:1000 1933 a=mid:bar 1934 a=rtpmap:31 H261/90000 1935 a=rtpmap:32 MPV/90000 1936 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1937 m=video 10000 RTP/AVP 66 1938 b=AS:1000 1939 a=mid:zen 1940 a=bundle-only 1941 a=rtcp-mux 1942 a=rtpmap:66 H261/90000 1943 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1945 SDP Answer (2) 1947 v=0 1948 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1949 s= 1950 c=IN IP4 biloxi.example.com 1951 t=0 0 1952 a=group:BUNDLE zen foo bar 1953 m=audio 0 RTP/AVP 0 1954 b=AS:200 1955 a=mid:foo 1956 a=bundle-only 1957 a=rtcp-mux 1958 a=rtpmap:0 PCMU/8000 1959 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1960 m=video 0 RTP/AVP 32 1961 b=AS:1000 1962 a=mid:bar 1963 a=bundle-only 1964 a=rtpmap:32 MPV/90000 1965 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1966 m=video 20000 RTP/AVP 66 1967 b=AS:1000 1968 a=mid:zen 1969 a=rtpmap:66 H261/90000 1970 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1972 18.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 1974 The example below shows: 1976 o A subsequent offer (the BUNDLE group has been created as part of a 1977 previous offer/answer transaction), in which the offerer moves a 1978 bundled "m=" section, represented by the "zen" identification-tag, 1979 out of a BUNDLE group, assigns a unique address to the moved "m=" 1980 section, and assigns the previously selected offerer BUNDLE 1981 address to another bundled "m=" section, represented by the 1982 offerer BUNDLE-tag. To every other bundled "m=" section the 1983 offerer assigns a zero port value and includes an SDP 'bundle- 1984 only' attribute. 1986 o An answer, in which the answerer moves the "m=" section out of the 1987 BUNDLE group, assigns a unique address to the moved "m=" section, 1988 and assigns the answerer BUNDLE address to the bundled "m=" 1989 section represented by the answerer BUNDLE-tag. To every other 1990 bundled "m=" section the answerer assigns a zero port value and 1991 includes an SDP 'bundle-only' attribute. 1993 SDP Offer (1) 1995 v=0 1996 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1997 s= 1998 c=IN IP4 atlanta.example.com 1999 t=0 0 2000 a=group:BUNDLE foo bar 2001 m=audio 10000 RTP/AVP 0 8 97 2002 b=AS:200 2003 a=mid:foo 2004 a=rtcp-mux 2005 a=rtpmap:0 PCMU/8000 2006 a=rtpmap:8 PCMA/8000 2007 a=rtpmap:97 iLBC/8000 2008 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2009 m=video 0 RTP/AVP 31 32 2010 b=AS:1000 2011 a=mid:bar 2012 a=bundle-only 2013 a=rtpmap:31 H261/90000 2014 a=rtpmap:32 MPV/90000 2015 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2016 m=video 50000 RTP/AVP 66 2017 b=AS:1000 2018 a=mid:zen 2019 a=rtcp-mux 2020 a=rtpmap:66 H261/90000 2022 SDP Answer (2) 2024 v=0 2025 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2026 s= 2027 c=IN IP4 biloxi.example.com 2028 t=0 0 2029 a=group:BUNDLE foo bar 2030 m=audio 20000 RTP/AVP 0 2031 b=AS:200 2032 a=mid:foo 2033 a=rtcp-mux 2034 a=rtpmap:0 PCMU/8000 2035 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2036 m=video 0 RTP/AVP 32 2037 b=AS:1000 2038 a=mid:bar 2039 a=bundle-only 2040 a=rtpmap:32 MPV/90000 2041 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2042 m=video 60000 RTP/AVP 66 2043 b=AS:1000 2044 a=mid:zen 2045 a=rtcp-mux 2046 a=rtpmap:66 H261/90000 2048 18.5. Example: Offerer Disables A Media Description Within A BUNDLE 2049 Group 2051 The example below shows: 2053 o A subsequent offer (the BUNDLE group has been created as part of a 2054 previous offer/answer transaction), in which the offerer disables 2055 a bundled "m=" section represented by the "zen" identification- 2056 tag, within a BUNDLE group, assigns a zero port number to the 2057 disabled "m=" section, and assigns the offerer BUNDLE address to 2058 another bundled "m=" section, represented by the offerer BUNDLE- 2059 tag. To every other bundled "m=" section the offerer assigns a 2060 zero port value and includes an SDP 'bundle-only' attribute. 2062 o An answer, in which the answerer moves the disabled "m=" sections 2063 out of the BUNDLE group, assigns a zero port value to the disabled 2064 "m=" section, and assigns the answerer BUNDLE address to the 2065 bundled "m=" section represented by the answerer BUNDLE-tag. To 2066 every other bundled "m=" section the answerer assigns a zero port 2067 value and includes an SDP 'bundle-only' attribute. 2069 SDP Offer (1) 2071 v=0 2072 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2073 s= 2074 c=IN IP4 atlanta.example.com 2075 t=0 0 2076 a=group:BUNDLE foo bar 2077 m=audio 10000 RTP/AVP 0 8 97 2078 b=AS:200 2079 a=mid:foo 2080 a=rtcp-mux 2081 a=rtpmap:0 PCMU/8000 2082 a=rtpmap:8 PCMA/8000 2083 a=rtpmap:97 iLBC/8000 2084 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2085 m=video 0 RTP/AVP 31 32 2086 b=AS:1000 2087 a=mid:bar 2088 a=bundle-only 2089 a=rtpmap:31 H261/90000 2090 a=rtpmap:32 MPV/90000 2091 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2092 m=video 0 RTP/AVP 66 2093 a=mid:zen 2094 a=rtpmap:66 H261/90000 2096 SDP Answer (2) 2098 v=0 2099 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2100 s= 2101 c=IN IP4 biloxi.example.com 2102 t=0 0 2103 a=group:BUNDLE foo bar 2104 m=audio 20000 RTP/AVP 0 2105 b=AS:200 2106 a=mid:foo 2107 a=rtcp-mux 2108 a=rtpmap:0 PCMU/8000 2109 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2110 m=video 0 RTP/AVP 32 2111 b=AS:1000 2112 a=mid:bar 2113 a=bundle-only 2114 a=rtpmap:32 MPV/90000 2115 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2116 m=video 0 RTP/AVP 66 2117 a=mid:zen 2118 a=rtpmap:66 H261/90000 2120 19. Acknowledgements 2122 The usage of the SDP grouping extension for negotiating bundled media 2123 is based on a similar alternatives proposed by Harald Alvestrand and 2124 Cullen Jennings. The BUNDLE extension described in this document is 2125 based on the different alternative proposals, and text (e.g., SDP 2126 examples) have been borrowed (and, in some cases, modified) from 2127 those alternative proposals. 2129 The SDP examples are also modified versions from the ones in the 2130 Alvestrand proposal. 2132 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 2133 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 2134 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin 2135 Uberti, Taylor Brandstetter, Byron Campen and Eric Rescorla for 2136 reading the text, and providing useful feedback. 2138 Thanks to Bernard Aboba, Cullen Jennings, Peter Thatcher, Justin 2139 Uberti, and Magnus Westerlund for providing the text for the section 2140 on RTP/RTCP stream association. 2142 Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for 2143 providing help and text on the RTP/RTCP procedures. 2145 Thanks to Spotify for providing music for the countless hours of 2146 document editing. 2148 20. Change Log 2150 [RFC EDITOR NOTE: Please remove this section when publishing] 2152 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40 2154 o Editorial changes and technical restrictions in order to make the 2155 specification more understandable: 2157 o https://github.com/cdh4u/draft-sdp-bundle/pull/45 2159 o - BUNDLE address is only assigned to m- section represented by 2160 BUNDLE-tag. 2162 o - bundle-only attribute also used in answers and subsequent 2163 offers. 2165 o - Answerer cannot reject, or remove, the bundled m- section that 2166 contains the BUNDLE address. 2168 o - ICE Offer/Answer sections removed, due to duplicated 2169 information. 2171 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39 2173 o Editorial terminology changes. 2175 o RFC 5285 reference replaced by reference to RFC 8285. 2177 o https://github.com/cdh4u/draft-sdp-bundle/pull/44 2179 o - Clarify that an m- section can not be moved between BUNDLE 2180 groups without first moving the m- section out of a BUNDLE group. 2182 o https://github.com/cdh4u/draft-sdp-bundle/pull/41 2184 o - Addition of BUNDLE transport concept. 2186 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38 2188 o Changes to RTP streaming mapping section based on text from Colin 2189 Perkins. 2191 o The following GitHub pull requests were merged: 2193 o https://github.com/cdh4u/draft-sdp-bundle/pull/34 2195 o - Proposed updates to RTP processing 2197 o https://github.com/cdh4u/draft-sdp-bundle/pull/35 2199 o - fixed reference to receiver-id section 2201 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-37 2203 o The following GitHub pull request was merged: 2205 o https://github.com/cdh4u/draft-sdp-bundle/pull/33 2207 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36 2209 o The following GitHub pull requests were merged: 2211 o https://github.com/cdh4u/draft-sdp-bundle/pull/32 2213 o - extmap handling in BUNDLE. 2215 o https://github.com/cdh4u/draft-sdp-bundle/pull/31 2217 o - Additional Acknowledgement text added. 2219 o https://github.com/cdh4u/draft-sdp-bundle/pull/30 2221 o - MID SDES item security procedures updated 2222 o https://github.com/cdh4u/draft-sdp-bundle/pull/29 2224 o - Appendix B of JSEP moved into BUNDLE. 2226 o - Associating RTP/RTCP packets with SDP m- lines. 2228 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35 2230 o Editorial changes on RTP streaming mapping section based on 2231 comments from Colin Perkins. 2233 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34 2235 o RTP streams, instead of RTP packets, are associated with m- lines. 2237 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 2239 o Editorial changes based on comments from Eric Rescorla and Cullen 2240 Jennings: 2242 o - Changes regarding usage of RTP/RTCP multiplexing attributes. 2244 o - Additional text regarding associating RTP/RTCP packets with SDP 2245 m- lines. 2247 o - Reference correction. 2249 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32 2251 o Editorial changes based on comments from Eric Rescorla and Cullen 2252 Jennings: 2254 o - Justification for mechanism added to Introduction. 2256 o - Clarify that the order of m- lines in the group:BUNDLE attribute 2257 does not have to be the same as the order in which the m- lines 2258 are listed in the SDP. 2260 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31 2262 o Editorial changes based on GitHub Pull requests by Martin Thomson: 2264 o - https://github.com/cdh4u/draft-sdp-bundle/pull/2 2266 o - https://github.com/cdh4u/draft-sdp-bundle/pull/1 2268 o Editorial change based on comment from Diederick Huijbers (9th 2269 July 2016). 2271 o Changes based on comments from Flemming Andreasen (21st June 2272 2016): 2274 o - Mux category for SDP bundle-only attribute added. 2276 o - Mux category considerations editorial clarification. 2278 o - Editorial changes. 2280 o RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext. 2282 o Note whether Design Considerations appendix is to be kept removed: 2284 o - Appendix is kept within document. 2286 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30 2288 o Indicating in the Abstract and Introduction that the document 2289 updates RFC 3264. 2291 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29 2293 o Change based on WGLC comment from Colin Perkins. 2295 o - Clarify that SSRC can be reused by another source after a delay 2296 of 5 RTCP reporting intervals. 2298 o Change based on WGLC comment from Alissa Cooper. 2300 o - IANA registry name fix. 2302 o - Additional IANA registration information added. 2304 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28 2306 o - Alignment with exclusive mux procedures. 2308 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 2310 o - Yet another terminology change. 2312 o - Mux category considerations added. 2314 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 2316 o - ICE considerations modified: ICE-related SDP attributes only 2317 added to the bundled m- line representing the selected BUNDLE 2318 address. 2320 o - Reference to draft-ietf-mmusic-ice-sip-sdp added. 2322 o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- 2323 rfc5245bis. 2325 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 2327 o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux 2328 considerations. 2330 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 2332 o - Reference and procedures associated with exclusive RTP/RTCP mux 2333 added 2335 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 2337 o - RTCP-MUX mandatory for bundled RTP m- lines 2339 o - Editorial fixes based on comments from Flemming Andreasen 2341 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 2343 o - Correction of Ari's family name 2345 o - Editorial fixes based on comments from Thomas Stach 2347 o - RTP/RTCP correction based on comment from Magnus Westerlund 2349 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2350 msg14861.html 2352 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 2354 o - Correct based on comment from Paul Kyzivat 2356 o -- 'received packets' replaced with 'received data' 2358 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 2360 o - Clarification based on comment from James Guballa 2362 o - Clarification based on comment from Flemming Andreasen 2364 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 2366 o - DTLS Considerations section added. 2368 o - BUNDLE semantics added to the IANA Considerations 2370 o - Changes based on WGLC comments from Adam Roach 2372 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2373 msg14673.html 2375 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 2377 o - Changes based on agreements at IETF#92 2379 o -- BAS Offer removed, based on agreement at IETF#92. 2381 o -- Procedures regarding usage of SDP "b=" line is replaced with a 2382 reference to to draft-ietf-mmusic-sdp-mux-attributes. 2384 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 2386 o - Editorial changes based on comments from Magnus Westerlund. 2388 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 2390 o - Modification of RTP/RTCP multiplexing section, based on comments 2391 from Magnus Westerlund. 2393 o - Reference updates. 2395 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 2397 o - Editorial fix. 2399 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 2401 o - Editorial changes. 2403 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 2405 o Changes to allow a new suggested offerer BUNDLE address to be 2406 assigned to each bundled m- line. 2408 o Changes based on WGLC comments from Paul Kyzivat 2410 o - Editorial fixes 2412 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 2414 o Usage of SDP 'extmap' attribute added 2415 o SDP 'bundle-only' attribute scoped with "m=" lines with a zero 2416 port value 2418 o Changes based on WGLC comments from Thomas Stach 2420 o - ICE candidates not assigned to bundle-only m- lines with a zero 2421 port value 2423 o - Editorial changes 2425 o Changes based on WGLC comments from Colin Perkins 2427 o - Editorial changes: 2429 o -- "RTP SDES item" -> "RTCP SDES item" 2431 o -- "RTP MID SDES item" -> "RTCP MID SDES item" 2433 o - Changes in section 10.1.1: 2435 o -- "SHOULD NOT" -> "MUST NOT" 2437 o -- Additional text added to the Note 2439 o - Change to section 13.2: 2441 o -- Clarify that mid value is not zero terminated 2443 o - Change to section 13.3: 2445 o -- Clarify that mid value is not zero terminated 2447 o -- Clarify padding 2449 o Changes based on WGLC comments from Paul Kyzivat 2451 o - Editorial changes: 2453 o Changes based on WGLC comments from Jonathan Lennox 2455 o - Editorial changes: 2457 o - Defintion of SDP bundle-only attribute alligned with structure 2458 in 4566bis draft 2460 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 2462 o Editorial corrections based on comments from Harald Alvestrand. 2464 o Editorial corrections based on comments from Cullen Jennings. 2466 o Reference update (RFC 7160). 2468 o Clarification about RTCP packet sending when RTP/RTCP multiplexing 2469 is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ 2470 msg13765.html). 2472 o Additional text added to the Security Considerations. 2474 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 2476 o SDP bundle-only attribute added to IANA Considerations. 2478 o SDES item and RTP header extension added to Abstract and 2479 Introduction. 2481 o Modification to text updating section 8.2 of RFC 3264. 2483 o Reference corrections. 2485 o Editorial corrections. 2487 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 2489 o Terminology change: "bundle-only attribute assigned to m= line" to 2490 "bundle-only attribute associated with m= line". 2492 o Editorial corrections. 2494 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 2496 o Editorial corrections. 2498 o - "of"->"if" (8.3.2.5). 2500 o - "optional"->"OPTIONAL" (9.1). 2502 o - Syntax/ABNF for 'bundle-only' attribute added. 2504 o - SDP Offer/Answer sections merged. 2506 o - 'Request new offerer BUNDLE address' section added 2508 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 2510 o OPEN ISSUE regarding Receiver-ID closed. 2512 o - RTP MID SDES Item. 2514 o - RTP MID Header Extension. 2516 o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers 2517 closed. 2519 o - Indicating that, when rtcp-mux is used, the answerer MUST NOT 2520 include an 'rtcp' attribute in the answer, based on the procedures 2521 in section 5.1.3 of RFC 5761. 2523 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 2525 o Draft title changed. 2527 o Added "SDP" to section names containing "Offer" or "Answer". 2529 o Editorial fixes based on comments from Paul Kyzivat 2530 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2531 msg13314.html). 2533 o Editorial fixed based on comments from Colin Perkins 2534 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2535 msg13318.html). 2537 o - Removed text about extending BUNDLE to allow multiple RTP 2538 sessions within a BUNDLE group. 2540 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 2542 o Major re-structure of SDP Offer/Answer sections, to align with RFC 2543 3264 structure. 2545 o Additional definitions added. 2547 o - Shared address. 2549 o - Bundled "m=" line. 2551 o - Bundle-only "m=" line. 2553 o - Offerer suggested BUNDLE mid. 2555 o - Answerer selected BUNDLE mid. 2557 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 2558 to multiple "m=" lines until it has received an SDP Answer 2559 indicating support of the BUNDLE extension. 2561 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 2562 Answerer supports the BUNDLE extension, assign a zero port value 2563 to a 'bundle-only' "m=" line. 2565 o SDP 'bundle-only' attribute section added. 2567 o Connection data nettype/addrtype restrictions added. 2569 o RFC 3264 update section added. 2571 o Indicating that a specific payload type value can be used in 2572 multiple "m=" lines, if the value represents the same codec 2573 configuration in each "m=" line. 2575 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 2577 o Updated Offerer procedures (http://www.ietf.org/mail- 2578 archive/web/mmusic/current/msg12293.html). 2580 o Updated Answerer procedures (http://www.ietf.org/mail- 2581 archive/web/mmusic/current/msg12333.html). 2583 o Usage of SDP 'bundle-only' attribute added. 2585 o Reference to Trickle ICE document added. 2587 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 2589 o Mechanism modified, to be based on usage of SDP Offers with both 2590 different and identical port number values, depending on whether 2591 it is known if the remote endpoint supports the extension. 2593 o Cullen Jennings added as co-author. 2595 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 2597 o No changes. New version due to expiration. 2599 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 2601 o No changes. New version due to expiration. 2603 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 2605 o Draft name changed. 2607 o Harald Alvestrand added as co-author. 2609 o "Multiplex" terminology changed to "bundle". 2611 o Added text about single versus multiple RTP Sessions. 2613 o Added reference to RFC 3550. 2615 21. References 2617 21.1. Normative References 2619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2620 Requirement Levels", BCP 14, RFC 2119, 2621 DOI 10.17487/RFC2119, March 1997, . 2624 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2625 with Session Description Protocol (SDP)", RFC 3264, 2626 DOI 10.17487/RFC3264, June 2002, . 2629 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2630 Jacobson, "RTP: A Transport Protocol for Real-Time 2631 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2632 July 2003, . 2634 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2635 in Session Description Protocol (SDP)", RFC 3605, 2636 DOI 10.17487/RFC3605, October 2003, . 2639 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2640 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2641 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2642 . 2644 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2645 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2646 July 2006, . 2648 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2649 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2650 . 2652 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2653 Control Packets on a Single Port", RFC 5761, 2654 DOI 10.17487/RFC5761, April 2010, . 2657 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2658 Security (DTLS) Extension to Establish Keys for the Secure 2659 Real-time Transport Protocol (SRTP)", RFC 5764, 2660 DOI 10.17487/RFC5764, May 2010, . 2663 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2664 Protocol (SDP) Grouping Framework", RFC 5888, 2665 DOI 10.17487/RFC5888, June 2010, . 2668 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2669 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2670 January 2012, . 2672 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2673 Header Extension for the RTP Control Protocol (RTCP) 2674 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2675 August 2016, . 2677 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 2678 Mechanism for RTP Header Extensions", RFC 8285, 2679 DOI 10.17487/RFC8285, October 2017, . 2682 [I-D.ietf-ice-rfc5245bis] 2683 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2684 Connectivity Establishment (ICE): A Protocol for Network 2685 Address Translator (NAT) Traversal", draft-ietf-ice- 2686 rfc5245bis-15 (work in progress), November 2017. 2688 [I-D.ietf-mmusic-sdp-mux-attributes] 2689 Nandakumar, S., "A Framework for SDP Attributes when 2690 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 2691 (work in progress), December 2016. 2693 [I-D.ietf-mmusic-mux-exclusive] 2694 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 2695 Multiplexing using SDP", draft-ietf-mmusic-mux- 2696 exclusive-12 (work in progress), May 2017. 2698 [I-D.ietf-mmusic-ice-sip-sdp] 2699 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, 2700 "Session Description Protocol (SDP) Offer/Answer 2701 procedures for Interactive Connectivity Establishment 2702 (ICE)", draft-ietf-mmusic-ice-sip-sdp-16 (work in 2703 progress), November 2017. 2705 21.2. Informative References 2707 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2708 A., Peterson, J., Sparks, R., Handley, M., and E. 2709 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2710 DOI 10.17487/RFC3261, June 2002, . 2713 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2714 "RTP Control Protocol Extended Reports (RTCP XR)", 2715 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2716 . 2718 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2719 "Codec Control Messages in the RTP Audio-Visual Profile 2720 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 2721 February 2008, . 2723 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2724 "Extended RTP Profile for Real-time Transport Control 2725 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2726 DOI 10.17487/RFC4585, July 2006, . 2729 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2730 Media Attributes in the Session Description Protocol 2731 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2732 . 2734 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2735 Clock Rates in an RTP Session", RFC 7160, 2736 DOI 10.17487/RFC7160, April 2014, . 2739 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2740 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2741 . 2743 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2744 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2745 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2746 DOI 10.17487/RFC7656, November 2015, . 2749 [I-D.ietf-ice-trickle] 2750 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 2751 "Trickle ICE: Incremental Provisioning of Candidates for 2752 the Interactive Connectivity Establishment (ICE) 2753 Protocol", draft-ietf-ice-trickle-15 (work in progress), 2754 November 2017. 2756 [I-D.ietf-avtext-lrr] 2757 Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 2758 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 2759 Message", draft-ietf-avtext-lrr-07 (work in progress), 2760 July 2017. 2762 Appendix A. Design Considerations 2764 One of the main issues regarding the BUNDLE grouping extensions has 2765 been whether, in SDP Offers and SDP Answers, the same port value 2766 should be inserted in "m=" lines associated with a BUNDLE group, as 2767 the purpose of the extension is to negotiate the usage of a single 2768 transport for media specified by the "m=" sections. Issues with both 2769 approaches, discussed in the Appendix have been raised. The outcome 2770 was to specify a mechanism which uses SDP Offers with both different 2771 and identical port values. 2773 Below are the primary issues that have been considered when defining 2774 the "BUNDLE" grouping extension: 2776 o 1) Interoperability with existing UAs. 2778 o 2) Interoperability with intermediary B2BUA- and proxy entities. 2780 o 3) Time to gather, and the number of, ICE candidates. 2782 o 4) Different error scenarios, and when they occur. 2784 o 5) SDP Offer/Answer impacts, including usage of port number value 2785 zero. 2787 A.1. UA Interoperability 2789 Consider the following SDP Offer/Answer exchange, where Alice sends 2790 an SDP Offer to Bob: 2792 SDP Offer 2794 v=0 2795 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2796 s= 2797 c=IN IP4 atlanta.example.com 2798 t=0 0 2799 m=audio 10000 RTP/AVP 97 2800 a=rtpmap:97 iLBC/8000 2801 m=video 10002 RTP/AVP 97 2802 a=rtpmap:97 H261/90000 2804 SDP Answer 2806 v=0 2807 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2808 s= 2809 c=IN IP4 biloxi.example.com 2810 t=0 0 2811 m=audio 20000 RTP/AVP 97 2812 a=rtpmap:97 iLBC/8000 2813 m=video 20002 RTP/AVP 97 2814 a=rtpmap:97 H261/90000 2816 RFC 4961 specifies a way of doing symmetric RTP but that is an a 2817 later invention to RTP and Bob can not assume that Alice supports RFC 2818 4961. This means that Alice may be sending RTP from a different port 2819 than 10000 or 10002 - some implementation simply send the RTP from an 2820 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2821 way that Bob knows if it should be passed to the video or audio codec 2822 is by looking at the port it was received on. This lead some SDP 2823 implementations to use the fact that each "m=" section had a 2824 different port number to use that port number as an index to find the 2825 correct m line in the SDP. As a result, some implementations that do 2826 support symmetric RTP and ICE still use a SDP data structure where 2827 SDP with "m=" sections with the same port such as: 2829 SDP Offer 2831 v=0 2832 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2833 s= 2834 c=IN IP4 atlanta.example.com 2835 t=0 0 2836 m=audio 10000 RTP/AVP 97 2837 a=rtpmap:97 iLBC/8000 2838 m=video 10000 RTP/AVP 98 2839 a=rtpmap:98 H261/90000 2841 will result in the second "m=" section being considered an SDP error 2842 because it has the same port as the first line. 2844 A.2. Usage of port number value zero 2846 In an SDP Offer or SDP Answer, the media specified by an "m=" section 2847 can be disabled/rejected by setting the port number value to zero. 2848 This is different from e.g., using the SDP direction attributes, 2849 where RTCP traffic will continue even if the SDP "inactive" attribute 2850 is indicated for the associated "m=" section. 2852 If each "m=" section associated with a BUNDLE group would contain 2853 different port values, and one of those port values would be used for 2854 a BUNDLE address associated with the BUNDLE group, problems would 2855 occur if an endpoint wants to disable/reject the "m=" sectcion 2856 associated with that port, by setting the port value to zero. After 2857 that, no "m=" section would contain the port value which is used for 2858 the BUNDLE address. In addition, it is unclear what would happen to 2859 the ICE candidates associated with the "m=" section, as they are also 2860 used for the BUNDLE address. 2862 A.3. B2BUA And Proxy Interoperability 2864 Some back to back user agents may be configured in a mode where if 2865 the incoming call leg contains an SDP attribute the B2BUA does not 2866 understand, the B2BUA still generates that SDP attribute in the Offer 2867 for the outgoing call leg. Consider a B2BUA that did not understand 2868 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 2869 Further assume that the B2BUA was configured to tear down any call 2870 where it did not see any RTCP for 5 minutes. In this case, if the 2871 B2BUA received an Offer like: 2873 SDP Offer 2875 v=0 2876 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2877 s= 2878 c=IN IP4 atlanta.example.com 2879 t=0 0 2880 m=audio 49170 RTP/AVP 0 2881 a=rtcp:53020 2883 It would be looking for RTCP on port 49172 but would not see any 2884 because the RTCP would be on port 53020 and after five minutes, it 2885 would tear down the call. Similarly, a B2BUA that did not understand 2886 BUNDLE yet put BUNDLE in it's offer may be looking for media on the 2887 wrong port and tear down the call. It is worth noting that a B2BUA 2888 that generated an Offer with capabilities it does not understand is 2889 not compliant with the specifications. 2891 A.3.1. Traffic Policing 2893 Sometimes intermediaries do not act as B2BUA, in the sense that they 2894 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2895 however, they may use SDP information (e.g., IP address and port) in 2896 order to control traffic gating functions, and to set traffic 2897 policing rules. There might be rules which will trigger a session to 2898 be terminated in case media is not sent or received on the ports 2899 retrieved from the SDP. This typically occurs once the session is 2900 already established and ongoing. 2902 A.3.2. Bandwidth Allocation 2904 Sometimes intermediaries do not act as B2BUA, in the sense that they 2905 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2906 however, they may use SDP information (e.g., codecs and media types) 2907 in order to control bandwidth allocation functions. The bandwidth 2908 allocation is done per "m=" section, which means that it might not be 2909 enough if media specified by all "m=" sections try to use that 2910 bandwidth. That may either simply lead to bad user experience, or to 2911 termination of the call. 2913 A.4. Candidate Gathering 2915 When using ICE, a candidate needs to be gathered for each port. This 2916 takes approximately 20 ms extra for each extra "m=" section due to 2917 the NAT pacing requirements. All of this gather can be overlapped 2918 with other things while for exampe a web-page is loading to minimize 2919 the impact. If the client only wants to generate TURN or STUN ICE 2920 candidates for one of the "m=" lines and then use trickle ICE 2921 [I-D.ietf-ice-trickle] to get the non host ICE candidates for the 2922 rest of the "m=" sections, it MAY do that and will not need any 2923 additional gathering time. 2925 Some people have suggested a TURN extension to get a bunch of TURN 2926 allocations at once. This would only provide a single STUN result so 2927 in cases where the other end did not support BUNDLE, may cause more 2928 use of the TURN server but would be quick in the cases where both 2929 sides supported BUNDLE and would fall back to a successful call in 2930 the other cases. 2932 Authors' Addresses 2934 Christer Holmberg 2935 Ericsson 2936 Hirsalantie 11 2937 Jorvas 02420 2938 Finland 2940 Email: christer.holmberg@ericsson.com 2942 Harald Tveit Alvestrand 2943 Google 2944 Kungsbron 2 2945 Stockholm 11122 2946 Sweden 2948 Email: harald@alvestrand.no 2950 Cullen Jennings 2951 Cisco 2952 400 3rd Avenue SW, Suite 350 2953 Calgary, AB T2P 4H2 2954 Canada 2956 Email: fluffy@iii.ca