Enpei Reporter
	Description • 11 years ago

When secondary SIM is already in call, there should have protection to avoid user dialing out voice call via primary outgoing call SIM. Currently system still allows user to dial out the call, user can see 2nd call which is connecting on dialer, but the call will still be ended finally. 

* Build Number                
Gaia:     03e6e87c7e1b740e2968bbab675600ead2cca84a
Gecko:    7d81d80a3caee905309f61e5696afaab5b9d4f08
BuildID   20131128093540
Version   28.0a1

* Reproduce Steps
1. Based on my DUT, dialing call to 2nd SIM which is 0986143883.
2. After call is connected, open dialer, press add call button, dial out 0955600532 from call history.

* Expected Result
Suggest to grey out add call button.

* Actual Result
time stamp of fugu_moincall1.txt

User can still press add call and dial out 2nd call which is not going to make it (time stamp of log is 11:03). 2nd call which is connecting is displayed on dialer and this will confuse user(dialing.png). 

This will cause another problem that when hang up 1st connected call while 2nd call is trying to connect, 1st call will still be on dialer displayed as connected with timer counts(11:04, 11/28), unable to end the call until reboot device.

* Occurrence rate
100%

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 3 • 11 years ago

I see two problems here:
1) Do we want to grey out the 'add call +' button when there's a call on the non-primary SIM? I think it's UX's call, and not necessary to v1.3.
2) Why 2nd call is still shown on dialer screen? I glanced over the log. Disconnected event has been dispatched, then dialer should be able to remove the 2nd call. Something wrong here... if the issue exists, it must be 1.3+ for sure.

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 4 • 11 years ago

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #3)
> I see two problems here:
> 1) Do we want to grey out the 'add call +' button when there's a call on the
> non-primary SIM? I think it's UX's call, and not necessary to v1.3.

We'd keep in mind https://bugzilla.mozilla.org/show_bug.cgi?id=926345#c37.

> 2) Why 2nd call is still shown on dialer screen? I glanced over the log.
> Disconnected event has been dispatched, then dialer should be able to remove
> the 2nd call. Something wrong here... if the issue exists, it must be 1.3+
> for sure.

I am taking a look at this.

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 5 • 11 years ago

STR:
1) remote user_1 (number: 0978502192) calls ffos sim_2 (non-primary sim)
2) the call connected
3) use FFOS to make a 2nd call to remote user_2 (number: 0916259153) by primary sim, sim_1.
4) When the 2nd call is 'connecting', remote user_1 hangs up the 1st call

Expected result:
FFOS receives an unsolicited event from rild/modem saying the 1st call is disconnected. FFOS dialer no longer shows the 1st call on screen

Actual result:
FFOS didn't receive unsolicited events to notify that 1st call is off.
The 1st call is always on dialer screen even the 2nd call goes away. And we have no way to clear it unless reboot. 

From the log, we see the last event about the state of 1st call:
============
11-28 15:05:26.816 I/Gecko   (  105): TelephonyProvider: handleCallStateChange: {"state":0,"callIndex":1,"toa":129,"isMpty":false,"isMT":true,"als":0,"isVoice":true,"isVoicePrivacy":false,"number":"0978502192","numberPresentation":0,"name":null,"namePresentation":0,"uusInfo":null,"isOutgoing":false,"isEmergency":false,"isConference":false,"started":1385622326810}
=============
The state remains 'state:0' (connected).

	sam.hua
	Comment 6 • 11 years ago

do u have the radio log?
if not,I will reproduce it and get radio log for it.

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 7 • 11 years ago

(In reply to sam.hua from comment #6)
> do u have the radio log?
> if not,I will reproduce it and get radio log for it.

Sure, will do that right away. Thanks :)

	Enpei Reporter
	Comment 8 • 11 years ago

Update bug for call cannot be ended bug and will file another one for UX design after discussing with UX owner.

STR is the same as comment 5, here is QA expected result:
1st connected call should be ended and removed from dialer.

Actual result:
1st connected call still remains on dialer along with 2nd outgoing call. After 2nd outgoing call is failed and remove from dialer, 1st call is still on dialer counting time.

