RE: Telephony API - Call States and Transitions

Hi Zoltan, all,

On 22 ene 2013 at 20:57:06, Kis, Zoltan wrote:
> 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.
>

The idea is to provide app developers predictability on the call flow. Note that not every state needs to be linked to a state in the telephony standard. For instance the disconnecting state may represent the state since the application request the disconnection until the disconnection is confirmed by the Radio Layer to the middleware and in turn to the application, even if the disconnection is immediate at the pure radio level. Another example is the accepted case which describes the state since the app confirms the user wants to pick the call until the middleware informs the app that the radio layer has connected the call.

>> 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.
>

Sorry if you feel that 'lax policy' does not properly qualifies your proposal. I meant that a wider range of states are allowed after each specific state. I am open to study these additional transitions on a case-by-case basis but I think that specifying the expected call flow (ideally in the form of a state diagram if workable) would be beneficial for app developers. Note that our proposal does not prevent the application trying to recover upon an unexpected state transition.

Regards,
Eduardo.

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Received on Wednesday, 23 January 2013 11:56:01 UTC