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

[Stefan Håkansson LK <[e-mail]>]

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).

>
>
>