- From: Matthew Kaufman <matthew.kaufman@skype.net>
- Date: Tue, 19 Jul 2011 15:22:20 -0700
- To: Anant Narayanan <anant@mozilla.com>
- CC: public-webrtc@w3.org
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