idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-42.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 29, 2017) is 2340 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 1562 == Missing Reference: 'RFCXXXX' is mentioned on line 1746, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-20) exists of draft-ietf-ice-rfc5245bis-15 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-16 == Outdated reference: A later version (-21) exists of draft-ietf-ice-trickle-15 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Updates: 3264 (if approved) H. Alvestrand 5 Intended status: Standards Track Google 6 Expires: June 2, 2018 C. Jennings 7 Cisco 8 November 29, 2017 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-42.txt 14 Abstract 16 This specification defines a new Session Description Protocol (SDP) 17 Grouping Framework extension, 'BUNDLE'. The extension can be used 18 with the SDP Offer/Answer mechanism to negotiate the usage of a 19 single transport (5-tuple) for sending and receiving media described 20 by multiple SDP media descriptions ("m=" sections). Such transport 21 is referred to as a BUNDLE transport, and the media is referred to as 22 bundled media. The "m=" sections that use the BUNDLE transport form 23 a BUNDLE group. 25 To assist endpoints in negotiating the use of bundle this 26 specification defines a new SDP attribute, 'bundle-only', which can 27 be used to request that specific media is only used if bundled. The 28 specification also updates RFC 3264, to allow assigning a zero port 29 value to a "m= section without meaning that the media described by 30 the "m=" section is disabled or rejected. 32 When RTP-based media is used, there are multiple ways to correlate 33 bundled RTP packets with the appropriate "m=" section. This 34 specification defines a new Real-time Transport Protocol (RTP) source 35 description (SDES) item and a new RTP header extension that provides 36 an additional way to do this correlation by using them to carry a 37 value that associates the RTP/RTCP packets with a specific "m=" 38 section. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on June 2, 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 . . . . 18 110 8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 18 111 8.5.4. Disabling A Media Description In A BUNDLE Group . . . 19 112 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 19 113 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 20 114 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 20 115 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 20 116 10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 21 117 10.2. Associating RTP/RTCP Streams With Correct SDP Media 118 Description . . . . . . . . . . . . . . . . . . . . . . 21 119 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 27 120 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 27 121 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 29 122 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 30 123 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 31 124 13. RTP Header Extensions Consideration . . . . . . . . . . . . . 31 125 14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 32 126 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 32 127 14.2. New text replacing section 5.1 (2nd paragraph) of RFC 128 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 32 129 14.3. Original text of section 6 (4th paragraph) of RFC 3264 . 33 130 14.4. New text replacing section 6 (4th paragraph) of RFC 3264 33 131 14.5. Original text of section 8.2 (2nd paragraph) of RFC 3264 33 132 14.6. New text replacing section 8.2 (2nd paragraph) of RFC 133 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 134 14.7. Original text of section 8.4 (6th paragraph) of RFC 3264 33 135 14.8. New text replacing section 8.4 (6th paragraph) of RFC 136 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 137 15. RTP/RTCP extensions for identification-tag transport . . . . 34 138 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 35 139 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 35 140 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 141 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 36 142 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 37 143 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 37 144 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 38 145 17. Security Considerations . . . . . . . . . . . . . . . . . . . 38 146 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39 147 18.1. Example: Bundle Address Selection . . . . . . . . . . . 39 148 18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 41 149 18.3. Example: Offerer Adds A Media Description To A BUNDLE 150 Group . . . . . . . . . . . . . . . . . . . . . . . . . 42 151 18.4. Example: Offerer Moves A Media Description Out Of A 152 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 44 153 18.5. Example: Offerer Disables A Media Description Within A 154 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46 155 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 156 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 48 157 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 158 21.1. Normative References . . . . . . . . . . . . . . . . . . 58 159 21.2. Informative References . . . . . . . . . . . . . . . . . 60 160 Appendix A. Design Considerations . . . . . . . . . . . . . . . 61 161 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 62 162 A.2. Usage of port number value zero . . . . . . . . . . . . . 63 163 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 63 164 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 64 165 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 64 166 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 64 167 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 169 1. Introduction 171 When multimedia communications are established, each transport 172 (5-tuple) reserved for an individual media stream consume additional 173 resources (especially when Interactive Connectivity Establishment 174 (ICE) [I-D.ietf-ice-rfc5245bis] is used). For this reason, it is 175 attractive to use a single transport for multiple media streams. 177 This specification defines a way to use a single transport (BUNDLE 178 transport) for sending and receiving media (bundled media) described 179 by multiple SDP media descriptions ("m=" sections). The same BUNDLE 180 transport is used for sending and receiving bundled media, which 181 means that the symmetric RTP mechanism [RFC4961] is always used for 182 RTP-based bundled media. 184 This specification defines a new SDP Grouping Framework [RFC5888] 185 extension called 'BUNDLE'. The extension can be used with the 186 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 187 to negotiate which "m=" sections will become part of a BUNDLE group. 188 Within a BUNDLE group, each "m=" section will use a BUNDLE transport 189 for sending and receiving bundled media. 191 Within a BUNDLE group, each endpoint uses a single address:port 192 combination for sending and receiving bundled media. The 193 address:port combination is referred to as BUNDLE address. In 194 addition to negotiating the BUNDLE group, the offerer and answerer 195 [RFC3264] use the BUNDLE extension to negotiate the BUNDLE addresses, 196 one for the offerer (offerer BUNDLE address) and one for the answerer 197 (answerer BUNDLE address). Once the offerer and the answerer have 198 negotiated the BUNDLE addresses, and a BUNDLE group has been formed, 199 they assign their respective BUNDLE address to each "m=" section 200 within the BUNDLE group. The endpoints then use the BUNDLE addresses 201 for sending and receiving the bundled media associated with the 202 BUNDLE group. 204 The use of a BUNDLE transport also allows the usage of a single set 205 of Interactive Connectivity Establishment (ICE) 206 [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group. 208 This specification also defines a new SDP attribute, 'bundle-only', 209 which can be used to request that specific media is only used if the 210 "m=" section describing the media is kept within a BUNDLE group. The 211 specification also updates RFC 3264, to allow usage of zero port 212 values without meaning that media is rejected. 214 As defined in RFC 4566 [RFC4566], the semantics of assigning the same 215 transport address (IP address and port) to multiple "m=" sections are 216 undefined, and there is no grouping defined by such means. Instead, 217 an explicit grouping mechanism needs to be used to express the 218 intended semantics. This specification provides such an extension. 220 This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 221 [RFC3264]. The update allows an answerer to assign a non-zero port 222 value to an "m=" section in an SDP answer, even if the "m=" section 223 in the associated SDP offer contained a zero port value. 225 This specification also defines a new Real-time Transport Protocol 226 (RTP) [RFC3550] source description (SDES) item, 'MID', and a new RTP 227 SDES header extension that can be used to associate RTP streams with 228 "m=" sections. 230 SDP bodies can contain multiple BUNDLE groups. A given BUNDLE 231 address MUST only be associated with a single BUNDLE group. The 232 procedures in this specification apply independently to a given 233 BUNDLE group. All RTP based media flows described by a single BUNDLE 234 group belong to a single RTP session [RFC3550]. 236 The BUNDLE extension is backward compatible. Endpoints that do not 237 support the extension are expected to generate offers and answers 238 without an SDP 'group:BUNDLE' attribute, and are expected to assign a 239 unique address to each "m=" section within an offer and answer, 240 according to the procedures in [RFC4566] and [RFC3264] 242 2. Terminology 244 "m=" section: SDP bodies contain one or more media descriptions, 245 referred to as "m=" sections. Each "m=" section is represented by an 246 SDP "m=" line, and zero or more SDP attributes associated with the 247 "m=" line. An local address:port combination is assigned to each 248 "m=" section. 250 5-tuple: A collection of the following values: source address, source 251 port, destination address, destination port, and transport-layer 252 protocol. 254 Unique address: An address:port combination that is assigned to only 255 one "m=" section in an offer or answer. 257 Offerer BUNDLE-tag: The first identification-tag in a given SDP 258 'group:BUNDLE' attribute identification-tag list in an offer. 260 Answerer BUNDLE-tag: The first identification-tag in a given SDP 261 'group:BUNDLE' attribute identification-tag list in an answer. 263 BUNDLE address: An address:port combination that an endpoint uses for 264 sending and receiving bundled media. 266 Offerer BUNDLE address: In an offer, the BUNDLE address of the 267 offerer. 269 Answerer BUNDLE address: In an answer, the BUNDLE address of the 270 answerer. 272 BUNDLE transport: The transport (5-tuple) used by all media described 273 by the "m=" sections within a BUNDLE group. 275 BUNDLE group: A set of "m=" sections, created using an SDP Offer/ 276 Answer exchange, which uses a single BUNDLE transport for sending and 277 receiving all media (bundled media) described by the set of "m=" 278 sections. The same BUNDLE transport is used for sending and 279 receiving bundled media. 281 Bundled "m=" section: An "m=" section, whose identification-tag is 282 placed in an SDP 'group:BUNDLE' attribute identification-tag list in 283 an offer or answer. 285 Bundle-only "m=" section: A bundled "m=" section that contains an SDP 286 'bundle-only' attribute. 288 Bundled media: All media associated with a given BUNDLE group. 290 Initial offer: The first offer, within an SDP session (e.g. a SIP 291 dialog when the Session Initiation Protocol (SIP) [RFC3261] is used 292 to carry SDP), in which the offerer indicates that it wants to create 293 a given BUNDLE group. 295 Subsequent offer: An offer which contains a BUNDLE group that has 296 been created as part of a previous offer/answer exchange. 298 Identification-tag: A unique token value that is used to identify an 299 "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" section 300 carries the unique identification-tag assigned to that "m=" section. 301 The session-level SDP 'group' attribute [RFC5888] carries a list of 302 identification-tags, identifying the "m=" sections associated with 303 that particular 'group' attribute. 305 3. Conventions 307 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 308 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 309 document are to be interpreted as described in BCP 14, RFC 2119 310 [RFC2119]. 312 4. Applicability Statement 314 The mechanism in this specification only applies to the Session 315 Description Protocol (SDP) [RFC4566], when used together with the SDP 316 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 317 scope of this document, and is thus undefined. 319 5. SDP Grouping Framework BUNDLE Extension 321 This section defines a new SDP Grouping Framework [RFC5888] 322 extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP 323 Offer/Answer mechanism to negotiate a set of "m=" sections that will 324 become part of a BUNDLE group. Within a BUNDLE group, each "m=" 325 section will use a BUNDLE transport for sending and receiving bundled 326 media. Each endpoint use a single address:port combination for 327 sending receiving the bundled media. 329 The BUNDLE extension is indicated using an SDP 'group' attribute with 330 a "BUNDLE" semantics value [RFC5888]. An identification-tag is 331 assigned to each bundled "m=" section, and each identification-tag is 332 listed in the SDP 'group:BUNDLE' attribute identification-tag list. 333 Each "m=" section whose identification-tag is listed in the 334 identification-tag list is associated with a given BUNDLE group. 336 SDP bodies can contain multiple BUNDLE groups. Any given bundled 337 "m=" section MUST NOT be associated with more than one BUNDLE group 338 at any given time. 340 NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' 341 attribute identification-tag list does not have to be the same as the 342 order in which the "m=" sections occur in the SDP. 344 Section 8 defines the detailed SDP Offer/Answer procedures for the 345 BUNDLE extension. 347 6. SDP 'bundle-only' Attribute 349 This section defines a new SDP media-level attribute [RFC4566], 350 'bundle-only'. 'bundle-only' is a property attribute [RFC4566], and 351 hence has no value. 353 Name: bundle-only 355 Value: N/A 357 Usage Level: media 359 Charset Dependent: no 361 Example: 363 a=bundle-only 365 In order to ensure that an answerer that does not support the BUNDLE 366 extension always rejects a bundled "m=" section, the offerer can 367 assign a zero port value to the "m=" section. According to [RFC3264] 368 an answerer will reject such "m=" section. By including an SDP 369 'bundle-only' attribute in such "m=" section, the offerer can request 370 that the answerer accepts the "m=" section if the answerer supports 371 the Bundle extension, and if the answerer keeps the "m=" section 372 within the associated BUNDLE group. 374 Once the offerer and answerer BUNDLE addresses have been selected, an 375 offerer and answerer only assigns the BUNDLE address to one bundled 376 "m=" section. To every other bundled "m=" section the offerer and 377 answerer assigns a zero port value and includes an SDP 'bundle-only' 378 attribute. 380 The usage of the 'bundle-only' attribute is only defined for a 381 bundled "m=" section with a zero port value, within an offer or 382 answer. Other usage is unspecified. 384 Section 8 defines the detailed SDP Offer/Answer procedures for the 385 'bundle-only' attribute. 387 7. SDP Information Considerations 389 This section describes restrictions associated with the usage of SDP 390 parameters within a BUNDLE group. It also describes, when parameter 391 and attribute values have been assigned to each bundled "m=" section, 392 how to calculate a value for the whole BUNDLE group. 394 7.1. Connection Data (c=) 396 The "c=" line nettype value [RFC4566] associated with a bundled "m=" 397 section MUST be 'IN'. 399 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" 400 section MUST be 'IP4' or 'IP6'. The same value MUST be associated 401 with each "m=" section. 403 NOTE: Extensions to this specification can specify usage of the 404 BUNDLE mechanism for other nettype and addrtype values than the ones 405 listed above. 407 7.2. Bandwidth (b=) 409 An offerer and answerer MUST use the rules and restrictions defined 410 in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP 411 bandwidth (b=) line with bundled "m=" section. 413 8. SDP Offer/Answer Procedures 415 This section describes the SDP Offer/Answer [RFC3264] procedures for: 417 o Negotiating a BUNDLE group; and 419 o Selecting the BUNDLE addresses (offerer BUNDLE address and 420 answerer BUNDLE address); and 422 o Adding an "m=" section to a BUNDLE group; and 424 o Moving an "m=" section out of a BUNDLE group; and 426 o Disabling an "m=" section within a BUNDLE group. 428 The generic rules and procedures defined in [RFC3264] and [RFC5888] 429 also apply to the BUNDLE extension. For example, if an offer is 430 rejected by the answerer, the previously negotiated SDP parameters 431 and characteristics (including those associated with a BUNDLE group) 432 apply. Hence, if an offerer generates an offer in which the offerer 433 wants to create a BUNDLE group, and the answerer rejects the offer, 434 the BUNDLE group is not created. 436 The procedures in this section are independent of the media type or 437 "m=" line proto value assigned to a bundled "m=" section. Section 10 438 defines additional considerations for RTP based media. Section 6 439 defines additional considerations for the usage of the SDP 'bundle- 440 only' attribute. Section 11 defines additional considerations for 441 the usage of Interactive Connectivity Establishment (ICE) 442 [I-D.ietf-ice-rfc5245bis] mechanism. 444 SDP offers and answers can contain multiple BUNDLE groups. The 445 procedures in this section apply independently to a given BUNDLE 446 group. 448 8.1. Mux Category Considerations 450 When a BUNDLE group is initially negotiated, and a unique address is 451 assigned to each bundled "m=" section (excluding any bundle-only "m=" 452 section) in the initial offer Section 8.2, IDENTICAL and TRANSPORT 453 mux category SDP attributes MUST explicitly included in each bundled 454 "m=" section (excluding any bundle-only "m=" secctions). 456 When an offerer or answerer includes SDP attributes in bundled "m=" 457 sections within a BUNDLE group for which the offerer and answerer 458 BUNDLE addresses have been selected, IDENTICAL and TRANSPORT mux 459 category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are only 460 included in the "m=" section represented by the BUNDLE-tag in the 461 offer or answer. The SDP attribute values are implicitly applied to 462 each bundled "m=" section (including any bundle-only "m=" section). 463 The offerer and answerer MUST NOT include such SDP attributes in any 464 other bundled "m=" section. 466 The semantics of some SDP attributes only apply to specific types of 467 media. For example, the semantics of the SDP 'rtcp-mux' and SDP 468 'rtcp-mux-only' attributes only apply to "m=" sections describing 469 RTP-based media. However, as described in Section 8.1, there are 470 cases where IDENTICAL and TRANSPORT mux category SDP attributes are 471 only included in the "m=" sections represented by the BUNDLE-tag. 472 That means that media-specific IDENTICAL and TRANSPORT mux category 473 attributes can be included in an "m=" section associated with another 474 type of media. 476 8.2. Generating the Initial SDP Offer 478 When an offerer generates an initial offer, in order to negotiate a 479 BUNDLE group, it MUST: 481 o Assign a unique address to each "m=" section within the offer, 482 following the procedures in [RFC3264], excluding any bundle-only 483 "m=" sections (see below); and 485 o Include an SDP 'group:BUNDLE' attribute in the offer; and 487 o Place the identification-tag of each bundled "m=" section in the 488 SDP 'group:BUNDLE' attribute identification-tag list; and 490 o Indicate which unique address the offerer suggests as the offerer 491 BUNDLE address [Section 8.2.1]. 493 If the offerer wants to request that the answerer accepts a given 494 bundled "m=" section only if the answerer keeps the "m=" section 495 within the BUNDLE group, the offerer MUST: 497 o Include an SDP 'bundle-only' attribute [Section 8.2.1] in the "m=" 498 secction; and 500 o Assign a zero port value to the "m=" section. 502 NOTE: If the offerer assigns a zero port value to an "m=" section, 503 but does not include an SDP 'bundle-only' attribute in the "m=" 504 section, it is an indication that the offerer wants to disable the 505 "m=" section [Section 8.5.4]. 507 [Section 18.1] shows an example of an initial offer. 509 8.2.1. Suggesting the offerer BUNDLE address 511 In the offer, the address:port combination assigned to the "m=" 512 section represented by the offerer BUNDLE-tag indicates offerer 513 BUNDLE address, i.e., the address:port combination that the offerer 514 suggests for sending and receiving bundled media. 516 The offerer BUNDLE-tag MUST NOT represent a bundle-only "m=" section. 517 Hence, the offer MUST contain at least one bundle "m=" section with a 518 unique address (and a non-zero port value). 520 8.2.2. Example: Initial SDP Offer 522 The example shows an initial SDP offer. The offer includes two "m=" 523 section in the SDP, and suggests that both are included in a BUNDLE 524 group. The audio "m=" section is associated with the offerer BUNDLE- 525 tag (placed first in the SDP group:BUNDLE attribute identification-id 526 list). 528 SDP Offer 530 v=0 531 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 532 s= 533 c=IN IP4 atlanta.example.com 534 t=0 0 535 a=group:BUNDLE foo bar 536 m=audio 10000 RTP/AVP 0 8 97 537 b=AS:200 538 a=mid:foo 539 a=rtcp-mux 540 a=rtpmap:0 PCMU/8000 541 a=rtpmap:8 PCMA/8000 542 a=rtpmap:97 iLBC/8000 543 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 544 m=video 10002 RTP/AVP 31 32 545 b=AS:1000 546 a=mid:bar 547 a=rtpmap:31 H261/90000 548 a=rtpmap:32 MPV/90000 549 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 551 8.3. Generating the SDP Answer 553 When an answerer generates an answer that contains a BUNDLE group, 554 the following general SDP grouping framework restrictions, defined in 555 [RFC5888], also apply to the BUNDLE group: 557 o The answerer MUST NOT include a BUNDLE group in the answer, unless 558 the offerer requested the BUNDLE group to be negotiated in the 559 corresponding offer; and 561 o The answerer MUST NOT include an "m=" section within a BUNDLE 562 group, unless the offerer requested the "m=" section to be within 563 that BUNDLE group in the corresponding offer. 565 o If the answer contains multiple BUNDLE groups, the answerer MUST 566 NOT move an "m=" section from one BUNDLE group to another. 568 If the answer contains a BUNDLE group, the answerer MUST: 570 o Select an offerer BUNDLE Address [Section 8.3.1]; and 572 o Select an answerer BUNDLE Address [Section 8.3.2]; 574 The answerer is allowed to select a new answerer BUNDLE address each 575 time it generates an answer to an offer. 577 If the answerer does not want to keep an "m=" section within a BUNDLE 578 group, it MUST: 580 o Move the "m=" section out of the BUNDLE group [Section 8.3.3]; or 582 o Reject the "m=" section [Section 8.3.4]; 584 When the answerer creates the answer, it selects the offerer BUNDLE 585 address [Section 8.3.1] and the answerer BUNDLE address 586 [Section 8.3.2]. The answerer then assigns the answerer BUNDLE 587 address to the bundled "m=" section represented by the answerer 588 BUNDLE-tag. In every other bundled "m=" section the answerer 589 includes an SDP 'bundle-only' attribute and assigns a zero port value 590 to the "m=" section. 592 If the answerer does not want to keep a bundle-only "m=" section 593 within the BUNDLE group, it MUST reject the "m=" section 594 [Section 8.3.4]. 596 NOTE: If a bundled "m=" section in an offer contains a zero port 597 value, but the "m=" section does not contain an SDP 'bundle-only' 598 attribute, it is an indication that the offerer wants to disable the 599 "m=" section [Section 8.5.4]. 601 8.3.1. Answerer Selection of Offerer Bundle Address 603 In an offer, the bundled "m=" section represented by the offerer 604 BUNDLE-tag contains the suggested offerer BUNDLE address, i.e, the 605 address:port combination that the offerer wants to use for sending 606 and receiving bundled media [Section 8.2.1]. The answerer MUST check 607 whether that "m=" section fulfils the following criteria: 609 o The answerer will not move the "m=" section out of the BUNDLE 610 group [Section 8.3.3]; and 612 o The answerer will not reject the "m=" section [Section 8.3.4]; and 613 o The "m=" section does not contain a zero port value. 615 If all of the criteria above are fulfilled, the answerer MUST select 616 the suggested offerer BUNDLE address. 618 If one or more of the criteria are not fulfilled, the answerer MUST 619 pick the next identification-tag in the identification-tag list in 620 the offer, and perform the same criteria check for the "m=" section 621 represented by that identification-tag. If there are no more 622 identification-tags in the identification-tag list, the answerer MUST 623 NOT create the BUNDLE group. Unless the answerer rejects the whole 624 offer, the answerer MUST apply the answerer procedures for moving an 625 "m=" section out of a BUNDLE group [Section 8.3.3] or rejecting an 626 "m=" section within a BUNDLE group [Section 8.3.4] to every bundled 627 "m=" section in the offer when creating the answer. 629 [Section 18.1] shows an example of an offerer BUNDLE address 630 selection. 632 8.3.2. Answerer Selection of Answerer BUNDLE Address 634 When the answerer selects a BUNDLE address for itself (answerer 635 BUNDLE address), the answerer MUST assign the answerer BUNDLE address 636 to the "m=" section that contains the selected offerer BUNDLE address 637 in the corresponding offer. The answerer BUNDLE-tag represents that 638 "m=" section in the answer. To every other bundled "m=" section the 639 answerer MUST assign a zero port value and include an SDP 'bundle- 640 only' attribute. 642 The answerer MUST NOT assign an answerer BUNDLE address to an "m=" 643 section that is not within the BUNDLE group, or to an "m=" section 644 that is within another BUNDLE group. 646 [Section 18.1] shows an example of an answerer BUNDLE address 647 selection. 649 8.3.3. Moving A Media Description Out Of A BUNDLE Group 651 When an answerer wants to move a bundled "m=" section out of a BUNDLE 652 group in an answer, it MUST first check the following criteria: 654 o In the corresponding offer, an offerer BUNDLE address (previously 655 selected [Section 8.3.1] or new suggested [Section 8.5.1]) has 656 been assigned to the "m=" section by the offerer; or 658 o In the corresponding offer, the "m=" section contains an SDP 659 'bundle-only' attribute and a zero port value. 661 If either criteria above is fulfilled, the answerer can not not move 662 the "m=" section out of the BUNDLE group in the answer. The answerer 663 can either reject the whole offer, or keep the "m=" section within 664 the BUNDLE group in the answer and later create an offer where the 665 "m=" section is moved out of the BUNDLE group [Section 8.5.3] 667 When the answerer generates an answer, in which it removes a bundled 668 "m=" section out of a BUNDLE group, the answerer: 670 o MUST assign a unique address to the "m=" section; and 672 o MUST NOT place the identification-tag associated with the "m=" 673 section in the SDP 'group:BUNDLE' attribute identification-tag 674 list associated with the BUNDLE group; and 676 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 677 section. 679 An answerer MUST NOT move an "m=" section from one BUNDLE group to 680 another within an answer. If the answerer wants to move an "m=" 681 section from one BUNDLE group to another it MUST first move the 682 BUNDLE group out of the current BUNDLE group, and then generate an 683 offer where the "m=" section is added to another BUNDLE group 684 [Section 8.5.2]. 686 8.3.4. Rejecting A Media Description In A BUNDLE Group 688 When an answerer wants to reject a bundled "m=" section in an answer, 689 it MUST first check the following criteria: 691 o In the corresponding offer, an offerer BUNDLE address (previously 692 selected [Section 8.3.1] or new suggested [Section 8.5.1]) has 693 been assigned to the "m=" section by the offerer. 695 If either criteria above is fulfilled, the answerer can not not 696 reject the "m=" section in the answer. The answerer can either 697 reject the whole offer, or keep the "m=" section within the BUNDLE 698 group in the answer and later create an offer where the "m=" section 699 is disabled of the BUNDLE group [Section 8.5.4] 701 When an answerer generates an answer, in which it rejects a bundled 702 "m=" section, the answerer: 704 o MUST assign a zero port value to the "m=" section, according to 705 the procedures in [RFC3264]; and 707 o MUST NOT place the identification-tag associated with the "m=" 708 section in the SDP 'group:BUNDLE' attribute identification-tag 709 list associated with the BUNDLE group; and 711 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 712 section. 714 8.3.5. Example: SDP Answer 716 The example shows an SDP answer, based on the SDP offer in 717 [Section 8.2.2]. The answers accepts both "m=" sections within the 718 BUNDLE group. The answerer assigns the answerer BUNDLE address to 719 the "m=" section represented by the answerer BUNDLE-tag. The 720 answerer assigns a zero port value and an SDP 'bundle-only' attribute 721 to the other bundled "m=" section. 723 SDP Answer 725 v=0 726 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 727 s= 728 c=IN IP4 biloxi.example.com 729 t=0 0 730 a=group:BUNDLE foo bar 731 m=audio 20000 RTP/AVP 0 732 b=AS:200 733 a=mid:foo 734 a=rtcp-mux 735 a=rtpmap:0 PCMU/8000 736 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 737 m=video 0 RTP/AVP 32 738 b=AS:1000 739 a=mid:bar 740 a=bundle-only 741 a=rtpmap:32 MPV/90000 742 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 744 8.4. Offerer Processing of the SDP Answer 746 When an offerer receives an answer, if the answer contains a BUNDLE 747 group, the offerer MUST check that any bundled "m=" section in the 748 answer was indicated as bundled in the corresponding offer. If there 749 is no mismatch, the offerer MUST use the offerer BUNDLE address, 750 selected by the answerer [Section 8.3.1], as the address for each 751 bundled "m=" section. 753 NOTE: As the answerer might reject one or more bundled "m=" sections, 754 or move a bundled "m=" section out of a BUNDLE group, each bundled 755 "m=" section in the offer might not be indicated as bundled in the 756 answer. 758 If the answer does not contain a BUNDLE group, the offerer MUST 759 process the answer as a normal answer. 761 8.5. Modifying the Session 763 When an offerer generates a subsequent offer (i.e., a BUNDLE group 764 has previously been negotiated), it MUST assign the previously 765 selected offer BUNDLE address [Section 8.3.1], or a new suggested 766 offerer BUNDLE address [Section 8.5.1], to exactly one "m=" section 767 within the BUNDLE group. 769 The offerer MUST NOT assign an offerer BUNDLE address (previously 770 selected [Section 8.3.1] or new suggested [Section 8.5.1]) to a 771 bundled "m=" section if: 773 o The offerer wants to move the bundled "m=" section out of the 774 BUNDLE group [Section 8.5.3]; or 776 o The offerer wants to disable the bundled "m=" section 777 [Section 8.5.4]. 779 To every other "m=" section within the BUNDLE group, the offerer MUST 780 assign a zero port value and an SDP 'bundle-only' attribute. 782 When the offerer generates a subsequent offer, the offerer BUNDLE-tag 783 MUST represent the bundled "m=" section to which the offerer BUNDLE 784 address (previously negotiated or new suggested) has been assigned. 786 8.5.1. Suggesting a new offerer BUNDLE address 788 When an offerer generates an offer, in which it suggests a new 789 offerer BUNDLE address [Section 8.2.1], the offerer MUST: 791 o Assign the new suggested offerer BUNDLE address to exactly one 792 "m=" section within the BUNDLE group; and 794 o Assign a zero port value and an SDP 'bundle-only' attribute to 795 every other "m=" section within the BUNDLE group. 797 8.5.2. Adding a media description to a BUNDLE group 799 When an offerer generates an offer, in which it wants to add a 800 bundled "m=" section, the offerer MUST: 802 o Assign the offerer BUNDLE address (previously selected 803 [Section 8.3.1] or new suggested [Section 8.5.1]) to the added 804 "m=" section; or 806 o Assign a zero port value and an SDP 'bundle-only' attribute to the 807 added "m=" section (in this case the offerer BUNDLE address is 808 assigned to another "m=" section within the BUNDLE group). 810 In addition, the offerer MUST place the identification-tag associated 811 with the added "m=" section in the SDP 'group:BUNDLE' attribute 812 identification-tag list associated with the BUNDLE group 813 [Section 8.2.1]. 815 NOTE: If the offerer also wants to suggest a new offerer BUNDLE 816 address to the BUNDLE group, the offerer can assign the new suggested 817 offerer BUNDLE address either to the added "m=" section, or to some 818 other "m=" section within the BUNDLE group [Section 8.5.1]. 820 [Section 18.3] shows an example where an offerer sends an offer in 821 order to add a bundled "m=" section to a BUNDLE group. 823 8.5.3. Moving A Media Description Out Of A BUNDLE Group 825 When an offerer generates an offer, in which it wants to move a 826 bundled "m=" section out of a BUNDLE group, the offerer: 828 o MUST assign a unique address to the "m=" section; and 830 o MUST NOT place the identification-tag associated with the "m=" 831 section in the SDP 'group:BUNDLE' attribute identification-tag 832 list associated with the BUNDLE group; and 834 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 835 section. 837 An offerer MUST NOT move an "m=" section from one BUNDLE group to 838 another within a single offer. If the offerer wants to move an "m=" 839 section from one BUNDLE group to another it MUST first move the 840 BUNDLE group out of the current BUNDLE group, and then generate a 841 second offer where the "m=" section is added to another BUNDLE group 842 [Section 8.5.2]. 844 [Section 18.4] shows an example of an offer for moving an "m=" 845 section out of a BUNDLE group. 847 8.5.4. Disabling A Media Description In A BUNDLE Group 849 When an offerer generates an offer, in which it wants to disable a 850 bundled "m=" section, the offerer: 852 o MUST assign a zero port value to the "m=" section, following the 853 procedures in [RFC4566]; and 855 o MUST NOT place the identification-tag associated with the "m=" 856 section in the SDP 'group:BUNDLE' attribute identification-tag 857 list associated with the BUNDLE group; and 859 o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" 860 section. 862 [Section 18.5] shows an example of an offer for disabling an "m=" 863 section within a BUNDLE group. 865 9. Protocol Identification 867 Each "m=" section within a BUNDLE group MUST use the same transport- 868 layer protocol. If bundled "m=" sections use different protocols on 869 top of the transport-layer protocol, there MUST exist a publicly 870 available specification which describes a mechanism, for this 871 particular protocol combination, how to associate received data with 872 the correct protocol. 874 In addition, if received data can be associated with more than one 875 bundled "m=" section, there MUST exist a publicly available 876 specification which describes a mechanism for associating the 877 received data with the correct "m=" section. 879 This document describes a mechanism to identify the protocol of 880 received data among the STUN, DTLS and SRTP protocols (in any 881 combination), when UDP is used as transport-layer protocol, but does 882 not describe how to identify different protocols transported on DTLS. 883 While the mechanism is generally applicable to other protocols and 884 transport-layer protocols, any such use requires further 885 specification around how to multiplex multiple protocols on a given 886 transport-layer protocol, and how to associate received data with the 887 correct protocols. 889 9.1. STUN, DTLS, SRTP 891 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 892 protocol of a received packet among the STUN, Datagram Transport 893 Layer Security (DTLS) and SRTP protocols (in any combination). If an 894 offer or answer includes bundled "m=" section that represent these 895 protocols, the offerer or answerer MUST support the mechanism 896 described in [RFC5764], and no explicit negotiation is required in 897 order to indicate support and usage of the mechanism. 899 [RFC5764] does not describe how to identify different protocols 900 transported on DTLS, only how to identify the DTLS protocol itself. 901 If multiple protocols are transported on DTLS, there MUST exist a 902 specification describing a mechanism for identifying each individual 903 protocol. In addition, if a received DTLS packet can be associated 904 with more than one "m=" section, there MUST exist a specification 905 which describes a mechanism for associating the received DTLS packet 906 with the correct "m=" section. 908 [Section 10.2] describes how to associate the packets in a received 909 SRTP stream with the correct "m=" section. 911 10. RTP Considerations 913 10.1. Single RTP Session 915 All RTP-based media within a single BUNDLE group belong to a single 916 RTP session [RFC3550]. 918 Since a single BUNDLE transport is used for sending and receiving 919 bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for 920 RTP-based bundled media. 922 Since a single RTP session is used for each BUNDLE group, all "m=" 923 sections representing RTP-based media within a BUNDLE group will 924 share a single SSRC numbering space [RFC3550]. 926 The following rules and restrictions apply for a single RTP session: 928 o A specific payload type value can be used in multiple bundled "m=" 929 sections only if each codec associated with the payload type 930 number shares an identical codec configuration [Section 10.1.1]. 932 o The proto value in each bundled RTP-based "m=" section MUST be 933 identical (e.g. RTP/AVPF). 935 o The RTP MID header extension MUST be enabled, by including an SDP 936 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 937 hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section 938 in every offer and answer. 940 o A given SSRC MUST NOT transmit RTP packets using payload types 941 that originate from different bundled "m=" sections. 943 NOTE: The last bullet above is to avoid sending multiple media types 944 from the same SSRC. If transmission of multiple media types are done 945 with time overlap, RTP and RTCP fail to function. Even if done in 946 proper sequence this causes RTP Timestamp rate switching issues 947 [RFC7160]. However, once an SSRC has left the RTP session (by 948 sending an RTCP BYE packet), that SSRC can be reused by another 949 source (possibly associated with a different bundled "m=" section) 950 after a delay of 5 RTCP reporting intervals (the delay is to ensure 951 the SSRC has timed out, in case the RTCP BYE packet was lost 952 [RFC3550]). 954 10.1.1. Payload Type (PT) Value Reuse 956 Multiple bundled "m=" section might describe RTP based media. As all 957 RTP based media associated with a BUNDLE group belong to the same RTP 958 session, in order for a given payload type value to be used inside 959 more than one bundled "m=" section, all codecs associated with the 960 payload type number MUST share an identical codec configuration. 961 This means that the codecs MUST share the same media type, encoding 962 name, clock rate and any parameter that can affect the codec 963 configuration and packetization. 964 [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose 965 attribute values must be identical for all codecs that use the same 966 payload type value. 968 10.2. Associating RTP/RTCP Streams With Correct SDP Media Description 970 NOTE: The text in this section is copied from Appendix B of JSEP. 971 The community has not yet agreed on the text. 973 As described in [RFC3550], RTP packets are associated with RTP 974 streams [RFC7656]. Each RTP stream is identified by an SSRC value, 975 and each RTP packet includes an SSRC field that is used to associate 976 the packet with the correct RTP stream. RTCP packets also use SSRCs 977 to identify which RTP streams the packet relates to. However, a RTCP 978 packet can contain multiple SSRC fields, in the course of providing 979 feedback or reports on different RTP streams, and therefore can be 980 associated with multiple such streams. 982 In order to be able to process received RTP/RTCP packets correctly, 983 it must be possible to associate an RTP stream with the correct "m=" 984 section, as the "m=" section and SDP attributes associated with the 985 "m=" section contains information needed to process the packets. 987 As all RTP streams associated with a BUNDLE group use the same 988 transport for sending and receiving RTP/RTCP packets, the local 989 address:port combination part of the transport cannot be used to 990 associate an RTP stream with the correct "m=" section. In addition, 991 multiple RTP streams might be associated with the same "m=" section. 993 An offerer and answerer can inform each other which SSRC values they 994 will use for an RTP stream by using the SDP 'ssrc' attribute 995 [RFC5576]. However, an offerer will not know which SSRC values the 996 answerer will use until the offerer has received the answer providing 997 that information. Due to this, before the offerer has received the 998 answer, the offerer will not be able to associate an RTP stream with 999 the correct "m=" section using the SSRC value associated with the RTP 1000 stream. In addition, the offerer and answerer may start using new 1001 SSRC values mid-session, without informing each other using the SDP 1002 'ssrc' attribute. 1004 In order for an offerer and answerer to always be able to associate 1005 an RTP stream with the correct "m=" section, the offerer and answerer 1006 using the BUNDLE extension MUST support the mechanism defined in 1007 Section 15, where the offerer and answerer insert the identification- 1008 tag associated with an "m=" section (provided by the remote peer) 1009 into RTP and RTCP packets associated with a BUNDLE group. 1011 When using this mechanism, the mapping from an SSRC to an 1012 identification-tag is carried in RTP header extensions or RTCP SDES 1013 packets, as specified in Section 15. Since a compound RTCP packet 1014 can contain multiple RTCP SDES packets, and each RTCP SDES packet can 1015 contain multiple chunks, a single RTCP packet can contain several 1016 SSRC to identification-tag mappings. The offerer and answerer 1017 maintain tables used for routing that are updated each time an RTP/ 1018 RTCP packet contains new information that affects how packets should 1019 be routed. 1021 However, some implementations of may not include this identification- 1022 tag in their RTP and RTCP traffic when using the BUNDLE mechanism, 1023 and instead use a payload type based mechanism to associate RTP 1024 streams with SDP "m=" sections. In this situation, each "m=" section 1025 MUST use unique payload type values, in order for the payload type to 1026 be a reliable indicator of the relevant "m=" section for the RTP 1027 stream. Note that when using the payload type to associate RTP 1028 streams with "m=" sections an RTP stream, identified by SSRC, will be 1029 mapped to an "m=" section when the first packet of that RTP stream is 1030 received, and the mapping will not be changed even if the payload 1031 type used by that RTP stream changes. In other words, the SSRC 1032 cannot to "move" to a different "m=" section simply by changing the 1033 payload type. 1035 Applications can implement RTP stacks in many different ways. The 1036 algorithm below details one way that RTP streams can be associated 1037 with "m=" sections, but is not meant to be prescriptive about exactly 1038 how an RTP stack needs to be implemented. Applications MAY use any 1039 algorithm that achieves equivalent results to those described in the 1040 algorithm below. 1042 To prepare to associate RTP streams with the correct "m=" section, 1043 the following steps MUST be followed for each BUNDLE group. 1045 Construct a table mapping MID to "m=" section for each "m=" 1046 section in this BUNDLE group. Note that an "m=" section may only 1047 have one MID. 1049 Construct a table mapping SSRCs of incoming RTP streams to "m=" 1050 section for each "m=" section in this BUNDLE group and for each 1051 SSRC configured for receiving in that "m=" section. 1053 Construct a table mapping the SSRC of each outgoing RTP stream to 1054 "m=" section for each "m=" section in this BUNDLE group and for 1055 each SSRC configured for sending in that "m=" section. 1057 Construct a table mapping payload type to "m=" section for each 1058 "m=" section in the BUNDLE group and for each payload type 1059 configured for receiving in that "m=" section. If any payload 1060 type is configured for receiving in more than one "m=" section in 1061 the BUNDLE group, do not it include it in the table, as it cannot 1062 be used to uniquely identify a "m=" section. 1064 Note that for each of these tables, there can only be one mapping 1065 for any given key (MID, SSRC, or PT). In other words, the tables 1066 are not multimaps. 1068 As "m=" sections are added or removed from the BUNDLE groups, or 1069 their configurations are changed, the tables above MUST also be 1070 updated. 1072 When an RTP packet is received, it MUST be delivered to the RTP 1073 stream corresponding to its SSRC. That RTP stream MUST then be 1074 associated with the correct "m=" section within a BUNDLE group, for 1075 additional processing, according to the following steps. 1077 If the MID associated with the RTP stream is not in the table 1078 mapping MID to "m=" section, then the RTP stream is not decoded 1079 and the payload data is discarded. 1081 If the packet has a MID, and the packet's extended sequence number 1082 is greater than that of the last MID update, as discussed in 1083 [RFC7941], Section 4.2.6, update the MID associated with the RTP 1084 stream to match the MID carried in the RTP packet, then update the 1085 mapping tables to include an entry that maps the SSRC of that RTP 1086 stream to the "m=" section for that MID. 1088 If the SSRC of the RTP stream is in the incoming SSRC mapping 1089 table, check that the payload type used by the RTP stream matches 1090 a payload type included on the matching "m=" section. If so, 1091 associate the RTP stream with that "m=" section. Otherwise, the 1092 RTP stream is not decoded and the payload data is discarded. 1094 If the payload type used by the RTP stream is in the payload type 1095 table, update the incoming SSRC mapping table to include an entry 1096 that maps the RTP stream's SSRC to the "m=" section for that 1097 payload type. Associate the RTP stream with the corresponding 1098 "m=" section. 1100 Otherwise, mark the RTP stream as not for decoding and discard the 1101 payload. 1103 If the RTP packet contains one of more contributing source (CSRC) 1104 identifiers, then each CSRC is looked up in the incoming SSRC table 1105 and a copy of the RTP packet is associated with the corresponding 1106 "m=" section for additional processing. 1108 For each RTCP packet received (including each RTCP packet that is 1109 part of a compound RTCP packet), the packet is processed as usual by 1110 the RTP layer, then is passed to the "m=" sections corresponding to 1111 the RTP streams it contains information about for additional 1112 processing. This routing is type-dependent, as each kind of RTCP 1113 packet has its own mechanism for associating it with the relevant RTP 1114 streams. 1116 RTCP packets for which no appropriate "m=" section can be identified 1117 MUST be processed as usual by the RTP layer, updating the metadata 1118 associated with the corresponding RTP streams, but are not passed to 1119 any "m=" section. This situation can occur with certain multiparty 1120 RTP topologies, or when RTCP packets are sent containing a subset of 1121 the SDES information. 1123 Rules for additional processing of the various types of RTCP packets 1124 are explained below. 1126 If the RTCP packet is of type SDES, for each chunk in the packet 1127 whose SSRC is found in the incoming SSRC table, deliver a copy of 1128 the SDES packet to the "m=" section associated with that SSRC. In 1129 addition, for any SDES MID items contained in these chunks, if the 1130 MID is found in the table mapping MID to "m=" section, update the 1131 incoming SSRC table to include an entry that maps the RTP stream 1132 associated with chunk's SSRC to the "m=" section associated with 1133 that MID, unless the packet is older than the packet that most 1134 recently updated the mapping for this SSRC, as discussed in 1135 [RFC7941], Section 4.2.6. 1137 Note that if an SDES packet is received as part of a compound RTCP 1138 packet, the SSRC to "m=" section mapping may not exist until the 1139 SDES packet is handled (e.g., in the case where RTCP for a source 1140 is received before any RTP packets). Therefore, when processing a 1141 compound packet, any contained SDES packet MUST be handled first. 1142 Note that this is a backwards change from [RFC3550] Section 6.1, 1143 which states that "Each individual RTCP packet in the compound 1144 packet may be processed independently with no requirements upon 1145 the order or combination of packets". 1147 If the RTCP packet is of type BYE, it indicates that the RTP 1148 streams referenced in the packet are ending. Therefore, for each 1149 SSRC indicated in the packet that is found in the incoming SSRC 1150 table, first deliver a copy of the BYE packet to the "m=" section 1151 associated with that SSRC, but then remove the entry for that SSRC 1152 from the incoming SSRC table after an appropriate delay to account 1153 for "straggler packets", as specified in [RFC3550], Section 6.2.1. 1155 If the RTCP packet is of type SR or RR, for each report block in 1156 the report whose "SSRC of source" is found in the outgoing SSRC 1157 table, deliver a copy of the SR or RR packet to the "m=" section 1158 associated with that SSRC. In addition, if the packet is of type 1159 SR, and the sender SSRC for the packet is found in the incoming 1160 SSRC table, deliver a copy of the SR packet to the "m=" section 1161 associated with that SSRC. 1163 If the implementation supports RTCP XR and the packet is of type 1164 XR, as defined in [RFC3611], for each report block in the report 1165 whose "SSRC of source" is is found in the outgoing SSRC table, 1166 deliver a copy of the XR packet to the "m=" section associated 1167 with that SSRC. In addition, if the sender SSRC for the packet is 1168 found in the incoming SSRC table, deliver a copy of the XR packet 1169 to the "m=" section associated with that SSRC. 1171 If the RTCP packet is a feedback message of type RTPFB or PSFB, as 1172 defined in [RFC4585], it will contain a media source SSRC, and 1173 this SSRC is used for routing certain subtypes of feedback 1174 messages. However, several subtypes of PSFB messages include 1175 target SSRC(s) in a section called Feedback Control Information 1176 (FCI). For these messages, the target SSRC(s) are used for 1177 routing. 1179 If the RTCP packet is a feedback packet that does not include 1180 target SSRCs in its FCI section, and the media source SSRC is 1181 found in the outgoing SSRC table, deliver the feedback packet to 1182 the "m=" section associated with that SSRC. RTPFB and PSFB types 1183 that are handled in this way include: 1185 Generic NACK: [RFC4585] (PT=RTPFB, FMT=1). 1187 Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1). 1189 Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2). 1191 Reference Picture Selection Indication (RPSI): [RFC4585] 1192 (PT=PSFB, FMT=3). 1194 If the RTCP packet is a feedback message that does include target 1195 SSRC(s) in its FCI section, it can either be a request or a 1196 notification. Requests reference a RTP stream that is being sent 1197 by the message recipient, whereas notifications are responses to 1198 an earlier request, and therefore reference a RTP stream that is 1199 being received by the message recipient. 1201 If the RTCP packet is a feedback request that includes target 1202 SSRC(s), for each target SSRC that is found in the outgoing SSRC 1203 table, deliver a copy of the RTCP packet to the "m=" section 1204 associated with that SSRC. PSFB types that are handled in this 1205 way include: 1207 Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). 1209 Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, 1210 FMT=5). 1212 H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, 1213 FMT=7). 1215 Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, 1216 FMT=TBD). 1218 If the RTCP packet is a feedback notification that include target 1219 SSRC(s), for each target SSRC that is found in the incoming SSRC 1220 table, deliver a copy of the RTCP packet to the "m=" section 1221 associated with the RTP stream with matching SSRC. PSFB types 1222 that are handled in this way include: 1224 Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] 1225 (PT=PSFB, FMT=6). This message is a notification in response 1226 to a prior TSTR. 1228 If the RTCP packet is of type APP, then it is handled in an 1229 application specific manner. If the application does not 1230 recognise the APP packet, then it MUST be discarded. 1232 10.3. RTP/RTCP Multiplexing 1234 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 1235 multiplexing [RFC5761] for the RTP-based media specified by the 1236 BUNDLE group. 1238 When RTP/RTCP multiplexing is enabled, the same transport will be 1239 used for both RTP packets and RTCP packets associated with the BUNDLE 1240 group. 1242 10.3.1. SDP Offer/Answer Procedures 1244 This section describes how an offerer and answerer use the SDP 'rtcp- 1245 mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute 1246 [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP 1247 multiplexing for RTP-based media associated with a BUNDLE group. 1249 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] of the SDP 1250 'rtcp-mux' and 'rtcp-mux-only' attributes is IDENTICAL. Section 8.1 1251 describes the details regarding which bundled "m=" sections an 1252 offerer and answerer associates the attributes with. 1254 RTP/RTCP multiplexing only applies to RTP-based media. However, as 1255 described in Section 8.1, within a BUNDLE group the SDP 'rtcp-mux' 1256 and SDP 'rtcp-mux-only' attributes might be included in a non-RTP- 1257 based bundled "m=" section. 1259 10.3.1.1. Generating the Initial SDP Offer 1261 When an offerer generates an initial offer, if the offer contains one 1262 or more RTP-based bundled "m=" sections (or, if there is a chance 1263 that RTP-based "m=" sections will later be added to the BUNDLE 1264 group), the offerer MUST include an SDP 'rtcp-mux' attribute 1265 [RFC5761] in one or more "m=" sections, following the procedures for 1266 IDENTICAL mux category attributes in Section 8.1. In addition, the 1267 offerer MAY include an SDP 'rtcp-mux-only' attribute 1268 [I-D.ietf-mmusic-mux-exclusive] in the same "m=" section. 1270 NOTE: Whether the offerer associates the SDP 'rtcp-mux-only' 1271 attribute depends on whether the offerer supports fallback to usage 1272 of a separate port for RTCP in case the answerer moves one or more 1273 RTP-based "m=" section out of the BUNDLE group in the answer. 1275 NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in one or 1276 more bundled "m=" sections, but does not include an SDP 'rtcp-mux- 1277 only' attribute, the offerer can also include an SDP 'rtcp' attribute 1278 [RFC3605] in one or more RTP-based "m=" sections in order to provide 1279 a fallback port for RTCP, as described in [RFC5761]. However, the 1280 fallback port will only be used for RTP-based "m=" sections moved out 1281 of the BUNDLE group by the answerer. 1283 In the initial offer, the address:port combination for RTCP MUST be 1284 unique in each bundled RTP-based "m=" section (excluding a bundle- 1285 only "m=" section), similar to RTP. 1287 10.3.1.2. Generating the SDP Answer 1289 When an answerer generates an answer, if the answerer supports RTP- 1290 based media, and if a bundled "m=" section in the offer contained an 1291 SDP 'rtcp-mux' attribute, the answerer MUST enable usage of RTP/RTCP 1292 multiplexing, even if there currently are no RTP-based "m=" sections 1293 within the BUNDLE group. The answerer MUST include an SDP 'rtcp-mux' 1294 attribute in "m=" sections within the BUNDLE group in the answer 1295 following the procedures for IDENTICAL mux category attributes in 1296 Section 8.1. In addition, if the "m=" section in the offer contained 1297 an an SDP "rtcp-mux-only" attribute, the answerer MUST include an SDP 1298 "rtcp-mux-only" attribute to the "m=" section in the answer. 1300 If the "m=" section associated with the offerer BUNDLE-tag in the 1301 offer contained an SDP 'rtcp-mux-only' attribute, and if the answerer 1302 moves an RTP-based "m=" section out of the BUNDLE group in the answer 1303 Section 8.3.3, the answerer MUST either include the attribute with in 1304 moved "m=" section (and enable RTP/RTCP multiplexing for the media 1305 associated with the "m=" section), or reject the "m=" section 1306 Section 8.3.4. 1308 The answerer MUST NOT include an SDP 'rtcp' attribute in any "m=" 1309 section within the BUNDLE group in the answer. The answerer will use 1310 the port value of the selected offerer BUNDLE address for sending RTP 1311 and RTCP packets associated with each RTP-based bundled "m=" section 1312 towards the offerer. 1314 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1315 negotiated in a previous offer/answer transaction, the answerer MUST 1316 include an SDP 'rtcp-mux' attribute in the "m=" section associated 1317 with the answerer BUNDLE-tag in the answer. It is not possible to 1318 disable RTP/RTCP multiplexing within a BUNDLE group. 1320 10.3.1.3. Offerer Processing of the SDP Answer 1322 When an offerer receives an answer, if the answerer has accepted the 1323 usage of RTP/RTCP multiplexing (see Section 10.3.1.2), the answerer 1324 follows the procedures for RTP/RTCP multiplexing defined in 1325 [RFC5761]. The offerer will use the port value associated with the 1326 answerer BUNDLE address for sending RTP and RTCP packets associated 1327 with each RTP-based bundled "m=" section towards the answerer. 1329 NOTE: It is considered a protocol error if the answerer has not 1330 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" 1331 sections that the answerer included in the BUNDLE group. 1333 10.3.1.4. Modifying the Session 1335 When an offerer generates a subsequent offer, the offerer MUST 1336 include an SDP 'rtcp-mux' attribute in a bundled "m=" section, 1337 following the procedures for IDENTICAL mux category attributes in 1338 Section 8.1. 1340 If the offerer wants to add a bundled RTP-based "m=" section to the 1341 BUNDLE group, it MAY also include an SDP 'rtcp-mux-only' attribute in 1342 a bundled "m=" section, following the procedures for IDENTICAL mux 1343 category attributes in Section 8.1. This allows the offerer to 1344 mandate RTP/RTCP multiplexing for the added "m=" section (or the "m=" 1345 section to be rejected by the answerer) even if the answerer does not 1346 accept the "m=" section within the BUNDLE group. 1348 11. ICE Considerations 1350 This section describes how to use the BUNDLE grouping extension 1351 together with the Interactive Connectivity Establishment (ICE) 1352 mechanism [I-D.ietf-ice-rfc5245bis]. 1354 The generic procedures for negotiating usage of ICE using SDP, 1355 defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE 1356 with BUNDLE, with the following exceptions: 1358 o When the BUNDLE transport has been established, ICE connectivity 1359 checks and keep-alives only need to be performed for the BUNDLE 1360 transport, instead of per individual "m=" section within the 1361 BUNDLE group. 1363 o In an offer, if the offer assigns a unique address to one or more 1364 bundled "m=" sections (excluding any bundle-only "m=" section), 1365 the offerer MUST include ICE-related media-level attributes in 1366 each of those "m=" sections. If the offerer assigns an offerer 1367 BUNDLE address (previously selected [Section 8.3.1] or new 1368 suggested [Section 8.5.1]) to a bundled "m=" section (the "m=" 1369 section represented by the offerer BUNDLE-tag), the offerer only 1370 includes ICE-related media-level SDP attributes in that "m=" 1371 section, following the procedures in Section 8.1. 1373 o In an answer, the answerer only includes ICE-related media-level 1374 SDP attributes in the bundled "m=" section to which the answerer 1375 has assigned the answerer BUNDLE address (the "m=" section 1376 represented by the answerer BUNDLE-tag), following the procedures 1377 in Section 8.1. 1379 Initially, before ICE has produced a candidate pair that will be used 1380 for media, there might by multiple transports established (if 1381 multiple candidate pairs are tested). Once ICE has produced a 1382 transport that will be used for media, that becomes the BUNDLE 1383 transport. 1385 Support and usage of ICE mechanism together with the BUNDLE extension 1386 is OPTIONAL. 1388 11.1. SDP Offer/Answer Procedures 1390 When an offerer assigns a unique address to one or more bundled "m=" 1391 sections (excluding any bundle-only "m=" section), the offerer MUST 1392 include SDP 'candidate' attributes (and other applicable ICE-related 1393 media-level SDP attributes), containing unique ICE properties 1394 (candidates etc), in each of those "m=" sections, follwoing the 1395 procedures in [I-D.ietf-mmusic-ice-sip-sdp]. 1397 When an offerer assigns a BUNDLE address (previously selected or new 1398 suggested) to a bundled "m=" section, (the "m=" section represented 1399 by the offerer BUNDLE-tag) the offerer MUST only include SDP 1400 'candidate' attributes (and other applicable ICE-related media-level 1401 SDP attributes) in that "m=" section, following the procedures in 1402 Section 8.1. 1404 When an answerer assigns a BUNDLE address to an "m=" section within a 1405 BUNDLE group (the "m=" section represented by the answerer BUNDLE- 1406 tag), the answerer MUST only include SDP 'candidate' attributes (and 1407 other applicable ICE-related media-level SDP attributes) in that "m=" 1408 section, following the procedures in Section 8.1. 1410 NOTE: As most ICE-related media-level SDP attributes belong to the 1411 TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the 1412 offerer and answerer follow the procedures in Section 8.1 when 1413 deciding whether to include an attribute in a bundled "m=" section. 1414 However, in the case of ICE-related media-level attributes, the rules 1415 apply to all attributes (see note below), even if they belong to a 1416 different mux category. 1418 NOTE: The following ICE-related media-level SDP attributes are 1419 defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote- 1420 candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- 1421 pacing'. 1423 12. DTLS Considerations 1425 One or more media streams within a BUNDLE group might use the 1426 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1427 to encrypt the data, or to negotiate encryption keys if another 1428 encryption mechanism is used to encrypt media. 1430 When DTLS is used within a BUNDLE group, the following rules apply: 1432 o There can only be one DTLS association [RFC6347] associated with 1433 the BUNDLE group; and 1435 o Each usage of the DTLS association within the BUNDLE group MUST 1436 use the same mechanism for determining which endpoints (the 1437 offerer or answerer) become DTLS client and DTLS server; and 1439 o Each usage of the DTLS association within the Bundle group MUST 1440 use the same mechanism for determining whether an offer or answer 1441 will trigger the establishment of a new DTLS association, or 1442 whether an existing DTLS association will be used; and 1444 o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include 1445 the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message 1446 [RFC5764], The client MUST include the extension even if the usage 1447 of DTLS-SRTP is not negotiated as part of the multimedia session 1448 (e.g., SIP session [RFC3261]. 1450 NOTE: The inclusion of the 'use_srtp' extension during the initial 1451 DTLS handshake ensures that a DTLS renegotiation will not be required 1452 in order to include the extension, in case DTLS-SRTP encrypted media 1453 is added to the BUNDLE group later during the multimedia session. 1455 13. RTP Header Extensions Consideration 1457 When [RFC8285] RTP header extensions are used in the context of this 1458 specification, the identifier used for a given extension MUST 1459 identify the same extension across all the bundled media 1460 descriptions. 1462 14. Update to RFC 3264 1464 This section replaces the text of the following sections of RFC 3264: 1466 o Section 5.1 (Unicast Streams). 1468 o Section 6 (Generating the Answer). 1470 o Section 8.2 (Removing a Media Stream). 1472 o Section 8.4 (Putting a Unicast Media Stream on Hold). 1474 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 1476 For recvonly and sendrecv streams, the port number and address in the 1477 offer indicate where the offerer would like to receive the media 1478 stream. For sendonly RTP streams, the address and port number 1479 indirectly indicate where the offerer wants to receive RTCP reports. 1480 Unless there is an explicit indication otherwise, reports are sent to 1481 the port number one higher than the number indicated. The IP address 1482 and port present in the offer indicate nothing about the source IP 1483 address and source port of RTP and RTCP packets that will be sent by 1484 the offerer. A port number of zero in the offer indicates that the 1485 stream is offered but MUST NOT be used. This has no useful semantics 1486 in an initial offer, but is allowed for reasons of completeness, 1487 since the answer can contain a zero port indicating a rejected stream 1488 (Section 6). Furthermore, existing streams can be terminated by 1489 setting the port to zero (Section 8). In general, a port number of 1490 zero indicates that the media stream is not wanted. 1492 14.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 1494 For recvonly and sendrecv streams, the port number and address in the 1495 offer indicate where the offerer would like to receive the media 1496 stream. For sendonly RTP streams, the address and port number 1497 indirectly indicate where the offerer wants to receive RTCP reports. 1498 Unless there is an explicit indication otherwise, reports are sent to 1499 the port number one higher than the number indicated. The IP address 1500 and port present in the offer indicate nothing about the source IP 1501 address and source port of RTP and RTCP packets that will be sent by 1502 the offerer. A port number of zero in the offer by default indicates 1503 that the stream is offered but MUST NOT be used, but an extension 1504 mechanism might specify different semantics for the usage of a zero 1505 port value. Furthermore, existing streams can be terminated by 1506 setting the port to zero (Section 8). In general, a port number of 1507 zero by default indicates that the media stream is not wanted. 1509 14.3. Original text of section 6 (4th paragraph) of RFC 3264 1511 An offered stream MAY be rejected in the answer, for any reason. If 1512 a stream is rejected, the offerer and answerer MUST NOT generate 1513 media (or RTCP packets) for that stream. To reject an offered 1514 stream, the port number in the corresponding stream in the answer 1515 MUST be set to zero. Any media formats listed are ignored. At least 1516 one MUST be present, as specified by SDP. 1518 14.4. New text replacing section 6 (4th paragraph) of RFC 3264 1520 An offered stream MAY be rejected in the answer, for any reason. If 1521 a stream is rejected, the offerer and answerer MUST NOT generate 1522 media (or RTCP packets) for that stream. A port number of zero in 1523 the answer by default indicates that the offered stream is rejected, 1524 but an extension mechanism might specify different semantics for the 1525 usage of a zero port value. If a stream is rejected, any media 1526 formats listed are ignored. At least one MUST be present, as 1527 specified by SDP. 1529 14.5. Original text of section 8.2 (2nd paragraph) of RFC 3264 1531 A stream that is offered with a port of zero MUST be marked with port 1532 zero in the answer. Like the offer, the answer MAY omit all 1533 attributes present previously, and MAY list just a single media 1534 format from amongst those in the offer. 1536 14.6. New text replacing section 8.2 (2nd paragraph) of RFC 3264 1538 A stream that is offered with a port of zero MUST by default be 1539 marked with port zero in the answer, unless an extension mechanism, 1540 which specifies semantics for the usage of a non-zero port value, is 1541 used. If the stream is marked with port zero in the answer, the 1542 answer MAY omit all attributes present previously, and MAY list just 1543 a single media format from amongst those in the offer." 1545 14.7. Original text of section 8.4 (6th paragraph) of RFC 3264 1547 RFC 2543 [10] specified that placing a user on hold was accomplished 1548 by setting the connection address to 0.0.0.0. Its usage for putting 1549 a call on hold is no longer recommended, since it doesn't allow for 1550 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1551 with connection oriented media. However, it can be useful in an 1552 initial offer when the offerer knows it wants to use a particular set 1553 of media streams and formats, but doesn't know the addresses and 1554 ports at the time of the offer. Of course, when used, the port 1555 number MUST NOT be zero, which would specify that the stream has been 1556 disabled. An agent MUST be capable of receiving SDP with a 1557 connection address of 0.0.0.0, in which case it means that neither 1558 RTP nor RTCP should be sent to the peer. 1560 14.8. New text replacing section 8.4 (6th paragraph) of RFC 3264 1562 RFC 2543 [10] specified that placing a user on hold was accomplished 1563 by setting the connection address to 0.0.0.0. Its usage for putting 1564 a call on hold is no longer recommended, since it doesn't allow for 1565 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1566 with connection oriented media. However, it can be useful in an 1567 initial offer when the offerer knows it wants to use a particular set 1568 of media streams and formats, but doesn't know the addresses and 1569 ports at the time of the offer. Of course, when used, the port 1570 number MUST NOT be zero, if it would specify that the stream has been 1571 disabled. However, an extension mechanism might specify different 1572 semantics of the zero port number usage. An agent MUST be capable of 1573 receiving SDP with a connection address of 0.0.0.0, in which case it 1574 means that neither RTP nor RTCP should be sent to the peer. 1576 15. RTP/RTCP extensions for identification-tag transport 1578 SDP Offerers and Answerers [RFC3264] can associate identification- 1579 tags with "m=" sections within SDP Offers and Answers, using the 1580 procedures in [RFC5888]. Each identification-tag uniquely represents 1581 an "m=" section. 1583 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1584 used to carry identification-tags within RTCP SDES packets. This 1585 section also defines a new RTP SDES header extension [RFC7941], which 1586 is used to carry the 'MID' RTCP SDES item in RTP packets. 1588 The SDES item and RTP SDES header extension make it possible for a 1589 receiver to associate each RTP stream with with a specific "m=" 1590 section, with which the receiver has associated an identification- 1591 tag, even if those "m=" sections are part of the same RTP session. 1592 The RTP SDES header extension also ensures that the media recipient 1593 gets the identification-tag upon receipt of the first decodable media 1594 and is able to associate the media with the correct application. 1596 A media recipient informs the media sender about the identification- 1597 tag associated with an "m=" section through the use of an 'mid' 1598 attribute [RFC5888]. The media sender then inserts the 1599 identification-tag in RTCP and RTP packets sent to the media 1600 recipient. 1602 NOTE: This text above defines how identification-tags are carried in 1603 SDP Offers and Answers. The usage of other signalling protocols for 1604 carrying identification-tags is not prevented, but the usage of such 1605 protocols is outside the scope of this document. 1607 [RFC3550] defines general procedures regarding the RTCP transmission 1608 interval. The RTCP MID SDES item SHOULD be sent in the first few 1609 RTCP packets sent after joining the session, and SHOULD be sent 1610 regularly thereafter. The exact number of RTCP packets in which this 1611 SDES item is sent is intentionally not specified here, as it will 1612 depend on the expected packet loss rate, the RTCP reporting interval, 1613 and the allowable overhead. 1615 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1616 be included in some RTP packets at the start of the session and 1617 whenever the SSRC changes. It might also be useful to include the 1618 header extension in RTP packets that comprise access points in the 1619 media (e.g., with video I-frames). The exact number of RTP packets 1620 in which this header extension is sent is intentionally not specified 1621 here, as it will depend on expected packet loss rate and loss 1622 patterns, the overhead the application can tolerate, and the 1623 importance of immediate receipt of the identification-tag. 1625 For robustness purpose, endpoints need to be prepared for situations 1626 where the reception of the identification-tag is delayed, and SHOULD 1627 NOT terminate sessions in such cases, as the identification-tag is 1628 likely to arrive soon. 1630 15.1. RTCP MID SDES Item 1632 0 1 2 3 1633 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 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | MID=TBD | length | identification-tag ... 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 The identification-tag payload is UTF-8 encoded, as in SDP. 1640 The identification-tag is not zero terminated. 1642 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1643 identifier value.] 1645 15.2. RTP SDES Header Extension For MID 1647 The payload, containing the identification-tag, of the RTP SDES 1648 header extension element can be encoded using either the one-byte or 1649 two-byte header [RFC7941]. The identification-tag payload is UTF-8 1650 encoded, as in SDP. 1652 The identification-tag is not zero terminated. Note, that the set of 1653 header extensions included in the packet needs to be padded to the 1654 next 32-bit boundary using zero bytes [RFC8285]. 1656 As the identification-tag is included in either an RTCP SDES item or 1657 an RTP SDES header extension, or both, there should be some 1658 consideration about the packet expansion caused by the 1659 identification-tag. To avoid Maximum Transmission Unit (MTU) issues 1660 for the RTP packets, the header extension's size needs to be taken 1661 into account when encoding the media. 1663 It is recommended that the identification-tag is kept short. Due to 1664 the properties of the RTP header extension mechanism, when using the 1665 one-byte header, a tag that is 1-3 bytes will result in a minimal 1666 number of 32-bit words used for the RTP SDES header extension, in 1667 case no other header extensions are included at the same time. Note, 1668 do take into account that some single characters when UTF-8 encoded 1669 will result in multiple octets. The identification-tag MUST NOT 1670 contain any user information, and applications SHALL avoid generating 1671 the identification-tag using a pattern that enables application 1672 identification. 1674 16. IANA Considerations 1676 16.1. New SDES item 1678 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1679 document.] 1681 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1682 identifier value.] 1684 This document adds the MID SDES item to the IANA "RTP SDES item 1685 types" registry as follows: 1687 Value: TBD 1688 Abbrev.: MID 1689 Name: Media Identification 1690 Reference: RFCXXXX 1692 16.2. New RTP SDES Header Extension URI 1694 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1695 document.] 1697 This document defines a new extension URI in the RTP SDES Compact 1698 Header Extensions sub-registry of the RTP Compact Header Extensions 1699 registry sub-registry, according to the following data: 1701 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1702 Description: Media identification 1703 Contact: christer.holmberg@ericsson.com 1704 Reference: RFCXXXX 1706 The SDES item does not reveal privacy information about the users. 1707 It is simply used to associate RTP-based media with the correct SDP 1708 media description ("m=" section) in the SDP used to negotiate the 1709 media. 1711 The purpose of the extension is for the offerer to be able to 1712 associate received multiplexed RTP-based media before the offerer 1713 receives the associated SDP answer. 1715 16.3. New SDP Attribute 1717 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1718 document.] 1720 This document defines a new SDP media-level attribute, 'bundle-only', 1721 according to the following data: 1723 Attribute name: bundle-only 1724 Type of attribute: media 1725 Subject to charset: No 1726 Purpose: Request a media description to be accepted 1727 in the answer only if kept within a BUNDLE 1728 group by the answerer. 1729 Appropriate values: N/A 1730 Contact name: Christer Holmberg 1731 Contact e-mail: christer.holmberg@ericsson.com 1732 Reference: RFCXXXX 1733 Mux category: NORMAL 1735 16.4. New SDP Group Semantics 1737 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1738 document.] 1740 This document registers the following semantics with IANA in the 1741 "Semantics for the "group" SDP Attribute" subregistry (under the 1742 "Session Description Protocol (SDP) Parameters" registry: 1744 Semantics Token Reference 1745 ------------------------------------- ------ --------- 1746 Media bundling BUNDLE [RFCXXXX] 1748 17. Security Considerations 1750 The security considerations defined in [RFC3264] and [RFC5888] apply 1751 to the BUNDLE extension. Bundle does not change which information, 1752 e.g., RTP streams, flows over the network, with the exception of the 1753 usage of the MID SDES item as discussed below. Primarily it changes 1754 which addresses and ports, and thus in which (RTP) sessions that the 1755 information is flowing in. This affects the security contexts being 1756 used and can cause previously separated information flows to share 1757 the same security context. This has very little impact on the 1758 performance of the security mechanism of the RTP sessions. In cases 1759 where one would have applied different security policies on the 1760 different RTP streams being bundled, or where the parties having 1761 access to the security contexts would have differed between the RTP 1762 stream, additional analysis of the implications are needed before 1763 selecting to apply BUNDLE. 1765 The identification-tag, independent of transport, RTCP SDES packet or 1766 RTP header extension, can expose the value to parties beyond the 1767 signaling chain. Therefore, the identification-tag values MUST be 1768 generated in a fashion that does not leak user information, e.g., 1769 randomly or using a per-bundle group counter, and SHOULD be 3 bytes 1770 or less, to allow them to efficiently fit into the MID RTP header 1771 extension. Note that if implementations use different methods for 1772 generating identification-tags this could enable fingerprinting of 1773 the implementation making it vulnerable to targeted attacks. The 1774 identification-tag is exposed on the RTP stream level when included 1775 in the RTP header extensions, however what it reveals of the RTP 1776 media stream structure of the endpoint and application was already 1777 possible to deduce from the RTP streams without the MID SDES header 1778 extensions. As the identification-tag is also used to route the 1779 media stream to the right application functionality it is also 1780 important that the value received is the one intended by the sender, 1781 thus integrity and the authenticity of the source are important to 1782 prevent denial of service on the application. Existing SRTP 1783 configurations and other security mechanisms protecting the whole 1784 RTP/RTCP packets will provide the necessary protection. 1786 When the BUNDLE extension is used, the set of configurations of the 1787 security mechanism used in all the bundled media descriptions will 1788 need to be compatible so that they can simultaneously used in 1789 parallel, at least per direction or endpoint. When using SRTP this 1790 will be the case, at least for the IETF defined key-management 1791 solutions due to their SDP attributes (a=crypto, a=fingerprint, 1792 a=mikey) and their classification in 1793 [I-D.ietf-mmusic-sdp-mux-attributes]. 1795 The security considerations of "RTP Header Extension for the RTP 1796 Control Protocol (RTCP) Source Description Items" [RFC7941] requires 1797 that when RTCP is confidentiality protected that any SDES RTP header 1798 extension carrying an SDES item, such as the MID RTP header 1799 extension, is also protected using commensurate strength algorithms. 1800 However, assuming the above requirements and recommendations are 1801 followed there are no known significant security risks with leaving 1802 the MID RTP header extension without confidentiality protection. 1803 Thus, the requirements in RFC 7941 MAY be ignored for the MID RTP 1804 header extension. Security mechanisms for RTP/RTCP are discussed in 1805 Options for Securing RTP Sessions [RFC7201], for example SRTP 1806 [RFC3711] can provide the necessary security functions of ensuring 1807 the integrity and source authenticity. 1809 18. Examples 1811 18.1. Example: Bundle Address Selection 1813 The example below shows: 1815 o An offer, in which the offerer assigns a unique address to each 1816 bundled "m=" section within the BUNDLE group. 1818 o An answer, in which the answerer selects the offerer BUNDLE 1819 address, and then selects its own BUNDLE address (the answerer 1820 BUNDLE address) and assigns it to the bundled "m=" section 1821 represented by the answerer BUNDLE-tag. 1823 SDP Offer (1) 1825 v=0 1826 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1827 s= 1828 c=IN IP4 atlanta.example.com 1829 t=0 0 1830 a=group:BUNDLE foo bar 1831 m=audio 10000 RTP/AVP 0 8 97 1832 b=AS:200 1833 a=mid:foo 1834 a=rtcp-mux 1835 a=rtpmap:0 PCMU/8000 1836 a=rtpmap:8 PCMA/8000 1837 a=rtpmap:97 iLBC/8000 1838 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1839 m=video 10002 RTP/AVP 31 32 1840 b=AS:1000 1841 a=mid:bar 1842 a=rtcp-mux 1843 a=rtpmap:31 H261/90000 1844 a=rtpmap:32 MPV/90000 1845 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1847 SDP Answer (2) 1849 v=0 1850 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1851 s= 1852 c=IN IP4 biloxi.example.com 1853 t=0 0 1854 a=group:BUNDLE foo bar 1855 m=audio 20000 RTP/AVP 0 1856 b=AS:200 1857 a=mid:foo 1858 a=rtcp-mux 1859 a=rtpmap:0 PCMU/8000 1860 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1861 m=video 0 RTP/AVP 32 1862 b=AS:1000 1863 a=mid:bar 1864 a=bundle-only 1865 a=rtpmap:32 MPV/90000 1866 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1868 18.2. Example: BUNDLE Extension Rejected 1870 The example below shows: 1872 o An offer, in which the offerer assigns a unique address to each 1873 bundled "m=" section within the BUNDLE group. 1875 o An answer, in which the answerer rejects the offered BUNDLE group, 1876 and assigns a unique address to each "m=" section (following 1877 normal RFC 3264 procedures). 1879 SDP Offer (1) 1881 v=0 1882 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1883 s= 1884 c=IN IP4 atlanta.example.com 1885 t=0 0 1886 a=group:BUNDLE foo bar 1887 m=audio 10000 RTP/AVP 0 8 97 1888 b=AS:200 1889 a=mid:foo 1890 a=rtcp-mux 1891 a=rtpmap:0 PCMU/8000 1892 a=rtpmap:8 PCMA/8000 1893 a=rtpmap:97 iLBC/8000 1894 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1895 m=video 10002 RTP/AVP 31 32 1896 b=AS:1000 1897 a=mid:bar 1898 a=rtcp-mux 1899 a=rtpmap:31 H261/90000 1900 a=rtpmap:32 MPV/90000 1901 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1903 SDP Answer (2) 1905 v=0 1906 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1907 s= 1908 c=IN IP4 biloxi.example.com 1909 t=0 0 1910 m=audio 20000 RTP/AVP 0 1911 b=AS:200 1912 a=rtcp-mux 1913 a=rtpmap:0 PCMU/8000 1914 m=video 30000 RTP/AVP 32 1915 b=AS:1000 1916 a=rtcp-mux 1917 a=rtpmap:32 MPV/90000 1919 18.3. Example: Offerer Adds A Media Description To A BUNDLE Group 1921 The example below shows: 1923 o A subsequent offer (the BUNDLE group has been created as part of a 1924 previous offer/answer exchange), in which the offerer adds a new 1925 "m=" section, represented by the "zen" identification-tag, to a 1926 previously negotiated BUNDLE group, assigns the previously 1927 selected offerer BUNDLE address to the added "m=" section, 1928 represented by the offerer BUNDLE-tag. To every other bundled 1929 "m=" section the offerer assigns a zero port value and includes an 1930 SDP 'bundle-only' attribute. 1932 o An answer, in which the answerer assigns the answerer BUNDLE 1933 address to the bundled "m=" section represented by the answerer 1934 BUNDLE-tag. To every other bundled "m=S section the answerer 1935 assigns a zero port value and includes an SDP 'bundle-only' 1936 attribute. 1938 SDP Offer (1) 1940 v=0 1941 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1942 s= 1943 c=IN IP4 atlanta.example.com 1944 t=0 0 1945 a=group:BUNDLE zen foo bar 1946 m=audio 0 RTP/AVP 0 8 97 1947 b=AS:200 1948 a=mid:foo 1949 a=bundle-only 1950 a=rtcp-mux 1951 a=rtpmap:0 PCMU/8000 1952 a=rtpmap:8 PCMA/8000 1953 a=rtpmap:97 iLBC/8000 1954 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1955 m=video 0 RTP/AVP 31 32 1956 b=AS:1000 1957 a=mid:bar 1958 a=rtpmap:31 H261/90000 1959 a=rtpmap:32 MPV/90000 1960 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1961 m=video 10000 RTP/AVP 66 1962 b=AS:1000 1963 a=mid:zen 1964 a=bundle-only 1965 a=rtcp-mux 1966 a=rtpmap:66 H261/90000 1967 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1969 SDP Answer (2) 1971 v=0 1972 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1973 s= 1974 c=IN IP4 biloxi.example.com 1975 t=0 0 1976 a=group:BUNDLE zen foo bar 1977 m=audio 0 RTP/AVP 0 1978 b=AS:200 1979 a=mid:foo 1980 a=bundle-only 1981 a=rtcp-mux 1982 a=rtpmap:0 PCMU/8000 1983 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1984 m=video 0 RTP/AVP 32 1985 b=AS:1000 1986 a=mid:bar 1987 a=bundle-only 1988 a=rtpmap:32 MPV/90000 1989 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1990 m=video 20000 RTP/AVP 66 1991 b=AS:1000 1992 a=mid:zen 1993 a=rtpmap:66 H261/90000 1994 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1996 18.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 1998 The example below shows: 2000 o A subsequent offer (the BUNDLE group has been created as part of a 2001 previous offer/answer transaction), in which the offerer moves a 2002 bundled "m=" section, represented by the "zen" identification-tag, 2003 out of a BUNDLE group, assigns a unique address to the moved "m=" 2004 section, and assigns the previously selected offerer BUNDLE 2005 address to another bundled "m=" section, represented by the 2006 offerer BUNDLE-tag. To every other bundled "m=" section the 2007 offerer assigns a zero port value and includes an SDP 'bundle- 2008 only' attribute. 2010 o An answer, in which the answerer moves the "m=" section out of the 2011 BUNDLE group, assigns a unique address to the moved "m=" section, 2012 and assigns the answerer BUNDLE address to the bundled "m=" 2013 section represented by the answerer BUNDLE-tag. To every other 2014 bundled "m=" section the answerer assigns a zero port value and 2015 includes an SDP 'bundle-only' attribute. 2017 SDP Offer (1) 2019 v=0 2020 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2021 s= 2022 c=IN IP4 atlanta.example.com 2023 t=0 0 2024 a=group:BUNDLE foo bar 2025 m=audio 10000 RTP/AVP 0 8 97 2026 b=AS:200 2027 a=mid:foo 2028 a=rtcp-mux 2029 a=rtpmap:0 PCMU/8000 2030 a=rtpmap:8 PCMA/8000 2031 a=rtpmap:97 iLBC/8000 2032 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2033 m=video 0 RTP/AVP 31 32 2034 b=AS:1000 2035 a=mid:bar 2036 a=bundle-only 2037 a=rtpmap:31 H261/90000 2038 a=rtpmap:32 MPV/90000 2039 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2040 m=video 50000 RTP/AVP 66 2041 b=AS:1000 2042 a=mid:zen 2043 a=rtcp-mux 2044 a=rtpmap:66 H261/90000 2046 SDP Answer (2) 2048 v=0 2049 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2050 s= 2051 c=IN IP4 biloxi.example.com 2052 t=0 0 2053 a=group:BUNDLE foo bar 2054 m=audio 20000 RTP/AVP 0 2055 b=AS:200 2056 a=mid:foo 2057 a=rtcp-mux 2058 a=rtpmap:0 PCMU/8000 2059 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2060 m=video 0 RTP/AVP 32 2061 b=AS:1000 2062 a=mid:bar 2063 a=bundle-only 2064 a=rtpmap:32 MPV/90000 2065 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2066 m=video 60000 RTP/AVP 66 2067 b=AS:1000 2068 a=mid:zen 2069 a=rtcp-mux 2070 a=rtpmap:66 H261/90000 2072 18.5. Example: Offerer Disables A Media Description Within A BUNDLE 2073 Group 2075 The example below shows: 2077 o A subsequent offer (the BUNDLE group has been created as part of a 2078 previous offer/answer transaction), in which the offerer disables 2079 a bundled "m=" section represented by the "zen" identification- 2080 tag, within a BUNDLE group, assigns a zero port number to the 2081 disabled "m=" section, and assigns the offerer BUNDLE address to 2082 another bundled "m=" section, represented by the offerer BUNDLE- 2083 tag. To every other bundled "m=" section the offerer assigns a 2084 zero port value and includes an SDP 'bundle-only' attribute. 2086 o An answer, in which the answerer moves the disabled "m=" sections 2087 out of the BUNDLE group, assigns a zero port value to the disabled 2088 "m=" section, and assigns the answerer BUNDLE address to the 2089 bundled "m=" section represented by the answerer BUNDLE-tag. To 2090 every other bundled "m=" section the answerer assigns a zero port 2091 value and includes an SDP 'bundle-only' attribute. 2093 SDP Offer (1) 2095 v=0 2096 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2097 s= 2098 c=IN IP4 atlanta.example.com 2099 t=0 0 2100 a=group:BUNDLE foo bar 2101 m=audio 10000 RTP/AVP 0 8 97 2102 b=AS:200 2103 a=mid:foo 2104 a=rtcp-mux 2105 a=rtpmap:0 PCMU/8000 2106 a=rtpmap:8 PCMA/8000 2107 a=rtpmap:97 iLBC/8000 2108 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2109 m=video 0 RTP/AVP 31 32 2110 b=AS:1000 2111 a=mid:bar 2112 a=bundle-only 2113 a=rtpmap:31 H261/90000 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 SDP Answer (2) 2122 v=0 2123 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2124 s= 2125 c=IN IP4 biloxi.example.com 2126 t=0 0 2127 a=group:BUNDLE foo bar 2128 m=audio 20000 RTP/AVP 0 2129 b=AS:200 2130 a=mid:foo 2131 a=rtcp-mux 2132 a=rtpmap:0 PCMU/8000 2133 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2134 m=video 0 RTP/AVP 32 2135 b=AS:1000 2136 a=mid:bar 2137 a=bundle-only 2138 a=rtpmap:32 MPV/90000 2139 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 2140 m=video 0 RTP/AVP 66 2141 a=mid:zen 2142 a=rtpmap:66 H261/90000 2144 19. Acknowledgements 2146 The usage of the SDP grouping extension for negotiating bundled media 2147 is based on a similar alternatives proposed by Harald Alvestrand and 2148 Cullen Jennings. The BUNDLE extension described in this document is 2149 based on the different alternative proposals, and text (e.g., SDP 2150 examples) have been borrowed (and, in some cases, modified) from 2151 those alternative proposals. 2153 The SDP examples are also modified versions from the ones in the 2154 Alvestrand proposal. 2156 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 2157 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 2158 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin 2159 Uberti, Taylor Brandstetter, Byron Campen and Eric Rescorla for 2160 reading the text, and providing useful feedback. 2162 Thanks to Bernard Aboba, Cullen Jennings, Peter Thatcher, Justin 2163 Uberti, and Magnus Westerlund for providing the text for the section 2164 on RTP/RTCP stream association. 2166 Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for 2167 providing help and text on the RTP/RTCP procedures. 2169 Thanks to Spotify for providing music for the countless hours of 2170 document editing. 2172 20. Change Log 2174 [RFC EDITOR NOTE: Please remove this section when publishing] 2176 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-41 2178 o Update to section 6 o RFC 3264: 2180 o https://github.com/cdh4u/draft-sdp-bundle/pull/47 2182 o Editorial clarification on BUNDLE address selection: 2184 o https://github.com/cdh4u/draft-sdp-bundle/pull/46 2186 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40 2188 o Editorial changes and technical restrictions in order to make the 2189 specification more understandable: 2191 o https://github.com/cdh4u/draft-sdp-bundle/pull/45 2193 o - BUNDLE address is only assigned to m- section represented by 2194 BUNDLE-tag. 2196 o - bundle-only attribute also used in answers and subsequent 2197 offers. 2199 o - Answerer cannot reject, or remove, the bundled m- section that 2200 contains the BUNDLE address. 2202 o - ICE Offer/Answer sections removed, due to duplicated 2203 information. 2205 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39 2207 o Editorial terminology changes. 2209 o RFC 5285 reference replaced by reference to RFC 8285. 2211 o https://github.com/cdh4u/draft-sdp-bundle/pull/44 2213 o - Clarify that an m- section can not be moved between BUNDLE 2214 groups without first moving the m- section out of a BUNDLE group. 2216 o https://github.com/cdh4u/draft-sdp-bundle/pull/41 2218 o - Addition of BUNDLE transport concept. 2220 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38 2222 o Changes to RTP streaming mapping section based on text from Colin 2223 Perkins. 2225 o The following GitHub pull requests were merged: 2227 o https://github.com/cdh4u/draft-sdp-bundle/pull/34 2229 o - Proposed updates to RTP processing 2231 o https://github.com/cdh4u/draft-sdp-bundle/pull/35 2233 o - fixed reference to receiver-id section 2235 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-37 2237 o The following GitHub pull request was merged: 2239 o https://github.com/cdh4u/draft-sdp-bundle/pull/33 2241 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36 2243 o The following GitHub pull requests were merged: 2245 o https://github.com/cdh4u/draft-sdp-bundle/pull/32 2246 o - extmap handling in BUNDLE. 2248 o https://github.com/cdh4u/draft-sdp-bundle/pull/31 2250 o - Additional Acknowledgement text added. 2252 o https://github.com/cdh4u/draft-sdp-bundle/pull/30 2254 o - MID SDES item security procedures updated 2256 o https://github.com/cdh4u/draft-sdp-bundle/pull/29 2258 o - Appendix B of JSEP moved into BUNDLE. 2260 o - Associating RTP/RTCP packets with SDP m- lines. 2262 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35 2264 o Editorial changes on RTP streaming mapping section based on 2265 comments from Colin Perkins. 2267 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34 2269 o RTP streams, instead of RTP packets, are associated with m- lines. 2271 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 2273 o Editorial changes based on comments from Eric Rescorla and Cullen 2274 Jennings: 2276 o - Changes regarding usage of RTP/RTCP multiplexing attributes. 2278 o - Additional text regarding associating RTP/RTCP packets with SDP 2279 m- lines. 2281 o - Reference correction. 2283 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32 2285 o Editorial changes based on comments from Eric Rescorla and Cullen 2286 Jennings: 2288 o - Justification for mechanism added to Introduction. 2290 o - Clarify that the order of m- lines in the group:BUNDLE attribute 2291 does not have to be the same as the order in which the m- lines 2292 are listed in the SDP. 2294 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31 2296 o Editorial changes based on GitHub Pull requests by Martin Thomson: 2298 o - https://github.com/cdh4u/draft-sdp-bundle/pull/2 2300 o - https://github.com/cdh4u/draft-sdp-bundle/pull/1 2302 o Editorial change based on comment from Diederick Huijbers (9th 2303 July 2016). 2305 o Changes based on comments from Flemming Andreasen (21st June 2306 2016): 2308 o - Mux category for SDP bundle-only attribute added. 2310 o - Mux category considerations editorial clarification. 2312 o - Editorial changes. 2314 o RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext. 2316 o Note whether Design Considerations appendix is to be kept removed: 2318 o - Appendix is kept within document. 2320 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30 2322 o Indicating in the Abstract and Introduction that the document 2323 updates RFC 3264. 2325 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29 2327 o Change based on WGLC comment from Colin Perkins. 2329 o - Clarify that SSRC can be reused by another source after a delay 2330 of 5 RTCP reporting intervals. 2332 o Change based on WGLC comment from Alissa Cooper. 2334 o - IANA registry name fix. 2336 o - Additional IANA registration information added. 2338 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28 2340 o - Alignment with exclusive mux procedures. 2342 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 2344 o - Yet another terminology change. 2346 o - Mux category considerations added. 2348 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 2350 o - ICE considerations modified: ICE-related SDP attributes only 2351 added to the bundled m- line representing the selected BUNDLE 2352 address. 2354 o - Reference to draft-ietf-mmusic-ice-sip-sdp added. 2356 o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- 2357 rfc5245bis. 2359 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 2361 o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux 2362 considerations. 2364 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 2366 o - Reference and procedures associated with exclusive RTP/RTCP mux 2367 added 2369 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 2371 o - RTCP-MUX mandatory for bundled RTP m- lines 2373 o - Editorial fixes based on comments from Flemming Andreasen 2375 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 2377 o - Correction of Ari's family name 2379 o - Editorial fixes based on comments from Thomas Stach 2381 o - RTP/RTCP correction based on comment from Magnus Westerlund 2383 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2384 msg14861.html 2386 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 2388 o - Correct based on comment from Paul Kyzivat 2389 o -- 'received packets' replaced with 'received data' 2391 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 2393 o - Clarification based on comment from James Guballa 2395 o - Clarification based on comment from Flemming Andreasen 2397 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 2399 o - DTLS Considerations section added. 2401 o - BUNDLE semantics added to the IANA Considerations 2403 o - Changes based on WGLC comments from Adam Roach 2405 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 2406 msg14673.html 2408 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 2410 o - Changes based on agreements at IETF#92 2412 o -- BAS Offer removed, based on agreement at IETF#92. 2414 o -- Procedures regarding usage of SDP "b=" line is replaced with a 2415 reference to to draft-ietf-mmusic-sdp-mux-attributes. 2417 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 2419 o - Editorial changes based on comments from Magnus Westerlund. 2421 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 2423 o - Modification of RTP/RTCP multiplexing section, based on comments 2424 from Magnus Westerlund. 2426 o - Reference updates. 2428 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 2430 o - Editorial fix. 2432 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 2434 o - Editorial changes. 2436 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 2437 o Changes to allow a new suggested offerer BUNDLE address to be 2438 assigned to each bundled m- line. 2440 o Changes based on WGLC comments from Paul Kyzivat 2442 o - Editorial fixes 2444 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 2446 o Usage of SDP 'extmap' attribute added 2448 o SDP 'bundle-only' attribute scoped with "m=" lines with a zero 2449 port value 2451 o Changes based on WGLC comments from Thomas Stach 2453 o - ICE candidates not assigned to bundle-only m- lines with a zero 2454 port value 2456 o - Editorial changes 2458 o Changes based on WGLC comments from Colin Perkins 2460 o - Editorial changes: 2462 o -- "RTP SDES item" -> "RTCP SDES item" 2464 o -- "RTP MID SDES item" -> "RTCP MID SDES item" 2466 o - Changes in section 10.1.1: 2468 o -- "SHOULD NOT" -> "MUST NOT" 2470 o -- Additional text added to the Note 2472 o - Change to section 13.2: 2474 o -- Clarify that mid value is not zero terminated 2476 o - Change to section 13.3: 2478 o -- Clarify that mid value is not zero terminated 2480 o -- Clarify padding 2482 o Changes based on WGLC comments from Paul Kyzivat 2484 o - Editorial changes: 2486 o Changes based on WGLC comments from Jonathan Lennox 2488 o - Editorial changes: 2490 o - Defintion of SDP bundle-only attribute alligned with structure 2491 in 4566bis draft 2493 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 2495 o Editorial corrections based on comments from Harald Alvestrand. 2497 o Editorial corrections based on comments from Cullen Jennings. 2499 o Reference update (RFC 7160). 2501 o Clarification about RTCP packet sending when RTP/RTCP multiplexing 2502 is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ 2503 msg13765.html). 2505 o Additional text added to the Security Considerations. 2507 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 2509 o SDP bundle-only attribute added to IANA Considerations. 2511 o SDES item and RTP header extension added to Abstract and 2512 Introduction. 2514 o Modification to text updating section 8.2 of RFC 3264. 2516 o Reference corrections. 2518 o Editorial corrections. 2520 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 2522 o Terminology change: "bundle-only attribute assigned to m= line" to 2523 "bundle-only attribute associated with m= line". 2525 o Editorial corrections. 2527 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 2529 o Editorial corrections. 2531 o - "of"->"if" (8.3.2.5). 2533 o - "optional"->"OPTIONAL" (9.1). 2535 o - Syntax/ABNF for 'bundle-only' attribute added. 2537 o - SDP Offer/Answer sections merged. 2539 o - 'Request new offerer BUNDLE address' section added 2541 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 2543 o OPEN ISSUE regarding Receiver-ID closed. 2545 o - RTP MID SDES Item. 2547 o - RTP MID Header Extension. 2549 o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers 2550 closed. 2552 o - Indicating that, when rtcp-mux is used, the answerer MUST NOT 2553 include an 'rtcp' attribute in the answer, based on the procedures 2554 in section 5.1.3 of RFC 5761. 2556 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 2558 o Draft title changed. 2560 o Added "SDP" to section names containing "Offer" or "Answer". 2562 o Editorial fixes based on comments from Paul Kyzivat 2563 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2564 msg13314.html). 2566 o Editorial fixed based on comments from Colin Perkins 2567 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2568 msg13318.html). 2570 o - Removed text about extending BUNDLE to allow multiple RTP 2571 sessions within a BUNDLE group. 2573 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 2575 o Major re-structure of SDP Offer/Answer sections, to align with RFC 2576 3264 structure. 2578 o Additional definitions added. 2580 o - Shared address. 2582 o - Bundled "m=" line. 2584 o - Bundle-only "m=" line. 2586 o - Offerer suggested BUNDLE mid. 2588 o - Answerer selected BUNDLE mid. 2590 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 2591 to multiple "m=" lines until it has received an SDP Answer 2592 indicating support of the BUNDLE extension. 2594 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 2595 Answerer supports the BUNDLE extension, assign a zero port value 2596 to a 'bundle-only' "m=" line. 2598 o SDP 'bundle-only' attribute section added. 2600 o Connection data nettype/addrtype restrictions added. 2602 o RFC 3264 update section added. 2604 o Indicating that a specific payload type value can be used in 2605 multiple "m=" lines, if the value represents the same codec 2606 configuration in each "m=" line. 2608 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 2610 o Updated Offerer procedures (http://www.ietf.org/mail- 2611 archive/web/mmusic/current/msg12293.html). 2613 o Updated Answerer procedures (http://www.ietf.org/mail- 2614 archive/web/mmusic/current/msg12333.html). 2616 o Usage of SDP 'bundle-only' attribute added. 2618 o Reference to Trickle ICE document added. 2620 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 2622 o Mechanism modified, to be based on usage of SDP Offers with both 2623 different and identical port number values, depending on whether 2624 it is known if the remote endpoint supports the extension. 2626 o Cullen Jennings added as co-author. 2628 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 2630 o No changes. New version due to expiration. 2632 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 2634 o No changes. New version due to expiration. 2636 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 2638 o Draft name changed. 2640 o Harald Alvestrand added as co-author. 2642 o "Multiplex" terminology changed to "bundle". 2644 o Added text about single versus multiple RTP Sessions. 2646 o Added reference to RFC 3550. 2648 21. References 2650 21.1. Normative References 2652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2653 Requirement Levels", BCP 14, RFC 2119, 2654 DOI 10.17487/RFC2119, March 1997, . 2657 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2658 with Session Description Protocol (SDP)", RFC 3264, 2659 DOI 10.17487/RFC3264, June 2002, . 2662 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2663 Jacobson, "RTP: A Transport Protocol for Real-Time 2664 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2665 July 2003, . 2667 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2668 in Session Description Protocol (SDP)", RFC 3605, 2669 DOI 10.17487/RFC3605, October 2003, . 2672 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2673 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2674 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2675 . 2677 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2678 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2679 July 2006, . 2681 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2682 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2683 . 2685 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2686 Control Packets on a Single Port", RFC 5761, 2687 DOI 10.17487/RFC5761, April 2010, . 2690 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2691 Security (DTLS) Extension to Establish Keys for the Secure 2692 Real-time Transport Protocol (SRTP)", RFC 5764, 2693 DOI 10.17487/RFC5764, May 2010, . 2696 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2697 Protocol (SDP) Grouping Framework", RFC 5888, 2698 DOI 10.17487/RFC5888, June 2010, . 2701 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2702 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2703 January 2012, . 2705 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2706 Header Extension for the RTP Control Protocol (RTCP) 2707 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2708 August 2016, . 2710 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 2711 Mechanism for RTP Header Extensions", RFC 8285, 2712 DOI 10.17487/RFC8285, October 2017, . 2715 [I-D.ietf-ice-rfc5245bis] 2716 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2717 Connectivity Establishment (ICE): A Protocol for Network 2718 Address Translator (NAT) Traversal", draft-ietf-ice- 2719 rfc5245bis-15 (work in progress), November 2017. 2721 [I-D.ietf-mmusic-sdp-mux-attributes] 2722 Nandakumar, S., "A Framework for SDP Attributes when 2723 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 2724 (work in progress), December 2016. 2726 [I-D.ietf-mmusic-mux-exclusive] 2727 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 2728 Multiplexing using SDP", draft-ietf-mmusic-mux- 2729 exclusive-12 (work in progress), May 2017. 2731 [I-D.ietf-mmusic-ice-sip-sdp] 2732 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, 2733 "Session Description Protocol (SDP) Offer/Answer 2734 procedures for Interactive Connectivity Establishment 2735 (ICE)", draft-ietf-mmusic-ice-sip-sdp-16 (work in 2736 progress), November 2017. 2738 21.2. Informative References 2740 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2741 A., Peterson, J., Sparks, R., Handley, M., and E. 2742 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2743 DOI 10.17487/RFC3261, June 2002, . 2746 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2747 "RTP Control Protocol Extended Reports (RTCP XR)", 2748 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2749 . 2751 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2752 "Codec Control Messages in the RTP Audio-Visual Profile 2753 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 2754 February 2008, . 2756 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2757 "Extended RTP Profile for Real-time Transport Control 2758 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2759 DOI 10.17487/RFC4585, July 2006, . 2762 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2763 Media Attributes in the Session Description Protocol 2764 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2765 . 2767 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2768 Clock Rates in an RTP Session", RFC 7160, 2769 DOI 10.17487/RFC7160, April 2014, . 2772 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2773 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2774 . 2776 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2777 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2778 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2779 DOI 10.17487/RFC7656, November 2015, . 2782 [I-D.ietf-ice-trickle] 2783 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 2784 "Trickle ICE: Incremental Provisioning of Candidates for 2785 the Interactive Connectivity Establishment (ICE) 2786 Protocol", draft-ietf-ice-trickle-15 (work in progress), 2787 November 2017. 2789 [I-D.ietf-avtext-lrr] 2790 Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 2791 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 2792 Message", draft-ietf-avtext-lrr-07 (work in progress), 2793 July 2017. 2795 Appendix A. Design Considerations 2797 One of the main issues regarding the BUNDLE grouping extensions has 2798 been whether, in SDP Offers and SDP Answers, the same port value 2799 should be inserted in "m=" lines associated with a BUNDLE group, as 2800 the purpose of the extension is to negotiate the usage of a single 2801 transport for media specified by the "m=" sections. Issues with both 2802 approaches, discussed in the Appendix have been raised. The outcome 2803 was to specify a mechanism which uses SDP Offers with both different 2804 and identical port values. 2806 Below are the primary issues that have been considered when defining 2807 the "BUNDLE" grouping extension: 2809 o 1) Interoperability with existing UAs. 2811 o 2) Interoperability with intermediary B2BUA- and proxy entities. 2813 o 3) Time to gather, and the number of, ICE candidates. 2815 o 4) Different error scenarios, and when they occur. 2817 o 5) SDP Offer/Answer impacts, including usage of port number value 2818 zero. 2820 A.1. UA Interoperability 2822 Consider the following SDP Offer/Answer exchange, where Alice sends 2823 an SDP Offer to Bob: 2825 SDP Offer 2827 v=0 2828 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2829 s= 2830 c=IN IP4 atlanta.example.com 2831 t=0 0 2832 m=audio 10000 RTP/AVP 97 2833 a=rtpmap:97 iLBC/8000 2834 m=video 10002 RTP/AVP 97 2835 a=rtpmap:97 H261/90000 2837 SDP Answer 2839 v=0 2840 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2841 s= 2842 c=IN IP4 biloxi.example.com 2843 t=0 0 2844 m=audio 20000 RTP/AVP 97 2845 a=rtpmap:97 iLBC/8000 2846 m=video 20002 RTP/AVP 97 2847 a=rtpmap:97 H261/90000 2849 RFC 4961 specifies a way of doing symmetric RTP but that is an a 2850 later invention to RTP and Bob can not assume that Alice supports RFC 2851 4961. This means that Alice may be sending RTP from a different port 2852 than 10000 or 10002 - some implementation simply send the RTP from an 2853 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2854 way that Bob knows if it should be passed to the video or audio codec 2855 is by looking at the port it was received on. This lead some SDP 2856 implementations to use the fact that each "m=" section had a 2857 different port number to use that port number as an index to find the 2858 correct m line in the SDP. As a result, some implementations that do 2859 support symmetric RTP and ICE still use a SDP data structure where 2860 SDP with "m=" sections with the same port such as: 2862 SDP Offer 2864 v=0 2865 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2866 s= 2867 c=IN IP4 atlanta.example.com 2868 t=0 0 2869 m=audio 10000 RTP/AVP 97 2870 a=rtpmap:97 iLBC/8000 2871 m=video 10000 RTP/AVP 98 2872 a=rtpmap:98 H261/90000 2874 will result in the second "m=" section being considered an SDP error 2875 because it has the same port as the first line. 2877 A.2. Usage of port number value zero 2879 In an SDP Offer or SDP Answer, the media specified by an "m=" section 2880 can be disabled/rejected by setting the port number value to zero. 2881 This is different from e.g., using the SDP direction attributes, 2882 where RTCP traffic will continue even if the SDP "inactive" attribute 2883 is indicated for the associated "m=" section. 2885 If each "m=" section associated with a BUNDLE group would contain 2886 different port values, and one of those port values would be used for 2887 a BUNDLE address associated with the BUNDLE group, problems would 2888 occur if an endpoint wants to disable/reject the "m=" sectcion 2889 associated with that port, by setting the port value to zero. After 2890 that, no "m=" section would contain the port value which is used for 2891 the BUNDLE address. In addition, it is unclear what would happen to 2892 the ICE candidates associated with the "m=" section, as they are also 2893 used for the BUNDLE address. 2895 A.3. B2BUA And Proxy Interoperability 2897 Some back to back user agents may be configured in a mode where if 2898 the incoming call leg contains an SDP attribute the B2BUA does not 2899 understand, the B2BUA still generates that SDP attribute in the Offer 2900 for the outgoing call leg. Consider a B2BUA that did not understand 2901 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 2902 Further assume that the B2BUA was configured to tear down any call 2903 where it did not see any RTCP for 5 minutes. In this case, if the 2904 B2BUA received an Offer like: 2906 SDP Offer 2908 v=0 2909 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2910 s= 2911 c=IN IP4 atlanta.example.com 2912 t=0 0 2913 m=audio 49170 RTP/AVP 0 2914 a=rtcp:53020 2916 It would be looking for RTCP on port 49172 but would not see any 2917 because the RTCP would be on port 53020 and after five minutes, it 2918 would tear down the call. Similarly, a B2BUA that did not understand 2919 BUNDLE yet put BUNDLE in it's offer may be looking for media on the 2920 wrong port and tear down the call. It is worth noting that a B2BUA 2921 that generated an Offer with capabilities it does not understand is 2922 not compliant with the specifications. 2924 A.3.1. Traffic Policing 2926 Sometimes intermediaries do not act as B2BUA, in the sense that they 2927 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2928 however, they may use SDP information (e.g., IP address and port) in 2929 order to control traffic gating functions, and to set traffic 2930 policing rules. There might be rules which will trigger a session to 2931 be terminated in case media is not sent or received on the ports 2932 retrieved from the SDP. This typically occurs once the session is 2933 already established and ongoing. 2935 A.3.2. Bandwidth Allocation 2937 Sometimes intermediaries do not act as B2BUA, in the sense that they 2938 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2939 however, they may use SDP information (e.g., codecs and media types) 2940 in order to control bandwidth allocation functions. The bandwidth 2941 allocation is done per "m=" section, which means that it might not be 2942 enough if media specified by all "m=" sections try to use that 2943 bandwidth. That may either simply lead to bad user experience, or to 2944 termination of the call. 2946 A.4. Candidate Gathering 2948 When using ICE, a candidate needs to be gathered for each port. This 2949 takes approximately 20 ms extra for each extra "m=" section due to 2950 the NAT pacing requirements. All of this gather can be overlapped 2951 with other things while for exampe a web-page is loading to minimize 2952 the impact. If the client only wants to generate TURN or STUN ICE 2953 candidates for one of the "m=" lines and then use trickle ICE 2954 [I-D.ietf-ice-trickle] to get the non host ICE candidates for the 2955 rest of the "m=" sections, it MAY do that and will not need any 2956 additional gathering time. 2958 Some people have suggested a TURN extension to get a bunch of TURN 2959 allocations at once. This would only provide a single STUN result so 2960 in cases where the other end did not support BUNDLE, may cause more 2961 use of the TURN server but would be quick in the cases where both 2962 sides supported BUNDLE and would fall back to a successful call in 2963 the other cases. 2965 Authors' Addresses 2967 Christer Holmberg 2968 Ericsson 2969 Hirsalantie 11 2970 Jorvas 02420 2971 Finland 2973 Email: christer.holmberg@ericsson.com 2975 Harald Tveit Alvestrand 2976 Google 2977 Kungsbron 2 2978 Stockholm 11122 2979 Sweden 2981 Email: harald@alvestrand.no 2983 Cullen Jennings 2984 Cisco 2985 400 3rd Avenue SW, Suite 350 2986 Calgary, AB T2P 4H2 2987 Canada 2989 Email: fluffy@iii.ca