Re: Mozilla/Cisco API Proposal Revisions

On 7/19/2011 2:35 PM, Anant Narayanan wrote:
>
>     3d) Matthew gave us an overview of what it meant to model 
> PeerConnections after either flows or sessions. Notably, he points out 
> that there is value in reusing session setup, thus, opening a new 
> session should have the same API as that of opening a flow that reuses 
> an existing session.
>
>     *ACTION*: We have not yet described in detail what actually 
> happens when a PeerConnection object is constructed and what happens 
> when connect() is called [if we decide to adopt that API], but when we 
> do, Mathew's suggestions are certainly useful. Does all of this get 
> specified as part of the W3C-WG or the IETF?

Just to clarify a bit: all of the below should have exactly the same 
API, and same behavior, modulo possibly firing events in some cases (to 
exchange candidates or request tunnels be set up) and not others, and 
the timing of when "ready" or "success" events fire:

Alice creates a flow for video to Bob and there is no session between 
Alice and Bob.
Alice creates a flow for video to Bob and there is a session between 
Alice and Bob already open and carrying audio from Alice to Bob.
Alice creates a flow for video to Bob and there's no other flows open 
from Alice to Bob but there is already a session open carrying a flow of 
audio from Bob to Alice.
Alice creates a flow for video to Bob and there is a session *being 
opened, but not yet open* between Alice and Bob that is being created 
for the purpose of carrying audio from Alice to Bob.
Alice creates a flow for video to Bob and there is no session between 
Alice and Bob *but* a session is already in the process of being opened 
between Bob and Alice in response to Bob creating an audio flow to Alice.
Alice and Bob simultaneously create flows for video to each other and 
there is not yet a session open between them. The result should be a 
single session and glare conditions should automatically (from the 
API-user's point of view) be resolved.

This list of cases is not exhaustive.

And note that detecting that the far end is the same "Bob" you already 
have a session open to can be non-trivial in some cases unless there are 
good unique identifiers that are part of the handshake.

Matthew Kaufman

Received on Tuesday, 19 July 2011 22:33:41 UTC