Internet DRAFT - draft-roach-rtcweb-plan-a
draft-roach-rtcweb-plan-a
Network Working Group A. B. Roach
Internet-Draft Mozilla
Intended status: Informational M. Thomson
Expires: November 08, 2013 Microsoft
May 07, 2013
Using SDP with Large Numbers of Media Flows
draft-roach-rtcweb-plan-a-00
Abstract
A recurrent theme in WebRTC has been the need to handle very large
numbers of media flows. Unfortunately, naive uses of SDP do not
handle this case particularly well. This document describes a modest
set of extensions to SDP which allow it to cleanly handle arbitrary
numbers of flows while still retaining a large degree of backward
compatibility with existing and non-RTCWEB endpoints.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 08, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Roach & Thomson Expires November 08, 2013 [Page 1]
Internet-Draft SDP Many Flows May 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Syntax Conventions . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Detailed Description . . . . . . . . . . . . . . . . . . . . 7
6.1. Bundle-Only M-Lines . . . . . . . . . . . . . . . . . . . 7
6.2. Flow Demultiplexing . . . . . . . . . . . . . . . . . . . 10
6.3. Indicating Simulcast Groups . . . . . . . . . . . . . . . 11
6.4. Identifying Flows . . . . . . . . . . . . . . . . . . . . 11
6.5. Compatibility with Non-RTCWEB uses . . . . . . . . . . . 11
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Simple example with one audio and one video . . . . . . . 12
7.2. Multiple Videos . . . . . . . . . . . . . . . . . . . . . 15
7.3. Many Videos . . . . . . . . . . . . . . . . . . . . . . . 17
7.4. Multiple Videos with Simulcast . . . . . . . . . . . . . 18
7.5. Video with Simulcast and RTX . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
A recurrent theme in WebRTC has been the need to cleanly handle very
large numbers of media flows. For instance, a video conferencing
application might have a main display plus thumbnails for 10 or more
other speakers all displayed at the same time. If each video source
is encoded in multiple resolutions (e.g., simulcast or layered
coding) and also has FEC or RTX, this could easily add up to 30 or
more independent RTP flows.
The standard way of encoding this information in SDP is to have each
RTP flow (i.e., SSRC) appear on its own m-line. For instance, the
SDP for two cameras with audio from a device with a public IP address
could look something like:
v=0
o=- 20518 0 IN IP4 203.0.113.1
s=
Roach & Thomson Expires November 08, 2013 [Page 2]
Internet-Draft SDP Many Flows May 2013
t=0 0
c=IN IP4 203.0.113.1
a=ice-ufrag:F7gI
a=ice-pwd:x9cml/YzichV2+XlhiMu8g
a=fingerprint:sha-1
42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7
m=audio 54400 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 opus/48000
a=ptime:20
a=sendrecv
a=candidate:0 1 UDP 2113667327 203.0.113.1 54400 typ host
a=candidate:1 2 UDP 2113667326 203.0.113.1 54401 typ host
m=video 55400 RTP/SAVPF 97 98
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
a=rtpmap:98 VP8/90000
a=sendrecv
a=candidate:0 1 UDP 2113667327 203.0.113.1 55400 typ host
a=candidate:1 2 UDP 2113667326 203.0.113.1 55401 typ host
m=video 56400 RTP/SAVPF 99 100
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=4d0028;packetization-mode=1
a=rtpmap:100 VP8/90000
a=sendrecv
a=candidate:0 1 UDP 2113667327 203.0.113.1 56400 typ host
a=candidate:1 2 UDP 2113667326 203.0.113.1 56401 typ host
Unfortunately, as the number of independent media sources starts to
increase, the scaling properties of this approach become problematic.
In particular, SDP currently requires that each m-line have its own
transport parameters (port, ICE candidates, etc.), which can get
expensive. For instance, the [RFC5245] pacing algorithm requires
that new STUN transactions be started no more frequently than 20 ms;
with 30 RTP flows, which would add 600 ms of latency for candidate
gathering alone. Moreover, having 30 persistent flows might lead to
excessive consumption of NAT binding resources.
A related issue is the number of payload types. Even multiple
sources are multiplexed over the same transport flow they must
somehow be demultiplexed. Consider the case where we want to be able
to transmit 32 video thumbnails (this is large, but not insane). In
the model described above, each of these flows would need its own
m-line and its own set of codecs. If each side supports three
Roach & Thomson Expires November 08, 2013 [Page 3]
Internet-Draft SDP Many Flows May 2013
separate codecs (e.g., H.263, H.264, VP8, and VP9), then we have just
consumed 128 payload types, which exceeds the available dynamic
payload space. This makes demuxing on payload type problematic in
some cases.
This document specifies a small number of modest extensions to SDP
which are intended to reduce the transport impact of using a large
number of flows. The general design philosophy is to maintain the
existing SDP negotiation model while simply reducing the consumption
of network resources.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119].
This draft uses the API and terminology described in [webrtc-api].
5-tuple: A collection of the following values: source IP address,
source transport port, destination IP address, destination transport
port and transport protocol.
Transport-Flow: An transport 5 Tuple representing the UDP source and
destination IP address and port over which RTP is flowing.
PC-Track: A source of media (audio and/or video) that is contained in
a PC-Stream. A PC-Track represents content comprising one or more
PC-Channels.
m-line: An SDP [RFC4566] media description identifier that starts
with an "m=" field and conveys the following values: media type,
transport port, transport protocol and media format descriptions.
Offer: An [RFC3264] SDP message generated by the participant who
wishes to initiate a multimedia communication session. An Offer
describes the participant's capabilities for engaging in a multimedia
session.
Answer: An [RFC3264] SDP message generated by the participant in
response to an Offer. An Answer describes the participant's
capabilities in continuing with the multimedia session with in the
constraints of the Offer.
This draft avoids using terms that implementors do not have a clear
idea of exactly what they are - for example RTP Session.
Roach & Thomson Expires November 08, 2013 [Page 4]
Internet-Draft SDP Many Flows May 2013
3. Syntax Conventions
The SDP examples given in this document deviate from actual on-the-
wire SDP notation in several ways. This is done to facilitate
readability and to conform to the restrictions imposed by the RFC
formatting rules. These deviations are as follows:
o Any line that is indented (compared to the initial line in the SDP
block) is a continuation of the preceding line. The line break
and indent are to be interpreted as a single space character.
o Empty lines in any SDP example are inserted to make functional
divisions in the SDP clearer, and are not actually part of the SDP
syntax.
o Excepting the above two conventions, line endings are to be
interpreted as <CR><LF> pairs (that is, an ASCII 13 followed by an
ASCII 10).
o Any text starting with the string "//" to the end of the line is
inserted for the benefit of the reader, and is not actually part
of the SDP syntax.
4. Requirements
This document is intended to address the following requirements,
based on those from [I-D.jennings-mmusic-media-req].
1. Support many media flows but minimize the number of transport
flows.
This requirement is partly satisfied by BUNDLE
[I-D.ietf-mmusic-sdp-bundle-negotiation]; however, BUNDLE
still requires a large number of ports and ICE candidates
in the initial offer. This can create serious latency
issues, as described in Section 1. The mechanisms in
Section Section 6.1 of this document address those issues.
3. Be able to successfully negotiate media with both legacy SIP
devices and new devices (whether SIP or RTCWEB) with a single
offer/answer exchange. If both endpoints support multiplexed
media, then multiplexing should be negotiated. Otherwise, non-
multiplexed media should be used.
The interaction of this mechanism with non-WEBRTC devices
is described in Section 6.5.
Roach & Thomson Expires November 08, 2013 [Page 5]
Internet-Draft SDP Many Flows May 2013
5. Provide a mechanism for harmonizing flow parameters for
different m-lines when they are multiplexed over the same
transport.
[I-D.nandakumar-mmusic-sdp-mux-attributes] documents the
required procedures.
7. Allow different sources (e.g., cameras) to use different codecs.
For example, if one camera had hardware encoders for VP8 while
another had encoders for H.264, the device may wish to negotiate
different codecs.
This requirement is also already satisfied by existing SDP
mechanisms; we simply need to preserve them.
9. Be able to independently set parameters such as resolution and
bandwidth, independently for each PC-Track, preferably even when
they are all multiplexed over the same transport flow.
Section 6.2 of this document satisfies the multiplexing
requirement and the normal SDP mechanisms are used for
parameters.
11. Be able to identify the PC-Tracks with an identifier that is
stable over the duration of the session.
Section 6.2 of this document explains track
identification.
Note that this document does not attempt to address the issue of
adding a stream with little or no chance of glare. See
[I-D.roach-rtcweb-glareless-add] for the description of a technique
that can be applied to any SDP offer/answer session establishment
protocol to eliminate mid-session glare.
5. Overview
This section provides an overview of the approach specified in this
document.
o We retain the existing SDP model that the m-line is the basic unit
of media negotiation/representation. Each independent unit (i.e.,
a specific encoding of a PC-Track) is represented on its own
m-line.
o BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] is used to
multiplex multiple m-lines (and their corresponding media) onto
the same set of transport flows.
Roach & Thomson Expires November 08, 2013 [Page 6]
Internet-Draft SDP Many Flows May 2013
o Both RTP payload type (PT) and SSRC are used to de-multiplex flows
multiplexed via bundle. This allows for many more flows to be
bundled than the limited number of PTs available.
o In order to minimize the number of transport parameters that need
to be allocated during the gathering phase, m-lines can be tagged
as "bundle only". Such m-lines in an offer will be ignored by
legacy endpoints but can be negotiated by endpoints that support
the mechanisms specified in this document.
6. Detailed Description
6.1. Bundle-Only M-Lines
As discussed in Section 1, even with bundle, it is expensive to
allocate ICE candidates for a large number of m-lines. An offer can
contain "bundle-only" m-lines which will be negotiated only by
endpoints which implement this specification and ignored by other
endpoints.
In order to offer such an m-line, the offerer does two things:
o Sets the port in the m-line to 0. This indicates to old endpoints
that the m-line is not to be negotiated.
o Adds an a=bundle-only line. This indicates to new endpoints that
the m-line is to be negotiated if (and only if) bundling is used.
An example offer that uses this feature looks like this:
v=0
o=- 20518 0 IN IP4 203.0.113.1
s=
t=0 0
c=IN IP4 203.0.113.1
a=ice-ufrag:F7gI
a=ice-pwd:x9cml/YzichV2+XlhiMu8g
a=fingerprint:sha-1
42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7
m=audio 54400 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 opus/48000
a=ptime:20
a=sendrecv
a=rtcp-mux
a=candidate:0 1 UDP 2113667327 203.0.113.1 54400 typ host
a=candidate:1 2 UDP 2113667326 203.0.113.1 54401 typ host
Roach & Thomson Expires November 08, 2013 [Page 7]
Internet-Draft SDP Many Flows May 2013
m=video 0 RTP/SAVPF 97 98
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
a=rtpmap:98 VP8/90000
a=sendrecv
a=rtcp-mux
a=bundle-only
m=video 0 RTP/SAVPF 99 100
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=4d0028;packetization-mode=1
a=rtpmap:100 VP8/90000
a=sendrecv
a=rtcp-mux
a=bundle-only
An old endpoint simply rejects the bundle-only m-lines by responding
with a 0 port. (This isn't a normative statement, just a description
of the way the older endpoints are expected to act.)
v=0
o=- 20518 0 IN IP4 203.0.113.1
s=
t=0 0
c=IN IP4 203.0.113.2
a=ice-ufrag:F7gI
a=ice-pwd:x9cml/YzichV2+XlhiMu8g
a=fingerprint:sha-1
42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7
m=audio 55400 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 opus/48000
a=ptime:20
a=sendrecv
a=candidate:0 1 UDP 2113667327 203.0.113.2 55400 typ host
a=candidate:1 2 UDP 2113667326 203.0.113.2 55401 typ host
m=video 0 RTP/SAVPF 97 98
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
a=rtpmap:98 VP8/90000
a=sendrecv
m=video 0 RTP/SAVPF 99 100
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=4d0028;packetization-mode=1
Roach & Thomson Expires November 08, 2013 [Page 8]
Internet-Draft SDP Many Flows May 2013
a=rtpmap:100 VP8/90000
a=sendrecv
A new endpoint accepts the m-lines (both bundle-only and regular) by
offering m-lines with a valid port, though this port may be
duplicated as specified in Section 6 of
[I-D.ietf-mmusic-sdp-bundle-negotiation]. For instance:
v=0
o=- 20518 0 IN IP4 203.0.113.2
s=
t=0 0
c=IN IP4 203.0.113.2
a=ice-ufrag:F7gI
a=ice-pwd:x9cml/YzichV2+XlhiMu8g
a=fingerprint:sha-1
42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7
m=audio 55400 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 opus/48000
a=ptime:20
a=sendrecv
a=rtcp-mux
a=candidate:0 1 UDP 2113667327 203.0.113.2 55400 typ host
m=video 55400 RTP/SAVPF 97 98
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
a=rtpmap:98 VP8/90000
a=sendrecv
a=rtcp-mux
a=bundle-only
m=video 55400 RTP/SAVPF 99 100
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=4d0028;packetization-mode=1
a=rtpmap:100 VP8/90000
a=sendrecv
a=rtcp-mux
a=bundle-only
Endpoints MUST NOT accept bundle-only m-lines if they are not part of
an accepted bundle group.
Roach & Thomson Expires November 08, 2013 [Page 9]
Internet-Draft SDP Many Flows May 2013
6.2. Flow Demultiplexing
As noted above, if a large number of m-lines are used and each codec
in each m-line uses its own PT, it is possible to exceed the number
of possible PT values. This makes PT-only demultiplexing
insufficient in some cases.
Offerers conformant to this specification MUST do one of the
following:
o Use non-overlapping PT values for each m-line in any given bundle
group.
o Provide distinct a=ssrc attributes for each m-line which uses
overlapping PT values with any other m-line. [Technically, this
is a general case of the previous point.]
If the offerer uses overlapping PT values for any two m-lines in a
given bundle group, the answerer MUST supply distinct a=ssrc
attributes for those m-lines.
Upon receipt of an RTP datagram on a port that is being used with
multiplexing, implementors SHOULD follow a procedure equivalent to
the following to demultiplex streams:
o If the SSRC in the received packet matches one that has been
mapped to an m-line (e.g., via a=ssrc attributes), then the packet
corresponds to that m-line.
o If the SSRC in the received packet does not matches one that has
associated with an m-line, but the PT value appears on only one
m-line, then the packet corresponds to the m-line containing that
PT.
o Otherwise, discard the packet.
Note that this approach means that if PT values overlap between two
m-lines, then those m-lines cannot be demultiplexed prior to
receiving the m-line-to-ssrc mapping (e.g., in the SDP answer). For
instance, if the offerer wants two m-lines to be rendered prior to
receipt of the SDP answer, it can use non-overlapping PT values on
those m-lines.
Roach & Thomson Expires November 08, 2013 [Page 10]
Internet-Draft SDP Many Flows May 2013
6.3. Indicating Simulcast Groups
Simulcast refers to taking a single capture (e.g., a camera), and
encoding it multiple times at different resolutions and / or frame
rates. For example, a device with a single HD camera may send one
version of the video at full HD resolution, and a second version
encoded at a low resolution. This would allow a video conferencing
bridge to be able to send the high resolution copy to some
destination and low resolution copy to other destinations without
having to recode the video at the conference bridge.
This document proposes that simulcast be done by defining a new SDP
group [RFC5888] called SIMULCAST. Any m-lines that are in the same
SIMULCAST group are alternative encodings of the same media capture.
One of the advantages of this approach is it works well with the many
existing RTP definitions that have been done in the past as well as
others that may be done in the future.
The order of m-lines in a SIMULCAST group determines the relative
size of the encoded streams. Streams at lower quality appear before
streams of higher quality. The entity creating the session
description can choose to order m-lines based on any quality criteria
(resolution, framerate, sample rate), but they SHOULD choose an
ordering that places streams with a lower average bitrate before
higher bitrate streams.
Providing an order to SIMULCAST groupings allows an intermediary
(such as a Media Translator [RFC5117]) to be able to select an
appropriate SIMULCAST layer without inspecting the media stream,
which could otherwise require decrypting and possibly partially
decoding media packets.
6.4. Identifying Flows
While this topic is largely out of scope for SDP, the SSRC value can
be used as a flow identifier. One minor caveat with this approach is
the ability to deal with the SSRC collision resolution procedure
described in section 8.2 of [RFC3550]. In the rare circumstances
that such an SSRC change is required, then any party that has changed
its SSRC needs to inform the remote participants of the updated
mapping, e.g. via a new SDP offer. In WebRTC use cases, this would
trigger an onrennegotiationneeded event.
6.5. Compatibility with Non-RTCWEB uses
Due to the fact that this approach re-uses existing SDP constructs
for indicating parameters in a media section, it remains compatible
Roach & Thomson Expires November 08, 2013 [Page 11]
Internet-Draft SDP Many Flows May 2013
with non-RTCWEB clients. Of particular note is the handling of
"bundle-only" media sections, described in Section 6.1. Offers
generated by an RTCWEB client and sent to a non-RTCWEB client will
simply negotiate those media the RTCWEB client did not use the
"bundle-only" extension with. This allows RTCWEB clients to select
which media streams are important for interoperability with non-
RTCWEB clients (by not making them bundle-only), and which ones are
not. Offers generated by non-RTCWEB clients will simply omit any
bundle-related attributes, and the RTCWEB client will be able to
process the SDP otherwise identically to the SDP received from RTCWEB
clients: each m-line represents a different media stream, and
contains a description of that stream in a syntax identical to the
syntax used between RTCWEB clients.
With the bundle-only approach, only those streams that are "important
for interoperability" will require allocation of ports and ICE
exchanges. By doing so, working with non-multiplexing clients is
enabled without requiring excess resource allocation for those
streams that are not critical for proper user experience.
Aside from BUNDLE, the bundle-only mechanism, and the rules around
port demultiplexing, this proposal requires no additional extensions
to SDP or the offer/answer model.
7. Examples
In all of these examples, there are many lines that are wrapped due
to column width limitation. It should be understood these lines are
not wrapped in the real SDP.
The convention used for IP addresses in this drafts is that private
IP behind a NAT come from 192.0.2.0/24, the public side of a NAT
comes from 198.51.100.0/24 and the TURN servers have addresses from
203.0.113.0/24. Typically the offer has an IP ending in .1 and the
answer has an IP ending in .2.
The examples do not include all the parts of SDP that are used in
RTCWeb (See [I-D.ietf-rtcweb-rtp-usage]) as that makes the example
unwieldy to read but instead focuses on showing the parts that are
key for the multiplexing.
7.1. Simple example with one audio and one video
The following SDP shows an offer that offers one audio stream and one
video steam with both a STUN and TURN address.
v=0
o=- 20518 0 IN IP4 198.51.100.1
Roach & Thomson Expires November 08, 2013 [Page 12]
Internet-Draft SDP Many Flows May 2013
s=
t=0 0
c=IN IP4 203.0.113.1
a=ice-ufrag:074c6550
a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068
a=fingerprint:sha-1
99:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:07
a=group:BUNDLE m1 m2
m=audio 56600 RTP/SAVPF 0 109
a=mid:m1
a=rtpmap:0 PCMU/8000
a=rtpmap:109 opus/48000
a=ptime:20
a=sendrecv
a=rtcp-mux
a=candidate:0 1 UDP 2113667327 192.0.2.1 54400 typ host
a=candidate:1 2 UDP 2113667326 192.0.2.1 54401 typ host
a=candidate:0 1 UDP 694302207 198.51.100.1 55500 typ srflx raddr
192.0.2.1 rport 54400
a=candidate:1 2 UDP 169430220 198.51.100.1 55501 typ srflx raddr
192.0.2.1 rport 54401
a=candidate:0 1 UDP 73545215 203.0.113.1 56600 typ relay raddr
192.0.2.1 rport 54400
a=candidate:1 2 UDP 51989708 203.0.113.1 56601 typ relay raddr
192.0.2.1 rport 54401
m=video 56602 RTP/SAVPF 99 120
a=mid:m2
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=4d0028;packetization-mode=1
a=rtpmap:120 VP8/90000
a=sendrecv
a=rtcp-mux
a=candidate:3 1 UDP 2113667327 192.0.2.1 54402 typ host
a=candidate:4 2 UDP 2113667326 192.0.2.1 54403 typ host
a=candidate:3 1 UDP 694302207 198.51.100.1 55502 typ srflx raddr
192.0.2.1 rport 54402
a=candidate:4 2 UDP 169430220 198.51.100.1 55503 typ srflx raddr
192.0.2.1 rport 54403
a=candidate:3 1 UDP 73545215 203.0.113.1 56602 typ relay raddr
192.0.2.1 rport 54402
a=candidate:4 2 UDP 51989708 203.0.113.1 56603 typ relay raddr
192.0.2.1 rport 54403
The following shows and answer to the above offer from a device that
does not support bundle or rtcp-mux.
Roach & Thomson Expires November 08, 2013 [Page 13]
Internet-Draft SDP Many Flows May 2013
v=0
o=- 16833 0 IN IP4 198.51.100.2
s=
t=0 0
c=IN IP4 203.0.113.2
a=ice-ufrag:c300d85b
a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2
a=fingerprint:sha-1
91:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:03
m=audio 60600 RTP/SAVPF 109
a=rtpmap:109 opus/48000
a=ptime:20
a=sendrecv
a=candidate:0 1 UDP 2113667327 192.0.2.2 60400 typ host
a=candidate:1 2 UDP 2113667326 192.0.2.2 60401 typ host
a=candidate:0 1 UDP 1694302207 198.51.100.2 60500 typ srflx raddr
192.0.2.2 rport 60400
a=candidate:1 2 UDP 1694302206 198.51.100.2 60501 typ srflx raddr
192.0.2.2 rport 60401
a=candidate:0 1 UDP 73545215 203.0.113.2 60600 typ relay raddr
192.0.2.1 rport 60400
a=candidate:1 2 UDP 51989708 203.0.113.2 60601 typ relay raddr
192.0.2.1 rport 60401
m=video 60602 RTP/SAVPF 99
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=4d0028;packetization-mode=1
a=sendrecv
a=candidate:2 1 UDP 2113667327 192.0.2.2 60402 typ host
a=candidate:3 2 UDP 2113667326 192.0.2.2 60403 typ host
a=candidate:2 1 UDP 694302207 198.51.100.2 60502 typ srflx raddr
192.0.2.2 rport 60402
a=candidate:3 2 UDP 169430220 198.51.100.2 60503 typ srflx raddr
192.0.2.2 rport 60403
a=candidate:2 1 UDP 73545215 203.0.113.2 60602 typ relay raddr
192.0.2.2 rport 60402
a=candidate:3 2 UDP 51989708 203.0.113.2 60603 typ relay raddr
192.0.2.2 rport 60403
The following shows and answer to the above offer from a device that
does support bundle.
v=0
o=- 16833 0 IN IP4 198.51.100.2
s=
t=0 0
Roach & Thomson Expires November 08, 2013 [Page 14]
Internet-Draft SDP Many Flows May 2013
c=IN IP4 203.0.113.2
a=ice-ufrag:c300d85b
a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2
a=fingerprint:sha-1
91:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:03
m=audio 60600 RTP/SAVPF 109
a=rtpmap:109 opus/48000
a=ptime:20
a=sendrecv
a=rtcp-mux
a=candidate:0 1 UDP 2113667327 192.0.2.2 60400 typ host
a=candidate:0 1 UDP 1694302207 198.51.100.2 60500 typ srflx raddr
192.0.2.2 rport 60400
a=candidate:0 1 UDP 73545215 203.0.113.2 60600 typ relay raddr
192.0.2.1 rport 60400
m=video 60600 RTP/SAVPF 99
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=4d0028;packetization-mode=1
a=sendrecv
a=rtcp-mux
a=candidate:3 1 UDP 2113667327 192.0.2.2 60400 typ host
a=candidate:3 1 UDP 694302207 198.51.100.2 60500 typ srflx raddr
192.0.2.2 rport 60400
a=candidate:3 1 UDP 73545215 203.0.113.2 60600 typ relay raddr
192.0.2.2 rport 60400
7.2. Multiple Videos
Simple example showing an offer with one audio stream and two video
streams.
v=0
o=- 20518 0 IN IP4 198.51.100.1
s=
t=0 0
c=IN IP4 203.0.113.1
a=ice-ufrag:F7gI
a=ice-pwd:x9cml/YzichV2+XlhiMu8g
a=fingerprint:sha-1
42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7
a=group:BUNDLE m1 m2 m3
m=audio 56600 RTP/SAVPF 0 96
a=mid:m1
a=rtpmap:0 PCMU/8000
Roach & Thomson Expires November 08, 2013 [Page 15]
Internet-Draft SDP Many Flows May 2013
a=rtpmap:96 opus/48000
a=ptime:20
a=sendrecv
a=rtcp-mux
a=candidate:0 1 UDP 2113667327 192.0.2.1 54400 typ host
a=candidate:1 2 UDP 2113667326 192.0.2.1 54401 typ host
a=candidate:0 1 UDP 694302207 198.51.100.1 55500 typ srflx raddr
192.0.2.1 rport 54400
a=candidate:1 2 UDP 169430220 198.51.100.1 55501 typ srflx raddr
192.0.2.1 rport 54401
a=candidate:0 1 UDP 73545215 203.0.113.1 56600 typ relay raddr
192.0.2.1 rport 54400
a=candidate:1 2 UDP 51989708 203.0.113.1 56601 typ relay raddr
192.0.2.1 rport 54401
m=video 56602 RTP/SAVPF 97 98
a=mid:m2
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
a=rtpmap:98 VP8/90000
a=sendrecv
a=rtcp-mux
a=candidate:2 1 UDP 2113667327 192.0.2.1 54402 typ host
a=candidate:3 2 UDP 2113667326 192.0.2.1 54403 typ host
a=candidate:2 1 UDP 694302207 198.51.100.1 55502 typ srflx raddr
192.0.2.1 rport 54402
a=candidate:3 2 UDP 169430220 198.51.100.1 55503 typ srflx raddr
192.0.2.1 rport 54403
a=candidate:2 1 UDP 73545215 203.0.113.1 56602 typ relay raddr
192.0.2.1 rport 54402
a=candidate:3 2 UDP 51989708 203.0.113.1 56603 typ relay raddr
192.0.2.1 rport 54403
a=ssrc:11111 cname:45:5f:fe:cb:81:e9
m=video 56604 RTP/SAVPF 99 100
a=mid:m3
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=4d0028;packetization-mode=1
a=rtpmap:100 VP8/90000
a=sendrecv
a=rtcp-mux
a=candidate:4 1 UDP 2113667327 192.0.2.1 54404 typ host
a=candidate:5 2 UDP 2113667326 192.0.2.1 54405 typ host
a=candidate:4 1 UDP 694302207 198.51.100.1 55504 typ srflx raddr
192.0.2.1 rport 54404
a=candidate:5 2 UDP 169430220 198.51.100.1 55505 typ srflx raddr
192.0.2.1 rport 54405
a=candidate:4 1 UDP 73545215 203.0.113.1 56604 typ relay raddr
Roach & Thomson Expires November 08, 2013 [Page 16]
Internet-Draft SDP Many Flows May 2013
192.0.2.1 rport 54404
a=candidate:5 2 UDP 51989708 203.0.113.1 56605 typ relay raddr
192.0.2.1 rport 54405
a=ssrc:22222 cname:45:5f:fe:cb:81:e9
7.3. Many Videos
This section adds three video streams and one audio. The video
streams are sent in such a way that they they are only accepted if
the far side supports bundle using the "bundle only" approach
described in Section 6.1. The video streams also use the same
payload types so it will not be possible to demux the video streams
from each other without using the SSRC values.
v=0
o=- 20518 0 IN IP4 198.51.100.1
s=
t=0 0
c=IN IP4 203.0.113.1
a=ice-ufrag:F7gI
a=ice-pwd:x9cml/YzichV2+XlhiMu8g
a=fingerprint:sha-1
42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7
a=group:BUNDLE m0 m1 m2 m3
m=audio 56600 RTP/SAVPF 0 96
a=mid:m0
a=rtpmap:0 PCMU/8000
a=rtpmap:96 opus/48000
a=ptime:20
a=sendrecv
a=rtcp-mux
a=candidate:0 1 UDP 2113667327 192.0.2.1 54400 typ host
a=candidate:1 2 UDP 2113667326 192.0.2.1 54401 typ host
a=candidate:0 1 UDP 694302207 198.51.100.1 55500 typ srflx raddr
192.0.2.1 rport 54400
a=candidate:1 2 UDP 169430220 198.51.100.1 55501 typ srflx raddr
192.0.2.1 rport 54401
a=candidate:0 1 UDP 73545215 203.0.113.1 56600 typ relay raddr
192.0.2.1 rport 54400
a=candidate:1 2 UDP 51989708 203.0.113.1 56601 typ relay raddr
192.0.2.1 rport 54401
m=video 0 RTP/SAVPF 97 98
a=mid:m1
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
Roach & Thomson Expires November 08, 2013 [Page 17]
Internet-Draft SDP Many Flows May 2013
a=rtpmap:98 VP8/90000
a=sendrecv
a=rtcp-mux
a=bundle-only
a=ssrc:11111 cname:45:5f:fe:cb:81:e9
m=video 0 RTP/SAVPF 97 98
a=mid:m2
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
a=rtpmap:98 VP8/90000
a=sendrecv
a=rtcp-mux
a=bundle-only
a=ssrc:22222 cname:45:5f:fe:cb:81:e9
m=video 0 RTP/SAVPF 97 98
a=mid:m3
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
a=rtpmap:98 VP8/90000
a=sendrecv
a=rtcp-mux
a=bundle-only
a=ssrc:333333 cname:45:5f:fe:cb:81:e9
7.4. Multiple Videos with Simulcast
This section shows an offer with with audio and two video each of
which can send it two resolutions as described in Section 6.3. Note
that the grouping places the lower bitrate streams first, even though
those appear first in the document. All the video is bundle-only.
v=0
o=- 20518 0 IN IP4 198.51.100.1
s=
t=0 0
c=IN IP4 203.0.113.1
a=ice-ufrag:F7gI
a=ice-pwd:x9cml/YzichV2+XlhiMu8g
a=fingerprint:sha-1
42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7
a=group:BUNDLE m0 m1 m2 m3 m4
a=group:SIMULCAST m2 m1
a=group:SIMULCAST m4 m3
Roach & Thomson Expires November 08, 2013 [Page 18]
Internet-Draft SDP Many Flows May 2013
m=audio 56600 RTP/SAVPF 0 96
a=mid:m0
a=rtpmap:0 PCMU/8000
a=rtpmap:96 opus/48000
a=ptime:20
a=sendrecv
a=rtcp-mux
a=candidate:0 1 UDP 2113667327 192.0.2.1 54400 typ host
a=candidate:1 2 UDP 2113667326 192.0.2.1 54401 typ host
a=candidate:0 1 UDP 694302207 198.51.100.1 55500 typ srflx raddr
192.0.2.1 rport 54400
a=candidate:1 2 UDP 169430220 198.51.100.1 55501 typ srflx raddr
192.0.2.1 rport 54401
a=candidate:0 1 UDP 73545215 203.0.113.1 56600 typ relay raddr
192.0.2.1 rport 54400
a=candidate:1 2 UDP 51989708 203.0.113.1 56601 typ relay raddr
192.0.2.1 rport 54401
m=video 0 RTP/SAVPF 98
b=AS:1500
a=mid:m1
a=rtpmap:98 VP8/90000
a=sendrecv
a=rtcp-mux
a=bundle-only
a=ssrc:11111 cname:45:5f:fe:cb:81:e9
a=framerate:30
m=video 0 RTP/SAVPF 100
b=AS:256
a=mid:m2
a=rtpmap:100 VP8/90000
a=sendrecv
a=rtcp-mux
a=bundle-only
a=ssrc:22222 cname:45:5f:fe:cb:81:e9
a=framerate:15
m=video 0 RTP/SAVPF 101
b=AS:1500
a=mid:m3
a=rtpmap:101 VP8/90000
a=sendrecv
a=rtcp-mux
a=bundle-only
a=ssrc:333333 cname:45:5f:fe:cb:81:e9
a=framerate:30
Roach & Thomson Expires November 08, 2013 [Page 19]
Internet-Draft SDP Many Flows May 2013
m=video 0 RTP/SAVPF 103
b=AS:256
a=mid:m4
a=rtpmap:103 VP8/90000
a=sendrecv
a=rtcp-mux
a=bundle-only
a=ssrc:44444 cname:45:5f:fe:cb:81:e9
a=framerate:15
7.5. Video with Simulcast and RTX
This section shows an SDP offer that has an audio and a single video
stream. The video stream that is simulcast at two resolutions and
has [RFC4588] style re-transmission flows.
v=0
o=- 20518 0 IN IP4 198.51.100.1
s=
t=0 0
c=IN IP4 203.0.113.1
a=ice-ufrag:F7gI
a=ice-pwd:x9cml/YzichV2+XlhiMu8g
a=fingerprint:sha-1
42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7
a=group:BUNDLE m0 m1 m2 m3 m4
a=group:SIMULCAST m2 m1
a=group:FID m1 m3
a=group:FID m2 m4
m=audio 56600 RTP/SAVPF 0 96
a=mid:m0
a=rtpmap:0 PCMU/8000
a=rtpmap:96 opus/48000
a=ptime:20
a=sendrecv
a=rtcp-mux
a=candidate:0 1 UDP 2113667327 192.0.2.1 54400 typ host
a=candidate:1 2 UDP 2113667326 192.0.2.1 54401 typ host
a=candidate:0 1 UDP 694302207 198.51.100.1 55500 typ srflx raddr
192.0.2.1 rport 54400
a=candidate:1 2 UDP 169430220 198.51.100.1 55501 typ srflx raddr
192.0.2.1 rport 54401
a=candidate:0 1 UDP 73545215 203.0.113.1 56600 typ relay raddr
192.0.2.1 rport 54400
Roach & Thomson Expires November 08, 2013 [Page 20]
Internet-Draft SDP Many Flows May 2013
a=candidate:1 2 UDP 51989708 203.0.113.1 56601 typ relay raddr
192.0.2.1 rport 54401
m=video 0 RTP/SAVPF 100 // This is the high res video
b=AS:1500
a=mid:m1
a=rtpmap:98 VP8/90000
a=sendrecv
a=rtcp-mux
a=bundle-only
a=framerate:30
m=video 0 RTP/SAVPF 101 // This is the low res video
b=AS:256
a=mid:m2
a=rtpmap:100 VP8/90000
a=sendonly
a=rtcp-mux
a=bundle-only
a=framerate:15
m=video 0 RTP/SAVPF 110 // This is the retransmission of high res
b=AS:1500
a=mid:m3
a=rtpmap:101 rtx/90000
a=sendrecv
a=rtcp-mux
a=bundle-only
a=framerate:30
a=rtcp-fb:101 nack
a=fmtp:101 apt=100;rtx-time=3000
m=video 0 RTP/SAVPF 111 // This is retransmission of low res
b=AS:256
a=mid:m4
a=rtpmap:103 rtx/90000
a=sendonly
a=rtcp-mux
a=bundle-only
a=framerate:15
a=rtcp-fb:111 nack
a=fmtp:11 apt=101;rtx-time=3000
8. Security Considerations
TBD
Roach & Thomson Expires November 08, 2013 [Page 21]
Internet-Draft SDP Many Flows May 2013
9. IANA Considerations
TBD: registration of SIMULCAST group
10. Acknowledgements
Thanks to Cullen Jennings for his assistance in generating the SDP
examples in this document.
Some of the material in this document was taken from
[I-D.jennings-rtcweb-plan].
11. References
11.1. Normative References
[I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings,
"Multiplexing Negotiation Using Session Description
Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-
bundle-negotiation-03 (work in progress), February 2013.
[I-D.jennings-mmusic-media-req]
Jennings, C., Uberti, J., and E. Rescorla, "Requirements
from various WG for MMUSIC", draft-jennings-mmusic-media-
req-00 (work in progress), February 2013.
[I-D.nandakumar-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-nandakumar-mmusic-sdp-mux-
attributes-02 (work in progress), April 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
11.2. Informative References
[I-D.ietf-rtcweb-rtp-usage]
Roach & Thomson Expires November 08, 2013 [Page 22]
Internet-Draft SDP Many Flows May 2013
Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
Communication (WebRTC): Media Transport and Use of RTP",
draft-ietf-rtcweb-rtp-usage-06 (work in progress),
February 2013.
[I-D.jennings-rtcweb-plan]
Jennings, C., "Proposed Plan for Usage of SDP and RTP",
draft-jennings-rtcweb-plan-01 (work in progress), February
2013.
[I-D.roach-rtcweb-glareless-add]
Roach, A. B., "An Approach for Adding RTCWEB Media Streams
without Glare ", May 2013.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[webrtc-api]
Bergkvist, Burnett, Jennings, Narayanan, , "WebRTC 1.0:
Real-time Communication Between Browsers", October 2011.
Available at http://dev.w3.org/2011/webrtc/editor/
webrtc.html
Authors' Addresses
Adam Roach
Mozilla
Dallas, TX
US
Phone: +1 650 903 0800 x863
Email: adam@nostrum.com
Roach & Thomson Expires November 08, 2013 [Page 23]
Internet-Draft SDP Many Flows May 2013
Martin Thomson
Microsoft
3210 Porter Drive
Palo Alto, CA 94304
US
Phone: +1 650 353 1925
Email: martin.thomson@skype.net
Roach & Thomson Expires November 08, 2013 [Page 24]
