Re: Mozilla/Cisco API Proposal

On Jul 11, 2011, at 20:22 , Ian Hickson wrote:

> 
> Whether you're on a call or not doesn't affect new calls. It's a new ICE 
> transaction each time, and ICE transactions don't interfere wich each 
> other.

mostly agree though they do interfere with each others pacing 

> 
> The way you start a call with the PeerConnection API is that you create a 
> PeerConnection object, and then don't call signalingMessage(). The API 
> will then call the callback with the initial SDP offer, to send via the 
> signaling channel to the other peer.

I'm sort of wondering how long you have to not call the signalingMessage before it sends the SDP offer?

> 
> The way you listen for a call with the PeerConnection API is that when you 
> receive that initial SDP offer from the initiating peer, you create a 
> PeerConnection object and immediately call signalingMessage() on it with 
> the SDP offer.
> 
> If these get out of sync, the normal ICE mechanism resolves any conflicts. 
> (For example, both sides can start the connection; the ICE agent will then 
> figure out what's going on. This is all defined by ICE already.)
> 
> There's thus no need for an explicit open() or listen().

There's two layers of signaling going on here. The ICE and the SDP. If both sides simultaneously send an offer to the other side, I don't think ICE sorts out what happens next. I don't view this as a real big problem with your current API - I like that it tries to hide all that. But it seems we have some edge conditions that we need to find a way to work around. I see it as underling the PeerConnection we have two state machines per person we are talking to. One is the ICE level state machine and other other is the Offer/Answer state machine and it needs to support half open connections as well as fully open connection. (sorry to use the unix sort of terminology but I think you know what I mean).

Received on Tuesday, 12 July 2011 14:53:39 UTC