926345 - [B2G][User Story] [DSDS] Emergency call on the active SIM

Status: RESOLVED DUPLICATE of bug 1027478

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

Description

[Kai-Chih Hu [:khu]]

As a user, I would like to make an emergency call on the currently active SIM.

Comment 1

[Kai-Chih Hu [:khu]]

Ken, can you help to list engineering bugs? Thanks.

Comment 2

[Ken Chang[:kenkai]]

It is unnecessary to have this user story. Emergency call and normal call should use the same active SIM.

Comment 3

[Kai-Chih Hu [:khu]]

In the user story review meeting today, we all agreed that this should be in v1.3.

Comment 4

[Ken Chang[:kenkai]]

After fixing bug 927764, this bug is also fixed.

Comment 5

[Enpei]

Acceptance criteria from PM:

1) At any given time, user should be able to make an emergency call from the currently active SIM.

2) This should be possible in locked screen as well (check 1.2 for consistency of this)

Comment 6

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

(In reply to Enpei from comment #5)
> Acceptance criteria from PM:
> 
> 1) At any given time, user should be able to make an emergency call from the
> currently active SIM.
> 

I think this acceptance criteria depends on modem support. The question came to my mind is quite similar to bug 926350 comment 2.

Assume SIM1 is the primary one for outgoing calls and SIM2 in in-call/active at the moment...

How could we know which sim card the modem is occupied by? For example, if user is talking to a call incoming from SIM2, could we have any indication from modem that SIM2 is active so that we could make an outgoing call only from SIM2, not the user-specified primary SIM?

If modem won't tell gecko/gaia the above situation, then modem should just make an emergency call no matter which SIM is the currently active one. Dose modem support that?
 
Thank you.

> 2) This should be possible in locked screen as well (check 1.2 for
> consistency of this)

Comment 7

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

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #6)
> (In reply to Enpei from comment #5)
> > Acceptance criteria from PM:
> > 
> > 1) At any given time, user should be able to make an emergency call from the
> > currently active SIM.
> > 
> 
> I think this acceptance criteria depends on modem support. The question came
> to my mind is quite similar to bug 926350 comment 2.
> 
> Assume SIM1 is the primary one for outgoing calls and SIM2 in in-call/active
> at the moment...
> 
> How could we know which sim card the modem is occupied by? For example, if
> user is talking to a call incoming from SIM2, could we have any indication
> from modem that SIM2 is active so that we could make an outgoing call only
> from SIM2, not the user-specified primary SIM?
> 
> If modem won't tell gecko/gaia the above situation, then modem should just
> make an emergency call no matter which SIM is the currently active one. 

no matter which SIM is the currently active one or no matter if the currently active one is the same as the primary one

> Dose modem support that?
>  
> Thank you.
> 
> > 2) This should be possible in locked screen as well (check 1.2 for
> > consistency of this)

Comment 8

[Anshul]

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #6)
> (In reply to Enpei from comment #5)
> > Acceptance criteria from PM:
> > 
> > 1) At any given time, user should be able to make an emergency call from the
> > currently active SIM.
> > 
> 
> I think this acceptance criteria depends on modem support. The question came
> to my mind is quite similar to bug 926350 comment 2.
> 
> Assume SIM1 is the primary one for outgoing calls and SIM2 in in-call/active
> at the moment...
> 
> How could we know which sim card the modem is occupied by? 
Please see my comment on https://bugzilla.mozilla.org/show_bug.cgi?id=926350#c4

For example, if
> user is talking to a call incoming from SIM2, could we have any indication
> from modem that SIM2 is active so that we could make an outgoing call only
> from SIM2, not the user-specified primary SIM?
> 
> If modem won't tell gecko/gaia the above situation, then modem should just
> make an emergency call no matter which SIM is the currently active one. Dose
> modem support that?
Hsin-Yi, for a regular call (non emergency number) if user is in call on SIM2 and SIM 1 is the preferred outgoing subscription, modem can not make a call on SUB1, so in that case we should always make a call on the currently in call subscription. So we do need to make the dialer intelligent enough to provide such information or have an API call into TelephonyProvider to get this information. You can look at MSimDialerActivity.java in code aurora DSDS implementation for reference. 

Given that with the information above we can find out which subscription is in call, we can use the same subscription information for the emergency call. I am going to find out if technically modem is capable of making emergency call on SUB1 if SUB2 is currently in use (I am assuming it would have to drop the call on SUB2 first if all possible).

