881853 - [leo-pre-iot-br] Call Forwarding by

Status: RESOLVED WORKSFORME

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

Description

[David Palomino [:dpalomino]]

Attachment: logcat

Device: leo
build 06/07:
Gecko revision : 08e8a7bbebec924c24a5187a3c0b2ef1ef6d08da
Gaia revision : e2346ca0297f40547e64a7eebc4bd2e4a4cdaf86
QC commercial RIL : AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.115

When trying to activate call forwarding dialing: 
**21*0199605XXXX#

Generic failure message (in English, not localized) appears. 

This is not always reproducible so I would not discard a nw issue, but I think it'd worth to confirm this taking a look on the logcat. 

Attaching log. 

Nominating to leo, for confirming this.

Comment 1

[leo.bugzilla.gecko]

The log you've attached has not enough information to confirm whether it is nw issue or not.

It needs QXDM log to verify.

And the generic failure message translate issue is arguing bugzilla.

Comment 2

[leo.bugzilla.gecko]

You can use dmc file where it is attached 881858

Comment 3

[leo.bugzilla.gecko]

Could you share the qxdm log by my mail ([e-mail]), not in bugzilla?

Comment 5

[David Palomino [:dpalomino]]

(In reply to leo.bugzilla.gecko from comment #3)
> Could you share the qxdm log by my mail ([e-mail]), not in
> bugzilla?

Yes, of course. We've asked for them (not QXDM available right now). 

Anyway, the issue was not only the localization, but the CF by MMI not working: 
**21*0199605XXXX#

So I'd prefer to reopen the bug.

Comment 6

[leo.bugzilla.gecko]

I think it depends on network results.
Please test other device (Unagi) with same SIM and chapture the QXDM log.

Comment 7

[José Antonio Olivera Ortega [:jaoo]]

(In reply to David Palomino [:dpv] from comment #5)
> (In reply to leo.bugzilla.gecko from comment #3)
> > Could you share the qxdm log by my mail ([e-mail]), not in
> > bugzilla?
> 
> Yes, of course. We've asked for them (not QXDM available right now). 
> 
> Anyway, the issue was not only the localization, but the CF by MMI not
> working: 
> **21*0199605XXXX#
> 
> So I'd prefer to reopen the bug.

I give a try to figure out what's going. Adding ni? to Anshul.

Comment 8

[José Antonio Olivera Ortega [:jaoo]]

Apparently the flow is correct:

I/Gecko   (  588): -*- RILContentHelper: Sending MMI **21*199605XXXX#
I/Gecko   (  144): -*- QCContentHelper_QC_B2G: receiveMessage: 'RIL:SendMMI' arrived from content process
I/Gecko   (  144): -*- QCContentHelper_QC_B2G: saveRequestTarget: RIL:SendMMI
I/Gecko   (  144): -*- QCContentHelper_QC_B2G: SendMMI dialstring: **21*199605XXXX#
I/Gecko   (  144): -*- QCContentHelper_QC_B2G: _parseMMI dialstring: **21*199605XXXX#
I/Gecko   (  144): -*- QCContentHelper_QC_B2G: SendMMI poundString:**21*199605XXXX# action:** serviceCode:21 sia:1996052375 sib:undefined sic:undefined pwd:undefined dialingNumber:
D/PHONE_QC_B2G(  144): dialing w/ mmi MmiCode { action=** serviceCode=21 sia=1996052375 poundString=**21*199605XXXX#}
D/MMI_CODE_QC_B2G(  144): Dial string is CF command
D/MMI_CODE_QC_B2G(  144): is CF setCallForward

And the response is:

I/Gecko   (  144): -*- QCContentHelper_QC_B2G: sendMessage to content process: RIL:SendMMI:Return:KO{requestId : 'id{18d7d095-5bca-4909-8fdf-3fe9c218aa51}', errorMsg : 'Call forwarding\ngeneric failure'}
I/Gecko   (  144): -*- QCContentHelper_QC_B2G: sendRequestResults: RIL:SendMMI:Return:KO
I/Gecko   (  144): -*- RILContentHelper: Received message 'RIL:CfStateChanged': {"success":false,"reason":0,"action":0}
I/Gecko   (  588): -*- RILContentHelper: Received message 'RIL:CfStateChanged': {"success":false,"reason":0,"action":0}
I/Gecko   (  588): -*- RILContentHelper: Received message 'RIL:SendMMI:Return:KO': {"requestId":"id{18d7d095-5bca-4909-8fdf-3fe9c218aa51}","errorMsg":"Call forwarding\ngeneric failure"}

The number introduced (the one I see in the log is different than the one you commented in comment #0). IIRC for some ICC cards the number matters, I mean It works by adding a `0` as first digit of the phone number (`0` + phone number) and a similar error happens if you don't provide the `0` digit. As I can see you didn't provide the `0` digit + phone number.

Note: AFAIK David is PTO.

Comment 9

[Anshul]

No radio logs to say for sure but seems like RIL is sending the failure for the call forwarding. Doesn't seem like a telephony issue at this moment.

Comment 10

[leo.bugzilla.gecko]

Would you refer to Comment #26 of Bug 882841?
It might be caused by use of reference ril, not commercial ril.

We use commercial ril, and this issue(call forwarding without '0') has never happened.

Please check above comment of the Bug 882841.

Thanks

Comment 11

[José Antonio Olivera Ortega [:jaoo]]

(In reply to leo.bugzilla.gecko from comment #10)
> Would you refer to Comment #26 of Bug 882841?
> It might be caused by use of reference ril, not commercial ril.
> 
> We use commercial ril, and this issue(call forwarding without '0') has never
> happened.

The issue I commented in comment #8 happens on both RIL implementations and It's because of the SIM.

Comment 12

[leo.bugzilla.gecko]

Do you know which kind of sim card has this problem?
Is it caused by sim field value or something?

Please share your idea.

Ps. What does the PTO that you've mentioned means?

Comment 13

[leo.bugzilla.gecko]

If it depends on the sim card, should be same on Unagi device.

Can you check it, David?

Comment 14

[José Antonio Olivera Ortega [:jaoo]]

(In reply to leo.bugzilla.gecko from comment #12)
> Do you know which kind of sim card has this problem?
> Is it caused by sim field value or something?
> 
> Please share your idea.

The ones that have both short and long dial numbers. They are mostly present in large corporation. The employees' ICC cards are an example. We have to provide this extra '0' before the phone number to avoid the RIL considers those number as the long dial one (which is the only one valid for enabling call forwarding).

> Ps. What does the PTO that you've mentioned means?

PTO stands for Personal Time Off, usually holidays or days off.

Comment 15

[leo.bugzilla.gecko]

In my opinion, there is a network problem at that time.
I tested the CF MMI code with same number you used. (**21*0199605XXXX#)
And it works fine with or without '0'. 

[ with 0 ]
1401	07-07	20:56:45.069	I	501	501	Gecko		   : -*- RILContentHelper: Sending MMI **21*01996051234#
1419	07-07	20:56:45.169	I	146	146	Gecko		   : -*- QCContentHelper_QC_B2G: SendMMI dialstring: **21*01996051234#
1420	07-07	20:56:45.169	I	146	146	Gecko		   : -*- QCContentHelper_QC_B2G: _parseMMI dialstring: **21*01996051234#
1421	07-07	20:56:45.169	I	146	146	Gecko		   : -*- QCContentHelper_QC_B2G: SendMMI poundString:**21*01996051234# action:** serviceCode:21 sia:01996051234 sib:undefined sic:undefined pwd:undefined dialingNumber:

1692	07-07	20:56:52.359	I	146	146	Gecko		   : -*- QCContentHelper_QC_B2G: sendMessage to content process: RIL:SendMMI:Return:OK{ requestId : id{84ea5c6c-f8e4-4743-9545-ed152ee581c1}, result : null,  }
1695	07-07	20:56:52.359	I	146	146	Gecko		   : -*- QCContentHelper_QC_B2G: sendRequestResults: RIL:SendMMI:Return:OK

[ without 0 ]
3049	07-07	21:10:10.379	I	501	501	Gecko		   : -*- RILContentHelper: Sending MMI **21*19960512345#
3053	07-07	21:10:10.409	I	146	146	Gecko		   : -*- QCContentHelper_QC_B2G: SendMMI dialstring: **21*19960512345#
3054	07-07	21:10:10.409	I	146	146	Gecko		   : -*- QCContentHelper_QC_B2G: _parseMMI dialstring: **21*19960512345#
3055	07-07	21:10:10.409	I	146	146	Gecko		   : -*- QCContentHelper_QC_B2G: SendMMI poundString:**21*19960512345# action:** serviceCode:21 sia:19960512345 sib:undefined sic:undefined pwd:undefined dialingNumber:

3104	07-07	21:10:14.389	I	146	146	Gecko		   : -*- QCContentHelper_QC_B2G: sendMessage to content process: RIL:SendMMI:Return:OK{ requestId : id{cb1bada1-7b61-4066-9833-a45faab3fc33}, result : null,  }
3105	07-07	21:10:14.389	I	146	146	Gecko		   : -*- QCContentHelper_QC_B2G: sendRequestResults: RIL:SendMMI:Return:OK

Also, the 'generic failure' could be caused by temporory network disorder.
We don't have the QXDM log, so we cannot sure 100% but, it could be.

Please re-test with latest version.

Comment 16

[José Antonio Olivera Ortega [:jaoo]]

(In reply to leo.bugzilla.gecko from comment #15)
> In my opinion, there is a network problem at that time.

Could be.

> Also, the 'generic failure' could be caused by temporory network disorder.
> We don't have the QXDM log, so we cannot sure 100% but, it could be.

Agree, could be. Let's wait what David says.

Thanks!

Comment 17

[leo.bugzilla.gecko]

Any update David?

Comment 18

[David Palomino [:dpalomino]]

Hi, 

Sorry, I'm just landing from holidays, didn't get your messages before. 

I don't think it'd be caused by a network issue, as it was working with other devices. Anyway, I think it'd be useful to retest (and get new logs) with latest build. May we ask to vendor colleagues in BZ to retest this?

Thanks!
David

Comment 19

[leo.bugzilla.gecko]

We asked for this to a coworker in Brazil with the latest binary, and it works same.

As José said at comment 8 , When you provide valid number (`0` + phone number) it works fine, but invalid number format(without '0') is rejected by network.

I think this is not an issue.

Comment 20

[David Palomino [:dpalomino]]

Hi, 

Many thanks for checking that it's working with the latest binary. I also think that if it's working with '0' before we can assume that it's working fine. 

setting the bug to WFM

Thanks!
David