Re: on Telephony

Hello,

There was no answer on email below (please read).
Are we counting on discussing all these issues on a face to face meeting?
Nevertheless, I try pinging, since email discussion still makes sense
before f2f.
I have moved the Intel proposal for Telephony into the Telephony
directory, with the intention to align them as much as possible.

Eduardo, Jonas, could we move forward with the Telephony specs as follows:

1. we revisit, discuss and decide about the call states and state
transitions (still waiting for comments from AT&T, Ericsson, and
others)
2. group the audio controls in a separate interface
3. review the support for multiple SIM's and eventually phone
conference which I have drafted
4. move the rest in a draft (Telephony_Intel.html renamed to
Telephony_next.html or something similar) which will serve for the
next version, including video call support. But if we can agree on it,
we can specify it now. (Waiting for comments from group member whether
to include video support in this version, or not.)

Does that sound acceptable?

Best regards,
Zoltan

On Thu, Jan 10, 2013 at 9:48 PM, Kis, Zoltan <zoltan.kis@intel.com> wrote:
> 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 Tuesday, 22 January 2013 13:03:55 UTC