>  
> Thank you.
> 
> > 2) This should be possible in locked screen as well (check 1.2 for
> > consistency of this)

Comment 9

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

(In reply to Anshul from comment #8)
> (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #6)
> > (In reply to Enpei from comment #5)
> > > Acceptance criteria from PM:
> > > 
> > > 1) At any given time, user should be able to make an emergency call from the
> > > currently active SIM.
> > > 
> > 
> > I think this acceptance criteria depends on modem support. The question came
> > to my mind is quite similar to bug 926350 comment 2.
> > 
> > Assume SIM1 is the primary one for outgoing calls and SIM2 in in-call/active
> > at the moment...
> > 
> > How could we know which sim card the modem is occupied by? 
> Please see my comment on
> https://bugzilla.mozilla.org/show_bug.cgi?id=926350#c4
> 
> For example, if
> > user is talking to a call incoming from SIM2, could we have any indication
> > from modem that SIM2 is active so that we could make an outgoing call only
> > from SIM2, not the user-specified primary SIM?
> > 
> > If modem won't tell gecko/gaia the above situation, then modem should just
> > make an emergency call no matter which SIM is the currently active one. Dose
> > modem support that?
> Hsin-Yi, for a regular call (non emergency number) if user is in call on
> SIM2 and SIM 1 is the preferred outgoing subscription, modem can not make a
> call on SUB1, so in that case we should always make a call on the currently
> in call subscription. So we do need to make the dialer intelligent enough to
> provide such information or have an API call into TelephonyProvider to get
> this information. You can look at MSimDialerActivity.java in code aurora
> DSDS implementation for reference. 

Thanks for the reply, Anshul.

In mozTelephony API, we provide 'serviceId' attribute exposing to TelephonyCall, so dialer has a way to knowing the information. Dialer is able to display that per our UI requirement.

But you remind me that our gecko implementation should take care of updating 'serviceId' as modem might use a different subscription for making an outgoing call.

> 
> Given that with the information above we can find out which subscription is
> in call, we can use the same subscription information for the emergency
> call. 

Sounds good to me. With my comment above, there should be no problem with this criteria.

> I am going to find out if technically modem is capable of making
> emergency call on SUB1 if SUB2 is currently in use (I am assuming it would
> have to drop the call on SUB2 first if all possible).
> 

This also works for this criteria. Waiting for your sequent reply. Thank you!

> >  
> > Thank you.
> > 
> > > 2) This should be possible in locked screen as well (check 1.2 for
> > > consistency of this)

Comment 10

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

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #9)
> (In reply to Anshul from comment #8)
> > Hsin-Yi, for a regular call (non emergency number) if user is in call on
> > SIM2 and SIM 1 is the preferred outgoing subscription, modem can not make a
> > call on SUB1, so in that case we should always make a call on the currently
> > in call subscription. So we do need to make the dialer intelligent enough to
> > provide such information or have an API call into TelephonyProvider to get
> > this information. You can look at MSimDialerActivity.java in code aurora
> > DSDS implementation for reference. 
> 
> Thanks for the reply, Anshul.
> 
> In mozTelephony API, we provide 'serviceId' attribute exposing to
> TelephonyCall, so dialer has a way to knowing the information. Dialer is
> able to display that per our UI requirement.
> 
> But you remind me that our gecko implementation should take care of updating
> 'serviceId' as modem might use a different subscription for making an
> outgoing call.
> 

Oh, sorry Anshul, I am afraid I misunderstand your reply. I'd like to confirm the behaviour of modem.

If user is in call on SIM2, but user requests making another outgoing call on SIM1, how would modem do? Will modem report an error on SIM1? Or modem will simply make a call on SIM2, then ril_worker.js receives unsolicited calls changed event on SIM2, and the original REQUEST_DIAL on SIM1 succeeds?


> > 
> > Given that with the information above we can find out which subscription is
> > in call, we can use the same subscription information for the emergency
> > call. 
>

Regarding 'we' in your context, were you meaning the gaia/gecko or modem?
 
> Sounds good to me. With my comment above, there should be no problem with
> this criteria.
> 

I thought you meant 'modem' when I was saying above ...


> > I am going to find out if technically modem is capable of making
> > emergency call on SUB1 if SUB2 is currently in use (I am assuming it would
> > have to drop the call on SUB2 first if all possible).
> > 
> 
> This also works for this criteria. Waiting for your sequent reply. Thank you!
> 
> > >  
> > > Thank you.
> > > 
> > > > 2) This should be possible in locked screen as well (check 1.2 for
> > > > consistency of this)

Comment 11

[Anshul]

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #10)
> (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #9)
> > (In reply to Anshul from comment #8)
> > > Hsin-Yi, for a regular call (non emergency number) if user is in call on
> > > SIM2 and SIM 1 is the preferred outgoing subscription, modem can not make a
> > > call on SUB1, so in that case we should always make a call on the currently
> > > in call subscription. So we do need to make the dialer intelligent enough to
> > > provide such information or have an API call into TelephonyProvider to get
> > > this information. You can look at MSimDialerActivity.java in code aurora
> > > DSDS implementation for reference. 
> > 
> > Thanks for the reply, Anshul.
> > 
> > In mozTelephony API, we provide 'serviceId' attribute exposing to
> > TelephonyCall, so dialer has a way to knowing the information. Dialer is
> > able to display that per our UI requirement.
> > 
> > But you remind me that our gecko implementation should take care of updating
> > 'serviceId' as modem might use a different subscription for making an
> > outgoing call.
> > 
> 
> Oh, sorry Anshul, I am afraid I misunderstand your reply. I'd like to
> confirm the behaviour of modem.
> 
> If user is in call on SIM2, but user requests making another outgoing call
> on SIM1, how would modem do? Will modem report an error on SIM1? Or modem
> will simply make a call on SIM2, then ril_worker.js receives unsolicited
> calls changed event on SIM2, and the original REQUEST_DIAL on SIM1 succeeds?
> 
> 
> > > 
> > > Given that with the information above we can find out which subscription is
> > > in call, we can use the same subscription information for the emergency
> > > call. 
> >
Hsin-Yi, I am not sure and I can find out but I expect it is going to take a few days to find the right POC. Whether the modem fails the call or drops the existing call and connect the new one the behavior from the end user POV doesn't seem good to me.

From what I can see on Android at codeaurora (Reference implementation) is that if the phone is in call then the dialer always uses the SIM in use rather than the preferred SIM for the outgoing call even for the emergency calls.

> 
> Regarding 'we' in your context, were you meaning the gaia/gecko or modem?
Gecko/gaia :)
>  
> > Sounds good to me. With my comment above, there should be no problem with
> > this criteria.
> > 
> 
> I thought you meant 'modem' when I was saying above ...
> 
> 
> > > I am going to find out if technically modem is capable of making
> > > emergency call on SUB1 if SUB2 is currently in use (I am assuming it would
> > > have to drop the call on SUB2 first if all possible).
> > > 
> > 
> > This also works for this criteria. Waiting for your sequent reply. Thank you!
> > 
> > > >  
> > > > Thank you.
> > > > 
> > > > > 2) This should be possible in locked screen as well (check 1.2 for
> > > > > consistency of this)

Comment 12

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

Summarizing ...

To support this acceptance criteria, there seems the following development options:
1) Dialer needs to be more intelligent: if user is in call with non-primary SIM, the following outgoing calls (emergency call included) needs to be made with that SIM rather than the primary one.

