- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Tue, 11 Sep 2012 19:45:37 +0200
- To: public-webrtc@w3.org
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