Re: Phone call about ICE states

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.

In the Peer state, the New and Active states are not different, except
for the fact that one might have some streams active.  I'd suggest
that you could collapse the two.

You don't describe what the states belong to.  If I infer that the
state owner is PeerConnection, then I might conclude that the ICE
states are no good.  But then I wasn't able to join a call on short
notice and I might have missed some discussion that was relevant.

Based on implementation of some ICE stuff, network adapter changes and
trickling make this entire state machine less clear.  For instance,
assuming that you don't suffer a network reset in Checking, you can
never transition to Failed because there is no way to tell that your
peer has finished supplying candidates.  Loss of a local candidate due
to loss of the interface can cause a transition to Failed or
Disconnected.

I'm not sure that you want to drive ICE state based on the receipt of
offers or answers.  Without trickle, answers trigger the start of
checking (which would imply the transition TO Checking).  Otherwise,
offers and answers formalize the conclusions made in ICE, they don't
drive the state machine.

Restarts probably shouldn't transition back to Starting.  If I
conclude that the transport is unusable in all states other than
Connected or Completed, then a restart that is triggered as a result
of (for example) the addition of a new, maybe preferable, interface
could keep the old transport live throughout the entire process.
Using Starting and Checking analogues might be appropriate.

Does it make sense to provide an event for the establishment of a transport?

Is it worthwhile identifying which peer is controlling?  I've found
that this has been useful from a diagnostic perspective.

Received on Monday, 10 September 2012 17:40:58 UTC