Closed Bug 951607 Opened 10 years ago Closed 10 years ago

[fugu][B2G]dial number "23" , after it displays the error, we can't dial a normal number .

Categories

(Firefox OS Graveyard :: RIL, defect)

ARM
Other
defect
Not set
major

Tracking

(tracking-b2g:backlog)

RESOLVED FIXED
tracking-b2g backlog

People

(Reporter: ming.li, Assigned: aknow)

References

Details

Attachments

(2 files)

steps:
1.call "23"
2.wait for the error msg to be displayed.
3.close the error msg
4.call 10086

result:
we can't call out.

The reason seems to be like this:
1.dialer takes the number "23" as a normal number,and make a call through mozTelephony. So there is a active call now.

2.Bug modem takes the number "23" as a ussd operation. So no call state events reported.

3.So next time we call other numbers , there is a active call ,and we can't call out.

Refer to android , it seems we need to follow the ts 22.030 clause 6.5 ,to take   some numbers as a mmi number. And then make a "sendUSSD" .
spreadtrum v1.2 major bug.
blocking-b2g: --- → fugu?
Flags: needinfo?(styang)
Attached file 951607.log
There are two problems on this bug.
1. Gecko/Gaia did not seperate MMI/dial string well. see Bug 889737.
2. Gecko only send dial request (mapping to ATD), there is no any USSD request from Gecko/Gaia. however, we got UNSOL_ON_USSD {2}, but not call fail, or call state change, that cause this dangling call object in Telephony.cpp issue.

1. It looks like to me that RILD/modem did extra mmi string parsing. (need partner's reply).
2. If "1." is correct, we might need extra discussion for the solution.


// Log snippet.
12-19 10:34:15.128   106   230 I Gecko   : RIL Worker[0]: Received chrome message {"number":"23","isDialEmergency":false,"rilMessageToken":9,"rilMessageType":"dial"}
12-19 10:34:15.138   100   292 D AT      : [w] Channel1: AT> ATD23;
...
12-19 10:34:17.198   100   272 D RILC    : [w] [UNSL]< UNSOL_ON_USSD {2}
12-19 10:34:17.208   106   106 I Gecko   : -*- RadioInterface[0]: USSDReceived {"rilMessageType":"USSDReceived","sessionEnded":true}
(In reply to shawn ku [:sku] from comment #2)

> There are two problems on this bug.
> 1. Gecko/Gaia did not seperate MMI/dial string well. see Bug 889737.
> 2. Gecko only send dial request (mapping to ATD), there is no any USSD
> request from Gecko/Gaia. however, we got UNSOL_ON_USSD {2}, but not call
> fail, or call state change, that cause this dangling call object in
> Telephony.cpp issue.
> 
> 1. It looks like to me that RILD/modem did extra mmi string parsing. (need
> partner's reply).

Yes, fugu's modem does
Is that a little weird that we send ATD, but got USSD response?

ATD: expect call_state_change.
AT+CUSD: expect UNSOL_ON_USSD.
This problem exits only with Fugu device.

On Buri, with USIM card, I can dialer out '23', but it is an empty number. After that, I can dial other numbers.
with China mobile SIM card, dialing '23' will end the call immediately but there is no error msg. After that I can dial other numbers.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(styang) → needinfo?(ming.li)
(In reply to shawn ku [:sku] from comment #4)
> Is that a little weird that we send ATD, but got USSD response?
> 
> ATD: expect call_state_change.
> AT+CUSD: expect UNSOL_ON_USSD.

Fugu's modem supports  the ME makes a ussd operation by sending ATD.
Although this may be a modem feature, but numbers like "23" is a special number.So should we need to act as a ussd operation,rather than to act as a normal call?


Add sam,  i suggest this issue could be discussed at next week meetings ,between sprd & ffos groups.
Flags: needinfo?(ming.li) → needinfo?(sam.hua)
Hi,
"23" is ussd code, so modem will return a ussd response.
could gecko or gaia filter this ussd code like "23" before sending dial request to RILC?
Flags: needinfo?(sam.hua) → needinfo?(sku)
Hi Sam:
 Please check Bug 889737, there is no conclusion so far.
(We all know length< 3 should be treated as USSD. not a call except ECC.)
Better triage this issue on meeting.

Hi Steven:
 Please put this into discussion topic. 

Thanks!!
sku
Flags: needinfo?(sku) → needinfo?(styang)
blocking-b2g: fugu? → 1.4?
Depends on: 889737
Flags: needinfo?(styang)
blocking-b2g: 1.4? → 1.4+
Aknow, please help this bug.
Assignee: nobody → szchen
Whiteboard: [FT:RIL]
Depends on: 969218
Attachment #8349805 - Attachment mime type: text/x-log → text/plain
Hi all,

Let me recap this issue. Shawn did a good investigation and summary as comment 2.
Quote from Shawn's comment 2:
=============================
There are two problems on this bug.
1. Gecko/Gaia did not seperate MMI/dial string well. see Bug 889737. <== FxOS team is working on this.
2. Gecko only send dial request (mapping to ATD), there is no any USSD request from Gecko/Gaia. however, we got UNSOL_ON_USSD {2}, but not call fail, or call state change, that cause this dangling call object in Telephony.cpp issue.
=============================

Regarding 1), FxOS team is working on this. See bug 889737.
However about 2), gecko is expecting that if REQUEST_DIAL (ATD) fails, gecko receives a failure from modem/RILD. In this case, if RILD/modem supports extra mmi string parsing, it's fine for gecko to receive the following 'UNSOL_ON_USSD.' Moreover, as the previous REQUEST_DIAL fails (apparently RILD/modem doesn't make a normal call out), RILD/modem should inform gecko a failure.

So, indeed, if gecko parses mmi string well, then this issue won't happen. However, IMO 2) is still a valid issue even after bug 889737. We do need 2) resolved to avoid any other unexpected behaviour. Since 1) will be handled on bug 889737, I'd suggest let this bug focus on 2), of course requiring sprd support.

