idnits 2.17.1 draft-worley-sdp-bundle-06.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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 12 characters in excess of 72. == There are 27 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1067 has weird spacing: '...ejected x ...' == Line 1078 has weird spacing: '...istinct x ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 15, 2013) is 4058 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) == Unused Reference: 'RFC5245' is defined on line 1648, but no explicit reference was found in the text == Unused Reference: 'RFC4960' is defined on line 1670, but no explicit reference was found in the text == Unused Reference: 'I-D.roach-mmusic-mlines' is defined on line 1716, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-13) exists of draft-ietf-avtcore-multi-media-rtp-session-02 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-03 == Outdated reference: A later version (-07) exists of draft-westerlund-avtcore-transport-multiplexing-05 == Outdated reference: A later version (-15) exists of draft-worley-service-example-11 Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rtcweb D. R. Worley 3 Internet-Draft Ariadne 4 Intended status: Standards Track March 15, 2013 5 Expires: September 16, 2013 7 A Generic Bundle Mechanism for the Session Description Protocol (SDP) 8 draft-worley-sdp-bundle-06 10 Abstract 12 This document defines a generic bundle mechanism for the Session 13 Description Protocol (SDP) by which the media described by a number 14 of media descriptions ("m= lines") are multiplexed and transmitted 15 over a single transport association. The single transport 16 association is described by an additional media description, allowing 17 SDP attributes to be applied to the aggregate, independently of 18 attributes applied to the constituents. In offer/answer usage, the 19 bundle mechanism is backward compatible with SDP processors that do 20 not understand the mechanism. The mechanism is designed to be 21 compatible with the limitations of the existing Internet 22 infrastructure. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 16, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Desiderata . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Feature Desiderata . . . . . . . . . . . . . . . . . . . 6 62 3.2. Compatibility Desiderata . . . . . . . . . . . . . . . . 8 63 4. Tutorial Examples . . . . . . . . . . . . . . . . . . . . . . 10 64 4.1. One Audio Stream and One Video Stream . . . . . . . . . . 10 65 4.1.1. Offer without Bundling . . . . . . . . . . . . . . . 10 66 4.1.2. Offer with Bundling . . . . . . . . . . . . . . . . . 11 67 4.1.3. Answer from an Answerer that Supports Bundling . . . 13 68 4.1.4. Answer from an Answerer that Does Not Support 69 Bundling . . . . . . . . . . . . . . . . . . . . . . 14 70 4.1.5. Fast-Start Offer . . . . . . . . . . . . . . . . . . 16 71 4.2. Two Audio Streams and Two Video Streams . . . . . . . . . 17 72 4.3. Virtual Classroom with One Audio Stream, Two Video 73 Streams, and a Group of Video Streams . . . . . . . . . . 19 74 4.4. One Audio Stream and Two SCTP Streams . . . . . . . . . . 21 75 5. Syntax and Semantics . . . . . . . . . . . . . . . . . . . . 21 76 5.1. Constructing an Offer . . . . . . . . . . . . . . . . . . 21 77 5.2. Constructing an Answer . . . . . . . . . . . . . . . . . 21 78 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 22 79 5.4. RTCP, SSRC, and RTP Sessions . . . . . . . . . . . . . . 22 80 5.5. ICE considerations . . . . . . . . . . . . . . . . . . . 22 81 5.6. Encryption considerations . . . . . . . . . . . . . . . . 22 82 6. Compatibility Considerations . . . . . . . . . . . . . . . . 22 83 6.1. Backward Compatibility during Offer/Answer . . . . . . . 22 84 6.2. Backward Compatibility with Existing Devices . . . . . . 22 85 7. Design Features and Comparison . . . . . . . . . . . . . . . 22 86 7.1. Aggregation of Constituent Media Descriptions . . . . . . 24 87 7.2. Presence of a Bundle Media Description and Its Media Type 24 88 7.3. Immediate Update . . . . . . . . . . . . . . . . . . . . 24 89 7.4. Effective Media Description Ports after Session 90 Establishment . . . . . . . . . . . . . . . . . . . . . . 25 91 7.5. Payload Types in the Bundled Media Description . . . . . 25 92 7.6. Relationship of Payload Types of Constituent Media 93 Descriptions . . . . . . . . . . . . . . . . . . . . . . 26 94 7.7. Basis of Demultiplexing . . . . . . . . . . . . . . . . . 26 95 7.8. Basis of Rejection of the Bundle MD . . . . . . . . . . . 26 96 7.9. How Constituent MDs Are Offered . . . . . . . . . . . . . 27 98 8. Demultiplexing Considerations . . . . . . . . . . . . . . . . 30 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 100 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 101 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 102 12. Revision History . . . . . . . . . . . . . . . . . . . . . . 34 103 12.1. draft-worley-sdp-bundle-00 . . . . . . . . . . . . . . . 34 104 12.2. Changes from draft-worley-sdp-bundle-00 to draft-worley- 105 sdp-bundle-01 . . . . . . . . . . . . . . . . . . . . . 34 106 12.3. Changes from draft-worley-sdp-bundle-01 to draft-worley- 107 sdp-bundle-02 . . . . . . . . . . . . . . . . . . . . . 34 108 12.4. Changes from draft-worley-sdp-bundle-02 to draft-worley- 109 sdp-bundle-03 . . . . . . . . . . . . . . . . . . . . . 34 110 12.5. Changes from draft-worley-sdp-bundle-03 to draft-worley- 111 sdp-bundle-04 . . . . . . . . . . . . . . . . . . . . . 35 112 12.6. Changes from draft-worley-sdp-bundle-04 to draft-worley- 113 sdp-bundle-05 . . . . . . . . . . . . . . . . . . . . . 35 114 12.7. Changes from draft-worley-sdp-bundle-05 to draft-worley- 115 sdp-bundle-06 . . . . . . . . . . . . . . . . . . . . . 35 116 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 117 13.1. Normative References . . . . . . . . . . . . . . . . . . 36 118 13.2. Informative References . . . . . . . . . . . . . . . . . 36 119 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38 121 1. Introduction 123 The central idea of bundling is to multiplex the media that would be 124 several transport flows into one transport flow, with particular 125 emphasis on allowing one transport association to carry media that 126 are presented to the higher, application layer, as multiple transport 127 flows. 129 At the interface between the SDP-configured layer and the lower, 130 transport layer, the media are organized into a single transport 131 flow. The transport-related properties of the RTP session (e.g., 132 transport 5-tuple, encryption, ICE) are described by the transport- 133 related attributes of a single media description. 135 At the interface between the SDP-configured layer and the higher, 136 application layer, the media are organized into several transport 137 flows. The application-related properties of the transport flow 138 (e.g., media type and label) are described by the application-related 139 attributes of separate media descriptions. 141 (There are some attributes (e.g., bandwidth limitation) that can 142 apply separately to both the bundled transport flow and the 143 constituent transport flows.) 144 However, we do not include the payload type numbers as information 145 available to the application; only the encoding name and its 146 parameters are accessible to the application. This gives the bundle 147 mechanism freedom to place constraints on the use of payload types. 149 The bundle is signaled in the session description by a "group" 150 attribute with semantics "BUNDLE". The first media description 151 listed in the group is the "bundle" media description (MD), whose 152 transport information describes the transport association via which 153 the packets will be sent. The remaining (zero or more) media 154 descriptions listed in the group are the "constituent" MDs. Packets 155 (either RTP/RTCP/SRTP/SRTCP, SCTP, or SCTP-over-DTLS) received from 156 the applications for these MDs are sent (unaltered) on the transport 157 association for the bundle MD. Packets received from the transport 158 association for the bundle MD are demultiplexed (based on particular 159 features of the constituent transport flow protocols and the payload 160 types and SCTP ports specified in the constituent MDs) and sent to 161 the applications for the constituent MDs. 163 In offer/answer usage, we must arrange that the bundle mechanism is 164 backward compatible with entities that do not understand the bundle 165 mechanism. This requirement drives many features of this solution. 166 Section 6.1 168 In addition, many devices in current usage (especially SBCs) apply 169 more restrictions on the usage of SDP than one would expect from 170 abstract consideration of their roles in the network. Some features 171 of this solution are constructed to avoid these restrictions. 172 Section 6.2 174 2. Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 The important RFCs in this area use inconsistent terminology. Here, 181 we use: 183 media Media is (1) media content, considered in an abstract way, 184 that is, without consideration of its particular encoding or the 185 framing information around it, and (2) the particular bits and 186 octets used to encode and transmit the abstract media content. 188 media stream (Taken from [RFC3550].) A media stream is a set of RTP 189 packets that are generated by and interpreted by one codec. The 190 RTP packets of a media stream are identified by a unique SSRC. 192 capture (Taken from CLUE's work.) A capture is a set of media 193 streams that originate from one (physical or virtual) media source 194 and should be composed to provide rendering of that source. For 195 example, media streams from one origin including layered 196 encodings, forward error correction streams, recovery streams, and 197 simulcasted media streams of varying bit rates compose one 198 capture. 200 transport association (Taken from [I-D.alvestrand-mmusic-msid].) A 201 transport association is a single data path between two hosts, 202 such as a TCP connection, or a pair of UDP ports that send packets 203 to each other. A transport association is identified by the 204 identity of the protocol being used, the relevant host addresses, 205 and the relevant port numbers. In the case of unicast 206 communications, these form a "5-tuple", namely, the protocol, the 207 host addresses of the two hosts, and the port numbers used on the 208 two hosts. In the case of multicast sessions, these form a 209 "3-tuple", namely, the protocol, the multicast address, and the 210 port number. In SDP, a transport association is specified by the 211 address and port of a media description (and possibly the same 212 information from the matching offer/answer SDP). If a media 213 description specifies multiple addresses or ports, each address or 214 port specifies one transport association. 216 transport flow (Taken from 217 [I-D.ietf-avtcore-multi-media-rtp-session].) (This is called an 218 "RTP session" by [RFC3264].) A transport flow is the data that 219 flows across a transport association. 221 media description (Taken from [RFC4566].) A media description is 222 one group of lines in a session description demarcated by an m= 223 line. By synecdoche, a media description is often referred to as 224 "an m= line". 226 transport association group A transport association group is the set 227 of transport associations denoted by one media description. 228 Usually the m= line specifies only one port and the c= line 229 specifies only one address, and so the media description's 230 transport association group contains only one transport 231 association. 233 transport flow group A transport flow group is the set of transport 234 flows of the transport associations of a transport association 235 group. 237 session description (Taken from [RFC4566] section 2.) A session 238 description is an SDP instance. 240 multimedia session (Taken from [RFC4566] section 2.) A multimedia 241 session is the totality of the media that is transmitted/received 242 as described by a particular session description. 244 RTP session (Taken from [RFC3550].) An RTP session is a group of 245 media streams which must not have duplicated SSRC values because 246 the endpoints share RTCP reporting information. Note that an RTP 247 session may encompass more than one multimedia session. RTP 248 sessions are not fully described by session descriptions. 250 3. Desiderata 252 This section lists desiderata for the bundle mechanism in SDP. (I 253 use the term "desiderata" -- "things that are desired" -- rather than 254 "requirements", because we may discover that we can't optimally 255 satisfy all of these criteria at the same time.) The first section 256 lists desiderata that are arise from considering the ways 257 applications may wish to bundling. The second section lists 258 desiderata that arise from compatibility with existing Internet 259 infrastructure. 261 3.1. Feature Desiderata 263 These desiderata describe features that we would like the bundling 264 mechanism to provide. 266 DES F1 For each bundle, there is a group of media descriptions which 267 describe the application-level RTP sessions. This specification 268 must allow the same granularity of description as when the media 269 flows were not multiplexed. This description includes identifiers 270 which connect the media flows with the application and with each 271 other. 273 This requirement is taken from [I-D.jennings-mmusic-media-req]. 275 DES F2 For each bundle, there is a media description that describes 276 the transport-level RTP session. 278 DES F1 and DES F2 do not specify whether the transport-level media 279 description may or may not also be one of the application-level media 280 descriptions. 282 DES F3 There must be a uniform way to deal with new SDP parameters, 283 so that newly defined SDP parameters do not require a specific 284 updating of the bundling procedures. 286 This desideratum is taken from slides-interim-2013-rtcweb-1-10.pdf. 288 DES F4 Multiple separate bundles within one SDP must be supported. 290 DES F5 Bundles may contain other bundles as constituents. 292 Of course, no bundle may directly or indirectly contain itself. (I 293 don't expect any current implementation to implement bundles within 294 bundles, but we should design the mechanism to allow this, as some 295 day we will likely need it.) 297 DES F6 A bundle may contain zero constituents. 299 A bundle with no constituents serves no purpose for the transport of 300 media, but we are likely to someday need to describe such a bundle. 301 (Compare that an SDP m= line is syntactically constrained to specify 302 at least one payload type. When SDP was used only to specify 303 multicast sessions, this constraint was common sense. But once SDP 304 offer/answer was invented, when a media description was rejected, the 305 natural representation would be an m= line with a zero port and no 306 payload types. But a payload type was syntactically required, so we 307 now have to provide at least one token payload type in rejected m= 308 lines.) 310 DES F7 If an answerer that does understand the bundle mechanism 311 processes an offer that contains a bundle, it must be able to (1) 312 accept the bundle and selectively accept or reject each 313 constituent RTP session within it, (2) reject the bundle as a 314 whole, or (3) reject the bundling and selectively accept or reject 315 each constituent RTP session as separate RTP sessions. 317 Presumably answer (3) resembles that which would be produced by an 318 answerer that does not understand the bundle mechanism. It is a 319 lower priority that the answerer can distinguish between accepting 320 the bundle while rejecting all of its constituents, and rejecting the 321 bundle as a whole. But those two conditions differ conceptually 322 regarding whether any "framing" actions of the bundle are performed. 324 DES F8 There must be a reliable way to demultiplex incoming RTP into 325 the separate application-level RTP sessions. Similarly, there 326 must be a reliable way to demultiplex the associated RTCP 327 information. 329 The RTCP information for each media stream is tagged with the SSRC 330 about which it reports, and the SSRC is used to correlate the RTCP 331 reports with the RTP sessions containing media with the same SSRC. 332 So regarding RTCP, this desideratum appears to be straightforward to 333 satisfy. 335 DES F9 The specification must specify any needed additional 336 procedures for handling SSRC collisions between media sources 337 within different application-level RTP sessions, as those can now 338 collide. 340 In the terminology of [RFC3550], the constituent media descriptions 341 are now part of one RTP session. 343 DES F10 When an offer is constructed, the offerer must not need to 344 preallocate TURN relays for constituent media descriptions. When 345 both endpoints support bundling, the mechanism must not require 346 the offerer to allocate TURN relays for constituent media 347 descriptions. 349 This desideratum was suggested by Andrew Hutton. 351 DES F11 It must be possible to add and remove one way video flows 352 within the bundle without requiring an additional offer/answer 353 cycle. 355 Presumably this can be accomplished as it is now, with a single media 356 description carrying multiple video flows that are distinguished only 357 by their SSRCs. This desideratum is taken from slides- 358 interim-2013-rtcweb-1-10.pdf. 360 DES F12 Bundling must not interfere with ICE usage, and in 361 particular, ICE's ability to negotiate both IPv4 and IPv6 362 addresses simultaneously. 364 This desideratum was suggested by Andrew Hutton. 366 DES F13 It is desirable for RTP media to appear on the wire as 367 (encrypted) SRTP packets and for RTCP reports to appear on the 368 wire as (authenticated but not encrypted) SRTCP packets. Thus, 369 encryption of RTP/RTCP via DTLS and encapsulation of multiplexed 370 packets is not desirable. 372 This desideratum was suggested by Martin Thompson (http:// 373 www.ietf.org/mail-archive/web/mmusic/current/msg10400.html) and Dan 374 Wing (http://www.ietf.org/mail-archive/web/mmusic/current/ 375 msg10408.html). 377 3.2. Compatibility Desiderata 379 These desiderata describe compatibility of the bundling mechanism 380 with with non-supporting endpoints or with existing entities in the 381 Internet infrastructure. 383 DES C1 In offer/answer usage, an endpoint using the bundle mechanism 384 must interwork correctly with an endpoint that does not understand 385 the bundle mechanism. 387 DES C2 Interworking must continue when SDP endpoints are replaced 388 with other endpoints during a sequence of offer/answer exchanges 389 (such as happens in 3PCC or call transfers "behind an SBC"), 390 including when a supporting endpoint is replaced by a non- 391 supporting endpoint or vice-versa. 393 SDP features (e.g., the codec set and ICE) are generally designed so 394 that an offerer always offers every facility it is willing to support 395 in the current situation, regardless of whether it was agreed to by 396 the answerer in a preceding exchange. Thus, if the current answerer 397 is a different endpoint than the previous answerer, the new answerer 398 will negotiate a compatible set of facilities without needing 399 knowledge of its predecessor's SDP. The offerer will smoothly 400 transition to the new facilities. This property is required to 401 support 3PCC situations (e.g., [RFC3725] and 402 [I-D.worley-service-example]). This desideratum was suggested by 403 Richard Ejzak. 405 DES C3 Avoid using media types in m= lines other than audio and 406 video unless required for user media, as some SBCs reject SDP that 407 uses other media types. 409 This desideratum was suggested by Hadriel Kaplan. 411 DES C4 Any additional m= lines prescribed by the bundle mechanism 412 should be ordered after the constituent m= lines. 414 Many devices that have only one audio or video channel accept the 415 first m= line with that media type and reject any further ones 417 non-DES C5 SBCs generally pass through attributes that they do not 418 understand. SBCs generally pass through codec specifications that 419 they do not understand, even if they are configured to transcode 420 certain specific codecs. 422 This non-desideratum was suggested by Hadriel Kaplan. 424 DES C6 After offer/answer processing is finished, if the exchanged 425 SDP is examined by a non-supporting SBC, the set of transport 426 associations that it sees being specified for media exchange 427 should be the set that are actually used for media transfer. 429 This is needed because SBCs monitor the packet traffic on the 430 transport associations and if no media is seen on one of the 431 associations for a significant period of time, the SBC will tear down 432 the call. This desideratum was suggested by Hadriel Kaplan. 434 DES C7 In a session description, no endpoint of a transport 435 association may be used multiple times. 437 Such duplication is not defined by [RFC4566]. Some SBCs do not 438 support such duplication (ultimately, because it was not supported by 439 [RFC2327]), and they reject SDP specifying duplicated transport 440 association endpoints. This desideratum was suggested by Cullen 441 Jennings. 443 DES C8 Offer/answer processing between supporting processors must be 444 completed in one exchange. When interworking between supporting 445 and non-supporting processors, it is less desirable but admissible 446 that a second offer/answer exchange may be needed to complete 447 configuring the multimedia session. 449 DES C9 If an intermediate entity provides transcoding between 450 codecs, and if the offer/answer does not specify encryption of a 451 media stream, the media stream should be able to take advantage of 452 the transcoding facility. 454 The non-encrypted case is not expected to be very common. Encrypted 455 media can't be transcoded by an intermediate entity. 457 4. Tutorial Examples 459 This section is non-normative. (This section was suggested by 460 Charles Eckel.) 462 This is an introduction to SDP bundling via a series of examples of 463 offer/answer processing. Some mandatory SDP lines have been omitted 464 from the examples for brevity. Long SDP lines have been folded by 465 using trailing backslashes. Blank lines have been inserted for 466 clarity. 468 4.1. One Audio Stream and One Video Stream 470 4.1.1. Offer without Bundling 472 Here is a typical, non-bundled SDP example with both audio and video 473 media: 475 o=- 2890844526 2890844526 IN IP4 host.example.com 476 c=IN IP4 host.example.com 478 This SDP media description (MD) provides the transport information 479 about the audio and also identifies the role of the audio from the 480 application's point of view. In this case, the fact that it is the 481 first audio m= line suffices to tell the application how to treat it. 482 In more complex cases, label or content attributes might be used to 483 communicate the proper handling to the application. 485 m=audio 10000 RTP/AVP 0 8 97 486 a=rtcp-mux 487 a=rtpmap:0 PCMU/8000 488 a=rtpmap:8 PCMA/8000 489 a=rtpmap:97 iLBC/8000 490 a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host 491 a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx 492 a=candidate:2 1 UDP 1006633215 10.0.100.1 31000 typ relay 494 This MD provides the transport information about the video and also 495 identifies the role of the video from the application's point of view. 497 m=video 10002 RTP/AVP 31 32 498 a=rtcp-mux 499 a=rtpmap:31 H261/90000 500 a=rtpmap:32 MPV/90000 501 a=candidate:0 1 UDP 2113601791 10.0.1.1 10002 typ host 502 a=candidate:1 1 UDP 1694194431 198.51.100.32 51002 typ srflx 503 a=candidate:2 1 UDP 1006633215 10.0.100.1 31002 typ relay 505 We call the RTP that is described by each media description (MD) a 506 transport flow (TF). The audio and video are carried in separate 507 TFs, which each have a separate transport association (address/port). 509 4.1.2. Offer with Bundling 511 With SDP bundling, we add an additional MD to describe a single 512 "bundle" TF to carry both the audio and video information, and a 513 group attribute to show the association of the bundle MD with the 514 constituent MDs: 516 o=- 2890844526 2890844526 IN IP4 host.example.com 517 c=IN IP4 host.example.com 519 The following group attribute declares which MDs are included in the 520 multiplexed MD: mid:con1 and mid:con2 are the constituent MDs whose 521 TFs (from the application point of view) will be carried by the TF of 522 the first-designed MD, mid:bundle, which is the bundle MD. In order 523 to allow demultiplexing of the packets on the bundle TF, the 524 constituent MDs must use disjoint sets of payload types. 526 a=group:BUNDLE bundle con1 con2 528 This MD provides the application-level description of the audio TF. 529 As in the previous example, it is the first audio m= line. It 530 includes any attributes which apply to the audio media from the 531 application point of view, including the payload type definitions. 532 When interpreted by a supporting processor, the transport information 533 is ignored. When interpreted by a processor that does not support 534 bundling, the transport information sets up the transport association 535 for the audio TF. But to avoid the overhead of preallocating TURN 536 relays that will probably not be used, ICE relay candidates are not 537 provided. 539 m=audio 10000 RTP/AVP 0 8 97 540 a=mid:con1 541 a=rtcp-mux 542 a=rtpmap:0 PCMU/8000 543 a=rtpmap:8 PCMA/8000 544 a=rtpmap:97 iLBC/8000 545 a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host 546 a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx 548 This MD provides the application-level description of the video TF. 549 As in the previous example, it is the first video m= line. It 550 includes any attributes which apply to the video media from the 551 application point of view. As in the audio MD, the association 552 information is used only by a processor that does not support 553 bundling. 555 m=video 10002 RTP/AVP 31 32 556 a=mid:con2 557 a=rtcp-mux 558 a=rtpmap:31 H261/90000 559 a=rtpmap:32 MPV/90000 560 a=candidate:0 1 UDP 2113601791 10.0.1.1 10002 typ host 561 a=candidate:1 1 UDP 1694194431 198.51.100.32 51002 typ srflx 563 This MD provides the transport information for the bundle TF, 564 including any attributes which apply to the transport. We use RTCP 565 multiplexing [RFC5761], so only one set of ICE candidates (and only 566 one TURN relay) is needed for this MD. 568 The MD is artificially given the media type "audio" (which is ugly, 569 but it avoids rejection by SBCs) and it is placed after all of the 570 constituent MDs so as to not affect their positions as "first audio 571 MD", etc. The MD has a proto value of "bundle" to describe the packet 572 traffic (which in general can be a mixture of RTP/SRTP/RTCP/SRTCP, 573 SCTP, and DTLS). A single, dummy fmt value of 0 is used. The proto 574 value ensures that an answerer that does not support bundling will not 575 accept this MD. 577 The packets sent on this transport flow are the packets provided by 578 the applications for the constituent transport flows. 580 m=audio 10004 bundle 0 581 a=mid:bundle 582 a=candidate:0 1 UDP 2113601791 10.0.1.1 10004 typ host 583 a=candidate:1 1 UDP 1694194431 198.51.100.32 51004 typ srflx 584 a=candidate:2 1 UDP 1006633215 10.0.100.1 31004 typ relay 586 If this SDP bundle is accepted, RTP provided by the application for 587 the audio TF will be sent from port 10004. RTP provided by the 588 application for the video TF will be also be sent from port 10004. 590 RTP that is received on port 10004 is interpreted according to the 591 payload type number. Since the payload type numbers used in the two 592 constituent transport flows are disjoint, incoming RTP packets can be 593 directed to the proper applications based on payload type number. 595 4.1.3. Answer from an Answerer that Supports Bundling 597 If the answerer supports SDP bundling, and desires to accept the 598 offered bundle and its constituent MDs, the answerer signals that it 599 accepts the SDP bundling by providing a matching group:BUNDLE 600 attribute in the answer. As always in offer/answer, the MDs in the 601 answer correspond to the MDs in the offer by ordinal position. 603 The answerer provides the necessary transport information for the 604 bundle MD. The answerer understands that MDs mid:con1 and mid:con2 605 are incorporated into MD mid:bundle, and ignores their transport 606 information. It accepts each constituent MD as part of the bundle by 607 providing an answer MD for each of them that specifies an attribute 608 "a=bundleaccept" and a port number of 0 (so intermediate entities see 609 the MD as being rejected). 611 Note that the constituent MDs, despite having zero port numbers, are 612 still incorporated in the "a=group:BUNDLE" attribute. This 613 contravenes [RFC5888] section 9.2, and so this proposal requires an 614 extension of RFC 5888. 616 o=- 2890844526 2890844526 IN IP4 answer.example.com 617 c=IN IP4 answer.example.com 619 a=group:BUNDLE bundle con1 con2 620 m=audio 0 RTP/AVP 0 8 97 621 a=mid:con1 622 a=bundleaccept 623 a=rtcp-mux 624 a=rtpmap:0 PCMU/8000 625 a=rtpmap:8 PCMA/8000 626 a=rtpmap:97 iLBC/8000 628 m=video 0 RTP/AVP 31 32 629 a=mid:con2 630 a=bundleaccept 631 a=rtcp-mux 632 a=rtpmap:31 H261/90000 633 a=rtpmap:32 MPV/90000 635 m=audio 20000 bundle 0 636 a=mid:bundle 637 a=candidate:0 1 UDP 2113601791 10.0.2.1 20000 typ host 638 a=candidate:1 1 UDP 1694194431 198.51.100.35 51090 typ srflx 639 a=candidate:2 1 UDP 1006633215 10.0.100.1 32000 typ relay 641 4.1.4. Answer from an Answerer that Does Not Support Bundling 643 SDP bundling allows for backward compatibility in case the answerer 644 does not understand bundling. If the answerer does not understand 645 bundling, it ignores the group attribute, and effectively sees the 646 offer as: 648 o=- 2890844526 2890844526 IN IP4 host.example.com 649 c=IN IP4 host.example.com 651 m=audio 10000 RTP/AVP 0 8 97 652 a=rtcp-mux 653 a=rtpmap:0 PCMU/8000 654 a=rtpmap:8 PCMA/8000 655 a=rtpmap:97 iLBC/8000 656 a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host 657 a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx 659 m=video 10002 RTP/AVP 31 32 660 a=rtcp-mux 661 a=rtpmap:31 H261/90000 662 a=rtpmap:32 MPV/90000 663 a=candidate:0 1 UDP 2113601791 10.0.1.1 10002 typ host 664 a=candidate:1 1 UDP 1694194431 198.51.100.32 51002 typ srflx 666 m=audio 10004 bundle 0 667 a=candidate:0 1 UDP 2113601791 10.0.1.1 10004 typ host 668 a=candidate:1 1 UDP 1694194431 198.51.100.32 51004 typ srflx 669 a=candidate:2 1 UDP 1006633215 10.0.100.1 31004 typ relay 671 If the answerer wishes to accept the first audio and video streams, 672 it assembles this answer: 674 o=- 2890844526 2890844526 IN IP4 answer.example.com 675 c=IN IP4 answer.example.com 677 The absence of the group attribute informs the offerer that bundling 678 was rejected. 680 The audio MD is accepted. Transport information is provided, 681 including ICE candidates. 683 m=audio 20000 RTP/AVP 0 8 97 684 a=rtcp-mux 685 a=rtpmap:0 PCMU/8000 686 a=rtpmap:8 PCMA/8000 687 a=rtpmap:97 iLBC/8000 688 a=candidate:0 1 UDP 2113601791 10.0.2.1 20000 typ host 689 a=candidate:1 1 UDP 1694194431 198.51.100.128 52000 typ srflx 691 The video MD is accepted. Transport information (using a different 692 port) is provided. 694 m=audio 20002 RTP/AVP 31 32 695 a=rtcp-mux 696 a=rtpmap:31 H261/90000 697 a=rtpmap:32 MPV/90000 698 a=candidate:0 1 UDP 2113601791 10.0.2.1 20002 typ host 699 a=candidate:1 1 UDP 1694194431 198.51.100.128 52002 typ srflx 701 The bundle MD is rejected by the answerer because the proto value is 702 "bundle", and the answerer does not implement it. 704 m=audio 0 bundle 0 706 Because the group attribute is not present in the response, the 707 offerer knows that the answerer does not support bundling (or does 708 not want to consider the offered bundle). The offerer knows that the 709 answerer wants to establish one audio TF and one video TF, and 710 formally, that has been done. But if transport requires ICE relay 711 candidates on the offerer's side, the offerer must send an updated 712 offer containing those ICE candidates for the constituent MDs: 714 o=- 2890844526 2890844527 IN IP4 host.example.com 715 c=IN IP4 host.example.com 717 No group attribute is included, to ensure that this update only 718 revises transport attributes, and does not trigger bundle-supporting 719 behavior if the answering entity has changed in the meantime. 721 Provide ICE relay candidates for the audio MD. 723 m=audio 10000 RTP/AVP 0 8 97 724 a=mid:con1 725 a=rtcp-mux 726 a=rtpmap:0 PCMU/8000 727 a=rtpmap:8 PCMA/8000 728 a=rtpmap:97 iLBC/8000 729 a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host 730 a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx 731 a=candidate:2 1 UDP 1006633215 10.0.100.1 31000 typ relay 733 Provide a separate TURN relay for the video MD. 735 m=video 10002 RTP/AVP 31 32 736 a=mid:con2 737 a=rtcp-mux 738 a=rtpmap:31 H261/90000 739 a=rtpmap:32 MPV/90000 740 a=candidate:0 1 UDP 2113601791 10.0.1.1 10002 typ host 741 a=candidate:1 1 UDP 1694194431 198.51.100.32 51002 typ srflx 742 a=candidate:2 1 UDP 1006633215 10.0.100.1 31002 typ relay 744 The bundle MD must still be listed, but it is disabled. 746 m=audio 0 bundle 0 747 a=mid:bundle 749 The answerer provides the same answer as before. 751 The ICE renegotiation proceeds, the transport associations are 752 established, and RTP flows. 754 4.1.5. Fast-Start Offer 756 The baseline procedure requires the offerer to update its offer when 757 it discovers that the answerer does not support SDP bundling if TURN 758 relays are needed to support the constituent MDs. The offerer can 759 avoid this delay by providing TURN relays for the constituent MDs as 760 well as for the bundle MD. The penalty is that the offerer must 761 preallocate TURN relays for both the constituent MDs as well as the 762 bundle MD. 764 o=- 2890844526 2890844526 IN IP4 host.example.com 765 c=IN IP4 host.example.com 767 a=group:BUNDLE bundle con1 con2 769 m=audio 10000 RTP/AVP 0 8 97 770 a=mid:con1 771 a=rtcp-mux 772 a=rtpmap:0 PCMU/8000 773 a=rtpmap:8 PCMA/8000 774 a=rtpmap:97 iLBC/8000 775 a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host 776 a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx 777 a=candidate:2 1 UDP 1006633215 10.0.100.1 31000 typ relay 779 m=video 10002 RTP/AVP 31 32 780 a=mid:con2 781 a=rtcp-mux 782 a=rtpmap:31 H261/90000 783 a=rtpmap:32 MPV/90000 784 a=candidate:0 1 UDP 2113601791 10.0.1.1 10002 typ host 785 a=candidate:1 1 UDP 1694194431 198.51.100.32 51002 typ srflx 786 a=candidate:2 1 UDP 1006633215 10.0.100.1 31002 typ relay 788 m=audio 10004 bundle 0 789 a=mid:bundle 790 a=rtcp-mux 791 a=candidate:0 1 UDP 2113601791 10.0.1.1 10004 typ host 792 a=candidate:1 1 UDP 1694194431 198.51.100.32 51004 typ srflx 793 a=candidate:2 1 UDP 1006633215 10.0.100.1 31004 typ relay 795 If the answerer understands bundling and accepts the bundle, it 796 accepts the constituent MDs within the bundle (with "a=bundleaccept" 797 and port 0) and accepts the bundle MD. If the answerer does not 798 understand bundling, it accepts the constituent MDs and rejects the 799 bundle MD. In either case, ICE relay candidates are in place and ICE 800 negotiation proceeds. 802 4.2. Two Audio Streams and Two Video Streams 803 In this example, a presentation involves four media roles: the 804 speaker's audio, the floor microphone, the video of the speaker, and 805 the video of the speaker's slides. We use separate MDs for each 806 media stream because each TF has a different role; the application 807 will handle each of them in distinctly different ways. 809 o=- 2890844526 2890844526 IN IP4 host.example.com 810 c=IN IP4 host.example.com 812 a=group:BUNDLE b c1 c2 c3 c4 814 m=audio 10000 RTP/AVP 0 8 97 815 a=mid:c1 816 a=label:speaker-audio 817 a=rtcp-mux 818 a=rtpmap:0 PCMU/8000 819 a=rtpmap:8 PCMA/8000 820 a=rtpmap:97 iLBC/8000 822 Note that different constituent MDs must use different payload types 823 (even for the same codec), because incoming RTP is demultiplexed based 824 on payload type. 826 m=audio 10002 RTP/AVP 98 99 100 827 a=mid:c2 828 a=label:floor-mic 829 a=rtcp-mux 830 a=rtpmap:98 PCMU/8000 831 a=rtpmap:99 PCMA/8000 832 a=rtpmap:100 G722 834 m=video 10004 RTP/AVP 101 102 835 a=mid:c3 836 a=label:speaker-video 837 a=rtcp-mux 838 a=rtpmap:101 H261/90000 839 a=rtpmap:102 MPV/90000 841 m=video 10006 RTP/AVP 103 104 842 a=mid:c4 843 a=label:slides 844 a=rtcp-mux 845 a=rtpmap:103 H261/90000 846 a=rtpmap:104 MPV/90000 848 m=multipart 10008 bundle 0 849 a=mid:b 851 4.3. Virtual Classroom with One Audio Stream, Two Video Streams, and a 852 Group of Video Streams 854 This example is the teacher's connection to a virtual classroom 855 server. The media descriptions are tagged using the "content" 856 attribute. [RFC4796] The media comprises: 858 1. 1. one audio channel, for sending the teacher's voice and 859 receiving the voice of a selected student 861 2. 2. one video channel, for sending the teacher's presentation 863 3. 3. one video channel, for sending the teacher's face 865 4. 4. one video channel, for receiving a dynamically varying set of 866 students' faces 868 The fourth TF (for students' faces) contains a large and dynamically 869 varying set of video captures. These can be handled by a single TF 870 because they all have essentially similar roles -- the application 871 will process them as a set. As Adam Roach would say, "no control 872 surfaces are necessary to talk about and/or manipulate the individual 873 streams". In particular, this allows a large number of captures to 874 be handled without mentioning them in the SDP, at the expense of not 875 allowing the SDP to describe any of them individually. Similarly, 876 the number of captures can vary without having to renegotiate the 877 SDP. 879 (In contrast, the third TF (the teacher's face) is a separate TF 880 because it is processed in a different role than that of the 881 students' faces.) 883 In unbundled usage, there would be one transport association for the 884 fourth TF. Incoming RTP from that association would be demultiplexed 885 by the application based on the SSRC values, which would be unique 886 for each student. With bundling, once the single transport TF is 887 demultiplexed based on the RTP payload type, packets destined for the 888 fourth TF (index = 3) would be further demultiplexed by their SSRC 889 values. The demultiplexing by SSRC is considered to be an 890 application layer function in the context of SDP bundling. 892 The offered SDP is: 894 o=- 2890844526 2890844526 IN IP4 host.example.com 895 c=IN IP4 host.example.com 897 a=group:BUNDLE b c1 c2 c3 c4 899 The audio channel is send/receive. 901 m=audio 10000 RTP/AVP 0 8 97 902 a=mid:c1 903 a=label:speaker-audio 904 a=content:speaker 905 a=rtcp-mux 906 a=rtpmap:0 PCMU/8000 907 a=rtpmap:8 PCMA/8000 908 a=rtpmap:97 iLBC/8000 910 The teacher's face and presentation are send-only. 912 m=video 10002 RTP/AVP 103 104 913 a=mid:c2 914 a=label:speaker-video 915 a=content:speaker 916 a=sendonly 917 a=rtcp-mux 918 a=rtpmap:103 H261/90000 919 a=rtpmap:104 MPV/90000 921 m=video 10004 RTP/AVP 105 106 922 a=mid:c3 923 a=label:presentation 924 a=content:slides 925 a=sendonly 926 a=rtcp-mux 927 a=rtpmap:105 H261/90000 928 a=rtpmap:106 MPV/90000 930 The student video input is receive-only and is limited to 24 931 simultaneous SSRCs. 933 m=video 10006 RTP/AVP 107 108 934 a=mid:c4 935 a=label:student-thumbnails 936 a=recvonly 937 a=max-recv-ssrc:* 24 938 a=rtcp-mux 939 a=rtpmap:107 H261/90000 940 a=rtpmap:108 MPV/90000 942 m=audio 10000 RTP/AVP 127 943 a=mid:b 944 a=rtcp-mux 945 a=rtpmap:127 bundle 946 a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host 947 a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx 949 4.4. One Audio Stream and Two SCTP Streams 951 This example contains one audio MD and two SCTP MDs, which are used 952 for Webrtc datachannels. 954 o=- 2890844526 2890844526 IN IP4 host.example.com 955 c=IN IP4 host.example.com 957 a=group:BUNDLE bundle con1 con2 con3 959 m=audio 10000 RTP/AVP 0 8 97 960 a=mid:con1 961 a=rtcp-mux 962 a=rtpmap:0 PCMU/8000 963 a=rtpmap:8 PCMA/8000 964 a=rtpmap:97 iLBC/8000 966 These MDs provides the the SCTP TFs. Because packets are not 967 encapsulated, the two SCTP TFs must use different (nominal) SCTP ports 968 to allow their packets to be distinguished. 970 m=application 10002 DTLS/SCTP 5000 971 a=mid:con2 972 a=sctpmap:5000 webrtc-datachannel 16 974 m=application 10004 DTLS/SCTP 5001 975 a=mid:con3 976 a=sctpmap:5001 webrtc-datachannel 16 978 m=audio 10006 bundle 0 979 a=mid:bundle 981 5. Syntax and Semantics 983 TBD (Here lies the real description.) 985 5.1. Constructing an Offer 987 TBD 989 5.2. Constructing an Answer 991 TBD 993 5.3. Offer/Answer Considerations 995 TBD 997 5.4. RTCP, SSRC, and RTP Sessions 999 TBD 1001 5.5. ICE considerations 1003 TBD 1005 5.6. Encryption considerations 1007 TBD Need to discuss here how the encryption associations are set up. 1008 For SRTP/SRTCP, it would be possible to have either one association 1009 for all multiplexed streams, or one for each constituent MD, because 1010 SRTP preserves the PTs. (Have to verify that and check whether SRTCP 1011 preserves SSRCs.) But SCTP-over-DTLS can't be demultiplexed before 1012 it's decrypted, so there can be only one DTLS crypto association. 1014 6. Compatibility Considerations 1016 6.1. Backward Compatibility during Offer/Answer 1018 TBD 1020 6.2. Backward Compatibility with Existing Devices 1022 TBD 1024 7. Design Features and Comparison 1026 Key: 1028 x = feature present in proposal 1029 - = feature not present in proposal 1030 . = feature not discussed in proposal 1031 N/A = feature is not relevant because of another feature choice 1033 worley-sdp-bundle-06 1034 | ietf-mmusic-sdp-bundle-negotiation-03 (BUNDLE) 1035 | | holmberg-mmusic-sdp-mmt-negotiation-00 (MMT) 1036 | | | alvestrand-one-rtp-02 (TOGETHER) 1037 | | | | ejzak-mmusic-bundle-alternatives-01 1038 | | | | | Roach alternative 1a 1039 | | | | | |(roach-mmusic-mlines-00) 1040 | | | | | | Roach alternative 1b 1041 | | | | | | | Roach alternative 2 1042 | | | | | | | | westerlund-avtcore- 1043 | | | | | | | | |transport-multiplexing-05 1044 | | | | | | | | |(SHIM) 1045 V V V V V V V V V 1046 MD grouping: 1047 one - - - - - - x - - 1048 per type - - - - - x - - - 1049 none x x x x x - - x x 1051 Separate bundle MD: 1052 no - x - x x x x x x 1053 m=anymedia - - x - - - - - - 1054 m=audio x - - - - - - - - 1055 m=multipart - - - - - - - - - 1057 Immediate update: 1058 none - - x x x x x x x 1059 for support - x - - - - - - - 1060 for compat. x - - - - - - - - 1062 Constituent MD ports after establishment: 1063 N/A - - - - - x x - - 1064 same - x - x - - - x x 1065 different - - - - - - - - - 1066 null - - - - - - - - - 1067 rejected x - x - x - - - - 1069 Bundle MD payload types: 1070 N/A x - - - - x x - - 1071 one MD - x - x . - - x x 1072 all MDs - - x - . - - - - 1073 one value - - - - . - - - - 1075 Constituent MD payload types: 1076 N/A - - - - - x x - - 1077 overlapping - - - - . - - x x 1078 distinct x x x x . - - - - 1080 Demultiplexing based on: 1081 N/A - - - - - x x - - 1082 PT x x x x . - - x - 1083 encap. - - - - . - - - x 1085 Rejection of bundle MD based on: 1086 N/A - x - x x x x x x 1087 media type - - x - - - - - - 1088 proto x - - - - - - - - 1089 codec - - - - - - - - - 1091 Addresses/ports in constituent MDs in offer: 1092 N/A - - - - - x x - - 1093 NA,ZP - - - - - - - - - 1094 NA,NZP - - - - x - - - - 1095 RA,ZP - - - - - - - - - 1096 RA,NZP,U x x x - x - - - - 1097 RA,NZP,S - x - x - - - x x 1098 NA = null address, RA = real address 1099 ZP = zero port, NZP = non-zero port 1100 U = unique ports, S = shared port 1102 7.1. Aggregation of Constituent Media Descriptions 1104 Are the constituent media descriptions combined into grouped media 1105 descriptions? 1107 o All media are combined into one media description. 1109 o All media of each media type are combined into one media 1110 description (which has that type). 1112 o Each constituent media description is separate in the session 1113 description. 1115 This proposal does not aggregate constituent MDs so that attributes 1116 can be provided directly for each constituent MD. 1118 7.2. Presence of a Bundle Media Description and Its Media Type 1120 Is there a separate bundle media description, and if so, what media 1121 type does it have? 1123 o There is no separate bundle media description. 1125 o There is a separate bundle media description of type "anymedia". 1127 o There is a separate bundle media description of type "audio". 1129 o There is a separate bundle media description of type "multipart". 1131 This proposal has a separate bundle MD so that attributes can be 1132 provided for the bundle MD independently of any constituent MD. 1134 7.3. Immediate Update 1135 Is an immediate updated offer/answer used during session 1136 establishment? 1138 o No. 1140 o Yes, when establishing a session using bundling. 1142 o Yes, when establishing a session not using bundling. 1144 This proposal can require immediate updates for non-bundle-supporting 1145 answers to provide ICE TURN candidates, if the offerer has not 1146 preallocated them. 1148 7.4. Effective Media Description Ports after Session Establishment 1150 What are the effective port numbers in MDs after the session is 1151 established? 1153 o There are not multiple media descriptions because constituent MDs 1154 are combined. 1156 o Port numbers in the MDs are the same. 1158 o Port numbers in the MDs are different. 1160 o All but one MD have null addresses. 1162 o All but one MD have a zero port number (and thus are formally 1163 rejected). 1165 This proposal uses a zero port number for constituent MDs to prevent 1166 intermediate entities from expecting to see media for the constituent 1167 transport associations. 1169 7.5. Payload Types in the Bundled Media Description 1171 What payload types are listed for the bundled MD? 1173 o There is no MD describing the bundle as a whole. 1175 o The bundle MD lists the payload types of one constituent MD. 1177 o The bundle MD lists the payload types of all constituent MDs. 1179 o The bundle MD lists one payload type. 1181 This proposal uses a distinct proto value that does not use payload 1182 type numbers. 1184 7.6. Relationship of Payload Types of Constituent Media Descriptions 1186 What is the relationship between the payload types of the constituent 1187 MDs? 1189 o There are not multiple media descriptions because constituent MDs 1190 are combined. 1192 o Different constituent MDs may have overlapping payload type 1193 numbers. 1195 o Different constituent MDs may not have overlapping payload type 1196 numbers. 1198 This proposal requires constituent MDs to use distinct payload types 1199 in order to demultiplex the constituent MDs. 1201 7.7. Basis of Demultiplexing 1203 What is the basis for the demultiplexing of RTP? 1205 o Demultiplexing is not done because incoming RTP is not attributed 1206 to specific constituent MDs (possibly because constituent MDs are 1207 combined). 1209 o Demultiplexing is done based on payload type numbers. 1211 o Demultiplexing is done based on data carried in an encapsulation. 1213 This proposal does demultiplexing based on information in the 1214 encapsulated payload format. 1216 7.8. Basis of Rejection of the Bundle MD 1218 We must ensure that the bundle MD is rejected by non-supporting 1219 endpoints. What method is used to ensure rejection? 1221 o There is no bundle MD. 1223 o The bundle MD uses a special media type value. 1225 o The bundle MD uses a special proto value. 1227 o The bundle MD uses (only) a special codec name. 1229 This proposal uses a distinct proto type in the bundle media 1230 description to ensure that answerers that do not implement bundling 1231 reject this MD. 1233 7.9. How Constituent MDs Are Offered 1235 There are a number of alternative ways that the offerer can configure 1236 the constituent media descriptions. 1238 +----------+-----+------+------+-------+-------+------+------+------+ 1239 | Method | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 1240 +----------+-----+------+------+-------+-------+------+------+------+ 1241 | Coded in | NA, | NA,N | RA,Z | RA,NZ | RA,NZ | RA,N | RA,N | RA,N | 1242 | chart as | ZP | ZP | P | P,U | P,U | ZP,U | ZP,U | ZP,S | 1243 | | | | | | | | | | 1244 | Offered | nul | null | real | real | real | real | real | real | 1245 | address | l | | | | | | | | 1246 | | | | | | | | | | 1247 | Offered | zer | non- | zero | non- | non- | non- | non- | non- | 1248 | port | o | zero | | zero, | zero, | zero | zero | zero | 1249 | | | | | uniqu | uniqu | , un | , un | , sh | 1250 | | | | | e | e | ique | ique | ared | 1251 | | | | | | | | | | 1252 | TURN can | N/A | N/A | N/A | no | yes | no | yes | yes | 1253 | didates? | | | | | | | | | 1254 | | | | | | | | | | 1255 | Supporti | yes | yes | yes | yes | yes | no | no | yes | 1256 | ng | | | | | | | | | 1257 | answerer | | | | | | | | | 1258 | accepts? | | | | | | | | | 1259 | | | | | | | | | | 1260 | Update | no | no | poss | yes | yes | no | no | no | 1261 | needed | | | ibly | | | | | | 1262 | for supp | | | | | | | | | 1263 | orting a | | | | | | | | | 1264 | nswerer? | | | | | | | | | 1265 | | | | | | | | | | 1266 | Non-supp | no | prob | no | yes | yes | yes | yes | yes | 1267 | orting | | ably | | | | | | | 1268 | answerer | | | | | | | | | 1269 | accepts? | | | | | | | | | 1270 | | | | | | | | | | 1271 | Update | yes | yes | yes | yes | no | yes | no | no | 1272 | needed | | | | | | | | | 1273 | for non- | | | | | | | | | 1274 | supporti | | | | | | | | | 1275 | ng answe | | | | | | | | | 1276 | rer? | | | | | | | | | 1277 | | | | | | | | | | 1278 | Disadvan | ACE | CD | ABCE | BC | BG | C | G | BFG | 1279 | tages | | | | | | | | | 1280 +----------+-----+------+------+-------+-------+------+------+------+ 1282 Offered address This is the address offered for the MD. There are 1283 two choices, a null address (0.0.0.0 for IPv4 or "invalid." for 1284 IPv6 or mixed IPv4/IPv6) or a real address of the offerer. 1286 Offered port This is the port that is offered. It can be either 1287 non-zero or zero (which indicates a stream that is not being 1288 offered). If the offered port is non-zero and the offered address 1289 is real, the port can be either unique, or shared with the other 1290 media descriptions in the bundle. 1292 TURN candidates? If the offered address is real and the offered port 1293 is non-zero, are TURN candidates for the address provided (if they 1294 are needed)? 1296 Supporting answerer accepts? If the answerer supports bundling, does 1297 it accept the constituent media description (with a non-zero port 1298 in the answer)? If not, the answerer must have some other method 1299 of indicating acceptance of the constituent of the bundle. 1301 Update needed for supporting answerer? Is an SDP update needed to 1302 complete session setup if the answerer supports bundling? If an 1303 update is needed, it is needed to inform intermediaries that there 1304 will be no media sent based on the connection information in this 1305 media description; the update is not needed to establish 1306 communications and does not delay the application. 1308 Non-supporting answerer accepts? If the answerer does not support 1309 bundling, does it accept this media description (without a further 1310 update)? 1312 Update needed for non-supporting answerer? Is an SDP update needed 1313 to complete session setup if the answerer does not support 1314 bundling? If an update is needed, in all cases, it is needed to 1315 establish communication. 1317 Flaws The disadvantages of each alternative: 1319 A Media descriptions that are rejected (have zero ports) are 1320 not allowed to be members of a group (in the 1321 offer).[RFC5888] 1323 B An SDP update is needed for a supporting answerer to prevent 1324 intermediaries from timing out the multimedia session. 1326 C An SDP update is needed for a non-supporting answerer to 1327 establish communications. 1329 D Although a media description with a non-zero port but a null 1330 address is formally offered (although shown as on-hold via 1331 the old method), it is possible that the answerer will not 1332 consider it to be offered and many not accept it even if it 1333 otherwise wood. 1335 E If the offered port is zero, the media description is not 1336 formally offered and the answerer should not accept it. 1338 F SDP offers with multiple media descriptions that use the 1339 same port number (for the same real address) may be rejected 1340 by intermediaries. 1342 G A TURN relay must be allocated for the constituent media 1343 description before the offer is sent. 1345 In my estimation, the worst disadvantages are A (zero port in offer), 1346 E (acceptance of offer with zero port), and F (duplicate port 1347 numbers), because they involve violations of [RFC4566] or are known 1348 to trigger limitations of large numbers of intermediate devices. 1349 Disadvantage D (offering a MD with a null address) is nearly as 1350 severe, as we expect it to cause undesired behavior in many non- 1351 supporting answerers. Disadvantages C (update needed to communicate 1352 with non-supporting answerer) and G (TURN relay must be preallocated) 1353 are moderate, and disadvantage B (updated needed to prevent 1354 intermediaries from timing out) is the least severe (because it never 1355 delays the establishment of communication). 1357 Applying these priorities to the possible solutions, methods 6 and 7 1358 (offer real address, non-zero unique port, with/without TURN 1359 candidates, answer has zero port for constituent MDs) are tied for 1360 the best choices, with the choice made based on the relative 1361 importance of minimizing preallocation of TURN relays compared to 1362 quickly establishing communication with non-supporting answerers. 1364 8. Demultiplexing Considerations 1366 This section discusses the constraints regarding demultiplexing 1367 datagrams from multiple protocols that are presented on one transport 1368 flow. This is an expansion of the analysis in [RFC5764] section 1369 5.1.2. 1371 The first octets of datagrams generated by particular protocols are: 1373 +--------------+------------+--------------+-----------+------------+ 1374 | Protocol | First | Second octet | Third | Fourth | 1375 | | octet | | octet | octet | 1376 +--------------+------------+--------------+-----------+------------+ 1377 | STUN | 0x00, 0x01 | 0x00, 0x01 | | | 1378 | | | | | | 1379 | RTP | 0x80 to | 0x00 to | | | 1380 | | 0xBF | 0xC7, 0xCD | | | 1381 | | | to 0xFF | | | 1382 | | | | | | 1383 | RTCP | 0x80 to | 0xC8 to 0xCC | | | 1384 | | 0xBF | | | | 1385 | | | | | | 1386 | RTP/RTCPv3 | 0xC0 to | | | | 1387 | | 0xFF | | | | 1388 | | | | | | 1389 | DTLS | 0x14 to | 0x03 | 0x03 | | 1390 | | 0x17 | | | | 1391 | | | | | | 1392 | SCTP | source | source port | dest. | dest. port | 1393 | | port high | low | port high | low | 1394 +--------------+------------+--------------+-----------+------------+ 1396 TBD RFC 5764 specifies that the first octet of a DTLS packet is in 1397 the range 0x14 to 0x3F. RFC 5246 and RFC 6374 together specify the 1398 first octet is a "ContentType", with the range 0x14 to 0x17. Are 1399 additional octet values reserved for expansion? What is the range 1400 that should be reserved in practice? 1402 The most generalized stack of protocols we consider is this: 1404 Layer 6: ... application interfaces ... 1405 ||| ||| ||| ||| 1406 V V V V 1407 | | | | 1408 | | | | 1409 Layer 5: | | | SCTP 1410 | | | | 1411 | | | | 1412 RTP SRTP | | 1413 Layer 4: RTCP SRTCP SCTP DTLS [ STUN ] 1414 \ | | | / 1415 --------------- ---------------- 1416 V 1417 | 1418 | 1419 Layer 3: [ encapsulation STUN ] 1420 [ \ / ] 1421 [ ---- --------- ] 1422 [ V ] 1423 | 1424 | 1425 Layer 2: [ DTLS STUN ] 1426 [ \ / ] 1427 [ ------- --------- ] 1428 [ V ] 1429 | 1430 | 1431 Layer 1: [ TURN ] 1432 | 1433 | 1434 Layer 0: UDP 1436 Layer 0: UDP This is the base layer of this analysis, where packets 1437 are carried by UDP. 1439 Layer 1: TURN (optional) If a packet arrives from a TURN relay for 1440 which we are a client, the TURN encapsulation must be removed 1441 before further processing. This need can be detected because the 1442 packet arrives from the client-facing address/port of a TURN 1443 server of which this entity is a client. 1445 Layer 2: DTLS applied to the bundle transport flow (optional) 1446 If DTLS is applied to the bundle transport flow as a whole, that 1447 use of DTLS will have been negotiated. However, before 1448 deciphering, STUN packets need to be separated. STUN packets can 1449 be distinguished from DTLS packets by their first or second 1450 octets. 1452 Layer 3: Decapsulation (depending on the bundling method If the 1453 bundling method uses encapsulation, decapsulation is done at this 1454 point in the protocol stack. However, before decapsulating, STUN 1455 packets need to be separated. The encapsulation method must allow 1456 encapsulated packets to be distinguished from STUN packets, if 1457 STUN packets have not been demultiplexed at layer 2 (due to DTLS 1458 encryption of the entire transport stream). 1460 All proposed encapsulation techniques ensure the first octet of 1461 the encapsulation is in the range allowed for the first octet of 1462 RTP, 0x80 to 0xBF, and thus is distinguishable from STUN. 1464 Layer 4: Core demultiplexing At this layer, most of the protocols 1465 are demultiplexed. RTP/SRTP, SRTP/SRTCP, DTLS, and STUN are 1466 distinguished by the values of the first two octets of the packet. 1467 SRTP/SRTCP is distinguished from RTP/RTCP by negotiation with the 1468 other endpoint -- SRTP/SRTCP is never multiplexed with RTP/RTCP. 1470 SCTP can be distinguished from the other protocols if the other 1471 endpoint agrees to use only SCTP port numbers in the range 0x4000 1472 to 0x7FFF. This restriction can be specified here, because this 1473 limitation is only needed when bundling is implemented, which 1474 happens only when when both endpoints support bundling. (This 1475 particular range is chosen to avoid collision with a future RTP/ 1476 RTCP version 3. The range of SCTP ports can be chosen arbitrarily 1477 because the SCTP ports are not used to route packets to this 1478 entity, as they are encapsulated in UDP.) 1480 Layer 5: SCTP over DTLS If the layer 4 protocol is DTLS, the 1481 protocol above it will always be SCTP. 1483 Layer 6: Application interface demultiplexing The method used to 1484 demultiplex the various application interface streams varies 1485 depending whether encapsulation is used and if not, on the layer 4 1486 /5 protocol. If the layer 4 protocol is encapsulated, the 1487 encapsulation determines which constituent media description is to 1488 be assigned to this packet, and then application demultiplexing is 1489 done as normal for for that particular media description. 1490 Otherwise, the constituent media description must be determined by 1491 a method that is specific to the layer 4/5 protocol: 1493 RTP/SRTP An RTP/SRTP packet is assigned to the constituent media 1494 description which specifies its payload type number. (If 1495 encapsulation is not used, the constituent media 1496 descriptions must specify distinct payload type numbers.) 1498 RTCP/SRTCP An RTCP/SRTCP sub-packet is dispatched to the 1499 application which receives the RTP media stream containing 1500 the SSRC that is carried in the RTCP sub-packet. 1502 SCTP An SCTP packet is assigned to the constituent media 1503 description which specifies its destination port number. 1504 (If encapsulation is not used, the constituent media 1505 descriptions must specify distinct SCTP port numbers.) 1507 9. Security Considerations 1509 If an SBC wishes to prevent positively the transport of certain media 1510 types or codecs, and enforces that by examining the content of RTP 1511 packets, the use of kumquat encoding may defeat the examination. 1513 TBD 1515 10. IANA Considerations 1517 TBD 1519 11. Acknowledgments 1521 Many people have provided input for this proposal regarding both the 1522 technical aspects and the organization of the presentation. Chief 1523 among them are the authors of the predecessor proposals 1524 ([I-D.alvestrand-one-rtp] (TOGETHER), 1526 [I-D.holmberg-mmusic-sdp-mmt-negotiation] (MMT), and 1527 [I-D.ietf-mmusic-sdp-bundle-negotiation] (BUNDLE)): Harald 1528 Alvestrand, Jonathan Lennox, and Christer Holmberg. In addition, 1529 input was provided by Charles Eckel, Andrew Hutton, Cullen Jennings, 1530 Hadriel Kaplan, Paul Kyzivat, Adam Roach, and Robert Sparks. 1532 12. Revision History 1534 Note to RFC Editor: Please remove this section before publication. 1536 12.1. draft-worley-sdp-bundle-00 1538 Initial version. 1540 12.2. Changes from draft-worley-sdp-bundle-00 to draft-worley-sdp- 1541 bundle-01 1543 Thoroughly revise the text and structure of the document. 1545 12.3. Changes from draft-worley-sdp-bundle-01 to draft-worley-sdp- 1546 bundle-02 1548 Heavily revise Terminology regarding media flows. 1550 Revise Desiderata, including adding that multiple separate bundles 1551 must be possible, and noninterference with ICE negotiation. 1553 Add section on ICE considerations. 1555 Change "fusion" to "bundle". 1557 Use a=rtcp-mux in examples to be more realistic (and to shorten the 1558 examples). 1560 Correct the use of ICE in answers; ICE candidates are not provided if 1561 an offered MD does not contain ICE candidates. 1563 Add an example of a fast-start offer. 1565 12.4. Changes from draft-worley-sdp-bundle-02 to draft-worley-sdp- 1566 bundle-03 1568 Add design comparison Section 7. 1570 Use bibxml references. 1572 Add DES C9, regarding continued usage of transcoding facilities 1573 offered by intermediate entities. 1575 12.5. Changes from draft-worley-sdp-bundle-03 to draft-worley-sdp- 1576 bundle-04 1578 Add demultiplexing considerations Section 8. 1580 12.6. Changes from draft-worley-sdp-bundle-04 to draft-worley-sdp- 1581 bundle-05 1583 Change recommendation for SCTP port numbers from 0xC000-0xFFFF to 1584 0x4000-0x7FFF to avoid collision with a future RTP/RTCP version 3. 1586 Add the transport flow index to the KUMQUAT encapsulation. 1588 Add section on choices for offering constituent MDs Section 7.9. 1589 Revise the examples to show offering "real address, non-zero port, no 1590 ICE candidates". 1592 Add note to DES C9 (support intermediate transcoding facilities) 1593 saying that intermediate transcoding facilities are not expected to 1594 be very useful, given that encryption will be the normal use case. 1596 Add an exampleSection 4.4 with SCTP MDs. 1598 Add a section for encryption considerations.Section 5.6 1600 Revise generalized demultiplexing diagram to make explicit the 1601 optional RTP encapsulation layer. 1603 Update comparison chartSection 7 for draft-ejzak-mmusic-bundle- 1604 alternatives-01[I-D.ejzak-mmusic-bundle-alternatives] and draft- 1605 westerlund-avtcore-transport- 1606 multiplexing-05[I-D.westerlund-avtcore-transport-multiplexing]. 1608 Update comparison chartSection 7 to discuss alternative address/port/ 1609 candidate policies for offering constituent MDs. 1611 12.7. Changes from draft-worley-sdp-bundle-05 to draft-worley-sdp- 1612 bundle-06 1614 Add desideratum that we want the RTP media to be visible on the wire 1615 as SRTP. 1617 Remove the encapsulation. 1619 Change acceptance-within-bundle in an answer to use a zero port 1620 number with a=bundleaccept attribute. Revise the the table 1621 Section 7.9 to include this method. 1623 Change c= lines in examples to use host names, which is what would be 1624 done in a dual-stack environment. (ICE candidates carry the actual 1625 addresses used.) 1627 Add TURN ICE candidates to the examples with ICE candidates, as 1628 described by the existing text. 1630 13. References 1632 13.1. Normative References 1634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1635 Requirement Levels", BCP 14, RFC 2119, March 1997. 1637 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1638 with Session Description Protocol (SDP)", RFC 3264, June 1639 2002. 1641 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1642 Jacobson, "RTP: A Transport Protocol for Real-Time 1643 Applications", STD 64, RFC 3550, July 2003. 1645 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1646 Description Protocol", RFC 4566, July 2006. 1648 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1649 (ICE): A Protocol for Network Address Translator (NAT) 1650 Traversal for Offer/Answer Protocols", RFC 5245, April 1651 2010. 1653 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1654 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1656 13.2. Informative References 1658 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 1659 Protocol", RFC 2327, April 1998. 1661 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1662 Camarillo, "Best Current Practices for Third Party Call 1663 Control (3pcc) in the Session Initiation Protocol (SIP)", 1664 BCP 85, RFC 3725, April 2004. 1666 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description 1667 Protocol (SDP) Content Attribute", RFC 4796, February 1668 2007. 1670 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 1671 4960, September 2007. 1673 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1674 Control Packets on a Single Port", RFC 5761, April 2010. 1676 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1677 Security (DTLS) Extension to Establish Keys for the Secure 1678 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1680 [I-D.alvestrand-mmusic-msid] 1681 Alvestrand, H., "Cross Session Stream Identification in 1682 the Session Description Protocol", draft-alvestrand- 1683 mmusic-msid-02 (work in progress), December 2012. 1685 [I-D.alvestrand-one-rtp] 1686 Alvestrand, H., "SDP Grouping for Single RTP Sessions", 1687 draft-alvestrand-one-rtp-02 (work in progress), September 1688 2011. 1690 [I-D.ejzak-mmusic-bundle-alternatives] 1691 Ejzak, R., "Alternatives to BUNDLE", draft-ejzak-mmusic- 1692 bundle-alternatives-01 (work in progress), February 2013. 1694 [I-D.holmberg-mmusic-sdp-mmt-negotiation] 1695 Holmberg, C., Alvestrand, H., and J. Lennox, "Multiplexed 1696 Media Types (MMT) Using Session Description Protocol (SDP) 1697 Port Numbers", draft-holmberg-mmusic-sdp-mmt- 1698 negotiation-00 (work in progress), October 2012. 1700 [I-D.ietf-avtcore-multi-media-rtp-session] 1701 Westerlund, M., Perkins, C., and J. Lennox, "Multiple 1702 Media Types in an RTP Session", draft-ietf-avtcore-multi- 1703 media-rtp-session-02 (work in progress), February 2013. 1705 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1706 Holmberg, C., Alvestrand, H., and C. Jennings, 1707 "Multiplexing Negotiation Using Session Description 1708 Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- 1709 bundle-negotiation-03 (work in progress), February 2013. 1711 [I-D.jennings-mmusic-media-req] 1712 Jennings, C., Uberti, J., and E. Rescorla, "Requirements 1713 from various WG for MMUSIC", draft-jennings-mmusic-media- 1714 req-00 (work in progress), February 2013. 1716 [I-D.roach-mmusic-mlines] 1717 Roach, A., "Thoughts on syntax for representing multiple 1718 media streams", draft-roach-mmusic-mlines-00 (work in 1719 progress), January 2013. 1721 [I-D.westerlund-avtcore-transport-multiplexing] 1722 Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a 1723 Single Lower-Layer Transport", draft-westerlund-avtcore- 1724 transport-multiplexing-05 (work in progress), February 1725 2013. 1727 [I-D.worley-service-example] 1728 Worley, D., "Session Initiation Protocol Service Example 1729 -- Music on Hold", draft-worley-service-example-11 (work 1730 in progress), February 2013. 1732 Author's Address 1734 Dale R. Worley 1735 Ariadne Internet Services, Inc. 1736 738 Main St. 1737 Waltham, MA 02451 1738 US 1740 Phone: +1 781 647 9199 1741 Email: worley@ariadne.com