Re: change proposal for Telephony API

Hi Hsin-Yi,

Thank you for looking through the proposal.

On Thu, Apr 18, 2013 at 11:58 AM, Hsin-Yi Tsai <htsai@mozilla.com> wrote:
> I am not sure I got a clear difference between the interfaces
> TelephonyManager and TelephonyService. I am a little confused at the purpose
> and definition of TelephonyManager in this proposal. For example, I am
> wondering shouldn't onincoming and oncallschanged be exposed on
> TelephonyService since we can't receive any calls without telephony service,
> and since you propose a separate API for that service. It seems not
> intuitive to me that we use TelephonyService to make an outgoing call but
> receive incoming calls via TelephonyManager.

In telephony domain all the incoming calls should be handled by one
object, since only one call will get resources (e.g. audio, video), so
arbitration is needed - as opposed to messaging, where each messaging
service can independently receive messages.

For dialed calls, the given service can be used, or by enumerating the
services through the manager and using them.

> Also, shouldn't each telephony service contain its calls?

It could, but not much use. The dialer is interested to resynchronize
itself with the list of current calls on startup (since perhaps it has
crashed). This is easier to do with one call list, then to list all
services, then list all calls from them. The calls themselves can be
managed by their TelephonyCall or ConferenceCall  objects, and they
keep track on which service they are (by the serviceId).

>
> In this proposal navigator.telephony is 'active' telephony service according
> to the comment. It looks not so right to me because there could be more than
> 1 active service at that same time.

You are right, the comment should be "default telephony service".

Best regards,
Zoltan

>
>
> On 2013¦~04¤ë17¤é 22:13, Kis, Zoltan wrote:
>>
>> Hello,
>>
>> Here is an alternative way to do Telephony, compatible with the
>> previous version, but cleaner, better aligned with how telephony
>> works, more extensible, and also aligned with the Messaging API.
>>
>> I kindly ask for comments at least from the persons named in the To field
>> :).
>>
>> In the current API we support multiple services, but they are not
>> exposed as objects.
>> Only the serviceId's can be seen, and specified as parameters for
>> methods like dial(), sendTones(), startTone(), stopTone(), and also
>> for errors (e.g. on which service the error occured).
>>
>> Also, there were requests to support telephony services (like network
>> selection, SIM info, call barring, call forwarding, USSD, etc) in
>> Phase 2, the TelephonyService objects will likely be exposed in the
>> API, but of course documented in a separate specification.
>>
>> The proposal here is to encapsulate the telephony service specific
>> methods and error handling to service objects (just like with
>> messaging), and expose the default service on the navigator object,
>> along with the telephony manager object.
>> This keeps the example unchanged:
>> var telCall = navigator.telephony.dial('+1234567890');
>>
>> This design could also be applied to Messaging (in a separate email,
>> later, eventually), by exposing an active/default service for sms,
>> mms, (im, email) and the messagingManager.
>>
>> For comparison, the current design can be seen at
>> http://telephony.sysapps.org/ .
>>
>> The WebIDL for the alternative proposal is here:
>>
>> ======================
>>
>> partial interface Navigator {
>>      readonly attribute TelephonyManager telephonyManager;
>>      attribute TelephonyService telephony; // active telephony service
>> };
>>
>> [NoInterfaceObject]
>> interface TelephonyManager : EventTarget {
>>      readonly attribute CallHandler?  activeCall;
>>      readonly attribute CallHandler[] calls;
>>      readonly attribute TelephonyService[] services;
>>
>>      attribute EventHandler onincoming; // for incoming and waiting
>>      attribute EventHandler oncallschanged;
>>      attribute EventHandler onserviceadded;
>>      attribute EventHandler onserviceremoved;
>> };
>>
>> [NoInterfaceObject]
>> interface TelephonyService : EventTarget {
>>      readonly attribute DOMString serviceId;
>>                   attribute DOMString displayName; // to be shown in a UI
>>                   attribute boolean  enabled;
>>      readonly attribute DOMString provider;
>>      readonly attribute DOMString type;
>>      readonly attribute DOMError  error;
>>      readonly attribute DOMString[] emergencyNumbers;
>>
>>      attribute EventHandler onerror;
>>
>>      TelephonyCall dial(DOMString remoteParty, optional DialParams
>> params);
>>      TelephonyCall dialEmergency();
>>      void sendTones(DOMString tones, optional ToneParams params);
>>      void startTone(DOMString tone);
>>      void stopTone();
>> };
>>
>> [NoInterfaceObject]
>> interface TelephonyEvent : Event {
>>      readonly attribute TelephonyCall call;
>> };
>>
>> [NoInterfaceObject]
>> interface TelephonyServiceEvent : Event {
>>      readonly attribute TelephonyService service;
>> };
>>
>> dictionary ToneParams {
>>      unsigned long duration;
>>      unsigned long gap;
>> };
>>
>> dictionary DialParams {
>>      boolean hideCallerId;
>>      // later: e.g. video related settings
>> };
>> ======================
>>
>> An example on how cellular services could be implemented in Phase 2
>> (shown here in order to demonstrate forward compatibility):
>>
>> interface CellularService : TelephonyService {
>>      // telephony service (provider + SIM + modem) related interfaces
>>      // if an interface is not supported, the property is null
>>      readonly attribute SimInfo?                 siminfo; // IMSI, MCC,
>> MNC, ...
>>      readonly attribute SimSettings?          simsettings; //PIN, PUK, ...
>>      readonly attribute SimToolkit?             simtoolkit;
>>      readonly attribute TelephonyNetwork? network;
>>      readonly attribute CallForwarding?      forwarding;
>>      readonly attribute CallBarring?            barring;
>>      readonly attribute CallMeters?            meters; // costs
>>      readonly attribute USSD?                  ussd; // USSD, ...
>>      // further extensible
>> };
>>
>> Note that this proposal is independent from how conference calls are
>> handled.
>>
>> Best regards,
>> Zoltan
>>
>
> --
> Hsin-Yi Tsai ½²ªY©y
> Mozilla Taiwan
> T: +886-2-87861100 ext:312
> htsai@mozilla.com
>
>
> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 -
> 4 Domiciled in Helsinki
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.

Received on Thursday, 18 April 2013 09:16:46 UTC