Telephony API supports that. Dialer could check TelephonyCall.serviceId to know if the non-primary SIM is used. If yes, Dialer needs to clearly specify serviceId in telephony.dial(). 

This option requires Comms team's effort.

2) No matter user is in-call or not, Dialer always tries to use the primary SIM to dial out. Instead, Gecko is the one who should be in charge of using the currently active SIM for that outgoing call.

IMHO, this is the worst, and apparently a temporary solution for v1.3. In v1.4, user will always tell Dialer which SIM is going to be used... We don't need this weird behaviour in gecko then.

3) Dialer/Gecko does nothing. Modem does something for this case. Anshul is checking right now, see comment 11. Gecko may need to do something specifically for v1.3 as well ... ...

For me, option 1) makes more sense. I believe this behaviour remains even in v1.4. How does that sound?

Comment 13

[Anshul]

Hsin-Yi I am also a proponent of option #1.

Comment 14

[Anshul]

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #12)
> Summarizing ...
> 
> To support this acceptance criteria, there seems the following development
> options:
> 1) Dialer needs to be more intelligent: if user is in call with non-primary
> SIM, the following outgoing calls (emergency call included) needs to be made
> with that SIM rather than the primary one.
> 
> Telephony API supports that. Dialer could check TelephonyCall.serviceId to
> know if the non-primary SIM is used. If yes, Dialer needs to clearly specify
> serviceId in telephony.dial(). 
> 
> This option requires Comms team's effort.
> 
> 2) No matter user is in-call or not, Dialer always tries to use the primary
> SIM to dial out. Instead, Gecko is the one who should be in charge of using
> the currently active SIM for that outgoing call.
> 
> IMHO, this is the worst, and apparently a temporary solution for v1.3. In
> v1.4, user will always tell Dialer which SIM is going to be used... We don't
> need this weird behaviour in gecko then.
> 
> 3) Dialer/Gecko does nothing. Modem does something for this case. Anshul is
> checking right now, see comment 11. Gecko may need to do something
> specifically for v1.3 as well ... ...
Confirmed that modem will reject the call on SIM 1 if the call is already in progress on SIM2.

