idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-31.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 (June 19, 2016) is 2862 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 1243 == Missing Reference: 'RFCXXXX' is mentioned on line 1419, 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-02 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-12 == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-mux-exclusive-07 == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-08 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: December 21, 2016 C. Jennings 7 Cisco 8 June 19, 2016 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-31.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 rejcted. 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 December 21, 2016. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 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. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 90 7.2. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9 91 7.3. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9 92 7.4. Attributes (a=) . . . . . . . . . . . . . . . . . . . . . 9 93 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9 94 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 95 8.2. Mux Category Considerations . . . . . . . . . . . . . . . 10 96 8.3. Generating the Initial SDP Offer . . . . . . . . . . . . 10 97 8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 11 98 8.3.2. Suggesting the offerer BUNDLE address . . . . . . . . 11 99 8.4. Generating the SDP Answer . . . . . . . . . . . . . . . . 11 100 8.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 12 101 8.4.2. Answerer Selection of Offerer Bundle Address . . . . 13 102 8.4.3. Answerer Selection of Answerer BUNDLE Address . . . . 13 103 8.4.4. Moving A Media Description Out Of A BUNDLE Group . . 14 104 8.4.5. Rejecting A Media Description In A BUNDLE Group . . . 14 105 8.5. Offerer Processing of the SDP Answer . . . . . . . . . . 14 106 8.6. Modifying the Session . . . . . . . . . . . . . . . . . . 15 107 8.6.1. General . . . . . . . . . . . . . . . . . . . . . . . 15 108 8.6.2. Suggesting a new offerer BUNDLE address . . . . . . . 15 109 8.6.3. Adding a media description to a BUNDLE group . . . . 16 110 8.6.4. Moving A Media Description Out Of A BUNDLE Group . . 16 111 8.6.5. Disabling A Media Description In A BUNDLE Group . . . 17 112 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 17 113 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 114 9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 18 115 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 18 116 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 18 117 10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 18 118 10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 19 119 10.2. Associating RTP/RTCP Packets With Correct SDP Media 120 Description . . . . . . . . . . . . . . . . . . . . . . 19 121 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 20 122 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 20 123 10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20 124 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22 125 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 23 126 11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 23 127 11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23 128 11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 24 129 11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 24 130 11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 24 131 11.2.5. Modifying the Session . . . . . . . . . . . . . . . 24 132 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 25 133 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 25 134 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 25 135 13.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 26 136 13.3. New text replacing section 5.1 (2nd paragraph) of RFC 137 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 138 13.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 26 139 13.5. New text replacing section 8.2 (2nd paragraph) of RFC 140 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 141 13.6. Original text of section 8.4 (6th paragraph) of RFC 3264 27 142 13.7. New text replacing section 8.4 (6th paragraph) of RFC 143 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 145 14. RTP/RTCP extensions for identification-tag transport . . . . 27 146 14.1. General . . . . . . . . . . . . . . . . . . . . . . . . 27 147 14.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 28 148 14.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 29 149 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 150 15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 29 151 15.2. New RTP Header Extension URI . . . . . . . . . . . . . . 30 152 15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 30 153 15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 31 154 16. Security Considerations . . . . . . . . . . . . . . . . . . . 31 155 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32 156 17.1. Example: Bundle Address Selection . . . . . . . . . . . 32 157 17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 34 158 17.3. Example: Offerer Adds A Media Description To A BUNDLE 159 Group . . . . . . . . . . . . . . . . . . . . . . . . . 35 160 17.4. Example: Offerer Moves A Media Description Out Of A 161 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 37 162 17.5. Example: Offerer Disables A Media Description Within A 163 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 38 164 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 165 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 40 166 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 167 20.1. Normative References . . . . . . . . . . . . . . . . . . 47 168 20.2. Informative References . . . . . . . . . . . . . . . . . 49 169 Appendix A. Design Considerations . . . . . . . . . . . . . . . 50 170 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 50 171 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 50 172 A.3. Usage of port number value zero . . . . . . . . . . . . . 52 173 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 52 174 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 53 175 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 53 176 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 53 177 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 179 1. Introduction 181 This specification defines a way to use a single address:port 182 combination (BUNDLE address) for receiving media specified by 183 multiple SDP media descriptions ("m=" lines). 185 This specification defines a new SDP Grouping Framework [RFC5888] 186 extension called 'BUNDLE'. The extension can be used with the 187 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 188 to negotiate the usage of a BUNDLE group. Within the BUNDLE group, a 189 BUNDLE address is used for receiving media specified by multiple "m=" 190 lines. This is referred to as bundled media. 192 The offerer and answerer [RFC3264] use the BUNDLE extension to 193 negotiate the BUNDLE addresses, one for the offerer (offerer BUNDLE 194 address) and one for the answerer (answerer BUNDLE address), to be 195 used for receiving the bundled media specified by a BUNDLE group. 196 Once the offerer and the answerer have negotiated a BUNDLE group, 197 they associate their respective BUNDLE address with each "m=" line in 198 the BUNDLE group. The BUNDLE addresses are used to receive all media 199 specified by the BUNDLE group. 201 The use of a BUNDLE group and a BUNDLE address also allows the usage 202 of a single set of Interactive Connectivity Establishment (ICE) 203 [RFC5245] candidates for multiple "m=" lines. 205 This specification also defines a new SDP attribute, 'bundle-only', 206 which can be used to request that specific media is only used if kept 207 within a BUNDLE group. The specification also updates RFC 3264, to 208 allow usage of zero port values without meaning that media is 209 rejcted. 211 As defined in RFC 4566 [RFC4566], the semantics of assigning the same 212 port value to multiple "m=" lines are undefined, and there is no 213 grouping defined by such means. Instead, an explicit grouping 214 mechanism needs to be used to express the intended semantics. This 215 specification provides such an extension. 217 This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 218 [RFC3264]. The update allows an answerer to assign a non-zero port 219 value to an "m=" line in an SDP answer, even if the "m=" line in the 220 associated SDP offer contained a zero port value. 222 This specification also defines a new Real-time Transport Protocol 223 (RTP) [RFC3550] source description (SDES) item and a new RTP header 224 extension that can be used to carry a value that associates RTP/RTCP 225 packets with a specific media description. This can be used to 226 correlate a RTP packet with the correct media. 228 SDP bodies can contain multiple BUNDLE groups. A given BUNDLE 229 address MUST only be associated with a single BUNDLE group. The 230 procedures in this specification apply independently to a given 231 BUNDLE group. All RTP based media flows described by a single BUNDLE 232 group belong to a single RTP session [RFC3550]. 234 The BUNDLE extension is backward compatible. Endpoints that do not 235 support the extension are expected to generate offers and answers 236 without an SDP 'group:BUNDLE' attribute, and are expected to 237 associate a unique address with each "m=" line within an offer and 238 answer, according to the procedures in [RFC4566] and [RFC3264] 240 2. Terminology 242 "m=" line: SDP bodies contain one or more media descriptions. Each 243 media description is identified by an SDP "m=" line. 245 5-tuple: A collection of the following values: source address, source 246 port, destination address, destination port, and transport-layer 247 protocol. 249 Unique address: An IP address and port combination that is associated 250 with only one "m=" line in an offer or answer. 252 Shared address: An IP address and port combination that is associated 253 with multiple "m=" lines within an offer or answer. 255 Offerer BUNDLE-tag: The first identification-tag in a given SDP 256 'group:BUNDLE' attribute identification-tag list in an offer. 258 Answerer BUNDLE-tag: The first identification-tag in a given SDP 259 'group:BUNDLE' attribute identification-tag list in an answer. 261 Offerer BUNDLE address: Within a given BUNDLE group, an IP address 262 and port combination used by an offerer to receive all media 263 specified by each "m=" line within the BUNDLE group. 265 Answerer BUNDLE address: Within a given BUNDLE group, an IP address 266 and port combination used by an answerer to receive all media 267 specified by each "m=" line within the BUNDLE group. 269 BUNDLE group: A set of "m=" lines, created using an SDP Offer/Answer 270 exchange, which uses the same BUNDLE address for receiving media. 272 Bundled "m=" line: An "m=" line, whose identification-tag is placed 273 in an SDP 'group:BUNDLE' attribute identification-tag list in an 274 offer or answer. 276 Bundle-only "m=" line: A bundled "m=" line with an associated SDP 277 'bundle-only' attribute. 279 Bundled media: All media specified by a given BUNDLE group. 281 Initial offer: The first offer, within an SDP session (e.g. a SIP 282 dialog when the Session Initiation Protocol (SIP) [RFC3261] is used 283 to carry SDP), in which the offerer indicates that it wants to create 284 a given BUNDLE group. 286 Subsequent offer: An offer which contains a BUNDLE group that has 287 been created as part of a previous offer/answer exchange. 289 Identification-tag: A unique token value that is used to identify an 290 "m=" line. The SDP 'mid' attribute [RFC5888], associated with an 291 "m=" line, carries an unique identification-tag. The session-level 292 SDP 'group' attribute [RFC5888] carries a list of identification- 293 tags, identifying the "m=" lines associated with that particular 294 'group' attribute. 296 3. Conventions 298 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 299 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 300 document are to be interpreted as described in BCP 14, RFC 2119 301 [RFC2119]. 303 4. Applicability Statement 305 The mechanism in this specification only applies to the Session 306 Description Protocol (SDP) [RFC4566], when used together with the SDP 307 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 308 scope of this document, and is thus undefined. 310 5. SDP Grouping Framework BUNDLE Extension 312 This section defines a new SDP Grouping Framework extension 313 [RFC5888], 'BUNDLE'. The BUNDLE extension can be used with the SDP 314 Offer/Answer mechanism to negotiate the usage of a single 315 address:port combination (BUNDLE address) for receiving bundled 316 media. 318 A single address:port combination is also used for sending bundled 319 media. The address:port combination used for sending bundled media 320 MAY be the same as the BUNDLE address, used to receive bundled media, 321 depending on whether symmetric RTP [RFC4961] is used. 323 All media specified by a BUNDLE group share a single 5-tuple, i.e. in 324 addition to using a single address:port combination all bundled media 325 MUST be transported using the same transport-layer protocol (e.g. 326 UDP or TCP). 328 The BUNDLE extension is indicated using an SDP 'group' attribute with 329 a "BUNDLE" semantics value [RFC5888]. An identification-tag is 330 associated with each bundled "m=" line, and each identification-tag 331 is listed in the SDP 'group:BUNDLE' attribute identification-tag 332 list. Each "m=" line whose identification-tag is listed in the 333 identification-tag list is associated with a given BUNDLE group. 335 SDP bodies can contain multiple BUNDLE groups. Any given bundled 336 "m=" line MUST NOT be associated with more than one BUNDLE group. 338 Section 8 defines the detailed SDP Offer/Answer procedures for the 339 BUNDLE extension. 341 6. SDP 'bundle-only' Attribute 343 This section defines a new SDP media-level attribute [RFC4566], 344 'bundle-only'. 'bundle-only' is a property attribute [RFC4566], and 345 hence has no value. 347 Name: bundle-only 349 Value: N/A 351 Usage Level: media 353 Charset Dependent: no 355 Example: 357 a=bundle-only 359 In order to ensure that an answerer that does not support the BUNDLE 360 extension always rejects a bundled "m=" line, the offerer can assign 361 a zero port value to the "m=" line. According to [RFC4566] an 362 answerer will reject such "m=" line. By associating an SDP 'bundle- 363 only' attribute with such "m=" line, the offerer can request that the 364 answerer accepts the "m=" line if the answerer supports the Bundle 365 extension, and if the answerer keeps the "m=" line within the 366 associated BUNDLE group. 368 NOTE: Once the offerer BUNDLE address has been selected, the offerer 369 does not need to include the 'bundle-only' attribute in subsequent 370 offers. By associating the offerer BUNDLE address with an "m=" line 371 of a subsequent offer, the offerer will ensure that the answerer will 372 either keep the "m=" line within the BUNDLE group, or the answerer 373 will have to reject the "m=" line. 375 The usage of the 'bundle-only' attribute is only defined for a 376 bundled "m=" line with a zero port value, within an offer. Other 377 usage is unspecified. 379 Section 8 defines the detailed SDP Offer/Answer procedures for the 380 'bundle-only' attribute. 382 7. SDP Information Considerations 384 7.1. General 386 This section describes restrictions associated with the usage of SDP 387 parameters within a BUNDLE group. It also describes, when parameter 388 and attribute values have been associated with each bundled "m=" 389 line, how to calculate a value for the whole BUNDLE group. 391 7.2. Connection Data (c=) 393 The "c=" line nettype value [RFC4566] associated with a bundled "m=" 394 line MUST be 'IN'. 396 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" 397 line MUST be 'IP4' or 'IP6'. The same value MUST be associated with 398 each "m=" line. 400 NOTE: Extensions to this specification can specify usage of the 401 BUNDLE mechanism for other nettype and addrtype values than the ones 402 listed above. 404 7.3. Bandwidth (b=) 406 An offerer and answerer MUST use the rules and restrictions defined 407 in [I-D.ietf-mmusic-sdp-mux-attributes] for when associating the SDP 408 bandwidth (b=) line with bundled "m=" lines. 410 7.4. Attributes (a=) 412 An offerer and answerer MUST use the rules and restrictions defined 413 in [I-D.ietf-mmusic-sdp-mux-attributes] for when associating SDP 414 attributes with bundled "m=" lines. 416 8. SDP Offer/Answer Procedures 418 8.1. General 420 This section describes the SDP Offer/Answer [RFC3264] procedures for: 422 o Negotiating and creating of a BUNDLE group; and 424 o Selecting the BUNDLE addresses (offerer BUNDLE address and 425 answerer BUNDLE address); and 427 o Adding an "m=" line to a BUNDLE group; and 429 o Moving an "m=" line out of a BUNDLE group; and 430 o Disabling an "m=" line within a BUNDLE group. 432 The generic rules and procedures defined in [RFC3264] and [RFC5888] 433 also apply to the BUNDLE extension. For example, if an offer is 434 rejected by the answerer, the previously negotiated SDP parameters 435 and characteristics (including those associated with a BUNDLE group) 436 apply. Hence, if an offerer generates an offer in which the offerer 437 wants to create a BUNDLE group, and the answerer rejects the offer, 438 the BUNDLE group is not created. 440 The procedures in this section are independent of the media type or 441 "m=" line proto value represented by a bundled "m=" line. Section 10 442 defines additional considerations for RTP based media. Section 6 443 defines additional considerations for the usage of the SDP 'bundle- 444 only' attribute. Section 11 defines additional considerations for 445 the usage of Interactive Connectivity Establishment (ICE) 446 [I-D.ietf-ice-rfc5245bis] mechanism. 448 SDP offers and answers can contain multiple BUNDLE groups. The 449 procedures in this section apply independently to a given BUNDLE 450 group. 452 8.2. Mux Category Considerations 454 When an offerer associates a shared address with a bundled "m=" line, 455 the offerer shall associate IDENTICAL and TRANSPORT mux category SDP 456 attributes [I-D.ietf-mmusic-sdp-mux-attributes] with the "m=" line 457 only if the "m=" line is associated with the offerer BUNDLE-tag. 458 Otherwise the offerer MUST NOT associate such SDP attributes with the 459 "m=" line. 461 When an answerer associates a shared address with a bundled "m=" 462 line, the answerer shall associate IDENTICAL and TRANSPORT category 463 SDP attributes with the "m=" line only if the "m=" line is associated 464 with the answerer BUNDLE-tag. Otherwise the answerer MUST NOT 465 associate such SDP attributes with the "m=" line. 467 NOTE: As bundled "m=" lines associated with a shared address will 468 share the same IDENTICAL and TRANSPORT mux category SDP attributes, 469 and attribute values, there is no need to associate such SDP 470 attributes with each "m=" line. 472 8.3. Generating the Initial SDP Offer 473 8.3.1. General 475 When an offerer generates an initial offer, in order to create a 476 BUNDLE group, it MUST: 478 o Assign a unique address to each "m=" line within the offer, 479 following the procedures in [RFC3264], unless the media line is a 480 'bundle-only' "m=" line (see below); and 482 o Add an SDP 'group:BUNDLE' attribute to the offer; and 484 o Place the identification-tag of each bundled "m=" line in the SDP 485 'group:BUNDLE' attribute identification-tag list; and 487 o Indicate which unique address the offerer suggests as the offerer 488 BUNDLE address [Section 8.3.2]. 490 If the offerer wants to request that the answerer accepts a given 491 bundled "m=" line only if the answerer keeps the "m=" line within the 492 BUNDLE group, the offerer MUST: 494 o Associate an SDP 'bundle-only' attribute [Section 8.3.2] with the 495 "m=" line; and 497 o Assign a zero port value to the "m=" line. 499 NOTE: If the offerer assigns a zero port value to an "m=" line, but 500 does not also associate an SDP 'bundle-only' attribute with the "m=" 501 line, it is an indication that the offerer wants to disable the "m=" 502 line [Section 8.6.5]. 504 [Section 17.1] shows an example of an initial offer. 506 8.3.2. Suggesting the offerer BUNDLE address 508 In the offer, the address associated with the "m=" line associated 509 with the offerer BUNDLE-tag indicates the address that the offerer 510 suggests as the offerer BUNDLE address. 512 The "m=" line associated with the offerer BUNDLE-tag MUST NOT contain 513 a zero port value or an SDP 'bundle-only' attribute. 515 8.4. Generating the SDP Answer 516 8.4.1. General 518 When an answerer generates an answer that contains a BUNDLE group, 519 the following general SDP grouping framework restrictions, defined in 520 [RFC5888], also apply to the BUNDLE group: 522 o The answerer MUST NOT include a BUNDLE group in the answer, unless 523 the offerer requested the BUNDLE group to be created in the 524 corresponding offer; and 526 o The answerer MUST NOT include an "m=" line within a BUNDLE group, 527 unless the offerer requested the "m=" line to be within that 528 BUNDLE group in the corresponding offer. 530 If the answer contains a BUNDLE group, the answerer MUST: 532 o Select an Offerer BUNDLE Address [Section 8.4.2]; and 534 o Select an Answerer BUNDLE Address [Section 8.4.3]; 536 The answerer is allowed to select a new Answerer BUNDLE address each 537 time it generates an answer to an offer. 539 If the answerer does not want to keep an "m=" line within a BUNDLE 540 group, it MUST: 542 o Move the "m=" line out of the BUNDLE group [Section 8.4.4]; or 544 o Reject the "m=" line [Section 8.4.5]; 546 If the answerer keeps a bundle-only "m=" line within the BUNDLE 547 group, it follows the procedures (associates the answerer BUNDLE 548 address with the "m=" line etc) for any other "m=" line kept within 549 the BUNDLE group. 551 If the answerer does not want to keep a bundle-only "m=" line within 552 the BUNDLE group, it MUST reject the "m=" line [Section 8.4.5]. 554 The answerer MUST NOT associate an SDP 'bundle-only' attribute with 555 any "m=" line in an answer. 557 NOTE: If a bundled "m=" line in an offer contains a zero port value, 558 but the "m=" line does not contain an SDP 'bundle-only' attribute, it 559 is an indication that the offerer wants to disable the "m=" line 560 [Section 8.6.5]. 562 8.4.2. Answerer Selection of Offerer Bundle Address 564 In an offer, the address (unique or shared) associated with the 565 bundled "m=" line associated with the offerer BUNDLE-tag indicates 566 the address that the offerer suggests as the offerer BUNDLE address 567 [Section 8.3.2]. The answerer MUST check whether that "m=" line 568 fulfils the following criteria: 570 o The answerer will not move the "m=" line out of the BUNDLE group 571 [Section 8.4.4]; and 573 o The answerer will not reject the "m=" line [Section 8.4.5]; and 575 o The "m=" line does not contain a zero port value. 577 If all of the criteria above are fulfilled, the answerer MUST select 578 the address associated with the "m=" line as the offerer BUNDLE 579 address. In the answer, the answerer BUNDLE-tag represents the "m=" 580 line, and the address associated with the "m=" line in the offer 581 becomes the offerer BUNDLE address. 583 If one or more of the criteria are not fulfilled, the answerer MUST 584 select the next identification-tag in the identification-tag list, 585 and perform the same criteria check for the "m=" line associated with 586 that identification-tag. If there are no more identification-tags in 587 the identification-tag list, the answerer MUST NOT create the BUNDLE 588 group. In addition, unless the answerer rejects the whole offer, the 589 answerer MUST apply the answerer procedures for moving an "m=" line 590 out of a BUNDLE group [Section 8.4.4] to each bundled "m=" line in 591 the offer when creating the answer. 593 [Section 17.1] shows an example of an offerer BUNDLE address 594 selection. 596 8.4.3. Answerer Selection of Answerer BUNDLE Address 598 When the answerer selects a BUNDLE address for itself, referred to as 599 the answerer BUNDLE address, it MUST associate that address with each 600 bundled "m=" line within the created BUNDLE group in the answer. 602 The answerer MUST NOT associate the answerer BUNDLE address with an 603 "m=" line that is not within the BUNDLE group, or to an "m=" line 604 that is within another BUNDLE group. 606 [Section 17.1] shows an example of an answerer BUNDLE address 607 selection. 609 8.4.4. Moving A Media Description Out Of A BUNDLE Group 611 When an answerer wants to move an "m=" line out of a BUNDLE group, it 612 MUST first check the following criteria: 614 o In the corresponding offer, the "m=" line is associated with a 615 shared address (e.g. a previously selected offerer BUNDLE 616 address); or 618 o In the corresponding offer, if an SDP 'bundle-only' attribute is 619 associated with the "m=" line, and if the "m=" line contains a 620 zero port value. 622 If either criteria above is fulfilled, the answerer MUST reject the 623 "m=" line [Section 8.4.5]. 625 Otherwise, if in the corresponding offer the "m=" line is associated 626 with a unique address, the answerer MUST associate a unique address 627 with the "m=" line in the answer (the answerer does not reject the 628 "m=" line). 630 In addition, in either case above, the answerer MUST NOT place the 631 identification-tag, associated with the moved "m=" line, in the SDP 632 'group' attribute identification-tag list associated with the BUNDLE 633 group. 635 8.4.5. Rejecting A Media Description In A BUNDLE Group 637 When an answerer rejects an "m=" line, it MUST associate an address 638 with a zero port value with the "m=" line in the answer, according to 639 the procedures in [RFC4566]. 641 In addition, the answerer MUST NOT place the identification-tag, 642 associated with the rejected "m=" line, in the SDP 'group' attribute 643 identification-tag list associated with the BUNDLE group. 645 8.5. Offerer Processing of the SDP Answer 647 When an offerer receives an answer, if the answer contains a BUNDLE 648 group, the offerer MUST check that any bundled "m=" line in the 649 answer was indicated as bundled in the corresponding offer. If there 650 is no mismatch, the offerer MUST use the offerer BUNDLE address, 651 selected by the answerer [Section 8.4.2], as the address for each 652 bundled "m=" line. 654 NOTE: As the answerer might reject one or more bundled "m=" lines, or 655 move a bundled "m=" line out of a BUNDLE group, each bundled "m=" 656 line in the offer might not be indicated as bundled in the answer. 658 If the answer does not contain a BUNDLE group, the offerer MUST 659 process the answer as a normal answer. 661 8.6. Modifying the Session 663 8.6.1. General 665 When an offerer generates a subsequent offer, it MUST associate the 666 previously selected offerer BUNDLE address [Section 8.4.2] with each 667 bundled "m=" line (including any bundle-only "m=" line), except if: 669 o The offerer suggests a new offerer BUNDLE address [Section 8.6.2]; 670 or 672 o The offerer wants to add a bundled "m=" line to the BUNDLE group 673 [Section 8.6.3]; or 675 o The offerer wants to move a bundled "m=" line out of the BUNDLE 676 group [Section 8.6.4]; or 678 o The offerer wants to disable the bundled "m=" line 679 [Section 8.6.5]. 681 In addition, the offerer MUST select an offerer BUNDLE-tag 682 [Section 8.3.2] associated with the previously selected offerer 683 BUNDLE address, unless the offerer suggests a new offerer BUNDLE 684 address. 686 8.6.2. Suggesting a new offerer BUNDLE address 688 When an offerer generates an offer, in which it suggests a new 689 offerer BUNDLE address [Section 8.3.2], the offerer MUST: 691 o Assign the address (shared address) to each "m=" line within the 692 BUNDLE group; or 694 o Assign the address (unique address) to one bundled "m=" line. 696 In addition, the offerer MUST indicate that the address is the new 697 suggested offerer BUNDLE address [Section 8.3.2]. 699 NOTE: Unless the offerer associates the new suggested offerer BUNDLE 700 address with each bundled "m=" line, it can associate unique 701 addresses with any number of bundled "m=" lines (and the previously 702 selected offerer BUNDLE address to any remaining bundled "m=" line) 703 if it wants to suggest multiple alternatives for the new offerer 704 BUNDLE address. 706 8.6.3. Adding a media description to a BUNDLE group 708 When an offerer generates an offer, in which it wants to add a 709 bundled "m=" line to a BUNDLE group, the offerer MUST: 711 o Assign a unique address to the added "m=" line; or 713 o Assign the previously selected offerer BUNDLE address to the added 714 "m=" line; or 716 o If the offerer associates a new (shared address) suggested offerer 717 BUNDLE address with each bundled "m=" line [Section 8.6.2], also 718 associate that address with the added "m=" line. 720 In addition, the offerer MUST extend the SDP 'group:BUNDLE' attribute 721 identification-tag list with the BUNDLE group [Section 8.3.2] by 722 adding the identification-tag associated with the added "m=" line to 723 the list. 725 NOTE: Assigning a unique address to the "m=" line allows the answerer 726 to move the "m=" line out of the BUNDLE group [Section 8.4.4], 727 without having to reject the "m=" line. 729 If the offerer associates a unique address with the added "m=" line, 730 and if the offerer suggests that address as the new offerer BUNDLE 731 address [Section 8.6.2], the offerer BUNDLE-tag MUST represent the 732 added "m=" line [Section 8.3.2]. 734 If the offerer associates a new suggested offerer BUNDLE address with 735 each bundled "m=" line [Section 8.6.2], including the added "m=" 736 line, the offerer BUNDLE-tag MAY represent the added "m=" line 737 [Section 8.3.2]. 739 [Section 17.3] shows an example where an offerer sends an offer in 740 order to add a bundled "m=" line to a BUNDLE group. 742 8.6.4. Moving A Media Description Out Of A BUNDLE Group 744 When an offerer generates an offer, in which it wants to move a 745 bundled "m=" line out of a BUNDLE group it was added to in a previous 746 offer/answer transaction, the offerer: 748 o MUST associate a unique address with the "m=" line; and 750 o MUST NOT place the identification-tag associated with the "m=" 751 line in the SDP 'group:BUNDLE' attribute identification-tag list 752 associated with the BUNDLE group. 754 NOTE: If the removed "m=" line is associated with the previously 755 selected BUNDLE-tag, the offerer needs to suggest a new BUNDLE-tag 756 [Section 8.3.2]. 758 NOTE: If an "m=" line, when being moved out of a BUNDLE group, is 759 added to another BUNDLE group, the offerer applies the procedures in 760 [Section 8.6.3] to the "m=" line. 762 [Section 17.4] shows an example of an offer for moving an "m=" line 763 out of a BUNDLE group. 765 8.6.5. Disabling A Media Description In A BUNDLE Group 767 When an offerer generates an offer, in which it wants to disable a 768 bundled "m=" line (added to the BUNDLE group in a previous offer/ 769 answer transaction), the offerer: 771 o MUST associate an address with a zero port value with the "m=" 772 line, following the procedures in [RFC4566]; and 774 o MUST NOT place the identification-tag associated with the "m=" 775 line in the SDP 'group:BUNDLE' attribute identification-tag list 776 associated with the BUNDLE group. 778 [Section 17.5] shows an example of an offer for disabling an "m=" 779 line within a BUNDLE group. 781 9. Protocol Identification 783 9.1. General 785 Each "m=" line within a BUNDLE group MUST use the same transport- 786 layer protocol. If bundled "m=" lines use different protocols on top 787 of the transport-layer protocol, there MUST exist a publicly 788 available specification which describes a mechanism, for this 789 particular protocol combination, how to associate received data with 790 the correct protocol. 792 In addition, if received data can be associated with more than one 793 bundled "m=" line, there MUST exist a publicly available 794 specification which describes a mechanism for associating the 795 received data with the correct "m=" line. 797 This document describes a mechanism to identify the protocol of 798 received data among the STUN, DTLS and SRTP protocols (in any 799 combination), when UDP is used as transport-layer protocol, but does 800 not describe how to identify different protocols transported on DTLS. 801 While the mechanism is generally applicable to other protocols and 802 transport-layers protocols, any such use requires further 803 specification around how to multiplex multiple protocols on a given 804 transport-layer protocols, and how to associate received data with 805 the correct protocols. 807 9.2. STUN, DTLS, SRTP 809 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 810 protocol of a received packet among the STUN, Datagram Transport 811 Layer Security (DTLS) and SRTP protocols (in any combination). If an 812 offer or answer includes bundled "m=" lines that represent these 813 protocols, the offerer or answerer MUST support the mechanism 814 described in [RFC5764], and no explicit negotiation is required in 815 order to indicate support and usage of the mechanism. 817 [RFC5764] does not describe how to identify different protocols 818 transported on DTLS, only how to identify the DTLS protocol itself. 819 If multiple protocols are transported on DTLS, there MUST exist a 820 specification describing a mechanism for identifying each individual 821 protocol. In addition, if a received DTLS packet can be associated 822 with more than one "m=" line, there MUST exist a specification which 823 describes a mechanism for associating the received DTLS packet with 824 the correct "m=" line. 826 [Section 10.2] describes how to associate a received (S)RTP packet 827 with the correct "m=" line. 829 10. RTP Considerations 831 10.1. Single RTP Session 833 10.1.1. General 835 All RTP-based media within a single BUNDLE group belong to a single 836 RTP session [RFC3550]. Disjoint BUNDLE groups will form multiple RTP 837 sessions, one per BUNDLE group. 839 Since a single RTP session is used for each bundle group, all "m=" 840 lines representing RTP-based media in a bundle group will share a 841 single SSRC numbering space [RFC3550]. 843 The following rules and restrictions apply for a single RTP session: 845 o A specific payload type value can be used in multiple bundled "m=" 846 lines if each codec associated with the payload type number shares 847 an identical codec configuration [Section 10.1.2]. 849 o The proto value in each bundled RTP-based "m=" line MUST be 850 identical (e.g. RTP/AVPF). 852 o The RTP MID header extension MUST be enabled, by associating an 853 SDP 'extmap' attribute [RFC5285], with a 'urn:ietf:params:rtp- 854 hdrext:sdes:mid' URI value, with each bundled RTP-based "m=" line 855 in every offer and answer. 857 o A given SSRC MUST NOT transmit RTP packets using payload types 858 that originate from different bundled "m=" lines. 860 NOTE: The last bullet above is to avoid sending multiple media types 861 from the same SSRC. If transmission of multiple media types are done 862 with time overlap, RTP and RTCP fail to function. Even if done in 863 proper sequence this causes RTP Timestamp rate switching issues 864 [RFC7160]. However, once an SSRC has left the RTP session (by 865 sending an RTCP BYE packet), that SSRC can be reused by another 866 source (possibly associated with a different bundled "m=" line) after 867 a delay of 5 RTCP reporting intervals (the delay is to ensure the 868 SSRC has timed out, in case the RTCP BYE packet was lost [RFC3550]). 870 10.1.2. Payload Type (PT) Value Reuse 872 Multiple bundled "m=" lines might represent RTP based media. As all 873 RTP based media specified by a BUNDLE group belong to the same RTP 874 session, in order for a given payload type value to be used inside 875 more than one bundled "m=" line, all codecs associated with the 876 payload type number MUST share an identical codec configuration. 877 This means that the codecs MUST share the same media type, encoding 878 name, clock rate and any parameter that can affect the codec 879 configuration and packetization. 880 [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose 881 attribute values must be identical for all codecs that use the same 882 payload type value. 884 10.2. Associating RTP/RTCP Packets With Correct SDP Media Description 886 There are multiple mechanisms that can be used by an endpoint in 887 order to associate received RTP/RTCP packets with a bundled "m=" 888 line. Such mechanisms include using the payload type value carried 889 inside the RTP packets, the SSRC values carried inside the RTP 890 packets, and other "m=" line specific information carried inside the 891 RTP packets. 893 As all RTP/RTCP packets associated with a BUNDLE group are received 894 (and sent) using single address:port combinations, the local 895 address:port combination cannot be used to associate received RTP 896 packets with the correct "m=" line. 898 As described in [Section 10.1.2], the same payload type value might 899 be used inside RTP packets described by multiple "m=" lines. In such 900 cases, the payload type value cannot be used to associate received 901 RTP packets with the correct "m=" line. 903 An offerer and answerer can inform each other which SSRC values they 904 will use for RTP and RTCP by using the SDP 'ssrc' attribute 905 [RFC5576]. To allow for proper association with this mechanism, the 906 'ssrc' attribute needs to be associated with each "m=" line that 907 shares a payload type with any other "m=" line in the same bundle. 908 As the SSRC values will be carried inside the RTP/RTCP packets, the 909 offerer and answerer can then use that information to associate 910 received RTP packets with the correct "m=" line. However, an offerer 911 will not know which SSRC values the answerer will use until it has 912 received the answer providing that information. Due to this, before 913 the offerer has received the answer, the offerer will not be able to 914 associate received RTP/RTCP packets with the correct "m=" line using 915 the SSRC values. 917 In order for an offerer and answerer to always be able to associate 918 received RTP and RTCP packets with the correct "m=" line, an offerer 919 and answerer using the BUNDLE extension MUST support the mechanism 920 defined in Section 14, where the remote endpoint inserts the 921 identification-tag associated with an "m=" line in RTP and RTCP 922 packets associated with that "m=" line. 924 10.3. RTP/RTCP Multiplexing 926 10.3.1. General 928 Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP 929 multiplexing [RFC5761] for the RTP-based media specified by the 930 BUNDLE group. 932 When RTP/RTCP multiplexing is enabled, the same address:port 933 combination will be used for sending all RTP packets and the RTCP 934 packets associated with the BUNDLE group. Each endpoint will send 935 the packets towards the BUNDLE address of the other endpoint. The 936 same address:port combination MAY be used for receiving RTP packets 937 and RTCP packets. 939 10.3.2. SDP Offer/Answer Procedures 941 10.3.2.1. General 943 This section describes how an offerer and answerer use the SDP 'rtcp- 944 mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute 946 [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP 947 multiplexing for RTP-based media specified by a BUNDLE group. 949 The procedures in this section only apply to RTP-based "m=" lines. 951 10.3.2.2. Generating the Initial SDP Offer 953 When an offerer generates an initial offer, the offerer MUST 954 associate either an SDP 'rtcp-mux' attribute [RFC5761] or an SDP 955 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] with each 956 bundled RTP-based "m=" line in the offer. The offerer MUST associate 957 an SDP 'rtcp-mux-only' attribute with each bundle-only "m=" line. If 958 the offerer associates a 'rtcp-mux-only' attribute with an "m=" line, 959 the offerer may also associate a 'rtcp-mux' attribute with the same 960 "m=" line, as described in [I-D.ietf-mmusic-mux-exclusive]. 962 NOTE: Within a BUNDLE group, the offerer can associate the SDP 'rtcp- 963 mux' attribute with some of the RTP-based "m=" lines, while it 964 associates the SDP 'rtcp-mux-only' attribute to other RTP-based "m=" 965 lines, depending on whether the offerer supports fallback to usage of 966 a separate port for RTCP in case the answerer does not include the 967 "m=" line in the BUNDLE group. 969 NOTE: If the offerer associates an SDP 'rtcp-mux' attribute with an 970 "m=" line, the offerer can also associate an SDP 'rtcp' attribute 971 [RFC3605] with a bundled "m=" line, excluding a bundle-only "m=" 972 line, in order to provide a fallback port for RTCP, as described in 973 [RFC5761]. However, the fallback port will only be used in case the 974 answerer does not include the "m=" line in the BUNDLE group in the 975 associated answer. 977 In the initial offer, the address:port combination for RTCP MUST be 978 unique in each bundled RTP-based "m=" line (excluding a 'bundle-only' 979 "m=" line), similar to RTP. 981 10.3.2.3. Generating the SDP Answer 983 When an answerer generates an answer, if the answerer accepts one or 984 more RTP-based "m=" lines within a BUNDLE group, the answerer MUST 985 enable usage of RTP/RTCP multiplexing. The answerer MUST associate 986 an SDP "rtcp-mux" attribute with each RTP-based "m=" line in the 987 answer. In addition, if an "m=" line in the corresponding offer 988 contained an SDP "rtcp-mux-only" attribute, the answerer MUST also 989 associate an SDP "rtcp-mux-only" attribute with the "m=" line in the 990 answer. 992 If an RTP-based "m=" line in the corresponding offer did not contain 993 an SDP "rtcp-mux" attribute or an SDP "rtcp-mux-only" attribute, the 994 answerer MUST NOT include the "m=" line within a BUNDLE group in the 995 answer. 997 If an RTP-based "m=" line in the corresponding offer contained an SDP 998 "rtcp-mux-only" attribute, and if the answerer moves the "m=" line 999 out of the BUNDLE group in the answer Section 8.4.4, the answerer 1000 MUST still either enable RTP/RTCP multiplexing for the media 1001 associated with the "m=" line, or reject the "m=" line Section 8.4.5. 1003 The answerer MUST NOT associate an SDP 'rtcp' attribute with any 1004 bundled "m=" line in the answer. The answerer will use the port 1005 value of the selected offerer BUNDLE address for sending RTP and RTCP 1006 packets associated with each RTP-based bundled "m=" line towards the 1007 offerer. 1009 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1010 negotiated in a previous offer/answer transaction, the answerer MUST 1011 associate an SDP 'rtcp-mux' attribute with each bundled RTP-based 1012 "m=" line in the answer. 1014 10.3.2.4. Offerer Processing of the SDP Answer 1016 When an offerer receives an answer, if the answerer has accepted the 1017 usage of RTP/RTCP multiplexing (see Section 10.3.2.3), the answerer 1018 follows the procedures for RTP/RTCP multiplexing defined in 1019 [RFC5761]. The offerer will use the port value associated with the 1020 answerer BUNDLE address for sending RTP and RTCP packets associated 1021 with each RTP-based bundled "m=" line towards the answerer. 1023 NOTE: It is considered a protocol error if the answerer has not 1024 accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" lines 1025 that the answerer included in the BUNDLE group. 1027 10.3.2.5. Modifying the Session 1029 When an offerer generates a subsequent offer, it MUST associate an 1030 SDP 'rtcp-mux' attribute or an SDP 'rtcp-mux-only' attribute with 1031 each RTP-based bundled "m=" line within the BUNDLE group (including 1032 any bundled RTP-based "m=" line that the offerer wants to add to the 1033 BUNDLE group), unless the offerer wants to disable or remove the "m=" 1034 line from the BUNDLE group. 1036 11. ICE Considerations 1037 11.1. General 1039 This section describes how to use the BUNDLE grouping extension 1040 together with the Interactive Connectivity Establishment (ICE) 1041 mechanism [I-D.ietf-ice-rfc5245bis]. 1043 The generic procedures for negotiating usage of ICE using SDP, 1044 defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE 1045 with BUNDLE, with the following exceptions: 1047 o When BUNDLE addresses for a BUNDLE group have been selected for 1048 both endpoints, ICE connectivity checks and keep-alives only need 1049 to be performed for the whole BUNDLE group, instead of per bundled 1050 "m=" line. 1052 o Among bundled "m=" lines with which the offerer has associated a 1053 shared address, the offerer only associates ICE-related media- 1054 level SDP attributes with the "m=" line associated with the 1055 offerer BUNDLE-tag. 1057 o Among bundled "m=" lines with which the answerer has associated a 1058 shared address, the answerer only associates ICE-related media- 1059 level SDP attributes with the "m=" line associated with the 1060 answerer BUNDLE-tag. 1062 Support and usage of ICE mechanism together with the BUNDLE extension 1063 is OPTIONAL. 1065 11.2. SDP Offer/Answer Procedures 1067 11.2.1. General 1069 When an offerer associates a unique address with a bundled "m=" line 1070 (excluding any bundle-only "m=" line), the offerer MUST associate SDP 1071 'candidate' attributes (and other applicable ICE-related media-level 1072 SDP attributes), containing unique ICE properties (candidates etc), 1073 with the "m=" line, according to the procedures in 1074 [I-D.ietf-mmusic-ice-sip-sdp]. 1076 When an offerer associates a shared address with a bundled "m=" line, 1077 if the "m=" line is associated with the offerer BUNDLE-tag, the 1078 offerer MUST associate SDP 'candidate' attributes (and other 1079 applicable ICE-related media-level SDP attributes), containing shared 1080 ICE properties, with the "m=" line. If the "m=" line is not 1081 associated with the offerer BUNDLE-tag, the offerer MUST NOT 1082 associate ICE-related SDP attributes with the "m=" line. 1084 When an answerer associates a shared address with a bundled "m=" 1085 line, if the "m=" line is associated with the answerer BUNDLE-tag, 1086 the answerer MUST associate SDP 'candidate' attributes (and other 1087 applicable ICE-related media-level SDP attributes), containing shared 1088 ICE properties, with the "m=" line. If the "m=" line is not 1089 associated with the answerer BUNDLE-tag, the answerer MUST NOT 1090 associate ICE-related SDP attributes with the "m=" line. 1092 NOTE: As most ICE-related media-level SDP attributes belong to the 1093 TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the 1094 offerer and answerer follow the rules in Section 8.2. However, in 1095 the case of ICE-related media-level attributes, the rules apply to 1096 all attributes (see note below), even if they belong to a different 1097 mux category. 1099 NOTE: The following ICE-related media-level SDP attributes are 1100 defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote- 1101 candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- 1102 pacing'. 1104 11.2.2. Generating the Initial SDP Offer 1106 When an offerer generates an initial offer, the offerer MUST 1107 associate ICE-related media-level SDP attributes with each bundled 1108 "m=" line, according to [Section 11.2.1]. 1110 11.2.3. Generating the SDP Answer 1112 When an answerer generates an answer that contains a BUNDLE group, 1113 the answerer MUST associated ICE-related SDP attributes with the "m=" 1114 line associated with the answerer BUNDLE-tag, according to 1115 [Section 11.2.1]. 1117 11.2.4. Offerer Processing of the SDP Answer 1119 When an offerer receives an answer, if the answerer supports and uses 1120 the ICE mechanism and the BUNDLE extension, the offerer MUST 1121 associate the ICE properties associated with the offerer BUNDLE 1122 address, selected by the answerer [Section 8.4.2], with each bundled 1123 "m=" line. 1125 11.2.5. Modifying the Session 1127 When an offerer generates a subsequent offer, it MUST associated 1128 unique or shared ICE properties to one or more bundled "m=" lines, 1129 according to [Section 11.2.1]. 1131 12. DTLS Considerations 1133 One or more media streams within a BUNDLE group might use the 1134 Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order 1135 to encrypt the data, or to negotiate encryption keys if another 1136 encryption mechanism is used to encrypt media. 1138 When DTLS is used within a BUNDLE group, the following rules apply: 1140 o There can only be one DTLS association [RFC6347] associated with 1141 the BUNDLE group; and 1143 o Each usage of the DTLS association within the BUNDLE group MUST 1144 use the same mechanism for determining which endpoints (the 1145 offerer or answerer) becomes DTLS client and DTLS server; and 1147 o Each usage of the DTLS association within the Bundle group MUST 1148 use the same mechanism for determining whether an offer or answer 1149 will trigger the establishment of a new DTLS association, or 1150 whether an existing DTLS association will be used; and 1152 o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include 1153 the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message 1154 [RFC5764], The client MUST include the extension even if the usage 1155 of DTLS-SRTP is not negotiated as part of the multimedia session 1156 (e.g. SIP session [RFC3261]. 1158 NOTE: The inclusion of the 'use_srtp' extension during the initial 1159 DTLS handshake ensures that a DTLS renegotiation will not be required 1160 in order to include the extension, in case DTLS-SRTP encrypted media 1161 is added to the BUNDLE group later during the multimedia session. 1163 13. Update to RFC 3264 1165 13.1. General 1167 This section replaces the text of the following sections of RFC 3264: 1169 o Section 5.1 (Unicast Streams). 1171 o Section 8.2 (Removing a Media Stream). 1173 o Section 8.4 (Putting a Unicast Media Stream on Hold). 1175 13.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 1177 For recvonly and sendrecv streams, the port number and address in the 1178 offer indicate where the offerer would like to receive the media 1179 stream. For sendonly RTP streams, the address and port number 1180 indirectly indicate where the offerer wants to receive RTCP reports. 1181 Unless there is an explicit indication otherwise, reports are sent to 1182 the port number one higher than the number indicated. The IP address 1183 and port present in the offer indicate nothing about the source IP 1184 address and source port of RTP and RTCP packets that will be sent by 1185 the offerer. A port number of zero in the offer indicates that the 1186 stream is offered but MUST NOT be used. This has no useful semantics 1187 in an initial offer, but is allowed for reasons of completeness, 1188 since the answer can contain a zero port indicating a rejected stream 1189 (Section 6). Furthermore, existing streams can be terminated by 1190 setting the port to zero (Section 8). In general, a port number of 1191 zero indicates that the media stream is not wanted. 1193 13.3. New text replacing section 5.1 (2nd paragraph) of RFC 3264 1195 For recvonly and sendrecv streams, the port number and address in the 1196 offer indicate where the offerer would like to receive the media 1197 stream. For sendonly RTP streams, the address and port number 1198 indirectly indicate where the offerer wants to receive RTCP reports. 1199 Unless there is an explicit indication otherwise, reports are sent to 1200 the port number one higher than the number indicated. The IP address 1201 and port present in the offer indicate nothing about the source IP 1202 address and source port of RTP and RTCP packets that will be sent by 1203 the offerer. A port number of zero in the offer by default indicates 1204 that the stream is offered but MUST NOT be used, but an extension 1205 mechanism might specify different semantics for the usage of a zero 1206 port value. Furthermore, existing streams can be terminated by 1207 setting the port to zero (Section 8). In general, a port number of 1208 zero by default indicates that the media stream is not wanted. 1210 13.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 1212 A stream that is offered with a port of zero MUST be marked with port 1213 zero in the answer. Like the offer, the answer MAY omit all 1214 attributes present previously, and MAY list just a single media 1215 format from amongst those in the offer. 1217 13.5. New text replacing section 8.2 (2nd paragraph) of RFC 3264 1219 A stream that is offered with a port of zero MUST by default be 1220 marked with port zero in the answer, unless an extension mechanism, 1221 which specifies semantics for the usage of a non-zero port value, is 1222 used. If the stream is marked with port zero in the answer, the 1223 answer MAY omit all attributes present previously, and MAY list just 1224 a single media format from amongst those in the offer." 1226 13.6. Original text of section 8.4 (6th paragraph) of RFC 3264 1228 RFC 2543 [10] specified that placing a user on hold was accomplished 1229 by setting the connection address to 0.0.0.0. Its usage for putting 1230 a call on hold is no longer recommended, since it doesn't allow for 1231 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1232 with connection oriented media. However, it can be useful in an 1233 initial offer when the offerer knows it wants to use a particular set 1234 of media streams and formats, but doesn't know the addresses and 1235 ports at the time of the offer. Of course, when used, the port 1236 number MUST NOT be zero, which would specify that the stream has been 1237 disabled. An agent MUST be capable of receiving SDP with a 1238 connection address of 0.0.0.0, in which case it means that neither 1239 RTP nor RTCP should be sent to the peer. 1241 13.7. New text replacing section 8.4 (6th paragraph) of RFC 3264 1243 RFC 2543 [10] specified that placing a user on hold was accomplished 1244 by setting the connection address to 0.0.0.0. Its usage for putting 1245 a call on hold is no longer recommended, since it doesn't allow for 1246 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1247 with connection oriented media. However, it can be useful in an 1248 initial offer when the offerer knows it wants to use a particular set 1249 of media streams and formats, but doesn't know the addresses and 1250 ports at the time of the offer. Of course, when used, the port 1251 number MUST NOT be zero, if it would specify that the stream has been 1252 disabled. However, an extension mechanism might specify different 1253 semantics of the zero port number usage. An agent MUST be capable of 1254 receiving SDP with a connection address of 0.0.0.0, in which case it 1255 means that neither RTP nor RTCP should be sent to the peer. 1257 14. RTP/RTCP extensions for identification-tag transport 1259 14.1. General 1261 SDP Offerers and Answerers [RFC3264] can associate identification- 1262 tags with "m=" lines within SDP Offers and Answers, using the 1263 procedures in [RFC5888]. Each identification-tag uniquely represents 1264 an "m=" line. 1266 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1267 used to carry identification-tags within RTCP SDES packets. This 1268 section also defines a new RTP header extension [RFC5285], which is 1269 used to carry identification-tags in RTP packets. 1271 The SDES item and RTP header extension make it possible for a 1272 receiver to associate received RTCP- and RTP packets with a specific 1273 "m=" line, with which the receiver has associated an identification- 1274 tag, even if those "m=" lines are part of the same RTP session. A 1275 media recipient informs the media sender about the identification-tag 1276 associated with an "m=" line through the use of an 'mid' attribute 1277 [RFC5888]. The media sender then inserts the identification-tag in 1278 RTCP and RTP packets sent to the media recipient. 1280 NOTE: This text above defines how identification-tags are carried in 1281 SDP Offers and Answers. The usage of other signalling protocols for 1282 carrying identification-tags is not prevented, but the usage of such 1283 protocols is outside the scope of this document. 1285 [RFC3550] defines general procedures regarding the RTCP transmission 1286 interval. The RTCP MID SDES item SHOULD be sent in the first few 1287 RTCP packets sent on joining the session, and SHOULD be sent 1288 regularly thereafter. The exact number of RTCP packets in which this 1289 SDES item is sent is intentionally not specified here, as it will 1290 depend on the expected packet loss rate, the RTCP reporting interval, 1291 and the allowable overhead. 1293 The RTP MID header extension SHOULD be included in some RTP packets 1294 at the start of the session and whenever the SSRC changes. It might 1295 also be useful to include the header extension in RTP packets that 1296 comprise random access points in the media (e.g., with video 1297 I-frames). The exact number of RTP packets in which this header 1298 extension is sent is intentionally not specified here, as it will 1299 depend on expected packet loss rate and loss patterns, the overhead 1300 the application can tolerate, and the importance of immediate receipt 1301 of the identification-tag. 1303 For robustness purpose, endpoints need to be prepared for situations 1304 where the reception of the identification-tag is delayed, and SHOULD 1305 NOT terminate sessions in such cases, as the identification-tag is 1306 likely to arrive soon. 1308 14.2. RTCP MID SDES Item 1310 0 1 2 3 1311 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 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | MID=TBD | length | identification-tag ... 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 The identification-tag payload is UTF-8 encoded, as in SDP. 1318 The identification-tag is not zero terminated. 1320 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1321 identifier value.] 1323 14.3. RTP MID Header Extension 1325 The payload, containing the identification-tag, of the RTP MID header 1326 extension element can be encoded using either the one-byte or two- 1327 byte header [RFC5285]. The identification-tag payload is UTF-8 1328 encoded, as in SDP. 1330 The identification-tag is not zero terminated. Note, that set of 1331 header extensions included in the packet needs to be padded to the 1332 next 32-bit boundary using zero bytes [RFC5285]. 1334 As the identification-tag is included in either an RTCP SDES item or 1335 an RTP header extension, or both, there should be some consideration 1336 about the packet expansion caused by the identification-tag. To 1337 avoid Maximum Transmission Unit (MTU) issues for the RTP packets, the 1338 header extension's size needs to be taken into account when encoding 1339 the media. 1341 It is recommended that the identification-tag is kept short. Due to 1342 the properties of the RTP header extension mechanism, when using the 1343 one-byte header, a tag that is 1-3 bytes will result in that a 1344 minimal number of 32-bit words are used for the RTP header extension, 1345 in case no other header extensions are included at the same time. 1346 Note, do take into account that some single characters when UTF-8 1347 encoded will result in multiple octets. 1349 15. IANA Considerations 1351 15.1. New SDES item 1353 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1354 document.] 1356 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1357 identifier value.] 1359 This document adds the MID SDES item to the IANA "RTP SDES item 1360 types" registry as follows: 1362 Value: TBD 1363 Abbrev.: MID 1364 Name: Media Identification 1365 Reference: RFCXXXX 1367 15.2. New RTP Header Extension URI 1369 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1370 document.] 1372 This document defines a new extension URI in the RTP SDES Compact 1373 Header Extensions sub-registry of the RTP Compact Header Extensions 1374 registry sub-registry, according to the following data: 1376 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1377 Description: Media identification 1378 Contact: christer.holmberg@ericsson.com 1379 Reference: RFCXXXX 1381 The SDES item does not reveal privacy information about the users. 1382 It is simply used to associate RTP-based media with the correct SDP 1383 media description (m- line) in the SDP used to negotiate the media. 1385 The purpose of the extension is for the offerer to be able to 1386 associate received multiplexed RTP-based media before the offerer 1387 receives the associated SDP answer. 1389 15.3. New SDP Attribute 1391 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1392 document.] 1394 This document defines a new SDP media-level attribute, 'bundle-only', 1395 according to the following data: 1397 Attribute name: bundle-only 1398 Type of attribute: media 1399 Subject to charset: No 1400 Purpose: Request a media description to be accepted 1401 in the answer only if kept within a BUNDLE 1402 group by the answerer. 1403 Appropriate values: N/A 1404 Contact name: Christer Holmberg 1405 Contact e-mail: christer.holmberg@ericsson.com 1406 Reference: RFCXXXX 1408 15.4. New SDP Group Semantics 1410 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1411 document.] 1413 This document registers the following semantics with IANA in the 1414 "Semantics for the "group" SDP Attribute" subregistry (under the 1415 "Session Description Protocol (SDP) Parameters" registry: 1417 Semantics Token Reference 1418 ------------------------------------- ------ --------- 1419 Media bundling BUNDLE [RFCXXXX] 1421 16. Security Considerations 1423 The security considerations defined in [RFC3264] and [RFC5888] apply 1424 to the BUNDLE extension. Bundle does not change which information 1425 flows over the network but only changes which addresses and ports 1426 that information is flowing on and thus has very little impact on the 1427 security of the RTP sessions. 1429 When the BUNDLE extension is used, a single set of security 1430 credentials might be used for all media streams specified by a BUNDLE 1431 group. 1433 When the BUNDLE extension is used, the number of SSRC values within a 1434 single RTP session increases, which increases the risk of SSRC 1435 collision. [RFC4568] describes how SSRC collision may weaken SRTP 1436 and SRTCP encryption in certain situations. 1438 17. Examples 1440 17.1. Example: Bundle Address Selection 1442 The example below shows: 1444 o An offer, in which the offerer associates a unique address with 1445 each bundled "m=" line within the BUNDLE group. 1447 o An answer, in which the answerer selects the offerer BUNDLE 1448 address, and in which selects its own BUNDLE address (the answerer 1449 BUNDLE address) and associates it with each bundled "m=" line 1450 within the BUNDLE group. 1452 SDP Offer (1) 1454 v=0 1455 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1456 s= 1457 c=IN IP4 atlanta.example.com 1458 t=0 0 1459 a=group:BUNDLE foo bar 1460 m=audio 10000 RTP/AVP 0 8 97 1461 b=AS:200 1462 a=mid:foo 1463 a=rtpmap:0 PCMU/8000 1464 a=rtpmap:8 PCMA/8000 1465 a=rtpmap:97 iLBC/8000 1466 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1467 m=video 10002 RTP/AVP 31 32 1468 b=AS:1000 1469 a=mid:bar 1470 a=rtpmap:31 H261/90000 1471 a=rtpmap:32 MPV/90000 1472 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1474 SDP Answer (2) 1476 v=0 1477 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1478 s= 1479 c=IN IP4 biloxi.example.com 1480 t=0 0 1481 a=group:BUNDLE foo bar 1482 m=audio 20000 RTP/AVP 0 1483 b=AS:200 1484 a=mid:foo 1485 a=rtpmap:0 PCMU/8000 1486 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1487 m=video 20000 RTP/AVP 32 1488 b=AS:1000 1489 a=mid:bar 1490 a=rtpmap:32 MPV/90000 1491 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1493 17.2. Example: BUNDLE Extension Rejected 1495 The example below shows: 1497 o An offer, in which the offerer associates a unique address with 1498 each bundled "m=" line within the BUNDLE group. 1500 o An answer, in which the answerer rejects the offered BUNDLE group, 1501 and associates a unique address with each "m=" line (following 1502 normal RFC 3264 procedures). 1504 SDP Offer (1) 1506 v=0 1507 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1508 s= 1509 c=IN IP4 atlanta.example.com 1510 t=0 0 1511 a=group:BUNDLE foo bar 1512 m=audio 10000 RTP/AVP 0 8 97 1513 b=AS:200 1514 a=mid:foo 1515 a=rtpmap:0 PCMU/8000 1516 a=rtpmap:8 PCMA/8000 1517 a=rtpmap:97 iLBC/8000 1518 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1519 m=video 10002 RTP/AVP 31 32 1520 b=AS:1000 1521 a=mid:bar 1522 a=rtpmap:31 H261/90000 1523 a=rtpmap:32 MPV/90000 1524 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1526 SDP Answer (2) 1528 v=0 1529 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1530 s= 1531 c=IN IP4 biloxi.example.com 1532 t=0 0 1533 m=audio 20000 RTP/AVP 0 1534 b=AS:200 1535 a=rtpmap:0 PCMU/8000 1536 m=video 30000 RTP/AVP 32 1537 b=AS:1000 1538 a=rtpmap:32 MPV/90000 1540 17.3. Example: Offerer Adds A Media Description To A BUNDLE Group 1542 The example below shows: 1544 o A subsequent offer (the BUNDLE group has been created as part of a 1545 previous offer/answer transaction), in which the offerer adds a 1546 new "m=" line, represented by the "zen" identification-tag, to a 1547 previously negotiated BUNDLE group, associates a unique address 1548 with the added "m=" line, and associates the previously selected 1549 offerer BUNDLE address with each of the other bundled "m=" lines 1550 within the BUNDLE group. 1552 o An answer, in which the answerer associates the answerer BUNDLE 1553 address with each bundled "m=" line (including the newly added 1554 "m=" line) within the BUNDLE group. 1556 SDP Offer (1) 1558 v=0 1559 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1560 s= 1561 c=IN IP4 atlanta.example.com 1562 t=0 0 1563 a=group:BUNDLE foo bar zen 1564 m=audio 10000 RTP/AVP 0 8 97 1565 b=AS:200 1566 a=mid:foo 1567 a=rtpmap:0 PCMU/8000 1568 a=rtpmap:8 PCMA/8000 1569 a=rtpmap:97 iLBC/8000 1570 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1571 m=video 10000 RTP/AVP 31 32 1572 b=AS:1000 1573 a=mid:bar 1574 a=rtpmap:31 H261/90000 1575 a=rtpmap:32 MPV/90000 1576 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1577 m=video 20000 RTP/AVP 66 1578 b=AS:1000 1579 a=mid:zen 1580 a=rtpmap:66 H261/90000 1581 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1583 SDP Answer (2) 1585 v=0 1586 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1587 s= 1588 c=IN IP4 biloxi.example.com 1589 t=0 0 1590 a=group:BUNDLE foo bar zen 1591 m=audio 20000 RTP/AVP 0 1592 b=AS:200 1593 a=mid:foo 1594 a=rtpmap:0 PCMU/8000 1595 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1596 m=video 20000 RTP/AVP 32 1597 b=AS:1000 1598 a=mid:bar 1599 a=rtpmap:32 MPV/90000 1600 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1601 m=video 20000 RTP/AVP 66 1602 b=AS:1000 1603 a=mid:zen 1604 a=rtpmap:66 H261/90000 1605 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1607 17.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 1609 The example below shows: 1611 o A subsequent offer (the BUNDLE group has been created as part of a 1612 previous offer/answer transaction), in which the offerer moves a 1613 bundled "m=" line out of a BUNDLE group, associates a unique 1614 address with the moved "m=" line, and associates the offerer 1615 BUNDLE address with each other bundled "m=" line within the BUNDLE 1616 group. 1618 o An answer, in which the answerer moves the "m=" line out of the 1619 BUNDLE group, associates unique address with the moved "m=" line, 1620 and associates the answerer BUNDLE address with each of the 1621 remaining bundled "m=" line within the BUNDLE group. 1623 SDP Offer (1) 1625 v=0 1626 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1627 s= 1628 c=IN IP4 atlanta.example.com 1629 t=0 0 1630 a=group:BUNDLE foo bar 1631 m=audio 10000 RTP/AVP 0 8 97 1632 b=AS:200 1633 a=mid:foo 1634 a=rtpmap:0 PCMU/8000 1635 a=rtpmap:8 PCMA/8000 1636 a=rtpmap:97 iLBC/8000 1637 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1638 m=video 10000 RTP/AVP 31 32 1639 b=AS:1000 1640 a=mid:bar 1641 a=rtpmap:31 H261/90000 1642 a=rtpmap:32 MPV/90000 1643 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1644 m=video 50000 RTP/AVP 66 1645 b=AS:1000 1646 a=mid:zen 1647 a=rtpmap:66 H261/90000 1649 SDP Answer (2) 1651 v=0 1652 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1653 s= 1654 c=IN IP4 biloxi.example.com 1655 t=0 0 1656 a=group:BUNDLE foo bar 1657 m=audio 20000 RTP/AVP 0 1658 b=AS:200 1659 a=mid:foo 1660 a=rtpmap:0 PCMU/8000 1661 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1662 m=video 20000 RTP/AVP 32 1663 b=AS:1000 1664 a=mid:bar 1665 a=rtpmap:32 MPV/90000 1666 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1667 m=video 60000 RTP/AVP 66 1668 b=AS:1000 1669 a=mid:zen 1670 a=rtpmap:66 H261/90000 1672 17.5. Example: Offerer Disables A Media Description Within A BUNDLE 1673 Group 1675 The example below shows: 1677 o A subsequent offer (the BUNDLE group has been created as part of a 1678 previous offer/answer transaction), in which the offerer disables 1679 a bundled "m=" line within BUNDLE group, assigns a zero port 1680 number to the disabled "m=" line, and associates the offerer 1681 BUNDLE address with each of the other bundled "m=" lines within 1682 the BUNDLE group. 1684 o An answer, in which the answerer moves the disabled "m=" line out 1685 of the BUNDLE group, assigns a zero port value to the disabled 1686 "m=" line, and associates the answerer BUNDLE address with each of 1687 the remaining bundled "m=" line within the BUNDLE group. 1689 SDP Offer (1) 1691 v=0 1692 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1693 s= 1694 c=IN IP4 atlanta.example.com 1695 t=0 0 1696 a=group:BUNDLE foo bar 1697 m=audio 10000 RTP/AVP 0 8 97 1698 b=AS:200 1699 a=mid:foo 1700 a=rtpmap:0 PCMU/8000 1701 a=rtpmap:8 PCMA/8000 1702 a=rtpmap:97 iLBC/8000 1703 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1704 m=video 10000 RTP/AVP 31 32 1705 b=AS:1000 1706 a=mid:bar 1707 a=rtpmap:31 H261/90000 1708 a=rtpmap:32 MPV/90000 1709 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1710 m=video 0 RTP/AVP 66 1711 a=mid:zen 1712 a=rtpmap:66 H261/90000 1714 SDP Answer (2) 1716 v=0 1717 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1718 s= 1719 c=IN IP4 biloxi.example.com 1720 t=0 0 1721 a=group:BUNDLE foo bar 1722 m=audio 20000 RTP/AVP 0 1723 b=AS:200 1724 a=mid:foo 1725 a=rtpmap:0 PCMU/8000 1726 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1727 m=video 20000 RTP/AVP 32 1728 b=AS:1000 1729 a=mid:bar 1730 a=rtpmap:32 MPV/90000 1731 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1732 m=video 0 RTP/AVP 66 1733 a=mid:zen 1734 a=rtpmap:66 H261/90000 1736 18. Acknowledgements 1738 The usage of the SDP grouping extension for negotiating bundled media 1739 is based on a similar alternatives proposed by Harald Alvestrand and 1740 Cullen Jennings. The BUNDLE extension described in this document is 1741 based on the different alternative proposals, and text (e.g. SDP 1742 examples) have been borrowed (and, in some cases, modified) from 1743 those alternative proposals. 1745 The SDP examples are also modified versions from the ones in the 1746 Alvestrand proposal. 1748 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 1749 Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, 1750 Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju and 1751 Justin Uberti for reading the text, and providing useful feedback. 1753 Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for 1754 providing help and text on the RTP/RTCP procedures. 1756 Thanks to Spotify for providing music for the countless hours of 1757 document editing. 1759 19. Change Log 1761 [RFC EDITOR NOTE: Please remove this section when publishing] 1763 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30 1765 o Indicating in the Abstract and Introduction that the document 1766 updates RFC 3264. 1768 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29 1770 o Change based on WGLC comment from Colin Perkins. 1772 o - Clarify that SSRC can be reused by another source after a delay 1773 of 5 RTCP reporting intervals. 1775 o Change based on WGLC comment from Alissa Cooper. 1777 o - IANA registry name fix. 1779 o - Additional IANA registration information added. 1781 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28 1783 o - Alignment with exclusive mux procedures. 1785 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 1787 o - Yet another terminology change. 1789 o - Mux category considerations added. 1791 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 1793 o - ICE considerations modified: ICE-related SDP attributes only 1794 added to the bundled m- line representing the selected BUNDLE 1795 address. 1797 o - Reference to draft-ietf-mmusic-ice-sip-sdp added. 1799 o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- 1800 rfc5245bis. 1802 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 1804 o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux 1805 considerations. 1807 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 1809 o - Reference and procedures associated with exclusive RTP/RTCP mux 1810 added 1812 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 1814 o - RTCP-MUX mandatory for bundled RTP m- lines 1816 o - Editorial fixes based on comments from Flemming Andreasen 1818 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 1820 o - Correction of Ari's family name 1822 o - Editorial fixes based on comments from Thomas Stach 1824 o - RTP/RTCP correction based on comment from Magnus Westerlund 1825 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 1826 msg14861.html 1828 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 1830 o - Correct based on comment from Paul Kyzivat 1832 o -- 'received packets' replaced with 'received data' 1834 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 1836 o - Clarification based on comment from James Guballa 1838 o - Clarification based on comment from Flemming Andreasen 1840 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 1842 o - DTLS Considerations section added. 1844 o - BUNDLE semantics added to the IANA Considerations 1846 o - Changes based on WGLC comments from Adam Roach 1848 o -- http://www.ietf.org/mail-archive/web/mmusic/current/ 1849 msg14673.html 1851 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 1853 o - Changes based on agreements at IETF#92 1855 o -- BAS Offer removed, based on agreement at IETF#92. 1857 o -- Procedures regarding usage of SDP "b=" line is replaced with a 1858 reference to to draft-ietf-mmusic-sdp-mux-attributes. 1860 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 1862 o - Editorial changes based on comments from Magnus Westerlund. 1864 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 1866 o - Modification of RTP/RTCP multiplexing section, based on comments 1867 from Magnus Westerlund. 1869 o - Reference updates. 1871 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 1872 o - Editorial fix. 1874 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 1876 o - Editorial changes. 1878 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 1880 o Changes to allow a new suggested offerer BUNDLE address to be 1881 assigned to each bundled m- line. 1883 o Changes based on WGLC comments from Paul Kyzivat 1885 o - Editorial fixes 1887 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 1889 o Usage of SDP 'extmap' attribute added 1891 o SDP 'bundle-only' attribute scoped with "m=" lines with a zero 1892 port value 1894 o Changes based on WGLC comments from Thomas Stach 1896 o - ICE candidates not assigned to bundle-only m- lines with a zero 1897 port value 1899 o - Editorial changes 1901 o Changes based on WGLC comments from Colin Perkins 1903 o - Editorial changes: 1905 o -- "RTP SDES item" -> "RTCP SDES item" 1907 o -- "RTP MID SDES item" -> "RTCP MID SDES item" 1909 o - Changes in section 10.1.1: 1911 o -- "SHOULD NOT" -> "MUST NOT" 1913 o -- Additional text added to the Note 1915 o - Change to section 13.2: 1917 o -- Clarify that mid value is not zero terminated 1919 o - Change to section 13.3: 1921 o -- Clarify that mid value is not zero terminated 1923 o -- Clarify padding 1925 o Changes based on WGLC comments from Paul Kyzivat 1927 o - Editorial changes: 1929 o Changes based on WGLC comments from Jonathan Lennox 1931 o - Editorial changes: 1933 o - Defintion of SDP bundle-only attribute alligned with structure 1934 in 4566bis draft 1936 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 1938 o Editorial corrections based on comments from Harald Alvestrand. 1940 o Editorial corrections based on comments from Cullen Jennings. 1942 o Reference update (RFC 7160). 1944 o Clarification about RTCP packet sending when RTP/RTCP multiplexing 1945 is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ 1946 msg13765.html). 1948 o Additional text added to the Security Considerations. 1950 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 1952 o SDP bundle-only attribute added to IANA Considerations. 1954 o SDES item and RTP header extension added to Abstract and 1955 Introduction. 1957 o Modification to text updating section 8.2 of RFC 3264. 1959 o Reference corrections. 1961 o Editorial corrections. 1963 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 1965 o Terminology change: "bundle-only attribute assigned to m= line" to 1966 "bundle-only attribute associated with m= line". 1968 o Editorial corrections. 1970 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 1972 o Editorial corrections. 1974 o - "of"->"if" (8.3.2.5). 1976 o - "optional"->"OPTIONAL" (9.1). 1978 o - Syntax/ABNF for 'bundle-only' attribute added. 1980 o - SDP Offer/Answer sections merged. 1982 o - 'Request new offerer BUNDLE address' section added 1984 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 1986 o OPEN ISSUE regarding Receiver-ID closed. 1988 o - RTP MID SDES Item. 1990 o - RTP MID Header Extension. 1992 o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers 1993 closed. 1995 o - Indicating that, when rtcp-mux is used, the answerer MUST NOT 1996 include an 'rtcp' attribute in the answer, based on the procedures 1997 in section 5.1.3 of RFC 5761. 1999 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 2001 o Draft title changed. 2003 o Added "SDP" to section names containing "Offer" or "Answer". 2005 o Editorial fixes based on comments from Paul Kyzivat 2006 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2007 msg13314.html). 2009 o Editorial fixed based on comments from Colin Perkins 2010 (http://www.ietf.org/mail-archive/web/mmusic/current/ 2011 msg13318.html). 2013 o - Removed text about extending BUNDLE to allow multiple RTP 2014 sessions within a BUNDLE group. 2016 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 2017 o Major re-structure of SDP Offer/Answer sections, to align with RFC 2018 3264 structure. 2020 o Additional definitions added. 2022 o - Shared address. 2024 o - Bundled "m=" line. 2026 o - Bundle-only "m=" line. 2028 o - Offerer suggested BUNDLE mid. 2030 o - Answerer selected BUNDLE mid. 2032 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 2033 to multiple "m=" lines until it has received an SDP Answer 2034 indicating support of the BUNDLE extension. 2036 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 2037 Answerer supports the BUNDLE extension, assign a zero port value 2038 to a 'bundle-only' "m=" line. 2040 o SDP 'bundle-only' attribute section added. 2042 o Connection data nettype/addrtype restrictions added. 2044 o RFC 3264 update section added. 2046 o Indicating that a specific payload type value can be used in 2047 multiple "m=" lines, if the value represents the same codec 2048 configuration in each "m=" line. 2050 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 2052 o Updated Offerer procedures (http://www.ietf.org/mail- 2053 archive/web/mmusic/current/msg12293.html). 2055 o Updated Answerer procedures (http://www.ietf.org/mail- 2056 archive/web/mmusic/current/msg12333.html). 2058 o Usage of SDP 'bundle-only' attribute added. 2060 o Reference to Trickle ICE document added. 2062 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 2063 o Mechanism modified, to be based on usage of SDP Offers with both 2064 different and identical port number values, depending on whether 2065 it is known if the remote endpoint supports the extension. 2067 o Cullen Jennings added as co-author. 2069 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 2071 o No changes. New version due to expiration. 2073 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 2075 o No changes. New version due to expiration. 2077 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 2079 o Draft name changed. 2081 o Harald Alvestrand added as co-author. 2083 o "Multiplex" terminology changed to "bundle". 2085 o Added text about single versus multiple RTP Sessions. 2087 o Added reference to RFC 3550. 2089 20. References 2091 20.1. Normative References 2093 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2094 Requirement Levels", BCP 14, RFC 2119, 2095 DOI 10.17487/RFC2119, March 1997, 2096 . 2098 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2099 with Session Description Protocol (SDP)", RFC 3264, 2100 DOI 10.17487/RFC3264, June 2002, 2101 . 2103 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2104 Jacobson, "RTP: A Transport Protocol for Real-Time 2105 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2106 July 2003, . 2108 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2109 in Session Description Protocol (SDP)", RFC 3605, 2110 DOI 10.17487/RFC3605, October 2003, 2111 . 2113 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2114 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2115 July 2006, . 2117 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2118 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 2119 . 2121 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2122 (ICE): A Protocol for Network Address Translator (NAT) 2123 Traversal for Offer/Answer Protocols", RFC 5245, 2124 DOI 10.17487/RFC5245, April 2010, 2125 . 2127 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 2128 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2129 2008, . 2131 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2132 Control Packets on a Single Port", RFC 5761, 2133 DOI 10.17487/RFC5761, April 2010, 2134 . 2136 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2137 Security (DTLS) Extension to Establish Keys for the Secure 2138 Real-time Transport Protocol (SRTP)", RFC 5764, 2139 DOI 10.17487/RFC5764, May 2010, 2140 . 2142 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2143 Protocol (SDP) Grouping Framework", RFC 5888, 2144 DOI 10.17487/RFC5888, June 2010, 2145 . 2147 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2148 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2149 January 2012, . 2151 [I-D.ietf-ice-rfc5245bis] 2152 Keraenen, A., Holmberg, C., and J. Rosenberg, "Interactive 2153 Connectivity Establishment (ICE): A Protocol for Network 2154 Address Translator (NAT) Traversal", draft-ietf-ice- 2155 rfc5245bis-02 (work in progress), June 2016. 2157 [I-D.ietf-mmusic-sdp-mux-attributes] 2158 Nandakumar, S., "A Framework for SDP Attributes when 2159 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 2160 (work in progress), January 2016. 2162 [I-D.ietf-mmusic-mux-exclusive] 2163 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 2164 Multiplexing using SDP", draft-ietf-mmusic-mux- 2165 exclusive-07 (work in progress), June 2016. 2167 [I-D.ietf-mmusic-ice-sip-sdp] 2168 Petit-Huguenin, M., Keraenen, A., and S. Nandakumar, 2169 "Using Interactive Connectivity Establishment (ICE) with 2170 Session Description Protocol (SDP) offer/answer and 2171 Session Initiation Protocol (SIP)", draft-ietf-mmusic-ice- 2172 sip-sdp-08 (work in progress), March 2016. 2174 20.2. Informative References 2176 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2177 A., Peterson, J., Sparks, R., Handley, M., and E. 2178 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2179 DOI 10.17487/RFC3261, June 2002, 2180 . 2182 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 2183 Description Protocol (SDP) Security Descriptions for Media 2184 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 2185 . 2187 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2188 Media Attributes in the Session Description Protocol 2189 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 2190 . 2192 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 2193 Clock Rates in an RTP Session", RFC 7160, 2194 DOI 10.17487/RFC7160, April 2014, 2195 . 2197 [I-D.ietf-mmusic-trickle-ice] 2198 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 2199 Incremental Provisioning of Candidates for the Interactive 2200 Connectivity Establishment (ICE) Protocol", draft-ietf- 2201 mmusic-trickle-ice-02 (work in progress), January 2015. 2203 Appendix A. Design Considerations 2205 A.1. General 2207 One of the main issues regarding the BUNDLE grouping extensions has 2208 been whether, in SDP Offers and SDP Answers, the same port value 2209 should be inserted in "m=" lines associated with a BUNDLE group, as 2210 the purpose of the extension is to negotiate the usage of a single 2211 address:port combination for media specified by the "m=" lines. 2212 Issues with both approaches, discussed in the Appendix have been 2213 raised. The outcome was to specify a mechanism which uses SDP Offers 2214 with both different and identical port values. 2216 Below are the primary issues that have been considered when defining 2217 the "BUNDLE" grouping extension: 2219 o 1) Interoperability with existing UAs. 2221 o 2) Interoperability with intermediary B2BUA- and proxy entities. 2223 o 3) Time to gather, and the number of, ICE candidates. 2225 o 4) Different error scenarios, and when they occur. 2227 o 5) SDP Offer/Answer impacts, including usage of port number value 2228 zero. 2230 NOTE: Before this document is published as an RFC, this 2231 Appendix might be removed. 2233 A.2. UA Interoperability 2235 Consider the following SDP Offer/Answer exchange, where Alice sends 2236 an SDP Offer to Bob: 2238 SDP Offer 2240 v=0 2241 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2242 s= 2243 c=IN IP4 atlanta.example.com 2244 t=0 0 2245 m=audio 10000 RTP/AVP 97 2246 a=rtpmap:97 iLBC/8000 2247 m=video 10002 RTP/AVP 97 2248 a=rtpmap:97 H261/90000 2250 SDP Answer 2252 v=0 2253 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2254 s= 2255 c=IN IP4 biloxi.example.com 2256 t=0 0 2257 m=audio 20000 RTP/AVP 97 2258 a=rtpmap:97 iLBC/8000 2259 m=video 20002 RTP/AVP 97 2260 a=rtpmap:97 H261/90000 2262 RFC 4961 specifies a way of doing symmetric RTP but that is an a 2263 later invention to RTP and Bob can not assume that Alice supports RFC 2264 4961. This means that Alice may be sending RTP from a different port 2265 than 10000 or 10002 - some implementation simply send the RTP from an 2266 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2267 way that Bob know if it should be passed to the video or audio codec 2268 is by looking at the port it was received on. This lead some SDP 2269 implementations to use the fact that each "m=" line had a different 2270 port number to use that port number as an index to find the correct m 2271 line in the SDP. As a result, some implementations that do support 2272 symmetric RTP and ICE still use a SDP data structure where SDP with 2273 "m=" lines with the same port such as: 2275 SDP Offer 2277 v=0 2278 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2279 s= 2280 c=IN IP4 atlanta.example.com 2281 t=0 0 2282 m=audio 10000 RTP/AVP 97 2283 a=rtpmap:97 iLBC/8000 2284 m=video 10000 RTP/AVP 98 2285 a=rtpmap:98 H261/90000 2287 will result in the second "m=" line being considered an SDP error 2288 because it has the same port as the first line. 2290 A.3. Usage of port number value zero 2292 In an SDP Offer or SDP Answer, the media specified by an "m=" line 2293 can be disabled/rejected by setting the port number value to zero. 2294 This is different from e.g. using the SDP direction attributes, where 2295 RTCP traffic will continue even if the SDP "inactive" attribute is 2296 indicated for the associated "m=" line. 2298 If each "m=" line associated with a BUNDLE group would contain 2299 different port values, and one of those port values would be used for 2300 a BUNDLE address associated with the BUNDLE group, problems would 2301 occur if an endpoint wants to disable/reject the "m=" line associated 2302 with that port, by setting the port value to zero. After that, no 2303 "m=" line would contain the port value which is used for the BUNDLE 2304 address. In addition, it is unclear what would happen to the ICE 2305 candidates associated with the "m=" line, as they are also used for 2306 the BUNDLE address. 2308 A.4. B2BUA And Proxy Interoperability 2310 Some back to back user agents may be configured in a mode where if 2311 the incoming call leg contains an SDP attribute the B2BUA does not 2312 understand, the B2BUS still generates that SDP attribute in the Offer 2313 for the outgoing call leg. Consider an B2BUA that did not understand 2314 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 2315 Further assume that the B2BUA was configured to tear down any call 2316 where it did not see any RTCP for 5 minutes. In this cases, if the 2317 B2BUA received an Offer like: 2319 SDP Offer 2321 v=0 2322 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2323 s= 2324 c=IN IP4 atlanta.example.com 2325 t=0 0 2326 m=audio 49170 RTP/AVP 0 2327 a=rtcp:53020 2329 It would be looking for RTCP on port 49172 but would not see any 2330 because the RTCP would be on port 53020 and after five minutes, it 2331 would tear down the call. Similarly, an SBC that did not understand 2332 BUNDLE yet put BUNDLE in it's offer may be looking for media on the 2333 wrong port and tear down the call. It is worth noting that a B2BUA 2334 that generated an Offer with capabilities it does not understand is 2335 not compliant with the specifications. 2337 A.4.1. Traffic Policing 2339 Sometimes intermediaries do not act as B2BUA, in the sense that they 2340 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2341 however, they may use SDP information (e.g. IP address and port) in 2342 order to control traffic gating functions, and to set traffic 2343 policing rules. There might be rules which will trigger a session to 2344 be terminated in case media is not sent or received on the ports 2345 retrieved from the SDP. This typically occurs once the session is 2346 already established and ongoing. 2348 A.4.2. Bandwidth Allocation 2350 Sometimes intermediaries do not act as B2BUA, in the sense that they 2351 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2352 however, they may use SDP information (e.g. codecs and media types) 2353 in order to control bandwidth allocation functions. The bandwidth 2354 allocation is done per "m=" line, which means that it might not be 2355 enough if media specified by all "m=" lines try to use that 2356 bandwidth. That may either simply lead to bad user experience, or to 2357 termination of the call. 2359 A.5. Candidate Gathering 2361 When using ICE, an candidate needs to be gathered for each port. 2362 This takes approximately 20 ms extra for each extra "m=" line due to 2363 the NAT pacing requirements. All of this gather can be overlapped 2364 with other things while the page is loading to minimize the impact. 2366 If the client only wants to generate TURN or STUN ICE candidates for 2367 one of the "m=" lines and then use trickle ICE 2368 [I-D.ietf-mmusic-trickle-ice] to get the non host ICE candidates for 2369 the rest of the "m=" lines, it MAY do that and will not need any 2370 additional gathering time. 2372 Some people have suggested a TURN extension to get a bunch of TURN 2373 allocation at once. This would only provide a single STUN result so 2374 in cases where the other end did not support BUNDLE, may cause more 2375 use of the TURN server but would be quick in the cases where both 2376 sides supported BUNDLE and would fall back to a successful call in 2377 the other cases. 2379 Authors' Addresses 2381 Christer Holmberg 2382 Ericsson 2383 Hirsalantie 11 2384 Jorvas 02420 2385 Finland 2387 Email: christer.holmberg@ericsson.com 2389 Harald Tveit Alvestrand 2390 Google 2391 Kungsbron 2 2392 Stockholm 11122 2393 Sweden 2395 Email: harald@alvestrand.no 2397 Cullen Jennings 2398 Cisco 2399 400 3rd Avenue SW, Suite 350 2400 Calgary, AB T2P 4H2 2401 Canada 2403 Email: fluffy@iii.ca