Re: Phone call about ICE states

On 09/12/2012 08:12 AM, Justin Uberti wrote:
>
>
>
> On Tue, Sep 11, 2012 at 10:45 AM, Stefan Hakansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto: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
>         <mailto: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)

That makes sense. I guess we should put some text about this somewhere 
so that app developers don't make silly mistakes.

>
>
>     * 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.

OK. I guess we need to study the rollback case a bit.

>
>

Received on Wednesday, 12 September 2012 06:38:21 UTC