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)
Tracking
(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
Reporter | ||
Updated•10 years ago
|
Whiteboard: [sprd335450]
Comment 1•10 years ago
|
||
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)
Comment 2•10 years ago
|
||
(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)
Comment 3•10 years ago
|
||
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)
Comment 4•10 years ago
|
||
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)
Comment 5•10 years ago
|
||
One more thing to mention: still need revision on Dialer even gecko reports "NoUserRespondingError" to gaia as Dialer doesn't recognize this type now.
Comment 6•10 years ago
|
||
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)
Comment 7•10 years ago
|
||
(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."
Comment 8•10 years ago
|
||
Yeah, Got it.
Thank you very much.
Comment 9•10 years ago
|
||
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)
Comment 10•10 years ago
|
||
(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
Updated•10 years ago
|
Blocks: dialer-most-wanted
Comment 11•10 years ago
|
||
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 ;)
Updated•10 years ago
|
Assignee: nobody → gtorodelvalle
Comment 12•10 years ago
|
||
Damn it! Obviously the third case (calling Lync) entries should start with a 3. Sorry about that! :(
Comment 13•10 years ago
|
||
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)
Comment 14•10 years ago
|
||
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)
Comment 15•10 years ago
|
||
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 :)
Comment 16•10 years ago
|
||
That would be bug 846403.
Comment 17•10 years ago
|
||
(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)
Comment 18•10 years ago
|
||
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!
Comment 19•10 years ago
|
||
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)
Comment 20•10 years ago
|
||
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!
Comment 21•10 years ago
|
||
Sorry, I meant "do not hesitate to guide me..." :S
Comment 22•10 years ago
|
||
(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)
Comment 23•10 years ago
|
||
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)
Updated•10 years ago
|
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
Comment 24•10 years ago
|
||
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
status-b2g-v1.4:
--- → affected
status-b2g-v2.0:
--- → affected
status-b2g-v2.1:
--- → affected
status-b2g-v2.2:
--- → affected
Flags: needinfo?(drs.bugzilla)
Whiteboard: [sprd335450] → [sprd335450][planned-sprint c=1]
Target Milestone: --- → 2.1 S7 (24Oct)
Comment 25•10 years ago
|
||
(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)
Comment 27•10 years ago
|
||
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)
Comment 28•10 years ago
|
||
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) → ---
Comment 30•10 years ago
|
||
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)
Updated•10 years ago
|
Comment 31•10 years ago
|
||
(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)
Comment 32•10 years ago
|
||
Thanks for clearing this up Hsin-Yi!
Updated•9 years ago
|
Comment 33•9 years ago
|
||
The gecko work has been landed for a while. Time to ship the gaia solution!
Depends on: 1043165
Updated•9 years ago
|
Comment 34•7 years ago
|
||
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.
Description
•