idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-34.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 19, 2016) is 2739 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 1298 == Missing Reference: 'RFCXXXX' is mentioned on line 1481, 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) == 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: 4 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 22, 2017 C. Jennings 7 Cisco 8 October 19, 2016 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-34.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 22, 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 . . . . . . . . . . . . . . . . . 22 117 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 22 118 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . 26 123 11.1.4. Modifying the Session . . . . . . . . . . . . . . . 26 124 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 26 125 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 27 126 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 27 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 28 130 13.4. New text replacing section 8.2 (2nd paragraph) of RFC 131 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 132 13.5. Original text of section 8.4 (6th paragraph) of RFC 3264 28 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 . . . . 29 136 14.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 30 137 14.2. RTP SDES Header Extension For MID . . . . . . . . . . . 30 138 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 139 15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 31 140 15.2. New RTP SDES Header Extension URI . . . . . . . . . . . 31 141 15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 32 142 15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 32 143 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 144 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33 145 17.1. Example: Bundle Address Selection . . . . . . . . . . . 33 146 17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 35 147 17.3. Example: Offerer Adds A Media Description To A BUNDLE 148 Group . . . . . . . . . . . . . . . . . . . . . . . . . 36 149 17.4. Example: Offerer Moves A Media Description Out Of A 150 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 38 151 17.5. Example: Offerer Disables A Media Description Within A 152 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 40 153 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 154 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 42 155 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 156 20.1. Normative References . . . . . . . . . . . . . . . . . . 50 157 20.2. Informative References . . . . . . . . . . . . . . . . . 51 158 Appendix A. Design Considerations . . . . . . . . . . . . . . . 52 159 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 53 160 A.2. Usage of port number value zero . . . . . . . . . . . . . 54 161 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 54 162 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 55 163 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 55 164 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 56 165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 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 packets with the correct "m=" line using the 959 SSRC values. In addition, the SSRC value can change during the 960 session, and values that were not provided using the SDP 'ssrc' 961 attribute may be used. 963 In order for an offerer and answerer to always be able to associate 964 received RTP packets with the correct "m=" line, an offerer and 965 answerer using the BUNDLE extension MUST support the mechanism 966 defined in Section 14, where the remote endpoint inserts the 967 identification-tag associated with an "m=" line in RTP and RTCP 968 packets associated with that "m=" line. 970 Once an offerer or answerer recieves an RTP/RTCP packet carrying an 971 identification-tag and an SSRC value, it associates the SSRC value 972 with the "m=" line associated with the identification-tag. Later, 973 when an offerer or answerer receives an RTP or RTCP packet that does 974 not carry the identification-tag, it can associate the packet with 975 the correct "m=" line using the SSRC value. Note that multiple SSRC 976 values may end up being associated with the same "m=" line. 978 If an offerer or answerer is not able to associate an RTP packet with 979 the correct "m=" line using the SSRC value, the offerer or answerer 980 can check whether the association can be done using the payload type 981 value (in case the payload type value is unique for a given "m=" line 982 within the BUNDLE group), or using other appropriate mechanisms. 983 After all appropriate mechanisms supported by the offerer or answerer 984 have been tried, if it is not possible to associate a packet with the 985 correct "m=" line, the packet SHOULD be dropped after having been 986 processed as received by the RTCP layer. 988 10.3. RTP/RTCP Multiplexing 990 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 991 multiplexing [RFC5761] for the RTP-based media specified by the 992 BUNDLE group. 994 When RTP/RTCP multiplexing is enabled, the same address:port 995 combination will be used for sending all RTP packets and the RTCP 996 packets associated with the BUNDLE group. Each endpoint will send 997 the packets towards the BUNDLE address of the other endpoint. The 998 same address:port combination MAY be used for receiving RTP packets 999 and RTCP packets. 1001 10.3.1. SDP Offer/Answer Procedures 1003 This section describes how an offerer and answerer use the SDP 'rtcp- 1004 mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute 1005 [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP 1006 multiplexing for RTP-based media specified by a BUNDLE group. 1008 The procedures in this section only apply to RTP-based "m=" lines. 1010 10.3.1.1. Generating the Initial SDP Offer 1012 When an offerer generates an initial offer, the offerer MUST 1013 associate an SDP 'rtcp-mux' attribute [RFC5761] with each bundled 1014 RTP-based "m=" line in the offer, including a bundle-only "m=" line. 1015 In addition, the offerer MUST associate an SDP 'rtcp-mux-only' 1016 attribute [I-D.ietf-mmusic-mux-exclusive] with each RTP-based bundle- 1017 only "m=" line, and MAY associated an SDP 'rtcp-mux-only' attribute 1018 with other bundled RTP-based "m=" lines. 1020 NOTE: Whether the offerer associates an SDP 'rtcp-mux-only' attribute 1021 with a bundled "m=" line or not depends on whether the offerer 1022 supports fallback to usage of a separate port for RTCP in case the 1023 answerer does not include the "m=" line in the BUNDLE group. 1025 NOTE: If the offerer associates an SDP 'rtcp-mux' attribute with a 1026 bundled "m=" line, but does not associate an SDP 'rtcp-mux-only' 1027 attribute with the "m=" line, the offerer can also associate an SDP 1028 'rtcp' attribute [RFC3605] with the "m=" line in order to provide a 1029 fallback port for RTCP, as described in [RFC5761]. However, the 1030 fallback port will only be used in case the answerer does not include 1031 the "m=" line in the BUNDLE group. 1033 In the initial offer, the address:port combination for RTCP MUST be 1034 unique in each bundled RTP-based "m=" line (excluding a bundle-only 1035 "m=" line), similar to RTP. 1037 10.3.1.2. Generating the SDP Answer 1039 When an answerer generates an answer, if the answerer accepts one or 1040 more RTP-based "m=" lines within a BUNDLE group, the answerer MUST 1041 enable usage of RTP/RTCP multiplexing. The answerer MUST associate 1042 an SDP "rtcp-mux" attribute with each RTP-based "m=" line in the 1043 answer. In addition, if an "m=" line in the corresponding offer 1044 contained an SDP "rtcp-mux-only" attribute, the answerer MUST 1045 associate an SDP "rtcp-mux-only" attribute with the "m=" line in the 1046 answer. 1048 If an RTP-based "m=" line in the corresponding offer did not contain 1049 an SDP 'rtcp-mux' attribute, the answerer MUST NOT include the "m=" 1050 line within a BUNDLE group in the answer. 1052 If an RTP-based "m=" line in the corresponding offer contained an SDP 1053 "rtcp-mux-only" attribute, and if the answerer moves the "m=" line 1054 out of the BUNDLE group in the answer Section 8.3.3, the answerer 1055 MUST still either enable RTP/RTCP multiplexing for the media 1056 associated with the "m=" line, or reject the "m=" line Section 8.3.4. 1058 The answerer MUST NOT associate an SDP 'rtcp' attribute with any 1059 bundled "m=" line in the answer. The answerer will use the port 1060 value of the selected offerer BUNDLE address for sending RTP and RTCP 1061 packets associated with each RTP-based bundled "m=" line towards the 1062 offerer. 1064 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1065 negotiated in a previous offer/answer transaction, the answerer MUST 1066 associate an SDP 'rtcp-mux' attribute with each bundled RTP-based 1067 "m=" line in the answer. 1069 10.3.1.3. Offerer Processing of the SDP Answer 1071 When an offerer receives an answer, if the answerer has accepted the 1072 usage of RTP/RTCP multiplexing (see Section 10.3.1.2), the answerer 1073 follows the procedures for RTP/RTCP multiplexing defined in 1074 [RFC5761]. The offerer will use the port value associated with the 1075 answerer BUNDLE address for sending RTP and RTCP packets associated 1076 with each RTP-based bundled "m=" line towards the answerer. 1078 NOTE: It is considered a protocol error if the answerer has not 1079 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" lines 1080 that the answerer included in the BUNDLE group. 1082 10.3.1.4. Modifying the Session 1084 When an offerer generates a subsequent offer, for each RTP-based "m=" 1085 line that was previously added to the BUNDLE group the offerer MUST 1086 associate an SDP 'rtcp-mux' attribute and an SDP 'rtcp-mux-only' 1087 attribute with the "m=" line in the same way it was previously done, 1088 unless the offerer wants to disable or remove the "m=" line from the 1089 BUNDLE group. 1091 If the offerer wants to add a bundled RTP-based "m=" line to the 1092 BUNDLE group, it associates an SDP 'rtcp-mux' attribute and an SDP 1093 'rtcp-mux-only' attribute with the "m=" line using the procedures in 1094 [Section 10.3.1.1]. 1096 11. ICE Considerations 1098 This section describes how to use the BUNDLE grouping extension 1099 together with the Interactive Connectivity Establishment (ICE) 1100 mechanism [I-D.ietf-ice-rfc5245bis]. 1102 The generic procedures for negotiating usage of ICE using SDP, 1103 defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE 1104 with BUNDLE, with the following exceptions: 1106 o When BUNDLE addresses for a BUNDLE group have been selected for 1107 both endpoints, ICE connectivity checks and keep-alives only need 1108 to be performed for the whole BUNDLE group, instead of per bundled 1109 "m=" line. 1111 o Among bundled "m=" lines with which the offerer has associated a 1112 shared address, the offerer only associates ICE-related media- 1113 level SDP attributes with the "m=" line associated with the 1114 offerer BUNDLE-tag. 1116 o Among bundled "m=" lines with which the answerer has associated a 1117 shared address, the answerer only associates ICE-related media- 1118 level SDP attributes with the "m=" line associated with the 1119 answerer BUNDLE-tag. 1121 Support and usage of ICE mechanism together with the BUNDLE extension 1122 is OPTIONAL. 1124 11.1. SDP Offer/Answer Procedures 1126 When an offerer associates a unique address with a bundled "m=" line 1127 (excluding any bundle-only "m=" line), the offerer MUST associate SDP 1128 'candidate' attributes (and other applicable ICE-related media-level 1129 SDP attributes), containing unique ICE properties (candidates etc), 1130 with the "m=" line, according to the procedures in 1131 [I-D.ietf-mmusic-ice-sip-sdp]. 1133 When an offerer associates a shared address with a bundled "m=" line, 1134 if the "m=" line is associated with the offerer BUNDLE-tag, the 1135 offerer MUST associate SDP 'candidate' attributes (and other 1136 applicable ICE-related media-level SDP attributes), containing shared 1137 ICE properties, with the "m=" line. If the "m=" line is not 1138 associated with the offerer BUNDLE-tag, the offerer MUST NOT 1139 associate ICE-related SDP attributes with the "m=" line. 1141 When an answerer associates a shared address with a bundled "m=" 1142 line, if the "m=" line is associated with the answerer BUNDLE-tag, 1143 the answerer MUST associate SDP 'candidate' attributes (and other 1144 applicable ICE-related media-level SDP attributes), containing shared 1145 ICE properties, with the "m=" line. If the "m=" line is not 1146 associated with the answerer BUNDLE-tag, the answerer MUST NOT 1147 associate ICE-related SDP attributes with the "m=" line. 1149 NOTE: As most ICE-related media-level SDP attributes belong to the 1150 TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the 1151 offerer and answerer follow the rules in Section 8.1. However, in 1152 the case of ICE-related media-level attributes, the rules apply to 1153 all attributes (see note below), even if they belong to a different 1154 mux category. 1156 NOTE: The following ICE-related media-level SDP attributes are 1157 defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote- 1158 candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- 1159 pacing'. 1161 11.1.1. Generating the Initial SDP Offer 1163 When an offerer generates an initial offer, the offerer MUST 1164 associate ICE-related media-level SDP attributes with each bundled 1165 "m=" line, according to [Section 11.1]. 1167 11.1.2. Generating the SDP Answer 1169 When an answerer generates an answer that contains a BUNDLE group, 1170 the answerer MUST associate ICE-related SDP attributes with the "m=" 1171 line associated with the answerer BUNDLE-tag, according to 1172 [Section 11.1]. 1174 11.1.3. Offerer Processing of the SDP Answer 1176 When an offerer receives an answer, if the answerer supports and uses 1177 the ICE mechanism and the BUNDLE extension, the offerer MUST 1178 associate the ICE properties associated with the offerer BUNDLE 1179 address, selected by the answerer [Section 8.3.1], with each bundled 1180 "m=" line. 1182 11.1.4. Modifying the Session 1184 When an offerer generates a subsequent offer, it MUST associate 1185 unique or shared ICE properties to one or more bundled "m=" lines, 1186 according to [Section 11.1]. 1188 12. DTLS Considerations 1190 One or more media streams within a BUNDLE group might use the 1191 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1192 to encrypt the data, or to negotiate encryption keys if another 1193 encryption mechanism is used to encrypt media. 1195 When DTLS is used within a BUNDLE group, the following rules apply: 1197 o There can only be one DTLS association [RFC6347] associated with 1198 the BUNDLE group; and 1200 o Each usage of the DTLS association within the BUNDLE group MUST 1201 use the same mechanism for determining which endpoints (the 1202 offerer or answerer) become DTLS client and DTLS server; and 1204 o Each usage of the DTLS association within the Bundle group MUST 1205 use the same mechanism for determining whether an offer or answer 1206 will trigger the establishment of a new DTLS association, or 1207 whether an existing DTLS association will be used; and 1209 o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include 1210 the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message 1211 [RFC5764], The client MUST include the extension even if the usage 1212 of DTLS-SRTP is not negotiated as part of the multimedia session 1213 (e.g., SIP session [RFC3261]. 1215 NOTE: The inclusion of the 'use_srtp' extension during the initial 1216 DTLS handshake ensures that a DTLS renegotiation will not be required 1217 in order to include the extension, in case DTLS-SRTP encrypted media 1218 is added to the BUNDLE group later during the multimedia session. 1220 13. Update to RFC 3264 1222 This section replaces the text of the following sections of RFC 3264: 1224 o Section 5.1 (Unicast Streams). 1226 o Section 8.2 (Removing a Media Stream). 1228 o Section 8.4 (Putting a Unicast Media Stream on Hold). 1230 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 1232 For recvonly and sendrecv streams, the port number and address in the 1233 offer indicate where the offerer would like to receive the media 1234 stream. For sendonly RTP streams, the address and port number 1235 indirectly indicate where the offerer wants to receive RTCP reports. 1236 Unless there is an explicit indication otherwise, reports are sent to 1237 the port number one higher than the number indicated. The IP address 1238 and port present in the offer indicate nothing about the source IP 1239 address and source port of RTP and RTCP packets that will be sent by 1240 the offerer. A port number of zero in the offer indicates that the 1241 stream is offered but MUST NOT be used. This has no useful semantics 1242 in an initial offer, but is allowed for reasons of completeness, 1243 since the answer can contain a zero port indicating a rejected stream 1244 (Section 6). Furthermore, existing streams can be terminated by 1245 setting the port to zero (Section 8). In general, a port number of 1246 zero indicates that the media stream is not wanted. 1248 13.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 1250 For recvonly and sendrecv streams, the port number and address in the 1251 offer indicate where the offerer would like to receive the media 1252 stream. For sendonly RTP streams, the address and port number 1253 indirectly indicate where the offerer wants to receive RTCP reports. 1254 Unless there is an explicit indication otherwise, reports are sent to 1255 the port number one higher than the number indicated. The IP address 1256 and port present in the offer indicate nothing about the source IP 1257 address and source port of RTP and RTCP packets that will be sent by 1258 the offerer. A port number of zero in the offer by default indicates 1259 that the stream is offered but MUST NOT be used, but an extension 1260 mechanism might specify different semantics for the usage of a zero 1261 port value. Furthermore, existing streams can be terminated by 1262 setting the port to zero (Section 8). In general, a port number of 1263 zero by default indicates that the media stream is not wanted. 1265 13.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 1267 A stream that is offered with a port of zero MUST be marked with port 1268 zero in the answer. Like the offer, the answer MAY omit all 1269 attributes present previously, and MAY list just a single media 1270 format from amongst those in the offer. 1272 13.4. New text replacing section 8.2 (2nd paragraph) of RFC 3264 1274 A stream that is offered with a port of zero MUST by default be 1275 marked with port zero in the answer, unless an extension mechanism, 1276 which specifies semantics for the usage of a non-zero port value, is 1277 used. If the stream is marked with port zero in the answer, the 1278 answer MAY omit all attributes present previously, and MAY list just 1279 a single media format from amongst those in the offer." 1281 13.5. Original text of section 8.4 (6th paragraph) of RFC 3264 1283 RFC 2543 [10] specified that placing a user on hold was accomplished 1284 by setting the connection address to 0.0.0.0. Its usage for putting 1285 a call on hold is no longer recommended, since it doesn't allow for 1286 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1287 with connection oriented media. However, it can be useful in an 1288 initial offer when the offerer knows it wants to use a particular set 1289 of media streams and formats, but doesn't know the addresses and 1290 ports at the time of the offer. Of course, when used, the port 1291 number MUST NOT be zero, which would specify that the stream has been 1292 disabled. An agent MUST be capable of receiving SDP with a 1293 connection address of 0.0.0.0, in which case it means that neither 1294 RTP nor RTCP should be sent to the peer. 1296 13.6. New text replacing section 8.4 (6th paragraph) of RFC 3264 1298 RFC 2543 [10] specified that placing a user on hold was accomplished 1299 by setting the connection address to 0.0.0.0. Its usage for putting 1300 a call on hold is no longer recommended, since it doesn't allow for 1301 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1302 with connection oriented media. However, it can be useful in an 1303 initial offer when the offerer knows it wants to use a particular set 1304 of media streams and formats, but doesn't know the addresses and 1305 ports at the time of the offer. Of course, when used, the port 1306 number MUST NOT be zero, if it would specify that the stream has been 1307 disabled. However, an extension mechanism might specify different 1308 semantics of the zero port number usage. An agent MUST be capable of 1309 receiving SDP with a connection address of 0.0.0.0, in which case it 1310 means that neither RTP nor RTCP should be sent to the peer. 1312 14. RTP/RTCP extensions for identification-tag transport 1314 SDP Offerers and Answerers [RFC3264] can associate identification- 1315 tags with "m=" lines within SDP Offers and Answers, using the 1316 procedures in [RFC5888]. Each identification-tag uniquely represents 1317 an "m=" line. 1319 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1320 used to carry identification-tags within RTCP SDES packets. This 1321 section also defines a new RTP SDES header extension [RFC7941], which 1322 is used to carry the 'MID' RTCP SDES item in RTP packets. 1324 The SDES item and RTP SDES header extension make it possible for a 1325 receiver to associate received RTCP- and RTP packets with a specific 1326 "m=" line, with which the receiver has associated an identification- 1327 tag, even if those "m=" lines are part of the same RTP session. The 1328 RTP SDES header extension also ensures that the media recipient gets 1329 the identification-tag upon receipt of the first decodable media and 1330 is able to associate the media with the correct application. 1332 A media recipient informs the media sender about the identification- 1333 tag associated with an "m=" line through the use of an 'mid' 1334 attribute [RFC5888]. The media sender then inserts the 1335 identification-tag in RTCP and RTP packets sent to the media 1336 recipient. 1338 NOTE: This text above defines how identification-tags are carried in 1339 SDP Offers and Answers. The usage of other signalling protocols for 1340 carrying identification-tags is not prevented, but the usage of such 1341 protocols is outside the scope of this document. 1343 [RFC3550] defines general procedures regarding the RTCP transmission 1344 interval. The RTCP MID SDES item SHOULD be sent in the first few 1345 RTCP packets sent after joining the session, and SHOULD be sent 1346 regularly thereafter. The exact number of RTCP packets in which this 1347 SDES item is sent is intentionally not specified here, as it will 1348 depend on the expected packet loss rate, the RTCP reporting interval, 1349 and the allowable overhead. 1351 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1352 be included in some RTP packets at the start of the session and 1353 whenever the SSRC changes. It might also be useful to include the 1354 header extension in RTP packets that comprise access points in the 1355 media (e.g., with video I-frames). The exact number of RTP packets 1356 in which this header extension is sent is intentionally not specified 1357 here, as it will depend on expected packet loss rate and loss 1358 patterns, the overhead the application can tolerate, and the 1359 importance of immediate receipt of the identification-tag. 1361 For robustness purpose, endpoints need to be prepared for situations 1362 where the reception of the identification-tag is delayed, and SHOULD 1363 NOT terminate sessions in such cases, as the identification-tag is 1364 likely to arrive soon. 1366 14.1. RTCP MID SDES Item 1368 0 1 2 3 1369 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 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | MID=TBD | length | identification-tag ... 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 The identification-tag payload is UTF-8 encoded, as in SDP. 1376 The identification-tag is not zero terminated. 1378 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1379 identifier value.] 1381 14.2. RTP SDES Header Extension For MID 1383 The payload, containing the identification-tag, of the RTP SDES 1384 header extension element can be encoded using either the one-byte or 1385 two-byte header [RFC7941]. The identification-tag payload is UTF-8 1386 encoded, as in SDP. 1388 The identification-tag is not zero terminated. Note, that the set of 1389 header extensions included in the packet needs to be padded to the 1390 next 32-bit boundary using zero bytes [RFC5285]. 1392 As the identification-tag is included in either an RTCP SDES item or 1393 an RTP SDES header extension, or both, there should be some 1394 consideration about the packet expansion caused by the 1395 identification-tag. To avoid Maximum Transmission Unit (MTU) issues 1396 for the RTP packets, the header extension's size needs to be taken 1397 into account when encoding the media. 1399 It is recommended that the identification-tag is kept short. Due to 1400 the properties of the RTP header extension mechanism, when using the 1401 one-byte header, a tag that is 1-3 bytes will result in a minimal 1402 number of 32-bit words used for the RTP SDES header extension, in 1403 case no other header extensions are included at the same time. Note, 1404 do take into account that some single characters when UTF-8 encoded 1405 will result in multiple octets. The identification-tag MUST NOT 1406 contain any user information, and applications SHALL avoid generating 1407 the identification-tag using a pattern that enables application 1408 identification. 1410 15. IANA Considerations 1412 15.1. New SDES item 1414 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1415 document.] 1417 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1418 identifier value.] 1420 This document adds the MID SDES item to the IANA "RTP SDES item 1421 types" registry as follows: 1423 Value: TBD 1424 Abbrev.: MID 1425 Name: Media Identification 1426 Reference: RFCXXXX 1428 15.2. New RTP SDES Header Extension URI 1430 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1431 document.] 1433 This document defines a new extension URI in the RTP SDES Compact 1434 Header Extensions sub-registry of the RTP Compact Header Extensions 1435 registry sub-registry, according to the following data: 1437 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1438 Description: Media identification 1439 Contact: christer.holmberg@ericsson.com 1440 Reference: RFCXXXX 1442 The SDES item does not reveal privacy information about the users. 1443 It is simply used to associate RTP-based media with the correct SDP 1444 media description (m- line) in the SDP used to negotiate the media. 1446 The purpose of the extension is for the offerer to be able to 1447 associate received multiplexed RTP-based media before the offerer 1448 receives the associated SDP answer. 1450 15.3. New SDP Attribute 1452 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1453 document.] 1455 This document defines a new SDP media-level attribute, 'bundle-only', 1456 according to the following data: 1458 Attribute name: bundle-only 1459 Type of attribute: media 1460 Subject to charset: No 1461 Purpose: Request a media description to be accepted 1462 in the answer only if kept within a BUNDLE 1463 group by the answerer. 1464 Appropriate values: N/A 1465 Contact name: Christer Holmberg 1466 Contact e-mail: christer.holmberg@ericsson.com 1467 Reference: RFCXXXX 1468 Mux category: NORMAL 1470 15.4. New SDP Group Semantics 1472 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1473 document.] 1475 This document registers the following semantics with IANA in the 1476 "Semantics for the "group" SDP Attribute" subregistry (under the 1477 "Session Description Protocol (SDP) Parameters" registry: 1479 Semantics Token Reference 1480 ------------------------------------- ------ --------- 1481 Media bundling BUNDLE [RFCXXXX] 1483 16. Security Considerations 1485 The security considerations defined in [RFC3264] and [RFC5888] apply 1486 to the BUNDLE extension. Bundle does not change which information 1487 flows over the network but only changes which addresses and ports 1488 that information is flowing on and thus has very little impact on the 1489 security of the RTP sessions. 1491 When the BUNDLE extension is used, a single set of security 1492 credentials might be used for all media streams specified by a BUNDLE 1493 group. 1495 When the BUNDLE extension is used, the number of SSRC values within a 1496 single RTP session increases, which increases the risk of SSRC 1497 collision. [RFC4568] describes how SSRC collision may weaken SRTP 1498 and SRTCP encryption in certain situations. 1500 17. Examples 1502 17.1. Example: Bundle Address Selection 1504 The example below shows: 1506 o An offer, in which the offerer associates a unique address with 1507 each bundled "m=" line within the BUNDLE group. 1509 o An answer, in which the answerer selects the offerer BUNDLE 1510 address, and then selects its own BUNDLE address (the answerer 1511 BUNDLE address) and associates it with each bundled "m=" line 1512 within the BUNDLE group. 1514 SDP Offer (1) 1516 v=0 1517 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1518 s= 1519 c=IN IP4 atlanta.example.com 1520 t=0 0 1521 a=group:BUNDLE foo bar 1522 m=audio 10000 RTP/AVP 0 8 97 1523 b=AS:200 1524 a=mid:foo 1525 a=rtcp-mux 1526 a=rtpmap:0 PCMU/8000 1527 a=rtpmap:8 PCMA/8000 1528 a=rtpmap:97 iLBC/8000 1529 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1530 m=video 10002 RTP/AVP 31 32 1531 b=AS:1000 1532 a=mid:bar 1533 a=rtcp-mux 1534 a=rtpmap:31 H261/90000 1535 a=rtpmap:32 MPV/90000 1536 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1538 SDP Answer (2) 1540 v=0 1541 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1542 s= 1543 c=IN IP4 biloxi.example.com 1544 t=0 0 1545 a=group:BUNDLE foo bar 1546 m=audio 20000 RTP/AVP 0 1547 b=AS:200 1548 a=mid:foo 1549 a=rtcp-mux 1550 a=rtpmap:0 PCMU/8000 1551 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1552 m=video 20000 RTP/AVP 32 1553 b=AS:1000 1554 a=mid:bar 1555 a=rtcp-mux 1556 a=rtpmap:32 MPV/90000 1557 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1559 17.2. Example: BUNDLE Extension Rejected 1561 The example below shows: 1563 o An offer, in which the offerer associates a unique address with 1564 each bundled "m=" line within the BUNDLE group. 1566 o An answer, in which the answerer rejects the offered BUNDLE group, 1567 and associates a unique address with each "m=" line (following 1568 normal RFC 3264 procedures). 1570 SDP Offer (1) 1572 v=0 1573 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1574 s= 1575 c=IN IP4 atlanta.example.com 1576 t=0 0 1577 a=group:BUNDLE foo bar 1578 m=audio 10000 RTP/AVP 0 8 97 1579 b=AS:200 1580 a=mid:foo 1581 a=rtcp-mux 1582 a=rtpmap:0 PCMU/8000 1583 a=rtpmap:8 PCMA/8000 1584 a=rtpmap:97 iLBC/8000 1585 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1586 m=video 10002 RTP/AVP 31 32 1587 b=AS:1000 1588 a=mid:bar 1589 a=rtcp-mux 1590 a=rtpmap:31 H261/90000 1591 a=rtpmap:32 MPV/90000 1592 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1594 SDP Answer (2) 1596 v=0 1597 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1598 s= 1599 c=IN IP4 biloxi.example.com 1600 t=0 0 1601 m=audio 20000 RTP/AVP 0 1602 b=AS:200 1603 a=rtcp-mux 1604 a=rtpmap:0 PCMU/8000 1605 m=video 30000 RTP/AVP 32 1606 b=AS:1000 1607 a=rtcp-mux 1608 a=rtpmap:32 MPV/90000 1610 17.3. Example: Offerer Adds A Media Description To A BUNDLE Group 1612 The example below shows: 1614 o A subsequent offer (the BUNDLE group has been created as part of a 1615 previous offer/answer exchange), in which the offerer adds a new 1616 "m=" line, represented by the "zen" identification-tag, to a 1617 previously negotiated BUNDLE group, associates a unique address 1618 with the added "m=" line, and associates the previously selected 1619 offerer BUNDLE address with each of the other bundled "m=" lines 1620 within the BUNDLE group. 1622 o An answer, in which the answerer associates the answerer BUNDLE 1623 address with each bundled "m=" line (including the newly added 1624 "m=" line) within the BUNDLE group. 1626 SDP Offer (1) 1628 v=0 1629 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1630 s= 1631 c=IN IP4 atlanta.example.com 1632 t=0 0 1633 a=group:BUNDLE foo bar zen 1634 m=audio 10000 RTP/AVP 0 8 97 1635 b=AS:200 1636 a=mid:foo 1637 a=rtcp-mux 1638 a=rtpmap:0 PCMU/8000 1639 a=rtpmap:8 PCMA/8000 1640 a=rtpmap:97 iLBC/8000 1641 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1642 m=video 10000 RTP/AVP 31 32 1643 b=AS:1000 1644 a=mid:bar 1645 a=rtcp-mux 1646 a=rtpmap:31 H261/90000 1647 a=rtpmap:32 MPV/90000 1648 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1649 m=video 20000 RTP/AVP 66 1650 b=AS:1000 1651 a=mid:zen 1652 a=rtcp-mux 1653 a=rtpmap:66 H261/90000 1654 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1656 SDP Answer (2) 1658 v=0 1659 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1660 s= 1661 c=IN IP4 biloxi.example.com 1662 t=0 0 1663 a=group:BUNDLE foo bar zen 1664 m=audio 20000 RTP/AVP 0 1665 b=AS:200 1666 a=mid:foo 1667 a=rtcp-mux 1668 a=rtpmap:0 PCMU/8000 1669 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1670 m=video 20000 RTP/AVP 32 1671 b=AS:1000 1672 a=mid:bar 1673 a=rtcp-mux 1674 a=rtpmap:32 MPV/90000 1675 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1676 m=video 20000 RTP/AVP 66 1677 b=AS:1000 1678 a=mid:zen 1679 a=rtcp-mux 1680 a=rtpmap:66 H261/90000 1681 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1683 17.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 1685 The example below shows: 1687 o A subsequent offer (the BUNDLE group has been created as part of a 1688 previous offer/answer transaction), in which the offerer moves a 1689 bundled "m=" line out of a BUNDLE group, associates a unique 1690 address with the moved "m=" line, and associates the offerer 1691 BUNDLE address with each other bundled "m=" line within the BUNDLE 1692 group. 1694 o An answer, in which the answerer moves the "m=" line out of the 1695 BUNDLE group, associates a unique address with the moved "m=" 1696 line, and associates the answerer BUNDLE address with each of the 1697 remaining bundled "m=" line within the BUNDLE group. 1699 SDP Offer (1) 1701 v=0 1702 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1703 s= 1704 c=IN IP4 atlanta.example.com 1705 t=0 0 1706 a=group:BUNDLE foo bar 1707 m=audio 10000 RTP/AVP 0 8 97 1708 b=AS:200 1709 a=mid:foo 1710 a=rtcp-mux 1711 a=rtpmap:0 PCMU/8000 1712 a=rtpmap:8 PCMA/8000 1713 a=rtpmap:97 iLBC/8000 1714 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1715 m=video 10000 RTP/AVP 31 32 1716 b=AS:1000 1717 a=mid:bar 1718 a=rtcp-mux 1719 a=rtpmap:31 H261/90000 1720 a=rtpmap:32 MPV/90000 1721 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1722 m=video 50000 RTP/AVP 66 1723 b=AS:1000 1724 a=mid:zen 1725 a=rtcp-mux 1726 a=rtpmap:66 H261/90000 1728 SDP Answer (2) 1730 v=0 1731 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1732 s= 1733 c=IN IP4 biloxi.example.com 1734 t=0 0 1735 a=group:BUNDLE foo bar 1736 m=audio 20000 RTP/AVP 0 1737 b=AS:200 1738 a=mid:foo 1739 a=rtcp-mux 1740 a=rtpmap:0 PCMU/8000 1741 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1742 m=video 20000 RTP/AVP 32 1743 b=AS:1000 1744 a=mid:bar 1745 a=rtcp-mux 1746 a=rtpmap:32 MPV/90000 1747 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1748 m=video 60000 RTP/AVP 66 1749 b=AS:1000 1750 a=mid:zen 1751 a=rtcp-mux 1752 a=rtpmap:66 H261/90000 1754 17.5. Example: Offerer Disables A Media Description Within A BUNDLE 1755 Group 1757 The example below shows: 1759 o A subsequent offer (the BUNDLE group has been created as part of a 1760 previous offer/answer transaction), in which the offerer disables 1761 a bundled "m=" line within a BUNDLE group, assigns a zero port 1762 number to the disabled "m=" line, and associates the offerer 1763 BUNDLE address with each of the other bundled "m=" lines within 1764 the BUNDLE group. 1766 o An answer, in which the answerer moves the disabled "m=" line out 1767 of the BUNDLE group, assigns a zero port value to the disabled 1768 "m=" line, and associates the answerer BUNDLE address with each of 1769 the remaining bundled "m=" line within the BUNDLE group. 1771 SDP Offer (1) 1773 v=0 1774 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1775 s= 1776 c=IN IP4 atlanta.example.com 1777 t=0 0 1778 a=group:BUNDLE foo bar 1779 m=audio 10000 RTP/AVP 0 8 97 1780 b=AS:200 1781 a=mid:foo 1782 a=rtcp-mux 1783 a=rtpmap:0 PCMU/8000 1784 a=rtpmap:8 PCMA/8000 1785 a=rtpmap:97 iLBC/8000 1786 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1787 m=video 10000 RTP/AVP 31 32 1788 b=AS:1000 1789 a=mid:bar 1790 a=rtcp-mux 1791 a=rtpmap:31 H261/90000 1792 a=rtpmap:32 MPV/90000 1793 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1794 m=video 0 RTP/AVP 66 1795 a=mid:zen 1796 a=rtpmap:66 H261/90000 1798 SDP Answer (2) 1800 v=0 1801 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1802 s= 1803 c=IN IP4 biloxi.example.com 1804 t=0 0 1805 a=group:BUNDLE foo bar 1806 m=audio 20000 RTP/AVP 0 1807 b=AS:200 1808 a=mid:foo 1809 a=rtcp-mux 1810 a=rtpmap:0 PCMU/8000 1811 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1812 m=video 20000 RTP/AVP 32 1813 b=AS:1000 1814 a=mid:bar 1815 a=rtcp-mux 1816 a=rtpmap:32 MPV/90000 1817 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1818 m=video 0 RTP/AVP 66 1819 a=mid:zen 1820 a=rtpmap:66 H261/90000 1822 18. Acknowledgements 1824 The usage of the SDP grouping extension for negotiating bundled media 1825 is based on a similar alternatives proposed by Harald Alvestrand and 1826 Cullen Jennings. The BUNDLE extension described in this document is 1827 based on the different alternative proposals, and text (e.g., SDP 1828 examples) have been borrowed (and, in some cases, modified) from 1829 those alternative proposals. 1831 The SDP examples are also modified versions from the ones in the 1832 Alvestrand proposal. 1834 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 1835 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 1836 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju and 1837 Justin Uberti for reading the text, and providing useful feedback. 1839 Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for 1840 providing help and text on the RTP/RTCP procedures. 1842 Thanks to Spotify for providing music for the countless hours of 1843 document editing. 1845 19. Change Log 1847 [RFC EDITOR NOTE: Please remove this section when publishing] 1849 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 1851 o Editorial changes based on comments from Eric Rescorla and Cullen 1852 Jennings: 1854 o - Changes regarding usage of RTP/RTCP multiplexing attributes. 1856 o - Additional text regarding associating RTP/RTCP packets with SDP 1857 m- lines. 1859 o - Reference correction. 1861 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32 1863 o Editorial changes based on comments from Eric Rescorla and Cullen 1864 Jennings: 1866 o - Justification for mechanism added to Introduction. 1868 o - Clarify that the order of m- lines in the group:BUNDLE attribute 1869 does not have to be the same as the order in which the m- lines 1870 are listed in the SDP. 1872 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31 1874 o Editorial changes based on GitHub Pull requests by Martin Thomson: 1876 o - https://github.com/cdh4u/draft-sdp-bundle/pull/2 1878 o - https://github.com/cdh4u/draft-sdp-bundle/pull/1 1880 o Editorial change based on comment from Diederick Huijbers (9th 1881 July 2016). 1883 o Changes based on comments from Flemming Andreasen (21st June 1884 2016): 1886 o - Mux category for SDP bundle-only attribute added. 1888 o - Mux category considerations editorial clarification. 1890 o - Editorial changes. 1892 o RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext. 1894 o Note whether Design Considerations appendix is to be kept removed: 1896 o - Appendix is kept within document. 1898 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30 1900 o Indicating in the Abstract and Introduction that the document 1901 updates RFC 3264. 1903 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29 1905 o Change based on WGLC comment from Colin Perkins. 1907 o - Clarify that SSRC can be reused by another source after a delay 1908 of 5 RTCP reporting intervals. 1910 o Change based on WGLC comment from Alissa Cooper. 1912 o - IANA registry name fix. 1914 o - Additional IANA registration information added. 1916 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28 1918 o - Alignment with exclusive mux procedures. 1920 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 1922 o - Yet another terminology change. 1924 o - Mux category considerations added. 1926 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 1928 o - ICE considerations modified: ICE-related SDP attributes only 1929 added to the bundled m- line representing the selected BUNDLE 1930 address. 1932 o - Reference to draft-ietf-mmusic-ice-sip-sdp added. 1934 o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- 1935 rfc5245bis. 1937 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 1939 o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux 1940 considerations. 1942 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 1944 o - Reference and procedures associated with exclusive RTP/RTCP mux 1945 added 1947 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 1949 o - RTCP-MUX mandatory for bundled RTP m- lines 1951 o - Editorial fixes based on comments from Flemming Andreasen 1953 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 1955 o - Correction of Ari's family name 1957 o - Editorial fixes based on comments from Thomas Stach 1959 o - RTP/RTCP correction based on comment from Magnus Westerlund 1961 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 1962 msg14861.html 1964 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 1966 o - Correct based on comment from Paul Kyzivat 1968 o -- 'received packets' replaced with 'received data' 1970 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 1972 o - Clarification based on comment from James Guballa 1974 o - Clarification based on comment from Flemming Andreasen 1976 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 1978 o - DTLS Considerations section added. 1980 o - BUNDLE semantics added to the IANA Considerations 1982 o - Changes based on WGLC comments from Adam Roach 1984 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 1985 msg14673.html 1987 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 1989 o - Changes based on agreements at IETF#92 1990 o -- BAS Offer removed, based on agreement at IETF#92. 1992 o -- Procedures regarding usage of SDP "b=" line is replaced with a 1993 reference to to draft-ietf-mmusic-sdp-mux-attributes. 1995 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 1997 o - Editorial changes based on comments from Magnus Westerlund. 1999 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 2001 o - Modification of RTP/RTCP multiplexing section, based on comments 2002 from Magnus Westerlund. 2004 o - Reference updates. 2006 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 2008 o - Editorial fix. 2010 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 2012 o - Editorial changes. 2014 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 2016 o Changes to allow a new suggested offerer BUNDLE address to be 2017 assigned to each bundled m- line. 2019 o Changes based on WGLC comments from Paul Kyzivat 2021 o - Editorial fixes 2023 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 2025 o Usage of SDP 'extmap' attribute added 2027 o SDP 'bundle-only' attribute scoped with "m=" lines with a zero 2028 port value 2030 o Changes based on WGLC comments from Thomas Stach 2032 o - ICE candidates not assigned to bundle-only m- lines with a zero 2033 port value 2035 o - Editorial changes 2037 o Changes based on WGLC comments from Colin Perkins 2038 o - Editorial changes: 2040 o -- "RTP SDES item" -> "RTCP SDES item" 2042 o -- "RTP MID SDES item" -> "RTCP MID SDES item" 2044 o - Changes in section 10.1.1: 2046 o -- "SHOULD NOT" -> "MUST NOT" 2048 o -- Additional text added to the Note 2050 o - Change to section 13.2: 2052 o -- Clarify that mid value is not zero terminated 2054 o - Change to section 13.3: 2056 o -- Clarify that mid value is not zero terminated 2058 o -- Clarify padding 2060 o Changes based on WGLC comments from Paul Kyzivat 2062 o - Editorial changes: 2064 o Changes based on WGLC comments from Jonathan Lennox 2066 o - Editorial changes: 2068 o - Defintion of SDP bundle-only attribute alligned with structure 2069 in 4566bis draft 2071 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 2073 o Editorial corrections based on comments from Harald Alvestrand. 2075 o Editorial corrections based on comments from Cullen Jennings. 2077 o Reference update (RFC 7160). 2079 o Clarification about RTCP packet sending when RTP/RTCP multiplexing 2080 is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ 2081 msg13765.html). 2083 o Additional text added to the Security Considerations. 2085 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 2086 o SDP bundle-only attribute added to IANA Considerations. 2088 o SDES item and RTP header extension added to Abstract and 2089 Introduction. 2091 o Modification to text updating section 8.2 of RFC 3264. 2093 o Reference corrections. 2095 o Editorial corrections. 2097 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 2099 o Terminology change: "bundle-only attribute assigned to m= line" to 2100 "bundle-only attribute associated with m= line". 2102 o Editorial corrections. 2104 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 2106 o Editorial corrections. 2108 o - "of"->"if" (8.3.2.5). 2110 o - "optional"->"OPTIONAL" (9.1). 2112 o - Syntax/ABNF for 'bundle-only' attribute added. 2114 o - SDP Offer/Answer sections merged. 2116 o - 'Request new offerer BUNDLE address' section added 2118 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 2120 o OPEN ISSUE regarding Receiver-ID closed. 2122 o - RTP MID SDES Item. 2124 o - RTP MID Header Extension. 2126 o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers 2127 closed. 2129 o - Indicating that, when rtcp-mux is used, the answerer MUST NOT 2130 include an 'rtcp' attribute in the answer, based on the procedures 2131 in section 5.1.3 of RFC 5761. 2133 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 2134 o Draft title changed. 2136 o Added "SDP" to section names containing "Offer" or "Answer". 2138 o Editorial fixes based on comments from Paul Kyzivat 2139 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2140 msg13314.html). 2142 o Editorial fixed based on comments from Colin Perkins 2143 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2144 msg13318.html). 2146 o - Removed text about extending BUNDLE to allow multiple RTP 2147 sessions within a BUNDLE group. 2149 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 2151 o Major re-structure of SDP Offer/Answer sections, to align with RFC 2152 3264 structure. 2154 o Additional definitions added. 2156 o - Shared address. 2158 o - Bundled "m=" line. 2160 o - Bundle-only "m=" line. 2162 o - Offerer suggested BUNDLE mid. 2164 o - Answerer selected BUNDLE mid. 2166 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 2167 to multiple "m=" lines until it has received an SDP Answer 2168 indicating support of the BUNDLE extension. 2170 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 2171 Answerer supports the BUNDLE extension, assign a zero port value 2172 to a 'bundle-only' "m=" line. 2174 o SDP 'bundle-only' attribute section added. 2176 o Connection data nettype/addrtype restrictions added. 2178 o RFC 3264 update section added. 2180 o Indicating that a specific payload type value can be used in 2181 multiple "m=" lines, if the value represents the same codec 2182 configuration in each "m=" line. 2184 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 2186 o Updated Offerer procedures (http://www.ietf.org/mail- 2187 archive/web/mmusic/current/msg12293.html). 2189 o Updated Answerer procedures (http://www.ietf.org/mail- 2190 archive/web/mmusic/current/msg12333.html). 2192 o Usage of SDP 'bundle-only' attribute added. 2194 o Reference to Trickle ICE document added. 2196 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 2198 o Mechanism modified, to be based on usage of SDP Offers with both 2199 different and identical port number values, depending on whether 2200 it is known if the remote endpoint supports the extension. 2202 o Cullen Jennings added as co-author. 2204 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 2206 o No changes. New version due to expiration. 2208 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 2210 o No changes. New version due to expiration. 2212 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 2214 o Draft name changed. 2216 o Harald Alvestrand added as co-author. 2218 o "Multiplex" terminology changed to "bundle". 2220 o Added text about single versus multiple RTP Sessions. 2222 o Added reference to RFC 3550. 2224 20. References 2226 20.1. Normative References 2228 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2229 Requirement Levels", BCP 14, RFC 2119, 2230 DOI 10.17487/RFC2119, March 1997, 2231 . 2233 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2234 with Session Description Protocol (SDP)", RFC 3264, 2235 DOI 10.17487/RFC3264, June 2002, 2236 . 2238 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2239 Jacobson, "RTP: A Transport Protocol for Real-Time 2240 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2241 July 2003, . 2243 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2244 in Session Description Protocol (SDP)", RFC 3605, 2245 DOI 10.17487/RFC3605, October 2003, 2246 . 2248 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2249 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2250 July 2006, . 2252 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2253 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2254 . 2256 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2257 (ICE): A Protocol for Network Address Translator (NAT) 2258 Traversal for Offer/Answer Protocols", RFC 5245, 2259 DOI 10.17487/RFC5245, April 2010, 2260 . 2262 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 2263 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2264 2008, . 2266 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2267 Control Packets on a Single Port", RFC 5761, 2268 DOI 10.17487/RFC5761, April 2010, 2269 . 2271 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2272 Security (DTLS) Extension to Establish Keys for the Secure 2273 Real-time Transport Protocol (SRTP)", RFC 5764, 2274 DOI 10.17487/RFC5764, May 2010, 2275 . 2277 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2278 Protocol (SDP) Grouping Framework", RFC 5888, 2279 DOI 10.17487/RFC5888, June 2010, 2280 . 2282 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2283 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2284 January 2012, . 2286 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2287 Header Extension for the RTP Control Protocol (RTCP) 2288 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2289 August 2016, . 2291 [I-D.ietf-ice-rfc5245bis] 2292 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2293 Connectivity Establishment (ICE): A Protocol for Network 2294 Address Translator (NAT) Traversal", draft-ietf-ice- 2295 rfc5245bis-04 (work in progress), June 2016. 2297 [I-D.ietf-mmusic-sdp-mux-attributes] 2298 Nandakumar, S., "A Framework for SDP Attributes when 2299 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-14 2300 (work in progress), September 2016. 2302 [I-D.ietf-mmusic-mux-exclusive] 2303 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 2304 Multiplexing using SDP", draft-ietf-mmusic-mux- 2305 exclusive-10 (work in progress), August 2016. 2307 [I-D.ietf-mmusic-ice-sip-sdp] 2308 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using 2309 Interactive Connectivity Establishment (ICE) with Session 2310 Description Protocol (SDP) offer/answer and Session 2311 Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip- 2312 sdp-10 (work in progress), July 2016. 2314 20.2. Informative References 2316 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2317 A., Peterson, J., Sparks, R., Handley, M., and E. 2318 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2319 DOI 10.17487/RFC3261, June 2002, 2320 . 2322 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 2323 Description Protocol (SDP) Security Descriptions for Media 2324 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 2325 . 2327 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2328 Media Attributes in the Session Description Protocol 2329 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2330 . 2332 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2333 Clock Rates in an RTP Session", RFC 7160, 2334 DOI 10.17487/RFC7160, April 2014, 2335 . 2337 [I-D.ietf-mmusic-trickle-ice] 2338 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 2339 Incremental Provisioning of Candidates for the Interactive 2340 Connectivity Establishment (ICE) Protocol", draft-ietf- 2341 mmusic-trickle-ice-02 (work in progress), January 2015. 2343 Appendix A. Design Considerations 2345 One of the main issues regarding the BUNDLE grouping extensions has 2346 been whether, in SDP Offers and SDP Answers, the same port value 2347 should be inserted in "m=" lines associated with a BUNDLE group, as 2348 the purpose of the extension is to negotiate the usage of a single 2349 address:port combination for media specified by the "m=" lines. 2350 Issues with both approaches, discussed in the Appendix have been 2351 raised. The outcome was to specify a mechanism which uses SDP Offers 2352 with both different and identical port values. 2354 Below are the primary issues that have been considered when defining 2355 the "BUNDLE" grouping extension: 2357 o 1) Interoperability with existing UAs. 2359 o 2) Interoperability with intermediary B2BUA- and proxy entities. 2361 o 3) Time to gather, and the number of, ICE candidates. 2363 o 4) Different error scenarios, and when they occur. 2365 o 5) SDP Offer/Answer impacts, including usage of port number value 2366 zero. 2368 A.1. UA Interoperability 2370 Consider the following SDP Offer/Answer exchange, where Alice sends 2371 an SDP Offer to Bob: 2373 SDP Offer 2375 v=0 2376 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2377 s= 2378 c=IN IP4 atlanta.example.com 2379 t=0 0 2380 m=audio 10000 RTP/AVP 97 2381 a=rtpmap:97 iLBC/8000 2382 m=video 10002 RTP/AVP 97 2383 a=rtpmap:97 H261/90000 2385 SDP Answer 2387 v=0 2388 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2389 s= 2390 c=IN IP4 biloxi.example.com 2391 t=0 0 2392 m=audio 20000 RTP/AVP 97 2393 a=rtpmap:97 iLBC/8000 2394 m=video 20002 RTP/AVP 97 2395 a=rtpmap:97 H261/90000 2397 RFC 4961 specifies a way of doing symmetric RTP but that is an a 2398 later invention to RTP and Bob can not assume that Alice supports RFC 2399 4961. This means that Alice may be sending RTP from a different port 2400 than 10000 or 10002 - some implementation simply send the RTP from an 2401 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2402 way that Bob knows if it should be passed to the video or audio codec 2403 is by looking at the port it was received on. This lead some SDP 2404 implementations to use the fact that each "m=" line had a different 2405 port number to use that port number as an index to find the correct m 2406 line in the SDP. As a result, some implementations that do support 2407 symmetric RTP and ICE still use a SDP data structure where SDP with 2408 "m=" lines with the same port such as: 2410 SDP Offer 2412 v=0 2413 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2414 s= 2415 c=IN IP4 atlanta.example.com 2416 t=0 0 2417 m=audio 10000 RTP/AVP 97 2418 a=rtpmap:97 iLBC/8000 2419 m=video 10000 RTP/AVP 98 2420 a=rtpmap:98 H261/90000 2422 will result in the second "m=" line being considered an SDP error 2423 because it has the same port as the first line. 2425 A.2. Usage of port number value zero 2427 In an SDP Offer or SDP Answer, the media specified by an "m=" line 2428 can be disabled/rejected by setting the port number value to zero. 2429 This is different from e.g., using the SDP direction attributes, 2430 where RTCP traffic will continue even if the SDP "inactive" attribute 2431 is indicated for the associated "m=" line. 2433 If each "m=" line associated with a BUNDLE group would contain 2434 different port values, and one of those port values would be used for 2435 a BUNDLE address associated with the BUNDLE group, problems would 2436 occur if an endpoint wants to disable/reject the "m=" line associated 2437 with that port, by setting the port value to zero. After that, no 2438 "m=" line would contain the port value which is used for the BUNDLE 2439 address. In addition, it is unclear what would happen to the ICE 2440 candidates associated with the "m=" line, as they are also used for 2441 the BUNDLE address. 2443 A.3. B2BUA And Proxy Interoperability 2445 Some back to back user agents may be configured in a mode where if 2446 the incoming call leg contains an SDP attribute the B2BUA does not 2447 understand, the B2BUA still generates that SDP attribute in the Offer 2448 for the outgoing call leg. Consider a B2BUA that did not understand 2449 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 2450 Further assume that the B2BUA was configured to tear down any call 2451 where it did not see any RTCP for 5 minutes. In this case, if the 2452 B2BUA received an Offer like: 2454 SDP Offer 2456 v=0 2457 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2458 s= 2459 c=IN IP4 atlanta.example.com 2460 t=0 0 2461 m=audio 49170 RTP/AVP 0 2462 a=rtcp:53020 2464 It would be looking for RTCP on port 49172 but would not see any 2465 because the RTCP would be on port 53020 and after five minutes, it 2466 would tear down the call. Similarly, a B2BUA that did not understand 2467 BUNDLE yet put BUNDLE in it's offer may be looking for media on the 2468 wrong port and tear down the call. It is worth noting that a B2BUA 2469 that generated an Offer with capabilities it does not understand is 2470 not compliant with the specifications. 2472 A.3.1. Traffic Policing 2474 Sometimes intermediaries do not act as B2BUA, in the sense that they 2475 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2476 however, they may use SDP information (e.g., IP address and port) in 2477 order to control traffic gating functions, and to set traffic 2478 policing rules. There might be rules which will trigger a session to 2479 be terminated in case media is not sent or received on the ports 2480 retrieved from the SDP. This typically occurs once the session is 2481 already established and ongoing. 2483 A.3.2. Bandwidth Allocation 2485 Sometimes intermediaries do not act as B2BUA, in the sense that they 2486 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2487 however, they may use SDP information (e.g., codecs and media types) 2488 in order to control bandwidth allocation functions. The bandwidth 2489 allocation is done per "m=" line, which means that it might not be 2490 enough if media specified by all "m=" lines try to use that 2491 bandwidth. That may either simply lead to bad user experience, or to 2492 termination of the call. 2494 A.4. Candidate Gathering 2496 When using ICE, a candidate needs to be gathered for each port. This 2497 takes approximately 20 ms extra for each extra "m=" line due to the 2498 NAT pacing requirements. All of this gather can be overlapped with 2499 other things while for exampe a web-page is loading to minimize the 2500 impact. If the client only wants to generate TURN or STUN ICE 2501 candidates for one of the "m=" lines and then use trickle ICE 2502 [I-D.ietf-mmusic-trickle-ice] to get the non host ICE candidates for 2503 the rest of the "m=" lines, it MAY do that and will not need any 2504 additional gathering time. 2506 Some people have suggested a TURN extension to get a bunch of TURN 2507 allocations at once. This would only provide a single STUN result so 2508 in cases where the other end did not support BUNDLE, may cause more 2509 use of the TURN server but would be quick in the cases where both 2510 sides supported BUNDLE and would fall back to a successful call in 2511 the other cases. 2513 Authors' Addresses 2515 Christer Holmberg 2516 Ericsson 2517 Hirsalantie 11 2518 Jorvas 02420 2519 Finland 2521 Email: christer.holmberg@ericsson.com 2523 Harald Tveit Alvestrand 2524 Google 2525 Kungsbron 2 2526 Stockholm 11122 2527 Sweden 2529 Email: harald@alvestrand.no 2531 Cullen Jennings 2532 Cisco 2533 400 3rd Avenue SW, Suite 350 2534 Calgary, AB T2P 4H2 2535 Canada 2537 Email: fluffy@iii.ca