change proposal for Telephony API

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

Received on Wednesday, 17 April 2013 14:13:36 UTC