[tarako] last call fail cause is not correctly updated if the call is hung up by user

RESOLVED FIXED in 2.0 S1 (9may)

Status

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: aknow, Assigned: aknow)

Tracking

unspecified
2.0 S1 (9may)
x86_64
Linux
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:1.3T+, b2g-v1.3T verified)

Details

(Whiteboard: [p=1][ETA: 4/29])

Attachments

(2 attachments, 2 obsolete attachments)

Steps.
1. Dial an invalid number (ex: 123) and let it hung up by network
2. The fail cause will be 'badNumberError'
3. Dial any number and hang up the call immediately by ourself.
4. Gecko fetches the fail cause and report it to gaia. In this case, it will also be 'badNumberError'. Thus user will see a weird error prompt showing the number is invalid even the number is correct.

Possible solutions:
1. Modem should update the fail cause.
2. If we know the call is hung up by user, we don't have to fetch the fail cause. It should always be normal call clearing.
Summary: [tarako] last call fail cause is not correctly update if the call is hung up by user → [tarako] last call fail cause is not correctly updated if the call is hung up by user
(In reply to Szu-Yu Chen [:aknow] from comment #0)
> Steps.
> 1. Dial an invalid number (ex: 123) and let it hung up by network
> 2. The fail cause will be 'badNumberError'
> 3. Dial any number and hang up the call immediately by ourself.
> 4. Gecko fetches the fail cause and report it to gaia. In this case, it will
> also be 'badNumberError'. Thus user will see a weird error prompt showing
> the number is invalid even the number is correct.
> 
> Possible solutions:
> 1. Modem should update the fail cause.
> 2. If we know the call is hung up by user, we don't have to fetch the fail
> cause. It should always be normal call clearing.

Option 2 seems okay but even we've hung a call up and even a call is eventually released, we can't be sure that it's our request triggering the consequence. It's also possible that the remote party has hung up a call at almost the same time. Option 2 seems no harm but I think we should first see if anything goes wrong in modem/rild. Why did they report this type of fail cause?
It seems that modem doesn't update the fail cause if the call is hung up by user.
Ex:
After step 4, we make another call and disconnect it from remote normally. Then repeat step 3, we will get 'normalCallClearing' this time.
Sam, I wonder why rild doesn't handle this? Is it possible for you to update a fail cause for this condition?
Flags: needinfo?(sam.hua)
Hi Ken,
RILC get the failure cause from modem. 
I think "2. If we know the call is hung up by user, we don't have to fetch the fail"
maybe be better.
as i know,if network hangups the call, it will send the CALL_DISC_IND to mobile and it contains the disconnect reason, but i don't know modem can get the reason or not if mobile hangup the call
Flags: needinfo?(sam.hua)
I seem over-expect REQUEST_GET_LAST_CALL_FAIL_CAUSE. AOSP [1] takes option II, though our gecko code work well on a device other than tarako.

[1] http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.4.2_r1/com/android/internal/telephony/gsm/GsmCallTracker.java/#590
A little information.

AOSP will not request last_call_fail_cause if disconnect is requested by MO side.

https://github.com/wilfredcool007/framework_base_telephony/blob/master/gsm/GsmConnection.java#L345
Assignee: nobody → szchen
Attachment #8412443 - Flags: review?(htsai)
triage: 1.3T+ for broken feature
blocking-b2g: 1.3T? → 1.3T+
Whiteboard: [p=1][ETA: 4/28]
Target Milestone: --- → 2.0 S1 (9may)
Comment on attachment 8412443 [details] [diff] [review]
Fix fail cuase of local hang up

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

::: dom/system/gonk/ril_worker.js
@@ +1544,5 @@
>        this._removeVoiceCall(call, GECKO_CALL_ERROR_NORMAL_CALL_CLEARING);
>        return;
>      }
>  
> +    call.hangUpLocal = true;

It turns out we also need to set the flag when 'rejectCall.'
Attachment #8412443 - Flags: review?(htsai)
add flag in rejectCall
Attachment #8412443 - Attachment is obsolete: true
Attachment #8412470 - Flags: review?(htsai)
Comment on attachment 8412470 [details] [diff] [review]
#2 Fix fail cuase of local hang up

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

Looks good, thanks~
Attachment #8412470 - Flags: review?(htsai) → review+
I will provide 1.3T patch later. It is rebased on bug 993255.
Whiteboard: [p=1][ETA: 4/28] → [p=1][ETA: 4/29]
https://hg.mozilla.org/mozilla-central/rev/e0d492d43a5e
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Please rebase on 1.3t.
Flags: needinfo?(szchen)
Depends on: 999334
Flags: needinfo?(szchen)
checkin-needed for 1.3T
Please land the patch after bug 999334. Thx.
Flags: needinfo?(szchen)
Keywords: checkin-needed
Keywords: checkin-needed
This issue does not occur in today's Tarako build


1.3t Environmental Variables:
Device: Tarako 1.3t
BuildID: 20140502014001
Gaia: a8e0ff550de08e58e4bf75af3cecf175b9b71e70
Gecko: 71790bf476cb
Version: 28.1
Firmware Version: sp6821
You need to log in before you can comment on or make changes to this bug.