Re: Phone call about ICE states

On Tue, Sep 11, 2012 at 10:45 AM, Stefan Hakansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> 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:
>
>
Your email was shorter, so responding to this one first...


> * 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);
>

The behavior is undefined. Some cases will work, some won't. Consider this
case:
- offer1 has just m=audio
- offer2 has m=audio, m=video
- clearly if answer-to-offer1 has just m=audio (as it should), this will
fail.

If the application actually sends offer1 and offer2 across the wire (as
opposed to doing setLocal(offer1), setLocal(offer2), but only sending
offer2 across the wire), it would have to roll back the local desc to
offer1 before doing setRemote with the answer-to-offer1, e.g.
- setLocal(offer1)
- setLocal(offer2)
- answer-to-offer1 is received
- setLocal(offer1)
- 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?
>

If rollback is possible, the state does not change. However, I imagine many
implementations will not be able to rollback if an error occurs while
applying the description, and will treat this error as fatal, resulting in
the closed state.