How do you think?
Flags: needinfo?(sam.hua)
Hi Hsin,
do u mean if ril_worker send REQUEST_DIAL with (23) to RILC, RILC should return failure for REQUEST_DIAL at first?
Flags: needinfo?(sam.hua)
(In reply to sam.hua from comment #11)
> Hi Hsin,
> do u mean if ril_worker send REQUEST_DIAL with (23) to RILC, RILC should
> return failure for REQUEST_DIAL at first?

Yes, apparently RILC/modem doesn't treat 23 as a call. I think RILC/modem should let us know the failure, i.e. returning failure of REQUEST_DIAL. 

More specifically, not only for "23" but for all other numbers that ril_worker sends via REQUEST_DIAL but RILC/modem parses as a MMI string eventually.
Hi Hsin,

If RILC return the failure of REQUEST_DIAL,will Gaia app show "call failure"? 
I think RILC can't know which RIL_UNSOL_ON_USSD should be replaced by failure of REQUEST_DIAL.
(In reply to sam.hua from comment #13)
> Hi Hsin,
> 
> If RILC return the failure of REQUEST_DIAL,will Gaia app show "call
> failure"? 
> I think RILC can't know which RIL_UNSOL_ON_USSD should be replaced by
> failure of REQUEST_DIAL.

I think either RILC or modem knows REQUEST_DIAL fails as the dialing number is replaced with MMI code somehow. According to your explanation, it's modem to have the information. Could modem send gecko the right response, a failure in this case?
Hi Hsin,
The problem is how to deal the 23 call? Gaia APP deals it as a call, but modem deals it as the MMI code.
Our modem think app should know 23 is MMI code,so it won't indicate the AP that it will treat the ATD23 as a MMI code,modem won't give RILC anything about call,such as ECIND or DSCI and etc.So unfortunately, RILC can't know UNSOL_ON_USSD is caused by ATD23 or AT+CUSD=1,"23". 

Maybe RILC can report one RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED when report UNSOL_ON_USSD.
I don't see this linked to any of the QC blocking feature & DSDS feature lists. Renoming.
blocking-b2g: 1.4+ → 1.4?
(In reply to sam.hua from comment #15)
> Hi Hsin,
> The problem is how to deal the 23 call? Gaia APP deals it as a call, but
> modem deals it as the MMI code.
> Our modem think app should know 23 is MMI code,so it won't indicate the AP
> that it will treat the ATD23 as a MMI code,modem won't give RILC anything
> about call,such as ECIND or DSCI and etc.So unfortunately, RILC can't know
> UNSOL_ON_USSD is caused by ATD23 or AT+CUSD=1,"23". 
> 
> Maybe RILC can report one RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED when report
> UNSOL_ON_USSD.

Sending an extra RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED along with UNSOL_ON_USSD doesn't help this issue.

Anyway, we will keep working on bug 889737 to parse MMI string correctly. Then this issue could be resolved eventually, even though I still think the response of REQUSET_DIAL should be fixed as well.
Hsin

Is this a RIL Issue that QC needs fixed in 1.4?
Flags: needinfo?(htsai)
Is this fix needed for Moz RIL testing?
(In reply to Preeti Raghunath(:Preeti) from comment #19)
> Is this fix needed for Moz RIL testing?

Quote from my comment 10:

Two problems observed:
1. Gecko/Gaia did not seperate MMI/dial string well. see Bug 889737. <== FxOS team is working on this.
2. Gecko only send dial request (mapping to ATD), there is no any USSD request from Gecko/Gaia. however, we got UNSOL_ON_USSD {2}, but not call fail, or call state change, that cause this dangling call object in Telephony.cpp issue.

So, if item 1 (bug 889737) is resolved, then this issue won't happen. However, IMO 2) is still a valid issue even after bug 889737. I expect 2) being resolved on modem side to avoid any further unexpected behaviour though it's totally our partner's call. No matter how our partner is going to address item 2), item 1) has to be fixed on mozRIL.
Flags: needinfo?(htsai)
Let's fix it in 1.5.
blocking-b2g: 1.4? → ---
it also happened in Tarako.
blocking-b2g: --- → 1.3T?
Bug 990467 should be able to fix this as well.
(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #23)
> Bug 990467 should be able to fix this as well.

Summarize again, extending comment 20:

Three problems in this bug:
1. Gecko/Gaia did not seperate MMI/dial string well. see Bug 889737. <== FxOS team is working on this.
2. Gecko only send dial request (mapping to ATD), there is no any USSD request from Gecko/Gaia. however, we got UNSOL_ON_USSD {2}, but not call fail, or call state change <== Partner's call to decide if they want to fix or not
3. Due to 2), there's a dangling call object in Telephony.cpp. <== Bug 990467 fixes this already. Since the is the direct cause that makes user unable to dial a second call after dialing '23' ask for QA's verification.
Keywords: qawanted
please help to review it.
just check it's mmi code or not
Hi steven,
please help to arrange it to merge into 1.3t
Flags: needinfo?(styang)
(In reply to sam.hua from comment #26)
> Hi steven,
> please help to arrange it to merge into 1.3t

Hi Sam,

May I know why you'd like to have this gaia patch? I believe once bug 990467 is landed in v1.3t, this issue should be automatically resolved, i.e. even after dialing "23" we could dial another normal number. We don't really need the parsing algorithm in gaia.
Flags: needinfo?(sam.hua)
ecc patch will fix this issue, sam please check it.
Flags: needinfo?(styang)
Hi Hsin,
yes, we can make normal call after dialing 23 on latest build.
Flags: needinfo?(sam.hua) → needinfo?(szchen)
(In reply to sam.hua from comment #30)
> Hi Hsin,
> yes, we can make normal call after dialing 23 on latest build.

I haven't got the available latest build yet. So, does it work on both fugu and tarako?

I think in Fugu, we will need your help as you suggested in comment 15 - Maybe RILC can report one RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED when report UNSOL_ON_USSD. Otherwise, even with bug 990467, gecko has no idea when to release the dangling call object.
Flags: needinfo?(sam.hua)
Flags: needinfo?(szchen)
this does not impact Tarako, only Fugu, moving flag to 1.5?
blocking-b2g: 1.3T? → 1.5?
Hi hsin.
if fugu use v1.3t, i will be okay.
Flags: needinfo?(sam.hua)
Whiteboard: [FT:RIL]
blocking-b2g: 2.0? → backlog
(In reply to sam.hua from comment #30)
> Hi Hsin,
> yes, we can make normal call after dialing 23 on latest build.

Close the bug base on this comment.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: