868346 - [Buri][Shira-48919] Only show single brand (postpaid or prepaid) APN in list to match SIM provider

Status: RESOLVED WONTFIX

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

Description

[sync-1]

+++ This bug was initially created as a clone of Bug #448907 +++
 
 Description: 
 On APN's list there are visible APN's for Postpaid and prepaid service (T-Mobile.pl and heyahinternet). Second APN is other brand and should not be visible for customer (if inserted card is T-Mobile card and conversely).
 
 
 Customer Impact Statement: 
 
 
 
 Expected Behaviour: 
 On APN's list should be visible only APN complies with card inserted
 
 DT Must-Fix = Launch blocker!
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
 
 
 AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.080
 Firefox os  v1.0.1
 Mozilla build ID:20130418070206
 
 ++++++++++ end of initial bug #448907 description ++++++++++
 
 
 
 CONTACT INFO (Name,Phone number):
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[Daniel Coloma:dcoloma]

Don't understand the description of the bug, we need clear info about what is expected and what is happening. Please renominate with that information. 

I am also seeing that the build is quite old: 04.18. Can you report with a more recent build (I know you have a more recent one)

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

We're currently listing all the available APNs on a network. Questions:

1. Does this allow a user to go into a 'roaming' state even if they could have been on their provider's network?

2. Is there a reason (from product perspective) to show all APN settings available?

Comment 3

[Peter Dolanjski [:pdol]]

