1056535 - [B2G][RIL] should view *225#4384903113430962# as a full string USSD

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Vendcom, defect)

Description

[Diego Urdiales]

This issue has been reported by movistar Colombia. It cannot be reproduced while in roaming due to restrictions on roaming for prepaid SIM cards in Colombia; thus, only under movistar Colombia coverage.

It has been tested by movistar Colombia using commercial terminals: both ZTE Open and Alcatel 4012, with FxOS 1.1

1. Use a FxOS phone with movistar Colombia prepaid SIM card
2. Open the dialer
3. Dial a topup USSD command. These commands follow this pattern: *225#topupcode# where topupcode is 16-digit long. Example: *225#4384903113430962#

Expected result: a message informing of the successful topup appears
Actual result: a message "Recarga no existosa" (unsuccessful topup) appears

The cause may have to do with a limitation in the length of USSD commands.

Comment 1

[Marcelino Veiga Tuimil [:sonmarce]]

[Blocking Requested - why for this release]:

Comment 2

[Marcelino Veiga Tuimil [:sonmarce]]

This is a certification blocker for 1.3 in Colombia, but I find no option to ask for 1.3+. What can I do to include in 1.3 triage?

Comment 3

[Marcelino Veiga Tuimil [:sonmarce]]

[Blocking Requested - why for this release]:

Asking also to be 2.0+ for future releases

Comment 4

[bhavana bajaj [:bajaj]]

(In reply to Marcelino Veiga Tuimil [:sonmarce] from comment #2)
> This is a certification blocker for 1.3 in Colombia, but I find no option to
> ask for 1.3+. What can I do to include in 1.3 triage?

Its to late for us to work on any 1.3 or 1.4 or 2.0 issue. But given this is a cert blocker we can try and fix this in 2.0 based on the effort needed here.

Comment 5

[Anthony Ricaud (:rik)]

Diego: Can you check if this happening on v2.0 in Colombia?

Comment 6

[Anthony Ricaud (:rik)]

Hsin-Yi: Do you know if our Gecko/RIL could have any limitation in the length of USSD commands?

Comment 7

[Diego Urdiales]

Anthony, it is hard for us to reproduce it with 2.0 because we don't have a development team in Colombia, only the local Devices team, which has access to commercial and certification builds and terminals only. Nevertheless, we are trying to find ways to reproduce it locally - we will report any progress.

Comment 8

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Anthony Ricaud (:rik) from comment #6)
> Hsin-Yi: Do you know if our Gecko/RIL could have any limitation in the
> length of USSD commands?

Okay, I know what's going on here. There's no limitation in the length of USSD commands. So, we don't have problem with the length concern.

But, mozRIL MMI parser did something wrong. In this case, "*225#4384903113430962#" should be viewed as a 'fullMMI' but our parser results in {"fullMMI":"*225#","procedure":"*","serviceCode":"225","dialNumber":"4384930113430962"} that is wrong.

Comment 9

[Anthony Ricaud (:rik)]

Ah nice finding Hsin-Yi. I guess this will help resolve this a lot faster :)

Moving to RIL component.

Comment 11

[Diego Urdiales]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #8)
> But, mozRIL MMI parser did something wrong. In this case,
> "*225#4384903113430962#" should be viewed as a 'fullMMI' but our parser
> results in
> {"fullMMI":"*225#","procedure":"*","serviceCode":"225","dialNumber":
> "4384930113430962"} that is wrong.

Just in case it is relevant: this bug was detected in commercial terminals, which as far as I know are using the Qualcomm RIL not Mozilla's. Therefore, if this is purely a RIL issue, it means it is likely happening with the Qualcomm RIL too, right?

Comment 12

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Diego Urdiales from comment #11)
> (In reply to Hsin-Yi Tsai [:hsinyi] from comment #8)
> > But, mozRIL MMI parser did something wrong. In this case,
> > "*225#4384903113430962#" should be viewed as a 'fullMMI' but our parser
> > results in
> > {"fullMMI":"*225#","procedure":"*","serviceCode":"225","dialNumber":
> > "4384930113430962"} that is wrong.
> 
> Just in case it is relevant: this bug was detected in commercial terminals,
> which as far as I know are using the Qualcomm RIL not Mozilla's. Therefore,
> if this is purely a RIL issue, it means it is likely happening with the
> Qualcomm RIL too, right?

I am not sure if anything suspicious on gaia side, Anthony might be able to answer this.

Also NI Vance for help to check with partner as this was reported on qcRIL. Thanks!

Comment 13

[Diego Urdiales]

A colleague just tested with a Flame device with master, eng build and [Qualcomm RIL 1.0]. Inputting the same USSD code, he saw a log trace with the same parsing:

I/Gecko   ( 7841): RIL Worker: [0] MMI {"fullMMI":"*225#","procedure":"*","serviceCode":"225","dialNumber":"4384903113430962"}

Comment 14

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Diego Urdiales from comment #13)
> A colleague just tested with a Flame device with master, eng build and
> [Qualcomm RIL 1.0]. Inputting the same USSD code, he saw a log trace with
> the same parsing:
> 
> I/Gecko   ( 7841): RIL Worker: [0] MMI
> {"fullMMI":"*225#","procedure":"*","serviceCode":"225","dialNumber":
> "4384903113430962"}

The log was coming from mozRIL, I believe.

Comment 15

[Joshua Mitchell (Inactive)]

QA-wanted team is located in WA, I don't think we can be much help here; removing tag.

Comment 16

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Anshul -

Mind taking a look at this one? not sure if the long format ussd string such as *225#4384903113430962# is supported...

Thanks!

Comment 17

[Anshul]

Reporter, please file a SR so we can investigate.

Comment 18

[Ken Chang[:kenkai]]

According to Comment 12, change component to vendcom. After getting feedback, we can know this bug belongs to which components.

Comment 19

[Beatriz Rodríguez [:brg]]

(In reply to Anshul from comment #17)
> Reporter, please file a SR so we can investigate.
Issue reported: TELEFONICA-2

Comment 20

[Jason Smith [:jsmith]]

Dropping blocking flag since this is a vendor bug.

Comment 21

[Anshul]

Fix has been provided to the reporter.