[Version Info] Gaia: 2d870100a945272824f8e42a8c52aac095fe907e B-D 2013-09-11 04:59:20 Gecko: 46c335b301fdb32f47e58c665190ffc41522ae00 BuildID 20130911062051 Version 26.0a1 * Symptom: 1. The first call is still on hold even 2nd incoming call is rejected on DUT, and the call is connected in 2nd incoming call. * Reproduce Steps 1. Make a call to other device or MT call to DUT. 2. MT a second call to DUT. 3. Reject second incoming call. * Actual results: The first call is still on hold even 2nd incoming call is rejected on DUT, and the call is connected in 2nd incoming call. * Expected results: 1. Incoming call message will be off and back to previous caller information page. 2. First call is not on hold

(In reply to hlu from comment #0) > Created attachment 802784 [details] > logcat.txt > > [Version Info] > Gaia: 2d870100a945272824f8e42a8c52aac095fe907e > B-D 2013-09-11 04:59:20 > Gecko: 46c335b301fdb32f47e58c665190ffc41522ae00 > BuildID 20130911062051 > Version 26.0a1 > > * Symptom: > 1. The first call is still on hold even 2nd incoming call is rejected on > DUT, and the call is connected in 2nd incoming call. > > * Reproduce Steps > 1. Make a call to other device or MT call to DUT. > 2. MT a second call to DUT. > 3. Reject second incoming call. > > * Actual results: > The first call is still on hold even 2nd incoming call is rejected on DUT, > and the call is connected in 2nd incoming call. > > * Expected results: > 1. Incoming call message will be off and back to previous caller information > page. > 2. First call is not on hold The log doesn't contain RIL debug messages. Please kindly help enable the ril debugger and attach a log with debug messages. Thank you. Instructions to enable ril messages: 1. make sure RIL debug configuration is enabled. 1.1 adb pull /system/b2g/defaults/pref/user.js /tmp 1.2 Modify the value of ril.debugging.enabled to true. pref("ril.debugging.enabled", true); 1.3 adb remount 1.4 adb push /tmp/user.js /system/b2g/defaults/pref/ 1.5 adb reboot

Upload the log file with RIL log.

I quickly checked the RIL log. I expected to see 'hangup' in the log but I didn't. However, I saw 'holdCall' after cdmaCallWaiting notification had been sent out. Wondering whether it's a gaia issue. Gabriele, any thoughts? Thank you.

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #3) > I quickly checked the RIL log. I expected to see 'hangup' in the log but I > didn't. However, I saw 'holdCall' after cdmaCallWaiting notification had > been sent out. Wondering whether it's a gaia issue. > > Gabriele, any thoughts? Thank you. Sounds like a problem on the Gaia side. In this scenario the dialer shouldn't send anything to the RIL because the second call cannot be rejected, i.e. we should just hide the incoming call screen and not invoke 'holdCall'. I'll double-check the code.

Dear all, I've updated title for the issue. The issue is that when 2nd call is incoming

Dear all, I've updated title for the issue. The issue is that when 2nd call is incoming, press end button(not "ignore call" button) should end 1st call. But now it is just like hold key to hold 1st call. But this is just for current UI, we also have another bug 915081 which means that UI will change again. By the new UI is ready, end key will going to end 2nd incoming call. So please check if we should still keep this issue or track with 915081 first.

(In reply to Enpei from comment #6) > I've updated title for the issue. The issue is that when 2nd call is > incoming, press end button(not "ignore call" button) should end 1st call. > But now it is just like hold key to hold 1st call. I see what the problem is. This invokes the end-and-answer functionality in the dialer but since in CDMA call waiting mode we cannot end the first call it behaves as if we did an hold-and-answer. > But this is just for current UI, we also have another bug 915081 which means > that UI will change again. By the new UI is ready, end key will going to end > 2nd incoming call. So please check if we should still keep this issue or > track with 915081 first. There's two way to fix this. A quick fix would be to make end-and-answer ignore the second incoming call as the new UI would do. The complete solution is to implement the UI in bug 915081 but that will require a significant amount of time so depending on our timeline we might want to go for the quick fix first.

add bug 915081 since this may change current UI design.

Agreed that if bug 915081 is fixed, this will be fixed. Re-opened if it's needed.