Re: Spec question: precise meaning of PeerState and IceState

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.