959914 - [DSDS] always use the 1st service to make an emergency call when 2 slots are empty

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Dialer, defect)

Description

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Currently, dialer is always using the user preference service to make a call. However, in airplane mode or in the case of 2 sim slots being empty, dialer should always use the 1st service/slot for outgoing calls.

Comment 1

[Hsin-Yi Tsai (she/her) [:hsinyi]]

nominate as 1.3+ because once bug 943215 landed, we have a specific radio control on fugu dsds devices. If we don't have this bug fixed, and if primary is set to 2, the phone becomes crazy when user tries to make a call out.

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Okay, I should correct my comment 0 a little bit:

We should -- always use the 1st slot for outgoing calls *when 2 slots are empty*, i.e. both mobileConnections[0].iccId and mobileConnections[1].iccId are null, even there's a chance that the primary setting is set to 2.

Comment 3

[Enpei]

Hi Hsinyi, 

Sorry for some dumb questions:

1. When there is no SIM, under airplane mode, why can't it dial out with slot 1 channel?

2. When there is no SIM, no airplane mode, device will dial out EC based on primary outgoing call setting, right?

3. When there are 2 SIM, under airplane mode, device will dial out EC based on primary outgoing call setting, right?

4. When there is only one SIM, under airplane mode, device will dial out EC via the SIM, right?

Comment 4

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Enpei from comment #3)
> Hi Hsinyi, 
> 
> Sorry for some dumb questions:
> 
> 1. When there is no SIM, under airplane mode, why can't it dial out with
> slot 1 channel?

Assuming slot 1 you mentioned is the 2nd slot ... 
The restriction is because of hardware/modem implementation.

For fugu, we CANNOT power on a specific slot if there's no SIM card inserted unless it's the hardware default slot, i.e. 1st slot, and both slots are empty.


> 
> 2. When there is no SIM, no airplane mode, device will dial out EC based on
> primary outgoing call setting, right?

No. No matter the device is on airplane mode or not, if there's no SIM card at all, we dial out an emergency call only with 1st slot rather than the primary setting.

> 
> 3. When there are 2 SIM, under airplane mode, device will dial out EC based
> on primary outgoing call setting, right?
> 

Not exactly...
Under airplane mode, some hardware/modem will turn off the power of SIM cards. That means, the symptom we observe makes our phone believe there's no SIM cards (mobileConnection[n].iccId == null). In this case, our dialer needs to choose 1st slot to make a call.

However, if the device is fugu, due to different hardware/modem design, the power of SIM cards won't be turned off even in airplane mode (only radio being off in airplane mode). Then, the symptom we observe (mobileConnections[n].iccId != null) is different from 'no-SIM-card case.' Therefore, dialer should make out a call via the one as the primary setting. 

> 4. When there is only one SIM, under airplane mode, device will dial out EC
> via the SIM, right?

Similar to 3.

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

So, this bug is filed due to hardware-dependent behaviours as below:
1) Radio control
a) fugu dsds: radio of a service/slot could be on only when 1) there's a SIM card inserted 2) the service/slot is the hardware default one (in fugu, it's always the 1st one) and both services/slots have no cards
b) qc devices: no special restriction

2) Airplane mode
a) fugu dsds: even in airplane mode, we can still detect SIM cards if there are any
b) qc devuces: in airplane mode, the cardstate from modem is null. We cannot really tell if there's a card or not.

To abstract the differences among hardware and to make sure at any time an emergency call can be dialed out, comment 2 is a proposal (Proposal#1).

Proposal#2 - dialer doesn't address such cases but SIM manager does. SIM manager always sets 'primary outgoing call' to 1st slot when mobileconnections[0].iccId == null and mobileconnections[1].iccId == null. However as case3 in comment 4, iccId==null doesn't necessarily mean there's no card inserted (at least on qc device). If SIM manager changes the primary setting, user could be surprised once she turns off the airplane mode.

Proposal#3 - make our gaia code hardware-conscious.

I am in favor of #1 because the code could be hardware-dependent and we don't surprise user by automatically changing the primary settings.

CC aknow, Arthur and EJ, who have discussed this as well

Comment 6

[Etienne Segonzac (:etienne)]

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #5)
> I am in favor of #1 because the code could be hardware-dependent and we
> don't surprise user by automatically changing the primary settings.

+1 (and we probably want to update the component of this bug)

Comment 7

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #5)
> So, this bug is filed due to hardware-dependent behaviours as below:
> 1) Radio control
> a) fugu dsds: radio of a service/slot could be on only when 1) there's a SIM
> card inserted 2) the service/slot is the hardware default one (in fugu, it's
> always the 1st one) and both services/slots have no cards
> b) qc devices: no special restriction
> 
> 2) Airplane mode
> a) fugu dsds: even in airplane mode, we can still detect SIM cards if there
> are any
> b) qc devuces: in airplane mode, the cardstate from modem is null. We cannot
> really tell if there's a card or not.
> 
> To abstract the differences among hardware and to make sure at any time an
> emergency call can be dialed out, comment 2 is a proposal (Proposal#1).
> 
> Proposal#2 - dialer doesn't address such cases but SIM manager does. SIM
> manager always sets 'primary outgoing call' to 1st slot when
> mobileconnections[0].iccId == null and mobileconnections[1].iccId == null.
> However as case3 in comment 4, iccId==null doesn't necessarily mean there's
> no card inserted (at least on qc device). If SIM manager changes the primary
> setting, user could be surprised once she turns off the airplane mode.
> 
> Proposal#3 - make our gaia code hardware-conscious.
> 
> I am in favor of #1 because the code could be hardware-dependent and we
                                               ^^^^^^^^^^^^^^^^^^^ Ha, definitely a typo. Should be "hardware-indenpendent" !

> don't surprise user by automatically changing the primary settings.
> 
> CC aknow, Arthur and EJ, who have discussed this as well

Comment 8

[Joe Cheng [:jcheng] (please needinfo)]

hsinyi, it looks like you are the best assginee for this bug. Assign to you for now, please feel free to reassign as needed. thanks

Comment 9

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Joe Cheng [:jcheng] from comment #8)
> hsinyi, it looks like you are the best assginee for this bug. Assign to you
> for now, please feel free to reassign as needed. thanks

I thought the fix should be on gaia/dialer. I'd like to ask for Comms gaia developers' help :)

