One document matched: draft-roach-rtcweb-plan-a-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY RFC3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY RFC4588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4588.xml">
<!ENTITY RFC5117 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5117.xml">
<!ENTITY RFC5245 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY RFC5888 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5888.xml">
<!ENTITY I-D.ietf-mmusic-sdp-bundle-negotiation SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-sdp-bundle-negotiation.xml">
<!ENTITY I-D.jennings-mmusic-media-req SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jennings-mmusic-media-req.xml">
<!ENTITY I-D.jennings-rtcweb-plan SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jennings-rtcweb-plan.xml">
<!ENTITY I-D.ietf-rtcweb-rtp-usage SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-rtp-usage.xml">
<!ENTITY I-D.nandakumar-mmusic-sdp-mux-attributes SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.nandakumar-mmusic-sdp-mux-attributes">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace="no" ?>
<?rfc rfcedstyle="no" ?>
<?rfc tocdepth="4"?>
<rfc category="info" docName="draft-roach-rtcweb-plan-a-00" ipr="trust200902">
<front>
<title abbrev="SDP Many Flows">Using SDP with Large Numbers of Media
Flows</title>
<author fullname="Adam Roach" initials="A. B." surname="Roach">
<organization>Mozilla</organization>
<address>
<postal>
<street></street>
<city>Dallas</city>
<region>TX</region>
<code></code>
<country>US</country>
</postal>
<phone>+1 650 903 0800 x863</phone>
<email>adam@nostrum.com</email>
</address>
</author>
<author initials="M" surname="Thomson" fullname="Martin Thomson">
<organization>Microsoft</organization>
<address>
<postal>
<street>3210 Porter Drive</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>
<phone>+1 650 353 1925</phone>
<email>martin.thomson@skype.net</email>
</address>
</author>
<date day="7" month="May" year="2013" />
<area>RAI</area>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="sec.introduction" title="Introduction">
<t>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.</t>
<t>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:</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
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=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
]]></artwork>
</figure>
<t>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 <xref target="RFC5245"></xref> 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.</t>
<t>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 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.</t>
<t>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.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in <xref target="RFC2119"></xref>.</t>
<t>This draft uses the API and terminology described in <xref
target="webrtc-api"></xref>.</t>
<t>5-tuple: A collection of the following values: source IP address,
source transport port, destination IP address, destination transport
port and transport protocol.</t>
<t>Transport-Flow: An transport 5 Tuple representing the UDP source and
destination IP address and port over which RTP is flowing.</t>
<t>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.</t>
<!-- <t>PC-Stream: Represents stream of data of audio and/or video added to a
Peer Connection by local or remote media source(s). A PC-Stream is made
up of zero or more PC-Tracks.</t> -->
<t>m-line: An <xref target="RFC4566">SDP</xref> media description
identifier that starts with an "m=" field and conveys the following
values: media type, transport port, transport protocol and media format
descriptions.</t>
<t>Offer: An <xref target="RFC3264"></xref> 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.</t>
<t>Answer: An <xref target="RFC3264"></xref> 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.</t>
<t hangText="Note">This draft avoids using terms that implementors do
not have a clear idea of exactly what they are - for example RTP
Session.</t>
</section>
<section title="Syntax Conventions">
<t>
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:
</t>
<t><list style="symbols">
<t> 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.</t>
<t> 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.</t>
<t> 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).</t>
<t> 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.</t>
</list></t>
</section>
<section title="Requirements">
<t>This document is intended to address the following requirements,
based on those from <xref
target="I-D.jennings-mmusic-media-req"></xref>.</t>
<t><list style="numbers">
<t>Support many media flows but minimize the number of transport
flows. <list style="hanging">
<t>This requirement is partly satisfied by BUNDLE <xref
target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref>;
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 <xref target="sec.introduction"></xref>.
The mechanisms in Section <xref target="sec.bundle-only"></xref>
of this document address those issues.</t>
</list></t>
<t></t>
<t>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. <list style="hanging">
<t>The interaction of this mechanism with non-WEBRTC devices is
described in <xref target="sec.legacy"></xref>.</t>
</list></t>
<t></t>
<t>Provide a mechanism for harmonizing flow parameters for different
m-lines when they are multiplexed over the same transport. <list
style="hanging">
<t><xref target="I-D.nandakumar-mmusic-sdp-mux-attributes"/>
documents the required procedures.</t>
</list></t>
<t></t>
<!--
<t>
Two implementations that support muxing should be able to and or
remove one way video flows with either a minimal chance of glare
or with simple glare resolution rules.
</t>-->
<t>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. <list style="hanging">
<t>This requirement is also already satisfied by existing SDP
mechanisms; we simply need to preserve them.</t>
</list></t>
<t></t>
<t>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. <list
style="hanging">
<t><xref target="sec.flow-demux"></xref> of this document
satisfies the multiplexing requirement and the normal SDP
mechanisms are used for parameters.</t>
</list></t>
<t></t>
<t>Be able to identify the PC-Tracks with an identifier that is
stable over the duration of the session. <list style="hanging">
<t><xref target="sec.flow-demux"></xref> of this document
explains track identification.</t>
</list></t>
</list></t>
<!-- I think we should remove this point because glare less add is not a req in media-req
<t>
Note that this document does not attempt to satisfy
requirement number #2 (glare less add) from <xref
target="I-D.jennings-mmusic-media-req"/>.
</t>
-->
<t>Note that this document does not attempt to address the issue of
adding a stream with little or no chance of glare. See <xref
target="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.</t>
</section>
<section anchor="sec.overview" title="Overview">
<t>This section provides an overview of the approach specified in this
document.</t>
<t><list style="symbols">
<t>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.</t>
<t>BUNDLE <xref
target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref> is used to
multiplex multiple m-lines (and their corresponding media) onto the
same set of transport flows.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</section>
<section anchor="sec.detailed-description" title="Detailed Description">
<section anchor="sec.bundle-only" title="Bundle-Only M-Lines">
<t>As discussed in <xref target="sec.introduction"></xref>, 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.</t>
<t>In order to offer such an m-line, the offerer does two things:</t>
<t><list style="symbols">
<t>Sets the port in the m-line to 0. This indicates to old
endpoints that the m-line is not to be negotiated.</t>
<t>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.</t>
</list></t>
<t>An example offer that uses this feature looks like this:</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
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
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
]]></artwork>
</figure>
<t>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.)</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
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
a=rtpmap:100 VP8/90000
a=sendrecv
]]></artwork>
</figure>
<t>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
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref>. For
instance:</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
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
]]></artwork>
</figure>
<t>Endpoints MUST NOT accept bundle-only m-lines if they are not part of an
accepted bundle group.</t>
</section>
<section anchor="sec.flow-demux" title="Flow Demultiplexing">
<t>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.</t>
<t>Offerers conformant to this specification MUST do one of the
following:</t>
<t><list style="symbols">
<t>Use non-overlapping PT values for each m-line in any given
bundle group.</t>
<t>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.]</t>
</list></t>
<t>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.</t>
<t>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:</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>Otherwise, discard the packet.</t>
</list></t>
<t>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.</t>
</section>
<section anchor="sec.simulcast" title="Indicating Simulcast Groups">
<t>
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.
</t>
<t>
This document proposes that simulcast be done by defining a
new <xref target="RFC5888">SDP group</xref> called
SIMULCAST. Any m-lines that are in the same SIMULCAST group
are alternative encodings of the same media capture.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Providing an order to SIMULCAST groupings allows an intermediary (such
as a <xref target="RFC5117">Media Translator</xref>) 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.
</t>
</section>
<section anchor="sec.identifying-flows" title="Identifying Flows">
<t>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 <xref target="RFC3550"></xref>. 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.</t>
</section>
<section anchor="sec.legacy" title="Compatibility with Non-RTCWEB uses">
<t>Due to the fact that this approach re-uses existing SDP constructs
for indicating parameters in a media section, it remains compatible
with non-RTCWEB clients. Of particular note is the handling of
"bundle-only" media sections, described in <xref
target="sec.bundle-only"></xref>. 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.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section anchor="sec.examples" title="Examples">
<t>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.</t>
<t> 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. </t>
<t> The examples do not include all the parts of SDP that are used in
RTCWeb (See <xref target="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. </t>
<section title="Simple example with one audio and one video">
<t>
The following SDP shows an offer that offers one audio stream and one
video steam with both a STUN and TURN address. </t>
<figure><artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
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: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
]]></artwork></figure>
<t>The following shows and answer to the above offer from a device that does not support bundle or rtcp-mux. </t>
<figure><artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
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
]]></artwork></figure>
<t>The following shows and answer to the above offer from a device that does support bundle. </t>
<figure><artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
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=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
]]></artwork></figure>
</section>
<section title="Multiple Videos">
<t> Simple example showing an offer with one audio stream and two video streams. </t>
<figure><artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
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
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
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
]]></artwork></figure>
</section>
<section title="Many Videos">
<t> 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
<xref target="sec.bundle-only"/>. 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. </t>
<figure><artwork><![CDATA[
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
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
]]></artwork></figure>
</section>
<section title="Multiple Videos with Simulcast">
<t>This section shows an offer with with audio and two video each of
which can send it two resolutions as described in <xref
target="sec.simulcast"/>. Note that the grouping places the lower
bitrate streams first, even though those appear first in the document.
All the video is bundle-only.</t>
<figure><artwork><![CDATA[
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
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
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
]]></artwork></figure>
</section>
<section title="Video with Simulcast and RTX">
<t> 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
<xref target="RFC4588"/> style re-transmission flows. </t>
<figure><artwork><![CDATA[
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
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
]]></artwork></figure>
</section>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>TBD: registration of SIMULCAST group</t>
</section>
<section title="Acknowledgements">
<t>
Thanks to Cullen Jennings for his assistance in generating the
SDP examples in this document.
</t>
<t>Some of the material in this document was taken from <xref
target="I-D.jennings-rtcweb-plan"></xref>.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3264;
&RFC4566;
&RFC5888;
&I-D.ietf-mmusic-sdp-bundle-negotiation;
&I-D.jennings-mmusic-media-req;
&I-D.nandakumar-mmusic-sdp-mux-attributes;
</references>
<references title="Informative References">
&RFC3550;
&RFC5245;
&RFC5117;
&RFC4588;
&I-D.jennings-rtcweb-plan;
&I-D.ietf-rtcweb-rtp-usage;
<reference anchor="I-D.roach-rtcweb-glareless-add">
<front>
<title abbrev="RTCWEB Glareless Adds">
An Approach for Adding RTCWEB Media Streams without Glare
</title>
<author fullname="Adam Roach" initials="A. B." surname="Roach"/>
<date day="7" month="May" year="2013" />
</front>
</reference>
<reference anchor="webrtc-api">
<front>
<title>WebRTC 1.0: Real-time Communication Between Browsers</title>
<author fullname="W3C editors"
surname="Bergkvist, Burnett, Jennings, Narayanan">
<organization>W3C</organization>
</author>
<date day="4" month="October" year="2011" />
</front>
<annotation>Available at
http://dev.w3.org/2011/webrtc/editor/webrtc.html</annotation>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:05:00 |