> 
> For me, option 1) makes more sense. I believe this behaviour remains even in
> v1.4. How does that sound?

Comment 15

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

(In reply to Anshul from comment #14)
> (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #12)
> > Summarizing ...
> > 
> > To support this acceptance criteria, there seems the following development
> > options:
> > 1) Dialer needs to be more intelligent: if user is in call with non-primary
> > SIM, the following outgoing calls (emergency call included) needs to be made
> > with that SIM rather than the primary one.
> > 
> > Telephony API supports that. Dialer could check TelephonyCall.serviceId to
> > know if the non-primary SIM is used. If yes, Dialer needs to clearly specify
> > serviceId in telephony.dial(). 
> > 
> > This option requires Comms team's effort.
> > 
> > 2) No matter user is in-call or not, Dialer always tries to use the primary
> > SIM to dial out. Instead, Gecko is the one who should be in charge of using
> > the currently active SIM for that outgoing call.
> > 
> > IMHO, this is the worst, and apparently a temporary solution for v1.3. In
> > v1.4, user will always tell Dialer which SIM is going to be used... We don't
> > need this weird behaviour in gecko then.
> > 
> > 3) Dialer/Gecko does nothing. Modem does something for this case. Anshul is
> > checking right now, see comment 11. Gecko may need to do something
> > specifically for v1.3 as well ... ...
> Confirmed that modem will reject the call on SIM 1 if the call is already in
> progress on SIM2.
> 

Thanks, Anshul.

> > 
> > For me, option 1) makes more sense. I believe this behaviour remains even in
> > v1.4. How does that sound?

Comment 16

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

Hi Sandip,

Per our previous discussion, the acceptance criteria could be split into 

AC1.a - If two SIMs are standby, the call can be made from the 'primary' one.
AC1.b - If one SIM, even not the primary one, is in use, i.e. currently active, the call can be made from the currently 'active' SIM.

However, in today's comms team meeting, AC1.b has been challenged as it sort of conflicts DSDS2 (using primary SIM for MO calls). The team suggested not supporting AC1.b in v1.3. If user wants to make a call, the existing call needs to be hung up first.

Comment 17

[Sandip Kamat]

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #16)
> Hi Sandip,
> 
> Per our previous discussion, the acceptance criteria could be split into 
> 
> AC1.a - If two SIMs are standby, the call can be made from the 'primary' one.
> AC1.b - If one SIM, even not the primary one, is in use, i.e. currently
> active, the call can be made from the currently 'active' SIM.
> 
> However, in today's comms team meeting, AC1.b has been challenged as it sort
> of conflicts DSDS2 (using primary SIM for MO calls). The team suggested not
> supporting AC1.b in v1.3. If user wants to make a call, the existing call
> needs to be hung up first.



this is governed by standards (3gpp / regulatory). anshul, what does the standards say?

Comment 18

[Anshul]

Sandip, will try to find some one who can point me to the spec. However the current modem behavior as per AC1.b seems correct to me. Since modem is busy on one SIM there is no possible way it can make a call on another subscription. Hanging up the call automatically on the existing SIM seems wrong from user perspective.

Comment 19

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

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #16)
> Hi Sandip,
> 
> Per our previous discussion, the acceptance criteria could be split into 
> 
> AC1.a - If two SIMs are standby, the call can be made from the 'primary' one.
> AC1.b - If one SIM, even not the primary one, is in use, i.e. currently
> active, the call can be made from the currently 'active' SIM.
> 
> However, in today's comms team meeting, AC1.b has been challenged as it sort
> of conflicts DSDS2 (using primary SIM for MO calls). The team suggested not
> supporting AC1.b in v1.3. If user wants to make a call, the existing call
> needs to be hung up first.

