Closed
Bug 1000705
Opened 10 years ago
Closed 10 years ago
[tarako] last call fail cause is not correctly updated if the call is hung up by user
Categories
(Firefox OS Graveyard :: RIL, defect)
Tracking
(blocking-b2g:1.3T+, b2g-v1.3T verified)
Tracking | Status | |
---|---|---|
b2g-v1.3T | --- | verified |
People
(Reporter: aknow, Assigned: aknow)
References
Details
(Whiteboard: [p=1][ETA: 4/29])
Attachments
(2 files, 2 obsolete files)
2.09 KB,
patch
|
aknow
:
review+
|
Details | Diff | Splinter Review |
2.20 KB,
patch
|
aknow
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Updated•10 years ago
|
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
Comment 1•10 years ago
|
||
(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?
Assignee | ||
Comment 2•10 years ago
|
||
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.
Comment 3•10 years ago
|
||
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)
Comment 5•10 years ago
|
||
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
Updated•10 years ago
|
blocking-b2g: --- → 1.3T?
status-b2g-v1.3T:
--- → affected
Comment 6•10 years ago
|
||
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 | ||
Updated•10 years ago
|
Assignee: nobody → szchen
Assignee | ||
Comment 7•10 years ago
|
||
Attachment #8412443 -
Flags: review?(htsai)
Assignee | ||
Updated•10 years ago
|
Whiteboard: [p=1][ETA: 4/28]
Target Milestone: --- → 2.0 S1 (9may)
Comment 9•10 years ago
|
||
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)
Assignee | ||
Comment 10•10 years ago
|
||
add flag in rejectCall
Attachment #8412443 -
Attachment is obsolete: true
Attachment #8412470 -
Flags: review?(htsai)
Comment 11•10 years ago
|
||
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+
Assignee | ||
Comment 12•10 years ago
|
||
Attachment #8412470 -
Attachment is obsolete: true
Attachment #8412474 -
Flags: review+
Assignee | ||
Comment 13•10 years ago
|
||
I will provide 1.3T patch later. It is rebased on bug 993255.
Assignee | ||
Updated•10 years ago
|
Whiteboard: [p=1][ETA: 4/28] → [p=1][ETA: 4/29]
Assignee | ||
Comment 14•10 years ago
|
||
checkin-needed for master branch https://tbpl.mozilla.org/?tree=Try&rev=faa565a3b5ec
Keywords: checkin-needed
Comment 15•10 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/e0d492d43a5e
Keywords: checkin-needed
Comment 16•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/e0d492d43a5e
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 18•10 years ago
|
||
Attachment #8413674 -
Flags: review+
Flags: needinfo?(szchen)
Assignee | ||
Comment 19•10 years ago
|
||
checkin-needed for 1.3T Please land the patch after bug 999334. Thx.
Flags: needinfo?(szchen)
Keywords: checkin-needed
Assignee | ||
Updated•10 years ago
|
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.
Description
•