Re: Telephony API - Call States and Transitions

Hi Eduardo,

> The idea is to provide app developers predictability on the call flow.

As a generic idea it is OK. But not as a spec to implement and guarantee.

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

This is the case when states are inserted. This should be OK, except
when the state perceived by the app is not in sync with the actual
call state, because delays introduced by the implementation.

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

What does your proposal do when there is a perceived state transition
which does not follow the specified state diagram?

A separate concern. What do you think about the issue Dan wrote about,
that in order to correctly interpret the reported call state a dialer
app also needs information about the protocol stack used? In Intel's
proposal, the telephony service may carry that information. I see this
as an additional argument to introduce the notion for telephony
service, also needed for supporting multiple SIM cards.

Best regards,
Zoltan

Received on Wednesday, 23 January 2013 12:31:40 UTC