(In reply to [e-mail] from comment #2)
> 1. Does this allow a user to go into a 'roaming' state even if they could
> have been on their provider's network?

Who can answer this?  Vicamo?

> 2. Is there a reason (from product perspective) to show all APN settings
> available?

Not from my perspective.

Comment 4

[Vicamo Yang [:vicamo][:vyang]]

(In reply to Peter Dolanjski [:pdol] from comment #3)
> (In reply to [e-mail] from comment #2)
> > 1. Does this allow a user to go into a 'roaming' state even if they could
> > have been on their provider's network?
> Who can answer this?  Vicamo?

APN list are maintained in Gaia `shared/resources/apn.json` and its elements should have the same mcc/mnc with ICC. Both T-Mobile.pl and heyahinternet have mcc/mnc 260/20. So is there any method we can have to distinguish them from each other and expose necessary information for Gaia?

Comment 5

[Daniel Coloma:dcoloma]

Based on the new description I think this a new feature. Indeed we highlighted this same problem a while ago as a similar problem is occurring for TEF with virtual operators and the decision was not supporting this in 1.0.1. I'd suggest we TEF- it

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

Agreed, new feature - will put this in scrum backlog.

Comment 7

[Cheng-An, XIONG]

(In reply to [e-mail] from comment #6)
> Agreed, new feature - will put this in scrum backlog.

Andreas,

would you confirm not fix is acceptable or not?

thanks

Comment 8

[Amelie Kong]

Feedback from customer:

Branding is very important for us and PL marketing wants
this to be clear to customer that they are with Tmobile. Please fix this till
launch.

So I change it to tef? again.

Comment 9

[Joe Cheng [:jcheng] (please needinfo)]

anything that can be used to distinguish between prepaid and postpaid SIMs? other than MCC/MNC? thanks

Comment 10

[Joe Cheng [:jcheng] (please needinfo)]

anything on the SIM i mean

Comment 11

[Amelie Kong]

To solve this you need to use some condition, for example:
If the SPN is filled, contains the name of the network HEYAH (68 65 79 61 68 )
terminal should display only APN's for HEYAH brand
If SPN is empty, terminal should only display APN's for T-Mobile.pl
Note, that this is only sugestion

Comment 12

[Joe Cheng [:jcheng] (please needinfo)]

tef+ per shira carrier comment
to vicamo for now, do you think this can be fixed given comment 11? thanks

Comment 13

[Vicamo Yang [:vicamo][:vyang]]

(In reply to Amelie Kong from comment #11)
> To solve this you need to use some condition, for example:
> If the SPN is filled, contains the name of the network HEYAH (68 65 79 61 68)
> terminal should display only APN's for HEYAH brand
> If SPN is empty, terminal should only display APN's for T-Mobile.pl
> Note, that this is only sugestion

Could you confirm SPN names are different on SIM cards of these two brands? If it is, Gecko has already export SPN info to content through |navigator.mozMobileConnection.iccInfo.spn|, so I guess the implementation will be done in Gaia. Could you provide the SPN names displayed with these SIM cards?

Comment 14

[sync-1]

Created an attachment (id=409240)
 screenshot

Comment 15

[sync-1]

Attachment: screenshot

Created an attachment (id=409240)
 screenshot

Comment 16

[sync-1]

With simulated sim card, PLMN=26002
 
 1.SPN is empty, APN list as below:
 Diablo PB9+FP :  Internet, MMS
 Bettle Lite FF: T-mobile.pl, heyahinternet
 
 2.SPN is filled with T-Mobile, APN list as below:
 Diablo PB9+FP :  Internet, MMS
 Bettle Lite FF: T-mobile.pl, heyahinternet
 
 No matter the SPN is filled or not, on Diablo PB9+FP, Bettle Lite FF, the APN
 keeps no difference.

Comment 17

[Amelie Kong]

Please refer to comment 11.
suggest solution is:

for PLMN = 26002, we have two APN available now:  T-mobile.pl, heyahinternet .
But, we don't want them to be shown together. So please check SPN when PLMN = 26002,
(1)if SPN = HEYAH (68 65 79 61 68 ), only show "heyahinternet"
(2)If no SPN  , only show "T-mobile.pl"

Comment 18

[Joe Cheng [:jcheng] (please needinfo)]

this requires a gaia fix, unassign from vicamo

Comment 19

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Amelie Kong from comment #17)

SPN information is not considered for showing the APN settings for the SIM inserted. We could use that info for filtering better and showing only the APN settings whose `carrier` property value matches the carrier name in the SPN ICC card field but I'm afraid the `carrier` property value from the `apn.json` database could mismatch and we would run into a problem and no APN settings will be showed. 

> Please refer to comment 11.
> suggest solution is:
> 
> for PLMN = 26002, we have two APN available now:  T-mobile.pl, heyahinternet
> .
> But, we don't want them to be shown together. So please check SPN when PLMN
> = 26002,
> (1)if SPN = HEYAH (68 65 79 61 68 ), only show "heyahinternet"
> (2)If no SPN  , only show "T-mobile.pl"

IMHO we should provide general solutions to problems in upstream code, and the solution you provide is quite specific for this case. For example, AOSP does the same I mean it shows all the APN setting matching MCC/MNC codes in the APN database.

IHMO I would resolve this bug as WONTFIX because this behavior don't seen wrong to me in the reference implementation. It seems this bug fits better for branding stuff.

Comment 20

[:gerard-majax]

On Android, it displays the full list, in a similar manner as what is reported as a bug here.

Comment 21

[:gerard-majax]

Daniel, what should we do, since Android does the same ?

Comment 22

[Daniel Coloma:dcoloma]

As jaoo commented in comment 19 we don't believe this is a bug but a customisation request. The current solution is the expected solution for a generic Operating System. If the MCC/MNC pair can be used with multiple combinations, it is logical to expose all of them to the user so he can select the right one. I think anything beyond that should be part of vendor/partner customisation, but not part of the mainstream. 

Triagers (lsblakk and myself) already marked this as tef-. It was Joe Cheng who marked it as tef+ despite our recommendation, so I think he should be the one deciding how to move forward on this thing. My recommendation is to make this Part of Vendor Build so that vendors can do it based on their partner requests.

Maybe Kaze can also shed some light here.

Comment 23

[Fabien Cazenave [:kaze]]

Last time we met, jaoo and I had a talk about the case where one MCC/MNC pair matches several APN items. We concluded that the best we could do was to check the SIM card SPN info and do a fuzzy match to *pre-select* the APN item (from the apn.json list) that is the most likely to be the one in the SIM card.

This method should cover /most/ cases, but it certainly won’t work in /all/ cases (as jaoo wrote in comment #19); that’s one of the reasons why we need to show the list of matching APN items.

(In reply to Amelie Kong from comment #11)
> To solve this you need to use some condition, for example:
> If the SPN is filled, contains the name of the network HEYAH (68 65 79 61 68)
> terminal should display only APN's for HEYAH brand
> If SPN is empty, terminal should only display APN's for T-Mobile.pl
> Note, that this is only sugestion

I agree with Daniel that it’s not a suitable approach for a generic OS, that’s why we propose to just pre-select the proper APN. I think this method would address the concerns for this specific case: the match should be fine, which means that the device will be connected as soon as it boots on this SIM card without any pre-configuration — and I doubt any user will look further in the APN settings to change something that works.

Comment 24

[Joe Cheng [:jcheng] (please needinfo)]

Amelie, are you able to make the change as a customization on your build? thanks

Comment 25

[Amelie Kong]

OK, we can take it.

Comment 26

[:gerard-majax]

(In reply to Amelie Kong from comment #25)
> OK, we can take it.

So I unassign myself from this bug?

Comment 27

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Alexandre LISSY :gerard-majax from comment #26)
> (In reply to Amelie Kong from comment #25)
> > OK, we can take it.
> 
> So I unassign myself from this bug?

I think so and even to resolve this bug as WONTFIX. Am I right?

Comment 28

[:gerard-majax]

David told me he will look into retriage this.

Comment 29

[David Scravaglieri [:scravag]]

No need to retriage. WONTFIX as per comment 24 and 25