idnits 2.17.1 draft-roach-rtcweb-plan-a-00.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 document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 07, 2013) is 4000 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-03 == Outdated reference: A later version (-05) exists of draft-nandakumar-mmusic-sdp-mux-attributes-02 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-06 -- No information found for draft-roach-rtcweb-glareless-add - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. B. Roach 3 Internet-Draft Mozilla 4 Intended status: Informational M. Thomson 5 Expires: November 08, 2013 Microsoft 6 May 07, 2013 8 Using SDP with Large Numbers of Media Flows 9 draft-roach-rtcweb-plan-a-00 11 Abstract 13 A recurrent theme in WebRTC has been the need to handle very large 14 numbers of media flows. Unfortunately, naive uses of SDP do not 15 handle this case particularly well. This document describes a modest 16 set of extensions to SDP which allow it to cleanly handle arbitrary 17 numbers of flows while still retaining a large degree of backward 18 compatibility with existing and non-RTCWEB endpoints. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 08, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Syntax Conventions . . . . . . . . . . . . . . . . . . . . . 5 57 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6. Detailed Description . . . . . . . . . . . . . . . . . . . . 7 60 6.1. Bundle-Only M-Lines . . . . . . . . . . . . . . . . . . . 7 61 6.2. Flow Demultiplexing . . . . . . . . . . . . . . . . . . . 10 62 6.3. Indicating Simulcast Groups . . . . . . . . . . . . . . . 11 63 6.4. Identifying Flows . . . . . . . . . . . . . . . . . . . . 11 64 6.5. Compatibility with Non-RTCWEB uses . . . . . . . . . . . 11 65 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 7.1. Simple example with one audio and one video . . . . . . . 12 67 7.2. Multiple Videos . . . . . . . . . . . . . . . . . . . . . 15 68 7.3. Many Videos . . . . . . . . . . . . . . . . . . . . . . . 17 69 7.4. Multiple Videos with Simulcast . . . . . . . . . . . . . 18 70 7.5. Video with Simulcast and RTX . . . . . . . . . . . . . . 20 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 76 11.2. Informative References . . . . . . . . . . . . . . . . . 22 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 79 1. Introduction 81 A recurrent theme in WebRTC has been the need to cleanly handle very 82 large numbers of media flows. For instance, a video conferencing 83 application might have a main display plus thumbnails for 10 or more 84 other speakers all displayed at the same time. If each video source 85 is encoded in multiple resolutions (e.g., simulcast or layered 86 coding) and also has FEC or RTX, this could easily add up to 30 or 87 more independent RTP flows. 89 The standard way of encoding this information in SDP is to have each 90 RTP flow (i.e., SSRC) appear on its own m-line. For instance, the 91 SDP for two cameras with audio from a device with a public IP address 92 could look something like: 94 v=0 95 o=- 20518 0 IN IP4 203.0.113.1 96 s= 97 t=0 0 98 c=IN IP4 203.0.113.1 99 a=ice-ufrag:F7gI 100 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 101 a=fingerprint:sha-1 102 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 104 m=audio 54400 RTP/SAVPF 0 96 105 a=rtpmap:0 PCMU/8000 106 a=rtpmap:96 opus/48000 107 a=ptime:20 108 a=sendrecv 109 a=candidate:0 1 UDP 2113667327 203.0.113.1 54400 typ host 110 a=candidate:1 2 UDP 2113667326 203.0.113.1 54401 typ host 112 m=video 55400 RTP/SAVPF 97 98 113 a=rtpmap:97 H264/90000 114 a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 115 a=rtpmap:98 VP8/90000 116 a=sendrecv 117 a=candidate:0 1 UDP 2113667327 203.0.113.1 55400 typ host 118 a=candidate:1 2 UDP 2113667326 203.0.113.1 55401 typ host 120 m=video 56400 RTP/SAVPF 99 100 121 a=rtpmap:99 H264/90000 122 a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 123 a=rtpmap:100 VP8/90000 124 a=sendrecv 125 a=candidate:0 1 UDP 2113667327 203.0.113.1 56400 typ host 126 a=candidate:1 2 UDP 2113667326 203.0.113.1 56401 typ host 128 Unfortunately, as the number of independent media sources starts to 129 increase, the scaling properties of this approach become problematic. 130 In particular, SDP currently requires that each m-line have its own 131 transport parameters (port, ICE candidates, etc.), which can get 132 expensive. For instance, the [RFC5245] pacing algorithm requires 133 that new STUN transactions be started no more frequently than 20 ms; 134 with 30 RTP flows, which would add 600 ms of latency for candidate 135 gathering alone. Moreover, having 30 persistent flows might lead to 136 excessive consumption of NAT binding resources. 138 A related issue is the number of payload types. Even multiple 139 sources are multiplexed over the same transport flow they must 140 somehow be demultiplexed. Consider the case where we want to be able 141 to transmit 32 video thumbnails (this is large, but not insane). In 142 the model described above, each of these flows would need its own 143 m-line and its own set of codecs. If each side supports three 144 separate codecs (e.g., H.263, H.264, VP8, and VP9), then we have just 145 consumed 128 payload types, which exceeds the available dynamic 146 payload space. This makes demuxing on payload type problematic in 147 some cases. 149 This document specifies a small number of modest extensions to SDP 150 which are intended to reduce the transport impact of using a large 151 number of flows. The general design philosophy is to maintain the 152 existing SDP negotiation model while simply reducing the consumption 153 of network resources. 155 2. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 158 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 159 interpreted as described in [RFC2119]. 161 This draft uses the API and terminology described in [webrtc-api]. 163 5-tuple: A collection of the following values: source IP address, 164 source transport port, destination IP address, destination transport 165 port and transport protocol. 167 Transport-Flow: An transport 5 Tuple representing the UDP source and 168 destination IP address and port over which RTP is flowing. 170 PC-Track: A source of media (audio and/or video) that is contained in 171 a PC-Stream. A PC-Track represents content comprising one or more 172 PC-Channels. 174 m-line: An SDP [RFC4566] media description identifier that starts 175 with an "m=" field and conveys the following values: media type, 176 transport port, transport protocol and media format descriptions. 178 Offer: An [RFC3264] SDP message generated by the participant who 179 wishes to initiate a multimedia communication session. An Offer 180 describes the participant's capabilities for engaging in a multimedia 181 session. 183 Answer: An [RFC3264] SDP message generated by the participant in 184 response to an Offer. An Answer describes the participant's 185 capabilities in continuing with the multimedia session with in the 186 constraints of the Offer. 188 This draft avoids using terms that implementors do not have a clear 189 idea of exactly what they are - for example RTP Session. 191 3. Syntax Conventions 193 The SDP examples given in this document deviate from actual on-the- 194 wire SDP notation in several ways. This is done to facilitate 195 readability and to conform to the restrictions imposed by the RFC 196 formatting rules. These deviations are as follows: 198 o Any line that is indented (compared to the initial line in the SDP 199 block) is a continuation of the preceding line. The line break 200 and indent are to be interpreted as a single space character. 202 o Empty lines in any SDP example are inserted to make functional 203 divisions in the SDP clearer, and are not actually part of the SDP 204 syntax. 206 o Excepting the above two conventions, line endings are to be 207 interpreted as pairs (that is, an ASCII 13 followed by an 208 ASCII 10). 210 o Any text starting with the string "//" to the end of the line is 211 inserted for the benefit of the reader, and is not actually part 212 of the SDP syntax. 214 4. Requirements 216 This document is intended to address the following requirements, 217 based on those from [I-D.jennings-mmusic-media-req]. 219 1. Support many media flows but minimize the number of transport 220 flows. 222 This requirement is partly satisfied by BUNDLE 223 [I-D.ietf-mmusic-sdp-bundle-negotiation]; however, BUNDLE 224 still requires a large number of ports and ICE candidates 225 in the initial offer. This can create serious latency 226 issues, as described in Section 1. The mechanisms in 227 Section Section 6.1 of this document address those issues. 229 3. Be able to successfully negotiate media with both legacy SIP 230 devices and new devices (whether SIP or RTCWEB) with a single 231 offer/answer exchange. If both endpoints support multiplexed 232 media, then multiplexing should be negotiated. Otherwise, non- 233 multiplexed media should be used. 235 The interaction of this mechanism with non-WEBRTC devices 236 is described in Section 6.5. 238 5. Provide a mechanism for harmonizing flow parameters for 239 different m-lines when they are multiplexed over the same 240 transport. 242 [I-D.nandakumar-mmusic-sdp-mux-attributes] documents the 243 required procedures. 245 7. Allow different sources (e.g., cameras) to use different codecs. 246 For example, if one camera had hardware encoders for VP8 while 247 another had encoders for H.264, the device may wish to negotiate 248 different codecs. 250 This requirement is also already satisfied by existing SDP 251 mechanisms; we simply need to preserve them. 253 9. Be able to independently set parameters such as resolution and 254 bandwidth, independently for each PC-Track, preferably even when 255 they are all multiplexed over the same transport flow. 257 Section 6.2 of this document satisfies the multiplexing 258 requirement and the normal SDP mechanisms are used for 259 parameters. 261 11. Be able to identify the PC-Tracks with an identifier that is 262 stable over the duration of the session. 264 Section 6.2 of this document explains track 265 identification. 267 Note that this document does not attempt to address the issue of 268 adding a stream with little or no chance of glare. See 269 [I-D.roach-rtcweb-glareless-add] for the description of a technique 270 that can be applied to any SDP offer/answer session establishment 271 protocol to eliminate mid-session glare. 273 5. Overview 275 This section provides an overview of the approach specified in this 276 document. 278 o We retain the existing SDP model that the m-line is the basic unit 279 of media negotiation/representation. Each independent unit (i.e., 280 a specific encoding of a PC-Track) is represented on its own 281 m-line. 283 o BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] is used to 284 multiplex multiple m-lines (and their corresponding media) onto 285 the same set of transport flows. 287 o Both RTP payload type (PT) and SSRC are used to de-multiplex flows 288 multiplexed via bundle. This allows for many more flows to be 289 bundled than the limited number of PTs available. 291 o In order to minimize the number of transport parameters that need 292 to be allocated during the gathering phase, m-lines can be tagged 293 as "bundle only". Such m-lines in an offer will be ignored by 294 legacy endpoints but can be negotiated by endpoints that support 295 the mechanisms specified in this document. 297 6. Detailed Description 299 6.1. Bundle-Only M-Lines 301 As discussed in Section 1, even with bundle, it is expensive to 302 allocate ICE candidates for a large number of m-lines. An offer can 303 contain "bundle-only" m-lines which will be negotiated only by 304 endpoints which implement this specification and ignored by other 305 endpoints. 307 In order to offer such an m-line, the offerer does two things: 309 o Sets the port in the m-line to 0. This indicates to old endpoints 310 that the m-line is not to be negotiated. 312 o Adds an a=bundle-only line. This indicates to new endpoints that 313 the m-line is to be negotiated if (and only if) bundling is used. 315 An example offer that uses this feature looks like this: 317 v=0 318 o=- 20518 0 IN IP4 203.0.113.1 319 s= 320 t=0 0 321 c=IN IP4 203.0.113.1 322 a=ice-ufrag:F7gI 323 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 324 a=fingerprint:sha-1 325 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 327 m=audio 54400 RTP/SAVPF 0 96 328 a=rtpmap:0 PCMU/8000 329 a=rtpmap:96 opus/48000 330 a=ptime:20 331 a=sendrecv 332 a=rtcp-mux 333 a=candidate:0 1 UDP 2113667327 203.0.113.1 54400 typ host 334 a=candidate:1 2 UDP 2113667326 203.0.113.1 54401 typ host 335 m=video 0 RTP/SAVPF 97 98 336 a=rtpmap:97 H264/90000 337 a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 338 a=rtpmap:98 VP8/90000 339 a=sendrecv 340 a=rtcp-mux 341 a=bundle-only 343 m=video 0 RTP/SAVPF 99 100 344 a=rtpmap:99 H264/90000 345 a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 346 a=rtpmap:100 VP8/90000 347 a=sendrecv 348 a=rtcp-mux 349 a=bundle-only 351 An old endpoint simply rejects the bundle-only m-lines by responding 352 with a 0 port. (This isn't a normative statement, just a description 353 of the way the older endpoints are expected to act.) 355 v=0 356 o=- 20518 0 IN IP4 203.0.113.1 357 s= 358 t=0 0 359 c=IN IP4 203.0.113.2 360 a=ice-ufrag:F7gI 361 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 362 a=fingerprint:sha-1 363 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 365 m=audio 55400 RTP/SAVPF 0 96 366 a=rtpmap:0 PCMU/8000 367 a=rtpmap:96 opus/48000 368 a=ptime:20 369 a=sendrecv 370 a=candidate:0 1 UDP 2113667327 203.0.113.2 55400 typ host 371 a=candidate:1 2 UDP 2113667326 203.0.113.2 55401 typ host 373 m=video 0 RTP/SAVPF 97 98 374 a=rtpmap:97 H264/90000 375 a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 376 a=rtpmap:98 VP8/90000 377 a=sendrecv 379 m=video 0 RTP/SAVPF 99 100 380 a=rtpmap:99 H264/90000 381 a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 382 a=rtpmap:100 VP8/90000 383 a=sendrecv 385 A new endpoint accepts the m-lines (both bundle-only and regular) by 386 offering m-lines with a valid port, though this port may be 387 duplicated as specified in Section 6 of 388 [I-D.ietf-mmusic-sdp-bundle-negotiation]. For instance: 390 v=0 391 o=- 20518 0 IN IP4 203.0.113.2 392 s= 393 t=0 0 394 c=IN IP4 203.0.113.2 395 a=ice-ufrag:F7gI 396 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 397 a=fingerprint:sha-1 398 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 400 m=audio 55400 RTP/SAVPF 0 96 401 a=rtpmap:0 PCMU/8000 402 a=rtpmap:96 opus/48000 403 a=ptime:20 404 a=sendrecv 405 a=rtcp-mux 406 a=candidate:0 1 UDP 2113667327 203.0.113.2 55400 typ host 408 m=video 55400 RTP/SAVPF 97 98 409 a=rtpmap:97 H264/90000 410 a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 411 a=rtpmap:98 VP8/90000 412 a=sendrecv 413 a=rtcp-mux 414 a=bundle-only 416 m=video 55400 RTP/SAVPF 99 100 417 a=rtpmap:99 H264/90000 418 a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 419 a=rtpmap:100 VP8/90000 420 a=sendrecv 421 a=rtcp-mux 422 a=bundle-only 424 Endpoints MUST NOT accept bundle-only m-lines if they are not part of 425 an accepted bundle group. 427 6.2. Flow Demultiplexing 429 As noted above, if a large number of m-lines are used and each codec 430 in each m-line uses its own PT, it is possible to exceed the number 431 of possible PT values. This makes PT-only demultiplexing 432 insufficient in some cases. 434 Offerers conformant to this specification MUST do one of the 435 following: 437 o Use non-overlapping PT values for each m-line in any given bundle 438 group. 440 o Provide distinct a=ssrc attributes for each m-line which uses 441 overlapping PT values with any other m-line. [Technically, this 442 is a general case of the previous point.] 444 If the offerer uses overlapping PT values for any two m-lines in a 445 given bundle group, the answerer MUST supply distinct a=ssrc 446 attributes for those m-lines. 448 Upon receipt of an RTP datagram on a port that is being used with 449 multiplexing, implementors SHOULD follow a procedure equivalent to 450 the following to demultiplex streams: 452 o If the SSRC in the received packet matches one that has been 453 mapped to an m-line (e.g., via a=ssrc attributes), then the packet 454 corresponds to that m-line. 456 o If the SSRC in the received packet does not matches one that has 457 associated with an m-line, but the PT value appears on only one 458 m-line, then the packet corresponds to the m-line containing that 459 PT. 461 o Otherwise, discard the packet. 463 Note that this approach means that if PT values overlap between two 464 m-lines, then those m-lines cannot be demultiplexed prior to 465 receiving the m-line-to-ssrc mapping (e.g., in the SDP answer). For 466 instance, if the offerer wants two m-lines to be rendered prior to 467 receipt of the SDP answer, it can use non-overlapping PT values on 468 those m-lines. 470 6.3. Indicating Simulcast Groups 472 Simulcast refers to taking a single capture (e.g., a camera), and 473 encoding it multiple times at different resolutions and / or frame 474 rates. For example, a device with a single HD camera may send one 475 version of the video at full HD resolution, and a second version 476 encoded at a low resolution. This would allow a video conferencing 477 bridge to be able to send the high resolution copy to some 478 destination and low resolution copy to other destinations without 479 having to recode the video at the conference bridge. 481 This document proposes that simulcast be done by defining a new SDP 482 group [RFC5888] called SIMULCAST. Any m-lines that are in the same 483 SIMULCAST group are alternative encodings of the same media capture. 485 One of the advantages of this approach is it works well with the many 486 existing RTP definitions that have been done in the past as well as 487 others that may be done in the future. 489 The order of m-lines in a SIMULCAST group determines the relative 490 size of the encoded streams. Streams at lower quality appear before 491 streams of higher quality. The entity creating the session 492 description can choose to order m-lines based on any quality criteria 493 (resolution, framerate, sample rate), but they SHOULD choose an 494 ordering that places streams with a lower average bitrate before 495 higher bitrate streams. 497 Providing an order to SIMULCAST groupings allows an intermediary 498 (such as a Media Translator [RFC5117]) to be able to select an 499 appropriate SIMULCAST layer without inspecting the media stream, 500 which could otherwise require decrypting and possibly partially 501 decoding media packets. 503 6.4. Identifying Flows 505 While this topic is largely out of scope for SDP, the SSRC value can 506 be used as a flow identifier. One minor caveat with this approach is 507 the ability to deal with the SSRC collision resolution procedure 508 described in section 8.2 of [RFC3550]. In the rare circumstances 509 that such an SSRC change is required, then any party that has changed 510 its SSRC needs to inform the remote participants of the updated 511 mapping, e.g. via a new SDP offer. In WebRTC use cases, this would 512 trigger an onrennegotiationneeded event. 514 6.5. Compatibility with Non-RTCWEB uses 516 Due to the fact that this approach re-uses existing SDP constructs 517 for indicating parameters in a media section, it remains compatible 518 with non-RTCWEB clients. Of particular note is the handling of 519 "bundle-only" media sections, described in Section 6.1. Offers 520 generated by an RTCWEB client and sent to a non-RTCWEB client will 521 simply negotiate those media the RTCWEB client did not use the 522 "bundle-only" extension with. This allows RTCWEB clients to select 523 which media streams are important for interoperability with non- 524 RTCWEB clients (by not making them bundle-only), and which ones are 525 not. Offers generated by non-RTCWEB clients will simply omit any 526 bundle-related attributes, and the RTCWEB client will be able to 527 process the SDP otherwise identically to the SDP received from RTCWEB 528 clients: each m-line represents a different media stream, and 529 contains a description of that stream in a syntax identical to the 530 syntax used between RTCWEB clients. 532 With the bundle-only approach, only those streams that are "important 533 for interoperability" will require allocation of ports and ICE 534 exchanges. By doing so, working with non-multiplexing clients is 535 enabled without requiring excess resource allocation for those 536 streams that are not critical for proper user experience. 538 Aside from BUNDLE, the bundle-only mechanism, and the rules around 539 port demultiplexing, this proposal requires no additional extensions 540 to SDP or the offer/answer model. 542 7. Examples 544 In all of these examples, there are many lines that are wrapped due 545 to column width limitation. It should be understood these lines are 546 not wrapped in the real SDP. 548 The convention used for IP addresses in this drafts is that private 549 IP behind a NAT come from 192.0.2.0/24, the public side of a NAT 550 comes from 198.51.100.0/24 and the TURN servers have addresses from 551 203.0.113.0/24. Typically the offer has an IP ending in .1 and the 552 answer has an IP ending in .2. 554 The examples do not include all the parts of SDP that are used in 555 RTCWeb (See [I-D.ietf-rtcweb-rtp-usage]) as that makes the example 556 unwieldy to read but instead focuses on showing the parts that are 557 key for the multiplexing. 559 7.1. Simple example with one audio and one video 561 The following SDP shows an offer that offers one audio stream and one 562 video steam with both a STUN and TURN address. 564 v=0 565 o=- 20518 0 IN IP4 198.51.100.1 566 s= 567 t=0 0 568 c=IN IP4 203.0.113.1 569 a=ice-ufrag:074c6550 570 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 571 a=fingerprint:sha-1 572 99:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:07 573 a=group:BUNDLE m1 m2 575 m=audio 56600 RTP/SAVPF 0 109 576 a=mid:m1 577 a=rtpmap:0 PCMU/8000 578 a=rtpmap:109 opus/48000 579 a=ptime:20 580 a=sendrecv 581 a=rtcp-mux 582 a=candidate:0 1 UDP 2113667327 192.0.2.1 54400 typ host 583 a=candidate:1 2 UDP 2113667326 192.0.2.1 54401 typ host 584 a=candidate:0 1 UDP 694302207 198.51.100.1 55500 typ srflx raddr 585 192.0.2.1 rport 54400 586 a=candidate:1 2 UDP 169430220 198.51.100.1 55501 typ srflx raddr 587 192.0.2.1 rport 54401 588 a=candidate:0 1 UDP 73545215 203.0.113.1 56600 typ relay raddr 589 192.0.2.1 rport 54400 590 a=candidate:1 2 UDP 51989708 203.0.113.1 56601 typ relay raddr 591 192.0.2.1 rport 54401 593 m=video 56602 RTP/SAVPF 99 120 594 a=mid:m2 595 a=rtpmap:99 H264/90000 596 a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 597 a=rtpmap:120 VP8/90000 598 a=sendrecv 599 a=rtcp-mux 600 a=candidate:3 1 UDP 2113667327 192.0.2.1 54402 typ host 601 a=candidate:4 2 UDP 2113667326 192.0.2.1 54403 typ host 602 a=candidate:3 1 UDP 694302207 198.51.100.1 55502 typ srflx raddr 603 192.0.2.1 rport 54402 604 a=candidate:4 2 UDP 169430220 198.51.100.1 55503 typ srflx raddr 605 192.0.2.1 rport 54403 606 a=candidate:3 1 UDP 73545215 203.0.113.1 56602 typ relay raddr 607 192.0.2.1 rport 54402 608 a=candidate:4 2 UDP 51989708 203.0.113.1 56603 typ relay raddr 609 192.0.2.1 rport 54403 611 The following shows and answer to the above offer from a device that 612 does not support bundle or rtcp-mux. 614 v=0 615 o=- 16833 0 IN IP4 198.51.100.2 616 s= 617 t=0 0 618 c=IN IP4 203.0.113.2 619 a=ice-ufrag:c300d85b 620 a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 621 a=fingerprint:sha-1 622 91:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:03 624 m=audio 60600 RTP/SAVPF 109 625 a=rtpmap:109 opus/48000 626 a=ptime:20 627 a=sendrecv 628 a=candidate:0 1 UDP 2113667327 192.0.2.2 60400 typ host 629 a=candidate:1 2 UDP 2113667326 192.0.2.2 60401 typ host 630 a=candidate:0 1 UDP 1694302207 198.51.100.2 60500 typ srflx raddr 631 192.0.2.2 rport 60400 632 a=candidate:1 2 UDP 1694302206 198.51.100.2 60501 typ srflx raddr 633 192.0.2.2 rport 60401 634 a=candidate:0 1 UDP 73545215 203.0.113.2 60600 typ relay raddr 635 192.0.2.1 rport 60400 636 a=candidate:1 2 UDP 51989708 203.0.113.2 60601 typ relay raddr 637 192.0.2.1 rport 60401 639 m=video 60602 RTP/SAVPF 99 640 a=rtpmap:99 H264/90000 641 a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 642 a=sendrecv 643 a=candidate:2 1 UDP 2113667327 192.0.2.2 60402 typ host 644 a=candidate:3 2 UDP 2113667326 192.0.2.2 60403 typ host 645 a=candidate:2 1 UDP 694302207 198.51.100.2 60502 typ srflx raddr 646 192.0.2.2 rport 60402 647 a=candidate:3 2 UDP 169430220 198.51.100.2 60503 typ srflx raddr 648 192.0.2.2 rport 60403 649 a=candidate:2 1 UDP 73545215 203.0.113.2 60602 typ relay raddr 650 192.0.2.2 rport 60402 651 a=candidate:3 2 UDP 51989708 203.0.113.2 60603 typ relay raddr 652 192.0.2.2 rport 60403 654 The following shows and answer to the above offer from a device that 655 does support bundle. 657 v=0 658 o=- 16833 0 IN IP4 198.51.100.2 659 s= 660 t=0 0 661 c=IN IP4 203.0.113.2 662 a=ice-ufrag:c300d85b 663 a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 664 a=fingerprint:sha-1 665 91:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:03 667 m=audio 60600 RTP/SAVPF 109 668 a=rtpmap:109 opus/48000 669 a=ptime:20 670 a=sendrecv 671 a=rtcp-mux 672 a=candidate:0 1 UDP 2113667327 192.0.2.2 60400 typ host 673 a=candidate:0 1 UDP 1694302207 198.51.100.2 60500 typ srflx raddr 674 192.0.2.2 rport 60400 675 a=candidate:0 1 UDP 73545215 203.0.113.2 60600 typ relay raddr 676 192.0.2.1 rport 60400 678 m=video 60600 RTP/SAVPF 99 679 a=rtpmap:99 H264/90000 680 a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 681 a=sendrecv 682 a=rtcp-mux 683 a=candidate:3 1 UDP 2113667327 192.0.2.2 60400 typ host 684 a=candidate:3 1 UDP 694302207 198.51.100.2 60500 typ srflx raddr 685 192.0.2.2 rport 60400 686 a=candidate:3 1 UDP 73545215 203.0.113.2 60600 typ relay raddr 687 192.0.2.2 rport 60400 689 7.2. Multiple Videos 691 Simple example showing an offer with one audio stream and two video 692 streams. 694 v=0 695 o=- 20518 0 IN IP4 198.51.100.1 696 s= 697 t=0 0 698 c=IN IP4 203.0.113.1 699 a=ice-ufrag:F7gI 700 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 701 a=fingerprint:sha-1 702 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 703 a=group:BUNDLE m1 m2 m3 705 m=audio 56600 RTP/SAVPF 0 96 706 a=mid:m1 707 a=rtpmap:0 PCMU/8000 708 a=rtpmap:96 opus/48000 709 a=ptime:20 710 a=sendrecv 711 a=rtcp-mux 712 a=candidate:0 1 UDP 2113667327 192.0.2.1 54400 typ host 713 a=candidate:1 2 UDP 2113667326 192.0.2.1 54401 typ host 714 a=candidate:0 1 UDP 694302207 198.51.100.1 55500 typ srflx raddr 715 192.0.2.1 rport 54400 716 a=candidate:1 2 UDP 169430220 198.51.100.1 55501 typ srflx raddr 717 192.0.2.1 rport 54401 718 a=candidate:0 1 UDP 73545215 203.0.113.1 56600 typ relay raddr 719 192.0.2.1 rport 54400 720 a=candidate:1 2 UDP 51989708 203.0.113.1 56601 typ relay raddr 721 192.0.2.1 rport 54401 723 m=video 56602 RTP/SAVPF 97 98 724 a=mid:m2 725 a=rtpmap:97 H264/90000 726 a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 727 a=rtpmap:98 VP8/90000 728 a=sendrecv 729 a=rtcp-mux 730 a=candidate:2 1 UDP 2113667327 192.0.2.1 54402 typ host 731 a=candidate:3 2 UDP 2113667326 192.0.2.1 54403 typ host 732 a=candidate:2 1 UDP 694302207 198.51.100.1 55502 typ srflx raddr 733 192.0.2.1 rport 54402 734 a=candidate:3 2 UDP 169430220 198.51.100.1 55503 typ srflx raddr 735 192.0.2.1 rport 54403 736 a=candidate:2 1 UDP 73545215 203.0.113.1 56602 typ relay raddr 737 192.0.2.1 rport 54402 738 a=candidate:3 2 UDP 51989708 203.0.113.1 56603 typ relay raddr 739 192.0.2.1 rport 54403 740 a=ssrc:11111 cname:45:5f:fe:cb:81:e9 742 m=video 56604 RTP/SAVPF 99 100 743 a=mid:m3 744 a=rtpmap:99 H264/90000 745 a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 746 a=rtpmap:100 VP8/90000 747 a=sendrecv 748 a=rtcp-mux 749 a=candidate:4 1 UDP 2113667327 192.0.2.1 54404 typ host 750 a=candidate:5 2 UDP 2113667326 192.0.2.1 54405 typ host 751 a=candidate:4 1 UDP 694302207 198.51.100.1 55504 typ srflx raddr 752 192.0.2.1 rport 54404 753 a=candidate:5 2 UDP 169430220 198.51.100.1 55505 typ srflx raddr 754 192.0.2.1 rport 54405 755 a=candidate:4 1 UDP 73545215 203.0.113.1 56604 typ relay raddr 756 192.0.2.1 rport 54404 757 a=candidate:5 2 UDP 51989708 203.0.113.1 56605 typ relay raddr 758 192.0.2.1 rport 54405 759 a=ssrc:22222 cname:45:5f:fe:cb:81:e9 761 7.3. Many Videos 763 This section adds three video streams and one audio. The video 764 streams are sent in such a way that they they are only accepted if 765 the far side supports bundle using the "bundle only" approach 766 described in Section 6.1. The video streams also use the same 767 payload types so it will not be possible to demux the video streams 768 from each other without using the SSRC values. 770 v=0 771 o=- 20518 0 IN IP4 198.51.100.1 772 s= 773 t=0 0 774 c=IN IP4 203.0.113.1 775 a=ice-ufrag:F7gI 776 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 777 a=fingerprint:sha-1 778 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 779 a=group:BUNDLE m0 m1 m2 m3 781 m=audio 56600 RTP/SAVPF 0 96 782 a=mid:m0 783 a=rtpmap:0 PCMU/8000 784 a=rtpmap:96 opus/48000 785 a=ptime:20 786 a=sendrecv 787 a=rtcp-mux 788 a=candidate:0 1 UDP 2113667327 192.0.2.1 54400 typ host 789 a=candidate:1 2 UDP 2113667326 192.0.2.1 54401 typ host 790 a=candidate:0 1 UDP 694302207 198.51.100.1 55500 typ srflx raddr 791 192.0.2.1 rport 54400 792 a=candidate:1 2 UDP 169430220 198.51.100.1 55501 typ srflx raddr 793 192.0.2.1 rport 54401 794 a=candidate:0 1 UDP 73545215 203.0.113.1 56600 typ relay raddr 795 192.0.2.1 rport 54400 796 a=candidate:1 2 UDP 51989708 203.0.113.1 56601 typ relay raddr 797 192.0.2.1 rport 54401 799 m=video 0 RTP/SAVPF 97 98 800 a=mid:m1 801 a=rtpmap:97 H264/90000 802 a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 803 a=rtpmap:98 VP8/90000 804 a=sendrecv 805 a=rtcp-mux 806 a=bundle-only 807 a=ssrc:11111 cname:45:5f:fe:cb:81:e9 809 m=video 0 RTP/SAVPF 97 98 810 a=mid:m2 811 a=rtpmap:97 H264/90000 812 a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 813 a=rtpmap:98 VP8/90000 814 a=sendrecv 815 a=rtcp-mux 816 a=bundle-only 817 a=ssrc:22222 cname:45:5f:fe:cb:81:e9 819 m=video 0 RTP/SAVPF 97 98 820 a=mid:m3 821 a=rtpmap:97 H264/90000 822 a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 823 a=rtpmap:98 VP8/90000 824 a=sendrecv 825 a=rtcp-mux 826 a=bundle-only 827 a=ssrc:333333 cname:45:5f:fe:cb:81:e9 829 7.4. Multiple Videos with Simulcast 831 This section shows an offer with with audio and two video each of 832 which can send it two resolutions as described in Section 6.3. Note 833 that the grouping places the lower bitrate streams first, even though 834 those appear first in the document. All the video is bundle-only. 836 v=0 837 o=- 20518 0 IN IP4 198.51.100.1 838 s= 839 t=0 0 840 c=IN IP4 203.0.113.1 841 a=ice-ufrag:F7gI 842 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 843 a=fingerprint:sha-1 844 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 845 a=group:BUNDLE m0 m1 m2 m3 m4 847 a=group:SIMULCAST m2 m1 848 a=group:SIMULCAST m4 m3 849 m=audio 56600 RTP/SAVPF 0 96 850 a=mid:m0 851 a=rtpmap:0 PCMU/8000 852 a=rtpmap:96 opus/48000 853 a=ptime:20 854 a=sendrecv 855 a=rtcp-mux 856 a=candidate:0 1 UDP 2113667327 192.0.2.1 54400 typ host 857 a=candidate:1 2 UDP 2113667326 192.0.2.1 54401 typ host 858 a=candidate:0 1 UDP 694302207 198.51.100.1 55500 typ srflx raddr 859 192.0.2.1 rport 54400 860 a=candidate:1 2 UDP 169430220 198.51.100.1 55501 typ srflx raddr 861 192.0.2.1 rport 54401 862 a=candidate:0 1 UDP 73545215 203.0.113.1 56600 typ relay raddr 863 192.0.2.1 rport 54400 864 a=candidate:1 2 UDP 51989708 203.0.113.1 56601 typ relay raddr 865 192.0.2.1 rport 54401 867 m=video 0 RTP/SAVPF 98 868 b=AS:1500 869 a=mid:m1 870 a=rtpmap:98 VP8/90000 871 a=sendrecv 872 a=rtcp-mux 873 a=bundle-only 874 a=ssrc:11111 cname:45:5f:fe:cb:81:e9 875 a=framerate:30 877 m=video 0 RTP/SAVPF 100 878 b=AS:256 879 a=mid:m2 880 a=rtpmap:100 VP8/90000 881 a=sendrecv 882 a=rtcp-mux 883 a=bundle-only 884 a=ssrc:22222 cname:45:5f:fe:cb:81:e9 885 a=framerate:15 887 m=video 0 RTP/SAVPF 101 888 b=AS:1500 889 a=mid:m3 890 a=rtpmap:101 VP8/90000 891 a=sendrecv 892 a=rtcp-mux 893 a=bundle-only 894 a=ssrc:333333 cname:45:5f:fe:cb:81:e9 895 a=framerate:30 896 m=video 0 RTP/SAVPF 103 897 b=AS:256 898 a=mid:m4 899 a=rtpmap:103 VP8/90000 900 a=sendrecv 901 a=rtcp-mux 902 a=bundle-only 903 a=ssrc:44444 cname:45:5f:fe:cb:81:e9 904 a=framerate:15 906 7.5. Video with Simulcast and RTX 908 This section shows an SDP offer that has an audio and a single video 909 stream. The video stream that is simulcast at two resolutions and 910 has [RFC4588] style re-transmission flows. 912 v=0 913 o=- 20518 0 IN IP4 198.51.100.1 914 s= 915 t=0 0 916 c=IN IP4 203.0.113.1 917 a=ice-ufrag:F7gI 918 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 919 a=fingerprint:sha-1 920 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 921 a=group:BUNDLE m0 m1 m2 m3 m4 923 a=group:SIMULCAST m2 m1 924 a=group:FID m1 m3 925 a=group:FID m2 m4 927 m=audio 56600 RTP/SAVPF 0 96 928 a=mid:m0 929 a=rtpmap:0 PCMU/8000 930 a=rtpmap:96 opus/48000 931 a=ptime:20 932 a=sendrecv 933 a=rtcp-mux 934 a=candidate:0 1 UDP 2113667327 192.0.2.1 54400 typ host 935 a=candidate:1 2 UDP 2113667326 192.0.2.1 54401 typ host 936 a=candidate:0 1 UDP 694302207 198.51.100.1 55500 typ srflx raddr 937 192.0.2.1 rport 54400 938 a=candidate:1 2 UDP 169430220 198.51.100.1 55501 typ srflx raddr 939 192.0.2.1 rport 54401 940 a=candidate:0 1 UDP 73545215 203.0.113.1 56600 typ relay raddr 941 192.0.2.1 rport 54400 943 a=candidate:1 2 UDP 51989708 203.0.113.1 56601 typ relay raddr 944 192.0.2.1 rport 54401 946 m=video 0 RTP/SAVPF 100 // This is the high res video 947 b=AS:1500 948 a=mid:m1 949 a=rtpmap:98 VP8/90000 950 a=sendrecv 951 a=rtcp-mux 952 a=bundle-only 953 a=framerate:30 955 m=video 0 RTP/SAVPF 101 // This is the low res video 956 b=AS:256 957 a=mid:m2 958 a=rtpmap:100 VP8/90000 959 a=sendonly 960 a=rtcp-mux 961 a=bundle-only 962 a=framerate:15 964 m=video 0 RTP/SAVPF 110 // This is the retransmission of high res 965 b=AS:1500 966 a=mid:m3 967 a=rtpmap:101 rtx/90000 968 a=sendrecv 969 a=rtcp-mux 970 a=bundle-only 971 a=framerate:30 972 a=rtcp-fb:101 nack 973 a=fmtp:101 apt=100;rtx-time=3000 975 m=video 0 RTP/SAVPF 111 // This is retransmission of low res 976 b=AS:256 977 a=mid:m4 978 a=rtpmap:103 rtx/90000 979 a=sendonly 980 a=rtcp-mux 981 a=bundle-only 982 a=framerate:15 983 a=rtcp-fb:111 nack 984 a=fmtp:11 apt=101;rtx-time=3000 986 8. Security Considerations 988 TBD 990 9. IANA Considerations 992 TBD: registration of SIMULCAST group 994 10. Acknowledgements 996 Thanks to Cullen Jennings for his assistance in generating the SDP 997 examples in this document. 999 Some of the material in this document was taken from 1000 [I-D.jennings-rtcweb-plan]. 1002 11. References 1004 11.1. Normative References 1006 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1007 Holmberg, C., Alvestrand, H., and C. Jennings, 1008 "Multiplexing Negotiation Using Session Description 1009 Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- 1010 bundle-negotiation-03 (work in progress), February 2013. 1012 [I-D.jennings-mmusic-media-req] 1013 Jennings, C., Uberti, J., and E. Rescorla, "Requirements 1014 from various WG for MMUSIC", draft-jennings-mmusic-media- 1015 req-00 (work in progress), February 2013. 1017 [I-D.nandakumar-mmusic-sdp-mux-attributes] 1018 Nandakumar, S., "A Framework for SDP Attributes when 1019 Multiplexing", draft-nandakumar-mmusic-sdp-mux- 1020 attributes-02 (work in progress), April 2013. 1022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1023 Requirement Levels", BCP 14, RFC 2119, March 1997. 1025 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1026 with Session Description Protocol (SDP)", RFC 3264, June 1027 2002. 1029 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1030 Description Protocol", RFC 4566, July 2006. 1032 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1033 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1035 11.2. Informative References 1037 [I-D.ietf-rtcweb-rtp-usage] 1038 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 1039 Communication (WebRTC): Media Transport and Use of RTP", 1040 draft-ietf-rtcweb-rtp-usage-06 (work in progress), 1041 February 2013. 1043 [I-D.jennings-rtcweb-plan] 1044 Jennings, C., "Proposed Plan for Usage of SDP and RTP", 1045 draft-jennings-rtcweb-plan-01 (work in progress), February 1046 2013. 1048 [I-D.roach-rtcweb-glareless-add] 1049 Roach, A. B., "An Approach for Adding RTCWEB Media Streams 1050 without Glare ", May 2013. 1052 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1053 Jacobson, "RTP: A Transport Protocol for Real-Time 1054 Applications", STD 64, RFC 3550, July 2003. 1056 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1057 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1058 July 2006. 1060 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1061 January 2008. 1063 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1064 (ICE): A Protocol for Network Address Translator (NAT) 1065 Traversal for Offer/Answer Protocols", RFC 5245, April 1066 2010. 1068 [webrtc-api] 1069 Bergkvist, Burnett, Jennings, Narayanan, , "WebRTC 1.0: 1070 Real-time Communication Between Browsers", October 2011. 1072 Available at http://dev.w3.org/2011/webrtc/editor/ 1073 webrtc.html 1075 Authors' Addresses 1077 Adam Roach 1078 Mozilla 1079 Dallas, TX 1080 US 1082 Phone: +1 650 903 0800 x863 1083 Email: adam@nostrum.com 1084 Martin Thomson 1085 Microsoft 1086 3210 Porter Drive 1087 Palo Alto, CA 94304 1088 US 1090 Phone: +1 650 353 1925 1091 Email: martin.thomson@skype.net