Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt

[Justin Uberti <[e-mail]>]

On Sat, May 11, 2013 at 5:20 AM, Stefan Håkansson LK <
[e-mail]> wrote:

> On 5/10/13 8:44 PM, Cullen Jennings wrote:
> >
> > On May 8, 2013, at 2:52 AM, Stefan Håkansson LK
> > <[e-mail]> wrote:
> >
> >> * The (3-way) handshake is well aligned with the API (where the
> >> sending app initiates the sending of media)
> >
> > Interesting - I saw it sort of the opposite so perhaps you can you
> > say some more.
>
> Absolutely. The API (as of now) is aligned towards sending media. You'd
> construct a PC-stream containing PC-tracks which in turn corresponds to
> microphones and cameras. If you want to send that PC-stream to a peer
> you do "addStream" with it on a PeerConnection. If you want to add or
> remove a PC-track, there are operations for that - and it would be
> reflected on the far end.
>
> The point is that the API is about sending - not about setting up a
> session with a certain amount of ougoing and incoming PC-tracks, and to
> me that harmonizes very well with the handshake in
> draft-uberti-rtcweb-plan-00 which has separate O/A exchanges for media
> A->B and B->A respectively. An additional benefit seems to be that those
> two exchanges are somewhat independent and would not cause glare. This
> is denoted as a 3-way handshake in the draft, that is a bit misleading
> perhaps.
>
> I think this is actually proposed in the JSEP draft as well, look at the
> second part of
> http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-4.2.3.1


>
>
> > I saw this as a complete change to everything we had
> > discussed up to this point in how the API would work and how it would
> > interact with Offer/Answer. I figured dealing with this change would
> > set  back the W3C API work over 8 months so this is good news if you
> > see a way that it is the well alighted. Can you explain how it lines
> > up with the current drafts, call flows, existing example
> > applications, and APIs that are all based on a 2 way hand shake?
>
> As I read draft-uberti-rtcweb-plan-00, no API changes are needed or
> proposed, and the call flows could stay the same (but as I recollect the
> discussion at the Boston interim they should be changed for other reasons).
>
> The sole API change that is proposed is the new .content property, to
allow a MST to have its a=content property set, and as such be placed on
its own m= line. The rest works using the existing APIs; the necessary
a=remote-ssrc lines can be generated (to enable or disable a stream) based
on whether a received MST is hooked up to an output or not.