[DSDS] First connected call(secondary SIM) cannot be ended from dialer UI when trying to dial out call from primary outgoing call SIM.

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 9 • 11 years ago

adb logcat -b radio -b main

	Joe Cheng [:jcheng] (please needinfo)
	Comment 10 • 11 years ago

triage: 1.3+ for comment 8. Ni? UX on expected behavior

	sam.hua
	Comment 11 • 11 years ago

Modem works well
in radio log:
1  AT< +CLCC: 1,1,4,0,0,"0978502192",129             //0978502192 incoming call
   AT< +CLCC: 1,1,0,0,0,"0978502192",129             //call is established
   Channel0: AT< ^DSCI: 1,1,6,0,0,0978502192,129,,16 //0978502192 is ended

2. AT< +CLCC: 1,0,2,0,0,"0916259153",129          //0916259153 is a mo call and in mo call state.
   AT< +CLCC: 1,0,3,0,0,"0916259153",129          //ringing now.
   AT< +CLCC: 1,0,0,0,0,"0916259153",129          //call is established
   AT< ^DSCI: 1,0,6,0,0,0916259153,129,,16        //call is ended

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 12 • 11 years ago

(In reply to sam.hua from comment #11)
> Modem works well
> in radio log:
> 1  AT< +CLCC: 1,1,4,0,0,"0978502192",129             //0978502192 incoming
> call
>    AT< +CLCC: 1,1,0,0,0,"0978502192",129             //call is established
>    Channel0: AT< ^DSCI: 1,1,6,0,0,0978502192,129,,16 //0978502192 is ended
> 

Did modem send event to rild/ffos? FFOS didn't be informed ... 

> 2. AT< +CLCC: 1,0,2,0,0,"0916259153",129          //0916259153 is a mo call
> and in mo call state.
>    AT< +CLCC: 1,0,3,0,0,"0916259153",129          //ringing now.
>    AT< +CLCC: 1,0,0,0,0,"0916259153",129          //call is established
>    AT< ^DSCI: 1,0,6,0,0,0916259153,129,,16        //call is ended

	Ken Chang[:kenkai]
	Comment 13 • 11 years ago

Sam, any suggestion?

	sam.hua
	Comment 14 • 11 years ago

yes. it did
11-28 16:01:06.282 D/AT      (   99): [w] Channel0: AT< ^DSCI: 1,1,6,0,0,0978502192,129,,16
11-28 16:01:06.282 D/RILC    (   99): [w] [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGED 

but i think FFOS get the result of : AT< +CLCC: 1,0,2,0,0,"0916259153",129 and it is for RIL_WORKER[0]

Maybe both radiointerfaces should handle the UNSOL_RESPONSE_CALL_STATE_CHANGED. and check the dial number to avoid this issue.

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 15 • 11 years ago

(In reply to sam.hua from comment #14)
> yes. it did
> 11-28 16:01:06.282 D/AT      (   99): [w] Channel0: AT< ^DSCI:
> 1,1,6,0,0,0978502192,129,,16
> 11-28 16:01:06.282 D/RILC    (   99): [w] [UNSL]<
> UNSOL_RESPONSE_CALL_STATE_CHANGED 
> 
> but i think FFOS get the result of : AT< +CLCC: 1,0,2,0,0,"0916259153",129
> and it is for RIL_WORKER[0]
> 
> Maybe both radiointerfaces should handle the
> UNSOL_RESPONSE_CALL_STATE_CHANGED. and check the dial number to avoid this
> issue.

Sam, thanks for checking. Indeed, from the log, I saw modem sent out UNSOL_RESPONSE_CALL_STATE_CHANGED as you pointed out.

line#13297 11-28 16:01:06.282 D/AT      (   99): [w] Channel0: AT< ^DSCI: 1,1,6,0,0,0978502192,129,,16
line#13298 11-28 16:01:06.282 D/RILC    (   99): [w] [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGED

However, RIL Worker[1] didn't receive UNSOLICITED_RESPONSE_CALL_STATE_CHANGED after line#13297. We were expecting that RIL Worker[1] have received that to correctly update the call "0978502192".

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 16 • 11 years ago

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #15)
> (In reply to sam.hua from comment #14)
> > yes. it did
> > 11-28 16:01:06.282 D/AT      (   99): [w] Channel0: AT< ^DSCI:
> > 1,1,6,0,0,0978502192,129,,16
> > 11-28 16:01:06.282 D/RILC    (   99): [w] [UNSL]<
> > UNSOL_RESPONSE_CALL_STATE_CHANGED 
> > 
> > but i think FFOS get the result of : AT< +CLCC: 1,0,2,0,0,"0916259153",129
> > and it is for RIL_WORKER[0]
> > 
> > Maybe both radiointerfaces should handle the
> > UNSOL_RESPONSE_CALL_STATE_CHANGED. and check the dial number to avoid this
> > issue.
> 
> Sam, thanks for checking. Indeed, from the log, I saw modem sent out
> UNSOL_RESPONSE_CALL_STATE_CHANGED as you pointed out.
> 
> line#13297 11-28 16:01:06.282 D/AT      (   99): [w] Channel0: AT< ^DSCI:
> 1,1,6,0,0,0978502192,129,,16
> line#13298 11-28 16:01:06.282 D/RILC    (   99): [w] [UNSL]<
> UNSOL_RESPONSE_CALL_STATE_CHANGED
> 
> However, RIL Worker[1] didn't receive
> UNSOLICITED_RESPONSE_CALL_STATE_CHANGED after line#13297. We were expecting
> that RIL Worker[1] have received that to correctly update the call
> "0978502192".

Did test again...
Right after the call 0978502192 has been released, I noticed RIL Worker[0] was the one receiving UNSOLICITED_RESPONSE_CALL_STATE_CHANGED instead of the expected RIL Worker[1] :(

Sam, looks modem works well, but I am wondering if you could help check RILC maybe. Thank you,

	sam.hua
	Comment 17 • 11 years ago

Hi.

as u said, rild sent out the UNSOLICITED_RESPONSE_CALL_STATE_CHANGED to RIL_WORKER[0],
but it should be rild1 to send out the UNSOLICITED_RESPONSE_CALL_STATE_CHANGED to RIL_WORKER[1]

I am afraid that modem sent the AT< ^DSCI:1,1,6,0,0,0978502192,129,,16 by wrong at channel .

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 18 • 11 years ago

(In reply to sam.hua from comment #17)
> Hi.
> 
> as u said, rild sent out the UNSOLICITED_RESPONSE_CALL_STATE_CHANGED to
> RIL_WORKER[0],
> but it should be rild1 to send out the
> UNSOLICITED_RESPONSE_CALL_STATE_CHANGED to RIL_WORKER[1]
> 
> I am afraid that modem sent the AT< ^DSCI:1,1,6,0,0,0978502192,129,,16 by
> wrong at channel .

Well, then we would need some help from modem side!

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 19 • 11 years ago

Clearing ni here because the UX discussion has been moved to bug 944303.

	Joe Cheng [:jcheng] (please needinfo)
	Comment 20 • 11 years ago

Steven, this bug requires partner support

	sam.hua
	Comment 21 • 11 years ago

We couldn't reproduce it now, after hold the active call.

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 22 • 11 years ago

(In reply to sam.hua from comment #21)
> We couldn't reproduce it now, after hold the active call.

Hi Sam,

Are you saying that you cannot reproduce this issue after bug 933153 landed?

	sam.hua
	Comment 23 • 11 years ago

Yes,at first, it ends the first call and make the second call,we can reproduce it.
but now it holds the first call and make the second call, we can't reproduce it.

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 24 • 11 years ago

(In reply to sam.hua from comment #23)
> Yes,at first, it ends the first call and make the second call,we can
> reproduce it.
> but now it holds the first call and make the second call, we can't reproduce
> it.

Thanks for the information, Sam.

Hi Enpei,
Per Sam's comment, the issue is somehow resolved by bug 933153. Could you please verify this again? Thanks.

	Enpei Reporter
	Comment 25 • 11 years ago

Bug could not be reproduced on today's build.

Gaia      fbb6ce88ce8b7bd4d2efdb7a4a9f5a3c145f3eab
Gecko     a0bb585098cc89c454fac0297b5ef748d5cab82c
BuildID   20131210063021
Version   28.0a1