idnits 2.17.1 draft-ietf-mmusic-sdp-bundle-negotiation-18.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 (March 9, 2015) is 3307 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 1211 ** 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-08 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 2 errors (**), 0 flaws (~~), 2 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: September 10, 2015 C. Jennings 7 Cisco 8 March 9, 2015 10 Negotiating Media Multiplexing Using the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-bundle-negotiation-18.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, associated with 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. This 26 specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 to 27 allow an answerer to assign a non-zero port value to an "m=" line in 28 an SDP answer, even if the "m=" line in the associated SDP offer 29 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 33 RTCP source description (SDES) item and a new RTP header extension 34 that provides an additional way to do this correlation by using them 35 to carry a value that associates the RTP/RTCP packets with a specific 36 media description. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on September 10, 2015. 55 Copyright Notice 57 Copyright (c) 2015 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 76 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7 77 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 7 78 7. SDP Information Considerations . . . . . . . . . . . . . . . 8 79 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 7.2. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9 81 7.3. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9 82 7.4. Attributes (a=) . . . . . . . . . . . . . . . . . . . . . 9 83 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9 84 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 10 86 8.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 87 8.2.2. Suggesting the offerer BUNDLE address . . . . . . . . 11 88 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 11 89 8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 11 90 8.3.2. Answerer Selection of Offerer Bundle Address . . . . 12 91 8.3.3. Answerer Selection of Answerer BUNDLE Address . . . . 13 92 8.3.4. Moving A Media Description Out Of A BUNDLE Group . . 13 93 8.3.5. Rejecting A Media Description In A BUNDLE Group . . . 13 94 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 14 95 8.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 14 96 8.4.2. Bundle Address Synchronization (BAS) . . . . . . . . 14 97 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 15 98 8.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 15 99 8.5.2. Suggesting a new offerer BUNDLE address . . . . . . . 15 100 8.5.3. Adding a media description to a BUNDLE group . . . . 16 101 8.5.4. Moving A Media Description Out Of A BUNDLE Group . . 17 102 8.5.5. Disabling A Media Description In A BUNDLE Group . . . 17 103 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 17 104 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 105 9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 18 106 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 18 107 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 18 108 10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 18 109 10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 19 110 10.2. Associating RTP/RTCP Packets With Correct SDP Media 111 Description . . . . . . . . . . . . . . . . . . . . . . 19 112 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 20 113 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 20 114 10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20 115 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 23 116 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 23 117 11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 23 118 11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23 119 11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 24 120 11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 24 121 11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 24 122 11.2.5. Modifying the Session . . . . . . . . . . . . . . . 24 123 12. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24 124 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 24 125 12.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 25 126 12.3. New text replacing section 5.1 (2nd paragraph) of RFC 127 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 128 12.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 25 129 12.5. New text replacing section 8.2 (2nd paragraph) of RFC 130 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 131 12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 26 132 12.7. New text replacing section 8.4 (6th paragraph) of RFC 133 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 134 13. RTP/RTCP extensions for identification-tag transport . . . . 26 135 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 26 136 13.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 27 137 13.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 28 138 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 139 14.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 28 140 14.2. New RTP Header Extension URI . . . . . . . . . . . . . . 29 141 14.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 29 142 15. Security Considerations . . . . . . . . . . . . . . . . . . . 29 143 16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 30 144 16.1. Example: Bundle Address Selection . . . . . . . . . . . 30 145 16.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 32 146 16.3. Example: Offerer Adds A Media Description To A BUNDLE 147 Group . . . . . . . . . . . . . . . . . . . . . . . . . 33 148 16.4. Example: Offerer Moves A Media Description Out Of A 149 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36 150 16.5. Example: Offerer Disables A Media Description Within A 151 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 37 152 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 153 18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39 154 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 155 19.1. Normative References . . . . . . . . . . . . . . . . . . 44 156 19.2. Informative References . . . . . . . . . . . . . . . . . 44 157 Appendix A. Design Considerations . . . . . . . . . . . . . . . 45 158 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45 159 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 46 160 A.3. Usage of port number value zero . . . . . . . . . . . . . 47 161 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 47 162 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 48 163 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 48 164 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 49 165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 167 1. Introduction 169 This specification defines a way to use a single address:port 170 combination (BUNDLE address) for receiving media associated with 171 multiple SDP media descriptions ("m=" lines). 173 This specification defines a new SDP Grouping Framework [RFC5888] 174 extension called 'BUNDLE'. The extension can be used with the 175 Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] 176 to negotiate the usage of a BUNDLE group. Within the BUNDLE group, a 177 BUNDLE address is used for receiving media associated with multiple 178 "m=" lines. This is referred to as bundled media. 180 The offerer and answerer [RFC3264] use the BUNDLE extension to 181 negotiate the BUNDLE addresses, one for the offerer (offerer BUNDLE 182 address) and one for the answerer (answerer BUNDLE address), to be 183 used for receiving the bundled media associated with a BUNDLE group. 184 Once the offerer and the answerer have negotiated a BUNDLE group, 185 they assign their respective BUNDLE address to each "m=" line in the 186 BUNDLE group. The BUNDLE addresses are used to receive all media 187 associated with the BUNDLE group. 189 The use of a BUNDLE group and a BUNDLE address also allows the usage 190 of a single set of Interactive Connectivity Establishment (ICE) 191 [RFC5245] candidates for multiple "m=" lines. 193 This specification also defines a new SDP attribute, 'bundle-only', 194 which can be used to request that specific media is only used if kept 195 within a BUNDLE group. 197 As defined in RFC 4566 [RFC4566], the semantics of assigning the same 198 port value to multiple "m=" lines are undefined, and there is no 199 grouping defined by such means. Instead, an explicit grouping 200 mechanism needs to be used to express the intended semantics. This 201 specification provides such an extension. 203 This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 204 [RFC3264]. The update allows an answerer to assign a non-zero port 205 value to an "m=" line in an SDP answer, even if the "m=" line in the 206 associated SDP offer contained a zero port value. 208 This specification also defines a new Real-time Transport Protocol 209 (RTP) [RFC3550] SDES item and a new RTP header extension that can be 210 used to carry a value that associates RTP/RTCP packets with a 211 specific media description. This can be used to correlate a RTP 212 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 RTP based media flows associated with a single 218 BUNDLE group belong to a single RTP session [RFC3550]. 220 The BUNDLE extension is backward compatible. Endpoints that do not 221 support the extension are expected to generate offers and answers 222 without an SDP 'group:BUNDLE' attribute, and are expected to assign a 223 unique address to each "m=" line within an offer and answer, 224 according to the procedures in [RFC4566] and [RFC3264] 226 2. Terminology 228 5-tuple: A collection of the following values: source address, source 229 port, destination address, destination port, and transport-layer 230 protocol. 232 Unique address: An IP address and port combination that is assigned 233 to only one "m=" line in an offer or answer. 235 Shared address: An IP address and port combination that is assigned 236 to multiple "m=" lines within an offer or answer. 238 Offerer BUNDLE-tag: The first identification-tag in a given SDP 239 'group:BUNDLE' attribute identification-tag list in an offer. 241 Answerer BUNDLE-tag: The first identification-tag in a given SDP 242 'group:BUNDLE' attribute identification-tag list in an answer. 244 Offerer BUNDLE address: Within a given BUNDLE group, an IP address 245 and 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 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, which uses the same BUNDLE address for receiving media. 255 Bundled "m=" line: An "m=" line, whose identification-tag is placed 256 in an SDP 'group:BUNDLE' attribute identification-tag list in an 257 offer or answer. 259 Bundle-only "m=" line: A bundled "m=" line with an associated SDP 260 'bundle-only' attribute. 262 Bundled media: All media associated with a given BUNDLE group. 264 Initial offer: The first offer, within an SDP session (e.g. a SIP 265 dialog when the Session Initiation Protocol (SIP) [RFC3261] is used 266 to carry SDP), in which the offerer indicates that it wants to create 267 a given BUNDLE group. 269 Subsequent offer: An offer which contains a BUNDLE group that has 270 been created as part of a previous offer/answer exchange. 272 Identification-tag: A unique token value that is used to identify an 273 "m=" line. The SDP 'mid' attribute [RFC5888], associated with an 274 "m=" line, carries an unique identification-tag. The session-level 275 SDP 'group' attribute [RFC5888] carries a list of identification- 276 tags, identifying the "m=" lines associated with that particular 277 'group' attribute. 279 3. Conventions 281 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 282 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 283 document are to be interpreted as described in BCP 14, RFC 2119 284 [RFC2119]. 286 4. Applicability Statement 288 The mechanism in this specification only applies to the Session 289 Description Protocol (SDP) [RFC4566], when used together with the SDP 290 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 291 scope of this document, and is thus undefined. 293 5. SDP Grouping Framework BUNDLE Extension 295 This section defines a new SDP Grouping Framework extension 296 [RFC5888], 'BUNDLE'. The BUNDLE extension can be used with the SDP 297 Offer/Answer mechanism to negotiate the usage of a single 298 address:port combination (BUNDLE address) for receiving bundled 299 media. 301 A single address:port combination is also used for sending bundled 302 media. The address:port combination used for sending bundled media 303 MAY be the same as the BUNDLE address, used to receive bundled media, 304 depending on whether symmetric RTP is used. A given address:port 305 combination MUST NOT be used for sending media associated with 306 multiple BUNDLE groups. 308 All media associated with a BUNDLE group share a single 5-tuple, i.e. 309 in addition to using a single address:port combination all bundled 310 media MUST be transported using the same transport-layer protocol 311 (e.g. UDP or TCP). 313 The BUNDLE extension is indicated using an SDP 'group' attribute with 314 a "BUNDLE" semantics value [RFC5888]. An identification-tag is 315 assigned to each bundled "m=" line, and each identification-tag is 316 listed in the SDP 'group:BUNDLE' attribute identification-tag list. 317 Each "m=" line, whose identification-tag is listed in the 318 identification-tag list, is associated with a given BUNDLE group. 320 SDP bodies can contain multiple BUNDLE groups. Any given bundled 321 "m=" line MUST NOT be associated with more than one BUNDLE group. 323 Section 8 defines the detailed SDP Offer/Answer procedures for the 324 BUNDLE extension. 326 6. SDP 'bundle-only' Attribute 328 This section defines a new SDP media-level attribute [RFC4566], 329 'bundle-only'. 331 Name: bundle-only 333 Value: 335 Usage Level: media 337 Charset Dependent: no 339 Example: 341 a=bundle-only 343 In order to ensure that an answerer that does not supports the BUNDLE 344 extension always rejects a bundled "m=" line, the offerer can assign 345 a zero port value to the "m=" line. According to [RFC4566] an 346 answerer will reject such "m=" line. By associating an SDP 'bundle- 347 only' attribute with such "m=" line, the offerer can request that the 348 answerer accepts the "m=" line if the answerer supports the Bundle 349 extension, and if the answerer keeps the "m=" line within the 350 associated BUNDLE group. 352 NOTE: Once an offerer BUNDLE address has been selected, the offerer 353 can ensure that an bundled "m=" line is accepted by the answerer only 354 if the answerer keeps the "m=" line within the associated BUNDLE 355 group by assigning the offerer BUNDLE address to the "m=" line. If 356 the answerer does not keep that "m=" line within the BUNDLE group, 357 the answerer will reject it. Therefore, the SDP 'bundle-only' 358 attribute is not needed in such cases 360 The usage of the 'bundle-only' attribute is only defined for a 361 bundled "m=" line with a zero port value, within an offer. Other 362 usage is unspecified. 364 Section 8 defines the detailed SDP Offer/Answer procedures for the 365 'bundle-only' attribute. 367 7. SDP Information Considerations 369 7.1. General 371 This section describes restrictions associated with the usage of SDP 372 parameters within a BUNDLE group. It also describes, when parameter 373 and attribute values have been associated with each bundled "m=" 374 line, how to calculate a value for the whole BUNDLE group. 376 7.2. Connection Data (c=) 378 The "c=" line nettype value [RFC4566] associated with a bundled "m=" 379 line MUST be 'IN'. 381 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" 382 line MUST be 'IP4' or 'IP6'. The same value MUST be associated with 383 each "m=" line. 385 NOTE: Extensions to this specification can specify usage of the 386 BUNDLE mechanism for other nettype and addrtype values than the ones 387 listed above. 389 7.3. Bandwidth (b=) 391 The proposed bandwidth for a bundled "m=" line SHOULD be calculated 392 in the same way as for a non-bundled "m=" line. 394 The total proposed bandwidth for a BUNDLE group is the sum of the 395 proposed bandwidth for each bundled "m=" line. 397 The total proposed bandwidth for an offer or answer is the sum of the 398 proposed bandwidth for each "m=" line (bundled and non-bundled) 399 within the offer or answer. 401 7.4. Attributes (a=) 403 An offerer and answerer MUST use the rules and restrictions defined 404 in [I-D.mmusic-sdp-mux-attributes] for when associating SDP 405 attributes with bundled "m=" lines. 407 8. SDP Offer/Answer Procedures 409 8.1. General 411 This section describes the SDP Offer/Answer [RFC3264] procedures for: 413 o Negotiating and creating of a BUNDLE group; 415 o Selecting the BUNDLE addresses (offerer BUNDLE address and 416 answerer BUNDLE address); 418 o Adding an "m=" line to a BUNDLE group; 420 o Moving an "m=" line out of a BUNDLE group; and 422 o Disabling an "m=" line within a BUNDLE group. 424 The generic rules and procedures defined in [RFC3264] and [RFC5888] 425 also apply to the BUNDLE extension. For example, if an offer is 426 rejected by the answerer, the previously negotiated SDP parameters 427 and characteristics (including those associated with a BUNDLE group) 428 apply. Hence, if an offerer generates an offer in which the offerer 429 wants to create a BUNDLE group, and the answerer rejects the offer, 430 the BUNDLE group is not created. 432 The procedures in this section are independent of the media type or 433 "m=" line proto value represented by a bundled "m=" line. Section 10 434 defines additional considerations for RTP based media. Section 6 435 defines additional considerations for the usage of the SDP 'bundle- 436 only' attribute. Section 11 defines additional considerations for 437 the usage of Interactive Connectivity Establishment (ICE) [RFC5245] 438 mechanism . 440 The offerer and answerer MUST follow the rules and restrictions 441 defined in Section 7 when creating offers and answers. 443 SDP offers and answers can contain multiple BUNDLE groups. The 444 procedures in this section apply independently to a given BUNDLE 445 group. 447 8.2. Generating the Initial SDP Offer 449 8.2.1. General 451 When an offerer generates an initial offer, in order to create a 452 BUNDLE group, it MUST: 454 o Assign a unique address to each "m=" line within the offer, 455 following the procedures in [RFC3264], unless the media line is a 456 'bundle-only' "m=" line (see below); 458 o Add an SDP 'group:BUNDLE' attribute to the offer; 460 o Place the identification-tag of each bundled "m=" line in the SDP 461 'group:BUNDLE' attribute identification-tag list; and 463 o Indicate which unique address the offerer suggests as the offerer 464 BUNDLE address [Section 8.2.2]. 466 If the offerer wants to request that the answerer accepts a given 467 bundled "m=" line only if the answerer keeps the "m=" line within the 468 BUNDLE group, the offerer MUST: 470 o Associate an SDP 'bundle-only' attribute [Section 8.2.2] with the 471 "m=" line; and 473 o Assign a zero port value to the "m=" line. 475 NOTE: If the offerer assigns a zero port value to an "m=" line, but 476 does not also associate an SDP 'bundle-only' attribute with the "m=" 477 line, it is an indication that the offerer wants to disable the "m=" 478 line [Section 8.5.5]. 480 [Section 16.1] shows an example of an initial offer. 482 8.2.2. Suggesting the offerer BUNDLE address 484 In the offer, the address assigned to the "m=" line associated with 485 the offerer BUNDLE-tag indicates the address that the offerer 486 suggests as the offerer BUNDLE address. 488 8.3. Generating the SDP Answer 490 8.3.1. General 492 When an answerer generates an answer, which contains a BUNDLE group, 493 the following general SDP grouping framework restrictions, defined in 494 [RFC5888], also apply to the BUNDLE group: 496 o The answerer MUST NOT include a BUNDLE group in the answer, unless 497 the offerer requested the BUNDLE group to be created in the 498 associated offer; and 500 o The answerer MUST NOT include an "m=" line within a BUNDLE group, 501 unless the offerer requested the "m=" line to be within that 502 BUNDLE group in the associated offer. 504 If the answer contains a BUNDLE group, the answerer MUST: 506 o Select an Offerer BUNDLE Address [Section 8.3.2]; and 508 o Select an Answerer BUNDLE Address [Section 8.3.3]; 510 The answerer is allowed to select a new Answerer BUNDLE address each 511 time it generates an answer to an offer. 513 If the answerer does not want to keep an "m=" line within a BUNDLE 514 group, it MUST: 516 o Move the "m=" line out of the BUNDLE group [Section 8.3.4]; or 518 o Reject the "m=" line [Section 8.3.5]; 519 If the answerer keeps a bundle-only "m=" line within the BUNDLE 520 group, it follows the procedures (assigns the answerer BUNDLE address 521 to the "m=" line etc) for any other "m=" line kept within the BUNDLE 522 group. 524 If the answerer does not want to keep a bundle-only "m=" line within 525 the BUNDLE group, it MUST reject the "m=" line [Section 8.3.5]. 527 The answerer MUST NOT associate an SDP 'bundle-only' attribute with 528 any "m=" line in an answer. 530 NOTE: If a bundled "m=" line in an offer contains a zero port value, 531 but the "m=" line does not contain an SDP 'bundle-only' attribute, it 532 is an indication that the offerer wants to disable the "m=" line 533 [Section 8.5.5]. 535 8.3.2. Answerer Selection of Offerer Bundle Address 537 In an offer, the address (unique or shared) assigned to the bundled 538 "m=" line associated with the offerer BUNDLE-tag indicates the 539 address that the offerer suggests as the offerer BUNDLE address 540 [Section 8.2.2]. The answerer MUST check whether that "m=" line 541 fulfills the following criteria: 543 o The answerer will not move the "m=" line out of the BUNDLE group 544 [Section 8.3.4]; 546 o The answerer will not reject the "m=" line [Section 8.3.5]; and 548 o The "m=" line does not contain a zero port value. 550 If all of the criteria above are fulfilled, the answerer MUST select 551 the address associated with the "m=" line as the offerer BUNDLE 552 address. In the answer, the answerer BUNDLE-tag represents the "m=" 553 line, and the address associated with the "m=" line in the offer 554 becomes the offerer BUNDLE address. 556 If one or more of the criteria are not fulfilled, the answerer MUST 557 select the next identification-tag in the identification-tag list, 558 and perform the same criteria check for the "m=" line associated with 559 that identification-tag. If there are no more identification-tags in 560 the identification-tag list, the answerer MUST NOT create the BUNDLE 561 group. In addition, unless the answerer rejects the whole offer, the 562 answerer MUST apply the answerer procedures for moving an "m=" line 563 out of a BUNDLE group [Section 8.3.4] to each bundled "m=" line in 564 the offer when creating the answer. 566 [Section 16.1] shows an example of an offerer BUNDLE address 567 selection. 569 8.3.3. Answerer Selection of Answerer BUNDLE Address 571 When the answerer selects a BUNDLE address for itself, referred to as 572 the answerer BUNDLE address, it MUST assign that address to each 573 bundled "m=" line within the created BUNDLE group in the answer. 575 The answerer MUST NOT assign the answerer BUNDLE address to an "m=" 576 line that is not within the BUNDLE group, or to an "m=" line that is 577 within another BUNDLE group. 579 [Section 16.1] shows an example of an answerer BUNDLE address 580 selection. 582 8.3.4. Moving A Media Description Out Of A BUNDLE Group 584 When an answerer moves a "m=" line out of a BUNDLE group, it assigns 585 an address to the "m=" line in the answer based on the following 586 rules: 588 o In the associated offer, if the "m=" line contains a shared 589 address (e.g. a previously selected offerer BUNDLE address), the 590 answerer MUST reject the moved "m=" line [Section 8.3.5]; 592 o In the associated offer, if the "m=" line contains a unique 593 address, the answerer MUST assign a unique address also to the 594 "m=" line in the answer; or 596 o In the associated offer, if an SDP 'bundle-only' attribute is 597 associated with the "m=" line, and if the "m=" line contains a 598 zero port value, the answerer MUST reject the "m=" line 599 [Section 8.3.5]. 601 In addition, in either case above, the answerer MUST NOT place the 602 identification-tag, associated with the moved "m=" line, in the SDP 603 'group' attribute identification-tag list associated with the BUNDLE 604 group. 606 8.3.5. Rejecting A Media Description In A BUNDLE Group 608 When an answerer rejects an "m=" line, it MUST assign an address with 609 a zero port value to the "m=" line in the answer, according to the 610 procedures in [RFC4566]. 612 In addition, the answerer MUST NOT place the identification-tag, 613 associated with the rejected "m=" line, in the SDP 'group' attribute 614 identification-tag list associated with the BUNDLE group. 616 8.4. Offerer Processing of the SDP Answer 618 8.4.1. General 620 When an offerer receives an answer, if the answer contains a BUNDLE 621 group, the offerer MUST check that any bundled "m=" line in the 622 answer was indicated as bundled in the associated offer. If there is 623 no mismatch, the offerer MUST use the offerer BUNDLE address, 624 selected by the answerer [Section 8.3.2], as the address for each 625 bundled "m=" line. 627 NOTE: As the answerer might reject one or more bundled "m=" lines, or 628 move a bundled "m=" line out of a BUNDLE group, each bundled "m=" 629 line in the offer might not be indicated as bundled in the answer. 631 If the answer does not contain a BUNDLE group, the offerer MUST 632 process the answer as a normal answer. 634 8.4.2. Bundle Address Synchronization (BAS) 636 When an offerer receives an answer, if the answer contains a BUNDLE 637 group, the offerer MUST check whether the offerer BUNDLE address, 638 selected by the answerer [Section 8.3.2], matches what was assigned 639 to each bundled "m=" line (excluding any bundled "m=" line that was 640 rejected, or moved out of the BUNDLE group, by the answerer) in the 641 associated offer. If there is a mismatch, the offerer SHOULD as soon 642 as possible generate a subsequent offer, in which it assigns the 643 offerer BUNDLE address to each bundled "m=" line. Such offer is 644 referred to as a Bundle Address Synchronization (BAS) offer. 646 A BAS offer is typically sent in the following scenarios: 648 o The offerer receives an answer to an initial offer, as the bundled 649 "m=" lines in the initial offer always contain unique addresses 650 [Section 8.2]; or 652 o The offerer receives an answer to an offer, in which a new bundled 653 "m=" line has been added to the BUNDLE group [Section 8.5.3], and 654 the offerer assigned a unique address to the bundled "m=" line in 655 the offer. 657 The offerer is allowed to modify any SDP parameter in the BAS offer. 659 NOTE: It is important that the BAS offer gets accepted by the 660 answerer. For that reason the offerer needs to consider the 661 necessity to modify SDP parameters in the BAS offer, in such a way 662 that could trigger the answerer to reject the BAS offer. Disabling 663 "m=" lines, or reducing the number of codecs, in a BAS offer is 664 considered to have a low risk of being rejected. 666 NOTE: The main purpose of the BAS offer is to ensure that 667 intermediaries, that might not support the BUNDLE extension, have 668 correct information regarding the address that is going to be used to 669 transport the bundled media. 671 [Section 16.1] shows an example of a BAS offer. 673 8.5. Modifying the Session 675 8.5.1. General 677 When an offerer generates a subsequent offer, it MUST assign the 678 previously selected offerer BUNDLE address [Section 8.3.2], to each 679 bundled "m=" line (including any bundle-only "m=" line), except if: 681 o The offerer suggests a new offerer BUNDLE address [Section 8.5.2]; 683 o The offerer wants to add a bundled "m=" line to the BUNDLE group 684 [Section 8.5.3]; 686 o The offerer wants to move a bundled "m=" line out of the BUNDLE 687 group [Section 8.5.4]; or 689 o The offerer wants to disable the bundled "m=" line 690 [Section 8.5.5]. 692 In addition, the offerer MUST select an offerer BUNDLE-tag 693 [Section 8.2.2] associated with the previously selected offerer 694 BUNDLE address, unless the offerer suggests a new offerer BUNDLE 695 address. 697 8.5.2. Suggesting a new offerer BUNDLE address 699 When an offerer generates an offer, in which it suggests a new 700 offerer BUNDLE address [Section 8.2.2], the offerer MUST: 702 o Assign the address (shared address) to each "m=" line within the 703 BUNDLE group; or 705 o Assign the address (unique address) to one bundled "m=" line. 707 NOTE: If the offerer assigns a unique address, there might be a need 708 to send a subsequent BAS offer [Section 8.4.2] once the offerer has 709 received the associated answer. 711 In addition, the offerer MUST indicate that the address is the new 712 suggested offerer BUNDLE address [Section 8.2.2]. 714 NOTE: Unless the offerer assigns the new suggested offerer BUNDLE 715 address to each bundled "m=" line, it can assign unique addresses to 716 any number of bundled "m=" lines (and the previously selected offerer 717 BUNDLE address to any remaining bundled "m=" line) if it wants to 718 suggest multiple alternatives for the new offerer BUNDLE address. 720 8.5.3. Adding a media description to a BUNDLE group 722 When an offerer generates an offer, in which it wants to add a 723 bundled "m=" line to a BUNDLE group, the offerer MUST: 725 o Assign a unique address to the "m=" line; 727 o Assign the previously selected offerer BUNDLE address to the "m=" 728 line; or 730 o If the offerer assigns a new (shared address) suggested offerer 731 BUNDLE address to each bundled "m=" line [Section 8.5.2], also 732 assign that address to the added "m=" line. 734 In addition, the offerer MUST extend the SDP 'group:BUNDLE' attribute 735 identification-tag list with the BUNDLE group [Section 8.2.2] by 736 adding the identification-tag associated with the added "m=" line to 737 the list. 739 NOTE: Assigning a unique address to the "m=" line allows the answerer 740 to move the "m=" line out of the BUNDLE group [Section 8.3.4], 741 without having to reject the "m=" line. 743 If the offerer assigns a unique address to the added "m=" line, and 744 if the offerer suggests that address as the new offerer BUNDLE 745 address [Section 8.5.2], the offerer BUNDLE-tag MUST represent the 746 added "m=" line [Section 8.2.2]. 748 If the offerer assigns a new suggested offerer BUNDLE address to each 749 bundled "m=" line [Section 8.5.2], including the added "m=" line, the 750 offerer BUNDLE-tag MAY represent the added "m=" line [Section 8.2.2]. 752 [Section 16.3] shows an example where an offerer sends an offer in 753 order to add a bundled "m=" line to a BUNDLE group. 755 8.5.4. Moving A Media Description Out Of A BUNDLE Group 757 When an offerer generates an offer, in which it wants to move a 758 bundled "m=" line out of a BUNDLE group it was added to in a previous 759 offer/answer transaction, the offerer: 761 o MUST assign a unique address to the "m=" line; and 763 o MUST NOT place the identification-tag associated with the "m=" 764 line in the SDP 'group:BUNDLE' attribute identification-tag list 765 associated with the BUNDLE group. 767 NOTE: If an "m=" line, when being moved out of a BUNDLE group, is 768 added to another BUNDLE group, the offerer applies the procedures in 769 [Section 8.5.3] to the "m=" line. 771 [Section 16.4] shows an example of an offer for moving an "m=" line 772 out of a BUNDLE group. 774 8.5.5. Disabling A Media Description In A BUNDLE Group 776 When an offerer generates an offer, in which it wants to disable a 777 bundled "m=" line (added to the BUNDLE group in a previous offer/ 778 answer transaction), the offerer: 780 o MUST assign an address with a zero port value to the "m=" line, 781 following the procedures in [RFC4566]; and 783 o MUST NOT place the identification-tag associated with the "m=" 784 line in the SDP 'group:BUNDLE' attribute identification-tag list 785 associated with the BUNDLE group. 787 [Section 16.5] shows an example of an offer for disabling an "m=" 788 line within a BUNDLE group. 790 9. Protocol Identification 792 9.1. General 794 Each "m=" line within a BUNDLE group MUST use the same transport- 795 layer protocol. If bundled "m=" lines use different protocols on top 796 of the transport-layer protocol, there MUST exist a publicly 797 available specification which describes a mechanism, for this 798 particular protocol combination, how to associate a received packet 799 with the correct protocol. 801 In addition, if a received packet can be associated with more than 802 one bundled "m=" line, there MUST exist a publically available 803 specification which describes a mechanism for associating the 804 received packet with the correct "m=" line. 806 9.2. STUN, DTLS, SRTP 808 Section 5.1.2 of [RFC5764] describes a mechanism to identify the 809 protocol of a received packet among the STUN, DTLS and SRTP protocols 810 (in any combination). If an offer or answer includes bundled "m=" 811 lines that represent these protocols, the offerer or answerer MUST 812 support the mechanism described in [RFC5764], and no explicit 813 negotiation is required in order to indicate support and usage of the 814 mechanism. 816 [RFC5764] does not describe how to identify different protocols 817 transported on DTLS, only how to identify the DTLS protocol itself. 818 If multiple protocols are transported on DTLS, there MUST exist a 819 specification describing a mechanism for identifying each individual 820 protocol. In addition, if a received DTLS packet can be associated 821 with more than one "m=" line, there MUST exist a specification which 822 describes a mechanism for associating the received DTLS packet with 823 the correct "m=" line. 825 [Section 10.2] describes how to associate a received (S)RTP packet 826 with the correct "m=" line. 828 10. RTP Considerations 830 10.1. Single RTP Session 832 10.1.1. General 834 All RTP-based media within a single BUNDLE group belong to a single 835 RTP session [RFC3550]. Disjoint BUNDLE groups will form multiple RTP 836 sessions, one per BUNDLE group. 838 Since a single RTP session is used for each bundle group, all "m=" 839 lines representing RTP-based media in a bundle group will share a 840 single SSRC numbering space [RFC3550]. 842 The following rules and restrictions apply for a single RTP session: 844 o A specific payload type value can be used in multiple bundled "m=" 845 lines if each codec associated with the payload type number shares 846 an identical codec configuration [Section 10.1.2]. 848 o The proto value in each bundled RTP-based "m=" line MUST be 849 identical (e.g. RTP/AVPF). 851 o The RTP MID header extension MUST be enabled, by associating an 852 SDP 'extmap' attribute [RFC5285], with a 'urn:ietf:params:rtp- 853 hdrext:sdes:mid' URI value, with each bundled RTP-based "m=" line 854 in every offer and answer. 856 o A given SSRC MUST NOT transmit RTP packets using payload types 857 that originate from different bundled "m=" lines. 859 NOTE: The last bullet above is to avoid sending multiple media types 860 from the same SSRC. If transmission of multiple media types are done 861 with time overlap, RTP and RTCP fail to function. Even if done in 862 proper sequence this causes RTP Timestamp rate switching issues 863 [RFC7160]. However, once an SSRC has left the RTP session (by 864 sending an RTCP BYE packet), that SSRC value can later be reused by 865 another source(possible associated with a different bundled "m=" 866 line. 868 10.1.2. Payload Type (PT) Value Reuse 870 Multiple bundled "m=" lines might represent RTP based media. As all 871 RTP based media associated with a BUNDLE group belong to the same RTP 872 session, in order for a given payload type value to be used inside 873 more than one bundled "m=" line, all codecs associated with the 874 payload type number MUST share an identical codec configuration. 875 This means that the codecs MUST share the same media type, encoding 876 name, clock rate and any parameter that can affect the codec 877 configuration and packetization. [I-D.mmusic-sdp-mux-attributes] 878 lists SDP attributes, whose attribute values must be identical for 879 all codecs that use the same payload type value. 881 10.2. Associating RTP/RTCP Packets With Correct SDP Media Description 883 There are multiple mechanisms that can be used by an endpoint in 884 order to associate received RTP/RTCP packets with a bundled "m=" 885 line. Such mechanisms include using the payload type value carried 886 inside the RTP packets, the SSRC values carried inside the RTP 887 packets, and other "m=" line specific information carried inside the 888 RTP packets. 890 As all RTP/RTCP packets associated with a BUNDLE group are received 891 (and sent) using single address:port combinations, the local 892 address:port combination cannot be used to associate received RTP 893 packets with the correct "m=" line. 895 As described in [Section 10.1.2], the same payload type value might 896 be used inside RTP packets described by multiple "m=" lines. In such 897 cases, the payload type value cannot be used to associate received 898 RTP packets with the correct "m=" line. 900 An offerer and answerer can in an offer and answer inform each other 901 which SSRC values they will use inside sent RTP/RTCP packets, by 902 associating one or more SDP 'ssrc' attributes [RFC5576] with each 903 bundled "m=" line which contains a payload type value that is also 904 used inside another bundled "m=" line. As the SSRC values will be 905 carried inside the RTP/RTCP packets, the offerer and answerer can 906 then use that information to associate received RTP packets with the 907 correct "m=" line. However, an offerer will not know which SSRC 908 values the answerer will use until it has received the answer 909 providing that information. Due to this, before the offerer has 910 received the answer, the offerer will not be able to associate 911 received RTP/RTCP packets with the correct "m=" line using the SSRC 912 values. 914 In order for an offerer and answerer to always be able to associate 915 received RTP and RTCP packets with the correct "m=" line, an offerer 916 and answerer using the BUNDLE extension MUST support the mechanism 917 defined in Section 13, where the remote endpoint inserts the 918 identification-tag associated with an "m=" line in RTP and RTCP 919 packets associated with that "m=" line. 921 10.3. RTP/RTCP Multiplexing 923 10.3.1. General 925 When a BUNDLE group, which contains RTP based media, is created, the 926 offerer and answerer MUST negotiate whether to enable RTP/RTCP 927 multiplexing for the RTP based media associated with the BUNDLE group 928 [RFC5761]. 930 If RTP/RTCP multiplexing is not enabled, separate address:port 931 combinations will be used for receiving (and sending) the RTP packets 932 and the RTCP packets. 934 10.3.2. SDP Offer/Answer Procedures 936 10.3.2.1. General 938 This section describes how an offerer and answerer can use the SDP 939 'rtcp-mux' attribute [RFC5761] and the SDP 'rtcp' attribute [RFC3605] 940 to negotiate usage of RTP/RTCP multiplexing for RTP based media 941 associated with a BUNDLE group. 943 10.3.2.2. Generating the Initial SDP Offer 945 When an offerer generates an initial offer, if the offerer wants to 946 negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, the 947 offerer MUST associate an SDP 'rtcp-mux' attribute [RFC5761] with 948 each bundled RTP-based "m=" line (including any bundle-only "m=" 949 line) in the offer. 951 If the offerer does not want to negotiate usage of RTP/RTCP 952 multiplexing, it MUST NOT associate an SDP 'rtcp-mux' attribute with 953 any bundled "m=" line in the offer. 955 In addition, the offerer can associate an SDP 'rtcp' attribute 956 [RFC3605] with one or more bundled RTP-based "m=" lines (including 957 any bundle-only "m=" line) in the offer, in order to provide a port 958 for receiving RTCP packets (if the answerer does not accept usage of 959 RTP/RTCP multiplexing, or if the offerer does not want to negotiate 960 usage of RTP/RTCP multiplexing). 962 In the initial offer, the IP address and port combination for RTCP 963 MUST be unique in each bundled RTP-based "m=" line, similar to RTP. 965 NOTE: In case the offer wants to receive RTCP packets on the next 966 higher port value, the SDP 'rtcp' attribute is not needed. 968 10.3.2.3. Generating the SDP Answer 970 When an answerer generates an answer, if the offerer indicated 971 support of RTP/RTCP multiplexing [RFC5761] within a BUNDLE group in 972 the associated offer, the answerer MUST either accept or reject the 973 usage of RTP/RTCP multiplexing for the whole BUNDLE group in the 974 answer. 976 If the answerer accepts the usage of RTP/RTCP multiplexing within the 977 BUNDLE group, it MUST associate an SDP 'rtcp-mux' attribute with each 978 bundled RTP-based "m=" line in the answer. The answerer MUST NOT 979 associate an SDP 'rtcp' attribute with any bundled "m=" line in the 980 answer. The answerer will use the port value of the selected offerer 981 BUNDLE address for sending RTP and RTCP packets associated with each 982 RTP-based bundled "m=" line towards the offerer. 984 If the answerer does not accept the usage of RTP/RTCP multiplexing 985 within the BUNDLE group, it MUST NOT associate an SDP 'rtcp-mux' 986 attribute with any bundled "m=" line in the answer. The answerer 987 will use the RTP and RTCP port values associated with the selected 988 offerer BUNDLE address for sending RTP and RTCP packets associated 989 with each RTP-based bundled "m=" line towards the offerer. 991 In addition, if the answerer rejects the usage of RTP/RTCP 992 multiplexing within the BUNDLE group, it MAY associate an SDP 'rtcp' 993 attribute, with identical attribute values, with each RTP-based 994 bundled "m=" line in the answer, in order to provide a port value for 995 receiving RTCP packets from the offerer. 997 NOTE: In case the answerer wants to receive RTCP packets on the next 998 higher port value, the SDP 'rtcp' attribute is not needed. 1000 If the usage of RTP/RTCP multiplexing within a BUNDLE group has been 1001 negotiated in a previous offer/answer transaction, and if the offerer 1002 indicates that it wants to continue using RTP/RTCP multiplexing in a 1003 subsequent offer, the answerer MUST associate an SDP 'rtcp-mux' 1004 attribute with each bundled "m=" line in the answer. I.e. the 1005 answerer MUST NOT disable the usage of RTP/RTCP multiplexing. 1007 If the usage of RTP/RTCP multiplexing within a BUNDLE group has not 1008 been negotiated in a previous offer/answer transaction, and if the 1009 offerer indicates that it wants to use RTP/RTCP multiplexing in a 1010 subsequent offer, the answerer either accepts or rejects the usage, 1011 using the procedures above. 1013 10.3.2.4. Offerer Processing of the SDP Answer 1015 When an offerer receives an answer, if the answerer has accepted the 1016 usage of RTP/RTCP multiplexing (see Section 10.3.2.3), the answerer 1017 follows the procedures for RTP/RTCP multiplexing defined in 1018 [RFC5761]. The offerer will use the port value associated with the 1019 answerer BUNDLE address for sending RTP and RTCP packets associated 1020 with each RTP-based bundled "m=" line towards the answerer. 1022 If the answerer did not accept the usage of RTP/RTCP multiplexing 1023 (see Section 10.3.2.3), the offerer will use separate address:port 1024 combinations for sending RTP and RTCP packets towards the answerer. 1025 If the answerer associated an SDP 'rtcp' attribute with the "m=" line 1026 representing the answerer BUNDLE address, the offerer will use the 1027 attribute port value for sending RTCP packets associated with each 1028 bundled RTP-based "m=" line towards the answerer. Otherwise the 1029 offerer will use the next higher port value associated with the 1030 answerer BUNDLE address for sending RTCP packets towards the 1031 answerer. 1033 10.3.2.5. Modifying the Session 1035 When an offerer generates a subsequent offer, if it wants to 1036 negotiate the usage of RTP/RTCP multiplexing within a BUNDLE group, 1037 or if it wants to continue the use of previously negotiated RTP/RTCP 1038 multiplexing, it MUST associate an SDP 'rtcp-mux' attribute with each 1039 RTP-based bundled "m=" line (including any bundled "m=" line that the 1040 offerer wants to add to the BUNDLE group), unless the offerer wants 1041 to disable or remove the "m=" line from the BUNDLE group. 1043 If the offerer does not want to negotiate the usage of RTP/RTCP 1044 multiplexing within the BUNDLE group, or if it wants to disable 1045 previously negotiated usage of RTP/RTCP multiplexing, it MUST NOT 1046 associate an SDP 'rtcp-mux' and attribute with any bundled "m=" line 1047 in the subsequent offer. 1049 In addition, if the offerer does not indicate support of RTP/RTCP 1050 multiplexing within the subsequent offer, it MAY associate an SDP 1051 'rtcp' attribute, with identical attribute values, with each RTP- 1052 based bundled "m=" line (including any bundled "m=" line that the 1053 offerer wants to add to the BUNDLE group), in order to provide a port 1054 for receiving RTCP packets. 1056 NOTE: It is RECOMMENDED that, once the usage of RTP/RTCP multiplexing 1057 has been negotiated within a BUNDLE group, that the usage is not 1058 disabled. Disabling RTP/RTCP multiplexing means that the offerer and 1059 answerer need to reserve new ports, to be used for sending and 1060 receiving RTCP packets. Similar, if the usage of a specific RTCP 1061 port has been negotiated within a BUNDLE group, it is RECOMMENDED 1062 that the port value is not modified. 1064 11. ICE Considerations 1066 11.1. General 1068 This section describes how to use the BUNDLE grouping extension 1069 together with the Interactive Connectivity Establishment (ICE) 1070 mechanism [RFC5245]. 1072 The procedures defined in [RFC5245] also apply to usage of ICE with 1073 BUNDLE, with the following exception: 1075 o When BUNDLE addresses for a BUNDLE group have been selected for 1076 both endpoints, ICE connectivity checks and keep-alives only need 1077 to be performed for the whole BUNDLE group, instead of per bundled 1078 "m=" line. 1080 Support and usage of ICE mechanism together with the BUNDLE extension 1081 is OPTIONAL. 1083 11.2. SDP Offer/Answer Procedures 1085 11.2.1. General 1087 When an offerer assigns a unique address to a bundled "m=" line 1088 (excluding any bundle-only "m=" line), it MUST also associate unique 1089 ICE candidates [RFC5245] to the "m=" line. 1091 An offerer MUST NOT assign ICE candidates to a bundle-only "m=" line 1092 with a zero port value. 1094 NOTE: The bundle-only "m=" line, if accepted by the answerer, will 1095 inherit the candidates associated with the selected offerer BUNDLE 1096 address. An answerer that does not support BUNDLE would not accept a 1097 bundle-only "m=" line. 1099 When an offerer or answerer assigns a shared address (i.e. a 1100 previously selected BUNDLE address) to one or more bundled "m=" 1101 lines, it MUST associate identical ICE candidates (referred to as 1102 shared ICE candidates) to each of those "m=" lines. 1104 11.2.2. Generating the Initial SDP Offer 1106 When an offerer generates an initial offer, it assigns unique or 1107 shared ICE candidates to the bundled "m=" lines, according to 1108 Section 11.1. 1110 11.2.3. Generating the SDP Answer 1112 When an answerer generates an answer, which contains a BUNDLE group, 1113 the answerer MUST assign shared ICE candidates to each bundled "m=" 1114 line (including "m=" lines that were indicated as bundle-only in the 1115 associated offer) in the answer. 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 assign 1121 the same ICE candidates, associated with the "m=" line representing 1122 the offerer BUNDLE address (selected by the answerer), to each 1123 bundled "m=" line. 1125 11.2.5. Modifying the Session 1127 When an offerer generates a subsequent offer, it assigns unique or 1128 shared ICE candidates to the bundled "m=" lines, according to 1129 (Section 11.1). 1131 12. Update to RFC 3264 1133 12.1. General 1135 This section replaces the text of the following sections of RFC 3264: 1137 o Section 5.1 (Unicast Streams). 1139 o Section 8.2 (Removing a Media Stream). 1141 o Section 8.4 (Putting a Unicast Media Stream on Hold). 1143 12.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 1145 For recvonly and sendrecv streams, the port number and address in the 1146 offer indicate where the offerer would like to receive the media 1147 stream. For sendonly RTP streams, the address and port number 1148 indirectly indicate where the offerer wants to receive RTCP reports. 1149 Unless there is an explicit indication otherwise, reports are sent to 1150 the port number one higher than the number indicated. The IP address 1151 and port present in the offer indicate nothing about the source IP 1152 address and source port of RTP and RTCP packets that will be sent by 1153 the offerer. A port number of zero in the offer indicates that the 1154 stream is offered but MUST NOT be used. This has no useful semantics 1155 in an initial offer, but is allowed for reasons of completeness, 1156 since the answer can contain a zero port indicating a rejected stream 1157 (Section 6). Furthermore, existing streams can be terminated by 1158 setting the port to zero (Section 8). In general, a port number of 1159 zero indicates that the media stream is not wanted. 1161 12.3. New text replacing section 5.1 (2nd paragraph) of RFC 3264 1163 For recvonly and sendrecv streams, the port number and address in the 1164 offer indicate where the offerer would like to receive the media 1165 stream. For sendonly RTP streams, the address and port number 1166 indirectly indicate where the offerer wants to receive RTCP reports. 1167 Unless there is an explicit indication otherwise, reports are sent to 1168 the port number one higher than the number indicated. The IP address 1169 and port present in the offer indicate nothing about the source IP 1170 address and source port of RTP and RTCP packets that will be sent by 1171 the offerer. A port number of zero in the offer by default indicates 1172 that the stream is offered but MUST NOT be used, but an extension 1173 mechanism might specify different semantics for the usage of a zero 1174 port value. Furthermore, existing streams can be terminated by 1175 setting the port to zero (Section 8). In general, a port number of 1176 zero by default indicates that the media stream is not wanted. 1178 12.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 1180 A stream that is offered with a port of zero MUST be marked with port 1181 zero in the answer. Like the offer, the answer MAY omit all 1182 attributes present previously, and MAY list just a single media 1183 format from amongst those in the offer. 1185 12.5. New text replacing section 8.2 (2nd paragraph) of RFC 3264 1187 A stream that is offered with a port of zero MUST by default be 1188 marked with port zero in the answer, unless an extension mechanism, 1189 which specifies semantics for the usage of a non-zero port value, is 1190 used. If the stream is marked with port zero in the answer, the 1191 answer MAY omit all attributes present previously, and MAY list just 1192 a single media format from amongst those in the offer." 1194 12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 1196 RFC 2543 [10] specified that placing a user on hold was accomplished 1197 by setting the connection address to 0.0.0.0. Its usage for putting 1198 a call on hold is no longer recommended, since it doesn't allow for 1199 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1200 with connection oriented media. However, it can be useful in an 1201 initial offer when the offerer knows it wants to use a particular set 1202 of media streams and formats, but doesn't know the addresses and 1203 ports at the time of the offer. Of course, when used, the port 1204 number MUST NOT be zero, which would specify that the stream has been 1205 disabled. An agent MUST be capable of receiving SDP with a 1206 connection address of 0.0.0.0, in which case it means that neither 1207 RTP nor RTCP should be sent to the peer. 1209 12.7. New text replacing section 8.4 (6th paragraph) of RFC 3264 1211 RFC 2543 [10] specified that placing a user on hold was accomplished 1212 by setting the connection address to 0.0.0.0. Its usage for putting 1213 a call on hold is no longer recommended, since it doesn't allow for 1214 RTCP to be used with held streams, doesn't work with IPv6, and breaks 1215 with connection oriented media. However, it can be useful in an 1216 initial offer when the offerer knows it wants to use a particular set 1217 of media streams and formats, but doesn't know the addresses and 1218 ports at the time of the offer. Of course, when used, the port 1219 number MUST NOT be zero, if it would specify that the stream has been 1220 disabled. However, an extension mechanism might specify different 1221 semantics of the zero port number usage. An agent MUST be capable of 1222 receiving SDP with a connection address of 0.0.0.0, in which case it 1223 means that neither RTP nor RTCP should be sent to the peer. 1225 13. RTP/RTCP extensions for identification-tag transport 1227 13.1. General 1229 SDP Offerers and Answerers [RFC3264] can associate identification- 1230 tags with "m=" lines within SDP Offers and Answers, using the 1231 procedures in [RFC5888]. Each identification-tag uniquely represents 1232 an "m=" line. 1234 This section defines a new RTCP SDES item [RFC3550], 'MID', which is 1235 used to carry identification-tags within RTCP SDES packets. This 1236 section also defines a new RTP header extension [RFC5285], which is 1237 used to carry identification-tags in RTP packets. 1239 The SDES item and RTP header extension make it possible for a 1240 receiver to associate received RTCP- and RTP packets with a specific 1241 "m=" line, to which the receiver has assigned an identification-tag, 1242 even if those "m=" lines are part of the same RTP session. The 1243 endpoint informs the remote endpoint about the identification-tag 1244 using the procedures in [RFC5888], and the remote endpoint then 1245 inserts the identification-tag in RTCP- and RTP packets sent towards 1246 the other endpoint. 1248 NOTE: This text above defines how identification-tags are carried in 1249 SDP Offers and Answers. The usage of other signalling protocols for 1250 carrying identification-tags is not prevented, but the usage of such 1251 protocols is outside the scope of this document. 1253 [RFC3550] defines general procedures regarding the RTCP transmission 1254 interval. The RTCP MID SDES item SHOULD be sent in the first few 1255 RTCP packets sent on joining the session, and SHOULD be sent 1256 regularly thereafter. The exact number of RTCP packets in which this 1257 SDES item is sent is intentionally not specified here, as it will 1258 depend on the expected packet loss rate, the RTCP reporting interval, 1259 and the allowable overhead. 1261 The RTP MID header extension SHOULD be included in some RTP packets 1262 at the start of the session and whenever the SSRC changes. It might 1263 also be useful to include the header extension in RTP packets that 1264 comprise random access points in the media (e.g., with video 1265 I-frames). The exact number of RTP packets in which this header 1266 extension is sent is intentionally not specified here, as it will 1267 depend on expected packet loss rate and loss patterns, the overhead 1268 the application can tolerate, and the importance of immediate receipt 1269 of the identification-tag. 1271 For robustness purpose, endpoints need to be prepared for situations 1272 where the reception of the identification-tag is delayed, and SHOULD 1273 NOT terminate sessions in such cases, as the identification-tag is 1274 likely to arrive soon. 1276 13.2. RTCP MID SDES Item 1278 0 1 2 3 1279 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 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | MID=TBD | length | identification-tag ... 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 The identification-tag payload is UTF-8 encoded, as in SDP. 1286 The identification-tag is not zero terminated. 1288 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1289 identifier value.] 1291 13.3. RTP MID Header Extension 1293 The payload, containing the identification-tag, of the RTP MID header 1294 extension element can be encoded using either the one-byte or two- 1295 byte header [RFC5285]. The identification-tag payload is UTF-8 1296 encoded, as in SDP. 1298 The identification-tag is not zero terminated. Note, that set of 1299 header extensions included in the packet needs to be padded to the 1300 next 32-bit boundary using zero bytes [RFC5285]. 1302 As the identification-tag is included in either an RTCP SDES item or 1303 an RTP header extension, or both, there should be some consideration 1304 about the packet expansion caused by the identification-tag. To 1305 avoid Maximum Transmission Unit (MTU) issues for the RTP packets, the 1306 header extension's size needs to be taken into account when the 1307 encoding media. 1309 It is recommended that the identification-tag is kept short. Due to 1310 the properties of the RTP header extension mechanism, when using the 1311 one-byte header, a tag that is 1-3 bytes will result in that a 1312 minimal number of 32-bit words are used for the RTP header extension, 1313 in case no other header extensions are included at the same time. 1314 Note, do take into account that some single characters when UTF-8 1315 encoded will result in multiple octets. 1317 14. IANA Considerations 1319 14.1. New SDES item 1321 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1322 document.] 1324 [RFC EDITOR NOTE: Please replace TBD with the assigned SDES 1325 identifier value.] 1327 This document adds the MID SDES item to the IANA "RTCP SDES item 1328 types" registry as follows: 1330 Value: TBD 1331 Abbrev.: MID 1332 Name: Media Identification 1333 Reference: RFCXXXX 1335 14.2. New RTP Header Extension URI 1337 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1338 document.] 1340 This document defines a new extension URI in the RTP Compact Header 1341 Extensions subregistry of the Real-Time Transport Protocol (RTP) 1342 Parameters registry, according to the following data: 1344 Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid 1345 Description: Media identification 1346 Contact: christer.holmberg@ericsson.com 1347 Reference: RFCXXXX 1349 14.3. New SDP Attribute 1351 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1352 document.] 1354 This document defines a new SDP media-level attribute, 'bundle-only', 1355 according to the following data: 1357 Attribute name: bundle-only 1358 Type of attribute: media 1359 Subject to charset: No 1360 Purpose: Request a media description to be accepted 1361 in the answer only if kept within a BUNDLE 1362 group by the answerer. 1363 Appropriate values: N/A 1364 Contact name: Christer Holmberg 1365 Contact e-mail: christer.holmberg@ericsson.com 1366 Reference: RFCXXXX 1368 15. Security Considerations 1370 The security considerations defined in [RFC3264] and [RFC5888] apply 1371 to the BUNDLE extension. Bundle does not change which information 1372 flows over the network but only changes which ports that information 1373 is flowing on and thus has very little impact on the security of the 1374 RTP sessions. 1376 When the BUNDLE extension is used, a single set of security 1377 credentials might be used for all media streams associated with a 1378 BUNDLE group. 1380 When the BUNDLE extension is used, the number of SSRC values within a 1381 single RTP session increases, which increases the risk of SSRC 1382 collision. [RFC4568] describes how SSRC collision may weaken SRTP 1383 and SRTCP encryption in certain situations. 1385 16. Examples 1387 16.1. Example: Bundle Address Selection 1389 The example below shows: 1391 o 1. An offer, in which the offerer assigns a unique address to 1392 each bundled "m=" line within the BUNDLE group. 1394 o 2. An answer, in which the answerer selects the offerer BUNDLE 1395 address, and in which selects its own BUNDLE address (the answerer 1396 BUNDLE address) and assigns it each bundled "m=" line within the 1397 BUNDLE group. 1399 o 3. A subsequent offer (BAS offer), which is used to perform a 1400 Bundle Address Synchronization (BAS). 1402 SDP Offer (1) 1404 v=0 1405 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1406 s= 1407 c=IN IP4 atlanta.example.com 1408 t=0 0 1409 a=group:BUNDLE foo bar 1410 m=audio 10000 RTP/AVP 0 8 97 1411 b=AS:200 1412 a=mid:foo 1413 a=rtpmap:0 PCMU/8000 1414 a=rtpmap:8 PCMA/8000 1415 a=rtpmap:97 iLBC/8000 1416 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1417 m=video 10002 RTP/AVP 31 32 1418 b=AS:1000 1419 a=mid:bar 1420 a=rtpmap:31 H261/90000 1421 a=rtpmap:32 MPV/90000 1422 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1424 SDP Answer (2) 1426 v=0 1427 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1428 s= 1429 c=IN IP4 biloxi.example.com 1430 t=0 0 1431 a=group:BUNDLE foo bar 1432 m=audio 20000 RTP/AVP 0 1433 b=AS:200 1434 a=mid:foo 1435 a=rtpmap:0 PCMU/8000 1436 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1437 m=video 20000 RTP/AVP 32 1438 b=AS:1000 1439 a=mid:bar 1440 a=rtpmap:32 MPV/90000 1441 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1443 SDP Offer (3) 1445 v=0 1446 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1447 s= 1448 c=IN IP4 atlanta.example.com 1449 t=0 0 1450 a=group:BUNDLE foo bar 1451 m=audio 10000 RTP/AVP 0 8 97 1452 b=AS:200 1453 a=mid:foo 1454 a=rtpmap:0 PCMU/8000 1455 a=rtpmap:8 PCMA/8000 1456 a=rtpmap:97 iLBC/8000 1457 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1458 m=video 10000 RTP/AVP 31 32 1459 b=AS:1000 1460 a=mid:bar 1461 a=rtpmap:31 H261/90000 1462 a=rtpmap:32 MPV/90000 1463 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1465 16.2. Example: BUNDLE Extension Rejected 1467 The example below shows: 1469 o 1. An offer, in which the offerer assigns a unique address to 1470 each bundled "m=" line within the BUNDLE group. 1472 o 2. An answer, in which the answerer rejects the offered BUNDLE 1473 group, and assigns a unique addresses to each "m=" line (following 1474 normal RFC 3264 procedures). 1476 SDP Offer (1) 1478 v=0 1479 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1480 s= 1481 c=IN IP4 atlanta.example.com 1482 t=0 0 1483 a=group:BUNDLE foo bar 1484 m=audio 10000 RTP/AVP 0 8 97 1485 b=AS:200 1486 a=mid:foo 1487 a=rtpmap:0 PCMU/8000 1488 a=rtpmap:8 PCMA/8000 1489 a=rtpmap:97 iLBC/8000 1490 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1491 m=video 10002 RTP/AVP 31 32 1492 b=AS:1000 1493 a=mid:bar 1494 a=rtpmap:31 H261/90000 1495 a=rtpmap:32 MPV/90000 1496 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1498 SDP Answer (2) 1500 v=0 1501 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1502 s= 1503 c=IN IP4 biloxi.example.com 1504 t=0 0 1505 m=audio 20000 RTP/AVP 0 1506 b=AS:200 1507 a=rtpmap:0 PCMU/8000 1508 m=video 30000 RTP/AVP 32 1509 b=AS:1000 1510 a=rtpmap:32 MPV/90000 1512 16.3. Example: Offerer Adds A Media Description To A BUNDLE Group 1514 The example below shows: 1516 o 1. A subsequent offer (the BUNDLE group has been created as part 1517 of a previous offer/answer transaction), in which the offerer adds 1518 a new "m=" line, represented by the "zen" identification-tag, to a 1519 previously negotiated BUNDLE group, assigns a unique address to 1520 the added "m=" line, and assigns the previously selected offerer 1521 BUNDLE address to each of the other bundled "m=" lines within the 1522 BUNDLE group. 1524 o 2. An answer, in which the answerer assigns the answerer BUNDLE 1525 address to each bundled "m=" line (including the newly added "m=" 1526 line) within the BUNDLE group. 1528 o 3. A subsequent offer (BAS offer), which is used to perform a 1529 Bundle Address Synchronization (BAS). 1531 SDP Offer (1) 1533 v=0 1534 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1535 s= 1536 c=IN IP4 atlanta.example.com 1537 t=0 0 1538 a=group:BUNDLE foo bar zen 1539 m=audio 10000 RTP/AVP 0 8 97 1540 b=AS:200 1541 a=mid:foo 1542 a=rtpmap:0 PCMU/8000 1543 a=rtpmap:8 PCMA/8000 1544 a=rtpmap:97 iLBC/8000 1545 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1546 m=video 10000 RTP/AVP 31 32 1547 b=AS:1000 1548 a=mid:bar 1549 a=rtpmap:31 H261/90000 1550 a=rtpmap:32 MPV/90000 1551 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1552 m=video 20000 RTP/AVP 66 1553 b=AS:1000 1554 a=mid:zen 1555 a=rtpmap:66 H261/90000 1556 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1558 SDP Answer (2) 1560 v=0 1561 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1562 s= 1563 c=IN IP4 biloxi.example.com 1564 t=0 0 1565 a=group:BUNDLE foo bar zen 1566 m=audio 20000 RTP/AVP 0 1567 b=AS:200 1568 a=mid:foo 1569 a=rtpmap:0 PCMU/8000 1570 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1571 m=video 20000 RTP/AVP 32 1572 b=AS:1000 1573 a=mid:bar 1574 a=rtpmap:32 MPV/90000 1575 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1576 m=video 20000 RTP/AVP 66 1577 b=AS:1000 1578 a=mid:zen 1579 a=rtpmap:66 H261/90000 1580 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1582 SDP Offer (3) 1584 v=0 1585 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1586 s= 1587 c=IN IP4 atlanta.example.com 1588 t=0 0 1589 a=group:BUNDLE foo bar zen 1590 m=audio 10000 RTP/AVP 0 8 97 1591 b=AS:200 1592 a=mid:foo 1593 a=rtpmap:0 PCMU/8000 1594 a=rtpmap:8 PCMA/8000 1595 a=rtpmap:97 iLBC/8000 1596 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1597 m=video 10000 RTP/AVP 31 32 1598 b=AS:1000 1599 a=mid:bar 1600 a=rtpmap:31 H261/90000 1601 a=rtpmap:32 MPV/90000 1602 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1603 m=video 10000 RTP/AVP 66 1604 b=AS:1000 1605 a=mid:zen 1606 a=rtpmap:66 H261/90000 1607 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1609 16.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 1611 The example below shows: 1613 o 1. A subsequent offer (the BUNDLE group has been created as part 1614 of a previous offer/answer transaction), in which the offerer 1615 moves a bundled "m=" line out of a BUNDLE group, assigns a unique 1616 address to the moved "m=" line, and assigns the offerer BUNDLE 1617 address to each other bundled "m=" line within the BUNDLE group. 1619 o 2. An answer, in which the answerer moves the "m=" line out of 1620 the BUNDLE group, assigns unique address to the moved "m=" line, 1621 and assigns the answerer BUNDLE address to each of the remaining 1622 bundled "m=" line within the BUNDLE group. 1624 SDP Offer (1) 1626 v=0 1627 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1628 s= 1629 c=IN IP4 atlanta.example.com 1630 t=0 0 1631 a=group:BUNDLE foo bar 1632 m=audio 10000 RTP/AVP 0 8 97 1633 b=AS:200 1634 a=mid:foo 1635 a=rtpmap:0 PCMU/8000 1636 a=rtpmap:8 PCMA/8000 1637 a=rtpmap:97 iLBC/8000 1638 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1639 m=video 10000 RTP/AVP 31 32 1640 b=AS:1000 1641 a=mid:bar 1642 a=rtpmap:31 H261/90000 1643 a=rtpmap:32 MPV/90000 1644 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1645 m=video 50000 RTP/AVP 66 1646 b=AS:1000 1647 a=mid:zen 1648 a=rtpmap:66 H261/90000 1650 SDP Answer (2) 1652 v=0 1653 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1654 s= 1655 c=IN IP4 biloxi.example.com 1656 t=0 0 1657 a=group:BUNDLE foo bar 1658 m=audio 20000 RTP/AVP 0 1659 b=AS:200 1660 a=mid:foo 1661 a=rtpmap:0 PCMU/8000 1662 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1663 m=video 20000 RTP/AVP 32 1664 b=AS:1000 1665 a=mid:bar 1666 a=rtpmap:32 MPV/90000 1667 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1668 m=video 60000 RTP/AVP 66 1669 b=AS:1000 1670 a=mid:zen 1671 a=rtpmap:66 H261/90000 1673 16.5. Example: Offerer Disables A Media Description Within A BUNDLE 1674 Group 1676 The example below shows: 1678 o 1. A subsequent offer (the BUNDLE group has been created as part 1679 of a previous offer/answer transaction), in which the offerer 1680 disables a bundled "m=" line within BUNDLE group, assigns a zero 1681 port number to the disabled "m=" line, and assigns the offerer 1682 BUNDLE address to each of the other bundled "m=" lines within the 1683 BUNDLE group. 1685 o 2. An answer, in which the answerer moves the disabled "m=" line 1686 out of the BUNDLE group, assigns a zero port value to the disabled 1687 "m=" line, and assigns the answerer BUNDLE address to each of the 1688 remaining bundled "m=" line within the BUNDLE group. 1690 SDP Offer (1) 1692 v=0 1693 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1694 s= 1695 c=IN IP4 atlanta.example.com 1696 t=0 0 1697 a=group:BUNDLE foo bar 1698 m=audio 10000 RTP/AVP 0 8 97 1699 b=AS:200 1700 a=mid:foo 1701 a=rtpmap:0 PCMU/8000 1702 a=rtpmap:8 PCMA/8000 1703 a=rtpmap:97 iLBC/8000 1704 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1705 m=video 10000 RTP/AVP 31 32 1706 b=AS:1000 1707 a=mid:bar 1708 a=rtpmap:31 H261/90000 1709 a=rtpmap:32 MPV/90000 1710 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1711 m=video 0 RTP/AVP 66 1712 a=mid:zen 1713 a=rtpmap:66 H261/90000 1715 SDP Answer (2) 1717 v=0 1718 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 1719 s= 1720 c=IN IP4 biloxi.example.com 1721 t=0 0 1722 a=group:BUNDLE foo bar 1723 m=audio 20000 RTP/AVP 0 1724 b=AS:200 1725 a=mid:foo 1726 a=rtpmap:0 PCMU/8000 1727 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1728 m=video 20000 RTP/AVP 32 1729 b=AS:1000 1730 a=mid:bar 1731 a=rtpmap:32 MPV/90000 1732 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1733 m=video 0 RTP/AVP 66 1734 a=mid:zen 1735 a=rtpmap:66 H261/90000 1737 17. Acknowledgements 1739 The usage of the SDP grouping extension for negotiating bundled media 1740 is based on a similar alternatives proposed by Harald Alvestrand and 1741 Cullen Jennings. The BUNDLE extension described in this document is 1742 based on the different alternative proposals, and text (e.g. SDP 1743 examples) have been borrowed (and, in some cases, modified) from 1744 those alternative proposals. 1746 The SDP examples are also modified versions from the ones in the 1747 Alvestrand proposal. 1749 Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas 1750 Stach and Ari Keraenen for taking the time to read the text along the 1751 way, and providing useful feedback. 1753 18. Change Log 1755 [RFC EDITOR NOTE: Please remove this section when publishing] 1757 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 1759 o - Editorial changes based on comments from Magnus Westerlund. 1761 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 1763 o - Modification of RTP/RTCP multiplexing section, based on comments 1764 from Magnus Westerlund. 1766 o - Reference updates. 1768 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 1770 o - Editorial fix. 1772 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 1774 o - Editorial changes. 1776 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 1778 o Changes to allow a new suggested offerer BUNDLE address to be 1779 assigned to each bundled m- line. 1781 o Changes based on WGLC comments from Paul Kyzivat 1783 o - Editorial fixes 1785 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 1787 o Usage of SDP 'extmap' attribute added 1789 o SDP 'bundle-only' attribute scoped with "m=" lines with a zero 1790 port value 1792 o Changes based on WGLC comments from Thomas Stach 1793 o - ICE candidates not assigned to bundle-only m- lines with a zero 1794 port value 1796 o - Editorial changes 1798 o Changes based on WGLC comments from Colin Perkins 1800 o - Editorial changes: 1802 o -- "RTP SDES item" -> "RTCP SDES item" 1804 o -- "RTP MID SDES item" -> "RTCP MID SDES item" 1806 o - Changes in section 10.1.1: 1808 o -- "SHOULD NOT" -> "MUST NOT" 1810 o -- Additional text added to the Note 1812 o - Change to section 13.2: 1814 o -- Clarify that mid value is not zero terminated 1816 o - Change to section 13.3: 1818 o -- Clarify that mid value is not zero terminated 1820 o -- Clarify padding 1822 o Changes based on WGLC comments from Paul Kyzivat 1824 o - Editorial changes: 1826 o Changes based on WGLC comments from Jonathan Lennox 1828 o - Editorial changes: 1830 o - Defintion of SDP bundle-only attribute alligned with structure 1831 in 4566bis draft 1833 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 1835 o Editorial corrections based on comments from Harald Alvestrand. 1837 o Editorial corrections based on comments from Cullen Jennings. 1839 o Reference update (RFC 7160). 1841 o Clarification about RTCP packet sending when RTP/RTCP multiplexing 1842 is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ 1843 msg13765.html). 1845 o Additional text added to the Security Considerations. 1847 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 1849 o SDP bundle-only attribute added to IANA Considerations. 1851 o SDES item and RTP header extension added to Abstract and 1852 Introduction. 1854 o Modification to text updating section 8.2 of RFC 3264. 1856 o Reference corrections. 1858 o Editorial corrections. 1860 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 1862 o Terminology change: "bundle-only attribute assigned to m= line" to 1863 "bundle-only attribute associated with m= line". 1865 o Editorial corrections. 1867 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 1869 o Editorial corrections. 1871 o - "of"->"if" (8.3.2.5). 1873 o - "optional"->"OPTIONAL" (9.1). 1875 o - Syntax/ABNF for 'bundle-only' attribute added. 1877 o - SDP Offer/Answer sections merged. 1879 o - 'Request new offerer BUNDLE address' section added 1881 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 1883 o OPEN ISSUE regarding Receiver-ID closed. 1885 o - RTP MID SDES Item. 1887 o - RTP MID Header Extension. 1889 o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers 1890 closed. 1892 o - Indicating that, when rtcp-mux is used, the answerer MUST NOT 1893 include an 'rtcp' attribute in the answer, based on the procedures 1894 in section 5.1.3 of RFC 5761. 1896 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 1898 o Draft title changed. 1900 o Added "SDP" to section names containing "Offer" or "Answer". 1902 o Editorial fixes based on comments from Paul Kyzivat 1903 (http://www.ietf.org/mail-archive/web/mmusic/current/ 1904 msg13314.html). 1906 o Editorial fixed based on comments from Colin Perkins 1907 (http://www.ietf.org/mail-archive/web/mmusic/current/ 1908 msg13318.html). 1910 o - Removed text about extending BUNDLE to allow multiple RTP 1911 sessions within a BUNDLE group. 1913 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 1915 o Major re-structure of SDP Offer/Answer sections, to align with RFC 1916 3264 structure. 1918 o Additional definitions added. 1920 o - Shared address. 1922 o - Bundled "m=" line. 1924 o - Bundle-only "m=" line. 1926 o - Offerer suggested BUNDLE mid. 1928 o - Answerer selected BUNDLE mid. 1930 o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address 1931 to multiple "m=" lines until it has received an SDP Answer 1932 indicating support of the BUNDLE extension. 1934 o Q8 Closed (IETF#88): An Offerer can, before it knows whether the 1935 Answerer supports the BUNDLE extension, assign a zero port value 1936 to a 'bundle-only' "m=" line. 1938 o SDP 'bundle-only' attribute section added. 1940 o Connection data nettype/addrtype restrictions added. 1942 o RFC 3264 update section added. 1944 o Indicating that a specific payload type value can be used in 1945 multiple "m=" lines, if the value represents the same codec 1946 configuration in each "m=" line. 1948 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 1950 o Updated Offerer procedures (http://www.ietf.org/mail- 1951 archive/web/mmusic/current/msg12293.html). 1953 o Updated Answerer procedures (http://www.ietf.org/mail- 1954 archive/web/mmusic/current/msg12333.html). 1956 o Usage of SDP 'bundle-only' attribute added. 1958 o Reference to Trickle ICE document added. 1960 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 1962 o Mechanism modified, to be based on usage of SDP Offers with both 1963 different and identical port number values, depending on whether 1964 it is known if the remote endpoint supports the extension. 1966 o Cullen Jennings added as co-author. 1968 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 1970 o No changes. New version due to expiration. 1972 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 1974 o No changes. New version due to expiration. 1976 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 1978 o Draft name changed. 1980 o Harald Alvestrand added as co-author. 1982 o "Multiplex" terminology changed to "bundle". 1984 o Added text about single versus multiple RTP Sessions. 1986 o Added reference to RFC 3550. 1988 19. References 1990 19.1. Normative References 1992 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1993 Requirement Levels", BCP 14, RFC 2119, March 1997. 1995 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1996 with Session Description Protocol (SDP)", RFC 3264, June 1997 2002. 1999 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2000 Description Protocol", RFC 4566, July 2006. 2002 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 2003 Header Extensions", RFC 5285, July 2008. 2005 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2006 Control Packets on a Single Port", RFC 5761, April 2010. 2008 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2009 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 2011 [I-D.mmusic-sdp-mux-attributes] 2012 Nandakumar, S., "A Framework for SDP Attributes when 2013 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-08 2014 (work in progress), January 2015. 2016 19.2. Informative References 2018 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2019 A., Peterson, J., Sparks, R., Handley, M., and E. 2020 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2021 June 2002. 2023 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2024 Jacobson, "RTP: A Transport Protocol for Real-Time 2025 Applications", STD 64, RFC 3550, July 2003. 2027 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2028 in Session Description Protocol (SDP)", RFC 3605, October 2029 2003. 2031 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 2032 Description Protocol (SDP) Security Descriptions for Media 2033 Streams", RFC 4568, July 2006. 2035 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2036 (ICE): A Protocol for Network Address Translator (NAT) 2037 Traversal for Offer/Answer Protocols", RFC 5245, April 2038 2010. 2040 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2041 Media Attributes in the Session Description Protocol 2042 (SDP)", RFC 5576, June 2009. 2044 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2045 Security (DTLS) Extension to Establish Keys for the Secure 2046 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 2048 [RFC7160] Petit-Huguenin, M. and G. Zorn, "Support for Multiple 2049 Clock Rates in an RTP Session", RFC 7160, April 2014. 2051 [I-D.ietf-mmusic-trickle-ice] 2052 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 2053 Incremental Provisioning of Candidates for the Interactive 2054 Connectivity Establishment (ICE) Protocol", draft-ietf- 2055 mmusic-trickle-ice-02 (work in progress), January 2015. 2057 Appendix A. Design Considerations 2059 A.1. General 2061 One of the main issues regarding the BUNDLE grouping extensions has 2062 been whether, in SDP Offers and SDP Answers, the same port value 2063 should be inserted in "m=" lines associated with a BUNDLE group, as 2064 the purpose of the extension is to negotiate the usage of a single 2065 address:port combination for media associated with the "m=" lines. 2066 Issues with both approaches, discussed in the Appendix have been 2067 raised. The outcome was to specify a mechanism which uses SDP Offers 2068 with both different and identical port values. 2070 Below are the primary issues that have been considered when defining 2071 the "BUNDLE" grouping extension: 2073 o 1) Interoperability with existing UAs. 2075 o 2) Interoperability with intermediary B2BUA- and proxy entities. 2077 o 3) Time to gather, and the number of, ICE candidates. 2079 o 4) Different error scenarios, and when they occur. 2081 o 5) SDP Offer/Answer impacts, including usage of port number value 2082 zero. 2084 NOTE: Before this document is published as an RFC, this 2085 Appendix might be removed. 2087 A.2. UA Interoperability 2089 Consider the following SDP Offer/Answer exchange, where Alice sends 2090 an SDP Offer to Bob: 2092 SDP Offer 2094 v=0 2095 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2096 s= 2097 c=IN IP4 atlanta.example.com 2098 t=0 0 2099 m=audio 10000 RTP/AVP 97 2100 a=rtpmap:97 iLBC/8000 2101 m=video 10002 RTP/AVP 97 2102 a=rtpmap:97 H261/90000 2104 SDP Answer 2106 v=0 2107 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 2108 s= 2109 c=IN IP4 biloxi.example.com 2110 t=0 0 2111 m=audio 20000 RTP/AVP 97 2112 a=rtpmap:97 iLBC/8000 2113 m=video 20002 RTP/AVP 97 2114 a=rtpmap:97 H261/90000 2116 RFC 4961 specifies a way of doing symmetric RTP but that is an a 2117 later invention to RTP and Bob can not assume that Alice supports RFC 2118 4961. This means that Alice may be sending RTP from a different port 2119 than 10000 or 10002 - some implementation simply send the RTP from an 2120 ephemeral port. When Bob's endpoint receives an RTP packet, the only 2121 way that Bob know if it should be passed to the video or audio codec 2122 is by looking at the port it was received on. This lead some SDP 2123 implementations to use the fact that each "m=" line had a different 2124 port number to use that port number as an index to find the correct m 2125 line in the SDP. As a result, some implementations that do support 2126 symmetric RTP and ICE still use a SDP data structure where SDP with 2127 "m=" lines with the same port such as: 2129 SDP Offer 2131 v=0 2132 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2133 s= 2134 c=IN IP4 atlanta.example.com 2135 t=0 0 2136 m=audio 10000 RTP/AVP 97 2137 a=rtpmap:97 iLBC/8000 2138 m=video 10000 RTP/AVP 98 2139 a=rtpmap:98 H261/90000 2141 will result in the second "m=" line being considered an SDP error 2142 because it has the same port as the first line. 2144 A.3. Usage of port number value zero 2146 In an SDP Offer or SDP Answer, the media associated with an "m=" line 2147 can be disabled/rejected by setting the port number value to zero. 2148 This is different from e.g. using the SDP direction attributes, where 2149 RTCP traffic will continue even if the SDP "inactive" attribute is 2150 indicated for the associated "m=" line. 2152 If each "m=" line associated with a BUNDLE group would contain 2153 different port values, and one of those port values would be used for 2154 a BUNDLE address associated with the BUNDLE group, problems would 2155 occur if an endpoint wants to disable/reject the "m=" line associated 2156 with that port, by setting the port value to zero. After that, no 2157 "m=" line would contain the port value which is used for the BUNDLE 2158 address. In addition, it is unclear what would happen to the ICE 2159 candidates associated with the "m=" line, as they are also used for 2160 the BUNDLE address. 2162 A.4. B2BUA And Proxy Interoperability 2164 Some back to back user agents may be configured in a mode where if 2165 the incoming call leg contains an SDP attribute the B2BUA does not 2166 understand, the B2BUS still generates that SDP attribute in the Offer 2167 for the outgoing call leg. Consider an B2BUA that did not understand 2168 the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. 2169 Further assume that the B2BUA was configured to tear down any call 2170 where it did not see any RTCP for 5 minutes. In this cases, if the 2171 B2BUA received an Offer like: 2173 SDP Offer 2175 v=0 2176 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2177 s= 2178 c=IN IP4 atlanta.example.com 2179 t=0 0 2180 m=audio 49170 RTP/AVP 0 2181 a=rtcp:53020 2183 It would be looking for RTCP on port 49172 but would not see any 2184 because the RTCP would be on port 53020 and after five minutes, it 2185 would tear down the call. Similarly, an SBC that did not understand 2186 BUNDLE yet put BUNDLE in it's offer may be looking for media on the 2187 wrong port and tear down the call. It is worth noting that a B2BUA 2188 that generated an Offer with capabilities it does not understand is 2189 not compliant with the specifications. 2191 A.4.1. Traffic Policing 2193 Sometimes intermediaries do not act as B2BUA, in the sense that they 2194 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2195 however, they may use SDP information (e.g. IP address and port) in 2196 order to control traffic gating functions, and to set traffic 2197 policing rules. There might be rules which will trigger a session to 2198 be terminated in case media is not sent or received on the ports 2199 retrieved from the SDP. This typically occurs once the session is 2200 already established and ongoing. 2202 A.4.2. Bandwidth Allocation 2204 Sometimes intermediaries do not act as B2BUA, in the sense that they 2205 don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 2206 however, they may use SDP information (e.g. codecs and media types) 2207 in order to control bandwidth allocation functions. The bandwidth 2208 allocation is done per "m=" line, which means that it might not be 2209 enough if media associated with all "m=" lines try to use that 2210 bandwidth. That may either simply lead to bad user experience, or to 2211 termination of the call. 2213 A.5. Candidate Gathering 2215 When using ICE, an candidate needs to be gathered for each port. 2216 This takes approximately 20 ms extra for each extra "m=" line due to 2217 the NAT pacing requirements. All of this gather can be overlapped 2218 with other things while the page is loading to minimize the impact. 2219 If the client only wants to generate TURN or STUN ICE candidates for 2220 one of the "m=" lines and then use trickle ICE 2221 [I-D.ietf-mmusic-trickle-ice] to get the non host ICE candidates for 2222 the rest of the "m=" lines, it MAY do that and will not need any 2223 additional gathering time. 2225 Some people have suggested a TURN extension to get a bunch of TURN 2226 allocation at once. This would only provide a single STUN result so 2227 in cases where the other end did not support BUNDLE, may cause more 2228 use of the TURN server but would be quick in the cases where both 2229 sides supported BUNDLE and would fall back to a successful call in 2230 the other cases. 2232 Authors' Addresses 2234 Christer Holmberg 2235 Ericsson 2236 Hirsalantie 11 2237 Jorvas 02420 2238 Finland 2240 Email: christer.holmberg@ericsson.com 2242 Harald Tveit Alvestrand 2243 Google 2244 Kungsbron 2 2245 Stockholm 11122 2246 Sweden 2248 Email: harald@alvestrand.no 2250 Cullen Jennings 2251 Cisco 2252 400 3rd Avenue SW, Suite 350 2253 Calgary, AB T2P 4H2 2254 Canada 2256 Email: fluffy@iii.ca