Re: Telephony API Review

Hi Giri,

Thank you very much for the review. I will look into this, and file issues
for the problems we don't track yet. I think we should continue most of the
discussion via github issues, but I will also send a reply to this list,
hopefully during this week, concerning scope and design decisions.

Best regards,
Zoltan



On Mon, Feb 3, 2014 at 4:36 PM, Wonsuk Lee <wonsuk73@gmail.com> wrote:

> Hi. Mandyam.
> Thanks a lot for valuable feedback.
>
> Editors for Telephoy spec, what do you think?
>
> Kr Wonsuk.
>
>
> 2014-01-31 Mandyam, Giridhar <mandyam@quicinc.com>:
>
> 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/.
>>
>> 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.
>>
>> 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).
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 6.      Current TelephonyCall (
>> http://www.w3.org/2012/sysapps/telephony/#telephonycall-interface) does
>> not have hold and disconnect (end) methods.  Is this intentional?
>>
>> 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.
>>
>> 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?
>>
>> 9.      Conference call states (
>> http://www.w3.org/2012/sysapps/telephony/#widl-ConferenceCall-onparticipantadded)
>> - held, active, disconnected can be supported.  The other states cannot.
>>
>>
>
>
> --
>
> =========================================
> ÀÌ ¿ø ¼® (Wonsuk, Lee) / Principal Engineer, Ph.D
> SAMSUNG ELECTRONICS Co., LTD. (ß²àøï³í­)
> Mobile: +82-10-5800-3997
> E-mail: wonsuk11.lee@samsung.com, wonsuk73@gmail.com
> http://www.wonsuk73.com/, twitter: @wonsuk73
> -----------------------------------------
> Inspire the World, Create the Future !!!
> =========================================
>

Received on Monday, 3 February 2014 14:53:59 UTC