[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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.

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
   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]

   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
   a=remote-ssrc:105 on
   [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 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]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/