W3C home > Mailing lists > Public > public-sysapps@w3.org > February 2014

Re: Telephony API Review

From: Kis, Zoltan <zoltan.kis@intel.com>
Date: Thu, 6 Feb 2014 18:32:02 +0200
Message-ID: <CANrNqUd_gXuGAS-jmxuvDn62_Z+sJ-4oe1t8j8GGsBSd_-dVtA@mail.gmail.com>
To: "Mandyam, Giridhar" <mandyam@quicinc.com>, "public-sysapps@w3.org" <public-sysapps@w3.org>
Hello Giri,

On Thu, Jan 30, 2014 at 5:19 PM, Mandyam, Giridhar <mandyam@quicinc.com>wrote:

> As I agreed to do at the last F2F (during the November 2013 TPAC), I
> conducted a review of the Telephony API with the internal Firefox OS team
> within Qualcomm.  Hope this is of use to the group.
> -Giri Mandyam, Qualcomm Innovation Center
> -------------------------------------------------------
> The version of the API we reviewed is at
> http://www.w3.org/2012/sysapps/telephony/.
Thank you very much for the review. This is really welcome. Some answers
Before I file issues, we could try to clarify the problems signaled below.
In the scope of this discussion, I assume the use case has not changed, and
the Telephony API serves for writing dialers.

> General comments:
> 1.      Concurrency (data/voice) is not a given - there are several
> situations where an incoming voice call will interrupt a data session.
>  There should be a system event for an incoming voice call that any
> application could leverage.

True. There is a Note and an issue on this. I believe this event belongs to
the API which will own the data session, and not to Telephony.

> 2.      The current API does not handle CDMA (IS-41) conference calling
> adequately.  {This is recognized by the spec editors and was discussed
> during the Toronto Working Group F2F last year).

I think the API does not need to match 1:1 the CDMA 3-way calling spec. It
is enough if the API implementation permits the users of this API to handle
CDMA 3-way calls. Clients should be aware of the service they are working
with, and adapt dialer behavior accordingly.
In more detail, see below.

> Specific comments:
> 1.      Hide caller ID (
> http://www.w3.org/2012/sysapps/telephony/#widl-DialOptions-hideCallerId)
> would be better handled via an MMI code rather than an API call.

The implementation of the API call could use MMI, but using MMI directly
would be rather user-unfriendly. With the API, the caller id can be hidden
per each call. If the API cannot be implemented on a given platform, an
error condition could be signaled. There is a new API proposal that returns
a Promise from a dial(). I will update that and send an update.

> 2.      Change default service (
> http://www.w3.org/2012/sysapps/telephony/#widl-TelephonyManager-changeDefaultService-Promise-DOMString-serviceId).
>  Why is this in the TAPI?  It would be better handled in a settings
> API/settings app.  This is not something that is typically controlled
> through the RIL.

The current design of the API comes from the original B2G which did not
support multiple SIM. The way it is supported now is to be
backward-compatible with the old API, and add optional serviceId for those
methods that can work on different telephony services. If the serviceId is
not specified, the a default one is used. This is described in the spec.

If it is exposed in a settings API, it still belongs to Telephony domain,
including permissions. Implementations will want to keep relevant
functionality in one place, because the special latency requirements of
telephony middleware.

> 3.      Service change events (
> http://www.w3.org/2012/sysapps/telephony/#widl-TelephonyManager-onserviceadded).
>  Why is this in the TAPI?  This is also not something that is typically
> propagated through the RIL.

If a new modem or SIM appears, the dialer app will definitely want to know
about it.
Both telephony middleware we use support this.

> 4.      Call states (http://www.w3.org/2012/sysapps/telephony/#call-states):
>  dialing, active, incoming, waiting, held and disconnected can be
> supported.  The other states cannot.

No problem. This has been discussed. The spec defines the space of
allowed/possible states, but the implementation follows the states as
reported by the network.

> 5.      Call redirect (
> http://www.w3.org/2012/sysapps/telephony/#the-redirect-method) and
> transfer (http://www.w3.org/2012/sysapps/telephony/#the-transfer-method)
> would be better handled via MMI codes.

For the general policy settings, yes. For in-call redirection, the API is

> 6.      Current TelephonyCall (
> http://www.w3.org/2012/sysapps/telephony/#telephonycall-interface) does
> not have hold and disconnect (end) methods.  Is this intentional?

 It is defined in
The CallHandler is used for specifying the common properties of
TelephonyCall and ConferenceCall (both implement CallHandler). This is
pretty clearly described in the spec.

> 7.      createConference (
> http://www.w3.org/2012/sysapps/telephony/#widl-TelephonyCall-createConference-ConferenceCall)
> method is fine for CDMA, but the returned ConferenceCall object will not
> have information on the dialed parties (at least this information won't be
> coming from the RIL).  The browser implementation would have to retain this
> info.  The current ConferenceCall object enumerates the dialed parties
> through a TelephonyCall array.

No problem. The implementation will expose the information it can gather,
and add what it can. I think we should make a Note about that clients
should be aware of such protocol differences.

> 8.      conferenceID (
> http://www.w3.org/2012/sysapps/telephony/#widl-ConferenceCall-conferenceId)
> is not obtainable through the RIL.  Is this going to be assigned by the
> User Agent?

Yes. The spec states that mapping between conferenceId and network
identification(s) of the conf call is maintained by the UA.

> 9.      Conference call states (
> http://www.w3.org/2012/sysapps/telephony/#widl-ConferenceCall-onparticipantadded)
> - held, active, disconnected can be supported.  The other states cannot.
As above, no problem. The actual set of states will be what the network
reports and the MW exposes.

I hope this clarifies some of the concerns . Please tell if there are
remaining problems, and feel free to file issues - or just reply here and I
will do it.

Best regards,
Received on Thursday, 6 February 2014 16:32:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:19 UTC