Closed Bug 1042484 Opened 10 years ago Closed 7 years ago

[dolphin][flame] wrong message was shown after the mo call was not received by another user.

Categories

(Firefox OS Graveyard :: Gaia::Dialer, defect)

Other
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected)

RESOLVED WONTFIX
Tracking Status
b2g-v1.4 --- affected
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected

People

(Reporter: angelc04, Unassigned)

References

Details

(Whiteboard: [sprd335450][planned-sprint c=])

Attachments

(2 files, 2 obsolete files)

Steps to reproduce: 1) Make Mo call 2) MO call was not answered(remote called user doesn't do anything) 3) Wait until MO call end automatically --> FFOS shows "Cannot make a call. If you already dialing, please hang up first". (Actually, there's no need to give any alert to user on the case.) Both Dolphin and Flame v1.4 has this problem. Test build ------------------------------------------------------------------------- Gaia 621d152f89347c79619aa909ad62cc2ac9d3ab5b Gecko https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/83b7be7fb33f BuildID 20140720160206 Version 30.0 ro.build.version.incremental=109 ro.build.date=Mon Jun 16 16:51:29 CST 2014 B1TC00011220
Whiteboard: [sprd335450]
From bug 846403, we should tell the user that the call failed. However, I don't think it's necessary to give user any alert info for the scene. More importantly, the fail cause of the case we got is 'UnspecifiedError' rather than 'NoUserRespondingError'[1]. This seems to be very confusing with the fail cause number '19'. Anthony, could you please help check it? Thanks. ---------------------------------------------- [1] Analysis result of the log file: 07-18 23:43:06.520 D/use-Rlog/RLOG-AT( 124): [w] Channel3: AT< ^DSCI: 1,0,6,0,0,15222696199,129,,19 07-18 23:43:06.520 D/use-Rlog/RLOG-RILC( 124): [w] [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGED 07-18 23:43:06.540 D/use-Rlog/RLOG-AT( 124): [w] Channel3: AT< NO ANSWER 07-18 23:43:06.540 D/use-Rlog/RLOG-AT( 124): [w] Channel3: AT< +SIND: 6,1,19 07-18 23:43:06.540 D/use-Rlog/RLOG-AT( 124): [w] Channel3: AT< ^CEND: 1,,104,19 07-18 23:43:06.540 D/use-Rlog/RLOG-RIL( 124): [w] The last call fail cause: 19 07-18 23:43:06.620 I/Gecko ( 112): RIL Worker: [1] Handling parcel as REQUEST_LAST_CALL_FAIL_CAUSE 07-18 23:43:06.620 I/Gecko ( 112): RIL Worker: Next parcel size unknown, going to sleep. 07-18 23:43:06.620 I/Gecko ( 112): -*- RadioInterface[1]: Received message from worker: {"rilMessageType":"callDisconnected","call":{"state":3,"callIndex":1,"toa":129,"isMpty":false,"isMT":false,"als":0,"isVoice":true,"isVoicePrivacy":false,"number":"15222696199","numberPresentation":0,"name":null,"namePresentation":0,"uusInfo":null,"isEmergency":false,"isOutgoing":true,"isConference":false,"failCause":"UnspecifiedError"},"rilMessageClientId":1}
Flags: needinfo?(anthony)
(In reply to helloarvin from comment #1) > From bug 846403, we should tell the user that the call failed. > > However, I don't think it's necessary to give user any alert info for the > scene. More importantly, the fail cause of the case we got is > 'UnspecifiedError' rather than 'NoUserRespondingError'[1]. This seems to be > very confusing with the fail cause number '19'. > > Anthony, could you please help check it? > > Thanks. > > ---------------------------------------------- > [1] Analysis result of the log file: > > 07-18 23:43:06.520 D/use-Rlog/RLOG-AT( 124): [w] Channel3: AT< ^DSCI: > 1,0,6,0,0,15222696199,129,,19 > 07-18 23:43:06.520 D/use-Rlog/RLOG-RILC( 124): [w] [UNSL]< > UNSOL_RESPONSE_CALL_STATE_CHANGED > > 07-18 23:43:06.540 D/use-Rlog/RLOG-AT( 124): [w] Channel3: AT< NO ANSWER > 07-18 23:43:06.540 D/use-Rlog/RLOG-AT( 124): [w] Channel3: AT< +SIND: 6,1,19 > 07-18 23:43:06.540 D/use-Rlog/RLOG-AT( 124): [w] Channel3: AT< ^CEND: > 1,,104,19 > 07-18 23:43:06.540 D/use-Rlog/RLOG-RIL( 124): [w] The last call fail cause: > 19 > > 07-18 23:43:06.620 I/Gecko ( 112): RIL Worker: [1] Handling parcel as > REQUEST_LAST_CALL_FAIL_CAUSE > 07-18 23:43:06.620 I/Gecko ( 112): RIL Worker: Next parcel size unknown, > going to sleep. > 07-18 23:43:06.620 I/Gecko ( 112): -*- RadioInterface[1]: Received > message from worker: > {"rilMessageType":"callDisconnected","call":{"state":3,"callIndex":1,"toa": > 129,"isMpty":false,"isMT":false,"als":0,"isVoice":true,"isVoicePrivacy": > false,"number":"15222696199","numberPresentation":0,"name":null, > "namePresentation":0,"uusInfo":null,"isEmergency":false,"isOutgoing":true, > "isConference":false,"failCause":"UnspecifiedError"},"rilMessageClientId":1} Hi Arvin, According to your snippet, modem seemed reply the fail cause code 19. However, what gecko reported was 0xfff (UnspecifiedError). I'd like to see if something went wrong b/w rild and gecko. Could you please attach a full log? Thank you.
Flags: needinfo?(arvin.zhang)
Attached file log-for-calling-failure.zip (deleted) —
Hi Hsin-Yi, Please check the log file and help find out the reason, thanks. ----------------------------------------------------------------------- 07-24 08:24:02.584 109 109 I Gecko : TelephonyProvider: Dialing 15222696199 07-24 08:25:08.884 109 482 I Gecko : RIL Worker: [0] Handling parcel as REQUEST_LAST_CALL_FAIL_CAUSE 07-24 08:25:08.884 109 109 I Gecko : -*- RadioInterface[0]: Received message from worker: {"rilMessageType":"callDisconnected","call":{"state":3,"callIndex":1,"toa":129,"isMpty":false,"isMT":false,"als":0,"isVoice":true,"isVoicePrivacy":false,"number":"15222696199","numberPresentation":0,"name":null,"namePresentation":0,"uusInfo":null,"isEmergency":false,"isOutgoing":true,"isConference":false,"failCause":"UnspecifiedError"},"rilMessageClientId":0} 07-24 08:25:08.884 109 109 I Gecko : TelephonyProvider: handleCallDisconnected: {"state":3,"callIndex":1,"toa":129,"isMpty":false,"isMT":false,"als":0,"isVoice":true,"isVoicePrivacy":false,"number":"15222696199","numberPresentation":0,"name":null,"namePresentation":0,"uusInfo":null,"isEmergency":false,"isOutgoing":true,"isConference":false,"failCause":"UnspecifiedError"}
Flags: needinfo?(arvin.zhang)
Hi Arvin, Seems something wrong in rild. Please see analysis below, thanks! === 0-radio-08-23-14.log === 07-24 08:25:08.844 134 195 D use-Rlog/RLOG-AT: [w] Channel0: AT< ^DSCI: 1,0,6,0,0,15222696199,129,,19 07-24 08:25:08.844 134 195 D use-Rlog/RLOG-RILC: [w] [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGED 07-24 08:25:08.854 134 195 D use-Rlog/RLOG-AT: [w] Channel0: AT< NO ANSWER 07-24 08:25:08.854 134 195 D use-Rlog/RLOG-AT: [w] Channel0: AT< +SIND: 6,1,19 07-24 08:25:08.854 134 195 D use-Rlog/RLOG-AT: [w] Channel0: AT< ^CEND: 1,,104,19 07-24 08:25:08.854 134 195 D use-Rlog/RLOG-RIL: [w] The last call fail cause: 19 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cause: 19 07-24 08:25:08.874 134 557 D use-Rlog/RLOG-RILC: [w] PCB request code 18 token 118 07-24 08:25:08.874 134 557 D use-Rlog/RLOG-RILC: [w] [0118]> LAST_CALL_FAIL_CAUSE 07-24 08:25:08.874 134 557 D use-Rlog/RLOG-RIL: [w] onRequest: LAST_CALL_FAIL_CAUSE sState=4 07-24 08:25:08.874 134 557 D use-Rlog/RLOG-RIL: [w] channel1 state: '0' 07-24 08:25:08.874 134 557 D use-Rlog/RLOG-RIL: [w] get Channel ID '1' 07-24 08:25:08.874 134 557 D use-Rlog/RLOG-RILC: [w] [0118]< LAST_CALL_FAIL_CAUSE {65535} ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ but here: 65535 === 0-main-08-23-14.log === 07-24 08:25:08.874 109 482 I Gecko : RIL Worker: [0] New outgoing parcel of type 18 07-24 08:25:08.874 109 482 I Gecko : RIL Worker: Outgoing parcel: 0,0,0,8,18,0,0,0,118,0,0,0 07-24 08:25:08.884 109 482 I Gecko : RIL Worker: Next parcel size unknown, going to sleep. 07-24 08:25:08.884 109 482 I Gecko : RIL Worker: Received 24 bytes. 07-24 08:25:08.884 109 482 I Gecko : RIL Worker: Already read 0 07-24 08:25:08.884 109 482 I Gecko : RIL Worker: New incoming parcel of size 20 07-24 08:25:08.884 109 482 I Gecko : RIL Worker: Parcel (size 20): 0,0,0,0,118,0,0,0,0,0,0,0,1,0,0,0,255,255,0,0 ^^^^^^^^^^^ what gecko received from rild is also 65535 07-24 08:25:08.884 109 482 I Gecko : RIL Worker: We have at least one complete parcel. 07-24 08:25:08.884 109 482 I Gecko : RIL Worker: [0] Solicited response for request type 18, token 118, error 0 07-24 08:25:08.884 109 482 I Gecko : RIL Worker: [0] Handling parcel as REQUEST_LAST_CALL_FAIL_CAUSE 07-24 08:25:08.884 109 109 I Gecko : -*- RadioInterface[0]: Received message from worker: {"rilMessageType":"callDisconnected","call":{"state":3,"callIndex":1,"toa":129,"isMpty":false,"isMT":false,"als":0,"isVoice":true,"isVoicePrivacy":false,"number":"15222696199","numberPresentation":0,"name":null,"namePresentation":0,"uusInfo":null,"isEmergency":false,"isOutgoing":true,"isConference":false,"failCause":"UnspecifiedError"},"rilMessageClientId":0} 07-24 08:25:08.884 109 109 I Gecko : TelephonyProvider: handleCallDisconnected: {"state":3,"callIndex":1,"toa":129,"isMpty":false,"isMT":false,"als":0,"isVoice":true,"isVoicePrivacy":false,"number":"15222696199","numberPresentation":0,"name":null,"namePresentation":0,"uusInfo":null,"isEmergency":false,"isOutgoing":true,"isConference":false,"failCause":"UnspecifiedError"}
Flags: needinfo?(arvin.zhang)
One more thing to mention: still need revision on Dialer even gecko reports "NoUserRespondingError" to gaia as Dialer doesn't recognize this type now.
Hi Hsin-Yi, Thanks for your analysis and kindly reminder. I will ask our RIL colleague for help check the point. Besides, I wonder why the issue also exists on flame? Does the same RIL error exist on it? Could you please help have a check, thanks?
Flags: needinfo?(arvin.zhang)
(In reply to helloarvin from comment #6) > Hi Hsin-Yi, > > Thanks for your analysis and kindly reminder. > > I will ask our RIL colleague for help check the point. > > Besides, I wonder why the issue also exists on flame? Does the same RIL > error exist on it? > Could you please help have a check, thanks? Hey, sorry that we don't support mozril on flame so I might not be able to help. However, my guess is as comment 5 -- Dialer doesn't recognize the type "NoUserRespondingError."
Yeah, Got it. Thank you very much.
Thanks Hsin-Yi for the investigation. That's true, Dialer is not recognizing this error yet. Should we turn this into a Dialer bug then? (since the other issue seems like a vendor issue)
Flags: needinfo?(anthony)
(In reply to Anthony Ricaud (:rik) from comment #9) > Thanks Hsin-Yi for the investigation. That's true, Dialer is not recognizing > this error yet. Should we turn this into a Dialer bug then? (since the other > issue seems like a vendor issue) Sounds good! :P
Component: RIL → Gaia::Dialer
Hi guys, I have run some tests around this issue using a Flame KK 2.2 build (Gecko-26c0b8d.Gaia-dfb0ab3) and these are the results: 1. Calling from the Flame to another Firefox OS mobile phone: 1.1. No answering machine enabled on the called device: 1.1.1. Everything works as expected if I leave the call ringing and I do not take it. Both calls are ended on each one of devices. No error message shown. 1.1.2. Everything works as expected if I intentionally hang up the call from the called Firefox OS device: I get the "number is currently busy" message and notification. 1.2. Answering machine enabled on the called device: 1.2.1. Everything works as expected if I leave the call ringing and I do not take it. On the called phone the call is ended and the calling one is redirected to the answering machine. 1.2.2. Everything works as expected if I intentionally hang up the call. On the called phone the call is ended and the calling one is redirected to the answering machine. 2. Calling from the Flame to an Android mobile phone: 2.1. No answering machine enabled on the called device: 2.1.1. If I leave the call ringing and I do not take it, I get the "cannot make a call if you are already dialing please hang up first" message as mentioned in comment 1. 2.1.2. If I intentionally hang up the call from the called Android device, I get the "number is currently busy" message and notification. 2.2. Answering machine enabled on the called device: 2.2.1. Everything works as expected if I leave the call ringing and I do not take it. On the called phone the call is ended and the calling one is redirected to the answering machine. 2.2.2. Everything works as expected if I intentionally hang up the call. On the called phone the call is ended and the calling one is redirected to the answering machine. 2. Calling from the Flame to Lync corporate phone number: 2.1. No answering machine enabled on the called device: 2.1.1. If I leave the call ringing and I do not take it, I get the "cannot make a call if you are already dialing please hang up first" message as mentioned in comment 1. 2.1.2. If I intentionally hang up the call using Lync, I get the "cannot make a call if you are already dialing please hang up first" message as mentioned in comment 1. I'll investigate the issue according to the comments already made ;)
Assignee: nobody → gtorodelvalle
Damn it! Obviously the third case (calling Lync) entries should start with a 3. Sorry about that! :(
Hi guys! I just confirmed that in 2.1.1, 3.1.1 and 3.1.2 (the three cases which are failing as reported in comment 1) what we are getting in Gaia via the call onerror handler is 'UnspecifiedError' as the error name. Hsin-yi, if understood you right, you mention we should be getting 'NoUserRespondingError 'in these cases. Is this right? Because we are not receiving it... :p Thanks!
Flags: needinfo?(htsai)
On the other hand and related to this bug, I noticed that we are not currently dealing with some of the error messages we could get from the RIL (see http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_consts.js#2621) such as NoUserRespondingError, CallRejectedError, CongestionError or UnspecifiedError to name a few. In fact, the error we currently show if the notified error does not match any of the expected ones is: "Cannot make a call. If you are already dialing, please hang up first." which is probably not the best one as reported in this bug :) In my opinion we should show a message as concrete and specific as possible for each of the errors we may get from the RIL and probably a more generic one when the received one does not match them (just to also cover that case). Doug, do you want me to create a bug about this issue or are you fine with the way we currently deal with call error messages? :) Thanks!
Flags: needinfo?(drs+bugzilla)
I was just told that I should be using dxr instead of mxr so the reference I mentioned in my previous comment should be this one: http://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_consts.js#2618 :)
That would be bug 846403.
(In reply to Germán Toro del Valle from comment #13) > Hi guys! I just confirmed that in 2.1.1, 3.1.1 and 3.1.2 (the three cases > which are failing as reported in comment 1) what we are getting in Gaia via > the call onerror handler is 'UnspecifiedError' as the error name. > > Hsin-yi, if understood you right, you mention we should be getting > 'NoUserRespondingError 'in these cases. Is this right? Because we are not > receiving it... :p Thanks! I was unable to test 2.1.1 (have no idea how to disable answering service on my personal phone). I expect gecko receives NoUserRespondingError in this case but I'd like to see ril log (can you attach it?) and confirm this behaviour again with partner.
Flags: needinfo?(htsai)
Doug, do you think bug 846403 should be added to bug 1036516. I do not really know if there is some kind of triage to add bugs to that meta :) Thanks!
Attached file 2.1.1.moz_logs (obsolete) (deleted) —
Hi Hsin-Yi! I am not sure I am providing you with the logs you need. If not, please do not guide me through the steps I should follow to do it ;) Thanks!
Flags: needinfo?(htsai)
Attached file 2.1.1.moz_radio_logs (obsolete) (deleted) —
Hi Hsin-Yi! I am not sure I am providing you with the logs you need. If not, please do not guide me through the steps I should follow to do it ;) Thanks!
Sorry, I meant "do not hesitate to guide me..." :S
(In reply to Germán Toro del Valle from comment #20) > Created attachment 8504139 [details] > 2.1.1.moz_radio_logs > > Hi Hsin-Yi! I am not sure I am providing you with the logs you need. If not, > please do not guide me through the steps I should follow to do it ;) Thanks! Hi Germán, Sorry that I didn't mention how to enable ril log clearly enough. Please refer to [1] to enable mozril debugger. If you enable the debugger successfully, you will see a lot of messages with prefix "RIL Worker". Then, kindly attach the log retrieved by |adb logcat -b radio -b main -v time|. Thanks again! [1] https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#Changing_preferences
Flags: needinfo?(htsai)
Attached file 2.1.1_ril_logs_gtorodelvalle.txt (deleted) —
Thanks Hsin-Yi! I hope these are the logs you really need ;) If not, please do not hesitate to ask for new ones :)
Attachment #8504138 - Attachment is obsolete: true
Attachment #8504139 - Attachment is obsolete: true
Flags: needinfo?(htsai)
Attachment #8504709 - Attachment description: ril_logs_gtorodelvalle.txt → 2.1.1_ril_logs_gtorodelvalle.txt
Attachment #8504709 - Attachment filename: ril_logs_gtorodelvalle.txt → 2.1.1_ril_logs_gtorodelvalle.txt
I think we should use bug 846403 as a meta-bug for adding each of these messages. We don't have every message that needs to be added clearly written anywhere, so we can write up a new report in bug 846403 about what's lacking. I went ahead and estimated this assuming the RIL is giving us the correct message. Feel free to alter my estimate if you disagree or my assumption turns out to be wrong.
Blocks: 846403
Flags: needinfo?(drs.bugzilla)
Whiteboard: [sprd335450] → [sprd335450][planned-sprint c=1]
Target Milestone: --- → 2.1 S7 (24Oct)
(In reply to Germán Toro del Valle from comment #23) > Created attachment 8504709 [details] > 2.1.1_ril_logs_gtorodelvalle.txt > > Thanks Hsin-Yi! I hope these are the logs you really need ;) If not, please > do not hesitate to ask for new ones :) Thanks! I got everything I need :) Hi Anshul, We were expecting to receive NoUserRespondingError (19) for the case #2.1.1 of comment 11 from modem/rild. What we actually received was UnspecifiedError (65535). Wondering if this is designed on purpose or should it be an flaw needed to be fixed?
Flags: needinfo?(htsai) → needinfo?(anshulj)
M4, please take a look.
Flags: needinfo?(anshulj) → needinfo?(mschwart)
Hi Hsin-Yi, AOSP doesn't include that fail cause in ril.h [1] so the behaviour is expected. I will look into it however. Thank you for bringing the issue to our attention. M [1] https://android.googlesource.com/platform/hardware/ril/+/master/include/telephony/ril.h
Flags: needinfo?(mschwart)
It looks like there's nothing we can do with this at this point. We can discuss during sprint planning, though.
Assignee: gtorodelvalle → nobody
Whiteboard: [sprd335450][planned-sprint c=1] → [sprd335450][planned-sprint c=]
Target Milestone: 2.1 S7 (24Oct) → ---
I think I saw a fix for this land in the RIL recently but I can't find it right now. Hsin-Yi do you know if this was fixed and in which bug? I have experienced this bug in the past but not in the last few days IIRC so I think it's fairly recent.
Flags: needinfo?(htsai)
(In reply to Gabriele Svelto [:gsvelto] from comment #30) > I think I saw a fix for this land in the RIL recently but I can't find it > right now. Hsin-Yi do you know if this was fixed and in which bug? I have > experienced this bug in the past but not in the last few days IIRC so I > think it's fairly recent. Hi Gabriele, No, I don't think Gecko already resolved this issue. I still see this with the build 20150226115903 (3.0.0.0-prerelease). The solution in my mind is: Dialer should first distinguish the promise rejection of telephony.dial() and the error coming through telephonyCall.onerror. Ultimately, we need Telephony API revision in bug 1043165.
Flags: needinfo?(htsai)
Thanks for clearing this up Hsin-Yi!
The gecko work has been landed for a while. Time to ship the gaia solution!
Depends on: 1043165
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: