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

Status: RESOLVED WONTFIX

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

Description

[Peipei Cheng (needinfo if you need my action)]

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

Comment 1

[helloarvin]

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}

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(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.

Comment 3

[helloarvin]

Attachment: log-for-calling-failure.zip

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"}

Comment 4

[Hsin-Yi Tsai (she/her) [:hsinyi]]

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"}

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

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

[helloarvin]

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?

Comment 7

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(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

[helloarvin]

Yeah, Got it.
Thank you very much.

Comment 9

[Anthony Ricaud (:rik)]

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)

Comment 10

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(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

Comment 11

[Germán Toro del Valle (:gtorodelvalle)]

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 ;)

Comment 12

[Germán Toro del Valle (:gtorodelvalle)]

Damn it! Obviously the third case (calling Lync) entries should start with a 3. Sorry about that! :(

Comment 13

[Germán Toro del Valle (:gtorodelvalle)]

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!

Comment 14

[Germán Toro del Valle (:gtorodelvalle)]

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!

Comment 15

[Germán Toro del Valle (:gtorodelvalle)]

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

[Anthony Ricaud (:rik)]

That would be bug 846403.

Comment 17

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(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.

Comment 18

[Germán Toro del Valle (:gtorodelvalle)]

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

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: 2.1.1.moz_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!

Comment 20

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: 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!

Comment 21

[Germán Toro del Valle (:gtorodelvalle)]

Sorry, I meant "do not hesitate to guide me..." :S

Comment 22

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(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

Comment 23

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: 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 :)

Comment 24

[Doug Sherk (:drs) (inactive)]

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.

Comment 25

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(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?

Comment 26

[Anshul]

M4, please take a look.

Comment 27

[Michael Schwartz [:m4]]

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

Comment 28

[Doug Sherk (:drs) (inactive)]

It looks like there's nothing we can do with this at this point. We can discuss during sprint planning, though.

Comment 30

[Gabriele Svelto [:gsvelto] (PTO)]

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.

Comment 31

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(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.

Comment 32

[Gabriele Svelto [:gsvelto] (PTO)]

Thanks for clearing this up Hsin-Yi!

Comment 33

[Hsin-Yi Tsai (she/her) [:hsinyi]]

The gecko work has been landed for a while. Time to ship the gaia solution!

Comment 34

[BMO Automation]

Firefox OS is not being worked on