RE: Spec question: precise meaning of PeerState and IceState

The concept of nested states is often useful for expressing this kind of error handling.  The idea is  that you have a parent state containing nested child states.  Each state can declare a transition/handler for an event, and the most deeply nested one wins.  Suppose parent state S has child states s1 and s2, and both s1 and S have transitions/handlers for event ‘foo’, but s2 does not.  Then if you’re in s1 and foo occurs, s1’s transition fires, while if you’re in s2,  S’s transition fires.  This allows you to place generic error handlers on the outer state, and more specific handlers in the inner states.   (In this case the idea is that foo is supposed to occur when you’re in s1.  Any place else it’s an error.  Placing the error handler on the parent state leads to a more succinct notation, particularly in complicated state machines.) 

 

Nested states can be found in UML  http://www.omg.org/spec/UML/2.4.1/  and SCXML http://www.w3.org/TR/scxml/ 

 

-          Jim

 

From: Justin Uberti [mailto:juberti@google.com] 
Sent: Wednesday, June 20, 2012 10:49 AM
To: Stefan Hakansson LK
Cc: public-webrtc@w3.org
Subject: 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.