(In reply to Anshul from comment #18)
> Sandip, will try to find some one who can point me to the spec. However the
> current modem behavior as per AC1.b seems correct to me. Since modem is busy
> on one SIM there is no possible way it can make a call on another
> subscription. Hanging up the call automatically on the existing SIM seems
> wrong from user perspective.

Anshul, the last line in my previous comment 16 seems not clear enough. Per the Comms team's opinion, if user wants to make a call in that case, user themselves need to hang up the existing call first.

Comment 20

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

Anshul, wonder if you have found the spec yet? this will help us move forward.thanks

Comment 21

[Anshul]

Joe, modem will not handle the outgoing call on SUB1 if already busy on SUB2. Either user hangs up the existing call or gaia could only allow the second call on the currently uses subscription.

Comment 22

[Kai-Chih Hu [:khu]]

Remove blocking-b2g flag from User Story bugs. Use whiteboard to indicate what FxOS version we target.

Comment 23

[Enpei]

Anyone could make the conclusion? Will active call be dropped? From UX spec, emergency call can be made no matter which SIM is primary SIM.

Comment 24

[Sandip Kamat]

I think hanging up the first call before dialing another is a common UX-level expectation with 1 SIM or multiple SIMs. With 1 SIM, an active call will need to be either ended (or put on hold) before dialing another call. I would propose to go with that experience. User has to hang up (or hold) currently active call and then dial the emergency number. Considering emergency situation, hanging up is the most straightfwd reaction user would have, before dialing 911 or equivalent.

Comment 25

[Enpei]

add moztrap link.

Comment 26

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

(In reply to Sandip Kamat from comment #24)
> I think hanging up the first call before dialing another is a common
> UX-level expectation with 1 SIM or multiple SIMs. With 1 SIM, an active call
> will need to be either ended (or put on hold) before dialing another call. I
> would propose to go with that experience. User has to hang up (or hold)
> currently active call and then dial the emergency number. Considering
> emergency situation, hanging up is the most straightfwd reaction user would
> have, before dialing 911 or equivalent.

The behavior looks fine to me. But please note that if the currently active sim isn't the specified primary sim, then user needs to hang up the call first. Putting that call on hold doesn't work.

Comment 27

[Anshul]

(In reply to Sandip Kamat from comment #24)
> I think hanging up the first call before dialing another is a common
> UX-level expectation with 1 SIM or multiple SIMs. With 1 SIM, an active call
> will need to be either ended (or put on hold) before dialing another call. I
> would propose to go with that experience. User has to hang up (or hold)
> currently active call and then dial the emergency number. Considering
Doesn't it contradict the UX spec "emergency call can be made no matter which SIM is primary SIM". If you are requiring user to hang up the active call then we can not say that emergency calls can be made on any SIM no matter which SIM is primary SIM. Also, are you suggesting that user now needs to remember (in case of emergency) that the call he is on is on SIM2 while SIM1 is primary and so he needs to hangup the call to make an emergency call. While if call is already on SIM1 then he can add an emergency call?

> emergency situation, hanging up is the most straightfwd reaction user would
> have, before dialing 911 or equivalent.
I would still urge to reconsider to allow emergency calls to made on the SIM currently in use and not the primary SIM. Also, being able to conference an existing call with emergency number is a valid use case although not a common one.

Comment 28

[Ken Chang[:kenkai]]

Kevin and Sandip,
   Should we move this user story in 1.4? Since Comms team have marked the related bug,930866, in 1.4?.

Comment 29

[Kai-Chih Hu [:khu]]

I am fine with it, but it is Sandip's call to make the product management related decision.

Comment 30

[Enpei]

Hi Sandip, 

So based on comment 27, which action will be taken when trying to dial emergency call while active SIM is not primary outgoing call SIM? 
1. User has to drop active call first manually.(conflict with UX spec)
2. Emergency call can be made from active SIM subscription even though it's not set as primary outgoing call.

Comment 31

[Sandip Kamat]

(In reply to Enpei from comment #30)
> Hi Sandip, 
> 
> So based on comment 27, which action will be taken when trying to dial
> emergency call while active SIM is not primary outgoing call SIM? 
> 1. User has to drop active call first manually.(conflict with UX spec)
> 2. Emergency call can be made from active SIM subscription even though it's
> not set as primary outgoing call.

Hi Enpei,
Can you pls check the market implementation of devices to see how it is implemented there?

Comment 32

[Sandip Kamat]

(In reply to Anshul from comment #27)
> (In reply to Sandip Kamat from comment #24)
> > I think hanging up the first call before dialing another is a common
> > UX-level expectation with 1 SIM or multiple SIMs. With 1 SIM, an active call
> > will need to be either ended (or put on hold) before dialing another call. I
> > would propose to go with that experience. User has to hang up (or hold)
> > currently active call and then dial the emergency number. Considering
> Doesn't it contradict the UX spec "emergency call can be made no matter
> which SIM is primary SIM". If you are requiring user to hang up the active
> call then we can not say that emergency calls can be made on any SIM no
> matter which SIM is primary SIM. 

Unless you hang up, Won't the digits go as DTMF? (Unless user goes to contacts and dials from there)

> Also, are you suggesting that user now
> needs to remember (in case of emergency) that the call he is on is on SIM2
> while SIM1 is primary and so he needs to hangup the call to make an
> emergency call. While if call is already on SIM1 then he can add an
> emergency call?

I am not suggesting user needs to remember anything. Just hang up and dial 911. The device will decide which SIM it will go on. This is no different from 1 SIM devices, right?

> 
> > emergency situation, hanging up is the most straightfwd reaction user would
> > have, before dialing 911 or equivalent.
> I would still urge to reconsider to allow emergency calls to made on the SIM
> currently in use and not the primary SIM. Also, being able to conference an
> existing call with emergency number is a valid use case although not a
> common one.

I am not sure how much technical feasibility (in 1.3) this has to make an exception for a non-primary SIM to make an emergency call. I will let Engg team comment. But again, see my first question above.

Comment 33

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

(In reply to Sandip Kamat from comment #32)
> (In reply to Anshul from comment #27)
> > (In reply to Sandip Kamat from comment #24)
> > > I think hanging up the first call before dialing another is a common
> > > UX-level expectation with 1 SIM or multiple SIMs. With 1 SIM, an active call
> > > will need to be either ended (or put on hold) before dialing another call. I
> > > would propose to go with that experience. User has to hang up (or hold)
> > > currently active call and then dial the emergency number. Considering
> > Doesn't it contradict the UX spec "emergency call can be made no matter
> > which SIM is primary SIM". If you are requiring user to hang up the active
> > call then we can not say that emergency calls can be made on any SIM no
> > matter which SIM is primary SIM. 
> 
> Unless you hang up, Won't the digits go as DTMF? (Unless user goes to
> contacts and dials from there)
> 

No. FFOS supports making a second call. User can dial out simply through the dialer app.

> > Also, are you suggesting that user now
> > needs to remember (in case of emergency) that the call he is on is on SIM2
> > while SIM1 is primary and so he needs to hangup the call to make an
> > emergency call. While if call is already on SIM1 then he can add an
> > emergency call?
> 
> I am not suggesting user needs to remember anything. Just hang up and dial
> 911. The device will decide which SIM it will go on. This is no different
> from 1 SIM devices, right?
> 

Sandip's idea also makes sense to me.

> > 
> > > emergency situation, hanging up is the most straightfwd reaction user would
> > > have, before dialing 911 or equivalent.
> > I would still urge to reconsider to allow emergency calls to made on the SIM
> > currently in use and not the primary SIM. Also, being able to conference an
> > existing call with emergency number is a valid use case although not a
> > common one.
> 
> I am not sure how much technical feasibility (in 1.3) this has to make an
> exception for a non-primary SIM to make an emergency call. I will let Engg
> team comment. But again, see my first question above.

Please see my comment 12 (item1) -- some gaia work needed.

Dialer needs to be more intelligent: if user is in call with non-primary SIM, the following outgoing calls (emergency call included) needs to be made with that SIM rather than the primary one.

Telephony API supports that. Dialer could check TelephonyCall.serviceId to know if the non-primary SIM is used. If yes, Dialer needs to clearly specify serviceId in telephony.dial().

Comment 34

[Enpei]

(In reply to Sandip Kamat from comment #31)
> (In reply to Enpei from comment #30)
> > Hi Sandip, 
> > 
> > So based on comment 27, which action will be taken when trying to dial
> > emergency call while active SIM is not primary outgoing call SIM? 
> > 1. User has to drop active call first manually.(conflict with UX spec)
> > 2. Emergency call can be made from active SIM subscription even though it's
> > not set as primary outgoing call.
> 
> Hi Enpei,
> Can you pls check the market implementation of devices to see how it is
> implemented there?

Hi Sandip,

There are SIM 1 and SIM 2 dial keys on dailer of reference phone. It will only allow user to use the dial key of same subscription as active SIM. That means user can only dial out emergency call with current active SIM. I cannot make calls with different SIM when one is on call already.

Comment 35

[Sandip Kamat]

(In reply to Enpei from comment #34)
> (In reply to Sandip Kamat from comment #31)
> > (In reply to Enpei from comment #30)
> > > Hi Sandip, 
> > > 
> > > So based on comment 27, which action will be taken when trying to dial
> > > emergency call while active SIM is not primary outgoing call SIM? 
> > > 1. User has to drop active call first manually.(conflict with UX spec)
> > > 2. Emergency call can be made from active SIM subscription even though it's
> > > not set as primary outgoing call.
> > 
> > Hi Enpei,
> > Can you pls check the market implementation of devices to see how it is
> > implemented there?
> 
> Hi Sandip,
> 
> There are SIM 1 and SIM 2 dial keys on dailer of reference phone. It will
> only allow user to use the dial key of same subscription as active SIM. That
> means user can only dial out emergency call with current active SIM. I
> cannot make calls with different SIM when one is on call already.

so do you need to hang up the active call before dialing emergency?

Comment 36

[Enpei]

In reply to Sandip Kamat from comment #35)
> > Hi Sandip,
> > 
> > There are SIM 1 and SIM 2 dial keys on dailer of reference phone. It will
> > only allow user to use the dial key of same subscription as active SIM. That
> > means user can only dial out emergency call with current active SIM. I
> > cannot make calls with different SIM when one is on call already.
> 
> so do you need to hang up the active call before dialing emergency?

No. It's like add call function in current single SIM case. Current active call will be put on hold after dialing out emergency call.

Comment 37

[Sandip Kamat]

> > I am not sure how much technical feasibility (in 1.3) this has to make an
> > exception for a non-primary SIM to make an emergency call. I will let Engg
> > team comment. But again, see my first question above.
> 
> Please see my comment 12 (item1) -- some gaia work needed.
> 
> Dialer needs to be more intelligent: if user is in call with non-primary
> SIM, the following outgoing calls (emergency call included) needs to be made
> with that SIM rather than the primary one.
> 
> Telephony API supports that. Dialer could check TelephonyCall.serviceId to
> know if the non-primary SIM is used. If yes, Dialer needs to clearly specify
> serviceId in telephony.dial().

OK, Hsin-Yi - I think this looks the same as the market implementation that Enpei confirmed, Let's proceed with this then.

Comment 38

[Anshul]

Enpei/Hsin-yi, could either of you please summarize the agreed behavior for the emergency calls and the voice calls?

Comment 39

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

(In reply to Anshul from comment #38)
> Enpei/Hsin-yi, could either of you please summarize the agreed behavior for
> the emergency calls and the voice calls?

According to the previous comment, I believe comment 37 is the agreed behavior. That is, user doesn't need to hang up the current call before dialing the 2nd (emergency) call. However, I think this should be product manager's call. Asking Sandip for final confirmation. Thanks!

Comment 40

[Jean Gong :jgong]

Update whiteboard tag to follow format [ucid:{id}, {release}:p{1,2}, ft:{team-id}]

Comment 41

[Ken Chang[:kenkai]]

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #39)
I would say Sandip had confirmed in comment 37 for this final decision. Let's do it. Thanks.

Comment 42

[Ken Chang[:kenkai]]

Wilfred, This user story has been discussed for a long time and Comms app team is supposed to implement this. However, it is too late to confirm the implementation details. I wonder if we should move this user story to 1.4?

Comment 43

[Wilfred Mathanaraj [:WDM]]

Can we confirm that in v1.3 I can make an emergency call via the primary SIM? 

If this is implemented then I dont think there is a need to handle putting calls on hold or automatically dropping calls to allow emergency call. In any normal emergency situation a user would not be putting on hold when he is in urgent need to make a emergency call.

Comment 44

[Ken Chang[:kenkai]]

Sandip, do you agree Comment 43?

Comment 45

[Enpei]

(In reply to Wilfred Mathanaraj [:WDM] from comment #43)
> Can we confirm that in v1.3 I can make an emergency call via the primary
> SIM? 
> 
> If this is implemented then I dont think there is a need to handle putting
> calls on hold or automatically dropping calls to allow emergency call. In
> any normal emergency situation a user would not be putting on hold when he
> is in urgent need to make a emergency call.

Hi Sandip, I've tested basic emergency call testing with primary SIM and even for put on hold case. It works now. But the user story here is for a special case that when active call is not primary outgoing SIM, that case is failed now and which is this user story is about, thanks.

Comment 46

[Sandip Kamat]

Hi Ken and Enpei: I and Wilfred discussed before he put the comment 43, so I agree there.


Enpei: when you say it fails, what happens exactly?

Comment 47

[Enpei]

(In reply to Sandip Kamat from comment #46)
> Hi Ken and Enpei: I and Wilfred discussed before he put the comment 43, so I
> agree there.
> 
> 
> Enpei: when you say it fails, what happens exactly?

Hi Sandip, this user story is not ready, so now if secondary SIM is active, and trying to add call and dial emergency call will fail. You will see Emergency call dialing, but in the end it will be ended. 

There is another bug that might be contrary to this user story. If user wants to dial out non-emergency call in same situation, the call should not be dialed out, that's bug 944303. So for this user story, we have to consider both cases.

Comment 48

[Kai-Chih Hu [:khu]]

Looks like we are still trying to clarify the user story. Can we move to 1.4?

Comment 49

[Sandip Kamat]

(In reply to Enpei from comment #47)
> (In reply to Sandip Kamat from comment #46)
> > Hi Ken and Enpei: I and Wilfred discussed before he put the comment 43, so I
> > agree there.
> > 
> > 
> > Enpei: when you say it fails, what happens exactly?
> 
> Hi Sandip, this user story is not ready, so now if secondary SIM is active,
> and trying to add call and dial emergency call will fail. You will see
> Emergency call dialing, but in the end it will be ended. 
> 

OK, that simply means that this user story is not working. This needs to be fixed as emergency calls are regulatory requirements. Agreed behavior already is in comment #37.

Comment 50

[Chris]

Sandip,

Has a decision be made on whether to fix this on 1.3 or move it to release 1.4?

Much appreciated,
Chris

Comment 51

[Ken Chang[:kenkai]]

(In reply to Chris from comment #50)
> Sandip,
> 
> Has a decision be made on whether to fix this on 1.3 or move it to release
> 1.4?
Sandip, this bug is supposed to be moved to 1.4. Right?

Comment 52

[Sandip Kamat]

(In reply to Ken Chang[:ken] from comment #51)
> (In reply to Chris from comment #50)
> > Sandip,
> > 
> > Has a decision be made on whether to fix this on 1.3 or move it to release
> > 1.4?
> Sandip, this bug is supposed to be moved to 1.4. Right?

No, pls refer to comment 37 (agreed behavior), and comment 42 (I and Wilfred recommendation). Unfortunately we can't push it out if 1.3 can be a launchable release.

Comment 53

[Sandip Kamat]

OK, after reviewing with several teams this week, here is what I suggest:

1. Let's use this user story for tracking "hang up the current call and dial emergency call" use case if a call is active on any SIM. (This part currently works with 1.3)

2. If a user is in a call on SIM2 (non-primary SIM), and he/she needs to make an emergency call (and does not hang up, just uses "add call"), then the emergency call needs to go through on SIM2 as well. This part can move to 1.4 and has to be done per the new UX implementation planned in 1.4. 

Wilfred, I suggest you create a new user story for #2 in release 1.4. Thx

Comment 54

[Enpei]

Hi Wilfred, could you create or link this bug to DSDS v1.4 meta bug 942446? Thank you.

Comment 55

[Wilfred Mathanaraj [:WDM]]

as discussed on the email thread what we want to do is:

if a call is in progress, all call buttons will not respect the preferred SIM setting (SIM1, SIM2, always ask). 
Instead, call buttons will display (and use) the SIM used by the call in progress. And call log will go to the Dialer instead of dialing directly (to inform the user).

Comment 56

[Anthony Ricaud (:rik)]

"And call log will go to the Dialer instead of dialing directly (to inform the user)." This is only if we implement bug 920011.