Re: Telephony API - Call States and Transitions

On Tue, Jan 22, 2013 at 7:29 PM, EDUARDO FULLEA CARRERA <efc@tid.es> wrote:
> Hi,
>
> There are two different trends followed by the two Telephony API proposals on the table regarding call states and transitions.
>
> In a nutshell the basic difference is whether:
> -we specify a call state machine that allows the telephony applications to be confident on the state transitions that may be expected at every point in the call flow (as in [1] section 8.2),

Please correct me if I misunderstood this proposal, but in my
interpretation this means that regardless of the telephony protocol
used and the telephony network conditions, implementations MUST
implement a fixed state machine with fixed state transitions,
inventing states when needed (and disconnecting? on perceived
irregularities), regardless on what state the call is in the network -
in order to allegedly ease the job of dialer developers. When
inventing states, there is a danger of race conditions. When
disconnecting for irregularities, there is a danger of conflicting
with telephony certifications.

> or otherwise
> -we define a state transition matrix (as in [2] section 4.4) which describes a lax transition policy between call states and require the telephony applications to re-synchronize its internal state according to the call transitions reported by the telephony network

A correction: the Intel spec does not define a lax policy, it just
enumerates the likely possible transitions, but states that the dialer
applications must not assume a desired sequence of events, but must
synchronize their internal states with the network and take care of
possible conflicts. While this method allows that dialers define a
fixed state machine themselves internally (similar to the other design
principle), but it does not mandate implementations doing and
guaranteeing it.

>
> The authors of these proposals are interested in getting fresh arguments from other members of the group on the two approaches.
>
> [1] http://sysapps.github.com/sysapps/proposals/Telephony/Telephony.html
> [2] http://sysapps.github.com/sysapps/proposals/Telephony_Intel/Telephony.html
>

As a note, I have been having this same argument in the past: dialer
developers want a known state machine (for understandable, but
theoretical reasons), and telephony middleware developers say this
completely depends on the telephony standard used and the telephony
network equipment (because that is the reality).

First, experience with telephony middleware and dialers tells me there
will be problems with the fixed state machine proposal,  will be an
unnecessary burden on implementations, and may even cause
certification issues, when e.g. an otherwise working call would be
disconnected by the implementation thinking the call is making a call
state transition which is not conforming to this specification. Dialer
developers tend to know the protocols in question anyway.

Second, W3C standardization should not mean and should not interfere
with telephony standardization.

So, my proposal would be that we don't specify at all state
transitions, but state that the implementations must convey the call
state and it is the responsibility of applications to handle the
transitions.
My compromised proposal (as in the Intel spec) is that we list the
most common state transitions, but don't mandate a unified state
machine.
My worst fear is that we mandate a fixed telephony state machine :).

Best regards,
Zoltan

Received on Tuesday, 22 January 2013 19:57:38 UTC