Re: Phone call about ICE states

On 09/10/2012 07:40 PM, Martin Thomson wrote:
> On 9 September 2012 23:26, Justin Uberti <juberti@google.com> wrote:
>> I updated my IceState proposal (which corresponds to Option A, or the
>> high-level part of Option C) based on the points raised at Thursday's
>> discussions. Please take a look at the "IceState proposal" section in the
>> attached document, and let me know what you think.
>
> A few comments:
>
> In the Peer state diagram there are six "events".  Not all states have
> transitions declared for all three events.  Is the implication that
> the events that are not shown are invalid and will be rejected?
> Obviously, setLocal(Offer) followed by setLocal(Answer) probably isn't
> good, but it's unclear whether the following sequence is necessarily
> bad: setLocal(Offer), setRemote(PRAnswer), setRemote(Offer).  In that
> case, you could force someone to insert a setRemote((Answer)PRAnswer)
> to progress, but a robust browser implementation might want to protect
> users by performing this implicitly.

(Sorry Justin, I know you asked for feedback on the ICE states only...). 
Yes, the things Martin points out are relevant. I just wanted to make 
the list longer (with the hope this might help in updating this part). 
The following things are also unclear to me:

* what happens if the same offer that is used in setLocal(offer) is 
answered to, while a new offer has been set? I.e. the following sequence:

1. setLocal(offer1);
2. setLocal(offer2);
3. setRemote(answer-to-offer1);

* what happens if an offer, or answer, is not accepted (in 
setLocal/setRemote)? The error callback is called, so the app would 
know, but what would the state be?

Received on Tuesday, 11 September 2012 17:46:04 UTC