Closed Bug 1113027 Opened 7 years ago Closed 7 years ago

[FFOS7715 v2.1]Can not make outgoing call after dial an emergency call via the second sim

Categories

(Firefox OS Graveyard :: RIL, defect)

x86_64
Linux
defect
Not set
major

Tracking

(blocking-b2g:2.1+, b2g-v2.1 verified, b2g-v2.1S verified, b2g-v2.2 verified)

VERIFIED FIXED
2.2 S3 (9jan)
blocking-b2g 2.1+
Tracking Status
b2g-v2.1 --- verified
b2g-v2.1S --- verified
b2g-v2.2 --- verified

People

(Reporter: arvin.zhang, Assigned: aknow)

References

Details

Attachments

(11 files)

1.91 KB, patch
hsinyi
: review+
Details | Diff | Splinter Review
4.07 KB, patch
hsinyi
: review+
Details | Diff | Splinter Review
2.75 KB, patch
hsinyi
: review+
Details | Diff | Splinter Review
1.30 KB, patch
hsinyi
: review+
Details | Diff | Splinter Review
1.56 KB, patch
aknow
: review+
Details | Diff | Splinter Review
3.52 KB, patch
aknow
: review+
Details | Diff | Splinter Review
2.26 KB, patch
aknow
: review+
Details | Diff | Splinter Review
1.39 KB, patch
aknow
: review+
Details | Diff | Splinter Review
4.90 MB, video/mp4
Details
2.58 MB, video/3gpp
Details
3.26 MB, video/3gpp
Details
Reproduce steps:
1\ Boot the device with two sim cards;
2\ Make an emergency call via sim 2 (dial 112);
3\ Hang up the call after the call-screen displayed;
4\ Cannot make outGoing call now.

Reproduce rate: 100%
Hi Shawn,

The direct cause is that "mozTelephony.activeCall" is not null after the emergency call on sim 2 disconnected and hence gaia will always put the dial request on the callback function of activeCall.onheld. However, there'll no chance to run the new dial request for current activeCall had been released in ril.

The following logs(with the patch[1][2] merged locally) can be used to find out the root-cause:
1) dial 112 via sim 0(the 1st sim)
12-18 14:29:19.980 I/Gecko   (  131): TelephonyService: Dialing emergency 112 via sim 0
12-18 14:29:20.040 I/Gecko   (  131): TelephonyService: Dialing: clientId for emergency call is:0
12-18 14:29:20.190 I/GonkT   (  769): Telephony-->CreateCall: aId=-1300470208,aServiceId=0,aCallIndex=1
12-18 14:29:20.290 I/GonkT   (  131): Telephony-->CreateCall: aId=-1412332352,aServiceId=0,aCallIndex=1
12-18 14:29:20.400 I/GonkT   (  131): Telephony-->CreateCall: aId=-1412306688,aServiceId=0,aCallIndex=1

