idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-12.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3264, but the abstract doesn't seem to directly say this. It does mention RFC3264 though, so this could be OK. 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 9, 2014) is 3477 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) == Missing Reference: 'Section 8' is mentioned on line 328, but not defined == Missing Reference: 'Section 10' is mentioned on line 407, but not defined == Missing Reference: 'Section 6' is mentioned on line 408, but not defined == Missing Reference: 'Section 11' is mentioned on line 410, but not defined == Missing Reference: 'Section 7' is mentioned on line 415, but not defined == Missing Reference: 'Section 13' is mentioned on line 882, but not defined -- Looks like a reference, but probably isn't: '10' on line 1134 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-02 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-02) exists of draft-ietf-mmusic-trickle-ice-01 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Updates: 3264 (if approved) H. Alvestrand 5 Intended status: Standards Track Google 6 Expires: April 12, 2015 C. Jennings 7 Cisco 8 October 9, 2014 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-12.txt 14 Abstract 16 This specification defines a new SDP Grouping Framework extension, 17 'BUNDLE'. The extension can be used with the Session Description 18 Protocol (SDP) Offer/Answer mechanism to negotiate the usage of a 19 single 5-tuple for sending and receiving media associated with 20 multiple SDP media descriptions ("m="). This is referred to as 21 bundled media. 23 Both endpoints can negotiate the use of bundle and to support that 24 negotiations, this specification defines a new SDP attribute, 25 'bundle-only', which can be used to request that specific media is 26 only used if bundled. This specification also updates sections 5.1, 27 8.1 and 8.2 of RFC 3264 to allows an answerer to assign a non-zero 28 port value to an "m=" line in an SDP answer, even if the "m=" line in 29 the associated SDP offer contained a zero port value. 31 There are multiple ways to correlate the bundled RTP packets with the 32 appropriate media descriptions. This specification defines a new RTP 33 SDES item and a new RTP header extension that provides an additional 34 way to do this correlation by using them to carry a value that 35 associates the RTP/RTCP packets with a specific media description. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 12, 2015. 54 Copyright Notice 56 Copyright (c) 2014 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 75 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7 76 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 7 78 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 6.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 7. SDP Information Considerations . . . . . . . . . . . . . . . 8 81 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 7.2. Connection Data (c=) . . . . . . . . . . . . . . . . . . 8 83 7.3. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 8 84 7.4. Attributes (a=) . . . . . . . . . . . . . . . . . . . . . 9 85 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9 86 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 10 88 8.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 89 8.2.2. Request offerer BUNDLE address selection . . . . . . 10 90 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 10 91 8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 92 8.3.2. Answerer Selection of Offerer Bundle Address . . . . 11 93 8.3.3. Answerer Selection of Answerer BUNDLE Address . . . . 12 94 8.3.4. Moving A Media Description Out Of A BUNDLE Group . . 12 95 8.3.5. Rejecting A Media Description In A BUNDLE Group . . . 13 96 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 13 97 8.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 98 8.4.2. Bundle Address Synchronization (BAS) . . . . . . . . 13 99 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 14 100 8.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 14 101 8.5.2. Request a new offerer BUNDLE address . . . . . . . . 15 102 8.5.3. Adding a media description to a BUNDLE group . . . . 15 103 8.5.4. Moving A Media Description Out Of A BUNDLE Group . . 16 104 8.5.5. Disabling A Media Description In A BUNDLE Group . . . 16 105 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 17 106 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 107 9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17 108 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 18 109 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 18 110 10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 18 111 10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 18 112 10.2. Associating RTP/RTCP Packets With Correct SDP Media 113 Description . . . . . . . . . . . . . . . . . . . . . . 19 114 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19 115 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19 116 10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20 117 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22 118 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22 119 11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 22 120 11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 22 121 11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 22 122 11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 22 123 11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 23 124 11.2.5. Modifying the Session . . . . . . . . . . . . . . . 23 125 12. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 23 126 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 23 127 12.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 23 128 12.3. New text replacing section 5.1 (2nd paragraph) of RFC 129 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 130 12.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 24 131 12.5. New text replacing section 8.2 (2nd paragraph) of RFC 132 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 133 12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 24 134 12.7. New text replacing section 8.4 (6th paragraph) of RFC 135 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 136 13. RTP/RTCP extensions for mid value transport . . . . . . . . . 25 137 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 25 138 13.2. RTP MID SDES Item . . . . . . . . . . . . . . . . . . . 26 139 13.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 26 140 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 141 14.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 26 142 14.2. New RTP Header Extension URI . . . . . . . . . . . . . . 27 143 14.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 27 144 15. Security Considerations . . . . . . . . . . . . . . . . . . . 27 145 16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 28 146 16.1. Example: Bundle Address Selection . . . . . . . . . . . 28 147 16.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 29 148 16.3. Example: Offerer Adds A Media Description To A BUNDLE 149 Group . . . . . . . . . . . . . . . . . . . . . . . . . 30 150 16.4. Example: Offerer Moves A Media Description Out Of A 151 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 32 152 16.5. Example: Offerer Disables A Media Description Within A 153 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35 154 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 155 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 156 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 37 157 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 158 20.1. Normative References . . . . . . . . . . . . . . . . . . 40 159 20.2. Informative References . . . . . . . . . . . . . . . . . 41 160 Appendix A. Design Considerations . . . . . . . . . . . . . . . 42 161 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 42 162 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 42 163 A.3. Usage of port number value zero . . . . . . . . . . . . . 44 164 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 44 165 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 45 166 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 45 167 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 45 168 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 170 1. Introduction 172 This specification defines a way to use a single 5-tuple for sending 173 and receiving media associated with multiple SDP media descriptions 174 ("m=" lines) . This allows the usage of a single set of Interactive 175 Connectivity Establishment (ICE) [RFC5245] candidates for multiple 176 media descriptions. 178 This specification defines a new SDP Grouping Framework [RFC5888] 179 extension called 'BUNDLE'. The extension can be used with the 180 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 181 to negotiate the usage of a single 5-tuple for sending and receiving 182 media associated with multiple SDP media descriptions ("m="). This 183 is referred to as bundled media. 185 The offerer and answerer [RFC3264] use the BUNDLE extension to 186 negotiate the 5-tuples (BUNDLE addresses), one for the offerer 187 (offerer BUNDLE address) and one for the answerer (answerer BUNDLE 188 address) to be used for the bundled media associated with a BUNDLE 189 group. Once the offerer and the answerer have negotiated a BUNDLE 190 group, they assign their respective BUNDLE address to each "m=" line 191 in the BUNDLE group. The BUNDLE address is used to send and receive 192 all media associated with the BUNDLE group. 194 This specification also defines a new SDP attribute, 'bundle-only', 195 which can be used to request that specific media is only used if 196 bundled. 198 As defined in RFC 4566 [RFC4566], the semantics of assigning the same 199 port value to multiple "m=" lines are undefined, and there is no 200 grouping defined by such means. Instead, an explicit grouping 201 mechanism needs to be used to express the intended semantics. This 202 specification provides such an extension. 204 This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 205 [RFC3264]. The update allows an answerer to assign a non-zero port 206 value to an "m=" line in an SDP answer, even if the "m=" line in the 207 associated SDP offer contained a zero port value. 209 This specification also defines a new RTP SDES item and a new RTP 210 header extension that can be used to carry a value that associates 211 RTP/RTCP packets with a specific media description. This can be used 212 to correlate a RTP packet with the correct media. 214 SDP bodies can contain multiple BUNDLE groups. A given BUNDLE 215 address MUST only be associated with a single BUNDLE group. The 216 procedures in this specification apply independently to a given 217 BUNDLE group. All Real-time Transport Protocol (RTP) [RFC3550] based 218 media flows associated with a single BUNDLE group belong to a single 219 RTP session [RFC3550]. 221 The BUNDLE extension is backward compatible. Endpoints that do not 222 support the extension are expected to generate offers and answers 223 without an SDP 'group:BUNDLE' attribute, and are expected to assign a 224 unique address to each "m=" line within an offer and answer, 225 according to the procedures in [RFC4566] and [RFC3264] 227 2. Terminology 229 5-tuple: A collection of the following values: source address, source 230 port, destination address, destination port, and protocol. 232 Unique address: An IP address and IP port combination that is 233 assigned to only one "m=" line in an offer or answer. 235 Shared address: An IP address and IP port combination that is 236 assigned to multiple "m=" lines within an offer or answer. 238 Offerer suggested BUNDLE mid: The first mid value in a given SDP 239 'group:BUNDLE' attribute mid list in an offer. 241 Answerer selected BUNDLE mid: The first mid value in a given SDP 242 'group:BUNDLE' attribute mid list in an answer. 244 Offerer BUNDLE address: Within a given BUNDLE group, an IP address 245 and IP port combination used by an offerer to receive all media 246 associated with each "m=" line within the BUNDLE group. 248 Answerer BUNDLE address: Within a given BUNDLE group, an IP address 249 and IP port combination used by an answerer to receive all media 250 associated with each "m=" line within the BUNDLE group. 252 BUNDLE group: A set of "m=" lines, created using an SDP Offer/Answer 253 exchange, for which each endpoint uses a single 5-tuple to send and 254 receive media. Each endpoint uses its BUNDLE address, associated 255 with the BUNDLE group, to send and receive the media. 257 Bundled "m=" line: An "m=" line, whose SDP 'mid' attribute value is 258 placed in a SDP 'group:BUNDLE' attribute mid value list in an offer 259 or answer. 261 Bundle-only "m=" line: A bundled "m=" line with an associated SDP 262 'bundle-only' attribute. 264 Bundled media: All media associated with a given BUNDLE group. 266 Initial offer: The first offer, within an SDP session, in which the 267 offerer indicates that it wants to create a given BUNDLE group. 269 Subsequent offer: An offer which contains a BUNDLE group that has 270 been created as part of a previous SDP Offer/Answer exchange. 272 3. Conventions 274 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 275 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 276 document are to be interpreted as described in BCP 14, RFC 2119 277 [RFC2119]. 279 4. Applicability Statement 281 The mechanism in this specification only applies to the Session 282 Description Protocol (SDP) [RFC4566], when used together with the SDP 283 Offer/Answer mechanism [RFC3264]. 285 5. SDP Grouping Framework BUNDLE Extension 287 5.1. General 289 This section defines a new SDP Grouping Framework extension 290 [RFC5888], 'BUNDLE'. The BUNDLE extension can be used with the 291 Session Description Protocol (SDP) Offer/Answer mechanism to 292 negotiate the usage of a single 5-tuple for sending and receiving 293 media, referred to as bundled media, associated with multiple SDP 294 media descriptions ("m=" lines). Within a successfully created 295 BUNDLE group, media described with "m=" lines associated with the 296 BUNDLE group will be sent and received using a single 5-tuple. 298 The BUNDLE extension is indicated using an SDP 'group' attribute with 299 a "BUNDLE" semantics value [RFC5888]. An SDP "mid" attribute is 300 assigned to each bundled "m=" line, and the "mid" attribute value is 301 listed in the 'group:BUNDLE' attribute mid value list. Each "m=" 302 line, whose mid value is listed in the mid value list, is associated 303 with a given BUNDLE group. 305 SDP bodies can contain multiple BUNDLE groups. Any given bundled 306 "m=" line MUST NOT be associated with more than one BUNDLE group. 308 [Section 8] defines the detailed SDP Offer/Answer procedures for the 309 BUNDLE extension. 311 6. SDP 'bundle-only' Attribute 313 6.1. General 315 This section defines a new SDP media-level attribute [RFC4566], 316 'bundle-only'. 318 The 'bundle-only' attribute can be associated with a bundled "m=" 319 line in an offer, to request that the answerer only accepts the "m=" 320 line if the answerer keeps the "m=" line within the associated BUNDLE 321 group. In order to ensure that an answerer that does not supports 322 the BUNDLE extension always rejects a 'bundle-only' "m=" line, the 323 offerer can assign a zero port value to the "m=" line. According to 324 [RFC4566] an answerer will reject such "m=" line. The usage of the 325 'bundle-only' attribute is only defined for a bundled "m=" line 326 within an offer. Other usage is unspecified. 328 [Section 8] defines the detailed SDP Offer/Answer procedures for the 329 'bundle-only' attribute. 331 6.2. Syntax 333 This section defines the Augmented Backus-Naur Form (ABNF) [RFC5234] 334 for the SDP 'bundle-only' attribute, based on the SDP [RFC4566] 335 grammar. 337 attribute =/ bundle-only-attribute 339 bundle-only-attribute = "bundle-only" 341 7. SDP Information Considerations 343 7.1. General 345 This section describes restrictions associated with the usage of SDP 346 parameters within a BUNDLE group. It also describes, when parameter 347 and attribute values have been assigned to each bundled "m=" line, 348 how to calculate a value for the whole BUNDLE group. 350 7.2. Connection Data (c=) 352 The "c=" line nettype value [RFC4566] assigned to a bundled "m=" line 353 MUST be 'IN'. 355 The "c=" line addrtype value [RFC4566] assigned to a bundled "m=" 356 line MUST be 'IP4' or 'IP6'. The same value MUST be assigned to each 357 "m=" line. 359 NOTE: Extensions to this specification can specify usage of the 360 BUNDLE mechanism for other nettype and addrtype values than the ones 361 listed above. 363 7.3. Bandwidth (b=) 365 The proposed bandwidth for a bundled "m=" line SHOULD be calculated 366 in the same way as for a non-bundled "m=" line. 368 The total proposed bandwidth for a BUNDLE group is the sum of the 369 proposed bandwidth for each bundled "m=" line. 371 The total proposed bandwidth for an offer or answer is the sum of the 372 proposed bandwidth for each "m=" line (bundled and non-bundled) 373 within the offer or answer. 375 7.4. Attributes (a=) 377 An offerer and answerer MUST use the rules and restrictions defined 378 in [I-D.mmusic-sdp-mux-attributes] for when associating SDP 379 attributes with bundled "m=" lines. 381 8. SDP Offer/Answer Procedures 383 8.1. General 385 This section describes the SDP Offer/Answer [RFC3264] procedures for: 387 o Negotiating and creating of a BUNDLE group; 389 o Selecting the BUNDLE addresses (offerer BUNDLE address and 390 answerer BUNDLE address); 392 o Adding an "m=" line to a BUNDLE group; 394 o Moving an "m=" line out of a BUNDLE group; and 396 o Disabling an "m=" line within a BUNDLE group. 398 The generic rules and procedures defined in [RFC3264] and [RFC5888] 399 also apply to the BUNDLE extension. For example, if an offer is 400 rejected by the answerer, the previously negotiated SDP parameters 401 and characteristics (including those associated with a BUNDLE group) 402 apply. Hence, if an offerer generates an offer in which the offerer 403 wants to create a BUNDLE group, and the answerer rejects the offer, 404 the BUNDLE group is not created. 406 The procedures in this section are independent of the media type or 407 transport protocol represented by a bundled "m=" line. [Section 10] 408 defines additional considerations for RTP based media. [Section 6] 409 defines additional considerations for the usage of the SDP 'bundle- 410 only' attribute. [Section 11] defines additional considerations for 411 the usage of Interactive Connectivity Establishment (ICE) mechanism 412 [RFC5245]. 414 The offerer and answerer MUST follow the rules and restrictions 415 defined in [Section 7] when creating offers and answers. 417 SDP bodies can contain multiple BUNDLE groups. The procedures in 418 this section apply independently to a given BUNDLE group. 420 8.2. Generating the Initial SDP Offer 422 8.2.1. General 424 When an offerer generates an initial offer, in order to create a 425 BUNDLE group, it MUST: 427 o Assign a unique address to each "m=" line within the offer, 428 following the procedures in [RFC3264]; 430 o Assign an SDP 'group:BUNDLE' attribute to the offer; 432 o Place the SDP 'mid' attribute value [RFC5888] of each bundled "m=" 433 line to the SDP 'group:BUNDLE' attribute mid value list; and 435 o Indicate which unique address the offerer wants the answerer to 436 select as the offerer BUNDLE address [Section 8.2.2]. 438 If the offerer wants to request that the answerer accepts a given 439 "m=" line only if the answerer keeps the "m=" line within the BUNDLE 440 group, the offerer MUST: 442 o Associate an SDP 'bundle-only' attribute [Section 8.2.2] with the 443 "m=" line; and 445 o Assign a zero port value to the "m=" line. 447 NOTE: If the offerer assigns a zero port value to an "m=" line, but 448 does not also associate an SDP 'bundle-only' attribute with the "m=" 449 line, it is an indication that the offerer wants to disable the "m=" 450 line [Section 8.5.5]. 452 [Section 16.1] shows an example of an initial offer. 454 8.2.2. Request offerer BUNDLE address selection 456 In the offer, the address assigned to the "m=" line associated with 457 the offerer suggested BUNDLE mid indicates the address that the 458 offerer wants the answer to select as the offerer BUNDLE address 459 [Section 8.3.2]. 461 8.3. Generating the SDP Answer 463 8.3.1. General 465 When an answerer generates an answer, which contains a BUNDLE group, 466 the following general SDP grouping framework restrictions, defined in 467 [RFC5888], also apply to the BUNDLE group: 469 o The answerer MUST NOT include a BUNDLE group in the answer, unless 470 the offerer requested the BUNDLE group to be created in the 471 associated offer; and 473 o The answerer MUST NOT include an "m=" line within a BUNDLE group, 474 unless the offerer requested the "m=" line to be within that 475 BUNDLE group in the associated offer. 477 If the answer contains a BUNDLE group, the answerer MUST: 479 o Select an Offerer BUNDLE Address [Section 8.3.2]; and 481 o Select an Answerer BUNDLE Address [Section 8.3.3]; 483 The answerer is allowed to select a new Answerer BUNDLE address each 484 time it generates an answer to an offer. 486 If the answerer does not want to keep an "m=" line within a BUNDLE 487 group, it MUST: 489 o Move the "m=" line out of the BUNDLE group [Section 8.3.4]; or 491 o Reject the "m=" line [Section 8.3.5]; 493 If the answerer keeps a bundle-only "m=" line within the BUNDLE 494 group, it follows the procedures (assigns the answerer BUNDLE address 495 to the "m=" line etc) for any other "m=" line kept within the BUNDLE 496 group. 498 If the answerer does not want to keep a bundle-only "m=" line within 499 the BUNDLE group, it MUST reject the "m=" line [Section 8.3.5]. 501 The answerer MUST NOT include a 'bundle-only' attribute in an answer. 503 NOTE: If a bundled "m=" line in an offer contains a port zero value, 504 but the "m=" line does not contain an SDP 'bundle-only' attribute, it 505 is an indication that the offerer wants to disable the "m=" line 506 [Section 8.5.5]. 508 8.3.2. Answerer Selection of Offerer Bundle Address 510 In an offer, the address (unique or shared) assigned to the bundled 511 "m=" line associated with the offerer suggested BUNDLE mid indicates 512 the address that the offerer wants the answer to select as the 513 offerer BUNDLE address [Section 8.2.2]. The answerer MUST check 514 whether the "m=" line fulfils the following criteria: 516 o The answerer will not move the "m=" line out of the BUNDLE group 517 [Section 8.3.4]; 519 o The answerer will not reject the "m=" line [Section 8.3.5]; and 521 o The "m=" line does not contain a zero port value. 523 If all of the criteria above is fulfilled, the answerer MUST select 524 the address associated with the "m=" line as the offerer BUNDLE 525 address. In the answer, the answerer selected BUNDLE mid represents 526 the "m=" line, and the address associated with the "m=" line in the 527 offer becomes the offerer BUNDLE address. 529 If all of the criteria is not fulfilled, the answerer MUST select the 530 next mid value in the mid list, and perform the same criteria check 531 for the "m=" line associated with that mid value. If there are no 532 more mid values in the mid list, the answerer MUST NOT create the 533 BUNDLE group. 535 [Section 16.1] shows an example of an offerer BUNDLE address 536 selection. 538 8.3.3. Answerer Selection of Answerer BUNDLE Address 540 When the answerer selects a BUNDLE address for itself, referred to as 541 the answerer BUNDLE address, it MUST assign the address to each 542 bundled "m=" line within the created BUNDLE group in the answer. 544 The answerer MUST NOT assign the answerer BUNDLE address to an "m=" 545 line that is not within the BUNDLE group, or to an "m=" line that is 546 within another BUNDLE group. 548 [Section 16.1] shows an example of an answerer BUNDLE address 549 selection. 551 8.3.4. Moving A Media Description Out Of A BUNDLE Group 553 When an answerer moves a "m=" line out of a BUNDLE group, it assigns 554 an address to the "m=" line in the answer based on the following 555 rules: 557 o In the associated offer, if the "m=" line contains a shared 558 address (e.g. a previously selected offerer BUNDLE address), the 559 answerer MUST reject the moved "m=" line [Section 8.3.5]; 561 o In the associated offer, if the "m=" line contains a unique 562 address, the answerer MUST assign a unique address to the "m=" 563 line in the answer; or 565 o In the associated offer, if the "m=" line contains an SDP 'bundle- 566 only' attribute the answerer MUST reject the "m=" line 567 [Section 8.3.5]. 569 In addition, in either case above, the answerer MUST NOT include a 570 mid value, associated with the moved "m=" line, in the SDP 571 'group:BUNDLE' attribute mid list associated with the BUNDLE group. 573 8.3.5. Rejecting A Media Description In A BUNDLE Group 575 When an answerer rejects an "m=" line, it MUST assign an address with 576 a zero port value to the "m=" line in the answer, according to the 577 procedures in [RFC4566]. 579 In addition, the answerer MUST NOT include a mid value, associated 580 with the rejected "m=" line, in the SDP 'group:BUNDLE' attribute mid 581 list associated with the BUNDLE group. 583 8.4. Offerer Processing of the SDP Answer 585 8.4.1. General 587 When an offerer receives an answer, if the answer contains a BUNDLE 588 group, the offerer MUST check that any bundled "m=" line in the 589 answer was indicated as bundled in the associated offer. If there is 590 no mismatch, the offerer MUST apply the offerer BUNDLE address, 591 selected by the answerer [Section 8.3.2], to each bundled "m=" line. 593 NOTE: As the answerer might reject one or more bundled "m=" lines, or 594 move a bundled "m=" line out of a BUNDLE group, each bundled "m=" 595 line in the offer might not be indicated as bundled in the answer. 597 If the answer does not contain a BUNDLE group, the offerer MUST 598 process the answer as a normal answer. 600 8.4.2. Bundle Address Synchronization (BAS) 602 When an offerer receives an answer, if the answer contains a BUNDLE 603 group, the offerer MUST check whether the offerer BUNDLE address, 604 selected by the answerer [Section 8.3.2], matches what was assigned 605 to each bundled "m=" line (excluding any bundled "m=" line that was 606 rejected, or moved out of the BUNDLE group, by the answer) in the 607 associated offer. If there is a mismatch, the offerer SHOULD as soon 608 as possible generate a subsequent offer, in which it assigns the 609 offerer BUNDLE address to each bundled "m=" line. Such offer is 610 referred to as a Bundle Address Synchronization (BAS) offer. 612 A BAS offer is typically sent in the following scenarios: 614 o The offerer receives an answer to an initial offer, as the bundled 615 "m=" lines in the initial offer always contain unique addresses 616 [Section 8.2]; or 618 o The offerer receives an answer to an offer, in which a new bundled 619 "m=" line has been added to the BUNDLE group [Section 8.5.3], and 620 the offerer assigned a unique address to the bundled "m=" line in 621 the offer. 623 The offerer is allowed to modify any SDP parameter in the BAS offer. 625 NOTE: It is important that the BAS offer gets accepted by the 626 answerer. For that reason the offerer needs to consider the 627 necessity to modify SDP parameters in the BAS offer, in such a way 628 that could trigger the answerer to reject the BAS offer. Disabling 629 "m=" lines, or reducing the number of codecs, in a BAS offer is 630 considered to have a low risk of being rejected. 632 NOTE: The main purpose of the BAS offer is to ensure that 633 intermediaries, that might not support the BUNDLE extension, have 634 correct information regarding the address is going to be used to 635 transport the bundled media. 637 [Section 16.1] shows an example of a BAS offer. 639 8.5. Modifying the Session 641 8.5.1. General 643 When an offerer generates a subsequent offer, it MUST assign the 644 previously selected offerer BUNDLE address [Section 8.3.2], to each 645 bundled "m=" line (including any bundle-only "m=" line), with the 646 following exceptions: 648 o The offerer wants to request the answerer to select a new offerer 649 BUNDLE address [Section 8.5.2]; 651 o The offerer wants to add a bundled "m=" line to the BUNDLE group 652 [Section 8.5.3]; 654 o The offerer wants to move a bundled "m=" line out of the BUNDLE 655 group [Section 8.5.4]; or 657 o The offerer wants to disable the bundled "m=" line 658 [Section 8.5.5]. 660 In addition, the offerer MUST select an offerer suggested BUNDLE mid 661 [Section 8.2.2], even if the offerer does not want the answerer to 662 select a new offerer BUNDLE address. 664 If the offerer associates an SDP 'bundle-only' attribute with a 665 bundled "m=" line in the subsequent offer, if MUST assign the offerer 666 BUNDLE address to the "m=" line. The offerer MUST NOT assign a 667 unique address, or a zero port value, to a bundle-only "m=" line in a 668 subsequent offer. 670 NOTE: The offerer can associate an SDP 'bundle-only' attribute with a 671 bundled "m=" line in a subsequent offer, even if the offerer did not 672 associate a 'bundle-only' attribute with the same "m=" line in a 673 previous offer. 675 8.5.2. Request a new offerer BUNDLE address 677 When an offerer generates an offer, in which it wants the answerer to 678 select a new offerer BUNDLE address [Section 8.2.2], the offerer 679 MUST: 681 o Assign a unique address, which the offerer wants the answerer to 682 select as the offerer BUNDLE address, to a bundled "m=" line; and 684 o Indicate that the offerer wants the answerer to select the unique 685 address as the offerer BUNDLE address [Section 8.2.2] 687 NOTE: The offerer can assign a unique address to each bundled "m=" 688 line in the offer, or it can assign the previously negotiated offerer 689 BUNDLE address to each "m=" line (except the "m=" line to which it 690 assigns the unique address that it wants the answerer to select as 691 the new offerer BUNDLE address). 693 8.5.3. Adding a media description to a BUNDLE group 695 When an offerer generates an offer, in which it wants to add a 696 bundled "m=" line to BUNDLE group, the offerer MUST: 698 o Assign a unique address (excluding bundle-only "m=" lines), or the 699 offerer BUNDLE address (selected by the answerer in a previous 700 offer/answer transaction), to the "m=" line; 702 o Place the SDP 'mid' attribute value associated with the "m=" line 703 in the SDP 'group:BUNDLE' attribute mid list associated with the 704 BUNDLE group [Section 8.2.2]. 706 NOTE: Adding a unique address to the "m=" line allows the answerer to 707 move the "m=" line out of the BUNDLE group [Section 8.3.4], without 708 having to reject the "m=" line. 710 If the offerer wants the answerer to select the address associated 711 with the added "m=" line as the new offerer BUNDLE address, the 712 offerer suggested BUNDLE mid MUST represent the added "m=" line 713 [Section 8.2.2]. 715 If the offerer associates an SDP 'bundle-only' attribute with the 716 added "m=" line, the offerer MUST assign the offerer BUNDLE address 717 (selected by the answerer in a previous offer/answer transaction) to 718 the "m=" line. 720 [Section 16.3] shows an example where an offerer sends an offer in 721 order to add a bundled "m=" line to a BUNDLE group. 723 8.5.4. Moving A Media Description Out Of A BUNDLE Group 725 When an offerer generates an offer, in which it wants to move a 726 bundled "m=" line out of a BUNDLE group it was added to in a previous 727 offer/answer transaction, the offerer: 729 o MUST assign a unique address to the "m=" line; 731 o MUST NOT place a mid value associated with the "m=" line in the 732 SDP 'group:BUNDLE' attribute mid list associated with that BUNDLE 733 group; and 735 o MUST NOT associate an SDP 'bundle-only' attribute with the "m=" 736 line. 738 NOTE: If an "m=" line, when being moved out of a BUNDLE group, is 739 added to another BUNDLE group, the offerer applies the procedures in 740 [Section 8.5.3] to the "m=" line. 742 [Section 16.4] shows an example of an offer for moving an "m=" line 743 out of a BUNDLE group. 745 8.5.5. Disabling A Media Description In A BUNDLE Group 747 When an offerer generates an offer, in which it wants to disable a 748 bundled "m=" line (added to the BUNDLE group in a previous offer/ 749 answer transaction), the offerer: 751 o MUST assign an address with a zero port value to the "m=" line, 752 following the procedures in [RFC4566]; 754 o MUST NOT place a mid value associated with the "m=" line in the 755 SDP 'group:BUNDLE' attribute mid list associated with the BUNDLE 756 group; and 758 o MUST NOT associate an SDP 'bundle-only' attribute with the "m=" 759 line. 761 [Section 16.5] shows an example of an offer for disabling an "m=" 762 line within a BUNDLE group. 764 9. Protocol Identification 766 9.1. General 768 If bundled "m=" lines represent different transport protocols, there 769 MUST exist a publicly available specification which describes a 770 mechanism for this specific transport protocol combination that 771 describes how to associate a received packet with the correct 772 transport protocol. 774 In addition, if a received packet can be associated with more than 775 one bundled "m=" line, there MUST exist a publically available 776 specification which describes a mechanism for associating the 777 received packet with the correct "m=" line. 779 9.2. STUN, DTLS, SRTP 781 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 782 protocol among the STUN, DTLS and SRTP protocols (in any 783 combination). If an offer or answerer in offers or answers include 784 bundled "m=" lines that represent these protocols, the offerer or 785 answerer MUST support the mechanism described in [RFC5764], and no 786 explicit negotiation is required in order to indicate support and 787 usage of the mechanism. 789 [RFC5764] does not describe how to identify different protocols 790 transported on DTLS, only how to identify the DTLS protocol itself. 791 If multiple protocols are transported on DTLS, there MUST exist a 792 specification describing a mechanism for identify each individual 793 protocol. In addition, if a received DTLS packet can be associated 794 with more than one "m=" line, there MUST exist a specification which 795 describes a mechanism for associating the received DTLS packet with 796 the correct "m=" line. 798 [Section 10.2] describes how to associate a received (S)RTP packet 799 with the correct "m=" line. 801 10. RTP Considerations 803 10.1. Single RTP Session 805 10.1.1. General 807 All RTP-based media within a single BUNDLE group belong to a single 808 RTP session [RFC3550]. Disjoint BUNDLE groups will form multiple RTP 809 sessions, one per BUNDLE group. 811 Since a single RTP session is used for each bundle group, all "m=" 812 lines representing RTP-based media in a bundle group will share a 813 single SSRC numbering space [RFC3550]. 815 The following rules and restrictions apply for a single RTP session: 817 o A specific payload type value can be used in multiple bundled "m=" 818 lines if each codec associated with the payload type number shares 819 an identical codec configuration [Section 10.1.2]. 821 o The "proto" value in each bundled "m=" line MUST be identical 822 (e.g. RTP/AVPF). 824 o A given SSRC SHOULD NOT transmit RTP packets using payload types 825 that originate from different bundled "m=" lines. 827 NOTE: The last bullet above is to avoid sending multiple media types 828 from the same SSRC. If transmission of multiple media types are done 829 with time overlap, RTP and RTCP fail to function. Even if done in 830 proper sequence this causes RTP Timestamp rate switching issues 831 [RFC7160]. 833 10.1.2. Payload Type (PT) Value Reuse 835 Multiple bundled "m=" lines might represent RTP based media. As all 836 RTP based media associated with a BUNDLE group belong to the same RTP 837 session, in order for a given payload type value to used inside more 838 than one bundled "m=" line, all codecs associated with the payload 839 type numbers MUST share an identical codec configuration. This means 840 that the codecs MUST share the same media type, encoding name, clock 841 rate and any parameter that can affect the codec configuration and 842 packetization. [I-D.mmusic-sdp-mux-attributes] lists SDP attributes, 843 whose attribute values must be identical for all codecs that use the 844 same payload type value. 846 10.2. Associating RTP/RTCP Packets With Correct SDP Media Description 848 In general, there are multiple mechanisms that can be used by an 849 endpoint in order to associate received RTP/RTCP packets with the 850 bundled "m=" line representing the RTP packets. Such mechanisms 851 include using the local address:port combination on which the RTP 852 packets are received, the payload type value carried inside the RTP 853 packets, the SSRC values carried inside the RTP packets, and other 854 "m=" line specific information carried inside the RTP packets. 856 As all RTP/RTCP packets associated with a BUNDLE group are sent and 857 received using the same 5-tuple, the local address:port combination 858 cannot be used to associate received RTP packets with the correct 859 "m=" line. 861 As described in [Section 10.1.2], the same payload type value might 862 be used inside RTP packets described by multiple "m=" lines. In such 863 cases, the payload type value cannot be used to associate received 864 RTP packets with the correct "m=" line. 866 An offerer and answerer can in an offer and answer inform each other 867 which SSRC values they will use inside sent RTP/RTCP packets, by 868 assigning an SDP 'ssrc' attribute [RFC5576] to each bundled "m=" line 869 which contains a payload type value that is also used inside another 870 bundled "m=" line. As the SSRC values will be carried inside the 871 RTP/RTCP packets, the offerer and answerer can then use that 872 information to associate received RTP packets with the correct "m=" 873 line. However, an offerer will not know which SSRC values the 874 answerer will use until it has received the answer providing that 875 information. Due to this, before the offerer has received the 876 answer, the offerer will not be able to associate received RTP/RTCP 877 packets with the correct "m=" line using the SSRC values. 879 In order for an offerer and answerer to always be able to associate 880 received RTP and RTCP packets with the correct "m=" line, an offerer 881 and answerer using the BUNDLE extension MUST support the mechanism 882 defined in [Section 13], where the remote endpoint inserts the SDP 883 'mid' attribute value of an "m=" line in RTP and RTCP packets 884 associated with that "m=" line. 886 10.3. RTP/RTCP Multiplexing 888 10.3.1. General 890 When a BUNDLE group, which contains RTP based media, is created, the 891 offerer and answerer MUST negotiate whether to enable RTP/RTCP 892 multiplexing for the RTP based media associated with the BUNDLE group 893 [RFC5761]. 895 If RTP/RTCP multiplexing is not enabled, separate 5-tuples will be 896 used for sending and receiving the RTP packets and the RTCP packets. 898 10.3.2. SDP Offer/Answer Procedures 900 10.3.2.1. General 902 This section describes how an offerer and answerer can use the SDP 903 'rtcp-mux' attribute [RFC5761] and the SDP 'rtcp' attribute [RFC3605] 904 to negotiate usage of RTP/RTCP multiplexing for RTP based media 905 associated with a BUNDLE group. 907 10.3.2.2. Generating the Initial SDP Offer 909 When an offerer generates an initial offer, if the offerer wants to 910 negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, the 911 offerer MUST assign an SDP 'rtcp-mux' attribute [RFC5761] to each 912 bundled "m=" line (including any bundle-only "m=" line) in the offer. 913 In addition, the offerer MUST assign an SDP 'rtcp' attribute 914 [RFC3605] to each bundled "m=" line (including any bundle-only "m=" 915 line), with an attribute value that is identical to the port value 916 assigned to the "m=" line itself, in the offer. 918 If the offerer does not want to negotiate usage of RTP/RTCP 919 multiplexing, it MUST NOT assign the SDP attributes above to any 920 bundled "m=" line. 922 10.3.2.3. Generating the SDP Answer 924 When an answerer generates an answer, if the offerer indicated 925 support of RTP/RTCP multiplexing [RFC5761] within a BUNDLE group in 926 the associated offer, the answerer MUST either accept or reject the 927 usage of RTP/RTCP multiplexing in the answer. 929 If the answerer accepts usage of RTP/RTCP multiplexing within the 930 BUNDLE group, it MUST assign an SDP 'rtcp-mux' attribute to each 931 bundled "m=" line in the answer. The answerer MUST NOT assign an SDP 932 'rtcp' attribute to any bundled "m=" line in the answer. The 933 answerer will use the port number of the selected offerer BUNDLE 934 address for sending RTP and RTCP packets associated with each bundled 935 "m=" line towards the offerer. 937 If the answerer rejects usage of RTP/RTCP multiplexing within the 938 BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp' 939 attribute to any bundled "m=" line in the answer. The answerer will, 940 based on the port number of the selected offerer BUNDLE address, use 941 the next higher (odd) destination port number [RFC3550] for sending 942 RTCP packets associated with each bundled "m=" line towards the 943 offerer. 945 If the usage of RTP/RTCP multiplexing has been negotiated in a 946 previous offer/answer transaction, and the offerer indicates that it 947 wants to continue using RTP/RTCP multiplexing in a subsequent offer, 948 the answerer MUST assign an SDP 'rtcp-mux' attribute to each bundled 949 "m=" line in the answer. I.e. the answerer MUST NOT disable the 950 usage of RTP/RTCP multiplexing. 952 10.3.2.4. Offerer Processing of the SDP Answer 954 When the offerer receives an answer, if the answerer accepts the 955 usage of RTP/RTCP multiplexing, by including an SDP 'rtcp-mux' 956 attribute to each bundled "m=" line in the answer [Section 10.3.2.3], 957 the answerer follows the procedures for RTP/RTCP multiplexing defined 958 in [RFC5761]. The offerer will use the port number of the answerer 959 BUNDLE address for sending RTP and RTCP packets associated with each 960 bundled "m=" line towards the answerer. 962 If the answerer does not accept the usage of RTP/RTCP multiplexing 963 [Section 10.3.2.3], the offerer MUST use separate 5-tuples for RTP 964 and RTCP. The offerer will, based on the port number of the answerer 965 BUNDLE address, use the next higher (odd) destination port number 966 [RFC3550] for sending RTCP packets associated with a bundled "m=" 967 line towards the answerer. 969 10.3.2.5. Modifying the Session 971 When an offerer generates a subsequent offer, if it wants to 972 negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, or if 973 it wants to continue usage of RTP/RTCP multiplexing (negotiated in a 974 previous offer/answer transaction), it MUST assign SDP 'rtcp-mux' and 975 'rtcp' attributes to each bundled "m=" line (including bundle-only 976 "m=" lines, and a bundled "m=" line that the offerer wants to add to 977 the BUNDLE group), unless the offerer wants to disable or remove the 978 "m=" line from the BUNDLE group. 980 If the offerer does not want to negotiate usage of RTP/RTCP 981 multiplexing within the BUNDLE group, or if it wants to disable usage 982 of RTP/RTCP multiplexing (negotiated in a previous offer/answer 983 transaction), the offerer MUST NOT assign SDP 'rtcp-mux' and 'rtcp' 984 attributes to any bundled "m=" line in the subsequent offer. 986 NOTE: It is RECOMMENDED that, once usage of RTP/RTCP multiplexing has 987 been negotiated within a BUNDLE group, that the usage is not 988 disabled. Disabling RTP/RTCP multiplexing means that the offerer and 989 answerer need to reserve new IP ports, to be used for sending and 990 receiving RTCP packets. 992 11. ICE Considerations 994 11.1. General 996 This section describes how to use the BUNDLE grouping extension 997 together with the Interactive Connectivity Establishment (ICE) 998 mechanism [RFC5245]. 1000 The procedures defined in [RFC5245] also apply to usage of ICE with 1001 BUNDLE, with the following exception: 1003 o When BUNDLE addresses for a BUNDLE group have been selected for 1004 both endpoints, ICE connectivity checks and keep-alives only need 1005 to be performed for the whole BUNDLE group, instead of per bundled 1006 "m=" line. 1008 Support and usage of ICE mechanism together with the BUNDLE extension 1009 is OPTIONAL. 1011 11.2. SDP Offer/Answer Procedures 1013 11.2.1. General 1015 When an offerer or answerer assigns a unique address to a bundled 1016 "m=" line (excluding bundle-only "m=" lines), it MUST also assign 1017 unique ICE candidates [RFC5245] to the "m=" line. 1019 When an offerer or answerer assigns a shared address (i.e. a 1020 previously selected BUNDLE address) to one or more bundled "m=" line 1021 (including bundle-only "m=" lines), and when it assigns an address 1022 with a zero port value to one or more bundle-only "m=" lines, it MUST 1023 assign identical ICE candidates (referred to as shared ICE 1024 candidates) to each of those "m=" lines. 1026 11.2.2. Generating the Initial SDP Offer 1028 When an offerer generates an initial offer, it assigns unique or 1029 shared ICE candidates to the bundled "m=" lines, according to 1030 [Section 11.1]. 1032 11.2.3. Generating the SDP Answer 1034 When an answerer generates an answer, which contains a BUNDLE group, 1035 the answerer MUST assign shared ICE candidates to each bundled "m=" 1036 line (including "m=" lines that were indicated as bundle-only in the 1037 associated offer) in the answer. 1039 11.2.4. Offerer Processing of the SDP Answer 1041 When an offerer receives an answer, if the answerer supports and uses 1042 the ICE mechanism and the BUNDLE extension, the offerer MUST assign 1043 the ICE candidates, associated with the "m=" line representing the 1044 offerer BUNDLE address (selected by the answerer) to each bundled 1045 "m=" line. 1047 11.2.5. Modifying the Session 1049 When an offerer generates a subsequent offer, it assigns unique or 1050 shared ICE candidates to the bundled "m=" lines, according to 1051 [Section 11.1]. 1053 12. Update to RFC 3264 1055 12.1. General 1057 This section replaces the text of the following sections of RFC 3264: 1059 o Section 5.1 (Unicast Streams). 1061 o Section 8.2 (Removing a Media Stream). 1063 o Section 8.4 (Putting a Unicast Media Stream on Hold). 1065 12.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 1067 For recvonly and sendrecv streams, the port number and address in the 1068 offer indicate where the offerer would like to receive the media 1069 stream. For sendonly RTP streams, the address and port number 1070 indirectly indicate where the offerer wants to receive RTCP reports. 1071 Unless there is an explicit indication otherwise, reports are sent to 1072 the port number one higher than the number indicated. The IP address 1073 and port present in the offer indicate nothing about the source IP 1074 address and source port of RTP and RTCP packets that will be sent by 1075 the offerer. A port number of zero in the offer indicates that the 1076 stream is offered but MUST NOT be used. This has no useful semantics 1077 in an initial offer, but is allowed for reasons of completeness, 1078 since the answer can contain a zero port indicating a rejected stream 1079 (Section 6). Furthermore, existing streams can be terminated by 1080 setting the port to zero (Section 8). In general, a port number of 1081 zero indicates that the media stream is not wanted. 1083 12.3. New text replacing section 5.1 (2nd paragraph) of RFC 3264 1085 For recvonly and sendrecv streams, the port number and address in the 1086 offer indicate where the offerer would like to receive the media 1087 stream. For sendonly RTP streams, the address and port number 1088 indirectly indicate where the offerer wants to receive RTCP reports. 1089 Unless there is an explicit indication otherwise, reports are sent to 1090 the port number one higher than the number indicated. The IP address 1091 and port present in the offer indicate nothing about the source IP 1092 address and source port of RTP and RTCP packets that will be sent by 1093 the offerer. A port number of zero in the offer by default indicates 1094 that the stream is offered but MUST NOT be used, but an extension 1095 mechanism might specify different semantics for the usage of a zero 1096 port value. Furthermore, existing streams can be terminated by 1097 setting the port to zero (Section 8). In general, a port number of 1098 zero by default indicates that the media stream is not wanted. 1100 12.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 1102 A stream that is offered with a port of zero MUST be marked with port 1103 zero in the answer. Like the offer, the answer MAY omit all 1104 attributes present previously, and MAY list just a single media 1105 format from amongst those in the offer. 1107 12.5. New text replacing section 8.2 (2nd paragraph) of RFC 3264 1109 A stream that is offered with a port of zero MUST by default be 1110 marked with port zero in the answer, unless an extension mechanism, 1111 which specifies semantics for the usage of a non-zero port value, is 1112 used. If the stream is marked with port zero in the answer, the 1113 answer MAY omit (like the offer) all attributes present previously, 1114 and MAY list just a single media format from amongst those in the 1115 offer." 1117 12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 1119 RFC 2543 [10] specified that placing a user on hold was accomplished 1120 by setting the connection address to 0.0.0.0. Its usage for putting 1121 a call on hold is no longer recommended, since it doesn't allow for 1122 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1123 with connection oriented media. However, it can be useful in an 1124 initial offer when the offerer knows it wants to use a particular set 1125 of media streams and formats, but doesn't know the addresses and 1126 ports at the time of the offer. Of course, when used, the port 1127 number MUST NOT be zero, which would specify that the stream has been 1128 disabled. An agent MUST be capable of receiving SDP with a 1129 connection address of 0.0.0.0, in which case it means that neither 1130 RTP nor RTCP should be sent to the peer. 1132 12.7. New text replacing section 8.4 (6th paragraph) of RFC 3264 1134 RFC 2543 [10] specified that placing a user on hold was accomplished 1135 by setting the connection address to 0.0.0.0. Its usage for putting 1136 a call on hold is no longer recommended, since it doesn't allow for 1137 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1138 with connection oriented media. However, it can be useful in an 1139 initial offer when the offerer knows it wants to use a particular set 1140 of media streams and formats, but doesn't know the addresses and 1141 ports at the time of the offer. Of course, when used, the port 1142 number MUST NOT be zero, if it would specify that the stream has been 1143 disabled. However, an extension mechanism might specify different 1144 semantics of the zero port number usage. An agent MUST be capable of 1145 receiving SDP with a connection address of 0.0.0.0, in which case it 1146 means that neither RTP nor RTCP should be sent to the peer. 1148 13. RTP/RTCP extensions for mid value transport 1150 13.1. General 1152 SDP Offerers and Answerers [RFC3264] can assign mid values to SDP 1153 Media Descriptions (m= lines) within SDP Offers and Answers, using 1154 the procedures in [RFC5888]. Each mid value uniquely identifies an 1155 m= line. 1157 This section defines a new RTP SDES item [RFC3550], 'MID', which is 1158 used to carry mid values within RTCP SDES packets. This section also 1159 defines a new RTP header extension [RFC5285], which can be used to 1160 carry the mid value in RTP packets. 1162 The SDES item and RTP header extension makes is possible for a 1163 receiver to associate received RTCP- and RTP packets with a specific 1164 m= line, to which the receiver has assigned a mid value, even if 1165 those m= lines are part of the same RTP session. The endpoint 1166 informs the remote endpoint about the mid values using the procedures 1167 in [RFC5888], and the remote endpoint then inserts the mid values in 1168 RTCP- and RTP packets sent towards the other endpoint. 1170 NOTE: This text above defines how the mid value is carried in SDP 1171 Offers and Answers. The usage of other signalling protocols for 1172 carrying the mid value is not prevented, but the usage of such 1173 protocols is outside the scope of this document. 1175 [RFC3550] defines general procedures regarding the RTCP transmission 1176 interval. The RTP MID SDES item SHOULD be sent in the first few RTCP 1177 packets sent on joining the session, and SHOULD be sent regularly 1178 thereafter. The exact number of RTCP packets in which this SDES item 1179 is sent is intentionally not specified here, as it will depend on the 1180 expected packet loss rate, the RTCP reporting interval, and the 1181 allowable overhead. 1183 The RTP MID header extension SHOULD be included in some RTP packets 1184 at the start of the session and whenever the SSRC changes. It might 1185 also be useful to include the header extension in RTP packets that 1186 comprise random access points in the media (e.g., with video 1187 I-frames). The exact number of RTP packets in which this header 1188 extension is sent is intentionally not specified here, as it will 1189 depend on expected packet loss rate and loss patterns, the overhead 1190 the application can tolerate, and the importance of immediate receipt 1191 of the mid value. 1193 For robustness purpose, endpoints need to be prepared for situations 1194 where the mid value is delayed, and SHOULD NOT terminate sessions in 1195 such cases, as the mid value is likely to arrive soon. 1197 13.2. RTP MID SDES Item 1199 0 1 2 3 1200 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 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | MID=TBD | length | mid value ... 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 The mid value payload is UTF-8 encoded, as in SDP. 1207 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1208 identifier value.] 1210 13.3. RTP MID Header Extension 1212 The payload, containing the mid value, of the RTP MID header 1213 extension element can be encoded using either the one-byte or two- 1214 byte header [RFC5285]. The mid value payload is UTF-8 encoded, as in 1215 SDP. 1217 14. IANA Considerations 1219 14.1. New SDES item 1221 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1222 document.] 1224 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1225 identifier value.] 1226 This document adds the MID SDES item to the IANA "RTP SDES item 1227 types" registry as follows: 1229 Value: TBD 1230 Abbrev.: MID 1231 Name: Media Identification 1232 Reference: RFCXXXX 1234 14.2. New RTP Header Extension URI 1236 This document defines a new extension URI in the RTP Compact Header 1237 Extensions subregistry of the Real-Time Transport Protocol (RTP) 1238 Parameters registry, according to the following data: 1240 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1241 Description: Media identification 1242 Contact: christer.holmberg@ericsson.com 1243 Reference: RFCXXXX 1245 14.3. New SDP Attribute 1247 This document defines a new SDP media-level attribute, according to 1248 the following data: 1250 Attribute name: bundle-only 1251 Type of attribute: Media-level 1252 Subject to charset: No 1253 Purpose: Request a media description to be accepted 1254 in the answer only if kept within a BUNDLE group 1255 by the answerer 1256 Appropriate values: N/A 1257 Contact name: Christer Holmberg 1258 Contact e-mail: christer.holmberg@ericsson.com 1260 15. Security Considerations 1262 The security considerations defined in [RFC3264] and [RFC5888] apply 1263 to the BUNDLE extension. Bundle does not change which information 1264 flows over the network but only changes which ports that information 1265 if flowing on and thus has very little impact on the security of the 1266 RTP sessions. 1268 When the BUNDLE extension is used, a single set of security 1269 credentials might be used for all media streams associated with a 1270 BUNDLE group. 1272 When the BUNDLE extension is used, the number of SSRC values within a 1273 single RTP session increases, which increases the risk of SSRC 1274 collision. [RFC4568] describes how SSRC collision may weaken SRTP 1275 and SRTCP encryption in certain situations. 1277 16. Examples 1279 16.1. Example: Bundle Address Selection 1281 The example below shows: 1283 o 1. An offer, in which the offerer assigns a unique address to 1284 each bundled "m=" line within the BUNDLE group. 1286 o 2. An answer, in which the answerer selects the offerer BUNDLE 1287 address, and in which selects its own BUNDLE address (the answerer 1288 BUNDLE address) and assigns it each bundled "m=" line within the 1289 BUNDLE group. 1291 o 3. A subsequent offer (BAS offer), which is used to perform a 1292 Bundle Address Synchronization (BAS). 1294 SDP Offer (1) 1296 v=0 1297 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1298 s= 1299 c=IN IP4 atlanta.example.com 1300 t=0 0 1301 a=group:BUNDLE foo bar 1302 m=audio 10000 RTP/AVP 0 8 97 1303 a=mid:foo 1304 b=AS:200 1305 a=rtpmap:0 PCMU/8000 1306 a=rtpmap:8 PCMA/8000 1307 a=rtpmap:97 iLBC/8000 1308 m=video 10002 RTP/AVP 31 32 1309 a=mid:bar 1310 b=AS:1000 1311 a=rtpmap:31 H261/90000 1312 a=rtpmap:32 MPV/90000 1314 SDP Answer (2) 1316 v=0 1317 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1318 s= 1319 c=IN IP4 biloxi.example.com 1320 t=0 0 1321 a=group:BUNDLE foo bar 1322 m=audio 20000 RTP/AVP 0 1323 a=mid:foo 1324 b=AS:200 1325 a=rtpmap:0 PCMU/8000 1326 m=video 20000 RTP/AVP 32 1327 a=mid:bar 1328 b=AS:1000 1329 a=rtpmap:32 MPV/90000 1331 SDP Offer (3) 1333 v=0 1334 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1335 s= 1336 c=IN IP4 atlanta.example.com 1337 t=0 0 1338 a=group:BUNDLE foo bar 1339 m=audio 10000 RTP/AVP 0 8 97 1340 a=mid:foo 1341 b=AS:200 1342 a=rtpmap:0 PCMU/8000 1343 a=rtpmap:8 PCMA/8000 1344 a=rtpmap:97 iLBC/8000 1345 m=video 10000 RTP/AVP 31 32 1346 a=mid:bar 1347 b=AS:1000 1348 a=rtpmap:31 H261/90000 1349 a=rtpmap:32 MPV/90000 1351 16.2. Example: BUNDLE Extension Rejected 1353 The example below shows: 1355 o 1. An offer, in which the offerer assigns a unique address to 1356 each bundled "m=" line within the BUNDLE group. 1358 o 2. An answer, in which the answerer rejects the offered BUNDLE 1359 group, and assigns a unique addresses to each "m=" line (following 1360 normal RFC 3264 procedures). 1362 SDP Offer (1) 1364 v=0 1365 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1366 s= 1367 c=IN IP4 atlanta.example.com 1368 t=0 0 1369 a=group:BUNDLE foo bar 1370 m=audio 10000 RTP/AVP 0 8 97 1371 a=mid:foo 1372 b=AS:200 1373 a=rtpmap:0 PCMU/8000 1374 a=rtpmap:8 PCMA/8000 1375 a=rtpmap:97 iLBC/8000 1376 m=video 10002 RTP/AVP 31 32 1377 a=mid:bar 1378 b=AS:1000 1379 a=rtpmap:31 H261/90000 1380 a=rtpmap:32 MPV/90000 1382 SDP Answer (2) 1384 v=0 1385 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1386 s= 1387 c=IN IP4 biloxi.example.com 1388 t=0 0 1389 m=audio 20000 RTP/AVP 0 1390 b=AS:200 1391 a=rtpmap:0 PCMU/8000 1392 m=video 30000 RTP/AVP 32 1393 b=AS:1000 1394 a=rtpmap:32 MPV/90000 1396 16.3. Example: Offerer Adds A Media Description To A BUNDLE Group 1398 The example below shows: 1400 o 1. An offer, in which the offerer adds a new "m=" line, 1401 represented by the "zen" mid value, to a previously negotiated 1402 BUNDLE group, assigns a unique address to the added "m=" line, and 1403 assigns the previously selected offerer BUNDLE address to each of 1404 the other bundled "m=" lines within the BUNDLE group. 1406 o 2. An answer, in which the answerer assigns the answerer BUNDLE 1407 address to each bundled "m=" line (including the newly added "m=" 1408 line) within the BUNDLE group. 1410 o 3. A subsequent offer (BAS offer), which is used to perform a 1411 Bundle Address Synchronization (BAS). 1413 SDP Offer (1) 1415 v=0 1416 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1417 s= 1418 c=IN IP4 atlanta.example.com 1419 t=0 0 1420 a=group:BUNDLE foo bar zen 1421 m=audio 10000 RTP/AVP 0 8 97 1422 a=mid:foo 1423 b=AS:200 1424 a=rtpmap:0 PCMU/8000 1425 a=rtpmap:8 PCMA/8000 1426 a=rtpmap:97 iLBC/8000 1427 m=video 10000 RTP/AVP 31 32 1428 a=mid:bar 1429 b=AS:1000 1430 a=rtpmap:31 H261/90000 1431 a=rtpmap:32 MPV/90000 1432 m=video 20000 RTP/AVP 66 1433 a=mid:zen 1434 b=AS:1000 1435 a=rtpmap:66 H261/90000 1437 SDP Answer (2) 1439 v=0 1440 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1441 s= 1442 c=IN IP4 biloxi.example.com 1443 t=0 0 1444 a=group:BUNDLE foo bar zen 1445 m=audio 20000 RTP/AVP 0 1446 a=mid:foo 1447 b=AS:200 1448 a=rtpmap:0 PCMU/8000 1449 m=video 20000 RTP/AVP 32 1450 a=mid:bar 1451 b=AS:1000 1452 a=rtpmap:32 MPV/90000 1453 m=video 20000 RTP/AVP 66 1454 a=mid:zen 1455 b=AS:1000 1456 a=rtpmap:66 H261/90000 1458 SDP Offer (3) 1460 v=0 1461 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1462 s= 1463 c=IN IP4 atlanta.example.com 1464 t=0 0 1465 a=group:BUNDLE foo bar zen 1466 m=audio 10000 RTP/AVP 0 8 97 1467 a=mid:foo 1468 b=AS:200 1469 a=rtpmap:0 PCMU/8000 1470 a=rtpmap:8 PCMA/8000 1471 a=rtpmap:97 iLBC/8000 1472 m=video 10000 RTP/AVP 31 32 1473 a=mid:bar 1474 b=AS:1000 1475 a=rtpmap:31 H261/90000 1476 a=rtpmap:32 MPV/90000 1477 m=video 10000 RTP/AVP 66 1478 a=mid:zen 1479 b=AS:1000 1480 a=rtpmap:66 H261/90000 1482 16.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 1484 The example below shows: 1486 o 1. An offer, in which the offerer moves a bundled "m=" line out 1487 of a BUNDLE group, assigns a unique address to the moved "m=" 1488 line, and assigns the offerer BUNDLE address to each other bundled 1489 "m=" line within the BUNDLE group. 1491 o 2. An answer, in which the answerer moves the "m=" line out of 1492 the BUNDLE group, assigns unique address to the moved "m=" line, 1493 and assigns the answerer BUNDLE address to each other bundled "m=" 1494 line within the BUNDLE group. 1496 SDP Offer (1) 1498 v=0 1499 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1500 s= 1501 c=IN IP4 atlanta.example.com 1502 t=0 0 1503 a=group:BUNDLE foo bar 1504 m=audio 10000 RTP/AVP 0 8 97 1505 a=mid:foo 1506 b=AS:200 1507 a=rtpmap:0 PCMU/8000 1508 a=rtpmap:8 PCMA/8000 1509 a=rtpmap:97 iLBC/8000 1510 m=video 10000 RTP/AVP 31 32 1511 a=mid:bar 1512 b=AS:1000 1513 a=rtpmap:31 H261/90000 1514 a=rtpmap:32 MPV/90000 1515 m=video 50000 RTP/AVP 66 1516 b=AS:1000 1517 a=rtpmap:66 H261/90000 1519 SDP Answer (2) 1521 v=0 1522 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1523 s= 1524 c=IN IP4 biloxi.example.com 1525 t=0 0 1526 a=group:BUNDLE foo bar 1527 m=audio 20000 RTP/AVP 0 1528 a=mid:foo 1529 b=AS:200 1530 a=rtpmap:0 PCMU/8000 1531 m=video 20000 RTP/AVP 32 1532 a=mid:bar 1533 b=AS:1000 1534 a=rtpmap:32 MPV/90000 1535 m=video 60000 RTP/AVP 66 1536 b=AS:1000 1537 a=rtpmap:66 H261/90000 1539 16.5. Example: Offerer Disables A Media Description Within A BUNDLE 1540 Group 1542 The example below shows: 1544 o 1. An offer, in which the offerer disables a bundled "m=" line 1545 within BUNDLE group, assigns a zero port number the disabled "m=" 1546 line, and assigns the offerer BUNDLE address to each of the other 1547 bundled "m=" lines within the BUNDLE group. 1549 o 2. An answer, in which the answerer moves the disabled "m=" line 1550 out of the BUNDLE group, assigns a zero port value to the disabled 1551 "m=" line, and assigns the answerer BUNDLE address to each of the 1552 other bundled "m=" lines within the BUNDLE group. 1554 SDP Offer (1) 1556 v=0 1557 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1558 s= 1559 c=IN IP4 atlanta.example.com 1560 t=0 0 1561 a=group:BUNDLE foo bar 1562 m=audio 10000 RTP/AVP 0 8 97 1563 a=mid:foo 1564 b=AS:200 1565 a=rtpmap:0 PCMU/8000 1566 a=rtpmap:8 PCMA/8000 1567 a=rtpmap:97 iLBC/8000 1568 m=video 10000 RTP/AVP 31 32 1569 a=mid:bar 1570 b=AS:1000 1571 a=rtpmap:31 H261/90000 1572 a=rtpmap:32 MPV/90000 1573 m=video 0 RTP/AVP 66 1574 a=rtpmap:66 H261/90000 1576 SDP Answer (2) 1578 v=0 1579 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1580 s= 1581 c=IN IP4 biloxi.example.com 1582 t=0 0 1583 a=group:BUNDLE foo bar 1584 m=audio 20000 RTP/AVP 0 1585 a=mid:foo 1586 b=AS:200 1587 a=rtpmap:0 PCMU/8000 1588 m=video 20000 RTP/AVP 32 1589 a=mid:bar 1590 b=AS:1000 1591 a=rtpmap:32 MPV/90000 1592 m=video 0 RTP/AVP 66 1593 a=rtpmap:66 H261/90000 1595 17. IANA Considerations 1597 This document requests IANA to register the new SDP Grouping semantic 1598 extension called BUNDLE. 1600 18. Acknowledgements 1602 The usage of the SDP grouping extension for negotiating bundled media 1603 is based on a similar alternatives proposed by Harald Alvestrand and 1604 Cullen Jennings. The BUNDLE extension described in this document is 1605 based on the different alternative proposals, and text (e.g. SDP 1606 examples) have been borrowed (and, in some cases, modified) from 1607 those alternative proposals. 1609 The SDP examples are also modified versions from the ones in the 1610 Alvestrand proposal. 1612 Thanks to Paul Kyzivat, Martin Thomson and Flemming Andreasen for 1613 taking the time to read the text along the way, and providing useful 1614 feedback. 1616 19. Change Log 1618 [RFC EDITOR NOTE: Please remove this section when publishing] 1620 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 1622 o Editorial corrections based on comments from Harald Alvestrand. 1624 o Editorial corrections based on comments from Cullen Jennings. 1626 o Reference update (RFC 7160). 1628 o Clarification about RTCP packet sending when RTP/RTCP multiplexing 1629 is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ 1630 msg13765.html). 1632 o Additional text added to the Security Considerations. 1634 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 1636 o SDP bundle-only attribute added to IANA Considerations. 1638 o SDES item and RTP header extension added to Abstract and 1639 Introduction. 1641 o Modification to text updating section 8.2 of RFC 3264. 1643 o Reference corrections. 1645 o Editorial corrections. 1647 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 1649 o Terminology change: "bundle-only attribute assigned to m= line" to 1650 "bundle-only attribute associated with m= line". 1652 o Editorial corrections. 1654 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 1656 o Editorial corrections. 1658 o - "of"->"if" (8.3.2.5). 1660 o - "optional"->"OPTIONAL" (9.1). 1662 o - Syntax/ABNF for 'bundle-only' attribute added. 1664 o - SDP Offer/Answer sections merged. 1666 o - 'Request new offerer BUNDLE address' section added 1668 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 1670 o OPEN ISSUE regarding Receiver-ID closed. 1672 o - RTP MID SDES Item. 1674 o - RTP MID Header Extension. 1676 o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers 1677 closed. 1679 o - Indicating that, when rtcp-mux is used, the answerer MUST NOT 1680 include an 'rtcp' attribute in the answer, based on the procedures 1681 in section 5.1.3 of RFC 5761. 1683 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 1685 o Draft title changed. 1687 o Added "SDP" to section names containing "Offer" or "Answer". 1689 o Editorial fixes based on comments from Paul Kyzivat 1690 (http://www.ietf.org/mail-archive/web/mmusic/current/ 1691 msg13314.html). 1693 o Editorial fixed based on comments from Colin Perkins 1694 (http://www.ietf.org/mail-archive/web/mmusic/current/ 1695 msg13318.html). 1697 o - Removed text about extending BUNDLE to allow multiple RTP 1698 sessions within a BUNDLE group. 1700 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 1702 o Major re-structure of SDP Offer/Answer sections, to align with RFC 1703 3264 structure. 1705 o Additional definitions added. 1707 o - Shared address. 1709 o - Bundled "m=" line. 1711 o - Bundle-only "m=" line. 1713 o - Offerer suggested BUNDLE mid. 1715 o - Answerer selected BUNDLE mid. 1717 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 1718 to multiple "m=" lines until it has received an SDP Answer 1719 indicating support of the BUNDLE extension. 1721 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 1722 Answerer supports the BUNDLE extension, assign a zero port value 1723 to a 'bundle-only' "m=" line. 1725 o SDP 'bundle-only' attribute section added. 1727 o Connection data nettype/addrtype restrictions added. 1729 o RFC 3264 update section added. 1731 o Indicating that a specific payload type value can be used in 1732 multiple "m=" lines, if the value represents the same codec 1733 configuration in each "m=" line. 1735 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 1736 o Updated Offerer procedures (http://www.ietf.org/mail- 1737 archive/web/mmusic/current/msg12293.html). 1739 o Updated Answerer procedures (http://www.ietf.org/mail- 1740 archive/web/mmusic/current/msg12333.html). 1742 o Usage of SDP 'bundle-only' attribute added. 1744 o Reference to Trickle ICE document added. 1746 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 1748 o Mechanism modified, to be based on usage of SDP Offers with both 1749 different and identical port number values, depending on whether 1750 it is known if the remote endpoint supports the extension. 1752 o Cullen Jennings added as co-author. 1754 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 1756 o No changes. New version due to expiration. 1758 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 1760 o No changes. New version due to expiration. 1762 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 1764 o Draft name changed. 1766 o Harald Alvestrand added as co-author. 1768 o "Multiplex" terminology changed to "bundle". 1770 o Added text about single versus multiple RTP Sessions. 1772 o Added reference to RFC 3550. 1774 20. References 1776 20.1. Normative References 1778 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1779 Requirement Levels", BCP 14, RFC 2119, March 1997. 1781 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1782 with Session Description Protocol (SDP)", RFC 3264, June 1783 2002. 1785 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1786 Description Protocol", RFC 4566, July 2006. 1788 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1789 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1791 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 1792 Header Extensions", RFC 5285, July 2008. 1794 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1795 Control Packets on a Single Port", RFC 5761, April 2010. 1797 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1798 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1800 [I-D.mmusic-sdp-mux-attributes] 1801 Nandakumar, S., "A Framework for SDP Attributes when 1802 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-02 1803 (work in progress), July 2014. 1805 20.2. Informative References 1807 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1808 Jacobson, "RTP: A Transport Protocol for Real-Time 1809 Applications", STD 64, RFC 3550, July 2003. 1811 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1812 in Session Description Protocol (SDP)", RFC 3605, October 1813 2003. 1815 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1816 Description Protocol (SDP) Security Descriptions for Media 1817 Streams", RFC 4568, July 2006. 1819 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1820 (ICE): A Protocol for Network Address Translator (NAT) 1821 Traversal for Offer/Answer Protocols", RFC 5245, April 1822 2010. 1824 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1825 Media Attributes in the Session Description Protocol 1826 (SDP)", RFC 5576, June 2009. 1828 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1829 Security (DTLS) Extension to Establish Keys for the Secure 1830 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1832 [RFC7160] Petit-Huguenin, M. and G. Zorn, "Support for Multiple 1833 Clock Rates in an RTP Session", RFC 7160, April 2014. 1835 [I-D.ietf-mmusic-trickle-ice] 1836 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 1837 Incremental Provisioning of Candidates for the Interactive 1838 Connectivity Establishment (ICE) Protocol", draft-ietf- 1839 mmusic-trickle-ice-01 (work in progress), February 2014. 1841 Appendix A. Design Considerations 1843 A.1. General 1845 One of the main issues regarding the BUNDLE grouping extensions has 1846 been whether, in SDP Offers and SDP Answers, the same port number 1847 value should be inserted in "m=" lines associated with a BUNDLE 1848 group, as the purpose of the extension is to negotiate the usage of a 1849 single 5-tuple for media associated with the "m=" lines. Issues with 1850 both approaches, discussed in the Appendix have been raised. The 1851 outcome was to specify a mechanism which uses SDP Offers with both 1852 different and identical port number values. 1854 Below are the primary issues that have been considered when defining 1855 the "BUNDLE" grouping extension: 1857 o 1) Interoperability with existing UAs. 1859 o 2) Interoperability with intermediary B2BUA- and proxy entities. 1861 o 3) Time to gather, and the number of, ICE candidates. 1863 o 4) Different error scenarios, and when they occur. 1865 o 5) SDP Offer/Answer impacts, including usage of port number value 1866 zero. 1868 NOTE: Before this document is published as an RFC, this 1869 Appendix might be removed. 1871 A.2. UA Interoperability 1873 Consider the following SDP Offer/Answer exchange, where Alice sends 1874 an SDP Offer to Bob: 1876 SDP Offer 1878 v=0 1879 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1880 s= 1881 c=IN IP4 atlanta.example.com 1882 t=0 0 1883 m=audio 10000 RTP/AVP 97 1884 a=rtpmap:97 iLBC/8000 1885 m=video 10002 RTP/AVP 97 1886 a=rtpmap:97 H261/90000 1888 SDP Answer 1890 v=0 1891 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1892 s= 1893 c=IN IP4 biloxi.example.com 1894 t=0 0 1895 m=audio 20000 RTP/AVP 97 1896 a=rtpmap:97 iLBC/8000 1897 m=video 20002 RTP/AVP 97 1898 a=rtpmap:97 H261/90000 1900 RFC 4961 specifies a way of doing symmetric RTP but that is an a 1901 later invention to RTP and Bob can not assume that Alice supports RFC 1902 4961. This means that Alice may be sending RTP from a different port 1903 than 10000 or 10002 - some implementation simply send the RTP from an 1904 ephemeral port. When Bob's endpoint receives an RTP packet, the only 1905 way that Bob know if it should be passed to the video or audio codec 1906 is by looking at the port it was received on. This lead some SDP 1907 implementations to use the fact that each "m=" line had a different 1908 port number to use that port number as an index to find the correct m 1909 line in the SDP. As a result, some implementations that do support 1910 symmetric RTP and ICE still use a SDP data structure where SDP with 1911 "m=" lines with the same port such as: 1913 SDP Offer 1915 v=0 1916 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1917 s= 1918 c=IN IP4 atlanta.example.com 1919 t=0 0 1920 m=audio 10000 RTP/AVP 97 1921 a=rtpmap:97 iLBC/8000 1922 m=video 10000 RTP/AVP 98 1923 a=rtpmap:98 H261/90000 1925 will result in the second "m=" line being considered an SDP error 1926 because it has the same port as the first line. 1928 A.3. Usage of port number value zero 1930 In an SDP Offer or SDP Answer, the media associated with an "m=" line 1931 can be disabled/rejected by setting the port number value to zero. 1932 This is different from e.g. using the SDP direction attributes, where 1933 RTCP traffic will continue even if the SDP "inactive" attribute is 1934 indicated for the associated "m=" line. 1936 If each "m=" line associated with a BUNDLE group would contain 1937 different port number values, and one of those port would be used for 1938 the 5-tuple, problems would occur if an endpoint wants to disable/ 1939 reject the "m=" line associated with that port, by setting the port 1940 number value to zero. After that, no "m=" line would contain the 1941 port number value which is used for the 5-tuple. In addition, it is 1942 unclear what would happen to the ICE candidates associated with the 1943 "m=" line, as they are also used for the 5-tuple. 1945 A.4. B2BUA And Proxy Interoperability 1947 Some back to back user agents may be configured in a mode where if 1948 the incoming call leg contains an SDP attribute the B2BUA does not 1949 understand, the B2BUS still generates that SDP attribute in the Offer 1950 for the outgoing call leg. Consider an B2BUA that did not understand 1951 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 1952 Further assume that the B2BUA was configured to tear down any call 1953 where it did not see any RTCP for 5 minutes. In this cases, if the 1954 B2BUA received an Offer like: 1956 SDP Offer 1958 v=0 1959 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1960 s= 1961 c=IN IP4 atlanta.example.com 1962 t=0 0 1963 m=audio 49170 RTP/AVP 0 1964 a=rtcp:53020 1966 It would be looking for RTCP on port 49172 but would not see any 1967 because the RTCP would be on port 53020 and after five minutes, it 1968 would tear down the call. Similarly, an SBC that did not understand 1969 BUNDLE yet put BUNDLE in it's offer may be looking for media on the 1970 wrong port and tear down the call. It is worth noting that a B2BUA 1971 that generated an Offer with capabilities it does not understand is 1972 not compliant with the specifications. 1974 A.4.1. Traffic Policing 1976 Sometimes intermediaries do not act as B2BUA, in the sense that they 1977 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 1978 however, they may use SDP information (e.g. IP address and port) in 1979 order to control traffic gating functions, and to set traffic 1980 policing rules. There might be rules which will trigger a session to 1981 be terminated in case media is not sent or received on the ports 1982 retrieved from the SDP. This typically occurs once the session is 1983 already established and ongoing. 1985 A.4.2. Bandwidth Allocation 1987 Sometimes intermediaries do not act as B2BUA, in the sense that they 1988 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 1989 however, they may use SDP information (e.g. codecs and media types) 1990 in order to control bandwidth allocation functions. The bandwidth 1991 allocation is done per "m=" line, which means that it might not be 1992 enough if media associated with all "m=" lines try to use that 1993 bandwidth. That may either simply lead to bad user experience, or to 1994 termination of the call. 1996 A.5. Candidate Gathering 1998 When using ICE, an candidate needs to be gathered for each port. 1999 This takes approximately 20 ms extra for each extra "m=" line due to 2000 the NAT pacing requirements. All of this gather can be overlapped 2001 with other things while the page is loading to minimize the impact. 2003 If the client only wants to generate TURN or STUN ICE candidates for 2004 one of the "m=" lines and then use trickle ICE 2005 [I-D.ietf-mmusic-trickle-ice] to get the non host ICE candidates for 2006 the rest of the "m=" lines, it MAY do that and will not need any 2007 additional gathering time. 2009 Some people have suggested a TURN extension to get a bunch of TURN 2010 allocation at once. This would only provide a single STUN result so 2011 in cases where the other end did not support BUNDLE, may cause more 2012 use of the TURN server but would be quick in the cases where both 2013 sides supported BUNDLE and would fall back to a successful call in 2014 the other cases. 2016 Authors' Addresses 2018 Christer Holmberg 2019 Ericsson 2020 Hirsalantie 11 2021 Jorvas 02420 2022 Finland 2024 Email: christer.holmberg@ericsson.com 2026 Harald Tveit Alvestrand 2027 Google 2028 Kungsbron 2 2029 Stockholm 11122 2030 Sweden 2032 Email: harald@alvestrand.no 2034 Cullen Jennings 2035 Cisco 2036 400 3rd Avenue SW, Suite 350 2037 Calgary, AB T2P 4H2 2038 Canada 2040 Email: fluffy@iii.ca