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)
Tracking
(tracking-b2g:backlog)
RESOLVED
FIXED
tracking-b2g | backlog |
People
(Reporter: ming.li, Assigned: aknow)
References
Details
Attachments
(2 files)
609.08 KB,
text/plain
|
Details | |
5.89 KB,
patch
|
Details | Diff | Splinter Review |
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" .
Comment 1•10 years ago
|
||
spreadtrum v1.2 major bug.
blocking-b2g: --- → fugu?
Flags: needinfo?(styang)
Comment 2•10 years ago
|
||
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
Comment 4•10 years ago
|
||
Is that a little weird that we send ATD, but got USSD response? ATD: expect call_state_change. AT+CUSD: expect UNSOL_ON_USSD.
Comment 5•10 years ago
|
||
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
Updated•10 years ago
|
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)
Comment 8•10 years ago
|
||
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)
Updated•10 years ago
|
Updated•10 years ago
|
blocking-b2g: 1.4? → 1.4+
Updated•10 years ago
|
Whiteboard: [FT:RIL]
Updated•10 years ago
|
Attachment #8349805 -
Attachment mime type: text/x-log → text/plain
Comment 10•10 years ago
|
||
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?
Updated•10 years ago
|
Flags: needinfo?(sam.hua)
Comment 11•10 years ago
|
||
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)
Comment 12•10 years ago
|
||
(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.
Comment 13•10 years ago
|
||
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.
Comment 14•10 years ago
|
||
(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?
Comment 15•10 years ago
|
||
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.
Comment 16•10 years ago
|
||
I don't see this linked to any of the QC blocking feature & DSDS feature lists. Renoming.
blocking-b2g: 1.4+ → 1.4?
Comment 17•10 years ago
|
||
(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.
Comment 18•10 years ago
|
||
Hsin Is this a RIL Issue that QC needs fixed in 1.4?
Flags: needinfo?(htsai)
Comment 19•10 years ago
|
||
Is this fix needed for Moz RIL testing?
Comment 20•10 years ago
|
||
(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)
Comment 23•10 years ago
|
||
Bug 990467 should be able to fix this as well.
Comment 24•10 years ago
|
||
(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
Comment 25•10 years ago
|
||
please help to review it. just check it's mmi code or not
Comment 26•10 years ago
|
||
Hi steven, please help to arrange it to merge into 1.3t
Flags: needinfo?(styang)
Comment 27•10 years ago
|
||
(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)
Comment 28•10 years ago
|
||
ecc patch will fix this issue, sam please check it.
Comment 29•10 years ago
|
||
see bug 990467
Updated•10 years ago
|
Flags: needinfo?(styang)
Comment 30•10 years ago
|
||
Hi Hsin, yes, we can make normal call after dialing 23 on latest build.
Flags: needinfo?(sam.hua) → needinfo?(szchen)
Comment 31•10 years ago
|
||
(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)
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(szchen)
Comment 32•10 years ago
|
||
this does not impact Tarako, only Fugu, moving flag to 1.5?
blocking-b2g: 1.3T? → 1.5?
Updated•10 years ago
|
Whiteboard: [FT:RIL]
Updated•10 years ago
|
blocking-b2g: 2.0? → backlog
Assignee | ||
Comment 34•10 years ago
|
||
(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
Updated•9 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
You need to log in
before you can comment on or make changes to this bug.
Description
•