2) dial 112 via sim 1(the 2nd sim, the same as the step2 in c#1)
12-18 14:29:35.660 I/Gecko   (  131): TelephonyService: Dialing 112 via sim 1
12-18 14:29:35.700 I/Gecko   (  131): TelephonyService: Dialing: clientId for emergency call is:0
12-18 14:29:35.790 I/GonkT   (  769): Telephony-->CreateCall: aId=-1300832832,aServiceId=1,aCallIndex=1
12-18 14:29:35.880 I/GonkT   (  131): Telephony-->CreateCall: aId=-1412283520,aServiceId=0,aCallIndex=1
12-18 14:29:35.880 I/GonkT   (  131): Telephony-->CreateCall: aId=-1412254976,aServiceId=0,aCallIndex=1
12-18 14:29:35.880 I/GonkT   (  769): Telephony-->CreateCall: aId=-1294189632,aServiceId=0,aCallIndex=1
12-18 14:29:36.000 I/GonkT   (  131): Telephony-->CreateCall: aId=-1412254464,aServiceId=0,aCallIndex=1

We can see that there's a mismatch of aServiceId on Telephony call when we use the 2nd sim to make 112 dialing. This might be the result of automatic selecting client for emergency call in TelephonyService:

      if (options.isEmergency) {
        // Automatically select a proper clientId for emergency call.
        aClientId = gRadioInterfaceLayer.getClientIdForEmergencyCall() ;

The clientId returned must be 0 if the 1st sim is available now so that the emergency call will be made via sim 0 rather than the sim user selected. And this leads to the mismatch issue of mozTelephony as well.

Please help check my analysis right or not. BTW, I'm very confused with the reason why we should select a proper clientId for emergency here?

Thanks a lot.


[1] patch on dom/telephony/Telephony.cpp:
     TelephonyCall::Create(this, aId, aServiceId, aCallIndex, aCallState,
                           aEmergency, aConference, aSwitchable, aMergeable);
 
+  LOGX("Telephony-->CreateCall: aId=%d,aServiceId=%d,aCallIndex=%d\n", aId, aServiceId, aCallIndex);

[2] patch on dom/telephony/gonk/TelephonyService.js:
   dial: function(aClientId, aNumber, aIsDialEmergency, aCallback) {
-    if (DEBUG) debug("Dialing " + (aIsDialEmergency ? "emergency " : "") + aNumber);
+    if (DEBUG) debug("Dialing " + (aIsDialEmergency ? "emergency " : "") +
+      aNumber + " via sim " + aClientId);
Flags: needinfo?(sku)
Summary: [FFOS7715 v2.1]Can not make outgoing call after dial an emergency call via sim 2 → [FFOS7715 v2.1]Can not make outgoing call after dial an emergency call via the second sim
Hi Arvin -

Just to clarify, you are testing with the old Dolphin 7715 device, right?

Thanks

Vance
Flags: needinfo?(arvin.zhang)
Hi Vance,

The device based on is 7715ea rather than 7715ga.

Thanks,
Arvin
Flags: needinfo?(arvin.zhang)
Hi Aknow,

Could you please help check the issue based on the analysis of c1 and answer my confusion?

Thank you very much.

Arvin
Flags: needinfo?(szchen)
Hi Arvin:
 Since Aknow will be the proper one to answer the design question, I will clear my ni first. If you still need my help, free feel to ni me again.

Thanks!!
Shawn
Flags: needinfo?(sku)
> The clientId returned must be 0 if the 1st sim is available now so that the
> emergency call will be made via sim 0 rather than the sim user selected. And
> this leads to the mismatch issue of mozTelephony as well.

The mismatch issue is a bug. We will fix it.

> Please help check my analysis right or not. BTW, I'm very confused with the
> reason why we should select a proper clientId for emergency here?

For emergency call, we try our best to make the call successful. In some cases (ex: sim2 only), making the phone call on sim1 may get the failure result. So, we want it smart enough to choose a proper sim to avoid the problem.

One of the resolutions to improve the selection mechanism is to choose user's preference as first priority. Then, retry on other sim if the previous one doesn't work.
Flags: needinfo?(szchen)
(In reply to Szu-Yu Chen [:aknow] from comment #6)
> > The clientId returned must be 0 if the 1st sim is available now so that the
> > emergency call will be made via sim 0 rather than the sim user selected. And
> > this leads to the mismatch issue of mozTelephony as well.
> 
> The mismatch issue is a bug. We will fix it.
> 
> > Please help check my analysis right or not. BTW, I'm very confused with the
> > reason why we should select a proper clientId for emergency here?
> 
> For emergency call, we try our best to make the call successful. In some
> cases (ex: sim2 only), making the phone call on sim1 may get the failure
> result. So, we want it smart enough to choose a proper sim to avoid the
> problem.
> 
> One of the resolutions to improve the selection mechanism is to choose
> user's preference as first priority. Then, retry on other sim if the
> previous one doesn't work.

I see:-)
Thanks very much for your quick reply.
Assignee: nobody → szchen
Hsinyi,

Although making the call on sim1, the call may be created on sim2 if the sim selection mechanism took effect.
So we need clientId in notifyDialCallsuccess() to pass the correct information.

Note: You could refer to comment 1 and comment 6 for more details.
Comment on attachment 8539980 [details] [diff] [review]
Part 1: Should pass clientId to notifyDialCallSuccess (idl)

Review of attachment 8539980 [details] [diff] [review]:
-----------------------------------------------------------------

comment 6 makes sense to me.
Attachment #8539980 - Flags: review?(htsai) → review+
Attachment #8539981 - Flags: review?(htsai) → review+
Attachment #8539982 - Flags: review?(htsai) → review+
Attachment #8539983 - Flags: review?(htsai) → review+
Hello Anshul,

Sorry to let you know that this is a flaw we need to fix. And the fix requires changes on internal interfaces.
Flags: needinfo?(anshulj)
Thanks for letting me know Hsin-Yi, we will make the corresponding change on our side.
Flags: needinfo?(anshulj)
[Blocking Requested - why for this release]:
The issue is reported on v2.1. Without the patch, user cannot make outgoing call after dialing an emergency call via second sim.
blocking-b2g: --- → 2.1?
triage: it's a blocker at least for 2.2. 
needinfo RM to decide whether to take it in 2.1.
Flags: needinfo?(bbajaj)
This should be taken in 2.1.

--
Keven
Status: RESOLVED → REOPENED
blocking-b2g: 2.1? → 2.1+
Resolution: FIXED → ---
Blocks: 1123554
Attachment #8553477 - Attachment description: Part 4: Should pass clientId to notifyDialCallSuccess (ril). r=hsinyi → [2.1] Part 4: Should pass clientId to notifyDialCallSuccess (ril). r=hsinyi
Comment on attachment 8553474 [details] [diff] [review]
[2.1] Part 1: Should pass clientId to notifyDialCallSuccess (idl). r=hsinyi

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 1031239	
User impact if declined: User cannot make outgoing call after dialing an emergency call via second sim.
Testing completed: None
Risk to taking this patch (and alternatives if risky): Low ~ Mid
String or UUID changes made by this patch: interface nsITelephonyDialCallback
Attachment #8553474 - Flags: approval-mozilla-b2g34?
Comment on attachment 8553475 [details] [diff] [review]
[2.1] Part 2: Should pass clientId to notifyDialCallSuccess (dom). r=hsinyi

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 1031239	
User impact if declined: User cannot make outgoing call after dialing an emergency call via second sim.
Testing completed: None
Risk to taking this patch (and alternatives if risky): Low ~ Mid
String or UUID changes made by this patch: None
Attachment #8553475 - Flags: approval-mozilla-b2g34?
Comment on attachment 8553476 [details] [diff] [review]
[2.1] Part 3: Should pass clientId to notifyDialCallSuccess (ipc). r=hsinyi

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 1031239	
User impact if declined: User cannot make outgoing call after dialing an emergency call via second sim.
Testing completed: None
Risk to taking this patch (and alternatives if risky): Low ~ Mid
String or UUID changes made by this patch: None
Attachment #8553476 - Flags: approval-mozilla-b2g34?
Comment on attachment 8553477 [details] [diff] [review]
[2.1] Part 4: Should pass clientId to notifyDialCallSuccess (ril). r=hsinyi

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 1031239	
User impact if declined: User cannot make outgoing call after dialing an emergency call via second sim.
Testing completed: None
Risk to taking this patch (and alternatives if risky): Low ~ Mid
String or UUID changes made by this patch: None
Attachment #8553477 - Flags: approval-mozilla-b2g34?
Flags: needinfo?(bbajaj)
Keywords: verifyme
Comment on attachment 8553474 [details] [diff] [review]
[2.1] Part 1: Should pass clientId to notifyDialCallSuccess (idl). r=hsinyi

requesting verification on-device for 2.1 once this lands.
Attachment #8553474 - Flags: approval-mozilla-b2g34? → approval-mozilla-b2g34+
Attachment #8553475 - Flags: approval-mozilla-b2g34? → approval-mozilla-b2g34+
Attachment #8553476 - Flags: approval-mozilla-b2g34? → approval-mozilla-b2g34+
Attachment #8553477 - Flags: approval-mozilla-b2g34? → approval-mozilla-b2g34+
checkin-needed for 2.1
Keywords: checkin-needed
Is this patch already landed in master? Then I think we only need to mark the bug as Fixed and no need for chekin-needed tag as the approval flags had already been granted. See comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1091790#c58
Attached video video
This problem is verified pass on latest build of Flame2.2
Per Comment#1, I have verified the two case:
1) dial 112 via sim 0(the 1st sim)
2) dial 112 via sim 1(the 2nd sim, the same as the step2 in c#1)
See attachment: Flame2.2_video.MP4
Reproduce rate 0/5

Flame 2.2 build:
Gaia-Rev        0518f4581a0925c0b703d730ef289ab15cbd1216
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/c6aa604a7967
Build-ID        20150126002536
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150126.042138
FW-Date         Mon Jan 26 04:21:49 EST 2015
Bootloader      L1TC000118D0
QA Whiteboard: MGSEI-Triage+
Keywords: verifyme
(In reply to Beatriz Rodríguez [:brg] from comment #32)
> Is this patch already landed in master? Then I think we only need to mark
> the bug as Fixed and no need for chekin-needed tag as the approval flags had
> already been granted. See comment:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1091790#c58

Yes.  It's already landed in master.  Just need to uplift to 2.1
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
This bug has been verified as "Pass" on latest Nightly build of Flame v2.1
STR:
1. Dail an emergency call(112).
2. End the call.
3. Dail a valid number.

Actual result: The outgoing call can be made successfully.
See video:"Verify.3GP"

Device info:
Flame 2.1(Pass):
Build ID               20150614001205
Gaia Revision          f8b848c82d1ed589f7a1eb5cc099830c867ff1d4
Gaia Date              2015-06-08 09:48:23
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/7d767fc15126
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150614.033810
Firmware Date          Sun Jun 14 03:38:22 EDT 2015
Bootloader             L1TC000118D0
Attached video Verify_Pass_2.1s.3gp
This Problem is verified as "pass" on latest build of 2.1S(512mb) by the STR in comment 33.
Actual result: After you hang up the emergency call, device can make outGoing call successfully.
See attachment: Verify_Pass_2.1s.3gp
Rate: 0/10

Device information:
2.1S_512mb (Pass)
Build ID               20150616001203
Gaia Revision          90463896d22b564fdd3202a97ff941e6cdc502ae
Gaia Date              2015-06-08 09:48:45
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/1ead146c2edf
Gecko Version          34.0
Device Name            scx15_sp7715ea
Firmware(Release)      4.4.2
Firmware(Incremental)  122
Firmware Date          Thu Feb  5 12:42:58 CST 2015
Status: RESOLVED → VERIFIED
QA Whiteboard: MGSEI-Triage+ → [MGSEI-Triage+]
You need to log in before you can comment on or make changes to this bug.