RE: Phone call about ICE states

Hi Justin,
Some questions.
1. Are we right in saying actual uses of ICE states from an App/User perspective, apart from logging/debugging are minimal. "Disconnected" and "Failed" may be used to report/alert the user and initiate re-trials. It's understandable that these are minimal states that need to be enumerated but can we have some information/guidance on their usage upon detection?
2. May be this adds to the list of "Error Transitions".
      The current state diagram looks simple and it is good to be that way. Question I have is, I believe PeerConnection States and ICE States overlap at some point. In such a case, the "error transitions" cases will be more in number. One such state transition: setLocal(Offer1)-->setRemote(Answer1)/Active-->ICE not moved to Connected/Completed yet-->setLocal(Offer2). Or is this just hypothetical?
      Error Transitions in state diagrams make it cluttered but can we have some small notes on what is allowed/not allowed.

Thanks,
Srikar.

________________________________________
From: Stefan Hakansson LK [stefan.lk.hakansson@ericsson.com]
Sent: Tuesday, September 11, 2012 11:15 PM
To: public-webrtc@w3.org
Subject: 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?





Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 

www.wipro.com

Received on Friday, 14 September 2012 16:34:28 UTC