Comment 10

[Kai-Chih Hu [:khu]]

Looks like this bug also blocks bug 946593 which is also a 1.3+ bug. Can we try to find an owner for this bug? Thank you.

Comment 11

[Joe Cheng [:jcheng] (please needinfo)]

etienne, will you be able to look into this? Thanks

Comment 12

[Etienne Segonzac (:etienne)]

Attachment: Pointer to gaia PR

Here's a patch.

Hsin-Yi just want to double check that this is the changed needed :)

Comment 13

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Comment on attachment 8363589 [details] [review]
Pointer to gaia PR

Think about one case:
slot 1 is empty and slot 2 has a card with pin locked. Now, if SIM manager works well, the defaultServiceId is set to 1 (i.e. slot 2). In this case, for slot 2, conn.voice.emergencyOnly will be true. However, since there's a card on slot 2 (conn.iccId !== null), we should keep using 'defaultServiceId' to make a call out.

f- for this.

Comment 14

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #13)
> Comment on attachment 8363589 [details] [review]
> Pointer to gaia PR
> 
> Think about one case:
> slot 1 is empty and slot 2 has a card with pin locked. Now, if SIM manager
> works well, the defaultServiceId is set to 1 (i.e. slot 2). In this case,
> for slot 2, conn.voice.emergencyOnly will be true. However, since there's a
> card on slot 2 (conn.iccId !== null), we should keep using
> 'defaultServiceId' to make a call out.
> 
> f- for this.

I think the logic would be:

var conn = mozMobileConnections[defautId];
var hasCard = conn.iccId !== null;
var emergencyOnly = conn.voice.emergencyOnly;

if (emergencyOnly && !hasCard) {
  telephony.dial(number, 0);
}

Comment 15

[Etienne Segonzac (:etienne)]

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #14)
> (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #13)
> > Comment on attachment 8363589 [details] [review]
> > Pointer to gaia PR
> > 
> > Think about one case:
> > slot 1 is empty and slot 2 has a card with pin locked. Now, if SIM manager
> > works well, the defaultServiceId is set to 1 (i.e. slot 2). In this case,
> > for slot 2, conn.voice.emergencyOnly will be true. However, since there's a
> > card on slot 2 (conn.iccId !== null), we should keep using
> > 'defaultServiceId' to make a call out.
> > 
> > f- for this.
> 
> I think the logic would be:
> 
> var conn = mozMobileConnections[defautId];
> var hasCard = conn.iccId !== null;
> var emergencyOnly = conn.voice.emergencyOnly;
> 
> if (emergencyOnly && !hasCard) {
>   telephony.dial(number, 0);
> }

Thanks a lot! I get it now :)
Will update the patch today.

Comment 16

[Etienne Segonzac (:etienne)]

Comment on attachment 8363589 [details] [review]
Pointer to gaia PR

v2

Comment 17

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Comment on attachment 8363589 [details] [review]
Pointer to gaia PR

Looks great! :)

Comment 18

[Anthony Ricaud (:rik)]

Comment on attachment 8363589 [details] [review]
Pointer to gaia PR

Can you change the commit message before merging? It doesn't represent what we do now.

Comment 19

[Etienne Segonzac (:etienne)]

https://github.com/mozilla-b2g/gaia/commit/1720aab5d5697e9c77029f15cff6ae343809c228

Comment 20

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 1720aab5d5697e9c77029f15cff6ae343809c228 to:
v1.3: 1318d1612299ba5d86820bbb6a65ae090f3b2fd6