USSD conversation not working

RESOLVED WORKSFORME

Status

P1
normal
RESOLVED WORKSFORME
6 years ago
6 years ago

People

(Reporter: anshulj, Assigned: gtorodelvalle)

Tracking

unspecified
B2G C2 (20nov-10dec)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments)

(Reporter)

Description

6 years ago
When I type a USSD code in the USSD popup, content process doesn't send the SendMMI message.

Steps to reproduce:
1. Dial a USSD code from the dialer. The USS UI poup is visible. 
2. Enter another USSD code in the textbox at the bottom of the USSD pop up but no SendMMI message is received.
(Reporter)

Updated

6 years ago
Blocks: 802677
blocking-basecamp: --- → ?
blocking-basecamp: ? → +

Updated

6 years ago
Priority: -- → P1
Anshul can you still reproduce it? It works for me on Unagi.
(Reporter)

Comment 2

6 years ago
Vivien, I tried again on the tip of aurora today and the USSD conversation is still not working for me. I am sending a random USSD number like (*23#), which fails by the network (as expected) and I see a null message printed on the USSD UI popup. At this time when I enter other numbers like (123) in the USSD UI text box and hit enter on the keyboard I see the sending message but not RIL:SendMMI message is received and so no message is sent to RIL. UI keeps showing the sending message until I hit the home key.
(Reporter)

Comment 3

6 years ago
Vivien, any updates on this issue?
Anshul -- can you please confirm that this is still an issue at the tip aurora just to be sure.
(Reporter)

Comment 5

6 years ago
Michael, yes this is still an issue on the tip of aurora from this morning. Now I see that Ussd UI popup doesn't show a text box if there is an error reported by UNSOL_ON_USSD and SessionEnded is set to true in RIL:USSDReceived message. I changed the code to report SessionEnded to false to get USSD UI to show the text box and I still don't seen SendMMI message from the content process.
Flags: needinfo?(21)
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

6 years ago
TEF engineers own this code. Can I add the TEF product manager to this QC confidential bug?
Yes please!

Comment 8

6 years ago
Daniel, your team owns this I think.
Anshul, which device are you using? Which RIL version (commercial vs. open source) are you using?
Hi guys! ;) I have just tested it and it works as expected for my using a prepaid VIVO SIM card... I have included a set of screenshots of the screen flow, from typing the code to getting the final "answer" :) Please, see attached files.

As you can see the "response text field" only appears when some response is expected from the user.

If in the latest screen the user types a new code (for example *204# again) the flow starts from the beginning.

So basically, it works for me :) Using Gecko-8635579.Gaia-96594a9
Created attachment 679661 [details]
Screenshot: screen flow 1
Created attachment 679663 [details]
Screenshot: screen flow 2
Created attachment 679664 [details]
Screenshot: screen flow 3
Created attachment 679665 [details]
Screenshot: screen flow 4
Created attachment 679666 [details]
Screenshot: screen flow 5
Created attachment 679667 [details]
Screenshot: screen flow 6
(Reporter)

Comment 17

6 years ago
Daniel, I using Ontoro device and tried on both Moz ril and commercial RIL and it doesn't work for me on either RIL. Let me retest it on the tip and get back.
(Reporter)

Comment 18

6 years ago
gtorodelvalle, I tried the MMI code #206* and that results in failure right away with Moz RIL "NO_VALID_MMI_STRING" and this is expected as per spec as this is not a valid MMI or USSD code.

So I tried MMI code *206# instead and I do see the USSD request going to the network. My operator doesn't support the USSD conversation (required a USSD code in response to another USSD code) so I cannot test it end to end. However, I am hacking my code a little to test this scenario.

I am sending a USSD code of *206#, which returns in failure and I see on the UI  "session ended" message.  If I hack the sessionEnded value to false in the message "RIL:USSDReceived" I see the keyboard on the USSD UI popup as I expected (the hack is just to fool the USSD UI in thinking that the session is available and so it can show the text box to enter another USSD code). I believe the sessionEnded flag is the way USSD UI known it is expected to allow sending another USSD code. Now, when I enter any code, say 1, I don't see the "RIL: SendMMI" message being received from RILContentHelper.

I am able to reproduce the issue with Moz ril as well as commercial ril. Am I missing something here?

Using Gecko: ac1ea16304c355bf8ff12d8cc2178730f71eef65
Using Gaia: 7ffd1c81db16bf0c6c3285a46259411d603109ca
(In reply to Anshul from comment #18)
> I am sending a USSD code of *206#, which returns in failure and I see on the
> UI  "session ended" message.

This is the expected behavior for a USSD message not recognized by the carrier. The RIL provides two different parameters for the REQUEST_SEND_USSD reply: 'message' and 'typeCode'. I've experienced that some operators provide an string value on the 'message' parameter indicating that the USSD message is not valid, but others just fails with an empty message reply. In both cases, a non recognize USSD message would end with a 'typeCode' 2, that indicates that the USSD session is finished. So, for this case where the USSD is not valid, the Gaia UI shows the error message provided by the operator or just the 'Session ended' message if no error message is provided by the carrier.

> If I hack the sessionEnded value to false in
> the message "RIL:USSDReceived" I see the keyboard on the USSD UI popup as I
> expected (the hack is just to fool the USSD UI in thinking that the session
> is available and so it can show the text box to enter another USSD code).

I am not sure what are you trying to prove with this modification. If you want to check how an interactive USSD menu works in Gaia, you just need to enter a valid USSD message (check it with your carrier). It would be great if you could check with a valid USSD instead of modifying the current implementation. We've recently fixed several issues with the UI.
(Reporter)

Comment 20

6 years ago
Michael Schwartz, will test on a test setup that supports USSD menu and get back.
Flags: needinfo?(21)
Assignee: nobody → gtorodelvalle

Updated

6 years ago
Flags: needinfo?(mschwart)
Milestoning for C2 (deadline of 12/10), as this meets the criteria of "remaining P1 bugs not already milestoned for C1".
Target Milestone: --- → B2G C2 (20nov-10dec)
Removing the blocking-basecamp+ tracking flag until this is confirmed
blocking-basecamp: + → ---

Updated

6 years ago
Component: Gaia → Gaia::Dialer
Group: qualcomm-confidential

Comment 23

6 years ago
Michael, any updates here? I think you guys were investigating.
Flags: needinfo?(mvines)
(just asked m4 to provide the requested info)
Flags: needinfo?(mvines)
There has been some delay in getting a test setup as AT&T doesn't seem to have any USSD commands that result in user input.  We will test this overnight and verify.
Flags: needinfo?(mschwart)
Michael, do you have an update on your testing?
Flags: needinfo?(mschwart)
Hi Dietrich, unfortunately most GCF test cases requiring user input are NW-initiated which Gaia currently does not support.  Trying to find a test that will work - please recommend one if you are familiar with them.  Will also press our test team in India to pursue live network if that is an option.  Sorry for the delay.
Flags: needinfo?(mschwart)
(In reply to Michael Schwartz from comment #27)
> Hi Dietrich, unfortunately most GCF test cases requiring user input are
> NW-initiated which Gaia currently does not support.  Trying to find a test
> that will work - please recommend one if you are familiar with them.  Will
> also press our test team in India to pursue live network if that is an
> option.  Sorry for the delay.

OK, but this bug was about device initiated USSDs, which should be working. Can we close this bug and open a follow-up if required?
Can't reproduce this issue anymore.   We'll file a new issue if needed.  Thanks all!!
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.