- From: Justin Uberti <juberti@google.com>
- Date: Wed, 20 Jun 2012 10:49:10 -0400
- To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Cc: public-webrtc@w3.org
- Message-ID: <CAOJ7v-0COS62O5Uw-Py2MUq_9yXQYC32QXqYgQuzAmsNVEAOcg@mail.gmail.com>
On Wed, Jun 20, 2012 at 6:58 AM, Stefan Hakansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 06/19/2012 08:54 PM, Randell Jesup wrote: > >> On 6/15/2012 5:33 PM, Justin Uberti wrote: >> >>> Reviewing the latest draft, the meanings of some of the values of >>> PeerState and IceState were unclear. In addition, there was no IceState >>> to indicate a liveness check failure. >>> >>> The following is a proposal to provide clear state information from both >>> PeerState and IceState as well as to notify the application of liveness >>> check failures. >>> >>> If you can't see the state diagrams below, you can view them at >>> https://docs.google.com/**document/d/**13TYiNSEmFkB7IeNLEJFxI0xMNk8q_** >>> LhXE_hbvFbXRTU/edit#<https://docs.google.com/document/d/13TYiNSEmFkB7IeNLEJFxI0xMNk8q_LhXE_hbvFbXRTU/edit#> >>> . >>> >> >> This all seems reasonable to me. >> > > My knowledge barely covers the "PeerState" part, but that looks reasonable > at first sight. > > A question: introducing these states also opens for error handling. Say > you're in state "received-pranswer", if the app does "setLocal(offer)" this > would be an illegal state transition. Is this something we should add? > Yes, any attempt to cause an invalid state transition should result in some sort of invalid-state exception. Chrome does this right now, albeit with some sort of generic exception.
Received on Wednesday, 20 June 2012 14:50:06 UTC