805169 - USSD conversation not working

Status: RESOLVED WORKSFORME

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

Description

[Anshul]

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.

Comment 1

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Anshul can you still reproduce it? It works for me on Unagi.

Comment 2

[Anshul]

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.

Comment 3

[Anshul]

Vivien, any updates on this issue?

Comment 4

[Michael Vines [:m1] [:evilmachines]]

Anshul -- can you please confirm that this is still an issue at the tip aurora just to be sure.

Comment 5

[Anshul]

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.

Comment 6

[Andreas Gal :gal]

TEF engineers own this code. Can I add the TEF product manager to this QC confidential bug?

Comment 7

[Michael Vines [:m1] [:evilmachines]]

Yes please!

Comment 8

[Andreas Gal :gal]

Daniel, your team owns this I think.

Comment 9

[Daniel Coloma:dcoloma]

Anshul, which device are you using? Which RIL version (commercial vs. open source) are you using?

Comment 10

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

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

Comment 11

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

Attachment: Screenshot: screen flow 1

Comment 12

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

Attachment: Screenshot: screen flow 2

Comment 13

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

Attachment: Screenshot: screen flow 3

Comment 14

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

Attachment: Screenshot: screen flow 4

Comment 15

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

Attachment: Screenshot: screen flow 5

Comment 16

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

Attachment: Screenshot: screen flow 6

Comment 17

[Anshul]

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.

Comment 18

[Anshul]

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

Comment 19

[Fernando Jiménez Moreno [:ferjm]]

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

Comment 20

[Anshul]

Michael Schwartz, will test on a test setup that supports USSD menu and get back.

Comment 21

[Alex Keybl [:akeybl]]

Milestoning for C2 (deadline of 12/10), as this meets the criteria of "remaining P1 bugs not already milestoned for C1".

Comment 22

[Daniel Coloma:dcoloma]

Removing the blocking-basecamp+ tracking flag until this is confirmed

Comment 23

[Andreas Gal :gal]

Michael, any updates here? I think you guys were investigating.

Comment 24

[Michael Vines [:m1] [:evilmachines]]

(just asked m4 to provide the requested info)

Comment 25

[Michael Schwartz [:m4]]

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.

Comment 26

[Dietrich Ayala (:dietrich)]

Michael, do you have an update on your testing?

Comment 27

[Michael Schwartz [:m4]]

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.

Comment 28

[Daniel Coloma:dcoloma]

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

Comment 29

[Michael Vines [:m1] [:evilmachines]]

Can't reproduce this issue anymore.   We'll file a new issue if needed.  Thanks all!!