idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-35.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 25, 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 1300 == Missing Reference: 'RFCXXXX' is mentioned on line 1483, 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 28, 2017 C. Jennings 7 Cisco 8 October 25, 2016 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-35.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 28, 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 Streams 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 Streams With Correct SDP Media Description 930 As described in [RFC3550], RTP/RTCP packets are associated with RTP 931 streams. Each RTP stream is identified by an SSRC value, and each 932 RTP/RTCP packet carries an SSRC value that is used to associate the 933 packet with the correct RTP stream (an RTCP packet can carry multiple 934 SSRC values, and might therefore be associated with multiple RTP 935 streams). 937 In order to be able to process received RTP/RTCP packets correctly it 938 must be possible to associate an RTP stream with the correct "m=" 939 line, as the "m=" line and SDP attributes associated with the "m=" 940 line contain information needed to process the packets. 942 As all RTP streams associated with a BUNDLE group are using the same 943 address:port combination for sending and receiving RTP/RTCP packets, 944 the local address:port combination cannot be used to associate an RTP 945 stream with the correct "m=" line. In addition, multiple RTP streams 946 might be associated with the same "m=" line. 948 Also, as described in [Section 10.1.1], the same payload type value 949 might be used by multiple RTP streams, in which case the payload type 950 value cannot be used to associate an RTP stream with the correct "m=" 951 line. 953 An offerer and answerer can inform each other which SSRC values they 954 will use for an RTP stream by using the SDP 'ssrc' attribute 955 [RFC5576]. However, an offerer will not know which SSRC values the 956 answerer will use until the offerer has received the answer providing 957 that information. Due to this, before the offerer has received the 958 answer, the offerer will not be able to associate an RTP stream with 959 the correct "m=" line using the SSRC value associated with the RTP 960 stream. In addition, the offerer and answerer may start using new 961 SSRC values mid-session, without informing each other using the SDP 962 'ssrc' attribute. 964 In order for an offerer and answerer to always be able to associate 965 an RTP stream with the correct "m=" line, the offerer and answerer 966 using the BUNDLE extension MUST support the mechanism defined in 967 Section 14, where the offerer and answerer insert the identification- 968 tag (provided by the remote peer) associated with an "m=" line in RTP 969 and RTCP packets associated with a BUNDLE group. 971 Once an offerer or answerer recieve an RTP/RTCP packet carrying an 972 identification-tag and an SSRC value (an RTCP packet might carry 973 multiple identification-tags and SSRC values), it creates a mapping 974 between the SSRC value and the identification-tag, in order to 975 associate the RTP stream with the "m=" line associated with the 976 identification-tag. Note that the mapping might change mid-session 977 if, for a given SSRC value, a different identification-tag is 978 provided in an RTP/RTCP packet. 980 If an offerer and answerer is not able to associate an RTP stream 981 with an "m=" line (using the mechanisms described in this section, or 982 using other appropriate mechanism, e.g, based on the payload type 983 value if it is unique to a single a€œm=a€ line), 984 it MUST either drop the RTP/RTCP packets associated with the RTP 985 stream, or process them in an application specific manner, once non- 986 stream specific processing (e.g., related to congestion control) of 987 the packets have occurred. Note that RTCP packets might be 988 associated with multiple RTP streams. 990 10.3. RTP/RTCP Multiplexing 992 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 993 multiplexing [RFC5761] for the RTP-based media specified by the 994 BUNDLE group. 996 When RTP/RTCP multiplexing is enabled, the same address:port 997 combination will be used for sending all RTP packets and the RTCP 998 packets associated with the BUNDLE group. Each endpoint will send 999 the packets towards the BUNDLE address of the other endpoint. The 1000 same address:port combination MAY be used for receiving RTP packets 1001 and RTCP packets. 1003 10.3.1. SDP Offer/Answer Procedures 1005 This section describes how an offerer and answerer use the SDP 'rtcp- 1006 mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute 1007 [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP 1008 multiplexing for RTP-based media specified by a BUNDLE group. 1010 The procedures in this section only apply to RTP-based "m=" lines. 1012 10.3.1.1. Generating the Initial SDP Offer 1014 When an offerer generates an initial offer, the offerer MUST 1015 associate an SDP 'rtcp-mux' attribute [RFC5761] with each bundled 1016 RTP-based "m=" line in the offer, including a bundle-only "m=" line. 1017 In addition, the offerer MUST associate an SDP 'rtcp-mux-only' 1018 attribute [I-D.ietf-mmusic-mux-exclusive] with each RTP-based bundle- 1019 only "m=" line, and MAY associated an SDP 'rtcp-mux-only' attribute 1020 with other bundled RTP-based "m=" lines. 1022 NOTE: Whether the offerer associates an SDP 'rtcp-mux-only' attribute 1023 with a bundled "m=" line or not depends on whether the offerer 1024 supports fallback to usage of a separate port for RTCP in case the 1025 answerer does not include the "m=" line in the BUNDLE group. 1027 NOTE: If the offerer associates an SDP 'rtcp-mux' attribute with a 1028 bundled "m=" line, but does not associate an SDP 'rtcp-mux-only' 1029 attribute with the "m=" line, the offerer can also associate an SDP 1030 'rtcp' attribute [RFC3605] with the "m=" line in order to provide a 1031 fallback port for RTCP, as described in [RFC5761]. However, the 1032 fallback port will only be used in case the answerer does not include 1033 the "m=" line in the BUNDLE group. 1035 In the initial offer, the address:port combination for RTCP MUST be 1036 unique in each bundled RTP-based "m=" line (excluding a bundle-only 1037 "m=" line), similar to RTP. 1039 10.3.1.2. Generating the SDP Answer 1041 When an answerer generates an answer, if the answerer accepts one or 1042 more RTP-based "m=" lines within a BUNDLE group, the answerer MUST 1043 enable usage of RTP/RTCP multiplexing. The answerer MUST associate 1044 an SDP "rtcp-mux" attribute with each RTP-based "m=" line in the 1045 answer. In addition, if an "m=" line in the corresponding offer 1046 contained an SDP "rtcp-mux-only" attribute, the answerer MUST 1047 associate an SDP "rtcp-mux-only" attribute with the "m=" line in the 1048 answer. 1050 If an RTP-based "m=" line in the corresponding offer did not contain 1051 an SDP 'rtcp-mux' attribute, the answerer MUST NOT include the "m=" 1052 line within a BUNDLE group in the answer. 1054 If an RTP-based "m=" line in the corresponding offer contained an SDP 1055 "rtcp-mux-only" attribute, and if the answerer moves the "m=" line 1056 out of the BUNDLE group in the answer Section 8.3.3, the answerer 1057 MUST still either enable RTP/RTCP multiplexing for the media 1058 associated with the "m=" line, or reject the "m=" line Section 8.3.4. 1060 The answerer MUST NOT associate an SDP 'rtcp' attribute with any 1061 bundled "m=" line in the answer. The answerer will use the port 1062 value of the selected offerer BUNDLE address for sending RTP and RTCP 1063 packets associated with each RTP-based bundled "m=" line towards the 1064 offerer. 1066 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1067 negotiated in a previous offer/answer transaction, the answerer MUST 1068 associate an SDP 'rtcp-mux' attribute with each bundled RTP-based 1069 "m=" line in the answer. 1071 10.3.1.3. Offerer Processing of the SDP Answer 1073 When an offerer receives an answer, if the answerer has accepted the 1074 usage of RTP/RTCP multiplexing (see Section 10.3.1.2), the answerer 1075 follows the procedures for RTP/RTCP multiplexing defined in 1076 [RFC5761]. The offerer will use the port value associated with the 1077 answerer BUNDLE address for sending RTP and RTCP packets associated 1078 with each RTP-based bundled "m=" line towards the answerer. 1080 NOTE: It is considered a protocol error if the answerer has not 1081 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" lines 1082 that the answerer included in the BUNDLE group. 1084 10.3.1.4. Modifying the Session 1086 When an offerer generates a subsequent offer, for each RTP-based "m=" 1087 line that was previously added to the BUNDLE group the offerer MUST 1088 associate an SDP 'rtcp-mux' attribute and an SDP 'rtcp-mux-only' 1089 attribute with the "m=" line in the same way it was previously done, 1090 unless the offerer wants to disable or remove the "m=" line from the 1091 BUNDLE group. 1093 If the offerer wants to add a bundled RTP-based "m=" line to the 1094 BUNDLE group, it associates an SDP 'rtcp-mux' attribute and an SDP 1095 'rtcp-mux-only' attribute with the "m=" line using the procedures in 1096 [Section 10.3.1.1]. 1098 11. ICE Considerations 1100 This section describes how to use the BUNDLE grouping extension 1101 together with the Interactive Connectivity Establishment (ICE) 1102 mechanism [I-D.ietf-ice-rfc5245bis]. 1104 The generic procedures for negotiating usage of ICE using SDP, 1105 defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE 1106 with BUNDLE, with the following exceptions: 1108 o When BUNDLE addresses for a BUNDLE group have been selected for 1109 both endpoints, ICE connectivity checks and keep-alives only need 1110 to be performed for the whole BUNDLE group, instead of per bundled 1111 "m=" line. 1113 o Among bundled "m=" lines with which the offerer has associated a 1114 shared address, the offerer only associates ICE-related media- 1115 level SDP attributes with the "m=" line associated with the 1116 offerer BUNDLE-tag. 1118 o Among bundled "m=" lines with which the answerer has associated a 1119 shared address, the answerer only associates ICE-related media- 1120 level SDP attributes with the "m=" line associated with the 1121 answerer BUNDLE-tag. 1123 Support and usage of ICE mechanism together with the BUNDLE extension 1124 is OPTIONAL. 1126 11.1. SDP Offer/Answer Procedures 1128 When an offerer associates a unique address with a bundled "m=" line 1129 (excluding any bundle-only "m=" line), the offerer MUST associate SDP 1130 'candidate' attributes (and other applicable ICE-related media-level 1131 SDP attributes), containing unique ICE properties (candidates etc), 1132 with the "m=" line, according to the procedures in 1133 [I-D.ietf-mmusic-ice-sip-sdp]. 1135 When an offerer associates a shared address with a bundled "m=" line, 1136 if the "m=" line is associated with the offerer BUNDLE-tag, the 1137 offerer MUST associate SDP 'candidate' attributes (and other 1138 applicable ICE-related media-level SDP attributes), containing shared 1139 ICE properties, with the "m=" line. If the "m=" line is not 1140 associated with the offerer BUNDLE-tag, the offerer MUST NOT 1141 associate ICE-related SDP attributes with the "m=" line. 1143 When an answerer associates a shared address with a bundled "m=" 1144 line, if the "m=" line is associated with the answerer BUNDLE-tag, 1145 the answerer MUST associate SDP 'candidate' attributes (and other 1146 applicable ICE-related media-level SDP attributes), containing shared 1147 ICE properties, with the "m=" line. If the "m=" line is not 1148 associated with the answerer BUNDLE-tag, the answerer MUST NOT 1149 associate ICE-related SDP attributes with the "m=" line. 1151 NOTE: As most ICE-related media-level SDP attributes belong to the 1152 TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the 1153 offerer and answerer follow the rules in Section 8.1. However, in 1154 the case of ICE-related media-level attributes, the rules apply to 1155 all attributes (see note below), even if they belong to a different 1156 mux category. 1158 NOTE: The following ICE-related media-level SDP attributes are 1159 defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote- 1160 candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- 1161 pacing'. 1163 11.1.1. Generating the Initial SDP Offer 1165 When an offerer generates an initial offer, the offerer MUST 1166 associate ICE-related media-level SDP attributes with each bundled 1167 "m=" line, according to [Section 11.1]. 1169 11.1.2. Generating the SDP Answer 1171 When an answerer generates an answer that contains a BUNDLE group, 1172 the answerer MUST associate ICE-related SDP attributes with the "m=" 1173 line associated with the answerer BUNDLE-tag, according to 1174 [Section 11.1]. 1176 11.1.3. Offerer Processing of the SDP Answer 1178 When an offerer receives an answer, if the answerer supports and uses 1179 the ICE mechanism and the BUNDLE extension, the offerer MUST 1180 associate the ICE properties associated with the offerer BUNDLE 1181 address, selected by the answerer [Section 8.3.1], with each bundled 1182 "m=" line. 1184 11.1.4. Modifying the Session 1186 When an offerer generates a subsequent offer, it MUST associate 1187 unique or shared ICE properties to one or more bundled "m=" lines, 1188 according to [Section 11.1]. 1190 12. DTLS Considerations 1192 One or more media streams within a BUNDLE group might use the 1193 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1194 to encrypt the data, or to negotiate encryption keys if another 1195 encryption mechanism is used to encrypt media. 1197 When DTLS is used within a BUNDLE group, the following rules apply: 1199 o There can only be one DTLS association [RFC6347] associated with 1200 the BUNDLE group; and 1202 o Each usage of the DTLS association within the BUNDLE group MUST 1203 use the same mechanism for determining which endpoints (the 1204 offerer or answerer) become DTLS client and DTLS server; and 1206 o Each usage of the DTLS association within the Bundle group MUST 1207 use the same mechanism for determining whether an offer or answer 1208 will trigger the establishment of a new DTLS association, or 1209 whether an existing DTLS association will be used; and 1211 o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include 1212 the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message 1213 [RFC5764], The client MUST include the extension even if the usage 1214 of DTLS-SRTP is not negotiated as part of the multimedia session 1215 (e.g., SIP session [RFC3261]. 1217 NOTE: The inclusion of the 'use_srtp' extension during the initial 1218 DTLS handshake ensures that a DTLS renegotiation will not be required 1219 in order to include the extension, in case DTLS-SRTP encrypted media 1220 is added to the BUNDLE group later during the multimedia session. 1222 13. Update to RFC 3264 1224 This section replaces the text of the following sections of RFC 3264: 1226 o Section 5.1 (Unicast Streams). 1228 o Section 8.2 (Removing a Media Stream). 1230 o Section 8.4 (Putting a Unicast Media Stream on Hold). 1232 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 1234 For recvonly and sendrecv streams, the port number and address in the 1235 offer indicate where the offerer would like to receive the media 1236 stream. For sendonly RTP streams, the address and port number 1237 indirectly indicate where the offerer wants to receive RTCP reports. 1238 Unless there is an explicit indication otherwise, reports are sent to 1239 the port number one higher than the number indicated. The IP address 1240 and port present in the offer indicate nothing about the source IP 1241 address and source port of RTP and RTCP packets that will be sent by 1242 the offerer. A port number of zero in the offer indicates that the 1243 stream is offered but MUST NOT be used. This has no useful semantics 1244 in an initial offer, but is allowed for reasons of completeness, 1245 since the answer can contain a zero port indicating a rejected stream 1246 (Section 6). Furthermore, existing streams can be terminated by 1247 setting the port to zero (Section 8). In general, a port number of 1248 zero indicates that the media stream is not wanted. 1250 13.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 1252 For recvonly and sendrecv streams, the port number and address in the 1253 offer indicate where the offerer would like to receive the media 1254 stream. For sendonly RTP streams, the address and port number 1255 indirectly indicate where the offerer wants to receive RTCP reports. 1256 Unless there is an explicit indication otherwise, reports are sent to 1257 the port number one higher than the number indicated. The IP address 1258 and port present in the offer indicate nothing about the source IP 1259 address and source port of RTP and RTCP packets that will be sent by 1260 the offerer. A port number of zero in the offer by default indicates 1261 that the stream is offered but MUST NOT be used, but an extension 1262 mechanism might specify different semantics for the usage of a zero 1263 port value. Furthermore, existing streams can be terminated by 1264 setting the port to zero (Section 8). In general, a port number of 1265 zero by default indicates that the media stream is not wanted. 1267 13.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 1269 A stream that is offered with a port of zero MUST be marked with port 1270 zero in the answer. Like the offer, the answer MAY omit all 1271 attributes present previously, and MAY list just a single media 1272 format from amongst those in the offer. 1274 13.4. New text replacing section 8.2 (2nd paragraph) of RFC 3264 1276 A stream that is offered with a port of zero MUST by default be 1277 marked with port zero in the answer, unless an extension mechanism, 1278 which specifies semantics for the usage of a non-zero port value, is 1279 used. If the stream is marked with port zero in the answer, the 1280 answer MAY omit all attributes present previously, and MAY list just 1281 a single media format from amongst those in the offer." 1283 13.5. Original text of section 8.4 (6th paragraph) of RFC 3264 1285 RFC 2543 [10] specified that placing a user on hold was accomplished 1286 by setting the connection address to 0.0.0.0. Its usage for putting 1287 a call on hold is no longer recommended, since it doesn't allow for 1288 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1289 with connection oriented media. However, it can be useful in an 1290 initial offer when the offerer knows it wants to use a particular set 1291 of media streams and formats, but doesn't know the addresses and 1292 ports at the time of the offer. Of course, when used, the port 1293 number MUST NOT be zero, which would specify that the stream has been 1294 disabled. An agent MUST be capable of receiving SDP with a 1295 connection address of 0.0.0.0, in which case it means that neither 1296 RTP nor RTCP should be sent to the peer. 1298 13.6. New text replacing section 8.4 (6th paragraph) of RFC 3264 1300 RFC 2543 [10] specified that placing a user on hold was accomplished 1301 by setting the connection address to 0.0.0.0. Its usage for putting 1302 a call on hold is no longer recommended, since it doesn't allow for 1303 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1304 with connection oriented media. However, it can be useful in an 1305 initial offer when the offerer knows it wants to use a particular set 1306 of media streams and formats, but doesn't know the addresses and 1307 ports at the time of the offer. Of course, when used, the port 1308 number MUST NOT be zero, if it would specify that the stream has been 1309 disabled. However, an extension mechanism might specify different 1310 semantics of the zero port number usage. An agent MUST be capable of 1311 receiving SDP with a connection address of 0.0.0.0, in which case it 1312 means that neither RTP nor RTCP should be sent to the peer. 1314 14. RTP/RTCP extensions for identification-tag transport 1316 SDP Offerers and Answerers [RFC3264] can associate identification- 1317 tags with "m=" lines within SDP Offers and Answers, using the 1318 procedures in [RFC5888]. Each identification-tag uniquely represents 1319 an "m=" line. 1321 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1322 used to carry identification-tags within RTCP SDES packets. This 1323 section also defines a new RTP SDES header extension [RFC7941], which 1324 is used to carry the 'MID' RTCP SDES item in RTP packets. 1326 The SDES item and RTP SDES header extension make it possible for a 1327 receiver to associate received RTCP- and RTP packets with a specific 1328 "m=" line, with which the receiver has associated an identification- 1329 tag, even if those "m=" lines are part of the same RTP session. The 1330 RTP SDES header extension also ensures that the media recipient gets 1331 the identification-tag upon receipt of the first decodable media and 1332 is able to associate the media with the correct application. 1334 A media recipient informs the media sender about the identification- 1335 tag associated with an "m=" line through the use of an 'mid' 1336 attribute [RFC5888]. The media sender then inserts the 1337 identification-tag in RTCP and RTP packets sent to the media 1338 recipient. 1340 NOTE: This text above defines how identification-tags are carried in 1341 SDP Offers and Answers. The usage of other signalling protocols for 1342 carrying identification-tags is not prevented, but the usage of such 1343 protocols is outside the scope of this document. 1345 [RFC3550] defines general procedures regarding the RTCP transmission 1346 interval. The RTCP MID SDES item SHOULD be sent in the first few 1347 RTCP packets sent after joining the session, and SHOULD be sent 1348 regularly thereafter. The exact number of RTCP packets in which this 1349 SDES item is sent is intentionally not specified here, as it will 1350 depend on the expected packet loss rate, the RTCP reporting interval, 1351 and the allowable overhead. 1353 The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD 1354 be included in some RTP packets at the start of the session and 1355 whenever the SSRC changes. It might also be useful to include the 1356 header extension in RTP packets that comprise access points in the 1357 media (e.g., with video I-frames). The exact number of RTP packets 1358 in which this header extension is sent is intentionally not specified 1359 here, as it will depend on expected packet loss rate and loss 1360 patterns, the overhead the application can tolerate, and the 1361 importance of immediate receipt of the identification-tag. 1363 For robustness purpose, endpoints need to be prepared for situations 1364 where the reception of the identification-tag is delayed, and SHOULD 1365 NOT terminate sessions in such cases, as the identification-tag is 1366 likely to arrive soon. 1368 14.1. RTCP MID SDES Item 1370 0 1 2 3 1371 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 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | MID=TBD | length | identification-tag ... 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 The identification-tag payload is UTF-8 encoded, as in SDP. 1378 The identification-tag is not zero terminated. 1380 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1381 identifier value.] 1383 14.2. RTP SDES Header Extension For MID 1385 The payload, containing the identification-tag, of the RTP SDES 1386 header extension element can be encoded using either the one-byte or 1387 two-byte header [RFC7941]. The identification-tag payload is UTF-8 1388 encoded, as in SDP. 1390 The identification-tag is not zero terminated. Note, that the set of 1391 header extensions included in the packet needs to be padded to the 1392 next 32-bit boundary using zero bytes [RFC5285]. 1394 As the identification-tag is included in either an RTCP SDES item or 1395 an RTP SDES header extension, or both, there should be some 1396 consideration about the packet expansion caused by the 1397 identification-tag. To avoid Maximum Transmission Unit (MTU) issues 1398 for the RTP packets, the header extension's size needs to be taken 1399 into account when encoding the media. 1401 It is recommended that the identification-tag is kept short. Due to 1402 the properties of the RTP header extension mechanism, when using the 1403 one-byte header, a tag that is 1-3 bytes will result in a minimal 1404 number of 32-bit words used for the RTP SDES header extension, in 1405 case no other header extensions are included at the same time. Note, 1406 do take into account that some single characters when UTF-8 encoded 1407 will result in multiple octets. The identification-tag MUST NOT 1408 contain any user information, and applications SHALL avoid generating 1409 the identification-tag using a pattern that enables application 1410 identification. 1412 15. IANA Considerations 1414 15.1. New SDES item 1416 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1417 document.] 1419 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1420 identifier value.] 1422 This document adds the MID SDES item to the IANA "RTP SDES item 1423 types" registry as follows: 1425 Value: TBD 1426 Abbrev.: MID 1427 Name: Media Identification 1428 Reference: RFCXXXX 1430 15.2. New RTP SDES Header Extension URI 1432 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1433 document.] 1435 This document defines a new extension URI in the RTP SDES Compact 1436 Header Extensions sub-registry of the RTP Compact Header Extensions 1437 registry sub-registry, according to the following data: 1439 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1440 Description: Media identification 1441 Contact: christer.holmberg@ericsson.com 1442 Reference: RFCXXXX 1444 The SDES item does not reveal privacy information about the users. 1445 It is simply used to associate RTP-based media with the correct SDP 1446 media description (m- line) in the SDP used to negotiate the media. 1448 The purpose of the extension is for the offerer to be able to 1449 associate received multiplexed RTP-based media before the offerer 1450 receives the associated SDP answer. 1452 15.3. New SDP Attribute 1454 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1455 document.] 1457 This document defines a new SDP media-level attribute, 'bundle-only', 1458 according to the following data: 1460 Attribute name: bundle-only 1461 Type of attribute: media 1462 Subject to charset: No 1463 Purpose: Request a media description to be accepted 1464 in the answer only if kept within a BUNDLE 1465 group by the answerer. 1466 Appropriate values: N/A 1467 Contact name: Christer Holmberg 1468 Contact e-mail: christer.holmberg@ericsson.com 1469 Reference: RFCXXXX 1470 Mux category: NORMAL 1472 15.4. New SDP Group Semantics 1474 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1475 document.] 1477 This document registers the following semantics with IANA in the 1478 "Semantics for the "group" SDP Attribute" subregistry (under the 1479 "Session Description Protocol (SDP) Parameters" registry: 1481 Semantics Token Reference 1482 ------------------------------------- ------ --------- 1483 Media bundling BUNDLE [RFCXXXX] 1485 16. Security Considerations 1487 The security considerations defined in [RFC3264] and [RFC5888] apply 1488 to the BUNDLE extension. Bundle does not change which information 1489 flows over the network but only changes which addresses and ports 1490 that information is flowing on and thus has very little impact on the 1491 security of the RTP sessions. 1493 When the BUNDLE extension is used, a single set of security 1494 credentials might be used for all media streams specified by a BUNDLE 1495 group. 1497 When the BUNDLE extension is used, the number of SSRC values within a 1498 single RTP session increases, which increases the risk of SSRC 1499 collision. [RFC4568] describes how SSRC collision may weaken SRTP 1500 and SRTCP encryption in certain situations. 1502 17. Examples 1504 17.1. Example: Bundle Address Selection 1506 The example below shows: 1508 o An offer, in which the offerer associates a unique address with 1509 each bundled "m=" line within the BUNDLE group. 1511 o An answer, in which the answerer selects the offerer BUNDLE 1512 address, and then selects its own BUNDLE address (the answerer 1513 BUNDLE address) and associates it with each bundled "m=" line 1514 within the BUNDLE group. 1516 SDP Offer (1) 1518 v=0 1519 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1520 s= 1521 c=IN IP4 atlanta.example.com 1522 t=0 0 1523 a=group:BUNDLE foo bar 1524 m=audio 10000 RTP/AVP 0 8 97 1525 b=AS:200 1526 a=mid:foo 1527 a=rtcp-mux 1528 a=rtpmap:0 PCMU/8000 1529 a=rtpmap:8 PCMA/8000 1530 a=rtpmap:97 iLBC/8000 1531 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1532 m=video 10002 RTP/AVP 31 32 1533 b=AS:1000 1534 a=mid:bar 1535 a=rtcp-mux 1536 a=rtpmap:31 H261/90000 1537 a=rtpmap:32 MPV/90000 1538 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1540 SDP Answer (2) 1542 v=0 1543 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1544 s= 1545 c=IN IP4 biloxi.example.com 1546 t=0 0 1547 a=group:BUNDLE foo bar 1548 m=audio 20000 RTP/AVP 0 1549 b=AS:200 1550 a=mid:foo 1551 a=rtcp-mux 1552 a=rtpmap:0 PCMU/8000 1553 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1554 m=video 20000 RTP/AVP 32 1555 b=AS:1000 1556 a=mid:bar 1557 a=rtcp-mux 1558 a=rtpmap:32 MPV/90000 1559 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1561 17.2. Example: BUNDLE Extension Rejected 1563 The example below shows: 1565 o An offer, in which the offerer associates a unique address with 1566 each bundled "m=" line within the BUNDLE group. 1568 o An answer, in which the answerer rejects the offered BUNDLE group, 1569 and associates a unique address with each "m=" line (following 1570 normal RFC 3264 procedures). 1572 SDP Offer (1) 1574 v=0 1575 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1576 s= 1577 c=IN IP4 atlanta.example.com 1578 t=0 0 1579 a=group:BUNDLE foo bar 1580 m=audio 10000 RTP/AVP 0 8 97 1581 b=AS:200 1582 a=mid:foo 1583 a=rtcp-mux 1584 a=rtpmap:0 PCMU/8000 1585 a=rtpmap:8 PCMA/8000 1586 a=rtpmap:97 iLBC/8000 1587 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1588 m=video 10002 RTP/AVP 31 32 1589 b=AS:1000 1590 a=mid:bar 1591 a=rtcp-mux 1592 a=rtpmap:31 H261/90000 1593 a=rtpmap:32 MPV/90000 1594 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1596 SDP Answer (2) 1598 v=0 1599 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1600 s= 1601 c=IN IP4 biloxi.example.com 1602 t=0 0 1603 m=audio 20000 RTP/AVP 0 1604 b=AS:200 1605 a=rtcp-mux 1606 a=rtpmap:0 PCMU/8000 1607 m=video 30000 RTP/AVP 32 1608 b=AS:1000 1609 a=rtcp-mux 1610 a=rtpmap:32 MPV/90000 1612 17.3. Example: Offerer Adds A Media Description To A BUNDLE Group 1614 The example below shows: 1616 o A subsequent offer (the BUNDLE group has been created as part of a 1617 previous offer/answer exchange), in which the offerer adds a new 1618 "m=" line, represented by the "zen" identification-tag, to a 1619 previously negotiated BUNDLE group, associates a unique address 1620 with the added "m=" line, and associates the previously selected 1621 offerer BUNDLE address with each of the other bundled "m=" lines 1622 within the BUNDLE group. 1624 o An answer, in which the answerer associates the answerer BUNDLE 1625 address with each bundled "m=" line (including the newly added 1626 "m=" line) within the BUNDLE group. 1628 SDP Offer (1) 1630 v=0 1631 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1632 s= 1633 c=IN IP4 atlanta.example.com 1634 t=0 0 1635 a=group:BUNDLE foo bar zen 1636 m=audio 10000 RTP/AVP 0 8 97 1637 b=AS:200 1638 a=mid:foo 1639 a=rtcp-mux 1640 a=rtpmap:0 PCMU/8000 1641 a=rtpmap:8 PCMA/8000 1642 a=rtpmap:97 iLBC/8000 1643 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1644 m=video 10000 RTP/AVP 31 32 1645 b=AS:1000 1646 a=mid:bar 1647 a=rtcp-mux 1648 a=rtpmap:31 H261/90000 1649 a=rtpmap:32 MPV/90000 1650 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1651 m=video 20000 RTP/AVP 66 1652 b=AS:1000 1653 a=mid:zen 1654 a=rtcp-mux 1655 a=rtpmap:66 H261/90000 1656 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1658 SDP Answer (2) 1660 v=0 1661 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1662 s= 1663 c=IN IP4 biloxi.example.com 1664 t=0 0 1665 a=group:BUNDLE foo bar zen 1666 m=audio 20000 RTP/AVP 0 1667 b=AS:200 1668 a=mid:foo 1669 a=rtcp-mux 1670 a=rtpmap:0 PCMU/8000 1671 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1672 m=video 20000 RTP/AVP 32 1673 b=AS:1000 1674 a=mid:bar 1675 a=rtcp-mux 1676 a=rtpmap:32 MPV/90000 1677 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1678 m=video 20000 RTP/AVP 66 1679 b=AS:1000 1680 a=mid:zen 1681 a=rtcp-mux 1682 a=rtpmap:66 H261/90000 1683 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1685 17.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 1687 The example below shows: 1689 o A subsequent offer (the BUNDLE group has been created as part of a 1690 previous offer/answer transaction), in which the offerer moves a 1691 bundled "m=" line out of a BUNDLE group, associates a unique 1692 address with the moved "m=" line, and associates the offerer 1693 BUNDLE address with each other bundled "m=" line within the BUNDLE 1694 group. 1696 o An answer, in which the answerer moves the "m=" line out of the 1697 BUNDLE group, associates a unique address with the moved "m=" 1698 line, and associates the answerer BUNDLE address with each of the 1699 remaining bundled "m=" line within the BUNDLE group. 1701 SDP Offer (1) 1703 v=0 1704 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1705 s= 1706 c=IN IP4 atlanta.example.com 1707 t=0 0 1708 a=group:BUNDLE foo bar 1709 m=audio 10000 RTP/AVP 0 8 97 1710 b=AS:200 1711 a=mid:foo 1712 a=rtcp-mux 1713 a=rtpmap:0 PCMU/8000 1714 a=rtpmap:8 PCMA/8000 1715 a=rtpmap:97 iLBC/8000 1716 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1717 m=video 10000 RTP/AVP 31 32 1718 b=AS:1000 1719 a=mid:bar 1720 a=rtcp-mux 1721 a=rtpmap:31 H261/90000 1722 a=rtpmap:32 MPV/90000 1723 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1724 m=video 50000 RTP/AVP 66 1725 b=AS:1000 1726 a=mid:zen 1727 a=rtcp-mux 1728 a=rtpmap:66 H261/90000 1730 SDP Answer (2) 1732 v=0 1733 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1734 s= 1735 c=IN IP4 biloxi.example.com 1736 t=0 0 1737 a=group:BUNDLE foo bar 1738 m=audio 20000 RTP/AVP 0 1739 b=AS:200 1740 a=mid:foo 1741 a=rtcp-mux 1742 a=rtpmap:0 PCMU/8000 1743 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1744 m=video 20000 RTP/AVP 32 1745 b=AS:1000 1746 a=mid:bar 1747 a=rtcp-mux 1748 a=rtpmap:32 MPV/90000 1749 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1750 m=video 60000 RTP/AVP 66 1751 b=AS:1000 1752 a=mid:zen 1753 a=rtcp-mux 1754 a=rtpmap:66 H261/90000 1756 17.5. Example: Offerer Disables A Media Description Within A BUNDLE 1757 Group 1759 The example below shows: 1761 o A subsequent offer (the BUNDLE group has been created as part of a 1762 previous offer/answer transaction), in which the offerer disables 1763 a bundled "m=" line within a BUNDLE group, assigns a zero port 1764 number to the disabled "m=" line, and associates the offerer 1765 BUNDLE address with each of the other bundled "m=" lines within 1766 the BUNDLE group. 1768 o An answer, in which the answerer moves the disabled "m=" line out 1769 of the BUNDLE group, assigns a zero port value to the disabled 1770 "m=" line, and associates the answerer BUNDLE address with each of 1771 the remaining bundled "m=" line within the BUNDLE group. 1773 SDP Offer (1) 1775 v=0 1776 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1777 s= 1778 c=IN IP4 atlanta.example.com 1779 t=0 0 1780 a=group:BUNDLE foo bar 1781 m=audio 10000 RTP/AVP 0 8 97 1782 b=AS:200 1783 a=mid:foo 1784 a=rtcp-mux 1785 a=rtpmap:0 PCMU/8000 1786 a=rtpmap:8 PCMA/8000 1787 a=rtpmap:97 iLBC/8000 1788 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1789 m=video 10000 RTP/AVP 31 32 1790 b=AS:1000 1791 a=mid:bar 1792 a=rtcp-mux 1793 a=rtpmap:31 H261/90000 1794 a=rtpmap:32 MPV/90000 1795 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1796 m=video 0 RTP/AVP 66 1797 a=mid:zen 1798 a=rtpmap:66 H261/90000 1800 SDP Answer (2) 1802 v=0 1803 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1804 s= 1805 c=IN IP4 biloxi.example.com 1806 t=0 0 1807 a=group:BUNDLE foo bar 1808 m=audio 20000 RTP/AVP 0 1809 b=AS:200 1810 a=mid:foo 1811 a=rtcp-mux 1812 a=rtpmap:0 PCMU/8000 1813 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1814 m=video 20000 RTP/AVP 32 1815 b=AS:1000 1816 a=mid:bar 1817 a=rtcp-mux 1818 a=rtpmap:32 MPV/90000 1819 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1820 m=video 0 RTP/AVP 66 1821 a=mid:zen 1822 a=rtpmap:66 H261/90000 1824 18. Acknowledgements 1826 The usage of the SDP grouping extension for negotiating bundled media 1827 is based on a similar alternatives proposed by Harald Alvestrand and 1828 Cullen Jennings. The BUNDLE extension described in this document is 1829 based on the different alternative proposals, and text (e.g., SDP 1830 examples) have been borrowed (and, in some cases, modified) from 1831 those alternative proposals. 1833 The SDP examples are also modified versions from the ones in the 1834 Alvestrand proposal. 1836 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 1837 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 1838 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju and 1839 Justin Uberti for reading the text, and providing useful feedback. 1841 Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for 1842 providing help and text on the RTP/RTCP procedures. 1844 Thanks to Spotify for providing music for the countless hours of 1845 document editing. 1847 19. Change Log 1849 [RFC EDITOR NOTE: Please remove this section when publishing] 1851 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34 1853 o RTP streams, instead of RTP packets, are associated with m- lines. 1855 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 1857 o Editorial changes based on comments from Eric Rescorla and Cullen 1858 Jennings: 1860 o - Changes regarding usage of RTP/RTCP multiplexing attributes. 1862 o - Additional text regarding associating RTP/RTCP packets with SDP 1863 m- lines. 1865 o - Reference correction. 1867 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32 1869 o Editorial changes based on comments from Eric Rescorla and Cullen 1870 Jennings: 1872 o - Justification for mechanism added to Introduction. 1874 o - Clarify that the order of m- lines in the group:BUNDLE attribute 1875 does not have to be the same as the order in which the m- lines 1876 are listed in the SDP. 1878 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31 1880 o Editorial changes based on GitHub Pull requests by Martin Thomson: 1882 o - https://github.com/cdh4u/draft-sdp-bundle/pull/2 1884 o - https://github.com/cdh4u/draft-sdp-bundle/pull/1 1886 o Editorial change based on comment from Diederick Huijbers (9th 1887 July 2016). 1889 o Changes based on comments from Flemming Andreasen (21st June 1890 2016): 1892 o - Mux category for SDP bundle-only attribute added. 1894 o - Mux category considerations editorial clarification. 1896 o - Editorial changes. 1898 o RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext. 1900 o Note whether Design Considerations appendix is to be kept removed: 1902 o - Appendix is kept within document. 1904 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30 1906 o Indicating in the Abstract and Introduction that the document 1907 updates RFC 3264. 1909 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29 1911 o Change based on WGLC comment from Colin Perkins. 1913 o - Clarify that SSRC can be reused by another source after a delay 1914 of 5 RTCP reporting intervals. 1916 o Change based on WGLC comment from Alissa Cooper. 1918 o - IANA registry name fix. 1920 o - Additional IANA registration information added. 1922 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28 1924 o - Alignment with exclusive mux procedures. 1926 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 1928 o - Yet another terminology change. 1930 o - Mux category considerations added. 1932 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 1934 o - ICE considerations modified: ICE-related SDP attributes only 1935 added to the bundled m- line representing the selected BUNDLE 1936 address. 1938 o - Reference to draft-ietf-mmusic-ice-sip-sdp added. 1940 o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- 1941 rfc5245bis. 1943 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 1944 o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux 1945 considerations. 1947 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 1949 o - Reference and procedures associated with exclusive RTP/RTCP mux 1950 added 1952 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 1954 o - RTCP-MUX mandatory for bundled RTP m- lines 1956 o - Editorial fixes based on comments from Flemming Andreasen 1958 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 1960 o - Correction of Ari's family name 1962 o - Editorial fixes based on comments from Thomas Stach 1964 o - RTP/RTCP correction based on comment from Magnus Westerlund 1966 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 1967 msg14861.html 1969 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 1971 o - Correct based on comment from Paul Kyzivat 1973 o -- 'received packets' replaced with 'received data' 1975 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 1977 o - Clarification based on comment from James Guballa 1979 o - Clarification based on comment from Flemming Andreasen 1981 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 1983 o - DTLS Considerations section added. 1985 o - BUNDLE semantics added to the IANA Considerations 1987 o - Changes based on WGLC comments from Adam Roach 1989 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 1990 msg14673.html 1992 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 1994 o - Changes based on agreements at IETF#92 1996 o -- BAS Offer removed, based on agreement at IETF#92. 1998 o -- Procedures regarding usage of SDP "b=" line is replaced with a 1999 reference to to draft-ietf-mmusic-sdp-mux-attributes. 2001 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 2003 o - Editorial changes based on comments from Magnus Westerlund. 2005 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 2007 o - Modification of RTP/RTCP multiplexing section, based on comments 2008 from Magnus Westerlund. 2010 o - Reference updates. 2012 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 2014 o - Editorial fix. 2016 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 2018 o - Editorial changes. 2020 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 2022 o Changes to allow a new suggested offerer BUNDLE address to be 2023 assigned to each bundled m- line. 2025 o Changes based on WGLC comments from Paul Kyzivat 2027 o - Editorial fixes 2029 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 2031 o Usage of SDP 'extmap' attribute added 2033 o SDP 'bundle-only' attribute scoped with "m=" lines with a zero 2034 port value 2036 o Changes based on WGLC comments from Thomas Stach 2038 o - ICE candidates not assigned to bundle-only m- lines with a zero 2039 port value 2041 o - Editorial changes 2043 o Changes based on WGLC comments from Colin Perkins 2045 o - Editorial changes: 2047 o -- "RTP SDES item" -> "RTCP SDES item" 2049 o -- "RTP MID SDES item" -> "RTCP MID SDES item" 2051 o - Changes in section 10.1.1: 2053 o -- "SHOULD NOT" -> "MUST NOT" 2055 o -- Additional text added to the Note 2057 o - Change to section 13.2: 2059 o -- Clarify that mid value is not zero terminated 2061 o - Change to section 13.3: 2063 o -- Clarify that mid value is not zero terminated 2065 o -- Clarify padding 2067 o Changes based on WGLC comments from Paul Kyzivat 2069 o - Editorial changes: 2071 o Changes based on WGLC comments from Jonathan Lennox 2073 o - Editorial changes: 2075 o - Defintion of SDP bundle-only attribute alligned with structure 2076 in 4566bis draft 2078 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 2080 o Editorial corrections based on comments from Harald Alvestrand. 2082 o Editorial corrections based on comments from Cullen Jennings. 2084 o Reference update (RFC 7160). 2086 o Clarification about RTCP packet sending when RTP/RTCP multiplexing 2087 is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ 2088 msg13765.html). 2090 o Additional text added to the Security Considerations. 2092 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 2094 o SDP bundle-only attribute added to IANA Considerations. 2096 o SDES item and RTP header extension added to Abstract and 2097 Introduction. 2099 o Modification to text updating section 8.2 of RFC 3264. 2101 o Reference corrections. 2103 o Editorial corrections. 2105 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 2107 o Terminology change: "bundle-only attribute assigned to m= line" to 2108 "bundle-only attribute associated with m= line". 2110 o Editorial corrections. 2112 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 2114 o Editorial corrections. 2116 o - "of"->"if" (8.3.2.5). 2118 o - "optional"->"OPTIONAL" (9.1). 2120 o - Syntax/ABNF for 'bundle-only' attribute added. 2122 o - SDP Offer/Answer sections merged. 2124 o - 'Request new offerer BUNDLE address' section added 2126 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 2128 o OPEN ISSUE regarding Receiver-ID closed. 2130 o - RTP MID SDES Item. 2132 o - RTP MID Header Extension. 2134 o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers 2135 closed. 2137 o - Indicating that, when rtcp-mux is used, the answerer MUST NOT 2138 include an 'rtcp' attribute in the answer, based on the procedures 2139 in section 5.1.3 of RFC 5761. 2141 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 2143 o Draft title changed. 2145 o Added "SDP" to section names containing "Offer" or "Answer". 2147 o Editorial fixes based on comments from Paul Kyzivat 2148 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2149 msg13314.html). 2151 o Editorial fixed based on comments from Colin Perkins 2152 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2153 msg13318.html). 2155 o - Removed text about extending BUNDLE to allow multiple RTP 2156 sessions within a BUNDLE group. 2158 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 2160 o Major re-structure of SDP Offer/Answer sections, to align with RFC 2161 3264 structure. 2163 o Additional definitions added. 2165 o - Shared address. 2167 o - Bundled "m=" line. 2169 o - Bundle-only "m=" line. 2171 o - Offerer suggested BUNDLE mid. 2173 o - Answerer selected BUNDLE mid. 2175 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 2176 to multiple "m=" lines until it has received an SDP Answer 2177 indicating support of the BUNDLE extension. 2179 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 2180 Answerer supports the BUNDLE extension, assign a zero port value 2181 to a 'bundle-only' "m=" line. 2183 o SDP 'bundle-only' attribute section added. 2185 o Connection data nettype/addrtype restrictions added. 2187 o RFC 3264 update section added. 2189 o Indicating that a specific payload type value can be used in 2190 multiple "m=" lines, if the value represents the same codec 2191 configuration in each "m=" line. 2193 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 2195 o Updated Offerer procedures (http://www.ietf.org/mail- 2196 archive/web/mmusic/current/msg12293.html). 2198 o Updated Answerer procedures (http://www.ietf.org/mail- 2199 archive/web/mmusic/current/msg12333.html). 2201 o Usage of SDP 'bundle-only' attribute added. 2203 o Reference to Trickle ICE document added. 2205 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 2207 o Mechanism modified, to be based on usage of SDP Offers with both 2208 different and identical port number values, depending on whether 2209 it is known if the remote endpoint supports the extension. 2211 o Cullen Jennings added as co-author. 2213 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 2215 o No changes. New version due to expiration. 2217 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 2219 o No changes. New version due to expiration. 2221 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 2223 o Draft name changed. 2225 o Harald Alvestrand added as co-author. 2227 o "Multiplex" terminology changed to "bundle". 2229 o Added text about single versus multiple RTP Sessions. 2231 o Added reference to RFC 3550. 2233 20. References 2235 20.1. Normative References 2237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2238 Requirement Levels", BCP 14, RFC 2119, 2239 DOI 10.17487/RFC2119, March 1997, 2240 . 2242 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2243 with Session Description Protocol (SDP)", RFC 3264, 2244 DOI 10.17487/RFC3264, June 2002, 2245 . 2247 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2248 Jacobson, "RTP: A Transport Protocol for Real-Time 2249 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2250 July 2003, . 2252 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2253 in Session Description Protocol (SDP)", RFC 3605, 2254 DOI 10.17487/RFC3605, October 2003, 2255 . 2257 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2258 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2259 July 2006, . 2261 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2262 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2263 . 2265 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2266 (ICE): A Protocol for Network Address Translator (NAT) 2267 Traversal for Offer/Answer Protocols", RFC 5245, 2268 DOI 10.17487/RFC5245, April 2010, 2269 . 2271 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 2272 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2273 2008, . 2275 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2276 Control Packets on a Single Port", RFC 5761, 2277 DOI 10.17487/RFC5761, April 2010, 2278 . 2280 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2281 Security (DTLS) Extension to Establish Keys for the Secure 2282 Real-time Transport Protocol (SRTP)", RFC 5764, 2283 DOI 10.17487/RFC5764, May 2010, 2284 . 2286 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2287 Protocol (SDP) Grouping Framework", RFC 5888, 2288 DOI 10.17487/RFC5888, June 2010, 2289 . 2291 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2292 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2293 January 2012, . 2295 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 2296 Header Extension for the RTP Control Protocol (RTCP) 2297 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 2298 August 2016, . 2300 [I-D.ietf-ice-rfc5245bis] 2301 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2302 Connectivity Establishment (ICE): A Protocol for Network 2303 Address Translator (NAT) Traversal", draft-ietf-ice- 2304 rfc5245bis-04 (work in progress), June 2016. 2306 [I-D.ietf-mmusic-sdp-mux-attributes] 2307 Nandakumar, S., "A Framework for SDP Attributes when 2308 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-14 2309 (work in progress), September 2016. 2311 [I-D.ietf-mmusic-mux-exclusive] 2312 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 2313 Multiplexing using SDP", draft-ietf-mmusic-mux- 2314 exclusive-10 (work in progress), August 2016. 2316 [I-D.ietf-mmusic-ice-sip-sdp] 2317 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using 2318 Interactive Connectivity Establishment (ICE) with Session 2319 Description Protocol (SDP) offer/answer and Session 2320 Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip- 2321 sdp-10 (work in progress), July 2016. 2323 20.2. Informative References 2325 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2326 A., Peterson, J., Sparks, R., Handley, M., and E. 2327 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2328 DOI 10.17487/RFC3261, June 2002, 2329 . 2331 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 2332 Description Protocol (SDP) Security Descriptions for Media 2333 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 2334 . 2336 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2337 Media Attributes in the Session Description Protocol 2338 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2339 . 2341 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2342 Clock Rates in an RTP Session", RFC 7160, 2343 DOI 10.17487/RFC7160, April 2014, 2344 . 2346 [I-D.ietf-mmusic-trickle-ice] 2347 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 2348 Incremental Provisioning of Candidates for the Interactive 2349 Connectivity Establishment (ICE) Protocol", draft-ietf- 2350 mmusic-trickle-ice-02 (work in progress), January 2015. 2352 Appendix A. Design Considerations 2354 One of the main issues regarding the BUNDLE grouping extensions has 2355 been whether, in SDP Offers and SDP Answers, the same port value 2356 should be inserted in "m=" lines associated with a BUNDLE group, as 2357 the purpose of the extension is to negotiate the usage of a single 2358 address:port combination for media specified by the "m=" lines. 2359 Issues with both approaches, discussed in the Appendix have been 2360 raised. The outcome was to specify a mechanism which uses SDP Offers 2361 with both different and identical port values. 2363 Below are the primary issues that have been considered when defining 2364 the "BUNDLE" grouping extension: 2366 o 1) Interoperability with existing UAs. 2368 o 2) Interoperability with intermediary B2BUA- and proxy entities. 2370 o 3) Time to gather, and the number of, ICE candidates. 2372 o 4) Different error scenarios, and when they occur. 2374 o 5) SDP Offer/Answer impacts, including usage of port number value 2375 zero. 2377 A.1. UA Interoperability 2379 Consider the following SDP Offer/Answer exchange, where Alice sends 2380 an SDP Offer to Bob: 2382 SDP Offer 2384 v=0 2385 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2386 s= 2387 c=IN IP4 atlanta.example.com 2388 t=0 0 2389 m=audio 10000 RTP/AVP 97 2390 a=rtpmap:97 iLBC/8000 2391 m=video 10002 RTP/AVP 97 2392 a=rtpmap:97 H261/90000 2394 SDP Answer 2396 v=0 2397 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2398 s= 2399 c=IN IP4 biloxi.example.com 2400 t=0 0 2401 m=audio 20000 RTP/AVP 97 2402 a=rtpmap:97 iLBC/8000 2403 m=video 20002 RTP/AVP 97 2404 a=rtpmap:97 H261/90000 2406 RFC 4961 specifies a way of doing symmetric RTP but that is an a 2407 later invention to RTP and Bob can not assume that Alice supports RFC 2408 4961. This means that Alice may be sending RTP from a different port 2409 than 10000 or 10002 - some implementation simply send the RTP from an 2410 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2411 way that Bob knows if it should be passed to the video or audio codec 2412 is by looking at the port it was received on. This lead some SDP 2413 implementations to use the fact that each "m=" line had a different 2414 port number to use that port number as an index to find the correct m 2415 line in the SDP. As a result, some implementations that do support 2416 symmetric RTP and ICE still use a SDP data structure where SDP with 2417 "m=" lines with the same port such as: 2419 SDP Offer 2421 v=0 2422 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2423 s= 2424 c=IN IP4 atlanta.example.com 2425 t=0 0 2426 m=audio 10000 RTP/AVP 97 2427 a=rtpmap:97 iLBC/8000 2428 m=video 10000 RTP/AVP 98 2429 a=rtpmap:98 H261/90000 2431 will result in the second "m=" line being considered an SDP error 2432 because it has the same port as the first line. 2434 A.2. Usage of port number value zero 2436 In an SDP Offer or SDP Answer, the media specified by an "m=" line 2437 can be disabled/rejected by setting the port number value to zero. 2438 This is different from e.g., using the SDP direction attributes, 2439 where RTCP traffic will continue even if the SDP "inactive" attribute 2440 is indicated for the associated "m=" line. 2442 If each "m=" line associated with a BUNDLE group would contain 2443 different port values, and one of those port values would be used for 2444 a BUNDLE address associated with the BUNDLE group, problems would 2445 occur if an endpoint wants to disable/reject the "m=" line associated 2446 with that port, by setting the port value to zero. After that, no 2447 "m=" line would contain the port value which is used for the BUNDLE 2448 address. In addition, it is unclear what would happen to the ICE 2449 candidates associated with the "m=" line, as they are also used for 2450 the BUNDLE address. 2452 A.3. B2BUA And Proxy Interoperability 2454 Some back to back user agents may be configured in a mode where if 2455 the incoming call leg contains an SDP attribute the B2BUA does not 2456 understand, the B2BUA still generates that SDP attribute in the Offer 2457 for the outgoing call leg. Consider a B2BUA that did not understand 2458 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 2459 Further assume that the B2BUA was configured to tear down any call 2460 where it did not see any RTCP for 5 minutes. In this case, if the 2461 B2BUA received an Offer like: 2463 SDP Offer 2465 v=0 2466 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2467 s= 2468 c=IN IP4 atlanta.example.com 2469 t=0 0 2470 m=audio 49170 RTP/AVP 0 2471 a=rtcp:53020 2473 It would be looking for RTCP on port 49172 but would not see any 2474 because the RTCP would be on port 53020 and after five minutes, it 2475 would tear down the call. Similarly, a B2BUA that did not understand 2476 BUNDLE yet put BUNDLE in it's offer may be looking for media on the 2477 wrong port and tear down the call. It is worth noting that a B2BUA 2478 that generated an Offer with capabilities it does not understand is 2479 not compliant with the specifications. 2481 A.3.1. Traffic Policing 2483 Sometimes intermediaries do not act as B2BUA, in the sense that they 2484 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2485 however, they may use SDP information (e.g., IP address and port) in 2486 order to control traffic gating functions, and to set traffic 2487 policing rules. There might be rules which will trigger a session to 2488 be terminated in case media is not sent or received on the ports 2489 retrieved from the SDP. This typically occurs once the session is 2490 already established and ongoing. 2492 A.3.2. Bandwidth Allocation 2494 Sometimes intermediaries do not act as B2BUA, in the sense that they 2495 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2496 however, they may use SDP information (e.g., codecs and media types) 2497 in order to control bandwidth allocation functions. The bandwidth 2498 allocation is done per "m=" line, which means that it might not be 2499 enough if media specified by all "m=" lines try to use that 2500 bandwidth. That may either simply lead to bad user experience, or to 2501 termination of the call. 2503 A.4. Candidate Gathering 2505 When using ICE, a candidate needs to be gathered for each port. This 2506 takes approximately 20 ms extra for each extra "m=" line due to the 2507 NAT pacing requirements. All of this gather can be overlapped with 2508 other things while for exampe a web-page is loading to minimize the 2509 impact. If the client only wants to generate TURN or STUN ICE 2510 candidates for one of the "m=" lines and then use trickle ICE 2511 [I-D.ietf-mmusic-trickle-ice] to get the non host ICE candidates for 2512 the rest of the "m=" lines, it MAY do that and will not need any 2513 additional gathering time. 2515 Some people have suggested a TURN extension to get a bunch of TURN 2516 allocations at once. This would only provide a single STUN result so 2517 in cases where the other end did not support BUNDLE, may cause more 2518 use of the TURN server but would be quick in the cases where both 2519 sides supported BUNDLE and would fall back to a successful call in 2520 the other cases. 2522 Authors' Addresses 2524 Christer Holmberg 2525 Ericsson 2526 Hirsalantie 11 2527 Jorvas 02420 2528 Finland 2530 Email: christer.holmberg@ericsson.com 2532 Harald Tveit Alvestrand 2533 Google 2534 Kungsbron 2 2535 Stockholm 11122 2536 Sweden 2538 Email: harald@alvestrand.no 2540 Cullen Jennings 2541 Cisco 2542 400 3rd Avenue SW, Suite 350 2543 Calgary, AB T2P 4H2 2544 Canada 2546 Email: fluffy@iii.ca