on Telephony

Hello,

I would like to open this thread to raise, discuss and resolve issues
related to the Telephony API.
As Adam noted, at the moment there are 2 specifications, with
overlapping authorship.

The "main" one is with joint ownership, which mainly covers the use
cases of Mozilla and Telefonica.

There have been requests for a few further use cases. I have submitted
another version for Telephony for presenting in a coherent way how to
support the missing use cases. This was not meant to replace the joint
spec, but for illustrating how to improve/develop it further.

The way I would like to proceed:
- let AT&T, Ericsson, and others review both proposals
- let the joint spec be the starting draft
- let's try to resolve the issues in the joint spec
- let's discuss the support for the missing use cases
- let's include all agreed features into the joint spec, with clear
statements on what is normative, and what is optional to implement.
This is to accommodate the different use case sets.

***

About the Intel proposal for Telephony.

1.) There is support for conference calls and for handling multiple
SIM cards/telephony services. These involve minimal changes: one
optional parameter in some of the existing methods for telephony
service id, and a couple of added methods for handling conference
calls. A side benefit is future compatibility with VoIP/VoLTE services
(2 call states were also added in order to support VoIP connection
setup phase). Since all calls are competing for the same audio/video
resources, it is much simpler to handle them from one API.

2.) Further, I have grouped audio controls into a separate object, and
created a similar object for the main video parameters needed for
making a dialer UI (since there was a request to try to draft it). We
do not need all properties from e.g. MediaStream, just the ones which
are needed to make a dialer UI. I also think these may be temporary
interfaces: once a coherent solution is found across the W3C
specifications, they can be obsoleted. However, until then I consider
important to keep them, in order to track what is the minimal
information needed for implementing dialers. This may influence the
development of the related specifications.

3.) I have also presented a different opinion in the dispute regarding
call state handling in the joint specification. The call state machine
in the joint proposal is not good enough in my opinion, especially in
picture form. The information the picture should captures is
the possible state transitions from a given state, which is much more
clear in a list form. The picture would become too loaded. Further,
the state transition list should be purely informative IMO. The
specification should not mandate any call state transitions or state
machine, since call state is controlled by the telephony network
equipment, not by the implementation of the API. For example, there
should be no errors raised by implementations for perceived erroneous
state transitions (especially if the call is otherwise working fine).
Dialers should not make assumptions about state transition either,
instead they should follow the call state as updated by the
network/modem and try to recover from perceived errors. Since this
affects telephony certifications, I have a strong opinion for making
any state transition picture non-normative for implementations.
Counter-opinions include concerns for how to write a dialer if state
transitions are not "regulated" before the dialer. For a fact, I am
using such a dialer daily, so it is possible. Call states are
controlled by telephony standards (and are different between
protocols), not by W3C standards. Dialer implementations are free to
define any intermediate internal state machine, but that should not be
standardized in and required by this API.

4.) I have included a description of Call History entry (only the
structure) in the Telephony API,  but nothing about how to retrieve or
search on it - which would be similar to what is used in Messaging and
Contacts API. That is a separate subject. The important information
here is what to expect to be stored in a call history, again, with
normative and informative parts.

5.) One gap which remains not handled is the graphical vs
non-graphical (vibra, LED, tones, ringtones) notifications for calls,
also in connection with notifications from other API's (calendar,
clock, navigation, music player, etc). This is an important issue. IMO
this group should discuss this. Intel can present a proposal, and
AFAIK, Mozilla also works on one. Since this is an essential part of
Telephony, I propose we add a Non-graphical Notification API to this
charter.

6.) Another gap which is not handled now is about performance
(connected with security). In the past I have seen issues with system
load affecting incoming telephony calls (network times out, there is
not even missed call event recorded). Therefore we need to make sure
that telephony events are not competing with any other app's or page's
events. Since this too affects certifications, it would be nice to
agree on a design which solves this issue. What we need to make sure
is that the API design allows such implementations.
So far, security design affects app lifecycle and data handling - I
would add it should also affect runtime isolation of key components in
terms of event handling etc.

Best regards,
Zoltan

Received on Thursday, 10 January 2013 19:48:52 UTC