WebAPI/WebTelephony/Multi-SIM

Proposal: WebTelephony API for Multi-SIM

Currently B2G supports a single SIM architecture. This proposal wants to extend it for supporting multi-SIMs. Here, we introduce a central 'nsIDOMTelephonyManager' to manage several DOMTelephony objects. One DOMTelephony object is binded to a physical SIM slot.

nsIDOMTelephonyManager controls the call policies, such as when an outgoing call can be placed or which incoming call is to be answered. Besides, by this WebTelephony API, user can choose which SIM card he wants to make a call through, or user can choose which incoming call he wants to accept if there are more than one. User can also easily get all the calls from all the SIMs as well as all the calls within a specific SIM.

Web API

interface nsIDOMTelephonyManager : nsIDOMEventTarget
{
attribute boolean muted; /* Moved from the original nsIDOMTelephony */
attribute boolean speakerEnabled; /* Moved from the original nsIDOMTelephony */

readonly attribute jsval active;
readonly attribute jsval calls;
readonly attribute phoneState;  /* Ringing, Offhook, Idle */
readonly attribute jsval phones;
readonly attribute nsIDOMTelephony defaultPhone;

[implicit_jscontext] attribute jsval onincoming;
[implicit_jscontext] attribute jsval oncallschanged;
};

interface nsIDOMTelephony: nsIDOMEventTarget
{
nsIDOMTelephonyCall dial(in DOMString number);

// The call that is "active", i.e. receives microphone input and tones
// generated via startTone.
readonly attribute jsval active;

// Array of all calls that are currently connected.
readonly attribute jsval calls;

void startTone(in DOMString tone);
void stopTone();

attribute nsIDOMEventListener onincoming;
attribute nsIDOMEventListener oncallschanged;
};

interface nsIDOMTelephonyCall: nsIDOMEventTarget
{
readonly attribute DOMString number;

// "dialing", "alerting", "busy", "connecting", "connected", "disconnecting", 
// "disconnected", "incoming", "holding", "held", "resuming"
readonly attribute DOMString state;

readonly attribute nsIDOMDOMError error;
readonly attribute nsIDOMTelephony phone; /* New attribute */

// functions to mediate a call.
void answer();  
void hangUp();
void hold(); 
void resume(); 

attribute nsIDOMEventListener onstatechange;

attribute nsIDOMEventListener ondialing;
attribute nsIDOMEventListener onalerting;
attribute nsIDOMEventListener onbusy;
attribute nsIDOMEventListener onconnecting;
attribute nsIDOMEventListener onconnected;
attribute nsIDOMEventListener ondisconnecting;
attribute nsIDOMEventListener ondisconnected;
attribute nsIDOMEventListener onincoming;
attribute nsIDOMEventListener onholding; 
attribute nsIDOMEventListener onheld; 
attribute nsIDOMEventListener onresuming; 
};

Use Case

Outgoing Call

• Current B2G (Single SIM)

 navigator.mozTelephony.dial(number)

• Multi-SIMs

 navigator.mozTelephonyManager.defaultPhone.dial()
 navigator.mozTelephonyManager.phones[index].dial()

Incoming Call

• Current B2G (Single SIM)

 Tel1 = navigator.mozTelephony;

• Multi-SIMs

 Tel1 = navigator.mozTelephonyManager.phones[index];

Once the telephony object is obtained, the following work remains the same. We can get notified when an incoming call occurs in the specified SIM.

Tel1.addEventListener('incoming');
Tel1.onincoming = function onincoming (evt) {
  incoming = evt.call; };
incoming.answer();

With the extended API, we are able to listen to the 'incoming' event for a newly incoming call, no matter which SIM the call comes from.

navigator.mozTelephonyManager.addEventListener('incoming');

Implementation Details

Proposal: Architecture

Current Architecture

This is the current architecture supporting a single SIM card.

Proposal for Multi-SIMs

With various hardware design, there might be multiple ril-daemon (rild), one rild taking care of one SIM, while it is also possible that a single rild manipulates all the SIMs. To make our architecture flexible enough, we are planning to have 'rilproxy' in charge of sending RIL parcels to the correct rild, no matter how many there are.

Here is a proposal for multi-SIMs.

RIL Implementation

We are proposing to add a new object called 'MSimRadioInterfaceLayer', which takes responsibility of creating RadioInterfaceLayer instances for every SIM, getting worker of each instance and receiving IPC messages. Once it receives the IPC messages, it dispatch the messages to the right RadioInterfaceLayer instance according to the 'subscriptionId' property. Then it is that instance to handle those messages. It is also each instacne's job to send messages to content.

In order to adding MSimRadioInterfaceLayer, we need to modify 'SystemWorkerManager.cpp' to create an instance of MSimRadioInterfaceLayer, instead of what it is doing, i.e. creating an instance of RadioInterfaceLayer.

rilproxy

Message format between rilproxy and rild needs to be revised accordingly.

The single-SIM data format is shown below.

To distingush data stream coming from different rild, we propose the following data format:

Internal API: nsIRILContentHelper.idl

Even we create an instance for a SIM, we might still need to add 『index』, used for connecting a telephony object (phoneIndex) and a specific 『SIM slot』 due to the limits of the IPC mechanism.

• Examples of modifiying the internal API:

void enumerateCalls(in short index,
                    in nsIRILTelephonyCallback callback);
void dial(in short index, in DOMString number);
readonly attribute jsval voicemailNumber; /* {index, number} */

Potential Issues (Bugs we might need to file)

• Array-ize RadioInterfaceLayer: one instance for one SIM slot
• Send parcel to the correct rild: might need to modify ril_worker.js and rilproxy
• Get the number of SIM slots

Discussion

• Q: How do we know how many phone objects should be created in 'navigator.mozTelephonyManager' ?
• A: Number of the sim slots

• Q: How to know default phone?
• A: Binded to a specified sim slot (per hardware design). We should reserve the flexibility that user has a chance to change the default phone at run-time, but note the 『default phone』 determination is another issue.

• Q: How much memory increase if we use two instances to handle 2 SIMs?
• A: According to the information from Bug 802446, the compartment of RadioInterface layer is about 3xx KBytes. But, after removing some fixed size overhead, it is expected 2xxK-increase to add an instance for each SIM. We expect it will add less than 200K for each instance after removing SMS and other stuffs out.