idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-33.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 (October 7, 2016) is 2756 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 1277 == Missing Reference: 'RFCXXXX' is mentioned on line 1458, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 7914 == Outdated reference: A later version (-20) exists of draft-ietf-ice-rfc5245bis-04 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-14 == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-mux-exclusive-10 == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-10 Summary: 5 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: April 10, 2017 C. Jennings 7 Cisco 8 October 7, 2016 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-33.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 address:port combination (BUNDLE address) for receiving media, 20 referred to as bundled media, specified by multiple SDP media 21 descriptions ("m=" lines). 23 To assist endpoints in negotiating the use of bundle this 24 specification defines a new SDP attribute, 'bundle-only', which can 25 be used to request that specific media is only used if bundled. The 26 specification also updates RFC 3264, to allow usage of zero port 27 values without meaning that media is rejected. 29 There are multiple ways to correlate the bundled RTP packets with the 30 appropriate media descriptions. This specification defines a new 31 Real-time Transport Protocol (RTP) source description (SDES) item and 32 a new RTP header extension that provides an additional way to do this 33 correlation by using them to carry a value that associates the RTP/ 34 RTCP packets with a specific media description. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 10, 2017. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 83 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 84 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 86 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7 87 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 8 88 7. SDP Information Considerations . . . . . . . . . . . . . . . 9 89 7.1. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9 90 7.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9 91 7.3. Attributes (a=) . . . . . . . . . . . . . . . . . . . . . 9 92 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9 93 8.1. Mux Category Considerations . . . . . . . . . . . . . . . 10 94 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 10 95 8.2.1. Suggesting the offerer BUNDLE address . . . . . . . . 11 96 8.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 11 97 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 12 98 8.3.1. Answerer Selection of Offerer Bundle Address . . . . 13 99 8.3.2. Answerer Selection of Answerer BUNDLE Address . . . . 14 100 8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 14 101 8.3.4. Rejecting A Media Description In A BUNDLE Group . . . 15 102 8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 15 103 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 15 104 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 16 105 8.5.1. Suggesting a new offerer BUNDLE address . . . . . . . 16 106 8.5.2. Adding a media description to a BUNDLE group . . . . 17 107 8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 17 108 8.5.4. Disabling A Media Description In A BUNDLE Group . . . 18 109 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 18 110 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19 111 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 19 112 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 19 113 10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 20 114 10.2. Associating RTP/RTCP Packets With Correct SDP Media 115 Description . . . . . . . . . . . . . . . . . . . . . . 20 116 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 21 117 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 21 118 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 23 119 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 24 120 11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 25 121 11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 25 122 11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 25 123 11.1.4. Modifying the Session . . . . . . . . . . . . . . . 25 124 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 25 125 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 26 126 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 26 127 13.2. New text replacing section 5.1 (2nd paragraph) of RFC 128 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 129 13.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 27 130 13.4. New text replacing section 8.2 (2nd paragraph) of RFC 131 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 132 13.5. Original text of section 8.4 (6th paragraph) of RFC 3264 27 133 13.6. New text replacing section 8.4 (6th paragraph) of RFC 134 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 135 14. RTP/RTCP extensions for identification-tag transport . . . . 28 136 14.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 29 137 14.2. RTP SDES Header Extension For MID . . . . . . . . . . . 29 138 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 139 15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 30 140 15.2. New RTP SDES Header Extension URI . . . . . . . . . . . 30 141 15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 31 142 15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 31 143 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 144 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32 145 17.1. Example: Bundle Address Selection . . . . . . . . . . . 32 146 17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 34 147 17.3. Example: Offerer Adds A Media Description To A BUNDLE 148 Group . . . . . . . . . . . . . . . . . . . . . . . . . 35 149 17.4. Example: Offerer Moves A Media Description Out Of A 150 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 37 151 17.5. Example: Offerer Disables A Media Description Within A 152 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 39 153 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 154 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 41 155 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 156 20.1. Normative References . . . . . . . . . . . . . . . . . . 48 157 20.2. Informative References . . . . . . . . . . . . . . . . . 50 158 Appendix A. Design Considerations . . . . . . . . . . . . . . . 51 159 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 51 160 A.2. Usage of port number value zero . . . . . . . . . . . . . 53 161 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 53 162 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 54 163 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 54 164 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 54 165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 167 1. Introduction 169 When multimedia communications are established, each 5-tuple reserved 170 for an individual media stream consume additional resources 171 (especially when Interactive Connectivity Establishment (ICE) 172 [RFC5245] is used). For this reason, it is attractive to use a 173 5-tuple for multiple media streams. 175 This specification defines a way to use a single address:port 176 combination (BUNDLE address) for receiving media specified by 177 multiple SDP media descriptions ("m=" lines). 179 This specification defines a new SDP Grouping Framework [RFC5888] 180 extension called 'BUNDLE'. The extension can be used with the 181 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 182 to negotiate the usage of a BUNDLE group. Within the BUNDLE group, a 183 BUNDLE address is used for receiving media specified by multiple "m=" 184 lines. This is referred to as bundled media. 186 The offerer and answerer [RFC3264] use the BUNDLE extension to 187 negotiate the BUNDLE addresses, one for the offerer (offerer BUNDLE 188 address) and one for the answerer (answerer BUNDLE address), to be 189 used for receiving the bundled media specified by a BUNDLE group. 190 Once the offerer and the answerer have negotiated a BUNDLE group, 191 they associate their respective BUNDLE address with each "m=" line in 192 the BUNDLE group. The BUNDLE addresses are used to receive all media 193 specified by the BUNDLE group. 195 The use of a BUNDLE group and a BUNDLE address also allows the usage 196 of a single set of Interactive Connectivity Establishment (ICE) 197 [RFC5245] candidates for multiple "m=" lines. 199 This specification also defines a new SDP attribute, 'bundle-only', 200 which can be used to request that specific media is only used if kept 201 within a BUNDLE group. The specification also updates RFC 3264, to 202 allow usage of zero port values without meaning that media is 203 rejected. 205 As defined in RFC 4566 [RFC4566], the semantics of assigning the same 206 transport address (IP address and port) to multiple "m=" lines are 207 undefined, and there is no grouping defined by such means. Instead, 208 an explicit grouping mechanism needs to be used to express the 209 intended semantics. This specification provides such an extension. 211 This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 212 [RFC3264]. The update allows an answerer to assign a non-zero port 213 value to an "m=" line in an SDP answer, even if the "m=" line in the 214 associated SDP offer contained a zero port value. 216 This specification also defines a new Real-time Transport Protocol 217 (RTP) [RFC3550] source description (SDES) item, 'MID', and a new RTP 218 SDES header extension that can be used to carry a value that 219 associates RTP/RTCP packets with a specific media description. This 220 can be used to correlate a RTP packet with the correct media. 222 SDP bodies can contain multiple BUNDLE groups. A given BUNDLE 223 address MUST only be associated with a single BUNDLE group. The 224 procedures in this specification apply independently to a given 225 BUNDLE group. All RTP based media flows described by a single BUNDLE 226 group belong to a single RTP session [RFC3550]. 228 The BUNDLE extension is backward compatible. Endpoints that do not 229 support the extension are expected to generate offers and answers 230 without an SDP 'group:BUNDLE' attribute, and are expected to 231 associate a unique address with each "m=" line within an offer and 232 answer, according to the procedures in [RFC4566] and [RFC3264] 234 2. Terminology 236 "m=" line: SDP bodies contain one or more media descriptions. Each 237 media description is identified by an SDP "m=" line. 239 5-tuple: A collection of the following values: source address, source 240 port, destination address, destination port, and transport-layer 241 protocol. 243 Unique address: An IP address and port combination that is associated 244 with only one "m=" line in an offer or answer. 246 Shared address: An IP address and port combination that is associated 247 with multiple "m=" lines within an offer or answer. 249 Offerer BUNDLE-tag: The first identification-tag in a given SDP 250 'group:BUNDLE' attribute identification-tag list in an offer. 252 Answerer BUNDLE-tag: The first identification-tag in a given SDP 253 'group:BUNDLE' attribute identification-tag list in an answer. 255 Offerer BUNDLE address: Within a given BUNDLE group, an IP address 256 and port combination used by an offerer to receive all media 257 specified by each "m=" line within the BUNDLE group. 259 Answerer BUNDLE address: Within a given BUNDLE group, an IP address 260 and port combination used by an answerer to receive all media 261 specified by each "m=" line within the BUNDLE group. 263 BUNDLE group: A set of "m=" lines, created using an SDP Offer/Answer 264 exchange, which uses the same BUNDLE address for receiving media. 266 Bundled "m=" line: An "m=" line, whose identification-tag is placed 267 in an SDP 'group:BUNDLE' attribute identification-tag list in an 268 offer or answer. 270 Bundle-only "m=" line: A bundled "m=" line with an associated SDP 271 'bundle-only' attribute. 273 Bundled media: All media specified by a given BUNDLE group. 275 Initial offer: The first offer, within an SDP session (e.g. a SIP 276 dialog when the Session Initiation Protocol (SIP) [RFC3261] is used 277 to carry SDP), in which the offerer indicates that it wants to create 278 a given BUNDLE group. 280 Subsequent offer: An offer which contains a BUNDLE group that has 281 been created as part of a previous offer/answer exchange. 283 Identification-tag: A unique token value that is used to identify an 284 "m=" line. The SDP 'mid' attribute [RFC5888], associated with an 285 "m=" line, carries an unique identification-tag. The session-level 286 SDP 'group' attribute [RFC5888] carries a list of identification- 287 tags, identifying the "m=" lines associated with that particular 288 'group' attribute. 290 3. Conventions 292 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 293 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 294 document are to be interpreted as described in BCP 14, RFC 2119 295 [RFC2119]. 297 4. Applicability Statement 299 The mechanism in this specification only applies to the Session 300 Description Protocol (SDP) [RFC4566], when used together with the SDP 301 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 302 scope of this document, and is thus undefined. 304 5. SDP Grouping Framework BUNDLE Extension 306 This section defines a new SDP Grouping Framework extension 307 [RFC5888], 'BUNDLE'. The BUNDLE extension can be used with the SDP 308 Offer/Answer mechanism to negotiate the usage of a single 309 address:port combination (BUNDLE address) for receiving bundled 310 media. 312 A single address:port combination is also used for sending bundled 313 media. The address:port combination used for sending bundled media 314 MAY be the same as the BUNDLE address, used to receive bundled media, 315 depending on whether symmetric RTP [RFC4961] is used. 317 All media associated with a BUNDLE group MUST be transport using the 318 same transport-layer protocol (e.g., UDP or TCP). 320 The BUNDLE extension is indicated using an SDP 'group' attribute with 321 a "BUNDLE" semantics value [RFC5888]. An identification-tag is 322 associated with each bundled "m=" line, and each identification-tag 323 is listed in the SDP 'group:BUNDLE' attribute identification-tag 324 list. Each "m=" line whose identification-tag is listed in the 325 identification-tag list is associated with a given BUNDLE group. 327 SDP bodies can contain multiple BUNDLE groups. Any given bundled 328 "m=" line MUST NOT be associated with more than one BUNDLE group. 330 NOTE: The order of the "m=" lines listed in the SDP 'group:BUNDLE' 331 attribute identification-tag list does not have to be the same as the 332 order in which the "m=" lines occur in the SDP. 334 Section 8 defines the detailed SDP Offer/Answer procedures for the 335 BUNDLE extension. 337 6. SDP 'bundle-only' Attribute 339 This section defines a new SDP media-level attribute [RFC4566], 340 'bundle-only'. 'bundle-only' is a property attribute [RFC4566], and 341 hence has no value. 343 Name: bundle-only 345 Value: N/A 347 Usage Level: media 349 Charset Dependent: no 351 Example: 353 a=bundle-only 355 In order to ensure that an answerer that does not support the BUNDLE 356 extension always rejects a bundled "m=" line, the offerer can assign 357 a zero port value to the "m=" line. According to [RFC3264] an 358 answerer will reject such "m=" line. By associating an SDP 'bundle- 359 only' attribute with such "m=" line, the offerer can request that the 360 answerer accepts the "m=" line if the answerer supports the Bundle 361 extension, and if the answerer keeps the "m=" line within the 362 associated BUNDLE group. 364 NOTE: Once the offerer BUNDLE address has been selected, the offerer 365 does not need to include the 'bundle-only' attribute in subsequent 366 offers. By associating the offerer BUNDLE address with an "m=" line 367 of a subsequent offer, the offerer will ensure that the answerer will 368 either keep the "m=" line within the BUNDLE group, or the answerer 369 will have to reject the "m=" line. 371 The usage of the 'bundle-only' attribute is only defined for a 372 bundled "m=" line with a zero port value, within an offer. Other 373 usage is unspecified. 375 Section 8 defines the detailed SDP Offer/Answer procedures for the 376 'bundle-only' attribute. 378 7. SDP Information Considerations 380 This section describes restrictions associated with the usage of SDP 381 parameters within a BUNDLE group. It also describes, when parameter 382 and attribute values have been associated with each bundled "m=" 383 line, how to calculate a value for the whole BUNDLE group. 385 7.1. Connection Data (c=) 387 The "c=" line nettype value [RFC4566] associated with a bundled "m=" 388 line MUST be 'IN'. 390 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" 391 line MUST be 'IP4' or 'IP6'. The same value MUST be associated with 392 each "m=" line. 394 NOTE: Extensions to this specification can specify usage of the 395 BUNDLE mechanism for other nettype and addrtype values than the ones 396 listed above. 398 7.2. Bandwidth (b=) 400 An offerer and answerer MUST use the rules and restrictions defined 401 in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP 402 bandwidth (b=) line with bundled "m=" lines. 404 7.3. Attributes (a=) 406 An offerer and answerer MUST use the rules and restrictions defined 407 in [I-D.ietf-mmusic-sdp-mux-attributes] for associating SDP 408 attributes with bundled "m=" lines. 410 8. SDP Offer/Answer Procedures 412 This section describes the SDP Offer/Answer [RFC3264] procedures for: 414 o Negotiating and creating a BUNDLE group; and 416 o Selecting the BUNDLE addresses (offerer BUNDLE address and 417 answerer BUNDLE address); and 419 o Adding an "m=" line to a BUNDLE group; and 421 o Moving an "m=" line out of a BUNDLE group; and 423 o Disabling an "m=" line within a BUNDLE group. 425 The generic rules and procedures defined in [RFC3264] and [RFC5888] 426 also apply to the BUNDLE extension. For example, if an offer is 427 rejected by the answerer, the previously negotiated SDP parameters 428 and characteristics (including those associated with a BUNDLE group) 429 apply. Hence, if an offerer generates an offer in which the offerer 430 wants to create a BUNDLE group, and the answerer rejects the offer, 431 the BUNDLE group is not created. 433 The procedures in this section are independent of the media type or 434 "m=" line proto value represented by a bundled "m=" line. Section 10 435 defines additional considerations for RTP based media. Section 6 436 defines additional considerations for the usage of the SDP 'bundle- 437 only' attribute. Section 11 defines additional considerations for 438 the usage of Interactive Connectivity Establishment (ICE) 439 [I-D.ietf-ice-rfc5245bis] mechanism. 441 SDP offers and answers can contain multiple BUNDLE groups. The 442 procedures in this section apply independently to a given BUNDLE 443 group. 445 8.1. Mux Category Considerations 447 When an offerer associates SDP attributes with a bundled "m=" line 448 associated with a shared address, IDENTICAL and TRANSPORT mux 449 category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are 450 associated with the "m=" line only if the "m=" line is also 451 associated with the offerer BUNDLE-tag. Otherwise the offerer MUST 452 NOT associate such SDP attributes with the "m=" line. 454 When an answerer associates SDP attributes with a bundled "m=" line, 455 IDENTICAL and TRANSPORT mux category SDP attributes are associated 456 with the "m=" line only if the "m=" line is also associated with the 457 answerer BUNDLE-tag. Otherwise the answerer MUST NOT associated such 458 SDP attributes with the "m=" line. 460 NOTE: As bundled "m=" lines associated with a shared address will 461 share the same IDENTICAL and TRANSPORT mux category SDP attributes, 462 and attribute values, there is no need to associate such SDP 463 attributes with each "m=" line. The attributes and attribute values 464 are implicitly applied to each "m=" line associated with the shared 465 address. 467 8.2. Generating the Initial SDP Offer 469 When an offerer generates an initial offer, in order to create a 470 BUNDLE group, it MUST: 472 o Assign a unique address to each "m=" line within the offer, 473 following the procedures in [RFC3264], unless the media line is a 474 'bundle-only' "m=" line (see below); and 476 o Add an SDP 'group:BUNDLE' attribute to the offer; and 478 o Place the identification-tag of each bundled "m=" line in the SDP 479 'group:BUNDLE' attribute identification-tag list; and 481 o Indicate which unique address the offerer suggests as the offerer 482 BUNDLE address [Section 8.2.1]. 484 If the offerer wants to request that the answerer accepts a given 485 bundled "m=" line only if the answerer keeps the "m=" line within the 486 BUNDLE group, the offerer MUST: 488 o Associate an SDP 'bundle-only' attribute [Section 8.2.1] with the 489 "m=" line; and 491 o Assign a zero port value to the "m=" line. 493 NOTE: If the offerer assigns a zero port value to an "m=" line, but 494 does not also associate an SDP 'bundle-only' attribute with the "m=" 495 line, it is an indication that the offerer wants to disable the "m=" 496 line [Section 8.5.4]. 498 [Section 17.1] shows an example of an initial offer. 500 8.2.1. Suggesting the offerer BUNDLE address 502 In the offer, the address associated with the "m=" line associated 503 with the offerer BUNDLE-tag indicates the address that the offerer 504 suggests as the offerer BUNDLE address. 506 The "m=" line associated with the offerer BUNDLE-tag MUST NOT contain 507 a zero port value or an SDP 'bundle-only' attribute. 509 8.2.2. Example: Initial SDP Offer 511 The example shows an initial SDP offer. The offer includes two "m=" 512 lines in the SDP, and suggests that both are included in a BUNDLE 513 group. The audio "m=" line is associated with the offerer BUNDLE-tag 514 (placed first in the SDP group:BUNDLE attribute identificatoin-id 515 list). 517 SDP Offer 519 v=0 520 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 521 s= 522 c=IN IP4 atlanta.example.com 523 t=0 0 524 a=group:BUNDLE foo bar 525 m=audio 10000 RTP/AVP 0 8 97 526 b=AS:200 527 a=mid:foo 528 a=rtcp-mux 529 a=rtpmap:0 PCMU/8000 530 a=rtpmap:8 PCMA/8000 531 a=rtpmap:97 iLBC/8000 532 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 533 m=video 10002 RTP/AVP 31 32 534 b=AS:1000 535 a=mid:bar 536 a=rtcp-mux 537 a=rtpmap:31 H261/90000 538 a=rtpmap:32 MPV/90000 539 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 541 8.3. Generating the SDP Answer 543 When an answerer generates an answer that contains a BUNDLE group, 544 the following general SDP grouping framework restrictions, defined in 545 [RFC5888], also apply to the BUNDLE group: 547 o The answerer MUST NOT include a BUNDLE group in the answer, unless 548 the offerer requested the BUNDLE group to be created in the 549 corresponding offer; and 551 o The answerer MUST NOT include an "m=" line within a BUNDLE group, 552 unless the offerer requested the "m=" line to be within that 553 BUNDLE group in the corresponding offer. 555 If the answer contains a BUNDLE group, the answerer MUST: 557 o Select an Offerer BUNDLE Address [Section 8.3.1]; and 559 o Select an Answerer BUNDLE Address [Section 8.3.2]; 561 The answerer is allowed to select a new Answerer BUNDLE address each 562 time it generates an answer to an offer. 564 If the answerer does not want to keep an "m=" line within a BUNDLE 565 group, it MUST: 567 o Move the "m=" line out of the BUNDLE group [Section 8.3.3]; or 569 o Reject the "m=" line [Section 8.3.4]; 571 If the answerer keeps a bundle-only "m=" line within the BUNDLE 572 group, it follows the procedures (associates the answerer BUNDLE 573 address with the "m=" line etc) for any other "m=" line kept within 574 the BUNDLE group. 576 If the answerer does not want to keep a bundle-only "m=" line within 577 the BUNDLE group, it MUST reject the "m=" line [Section 8.3.4]. 579 The answerer MUST NOT associate an SDP 'bundle-only' attribute with 580 any "m=" line in an answer. 582 NOTE: If a bundled "m=" line in an offer contains a zero port value, 583 but the "m=" line does not contain an SDP 'bundle-only' attribute, it 584 is an indication that the offerer wants to disable the "m=" line 585 [Section 8.5.4]. 587 8.3.1. Answerer Selection of Offerer Bundle Address 589 In an offer, the address (unique or shared) associated with the 590 bundled "m=" line associated with the offerer BUNDLE-tag indicates 591 the address that the offerer suggests as the offerer BUNDLE address 592 [Section 8.2.1]. The answerer MUST check whether that "m=" line 593 fulfils the following criteria: 595 o The answerer will not move the "m=" line out of the BUNDLE group 596 [Section 8.3.3]; and 598 o The answerer will not reject the "m=" line [Section 8.3.4]; and 600 o The "m=" line does not contain a zero port value. 602 If all of the criteria above are fulfilled, the answerer MUST select 603 the address associated with the "m=" line as the offerer BUNDLE 604 address. In the answer, the answerer BUNDLE-tag represents the "m=" 605 line, and the address associated with the "m=" line in the offer 606 becomes the offerer BUNDLE address. 608 If one or more of the criteria are not fulfilled, the answerer MUST 609 select the next identification-tag in the identification-tag list, 610 and perform the same criteria check for the "m=" line associated with 611 that identification-tag. If there are no more identification-tags in 612 the identification-tag list, the answerer MUST NOT create the BUNDLE 613 group. In addition, unless the answerer rejects the whole offer, the 614 answerer MUST apply the answerer procedures for moving an "m=" line 615 out of a BUNDLE group [Section 8.3.3] to each bundled "m=" line in 616 the offer when creating the answer. 618 [Section 17.1] shows an example of an offerer BUNDLE address 619 selection. 621 8.3.2. Answerer Selection of Answerer BUNDLE Address 623 When the answerer selects a BUNDLE address for itself, referred to as 624 the answerer BUNDLE address, it MUST associate that address with each 625 bundled "m=" line within the created BUNDLE group in the answer. 627 The answerer MUST NOT associate the answerer BUNDLE address with an 628 "m=" line that is not within the BUNDLE group, or to an "m=" line 629 that is within another BUNDLE group. 631 [Section 17.1] shows an example of an answerer BUNDLE address 632 selection. 634 8.3.3. Moving A Media Description Out Of A BUNDLE Group 636 When an answerer wants to move an "m=" line out of a BUNDLE group, it 637 MUST first check the following criteria: 639 o In the corresponding offer, the "m=" line is associated with a 640 shared address (e.g. a previously selected offerer BUNDLE 641 address); or 643 o In the corresponding offer, an SDP 'bundle-only' attribute is 644 associated with the "m=" line, and the "m=" line contains a zero 645 port value. 647 If either criteria above is fulfilled, the answerer MUST reject the 648 "m=" line [Section 8.3.4]. 650 Otherwise, if in the corresponding offer the "m=" line is associated 651 with a unique address, the answerer MUST associate a unique address 652 with the "m=" line in the answer (the answerer does not reject the 653 "m=" line). 655 In addition, in either case above, the answerer MUST NOT place the 656 identification-tag, associated with the moved "m=" line, in the SDP 657 'group' attribute identification-tag list associated with the BUNDLE 658 group. 660 8.3.4. Rejecting A Media Description In A BUNDLE Group 662 When an answerer rejects an "m=" line, it MUST associate an address 663 with a zero port value with the "m=" line in the answer, according to 664 the procedures in [RFC3264]. 666 In addition, the answerer MUST NOT place the identification-tag, 667 associated with the rejected "m=" line, in the SDP 'group' attribute 668 identification-tag list associated with the BUNDLE group. 670 8.3.5. Example: SDP Answer 672 The example shows an SDP answer, based on the SDP offer in 673 [Section 8.2.2]. The answers acceppts both "m=" lines in the BUNDLE 674 group. 676 SDP Answer 678 v=0 679 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 680 s= 681 c=IN IP4 biloxi.example.com 682 t=0 0 683 a=group:BUNDLE foo bar 684 m=audio 20000 RTP/AVP 0 685 b=AS:200 686 a=mid:foo 687 a=rtcp-mux 688 a=rtpmap:0 PCMU/8000 689 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 690 m=video 20000 RTP/AVP 32 691 b=AS:1000 692 a=mid:bar 693 a=rtcp-mux 694 a=rtpmap:32 MPV/90000 695 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 697 8.4. Offerer Processing of the SDP Answer 699 When an offerer receives an answer, if the answer contains a BUNDLE 700 group, the offerer MUST check that any bundled "m=" line in the 701 answer was indicated as bundled in the corresponding offer. If there 702 is no mismatch, the offerer MUST use the offerer BUNDLE address, 703 selected by the answerer [Section 8.3.1], as the address for each 704 bundled "m=" line. 706 NOTE: As the answerer might reject one or more bundled "m=" lines, or 707 move a bundled "m=" line out of a BUNDLE group, each bundled "m=" 708 line in the offer might not be indicated as bundled in the answer. 710 If the answer does not contain a BUNDLE group, the offerer MUST 711 process the answer as a normal answer. 713 8.5. Modifying the Session 715 When an offerer generates a subsequent offer, it MUST associate the 716 previously selected offerer BUNDLE address [Section 8.3.1] with each 717 bundled "m=" line (including any bundle-only "m=" line), except if: 719 o The offerer suggests a new offerer BUNDLE address [Section 8.5.1]; 720 or 722 o The offerer wants to add a bundled "m=" line to the BUNDLE group 723 [Section 8.5.2]; or 725 o The offerer wants to move a bundled "m=" line out of the BUNDLE 726 group [Section 8.5.3]; or 728 o The offerer wants to disable the bundled "m=" line 729 [Section 8.5.4]. 731 In addition, the offerer MUST select an offerer BUNDLE-tag 732 [Section 8.2.1] associated with the previously selected offerer 733 BUNDLE address, unless the offerer suggests a new offerer BUNDLE 734 address. 736 8.5.1. Suggesting a new offerer BUNDLE address 738 When an offerer generates an offer, in which it suggests a new 739 offerer BUNDLE address [Section 8.2.1], the offerer MUST: 741 o Assign the address (shared address) to each "m=" line within the 742 BUNDLE group; or 744 o Assign the address (unique address) to one bundled "m=" line. 746 In addition, the offerer MUST indicate that the address is the new 747 suggested offerer BUNDLE address [Section 8.2.1]. 749 NOTE: Unless the offerer associates the new suggested offerer BUNDLE 750 address with each bundled "m=" line, it can associate unique 751 addresses with any number of bundled "m=" lines (and the previously 752 selected offerer BUNDLE address to any remaining bundled "m=" line) 753 if it wants to suggest multiple alternatives for the new offerer 754 BUNDLE address. 756 8.5.2. Adding a media description to a BUNDLE group 758 When an offerer generates an offer, in which it wants to add a 759 bundled "m=" line to a BUNDLE group, the offerer MUST: 761 o Assign a unique address to the added "m=" line; or 763 o Assign the previously selected offerer BUNDLE address to the added 764 "m=" line; or 766 o If the offerer associates a new (shared address) suggested offerer 767 BUNDLE address with each bundled "m=" line [Section 8.5.1], also 768 associate that address with the added "m=" line. 770 In addition, the offerer MUST add the identification-tag associated 771 with the added "m=" line to the SDP 'group:BUNDLE' attribute 772 identification-tag list with the BUNDLE group [Section 8.2.1]. 774 NOTE: Assigning a unique address to the "m=" line allows the answerer 775 to move the "m=" line out of the BUNDLE group [Section 8.3.3], 776 without having to reject the "m=" line. 778 If the offerer associates a unique address with the added "m=" line, 779 and if the offerer suggests that address as the new offerer BUNDLE 780 address [Section 8.5.1], the offerer BUNDLE-tag MUST represent the 781 added "m=" line [Section 8.2.1]. 783 If the offerer associates a new suggested offerer BUNDLE address with 784 each bundled "m=" line [Section 8.5.1], including the added "m=" 785 line, the offerer BUNDLE-tag MAY represent the added "m=" line 786 [Section 8.2.1]. 788 [Section 17.3] shows an example where an offerer sends an offer in 789 order to add a bundled "m=" line to a BUNDLE group. 791 8.5.3. Moving A Media Description Out Of A BUNDLE Group 793 When an offerer generates an offer, in which it wants to move a 794 bundled "m=" line out of a BUNDLE group it was added to in a previous 795 offer/answer transaction, the offerer: 797 o MUST associate a unique address with the "m=" line; and 798 o MUST NOT place the identification-tag associated with the "m=" 799 line in the SDP 'group:BUNDLE' attribute identification-tag list 800 associated with the BUNDLE group. 802 NOTE: If the removed "m=" line is associated with the previously 803 selected BUNDLE-tag, the offerer needs to suggest a new BUNDLE-tag 804 [Section 8.2.1]. 806 NOTE: If an "m=" line, when being moved out of a BUNDLE group, is 807 added to another BUNDLE group, the offerer applies the procedures in 808 [Section 8.5.2] to the "m=" line. 810 [Section 17.4] shows an example of an offer for moving an "m=" line 811 out of a BUNDLE group. 813 8.5.4. Disabling A Media Description In A BUNDLE Group 815 When an offerer generates an offer, in which it wants to disable a 816 bundled "m=" line (added to the BUNDLE group in a previous offer/ 817 answer transaction), the offerer: 819 o MUST associate an address with a zero port value with the "m=" 820 line, following the procedures in [RFC4566]; and 822 o MUST NOT place the identification-tag associated with the "m=" 823 line in the SDP 'group:BUNDLE' attribute identification-tag list 824 associated with the BUNDLE group. 826 [Section 17.5] shows an example of an offer for disabling an "m=" 827 line within a BUNDLE group. 829 9. Protocol Identification 831 Each "m=" line within a BUNDLE group MUST use the same transport- 832 layer protocol. If bundled "m=" lines use different protocols on top 833 of the transport-layer protocol, there MUST exist a publicly 834 available specification which describes a mechanism, for this 835 particular protocol combination, how to associate received data with 836 the correct protocol. 838 In addition, if received data can be associated with more than one 839 bundled "m=" line, there MUST exist a publicly available 840 specification which describes a mechanism for associating the 841 received data with the correct "m=" line. 843 This document describes a mechanism to identify the protocol of 844 received data among the STUN, DTLS and SRTP protocols (in any 845 combination), when UDP is used as transport-layer protocol, but does 846 not describe how to identify different protocols transported on DTLS. 847 While the mechanism is generally applicable to other protocols and 848 transport-layer protocols, any such use requires further 849 specification around how to multiplex multiple protocols on a given 850 transport-layer protocol, and how to associate received data with the 851 correct protocols. 853 9.1. STUN, DTLS, SRTP 855 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 856 protocol of a received packet among the STUN, Datagram Transport 857 Layer Security (DTLS) and SRTP protocols (in any combination). If an 858 offer or answer includes bundled "m=" lines that represent these 859 protocols, the offerer or answerer MUST support the mechanism 860 described in [RFC5764], and no explicit negotiation is required in 861 order to indicate support and usage of the mechanism. 863 [RFC5764] does not describe how to identify different protocols 864 transported on DTLS, only how to identify the DTLS protocol itself. 865 If multiple protocols are transported on DTLS, there MUST exist a 866 specification describing a mechanism for identifying each individual 867 protocol. In addition, if a received DTLS packet can be associated 868 with more than one "m=" line, there MUST exist a specification which 869 describes a mechanism for associating the received DTLS packet with 870 the correct "m=" line. 872 [Section 10.2] describes how to associate a received (S)RTP packet 873 with the correct "m=" line. 875 10. RTP Considerations 877 10.1. Single RTP Session 879 All RTP-based media within a single BUNDLE group belong to a single 880 RTP session [RFC3550]. Disjoint BUNDLE groups will form multiple RTP 881 sessions, one per BUNDLE group. 883 Since a single RTP session is used for each bundle group, all "m=" 884 lines representing RTP-based media in a bundle group will share a 885 single SSRC numbering space [RFC3550]. 887 The following rules and restrictions apply for a single RTP session: 889 o A specific payload type value can be used in multiple bundled "m=" 890 lines only if each codec associated with the payload type number 891 shares an identical codec configuration [Section 10.1.1]. 893 o The proto value in each bundled RTP-based "m=" line MUST be 894 identical (e.g. RTP/AVPF). 896 o The RTP MID header extension MUST be enabled, by associating an 897 SDP 'extmap' attribute [RFC5285], with a 'urn:ietf:params:rtp- 898 hdrext:sdes:mid' URI value, with each bundled RTP-based "m=" line 899 in every offer and answer. 901 o A given SSRC MUST NOT transmit RTP packets using payload types 902 that originate from different bundled "m=" lines. 904 NOTE: The last bullet above is to avoid sending multiple media types 905 from the same SSRC. If transmission of multiple media types are done 906 with time overlap, RTP and RTCP fail to function. Even if done in 907 proper sequence this causes RTP Timestamp rate switching issues 908 [RFC7160]. However, once an SSRC has left the RTP session (by 909 sending an RTCP BYE packet), that SSRC can be reused by another 910 source (possibly associated with a different bundled "m=" line) after 911 a delay of 5 RTCP reporting intervals (the delay is to ensure the 912 SSRC has timed out, in case the RTCP BYE packet was lost [RFC3550]). 914 10.1.1. Payload Type (PT) Value Reuse 916 Multiple bundled "m=" lines might represent RTP based media. As all 917 RTP based media specified by a BUNDLE group belong to the same RTP 918 session, in order for a given payload type value to be used inside 919 more than one bundled "m=" line, all codecs associated with the 920 payload type number MUST share an identical codec configuration. 921 This means that the codecs MUST share the same media type, encoding 922 name, clock rate and any parameter that can affect the codec 923 configuration and packetization. 924 [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose 925 attribute values must be identical for all codecs that use the same 926 payload type value. 928 10.2. Associating RTP/RTCP Packets With Correct SDP Media Description 930 There are multiple mechanisms that can be used by an endpoint in 931 order to associate received RTP/RTCP packets with a bundled "m=" 932 line. Such mechanisms include using the payload type value carried 933 inside the RTP packets, the SSRC values carried inside the RTP 934 packets, and other "m=" line specific information carried inside the 935 RTP packets. 937 As all RTP/RTCP packets associated with a BUNDLE group are received 938 (and sent) using single address:port combinations, the local 939 address:port combination cannot be used to associate received RTP 940 packets with the correct "m=" line. 942 As described in [Section 10.1.1], the same payload type value might 943 be used inside RTP packets described by multiple "m=" lines. In such 944 cases, the payload type value cannot be used to associate received 945 RTP packets with the correct "m=" line. 947 An offerer and answerer can inform each other which SSRC values they 948 will use for RTP and RTCP by using the SDP 'ssrc' attribute 949 [RFC5576]. To allow for proper association with this mechanism, the 950 'ssrc' attribute needs to be associated with each "m=" line that 951 shares a payload type with any other "m=" line in the same bundle. 952 As the SSRC values will be carried inside the RTP/RTCP packets, the 953 offerer and answerer can then use that information to associate 954 received RTP packets with the correct "m=" line. However, an offerer 955 will not know which SSRC values the answerer will use until it has 956 received the answer providing that information. Due to this, before 957 the offerer has received the answer, the offerer will not be able to 958 associate received RTP/RTCP packets with the correct "m=" line using 959 the SSRC values. 961 In order for an offerer and answerer to always be able to associate 962 received RTP and RTCP packets with the correct "m=" line, an offerer 963 and answerer using the BUNDLE extension MUST support the mechanism 964 defined in Section 14, where the remote endpoint inserts the 965 identification-tag associated with an "m=" line in RTP and RTCP 966 packets associated with that "m=" line. 968 10.3. RTP/RTCP Multiplexing 970 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 971 multiplexing [RFC5761] for the RTP-based media specified by the 972 BUNDLE group. 974 When RTP/RTCP multiplexing is enabled, the same address:port 975 combination will be used for sending all RTP packets and the RTCP 976 packets associated with the BUNDLE group. Each endpoint will send 977 the packets towards the BUNDLE address of the other endpoint. The 978 same address:port combination MAY be used for receiving RTP packets 979 and RTCP packets. 981 10.3.1. SDP Offer/Answer Procedures 983 This section describes how an offerer and answerer use the SDP 'rtcp- 984 mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute 985 [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP 986 multiplexing for RTP-based media specified by a BUNDLE group. 988 The procedures in this section only apply to RTP-based "m=" lines. 990 10.3.1.1. Generating the Initial SDP Offer 992 When an offerer generates an initial offer, the offerer MUST 993 associate either an SDP 'rtcp-mux' attribute [RFC5761] or an SDP 994 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] with each 995 bundled RTP-based "m=" line in the offer. The offerer MUST associate 996 an SDP 'rtcp-mux-only' attribute with each bundle-only "m=" line. If 997 the offerer associates a 'rtcp-mux-only' attribute with an "m=" line, 998 the offerer may also associate a 'rtcp-mux' attribute with the same 999 "m=" line, as described in [I-D.ietf-mmusic-mux-exclusive]. 1001 NOTE: Within a BUNDLE group, the offerer can associate the SDP 'rtcp- 1002 mux' attribute with some of the RTP-based "m=" lines, while it 1003 associates the SDP 'rtcp-mux-only' attribute to other RTP-based "m=" 1004 lines, depending on whether the offerer supports fallback to usage of 1005 a separate port for RTCP in case the answerer does not include the 1006 "m=" line in the BUNDLE group. 1008 NOTE: If the offerer associates an SDP 'rtcp-mux' attribute with an 1009 "m=" line, the offerer can also associate an SDP 'rtcp' attribute 1010 [RFC3605] with a bundled "m=" line, excluding a bundle-only "m=" 1011 line, in order to provide a fallback port for RTCP, as described in 1012 [RFC5761]. However, the fallback port will only be used in case the 1013 answerer does not include the "m=" line in the BUNDLE group in the 1014 associated answer. 1016 In the initial offer, the address:port combination for RTCP MUST be 1017 unique in each bundled RTP-based "m=" line (excluding a 'bundle-only' 1018 "m=" line), similar to RTP. 1020 10.3.1.2. Generating the SDP Answer 1022 When an answerer generates an answer, if the answerer accepts one or 1023 more RTP-based "m=" lines within a BUNDLE group, the answerer MUST 1024 enable usage of RTP/RTCP multiplexing. The answerer MUST associate 1025 an SDP "rtcp-mux" attribute with each RTP-based "m=" line in the 1026 answer. In addition, if an "m=" line in the corresponding offer 1027 contained an SDP "rtcp-mux-only" attribute, the answerer MUST also 1028 associate an SDP "rtcp-mux-only" attribute with the "m=" line in the 1029 answer. 1031 If an RTP-based "m=" line in the corresponding offer did not contain 1032 an SDP "rtcp-mux" attribute or an SDP "rtcp-mux-only" attribute, the 1033 answerer MUST NOT include the "m=" line within a BUNDLE group in the 1034 answer. 1036 If an RTP-based "m=" line in the corresponding offer contained an SDP 1037 "rtcp-mux-only" attribute, and if the answerer moves the "m=" line 1038 out of the BUNDLE group in the answer Section 8.3.3, the answerer 1039 MUST still either enable RTP/RTCP multiplexing for the media 1040 associated with the "m=" line, or reject the "m=" line Section 8.3.4. 1042 The answerer MUST NOT associate an SDP 'rtcp' attribute with any 1043 bundled "m=" line in the answer. The answerer will use the port 1044 value of the selected offerer BUNDLE address for sending RTP and RTCP 1045 packets associated with each RTP-based bundled "m=" line towards the 1046 offerer. 1048 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1049 negotiated in a previous offer/answer transaction, the answerer MUST 1050 associate an SDP 'rtcp-mux' attribute with each bundled RTP-based 1051 "m=" line in the answer. 1053 10.3.1.3. Offerer Processing of the SDP Answer 1055 When an offerer receives an answer, if the answerer has accepted the 1056 usage of RTP/RTCP multiplexing (see Section 10.3.1.2), the answerer 1057 follows the procedures for RTP/RTCP multiplexing defined in 1058 [RFC5761]. The offerer will use the port value associated with the 1059 answerer BUNDLE address for sending RTP and RTCP packets associated 1060 with each RTP-based bundled "m=" line towards the answerer. 1062 NOTE: It is considered a protocol error if the answerer has not 1063 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" lines 1064 that the answerer included in the BUNDLE group. 1066 10.3.1.4. Modifying the Session 1068 When an offerer generates a subsequent offer, it MUST associate an 1069 SDP 'rtcp-mux' attribute or an SDP 'rtcp-mux-only' attribute with 1070 each RTP-based bundled "m=" line within the BUNDLE group (including 1071 any bundled RTP-based "m=" line that the offerer wants to add to the 1072 BUNDLE group), unless the offerer wants to disable or remove the "m=" 1073 line from the BUNDLE group. 1075 11. ICE Considerations 1077 This section describes how to use the BUNDLE grouping extension 1078 together with the Interactive Connectivity Establishment (ICE) 1079 mechanism [I-D.ietf-ice-rfc5245bis]. 1081 The generic procedures for negotiating usage of ICE using SDP, 1082 defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE 1083 with BUNDLE, with the following exceptions: 1085 o When BUNDLE addresses for a BUNDLE group have been selected for 1086 both endpoints, ICE connectivity checks and keep-alives only need 1087 to be performed for the whole BUNDLE group, instead of per bundled 1088 "m=" line. 1090 o Among bundled "m=" lines with which the offerer has associated a 1091 shared address, the offerer only associates ICE-related media- 1092 level SDP attributes with the "m=" line associated with the 1093 offerer BUNDLE-tag. 1095 o Among bundled "m=" lines with which the answerer has associated a 1096 shared address, the answerer only associates ICE-related media- 1097 level SDP attributes with the "m=" line associated with the 1098 answerer BUNDLE-tag. 1100 Support and usage of ICE mechanism together with the BUNDLE extension 1101 is OPTIONAL. 1103 11.1. SDP Offer/Answer Procedures 1105 When an offerer associates a unique address with a bundled "m=" line 1106 (excluding any bundle-only "m=" line), the offerer MUST associate SDP 1107 'candidate' attributes (and other applicable ICE-related media-level 1108 SDP attributes), containing unique ICE properties (candidates etc), 1109 with the "m=" line, according to the procedures in 1110 [I-D.ietf-mmusic-ice-sip-sdp]. 1112 When an offerer associates a shared address with a bundled "m=" line, 1113 if the "m=" line is associated with the offerer BUNDLE-tag, the 1114 offerer MUST associate SDP 'candidate' attributes (and other 1115 applicable ICE-related media-level SDP attributes), containing shared 1116 ICE properties, with the "m=" line. If the "m=" line is not 1117 associated with the offerer BUNDLE-tag, the offerer MUST NOT 1118 associate ICE-related SDP attributes with the "m=" line. 1120 When an answerer associates a shared address with a bundled "m=" 1121 line, if the "m=" line is associated with the answerer BUNDLE-tag, 1122 the answerer MUST associate SDP 'candidate' attributes (and other 1123 applicable ICE-related media-level SDP attributes), containing shared 1124 ICE properties, with the "m=" line. If the "m=" line is not 1125 associated with the answerer BUNDLE-tag, the answerer MUST NOT 1126 associate ICE-related SDP attributes with the "m=" line. 1128 NOTE: As most ICE-related media-level SDP attributes belong to the 1129 TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the 1130 offerer and answerer follow the rules in Section 8.1. However, in 1131 the case of ICE-related media-level attributes, the rules apply to 1132 all attributes (see note below), even if they belong to a different 1133 mux category. 1135 NOTE: The following ICE-related media-level SDP attributes are 1136 defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote- 1137 candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- 1138 pacing'. 1140 11.1.1. Generating the Initial SDP Offer 1142 When an offerer generates an initial offer, the offerer MUST 1143 associate ICE-related media-level SDP attributes with each bundled 1144 "m=" line, according to [Section 11.1]. 1146 11.1.2. Generating the SDP Answer 1148 When an answerer generates an answer that contains a BUNDLE group, 1149 the answerer MUST associate ICE-related SDP attributes with the "m=" 1150 line associated with the answerer BUNDLE-tag, according to 1151 [Section 11.1]. 1153 11.1.3. Offerer Processing of the SDP Answer 1155 When an offerer receives an answer, if the answerer supports and uses 1156 the ICE mechanism and the BUNDLE extension, the offerer MUST 1157 associate the ICE properties associated with the offerer BUNDLE 1158 address, selected by the answerer [Section 8.3.1], with each bundled 1159 "m=" line. 1161 11.1.4. Modifying the Session 1163 When an offerer generates a subsequent offer, it MUST associate 1164 unique or shared ICE properties to one or more bundled "m=" lines, 1165 according to [Section 11.1]. 1167 12. DTLS Considerations 1169 One or more media streams within a BUNDLE group might use the 1170 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1171 to encrypt the data, or to negotiate encryption keys if another 1172 encryption mechanism is used to encrypt media. 1174 When DTLS is used within a BUNDLE group, the following rules apply: 1176 o There can only be one DTLS association [RFC6347] associated with 1177 the BUNDLE group; and 1179 o Each usage of the DTLS association within the BUNDLE group MUST 1180 use the same mechanism for determining which endpoints (the 1181 offerer or answerer) become DTLS client and DTLS server; and 1183 o Each usage of the DTLS association within the Bundle group MUST 1184 use the same mechanism for determining whether an offer or answer 1185 will trigger the establishment of a new DTLS association, or 1186 whether an existing DTLS association will be used; and 1188 o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include 1189 the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message 1190 [RFC5764], The client MUST include the extension even if the usage 1191 of DTLS-SRTP is not negotiated as part of the multimedia session 1192 (e.g., SIP session [RFC3261]. 1194 NOTE: The inclusion of the 'use_srtp' extension during the initial 1195 DTLS handshake ensures that a DTLS renegotiation will not be required 1196 in order to include the extension, in case DTLS-SRTP encrypted media 1197 is added to the BUNDLE group later during the multimedia session. 1199 13. Update to RFC 3264 1201 This section replaces the text of the following sections of RFC 3264: 1203 o Section 5.1 (Unicast Streams). 1205 o Section 8.2 (Removing a Media Stream). 1207 o Section 8.4 (Putting a Unicast Media Stream on Hold). 1209 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 1211 For recvonly and sendrecv streams, the port number and address in the 1212 offer indicate where the offerer would like to receive the media 1213 stream. For sendonly RTP streams, the address and port number 1214 indirectly indicate where the offerer wants to receive RTCP reports. 1215 Unless there is an explicit indication otherwise, reports are sent to 1216 the port number one higher than the number indicated. The IP address 1217 and port present in the offer indicate nothing about the source IP 1218 address and source port of RTP and RTCP packets that will be sent by 1219 the offerer. A port number of zero in the offer indicates that the 1220 stream is offered but MUST NOT be used. This has no useful semantics 1221 in an initial offer, but is allowed for reasons of completeness, 1222 since the answer can contain a zero port indicating a rejected stream 1223 (Section 6). Furthermore, existing streams can be terminated by 1224 setting the port to zero (Section 8). In general, a port number of 1225 zero indicates that the media stream is not wanted. 1227 13.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 1229 For recvonly and sendrecv streams, the port number and address in the 1230 offer indicate where the offerer would like to receive the media 1231 stream. For sendonly RTP streams, the address and port number 1232 indirectly indicate where the offerer wants to receive RTCP reports. 1233 Unless there is an explicit indication otherwise, reports are sent to 1234 the port number one higher than the number indicated. The IP address 1235 and port present in the offer indicate nothing about the source IP 1236 address and source port of RTP and RTCP packets that will be sent by 1237 the offerer. A port number of zero in the offer by default indicates 1238 that the stream is offered but MUST NOT be used, but an extension 1239 mechanism might specify different semantics for the usage of a zero 1240 port value. Furthermore, existing streams can be terminated by 1241 setting the port to zero (Section 8). In general, a port number of 1242 zero by default indicates that the media stream is not wanted. 1244 13.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 1246 A stream that is offered with a port of zero MUST be marked with port 1247 zero in the answer. Like the offer, the answer MAY omit all 1248 attributes present previously, and MAY list just a single media 1249 format from amongst those in the offer. 1251 13.4. New text replacing section 8.2 (2nd paragraph) of RFC 3264 1253 A stream that is offered with a port of zero MUST by default be 1254 marked with port zero in the answer, unless an extension mechanism, 1255 which specifies semantics for the usage of a non-zero port value, is 1256 used. If the stream is marked with port zero in the answer, the 1257 answer MAY omit all attributes present previously, and MAY list just 1258 a single media format from amongst those in the offer." 1260 13.5. Original text of section 8.4 (6th paragraph) of RFC 3264 1262 RFC 2543 [10] specified that placing a user on hold was accomplished 1263 by setting the connection address to 0.0.0.0. Its usage for putting 1264 a call on hold is no longer recommended, since it doesn't allow for 1265 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1266 with connection oriented media. However, it can be useful in an 1267 initial offer when the offerer knows it wants to use a particular set 1268 of media streams and formats, but doesn't know the addresses and 1269 ports at the time of the offer. Of course, when used, the port 1270 number MUST NOT be zero, which would specify that the stream has been 1271 disabled. An agent MUST be capable of receiving SDP with a 1272 connection address of 0.0.0.0, in which case it means that neither 1273 RTP nor RTCP should be sent to the peer. 1275 13.6. New text replacing section 8.4 (6th paragraph) of RFC 3264 1277 RFC 2543 [10] specified that placing a user on hold was accomplished 1278 by setting the connection address to 0.0.0.0. Its usage for putting 1279 a call on hold is no longer recommended, since it doesn't allow for 1280 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1281 with connection oriented media. However, it can be useful in an 1282 initial offer when the offerer knows it wants to use a particular set 1283 of media streams and formats, but doesn't know the addresses and 1284 ports at the time of the offer. Of course, when used, the port 1285 number MUST NOT be zero, if it would specify that the stream has been 1286 disabled. However, an extension mechanism might specify different 1287 semantics of the zero port number usage. An agent MUST be capable of 1288 receiving SDP with a connection address of 0.0.0.0, in which case it 1289 means that neither RTP nor RTCP should be sent to the peer. 1291 14. RTP/RTCP extensions for identification-tag transport 1293 SDP Offerers and Answerers [RFC3264] can associate identification- 1294 tags with "m=" lines within SDP Offers and Answers, using the 1295 procedures in [RFC5888]. Each identification-tag uniquely represents 1296 an "m=" line. 1298 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1299 used to carry identification-tags within RTCP SDES packets. This 1300 section also defines a new RTP SDES header extension [RFC7914], which 1301 is used to carry the 'MID' RTCP SDES item in RTP packets. 1303 The SDES item and RTP SDES header extension make it possible for a 1304 receiver to associate received RTCP- and RTP packets with a specific 1305 "m=" line, with which the receiver has associated an identification- 1306 tag, even if those "m=" lines are part of the same RTP session. The 1307 RTP SDES header extension also ensures that the media recipient gets 1308 the identification-tag upon receipt of the first decodable media and 1309 is able to associate the media with the correct application. 1311 A media recipient informs the media sender about the identification- 1312 tag associated with an "m=" line through the use of an 'mid' 1313 attribute [RFC5888]. The media sender then inserts the 1314 identification-tag in RTCP and RTP packets sent to the media 1315 recipient. 1317 NOTE: This text above defines how identification-tags are carried in 1318 SDP Offers and Answers. The usage of other signalling protocols for 1319 carrying identification-tags is not prevented, but the usage of such 1320 protocols is outside the scope of this document. 1322 [RFC3550] defines general procedures regarding the RTCP transmission 1323 interval. The RTCP MID SDES item SHOULD be sent in the first few 1324 RTCP packets sent after joining the session, and SHOULD be sent 1325 regularly thereafter. The exact number of RTCP packets in which this 1326 SDES item is sent is intentionally not specified here, as it will 1327 depend on the expected packet loss rate, the RTCP reporting interval, 1328 and the allowable overhead. 1330 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1331 be included in some RTP packets at the start of the session and 1332 whenever the SSRC changes. It might also be useful to include the 1333 header extension in RTP packets that comprise access points in the 1334 media (e.g., with video I-frames). The exact number of RTP packets 1335 in which this header extension is sent is intentionally not specified 1336 here, as it will depend on expected packet loss rate and loss 1337 patterns, the overhead the application can tolerate, and the 1338 importance of immediate receipt of the identification-tag. 1340 For robustness purpose, endpoints need to be prepared for situations 1341 where the reception of the identification-tag is delayed, and SHOULD 1342 NOT terminate sessions in such cases, as the identification-tag is 1343 likely to arrive soon. 1345 14.1. RTCP MID SDES Item 1347 0 1 2 3 1348 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 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | MID=TBD | length | identification-tag ... 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 The identification-tag payload is UTF-8 encoded, as in SDP. 1355 The identification-tag is not zero terminated. 1357 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1358 identifier value.] 1360 14.2. RTP SDES Header Extension For MID 1362 The payload, containing the identification-tag, of the RTP SDES 1363 header extension element can be encoded using either the one-byte or 1364 two-byte header [RFC7914]. The identification-tag payload is UTF-8 1365 encoded, as in SDP. 1367 The identification-tag is not zero terminated. Note, that the set of 1368 header extensions included in the packet needs to be padded to the 1369 next 32-bit boundary using zero bytes [RFC5285]. 1371 As the identification-tag is included in either an RTCP SDES item or 1372 an RTP SDES header extension, or both, there should be some 1373 consideration about the packet expansion caused by the 1374 identification-tag. To avoid Maximum Transmission Unit (MTU) issues 1375 for the RTP packets, the header extension's size needs to be taken 1376 into account when encoding the media. 1378 It is recommended that the identification-tag is kept short. Due to 1379 the properties of the RTP header extension mechanism, when using the 1380 one-byte header, a tag that is 1-3 bytes will result in a minimal 1381 number of 32-bit words used for the RTP SDES header extension, in 1382 case no other header extensions are included at the same time. Note, 1383 do take into account that some single characters when UTF-8 encoded 1384 will result in multiple octets. The identification-tag MUST NOT 1385 contain any user information, and applications SHALL avoid generating 1386 the identification-tag using a pattern that enables application 1387 identification. 1389 15. IANA Considerations 1391 15.1. New SDES item 1393 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1394 document.] 1396 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1397 identifier value.] 1399 This document adds the MID SDES item to the IANA "RTP SDES item 1400 types" registry as follows: 1402 Value: TBD 1403 Abbrev.: MID 1404 Name: Media Identification 1405 Reference: RFCXXXX 1407 15.2. New RTP SDES Header Extension URI 1409 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1410 document.] 1411 This document defines a new extension URI in the RTP SDES Compact 1412 Header Extensions sub-registry of the RTP Compact Header Extensions 1413 registry sub-registry, according to the following data: 1415 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1416 Description: Media identification 1417 Contact: christer.holmberg@ericsson.com 1418 Reference: RFCXXXX 1420 The SDES item does not reveal privacy information about the users. 1421 It is simply used to associate RTP-based media with the correct SDP 1422 media description (m- line) in the SDP used to negotiate the media. 1424 The purpose of the extension is for the offerer to be able to 1425 associate received multiplexed RTP-based media before the offerer 1426 receives the associated SDP answer. 1428 15.3. New SDP Attribute 1430 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1431 document.] 1433 This document defines a new SDP media-level attribute, 'bundle-only', 1434 according to the following data: 1436 Attribute name: bundle-only 1437 Type of attribute: media 1438 Subject to charset: No 1439 Purpose: Request a media description to be accepted 1440 in the answer only if kept within a BUNDLE 1441 group by the answerer. 1442 Appropriate values: N/A 1443 Contact name: Christer Holmberg 1444 Contact e-mail: christer.holmberg@ericsson.com 1445 Reference: RFCXXXX 1446 Mux category: NORMAL 1448 15.4. New SDP Group Semantics 1450 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1451 document.] 1452 This document registers the following semantics with IANA in the 1453 "Semantics for the "group" SDP Attribute" subregistry (under the 1454 "Session Description Protocol (SDP) Parameters" registry: 1456 Semantics Token Reference 1457 ------------------------------------- ------ --------- 1458 Media bundling BUNDLE [RFCXXXX] 1460 16. Security Considerations 1462 The security considerations defined in [RFC3264] and [RFC5888] apply 1463 to the BUNDLE extension. Bundle does not change which information 1464 flows over the network but only changes which addresses and ports 1465 that information is flowing on and thus has very little impact on the 1466 security of the RTP sessions. 1468 When the BUNDLE extension is used, a single set of security 1469 credentials might be used for all media streams specified by a BUNDLE 1470 group. 1472 When the BUNDLE extension is used, the number of SSRC values within a 1473 single RTP session increases, which increases the risk of SSRC 1474 collision. [RFC4568] describes how SSRC collision may weaken SRTP 1475 and SRTCP encryption in certain situations. 1477 17. Examples 1479 17.1. Example: Bundle Address Selection 1481 The example below shows: 1483 o An offer, in which the offerer associates a unique address with 1484 each bundled "m=" line within the BUNDLE group. 1486 o An answer, in which the answerer selects the offerer BUNDLE 1487 address, and then selects its own BUNDLE address (the answerer 1488 BUNDLE address) and associates it with each bundled "m=" line 1489 within the BUNDLE group. 1491 SDP Offer (1) 1493 v=0 1494 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1495 s= 1496 c=IN IP4 atlanta.example.com 1497 t=0 0 1498 a=group:BUNDLE foo bar 1499 m=audio 10000 RTP/AVP 0 8 97 1500 b=AS:200 1501 a=mid:foo 1502 a=rtcp-mux 1503 a=rtpmap:0 PCMU/8000 1504 a=rtpmap:8 PCMA/8000 1505 a=rtpmap:97 iLBC/8000 1506 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1507 m=video 10002 RTP/AVP 31 32 1508 b=AS:1000 1509 a=mid:bar 1510 a=rtcp-mux 1511 a=rtpmap:31 H261/90000 1512 a=rtpmap:32 MPV/90000 1513 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1515 SDP Answer (2) 1517 v=0 1518 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1519 s= 1520 c=IN IP4 biloxi.example.com 1521 t=0 0 1522 a=group:BUNDLE foo bar 1523 m=audio 20000 RTP/AVP 0 1524 b=AS:200 1525 a=mid:foo 1526 a=rtcp-mux 1527 a=rtpmap:0 PCMU/8000 1528 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1529 m=video 20000 RTP/AVP 32 1530 b=AS:1000 1531 a=mid:bar 1532 a=rtcp-mux 1533 a=rtpmap:32 MPV/90000 1534 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1536 17.2. Example: BUNDLE Extension Rejected 1538 The example below shows: 1540 o An offer, in which the offerer associates a unique address with 1541 each bundled "m=" line within the BUNDLE group. 1543 o An answer, in which the answerer rejects the offered BUNDLE group, 1544 and associates a unique address with each "m=" line (following 1545 normal RFC 3264 procedures). 1547 SDP Offer (1) 1549 v=0 1550 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1551 s= 1552 c=IN IP4 atlanta.example.com 1553 t=0 0 1554 a=group:BUNDLE foo bar 1555 m=audio 10000 RTP/AVP 0 8 97 1556 b=AS:200 1557 a=mid:foo 1558 a=rtcp-mux 1559 a=rtpmap:0 PCMU/8000 1560 a=rtpmap:8 PCMA/8000 1561 a=rtpmap:97 iLBC/8000 1562 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1563 m=video 10002 RTP/AVP 31 32 1564 b=AS:1000 1565 a=mid:bar 1566 a=rtcp-mux 1567 a=rtpmap:31 H261/90000 1568 a=rtpmap:32 MPV/90000 1569 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1571 SDP Answer (2) 1573 v=0 1574 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1575 s= 1576 c=IN IP4 biloxi.example.com 1577 t=0 0 1578 m=audio 20000 RTP/AVP 0 1579 b=AS:200 1580 a=rtcp-mux 1581 a=rtpmap:0 PCMU/8000 1582 m=video 30000 RTP/AVP 32 1583 b=AS:1000 1584 a=rtcp-mux 1585 a=rtpmap:32 MPV/90000 1587 17.3. Example: Offerer Adds A Media Description To A BUNDLE Group 1589 The example below shows: 1591 o A subsequent offer (the BUNDLE group has been created as part of a 1592 previous offer/answer exchange), in which the offerer adds a new 1593 "m=" line, represented by the "zen" identification-tag, to a 1594 previously negotiated BUNDLE group, associates a unique address 1595 with the added "m=" line, and associates the previously selected 1596 offerer BUNDLE address with each of the other bundled "m=" lines 1597 within the BUNDLE group. 1599 o An answer, in which the answerer associates the answerer BUNDLE 1600 address with each bundled "m=" line (including the newly added 1601 "m=" line) within the BUNDLE group. 1603 SDP Offer (1) 1605 v=0 1606 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1607 s= 1608 c=IN IP4 atlanta.example.com 1609 t=0 0 1610 a=group:BUNDLE foo bar zen 1611 m=audio 10000 RTP/AVP 0 8 97 1612 b=AS:200 1613 a=mid:foo 1614 a=rtcp-mux 1615 a=rtpmap:0 PCMU/8000 1616 a=rtpmap:8 PCMA/8000 1617 a=rtpmap:97 iLBC/8000 1618 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1619 m=video 10000 RTP/AVP 31 32 1620 b=AS:1000 1621 a=mid:bar 1622 a=rtcp-mux 1623 a=rtpmap:31 H261/90000 1624 a=rtpmap:32 MPV/90000 1625 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1626 m=video 20000 RTP/AVP 66 1627 b=AS:1000 1628 a=mid:zen 1629 a=rtcp-mux 1630 a=rtpmap:66 H261/90000 1631 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1633 SDP Answer (2) 1635 v=0 1636 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1637 s= 1638 c=IN IP4 biloxi.example.com 1639 t=0 0 1640 a=group:BUNDLE foo bar zen 1641 m=audio 20000 RTP/AVP 0 1642 b=AS:200 1643 a=mid:foo 1644 a=rtcp-mux 1645 a=rtpmap:0 PCMU/8000 1646 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1647 m=video 20000 RTP/AVP 32 1648 b=AS:1000 1649 a=mid:bar 1650 a=rtcp-mux 1651 a=rtpmap:32 MPV/90000 1652 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1653 m=video 20000 RTP/AVP 66 1654 b=AS:1000 1655 a=mid:zen 1656 a=rtcp-mux 1657 a=rtpmap:66 H261/90000 1658 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1660 17.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 1662 The example below shows: 1664 o A subsequent offer (the BUNDLE group has been created as part of a 1665 previous offer/answer transaction), in which the offerer moves a 1666 bundled "m=" line out of a BUNDLE group, associates a unique 1667 address with the moved "m=" line, and associates the offerer 1668 BUNDLE address with each other bundled "m=" line within the BUNDLE 1669 group. 1671 o An answer, in which the answerer moves the "m=" line out of the 1672 BUNDLE group, associates a unique address with the moved "m=" 1673 line, and associates the answerer BUNDLE address with each of the 1674 remaining bundled "m=" line within the BUNDLE group. 1676 SDP Offer (1) 1678 v=0 1679 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1680 s= 1681 c=IN IP4 atlanta.example.com 1682 t=0 0 1683 a=group:BUNDLE foo bar 1684 m=audio 10000 RTP/AVP 0 8 97 1685 b=AS:200 1686 a=mid:foo 1687 a=rtcp-mux 1688 a=rtpmap:0 PCMU/8000 1689 a=rtpmap:8 PCMA/8000 1690 a=rtpmap:97 iLBC/8000 1691 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1692 m=video 10000 RTP/AVP 31 32 1693 b=AS:1000 1694 a=mid:bar 1695 a=rtcp-mux 1696 a=rtpmap:31 H261/90000 1697 a=rtpmap:32 MPV/90000 1698 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1699 m=video 50000 RTP/AVP 66 1700 b=AS:1000 1701 a=mid:zen 1702 a=rtcp-mux 1703 a=rtpmap:66 H261/90000 1705 SDP Answer (2) 1707 v=0 1708 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1709 s= 1710 c=IN IP4 biloxi.example.com 1711 t=0 0 1712 a=group:BUNDLE foo bar 1713 m=audio 20000 RTP/AVP 0 1714 b=AS:200 1715 a=mid:foo 1716 a=rtcp-mux 1717 a=rtpmap:0 PCMU/8000 1718 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1719 m=video 20000 RTP/AVP 32 1720 b=AS:1000 1721 a=mid:bar 1722 a=rtcp-mux 1723 a=rtpmap:32 MPV/90000 1724 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1725 m=video 60000 RTP/AVP 66 1726 b=AS:1000 1727 a=mid:zen 1728 a=rtcp-mux 1729 a=rtpmap:66 H261/90000 1731 17.5. Example: Offerer Disables A Media Description Within A BUNDLE 1732 Group 1734 The example below shows: 1736 o A subsequent offer (the BUNDLE group has been created as part of a 1737 previous offer/answer transaction), in which the offerer disables 1738 a bundled "m=" line within a BUNDLE group, assigns a zero port 1739 number to the disabled "m=" line, and associates the offerer 1740 BUNDLE address with each of the other bundled "m=" lines within 1741 the BUNDLE group. 1743 o An answer, in which the answerer moves the disabled "m=" line out 1744 of the BUNDLE group, assigns a zero port value to the disabled 1745 "m=" line, and associates the answerer BUNDLE address with each of 1746 the remaining bundled "m=" line within the BUNDLE group. 1748 SDP Offer (1) 1750 v=0 1751 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1752 s= 1753 c=IN IP4 atlanta.example.com 1754 t=0 0 1755 a=group:BUNDLE foo bar 1756 m=audio 10000 RTP/AVP 0 8 97 1757 b=AS:200 1758 a=mid:foo 1759 a=rtcp-mux 1760 a=rtpmap:0 PCMU/8000 1761 a=rtpmap:8 PCMA/8000 1762 a=rtpmap:97 iLBC/8000 1763 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1764 m=video 10000 RTP/AVP 31 32 1765 b=AS:1000 1766 a=mid:bar 1767 a=rtcp-mux 1768 a=rtpmap:31 H261/90000 1769 a=rtpmap:32 MPV/90000 1770 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1771 m=video 0 RTP/AVP 66 1772 a=mid:zen 1773 a=rtpmap:66 H261/90000 1775 SDP Answer (2) 1777 v=0 1778 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1779 s= 1780 c=IN IP4 biloxi.example.com 1781 t=0 0 1782 a=group:BUNDLE foo bar 1783 m=audio 20000 RTP/AVP 0 1784 b=AS:200 1785 a=mid:foo 1786 a=rtcp-mux 1787 a=rtpmap:0 PCMU/8000 1788 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1789 m=video 20000 RTP/AVP 32 1790 b=AS:1000 1791 a=mid:bar 1792 a=rtcp-mux 1793 a=rtpmap:32 MPV/90000 1794 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1795 m=video 0 RTP/AVP 66 1796 a=mid:zen 1797 a=rtpmap:66 H261/90000 1799 18. Acknowledgements 1801 The usage of the SDP grouping extension for negotiating bundled media 1802 is based on a similar alternatives proposed by Harald Alvestrand and 1803 Cullen Jennings. The BUNDLE extension described in this document is 1804 based on the different alternative proposals, and text (e.g., SDP 1805 examples) have been borrowed (and, in some cases, modified) from 1806 those alternative proposals. 1808 The SDP examples are also modified versions from the ones in the 1809 Alvestrand proposal. 1811 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 1812 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 1813 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju and 1814 Justin Uberti for reading the text, and providing useful feedback. 1816 Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for 1817 providing help and text on the RTP/RTCP procedures. 1819 Thanks to Spotify for providing music for the countless hours of 1820 document editing. 1822 19. Change Log 1824 [RFC EDITOR NOTE: Please remove this section when publishing] 1826 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32 1828 o Editorial changes based on comments from Eric Rescorla and Cullen 1829 Jennings: 1831 o - Justification for mechanism added to Introduction. 1833 o - Clarify that the order of m- lines in the group:BUNDLE attribute 1834 does not have to be the same as the order in which the m- lines 1835 are listed in the SDP. 1837 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31 1839 o Editorial changes based on GitHub Pull requests by Martin Thomson: 1841 o - https://github.com/cdh4u/draft-sdp-bundle/pull/2 1843 o - https://github.com/cdh4u/draft-sdp-bundle/pull/1 1845 o Editorial change based on comment from Diederick Huijbers (9th 1846 July 2016). 1848 o Changes based on comments from Flemming Andreasen (21st June 1849 2016): 1851 o - Mux category for SDP bundle-only attribute added. 1853 o - Mux category considerations editorial clarification. 1855 o - Editorial changes. 1857 o RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext. 1859 o Note whether Design Considerations appendix is to be kept removed: 1861 o - Appendix is kept within document. 1863 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30 1865 o Indicating in the Abstract and Introduction that the document 1866 updates RFC 3264. 1868 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29 1869 o Change based on WGLC comment from Colin Perkins. 1871 o - Clarify that SSRC can be reused by another source after a delay 1872 of 5 RTCP reporting intervals. 1874 o Change based on WGLC comment from Alissa Cooper. 1876 o - IANA registry name fix. 1878 o - Additional IANA registration information added. 1880 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28 1882 o - Alignment with exclusive mux procedures. 1884 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 1886 o - Yet another terminology change. 1888 o - Mux category considerations added. 1890 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 1892 o - ICE considerations modified: ICE-related SDP attributes only 1893 added to the bundled m- line representing the selected BUNDLE 1894 address. 1896 o - Reference to draft-ietf-mmusic-ice-sip-sdp added. 1898 o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- 1899 rfc5245bis. 1901 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 1903 o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux 1904 considerations. 1906 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 1908 o - Reference and procedures associated with exclusive RTP/RTCP mux 1909 added 1911 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 1913 o - RTCP-MUX mandatory for bundled RTP m- lines 1915 o - Editorial fixes based on comments from Flemming Andreasen 1916 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 1918 o - Correction of Ari's family name 1920 o - Editorial fixes based on comments from Thomas Stach 1922 o - RTP/RTCP correction based on comment from Magnus Westerlund 1924 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 1925 msg14861.html 1927 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 1929 o - Correct based on comment from Paul Kyzivat 1931 o -- 'received packets' replaced with 'received data' 1933 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 1935 o - Clarification based on comment from James Guballa 1937 o - Clarification based on comment from Flemming Andreasen 1939 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 1941 o - DTLS Considerations section added. 1943 o - BUNDLE semantics added to the IANA Considerations 1945 o - Changes based on WGLC comments from Adam Roach 1947 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 1948 msg14673.html 1950 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 1952 o - Changes based on agreements at IETF#92 1954 o -- BAS Offer removed, based on agreement at IETF#92. 1956 o -- Procedures regarding usage of SDP "b=" line is replaced with a 1957 reference to to draft-ietf-mmusic-sdp-mux-attributes. 1959 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 1961 o - Editorial changes based on comments from Magnus Westerlund. 1963 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 1964 o - Modification of RTP/RTCP multiplexing section, based on comments 1965 from Magnus Westerlund. 1967 o - Reference updates. 1969 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 1971 o - Editorial fix. 1973 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 1975 o - Editorial changes. 1977 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 1979 o Changes to allow a new suggested offerer BUNDLE address to be 1980 assigned to each bundled m- line. 1982 o Changes based on WGLC comments from Paul Kyzivat 1984 o - Editorial fixes 1986 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 1988 o Usage of SDP 'extmap' attribute added 1990 o SDP 'bundle-only' attribute scoped with "m=" lines with a zero 1991 port value 1993 o Changes based on WGLC comments from Thomas Stach 1995 o - ICE candidates not assigned to bundle-only m- lines with a zero 1996 port value 1998 o - Editorial changes 2000 o Changes based on WGLC comments from Colin Perkins 2002 o - Editorial changes: 2004 o -- "RTP SDES item" -> "RTCP SDES item" 2006 o -- "RTP MID SDES item" -> "RTCP MID SDES item" 2008 o - Changes in section 10.1.1: 2010 o -- "SHOULD NOT" -> "MUST NOT" 2011 o -- Additional text added to the Note 2013 o - Change to section 13.2: 2015 o -- Clarify that mid value is not zero terminated 2017 o - Change to section 13.3: 2019 o -- Clarify that mid value is not zero terminated 2021 o -- Clarify padding 2023 o Changes based on WGLC comments from Paul Kyzivat 2025 o - Editorial changes: 2027 o Changes based on WGLC comments from Jonathan Lennox 2029 o - Editorial changes: 2031 o - Defintion of SDP bundle-only attribute alligned with structure 2032 in 4566bis draft 2034 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 2036 o Editorial corrections based on comments from Harald Alvestrand. 2038 o Editorial corrections based on comments from Cullen Jennings. 2040 o Reference update (RFC 7160). 2042 o Clarification about RTCP packet sending when RTP/RTCP multiplexing 2043 is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ 2044 msg13765.html). 2046 o Additional text added to the Security Considerations. 2048 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 2050 o SDP bundle-only attribute added to IANA Considerations. 2052 o SDES item and RTP header extension added to Abstract and 2053 Introduction. 2055 o Modification to text updating section 8.2 of RFC 3264. 2057 o Reference corrections. 2059 o Editorial corrections. 2061 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 2063 o Terminology change: "bundle-only attribute assigned to m= line" to 2064 "bundle-only attribute associated with m= line". 2066 o Editorial corrections. 2068 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 2070 o Editorial corrections. 2072 o - "of"->"if" (8.3.2.5). 2074 o - "optional"->"OPTIONAL" (9.1). 2076 o - Syntax/ABNF for 'bundle-only' attribute added. 2078 o - SDP Offer/Answer sections merged. 2080 o - 'Request new offerer BUNDLE address' section added 2082 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 2084 o OPEN ISSUE regarding Receiver-ID closed. 2086 o - RTP MID SDES Item. 2088 o - RTP MID Header Extension. 2090 o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers 2091 closed. 2093 o - Indicating that, when rtcp-mux is used, the answerer MUST NOT 2094 include an 'rtcp' attribute in the answer, based on the procedures 2095 in section 5.1.3 of RFC 5761. 2097 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 2099 o Draft title changed. 2101 o Added "SDP" to section names containing "Offer" or "Answer". 2103 o Editorial fixes based on comments from Paul Kyzivat 2104 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2105 msg13314.html). 2107 o Editorial fixed based on comments from Colin Perkins 2108 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2109 msg13318.html). 2111 o - Removed text about extending BUNDLE to allow multiple RTP 2112 sessions within a BUNDLE group. 2114 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 2116 o Major re-structure of SDP Offer/Answer sections, to align with RFC 2117 3264 structure. 2119 o Additional definitions added. 2121 o - Shared address. 2123 o - Bundled "m=" line. 2125 o - Bundle-only "m=" line. 2127 o - Offerer suggested BUNDLE mid. 2129 o - Answerer selected BUNDLE mid. 2131 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 2132 to multiple "m=" lines until it has received an SDP Answer 2133 indicating support of the BUNDLE extension. 2135 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 2136 Answerer supports the BUNDLE extension, assign a zero port value 2137 to a 'bundle-only' "m=" line. 2139 o SDP 'bundle-only' attribute section added. 2141 o Connection data nettype/addrtype restrictions added. 2143 o RFC 3264 update section added. 2145 o Indicating that a specific payload type value can be used in 2146 multiple "m=" lines, if the value represents the same codec 2147 configuration in each "m=" line. 2149 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 2151 o Updated Offerer procedures (http://www.ietf.org/mail- 2152 archive/web/mmusic/current/msg12293.html). 2154 o Updated Answerer procedures (http://www.ietf.org/mail- 2155 archive/web/mmusic/current/msg12333.html). 2157 o Usage of SDP 'bundle-only' attribute added. 2159 o Reference to Trickle ICE document added. 2161 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 2163 o Mechanism modified, to be based on usage of SDP Offers with both 2164 different and identical port number values, depending on whether 2165 it is known if the remote endpoint supports the extension. 2167 o Cullen Jennings added as co-author. 2169 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 2171 o No changes. New version due to expiration. 2173 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 2175 o No changes. New version due to expiration. 2177 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 2179 o Draft name changed. 2181 o Harald Alvestrand added as co-author. 2183 o "Multiplex" terminology changed to "bundle". 2185 o Added text about single versus multiple RTP Sessions. 2187 o Added reference to RFC 3550. 2189 20. References 2191 20.1. Normative References 2193 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2194 Requirement Levels", BCP 14, RFC 2119, 2195 DOI 10.17487/RFC2119, March 1997, 2196 . 2198 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2199 with Session Description Protocol (SDP)", RFC 3264, 2200 DOI 10.17487/RFC3264, June 2002, 2201 . 2203 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2204 Jacobson, "RTP: A Transport Protocol for Real-Time 2205 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2206 July 2003, . 2208 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2209 in Session Description Protocol (SDP)", RFC 3605, 2210 DOI 10.17487/RFC3605, October 2003, 2211 . 2213 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2214 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2215 July 2006, . 2217 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2218 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2219 . 2221 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2222 (ICE): A Protocol for Network Address Translator (NAT) 2223 Traversal for Offer/Answer Protocols", RFC 5245, 2224 DOI 10.17487/RFC5245, April 2010, 2225 . 2227 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 2228 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2229 2008, . 2231 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2232 Control Packets on a Single Port", RFC 5761, 2233 DOI 10.17487/RFC5761, April 2010, 2234 . 2236 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2237 Security (DTLS) Extension to Establish Keys for the Secure 2238 Real-time Transport Protocol (SRTP)", RFC 5764, 2239 DOI 10.17487/RFC5764, May 2010, 2240 . 2242 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2243 Protocol (SDP) Grouping Framework", RFC 5888, 2244 DOI 10.17487/RFC5888, June 2010, 2245 . 2247 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2248 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2249 January 2012, . 2251 [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based 2252 Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, 2253 August 2016, . 2255 [I-D.ietf-ice-rfc5245bis] 2256 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2257 Connectivity Establishment (ICE): A Protocol for Network 2258 Address Translator (NAT) Traversal", draft-ietf-ice- 2259 rfc5245bis-04 (work in progress), June 2016. 2261 [I-D.ietf-mmusic-sdp-mux-attributes] 2262 Nandakumar, S., "A Framework for SDP Attributes when 2263 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-14 2264 (work in progress), September 2016. 2266 [I-D.ietf-mmusic-mux-exclusive] 2267 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 2268 Multiplexing using SDP", draft-ietf-mmusic-mux- 2269 exclusive-10 (work in progress), August 2016. 2271 [I-D.ietf-mmusic-ice-sip-sdp] 2272 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using 2273 Interactive Connectivity Establishment (ICE) with Session 2274 Description Protocol (SDP) offer/answer and Session 2275 Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip- 2276 sdp-10 (work in progress), July 2016. 2278 20.2. Informative References 2280 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2281 A., Peterson, J., Sparks, R., Handley, M., and E. 2282 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2283 DOI 10.17487/RFC3261, June 2002, 2284 . 2286 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 2287 Description Protocol (SDP) Security Descriptions for Media 2288 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 2289 . 2291 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2292 Media Attributes in the Session Description Protocol 2293 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2294 . 2296 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2297 Clock Rates in an RTP Session", RFC 7160, 2298 DOI 10.17487/RFC7160, April 2014, 2299 . 2301 [I-D.ietf-mmusic-trickle-ice] 2302 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 2303 Incremental Provisioning of Candidates for the Interactive 2304 Connectivity Establishment (ICE) Protocol", draft-ietf- 2305 mmusic-trickle-ice-02 (work in progress), January 2015. 2307 Appendix A. Design Considerations 2309 One of the main issues regarding the BUNDLE grouping extensions has 2310 been whether, in SDP Offers and SDP Answers, the same port value 2311 should be inserted in "m=" lines associated with a BUNDLE group, as 2312 the purpose of the extension is to negotiate the usage of a single 2313 address:port combination for media specified by the "m=" lines. 2314 Issues with both approaches, discussed in the Appendix have been 2315 raised. The outcome was to specify a mechanism which uses SDP Offers 2316 with both different and identical port values. 2318 Below are the primary issues that have been considered when defining 2319 the "BUNDLE" grouping extension: 2321 o 1) Interoperability with existing UAs. 2323 o 2) Interoperability with intermediary B2BUA- and proxy entities. 2325 o 3) Time to gather, and the number of, ICE candidates. 2327 o 4) Different error scenarios, and when they occur. 2329 o 5) SDP Offer/Answer impacts, including usage of port number value 2330 zero. 2332 A.1. UA Interoperability 2334 Consider the following SDP Offer/Answer exchange, where Alice sends 2335 an SDP Offer to Bob: 2337 SDP Offer 2339 v=0 2340 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2341 s= 2342 c=IN IP4 atlanta.example.com 2343 t=0 0 2344 m=audio 10000 RTP/AVP 97 2345 a=rtpmap:97 iLBC/8000 2346 m=video 10002 RTP/AVP 97 2347 a=rtpmap:97 H261/90000 2349 SDP Answer 2351 v=0 2352 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2353 s= 2354 c=IN IP4 biloxi.example.com 2355 t=0 0 2356 m=audio 20000 RTP/AVP 97 2357 a=rtpmap:97 iLBC/8000 2358 m=video 20002 RTP/AVP 97 2359 a=rtpmap:97 H261/90000 2361 RFC 4961 specifies a way of doing symmetric RTP but that is an a 2362 later invention to RTP and Bob can not assume that Alice supports RFC 2363 4961. This means that Alice may be sending RTP from a different port 2364 than 10000 or 10002 - some implementation simply send the RTP from an 2365 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2366 way that Bob knows if it should be passed to the video or audio codec 2367 is by looking at the port it was received on. This lead some SDP 2368 implementations to use the fact that each "m=" line had a different 2369 port number to use that port number as an index to find the correct m 2370 line in the SDP. As a result, some implementations that do support 2371 symmetric RTP and ICE still use a SDP data structure where SDP with 2372 "m=" lines with the same port such as: 2374 SDP Offer 2376 v=0 2377 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2378 s= 2379 c=IN IP4 atlanta.example.com 2380 t=0 0 2381 m=audio 10000 RTP/AVP 97 2382 a=rtpmap:97 iLBC/8000 2383 m=video 10000 RTP/AVP 98 2384 a=rtpmap:98 H261/90000 2386 will result in the second "m=" line being considered an SDP error 2387 because it has the same port as the first line. 2389 A.2. Usage of port number value zero 2391 In an SDP Offer or SDP Answer, the media specified by an "m=" line 2392 can be disabled/rejected by setting the port number value to zero. 2393 This is different from e.g., using the SDP direction attributes, 2394 where RTCP traffic will continue even if the SDP "inactive" attribute 2395 is indicated for the associated "m=" line. 2397 If each "m=" line associated with a BUNDLE group would contain 2398 different port values, and one of those port values would be used for 2399 a BUNDLE address associated with the BUNDLE group, problems would 2400 occur if an endpoint wants to disable/reject the "m=" line associated 2401 with that port, by setting the port value to zero. After that, no 2402 "m=" line would contain the port value which is used for the BUNDLE 2403 address. In addition, it is unclear what would happen to the ICE 2404 candidates associated with the "m=" line, as they are also used for 2405 the BUNDLE address. 2407 A.3. B2BUA And Proxy Interoperability 2409 Some back to back user agents may be configured in a mode where if 2410 the incoming call leg contains an SDP attribute the B2BUA does not 2411 understand, the B2BUA still generates that SDP attribute in the Offer 2412 for the outgoing call leg. Consider a B2BUA that did not understand 2413 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 2414 Further assume that the B2BUA was configured to tear down any call 2415 where it did not see any RTCP for 5 minutes. In this case, if the 2416 B2BUA received an Offer like: 2418 SDP Offer 2420 v=0 2421 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2422 s= 2423 c=IN IP4 atlanta.example.com 2424 t=0 0 2425 m=audio 49170 RTP/AVP 0 2426 a=rtcp:53020 2428 It would be looking for RTCP on port 49172 but would not see any 2429 because the RTCP would be on port 53020 and after five minutes, it 2430 would tear down the call. Similarly, a B2BUA that did not understand 2431 BUNDLE yet put BUNDLE in it's offer may be looking for media on the 2432 wrong port and tear down the call. It is worth noting that a B2BUA 2433 that generated an Offer with capabilities it does not understand is 2434 not compliant with the specifications. 2436 A.3.1. Traffic Policing 2438 Sometimes intermediaries do not act as B2BUA, in the sense that they 2439 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2440 however, they may use SDP information (e.g., IP address and port) in 2441 order to control traffic gating functions, and to set traffic 2442 policing rules. There might be rules which will trigger a session to 2443 be terminated in case media is not sent or received on the ports 2444 retrieved from the SDP. This typically occurs once the session is 2445 already established and ongoing. 2447 A.3.2. Bandwidth Allocation 2449 Sometimes intermediaries do not act as B2BUA, in the sense that they 2450 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2451 however, they may use SDP information (e.g., codecs and media types) 2452 in order to control bandwidth allocation functions. The bandwidth 2453 allocation is done per "m=" line, which means that it might not be 2454 enough if media specified by all "m=" lines try to use that 2455 bandwidth. That may either simply lead to bad user experience, or to 2456 termination of the call. 2458 A.4. Candidate Gathering 2460 When using ICE, a candidate needs to be gathered for each port. This 2461 takes approximately 20 ms extra for each extra "m=" line due to the 2462 NAT pacing requirements. All of this gather can be overlapped with 2463 other things while for exampe a web-page is loading to minimize the 2464 impact. If the client only wants to generate TURN or STUN ICE 2465 candidates for one of the "m=" lines and then use trickle ICE 2466 [I-D.ietf-mmusic-trickle-ice] to get the non host ICE candidates for 2467 the rest of the "m=" lines, it MAY do that and will not need any 2468 additional gathering time. 2470 Some people have suggested a TURN extension to get a bunch of TURN 2471 allocations at once. This would only provide a single STUN result so 2472 in cases where the other end did not support BUNDLE, may cause more 2473 use of the TURN server but would be quick in the cases where both 2474 sides supported BUNDLE and would fall back to a successful call in 2475 the other cases. 2477 Authors' Addresses 2479 Christer Holmberg 2480 Ericsson 2481 Hirsalantie 11 2482 Jorvas 02420 2483 Finland 2485 Email: christer.holmberg@ericsson.com 2487 Harald Tveit Alvestrand 2488 Google 2489 Kungsbron 2 2490 Stockholm 11122 2491 Sweden 2493 Email: harald@alvestrand.no 2495 Cullen Jennings 2496 Cisco 2497 400 3rd Avenue SW, Suite 350 2498 Calgary, AB T2P 4H2 2499 Canada 2501 Email: fluffy@iii.ca