uberti-rtcweb-plan-00.txt

Internet DRAFT - draft-uberti-rtcweb-plan

draft-uberti-rtcweb-plan

Last Version:	draft-uberti-rtcweb-plan-00.txt	Tracker Entry
Date:	`04-May-2013`
Disposition:	expired

Network Working Group J. Uberti
Internet-Draft Google
Intended status: Standards Track May 03, 2013
Expires: November 04, 2013

Plan B: a proposal for signaling multiple media sources in WebRTC.
draft-uberti-rtcweb-plan-00

Abstract

This document explains how multiple media sources can be signaled in
WebRTC using SDP, in a fashion that avoids many common problems and
provides a simple control surface to the receiver.

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 04, 2013.

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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

Uberti Expires November 04, 2013 [Page 1]

Internet-Draft WebRTC Plan B May 2013

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Support for a large number of arbitrary sources . . . . . 4
2.2. Support for fine-grained receiver control of sources . . 4
2.3. Glareless addition and removal of sources . . . . . . . . 4
2.4. Interworking with legacy devices . . . . . . . . . . . . 5
2.5. Avoidance of unnecessary port allocation . . . . . . . . 5
2.6. Simple binding of MediaStreamTrack to SDP . . . . . . . . 5
2.7. Support for RTX, FEC, simulcast, layered coding . . . . . 5
2.8. Works with or without BUNDLE . . . . . . . . . . . . . . 5
3. Detailed Design . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. One m= line per [media-type, content] tuple . . . . . . . 6
3.2. Transmit sources identified by SSRC in signaling . . . . 6
3.3. Receive sources requested using remote-ssrc . . . . . . . 7
3.4. RTX, FEC, Simulcast . . . . . . . . . . . . . . . . . . . 7
4. Signaling Behavior . . . . . . . . . . . . . . . . . . . . . 8
4.1. Negotiation of new or legacy behavior . . . . . . . . . . 9
4.2. New signaling flow . . . . . . . . . . . . . . . . . . . 9
4.3. Legacy signaling flow . . . . . . . . . . . . . . . . . . 9
4.4. Interactions with BUNDLE . . . . . . . . . . . . . . . . 10
5. Full Example . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. New endpoint . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. Offer 1 (A->B): (A indicates streams to B) . . . . . 10
5.1.2. Answer 1 (B->A): (B requests streams from A) . . . . 11
5.1.3. Offer 2 (B->A): (B indicates streams to A) . . . . . 11
5.1.4. Answer 2 (A->B): (A requests streams from B) . . . . 12
5.2. Legacy endpoint . . . . . . . . . . . . . . . . . . . . . 13
5.2.1. Offer 1 (A->B): (A indicates streams to B) . . . . . 13
5.2.2. Answer 1 (B->A): (A accepts B's offer) . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15

1. Introduction

"Plan B" describes a simple, flexible approach for the negotiation
and exchange of multiple media sources (AKA MediaStreamTracks, or
MSTs) between two WebRTC endpoints. Each media source can be
individually accepted or rejected by the recipient, and preferences
on these track requests (e.g. the relative priority of the tracks)
can also be provided.

Uberti Expires November 04, 2013 [Page 2]

Internet-Draft WebRTC Plan B May 2013

One of the core problems with existing approaches that map media
sources to individual m= lines, is that m= lines, by their very
nature, specify information about how media should be transported.
This means that if N m= lines are created, N media ports (and their
corresponding STUN/TURN candidates) need to be allocated. This
causes problems when even relatively small numbers of media sources
are used, as each source can result in multiple m= lines when
techniques like simulcast or RTX are used.

Plan B takes a different approach, and creates a hierarchy within
SDP; a m= line defines an "envelope", specifying codec and transport
parameters, and [RFC5576] a=ssrc lines are used to describe
individual media sources within that envelope. In this manner, Plan
B disconnects media streams from transport, and solves the following
problems:

o Supports large numbers (>> 100) of sources

o Glareless add/removal of sources

o No need to allocate ports for each source

o Simple binding of MediaStreamTrack to SDP

o Simple use of RTX and FEC streams within a single RTP session

o Impossible to get "out-of-sync" (e.g. getting RTX or FEC flow
without its corresponding primary flow)

o Does not require BUNDLE (although BUNDLE can still help)

Plan B mostly uses existing IETF standards, introducing a single new
draft [I-D.lennox-mmusic-sdp-source-selection] to specify how
individual media sources can be accepted/rejected at the SSRC level
via SDP. An extensive review of SDP attributes was performed, in
order to determine which SDP attributes that exist at m= line level
would need to also exist at "source" level; these attributes are
(aside from some trivial exceptions, such as a=label) covered in the
aforementioned draft.

Note that at the wire level, RTP is handled identically to Plan A
(which specifies separate m= line for each media source), after a
successful BUNDLE, in that MSTs are all sent in a single RTP session,
and demuxed by SSRC. Therefore, Plan B could be converted to Plan A
by a signaling-only gateway (although it would lose the advantages
mentioned above).

Uberti Expires November 04, 2013 [Page 3]

Internet-Draft WebRTC Plan B May 2013

2. Design Goals

Plan B attempts to provide a comprehensive mechanism for handling
large numbers of simultaneous media sources, as might commonly be the
case in a video conference or TV guide application. It attempts to
address the following concerns:

2.1. Support for a large number of arbitrary sources

In cases such as a video conference, there may be dozens or hundreds
of participants, each with their own audio and video sources. A
participant may even want to browse conferences before joining one,
meaning that there may be cases where there are many such conferences
displayed simultaneously.

In these conferences, participants may have varying capabilities and
therefore video resolutions. In addition, depending on conference
policy, user preference, and the desired UI, participants may be
displayed in various layouts, including:

o A single large main speaker with thumbnails for other participants

o Multiple medium-sized main speakers, with or without thumbnails

o Large slides + medium speaker, without thumbnails

These layouts can change dynamically, depending on the conference
content and the preferences of the receiver. As such, there are not
well-defined 'roles', that could be used to group sources into
specific 'large' or 'thumbnail' categories. As such, the requirement
Plan B attempts to satisfy is support for sending and receiving up to
hundreds of simultaneous, hetereogeneous sources.

2.2. Support for fine-grained receiver control of sources

Since there may be large numbers of sources, which can be displayed
in different layouts, it is imperative that the receiver can easily
control which sources are received, and what resolution or quality is
desired, for both audio and video. The receiver should also be able
to prioritize the source it requests, so that if system limits or
bandwidth force a reduction in quality, the sources chosen by the
receiver as important will receive the best quality. These details
must be exposed to the application via the API.

2.3. Glareless addition and removal of sources

Sources may come and go frequently, as is the case in a conference
where various participants are presenting, or an interaction between

Uberti Expires November 04, 2013 [Page 4]

Internet-Draft WebRTC Plan B May 2013

multiple distributed conference servers. Because of this, it is
desirable that sources can be added to SDP in a way that avoids
signaling glare. The m= line approach suffers from this problem, as
each m= line is indicated by a numeric index, and either side may add
a new m= line as the same numeric index.

2.4. Interworking with legacy devices

When interacting with a legacy application that only knows how to
deal with a small number of sources, it must be possible to degrade
gracefully to a usable basic experience, where at least a single
audio and video source are active on each side, using a typical offer
/answer exchange.

2.5. Avoidance of unnecessary port allocation

When there are dozens or hundreds of streams, it is desirable to
avoid creating dozens or hundreds of transports, as empirical data
shows a clear inverse relationship between number of transports (NAT
bindings) and call success rate. While BUNDLE helps avoid creating
large numbers of transports, it is also desirable to avoid creating
large numbers of ports during call setup, since ICE pacing alone can
lead to significant delays, and BUNDLE does not attempt to address
this.

2.6. Simple binding of MediaStreamTrack to SDP

In WebRTC, each media source is identified by a MediaStreamTrack
object. In order to ensure that the MSTs created by the sender show
up at the receiver, each MST's id attribute needs to be reflected in
SDP.

2.7. Support for RTX, FEC, simulcast, layered coding

For robust applications, techniques like RTX and FEC are used to
protect media, and simulcast/layered coding can be used to provide
support to hetereogeneous receivers. It needs to be possible to
support these techniques, allow the receipient to optionally use or
not use them on a source-by-source basis, and for simulcast/layered
scenarios, control which simulcast streams or layers are received.

2.8. Works with or without BUNDLE

Uberti Expires November 04, 2013 [Page 5]

Internet-Draft WebRTC Plan B May 2013

While BUNDLE provides a major win in allowing the multiplexing of
multiple m= lines over a single transport, it does not solve all
transport-related problems. Moreover, like any new technology, it
will take time to identify all the edge cases and deployment issues.
Therefore not having a hard dependency on BUNDLE, while still keeping
the ability to benefit from BUNDLE, is considered advantageous.

3. Detailed Design

3.1. One m= line per [media-type, content] tuple

Regardless of how many sources are offered or used, only one m= line,
by default, is used for each media type (e.g. audio, video, or
application). If the application wishes, it can request that a given
media source be placed onto a separate m= line, by setting a new
.content property on the desired MediaStreamTrack; the values for the
.content property are those defined for the a=content attribute in
[RFC4796]. This helps with certain legacy interop cases, for
example, an endpoint who expected a screenshare video source to be
signaled on its own m=video line. It is expected that the number of
scenarios that require this property setting are fairly limited,
primarily to cases like this one. In these situations, the number of
m= lines still remains manageable.

By only using a m= line for each media type, as opposed to each media
source, this approach reduces the number of transports required to 2
even in complex audio/video cases. Note that in the common case of a
call with a single audio and video source, the result is identical to
the m= line per source approach, and so there are no issues with
legacy devices in this case. In more complex cases, the application
can select which of the sources for each m= line should be sent when
interacting with a legacy device.

3.2. Transmit sources identified by SSRC in signaling

Media sources are identified in signaling by SSRC, via [RFC5576]
a=ssrc attributes. Each provider of MSTs (i.e. endpoint) indicates
the MSTs they wish to send in their signaling message, and describes
them using one of more SSRCs; when techniques like simulcast or RTX
are used, a media source can span multiple SSRCs. Correlation of
MediaStreamTracks with SSRCs is performed by the MSID attribute, a
per-ssrc attribute defined in [I-D.alvestrand-mmusic-msid] that
contains the MST's "id" property, and thereby indicates which MST
corresponds to which SSRC. In the example below, the SDP advertises
3 separate audio sources, each identified by a single SSRC.

m=audio 49170 RTP/AVP 101 // main audio
a=ssrc:1 msid:left-mic // declare 3 outgoing audio sources

Uberti Expires November 04, 2013 [Page 6]

Internet-Draft WebRTC Plan B May 2013

a=ssrc:2 msid:center-mic
a=ssrc:3 msid:right-mic

Note that because of the signaling of SSRCs, SSRC collision is not a
major issue. Each endpoint can ensure that the SSRCs it chooses
don't collide, because it already knows about the SSRCs it has
already used, as well as the ones the remote side has signaled. In
the few cases where it can still occur - perhaps because of
simultaneous signaling by both endpoints, upon recognizing the
collision, an endpoint can update its send sources to not collide.
If a collision occurs on an in-progress media flow, or if an endpoint
needs to change SSRCs, for whatever reason, the [RFC5576] a=previous-
ssrc attribute can be used to change an existing SSRC to a new value,
while retaining continuity of media playout.

3.3. Receive sources requested using remote-ssrc

When the offerer advertises its streams, the remote side can select
which of them it wants to receive in its answer message. This is
performed via [I-D.lennox-mmusic-sdp-source-selection], which
introduces the concept of an a=remote-ssrc attribute. Through use of
this attribute, the remote side chooses which of the offered sources
should be received, by turning each one on or off, and optionally
specifying what resolution, framerate and priority the recipient
suggests for a particular source. This can also be used to select
simulcast streams, or enabling/disabling of techniques like RTX or
FEC. In the example below, the SDP sent by the receiver asks for
just one of the offered streams.

m=audio 39170 RTP/AVP 101 // main audio
a=remote-ssrc:1 recv:on // just turn on the center mic

The exact rules for how this logic works are specified in the
aforementioned draft.

3.4. RTX, FEC, Simulcast

In cases where a media source needs to correspond to more than one
RTP flow, e.g. RTX, FEC, or simulcast, the [RFC5576] a=ssrc-group
concept is used to create a grouping of SSRCs for a single MST. Each
SSRC is declared using a=ssrc attributes, the same MSID is shared
between the SSRCs, and the a=ssrc-group attribute defines the
behavior of the grouped SSRCs.

These groupings are used to perform demux of the incoming RTP streams
and associate them (by SSRC) with their primary flows; this is the

Uberti Expires November 04, 2013 [Page 7]

Internet-Draft WebRTC Plan B May 2013

only way that a RTX or FEC stream can be correlated with its primary
flow, when many streams are multiplexed in a single RTP session.
This multiplexing of RTX and FEC in a single RTP session is already
well-defined; RTX SSRC-multiplexing behavior is defined in [RFC4588],
and FEC SSRC-multiplexing behavior is defined in [RFC5956].

For multi-resolution simulcast, we can create a similar ssrc-group,
and adapt the imageattr attribute defined in [RFC6236] for the a=ssrc
line attribute to indicate the send resolution for a given simulcast
stream. (This will be added to the source-selection draft). In the
example below, the SDP advertises a simulcast of a camera source at
two different resolutions, as well as a screenshare source that
supports RTX; a=ssrc-group is used to correlate the different SSRCs
as part of a single media source.

m=video 62537 RTP/SAVPF 96 // main video
a=ssrc:5 msid:center-cam // one source is simulcasting at two resolutions
a=ssrc:5 imageattr:* [1280, 720]
a=ssrc:51 msid:center-cam // different SSRC, same MSID for simulcasts
a=ssrc:51 imageattr:* [640, 360]
a=ssrc-group:SIMULCAST 5 51
a=ssrc:8 msid:slides
a=ssrc:9 msid:slides // RTX SSRC
a=ssrc-group:FID 8 9

As specified in [I-D.lennox-mmusic-sdp-source-selection], the usage
of RTX and FEC can be enabled or disabled on a per-media-source
basis, as the recipient can turn off these secondary flows in its
SDP. However, it is not possible to get into undefined situations,
such as receiving the FEC flow without the primary flow.

Note that at the wire level, the RTP flows will be the same as
BUNDLEd session-multiplexed flows - the flows are all multiplexed in
a single RTP session, which means that SSRCs must be used to
correlate a RTX or FEC flow with their primary flow. Using payload
types for this correlation, while possible in certain simple cases,
is not suitable for the general case of many media sources, since
individual PTs would have to be declared for every [codec, media
source, primary/RTX/FEC] tuple, which quickly becomes unworkable.

4. Signaling Behavior

Uberti Expires November 04, 2013 [Page 8]

Internet-Draft WebRTC Plan B May 2013

4.1. Negotiation of new or legacy behavior

In order to know whether a given application supports Plan B, an
attribute in the offer is needed. There are various options that
could be used for this:

o a=ssrc isn't enough, since you might not have any send streams,
and therefore no a=ssrc attributes.

o a=max-*-ssrc could work, but has additional semantics

o a=msid-semantic indicates that you understand MSIDs.

Because understanding MSID is a prerequisite to using plan B, the
third option (presence of a=msid-semantic) is recommended.

4.2. New signaling flow

When both sides support Plan B, to properly allow both sides to
indicate which MSTs they have, and allow the remote side to select
the desired MSTs to receive, a 3-way handshake is needed (this is
just math; the offer can't select the answerer's MSTs until they know
about them). The expected flow for this would be for the caller to
send an offer with its sources, then the callee would send back an
answer with the sources it wants the caller to send, followed
immediately by an offer with the sources that the callee has
available to send. Finally, the answerer will reply back with the
sources that it wants to request from the callee. The entire
sequence can be done in 1.5 RTT.

Typically a race condition exists between the receipt of the callee
answer and the receipt of the callee media. However, this is avoided
with Plan B, with its 3-way handshake. In addition, since the
sources are known ahead of time by the recipient of said sources, it
is prepared to demux them by SSRC without any signaling/media race.

4.3. Legacy signaling flow

In the legacy case, Plan B degrades gracefully back to a single
offer-answer sequence. Since there's no brokering of which sources
should be sent, the "new" endpoint picks a default media source for
each m= line, and upon receiving an answer indicating lack of support
for Plan B, it sends just the default sources to the legacy endpoint.
When receiving media from the legacy endpoint, the new endpoint
creates a "default" MediaStream (containing a single
MediaStreamTrack) for each m= line, just as when talking to any other
legacy endpoint, as specified in the MSID draft.

Uberti Expires November 04, 2013 [Page 9]

Internet-Draft WebRTC Plan B May 2013

Typically this will result in the negotiation of a single audio and
single video MediaStreamTrack. However, if the .content property was
used above, additional audio or video MediaStreamTracks could be
specifically negotiated for the purpose of communicating with legacy
equipment (e.g. an additional screenshare video source).

4.4. Interactions with BUNDLE

Since Plan B already muxes streams of the same media type onto a
single m= line, BUNDLE is not as critical to its success as other
approaches. Regardless, BUNDLE can be used to get down to just a
single transport, by multiplexing the various media types together,
and Plan B works well with BUNDLE. Since all streams are pre-
identified by their SSRC attributes, their RTP flows can be demuxed
easily even when grouped on the same 5-tuple.

5. Full Example

5.1. New endpoint

The example below shows two new endpoints, A and B, establishing a
Plan B call with audio, video, screensharing, simulcast, and RTX; B
decides to select a subset of the sources that A advertises.

5.1.1. Offer 1 (A->B): (A indicates streams to B)

a=msid-semantics:WMS // I understand SSRCs and MSTs

m=audio 49170 RTP/AVP 101 // main audio
a=ssrc:1 msid:left-mic // declare 3 outgoing audio sources, each with unique MSID
a=ssrc:2 msid:center-mic
a=ssrc:3 msid:right-mic
[Candidates]

m=video 62537 RTP/SAVPF 96 // main video
a=ssrc:4 msid:left-cam // declare 3 outgoing video sources
a=ssrc:5 msid:center-cam // one source is simulcasting at two resolutions, same codec
a=ssrc:5 imageattr:* [1280, 720]
a=ssrc:51 msid:center-cam // different SSRC, same MSID for simulcasts
a=ssrc:51 imageattr:* [640, 360]
a=ssrc:6 msid:right-cam
a=ssrc-group:SIMULCAST 5 51
[Candidates]

m=video 62538 RTP/SAVPF 96 // presentation
a=content:slides // [media, content] tuples must be unique in m= lines
a=ssrc:8 msid:slides // app decision to do this; could have been put in the m=video line above
a=ssrc:9 msid:slides // RTX SSRC

Uberti Expires November 04, 2013 [Page 10]

Internet-Draft WebRTC Plan B May 2013

a=ssrc-group:FID 8 9 // declaration that SSRC 9 is a repair flow for 8
[Candidates]

5.1.2. Answer 1 (B->A): (B requests streams from A)

a=msid-semantics:WMS // I understand SSRCs and MSTs

m=audio 39170 RTP/AVP 101 // main audio
a=remote-ssrc:1 recv:on // just turn on the center mic
[Candidates]

m=video 52537 RTP/SAVPF 96 // main video
a=remote-ssrc:5 recv:off // explicitly turn off the 720p feed
a=remote-ssrc:51 recv:on // explicitly turn on the 360p feed
a=remote-ssrc:51 priority:1 // lower priority than slides (in this application)
[Candidates]

m=video 52538 RTP/SAVPF 96 // presentation
a=content:slides
a=remote-ssrc:8 recv:on // turn on the slides feed with higher priority
// FID is sent implicitly, unless explicitly rejected
a=remote-ssrc:8 priority:2 // (sender uses priority when making BW decisions)
[Candidates]

5.1.3. Offer 2 (B->A): (B indicates streams to A)

Uberti Expires November 04, 2013 [Page 11]

Internet-Draft WebRTC Plan B May 2013

a=msid-semantics:WMS // I understand SSRCs and MSTs

m=audio 39170 RTP/AVP 101 // main audio
a=ssrc:101 msid:center-mic
a=remote-ssrc:1 recv:on // just turn on the center mic
[Candidates]

m=video 52537 RTP/SAVPF 96 // main video
a=ssrc:105 msid:center-cam
a=remote-ssrc:5 recv:off // explicitly turn off the 720p feed
a=remote-ssrc:51 recv:on // explicitly turn on the 360p feed
a=remote-ssrc:51 priority:1 // lower priority than slides (in this application)
[Candidates]

m=video 52538 RTP/SAVPF 96 // presentation
a=content:slides
a=remote-ssrc:8 recv:on // turn on the slides feed with higher priority
// FID is sent implicitly (unless explicitly rejected)
a=remote-ssrc:8 priority:2 // (sender uses priority when making BW decisions)
[Candidates]

5.1.4. Answer 2 (A->B): (A requests streams from B)

a=msid-semantics:WMS // I understand SSRCs and MSTs

m=audio 49170 RTP/AVP 101 // main audio
a=ssrc:1 msid:left-mic // declare 3 outgoing audio sources, each with unique MSID
a=ssrc:2 msid:center-mic
a=ssrc:3 msid:right-mic
a=remote-ssrc:101 on
[Candidates]

Uberti Expires November 04, 2013 [Page 12]

Internet-Draft WebRTC Plan B May 2013

a=ssrc-group:FID 8 9 // declaration that SSRC 9 is a repair flow for 8
[Candidates]

5.2. Legacy endpoint

The example below shows a new endpoint, A, and a legacy endpoint, B,
establishing a Plan B call with audio, video, and screensharing.
Although A supports multiple media sources for audio and video, B
receives only A's default streams. However, since screensharing was
done as its own m= line, screensharing continues to work with the
legacy endpoint.

5.2.1. Offer 1 (A->B): (A indicates streams to B)

a=msid-semantics:WMS // I understand SSRCs and MSTs

m=audio 49170 RTP/AVP 101 // main audio
a=ssrc:1 msid:left-mic // declare 3 outgoing audio sources, each
// with unique MSID
a=ssrc:2 msid:center-mic
a=ssrc:3 msid:right-mic
[Candidates]

m=video 62537 RTP/SAVPF 96 // main video
a=ssrc:4 msid:left-cam // declare 3 outgoing video sources
a=ssrc:5 msid:center-cam // one source is simulcasting at two
// resolutions, same codec
a=ssrc:5 imageattr:* [1280, 720]
a=ssrc:51 msid:center-cam // different SSRC, same MSID for simulcasts
a=ssrc:51 imageattr:* [640, 360]
a=ssrc:6 msid:right-cam
a=ssrc-group:SIMULCAST 5 51
[Candidates]

m=video 62538 RTP/SAVPF 96 // presentation
a=content:slides // [media, content] tuples must be unique
// in m= lines
a=ssrc:8 msid:slides // app decision to do this; could have been
// put in the m=video line above
a=ssrc:9 msid:slides // RTX SSRC
a=ssrc-group:FID 8 9 // declaration that SSRC 9 is a repair
// flow for 8
[Candidates]

5.2.2. Answer 1 (B->A): (A accepts B's offer)

Uberti Expires November 04, 2013 [Page 13]

Internet-Draft WebRTC Plan B May 2013

// Since endpoint doesn't understand a=ssrc or MSTs, A must decide
// on a single media source to send for each m=line, e.g. center-mic,
// center-cam (360p), slides

m=audio 39170 RTP/AVP 101 // main audio
[Candidates]

m=video 52537 RTP/SAVPF 96 // main video
[Candidates]

m=video 52538 RTP/SAVPF 96 // presentation
a=content:slides
[Candidates]

6. Security Considerations

None.

7. IANA Considerations

None.

8. Acknowledgements

Harald Alvestrand provided review and several suggestions on this
document.

9. References

9.1. Normative References

[I-D.alvestrand-mmusic-msid]
Alvestrand, H., "Cross Session Stream Identification in
the Session Description Protocol", draft-alvestrand-
mmusic-msid-01 (work in progress), October 2012.

[I-D.lennox-mmusic-sdp-source-selection]
Lennox, J. and H. Schulzrinne, "Mechanisms for Media
Source Selection in the Session Description Protocol
(SDP)", draft-lennox-mmusic-sdp-source-selection-05 (work
in progress), October 2012.

[RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description
Protocol (SDP) Content Attribute", RFC 4796, February
2007.

Uberti Expires November 04, 2013 [Page 14]

Internet-Draft WebRTC Plan B May 2013

[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009.

9.2. Informative 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.

[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.

[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in
the Session Description Protocol", RFC 5956, September
2010.

[RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image
Attributes in the Session Description Protocol (SDP)", RFC
6236, May 2011.

Author's Address

Justin Uberti
Google
747 6th St S
Kirkland, WA 98033
USA

Email: justin@uberti.name

Uberti Expires November 04, 2013 [Page 15]