Re: Telephony API Review

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


>
> 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
http://www.w3.org/2012/sysapps/telephony/#callhandler-interface
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,
Zoltan