WebAPI/WebTelephony/Multi-SIM

From MozillaWiki
Jump to navigation Jump to search

Multi-SIM Scenario

In the multisim scenario, the phone, the whole device, is using all sim cards that are all on standby. All cards are working separately and they can be connected to different networks simultaneously, like gsm, cdma, etc. Each app should be able to allow user to choose a sim card as the user currently wants. Taking telephony as example, user should be able to choose via which sim card he wants to make a call. User can choose to use a specific sim or simply use the default one. He can call friend A by sim no. 1 and to call friend B by sim no. 2. He is definitely able to receive calls from any sim. Also, among different APIs such as mobile connections and telephony, technically user can set a default sim for 3G data connection and another default sim for telephony voice calls.

In reality, hardware implementation for multi-SIM scenario varies. Some devices may have one antenna while others have multiple. Some devices may have one modem but others have multiple. If the device has one antenna only, then even in multisim scenario, user is uncapable of placing calls with both sim cards at the same time. If the hardware supports multi-antenna as well, then placing calls with both sim cards at the same time works. Neverthless, in fact, though most existing multisim-devices claim they support multi-sim-standby, they automatically disable other sim card while one is in call. If user talks on one sim card and get an incoming call on other, the second call will be redirected to voice mail or user will be unavailable. Very few, but there is, supports the full multi-sim-standby feature.

Proposal: WebTelephony API for Multi-SIM

Currently B2G supports a single SIM architecture. This proposal wants to extend it for supporting multi-SIMs. 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 */

// Calls existing in all the sim cards.
readonly attribute jsval calls;
readonly attribute phoneState;  /* ringtone, incall, idle */
// Array of nsIDOMTelephony. Each service is taking care of one sim card.
readonly attribute jsval services; 
readonly attribute nsIDOMTelephony defaultService;

[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;

// Indicate which SIM card this call belongs to.
readonly attribute unsigned long subscriptionId; /* 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.defaultService.dial()
 navigator.mozTelephonyManager.services[index].dial()

Incoming Call

  • Current B2G (Single SIM)
 Tel1 = navigator.mozTelephony;
  • Multi-SIMs
 Tel1 = navigator.mozTelephonyManager.services[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

WebTelephonyAPI multisim impl.png

Proposal: Architecture

Current Architecture

This is the current architecture supporting a single SIM card. B2G Architecture

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.

Proposal: B2G Architecture 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 right now, 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.

Single-SIM Data Format between rilproxy and rild

To distingush data stream coming from different rild, we propose the following data format: Multi-SIMs Data Format between rilproxy and rild

Two prefixes, id and data size, are appended to the data originally from rild.

  • Id: 0-based identifier of rild, i.e. 0, 1, 2, ...
  • Size: size of the original data sent by rild

Internal API: nsIRILContentHelper.idl

We need to add 『subscription Id』 in every IPC message, 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 unsigned long subscriptionId,
                    in nsIRILTelephonyCallback callback);
void dial(in unsigned long subscriptionId, in DOMString number);
readonly attribute jsval voicemailNumber; /* {subscriptionId, number} */

Bugzilla

  • Get the number of SIM slots
  • Set default sim for each application

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.
Retrieved from "https://wiki.allizom.org/index.php?title=WebAPI/WebTelephony/Multi-SIM&oldid=523956"