Closed Bug 1049908 Opened 10 years ago Closed 10 years ago

Recognize EF_SPNs and show the right operator shelf

Categories

(Marketplace Graveyard :: Consumer Pages, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED FIXED
2014-09-02

People

(Reporter: clouserw, Assigned: mat)

References

Details

(Whiteboard: [qa+])

Background:  We detect what MNO (Mobile Network Operator) a user is on based on the standard MCC and MNC codes.  However, there is a thing called an MVNO, that is, a Mobile Virtual Network Operator.  There are a zillion of these and basically it happens when the parent operator resells its network to another company.  For example, Consumer Cellular and Cricket Wireless are both AT&T, GoSmart Mobile is T-Mobile, Ting is Sprint, etc.

If someone on Ting comes to our Marketplace we'd show them the Sprint operator shelf because that's what their MCC and MNC report.  Enter the SPN.  In bug 1027430 the SPN was appended to mozMobileConnections and when a user is on an MVNO there will be a value there we should detect.  For now, let's differentiate DT and Congstar and make sure everything is working.  The codes are:

Congstar: 
> xx636F6E6773746172FFFFFFFFFFFFFFFF
> xx636F6E67737461722E6465FFFFFFFFFF

DT: 
> xx54656C656B6F6D2E6465FFFFFFFFFFFF
> xx542D4D6F62696C652044FFFFFFFFFFFF
> xx427573696E657373FFFFFFFFFFFFFFFF
> xx507269766174FFFFFFFFFFFFFFFFFFFF


Marking as a P1 because this API just landed on the client side and if there is a problem with it we should get it fixed ASAP.  See bug 1027430 for notes/discussion on it.
Assignee: nobody → mpillard
I tested with my flame that I just updated.

I don't have a SIM card from a MVNO at the moment, but the additional data exposed by navigator.mozMobileConnections[x].lastKnownHomeNetwork doesn't seem to help in our case. I expected either nothing or an hexadecimal string like the one you gave above, but with the 2 SIM cards (from Orange and Siminn respectively, both "real" network operators in their respective countries AFAIK) I had with me, I saw:

navigator.mozMobileConnections[0].lastKnownHomeNetwork
"208-01-Orange F"

navigator.mozMobileConnections[1].lastKnownHomeNetwork
"274-01-Siminn"

The 3rd parameter is here but it looks like the name of the network instead ? I am not sure this is something we can rely on, so I guess either this is not the data we asked for or what we asked for was incorrect.
Flags: needinfo?(clouserw)
Hmm.  I got the hex numbers from David.

David - would you confirm that you'd expect to see the hex numbers here?

Hsin-Yi - would you confirm what data you'd expect to see here?
Flags: needinfo?(htsai)
Flags: needinfo?(dalmstrom)
Flags: needinfo?(clouserw)
(In reply to Wil Clouser [:clouserw] from comment #2)
> Hmm.  I got the hex numbers from David.
> 
> David - would you confirm that you'd expect to see the hex numbers here?
> 
> Hsin-Yi - would you confirm what data you'd expect to see here?

A string, service provider name, as what we exposed to nsIDOMIccInfo [1].

[1] http://dxr.mozilla.org/mozilla-central/source/dom/icc/interfaces/nsIDOMIccInfo.idl?from=nsIDOMIccInfo.idl&case=true#35
Flags: needinfo?(htsai)
My only datapoint was from DT who provided us with HEX. I need to verify with TEF as well if they do so.
-> David to sort out what we should do here.  Either they strings are right and we can use them, or the hex numbers are right and we'll need to adjust the patch that landed in moz-central.
Assignee: mpillard → dalmstrom
Adding Karen and Tony A to the thread as well
[Blocking Requested - why for this release]: This is needed to differentiate networks.
blocking-b2g: --- → 2.1?
There is a (small) chance that this is working correctly.  It could be that Orange F is simply the name of the network in France and xx54656C656B6F6D2E6465FFFFFFFFFFFF is the name in Germany.  In order to confirm or deny that, we need to get a German SIM that we can test this with.  David is going to connect with Karen to make that happen.
It looks like a format issue. How about taking advantage of String.fromCharCode() if the data from carrier is hex number?

So, for xx54656C656B6F6D2E6465FFFFFFFFFFFF, the string name got from |String.fromCharCode(0x54, 0x65, 0x6C, 0x65, 0x6B, 0x6F, 0x6D, 0x2E, 0x64, 0x65)| is "Telekom.de".
Ah, didn't think of that! I was expecting that hex number to be some kind of unique identifier... That should be it then. I'm still worried that this won't work for all MVNOs, but at least I can give it a try.
Assignee: dalmstrom → mpillard
Flags: needinfo?(dalmstrom)
(In reply to Mathieu Pillard [:mat] from comment #10)
> Ah, didn't think of that! I was expecting that hex number to be some kind of
> unique identifier... That should be it then. I'm still worried that this
> won't work for all MVNOs, but at least I can give it a try.

It should work for all MVNOs unless we have different definitions of EF_SPN. :) But let me know if I miss anything!
Depends on: 1056088
It should probably work correctly for DT in Germany. There is no standard for this, it seems like. I talked with Sony Mobile today and one of the guys told me that the SIM card is a storage for information that can be read - so we read the standardized MCC/MNC to identify country and network. But as vendors add more memory, the operators start using the SIM card for more than just MCC/MNC -  some tried information portals (like WAP-style) but DT uses this to throw in additional information and in this case, which type of consumer. One of the HEX numbers identify which type of services they have (DT Business, DT post-paid consumer, prepaid, etc. and Congstar).

As it doesn't seem to be a standard we may have to either i) do a manual mapping to an operator shelf or ii) display the same operator shelf for one network (not ideal).
(In reply to David Almström from comment #12)
> It should probably work correctly for DT in Germany. There is no standard
> for this, it seems like. I talked with Sony Mobile today and one of the guys
> told me that the SIM card is a storage for information that can be read - so
> we read the standardized MCC/MNC to identify country and network. But as
> vendors add more memory, the operators start using the SIM card for more
> than just MCC/MNC -  some tried information portals (like WAP-style) but DT
> uses this to throw in additional information and in this case, which type of
> consumer. One of the HEX numbers identify which type of services they have
> (DT Business, DT post-paid consumer, prepaid, etc. and Congstar).
> 
> As it doesn't seem to be a standard we may have to either i) do a manual
> mapping to an operator shelf or ii) display the same operator shelf for one
> network (not ideal).

Yup, for MVNOs, operators might use various data to identify services. Common mvno types are "spn", "imsi" and "gid". "spn" is one of them. So I guess in marketplace there needs a database for the mapping between operator and mvno type, just like [1].

[1] https://github.com/mozilla-b2g/gaia/blob/master/shared/resources/apn.json
Ah, but that was my concern above: How do we find out the "imsi" and "gid" for MVNOs that use that and not the "spn" ?
(In reply to Mathieu Pillard [:mat] from comment #14)
> Ah, but that was my concern above: How do we find out the "imsi" and "gid"
> for MVNOs that use that and not the "spn" ?

We have |mozIcc.matchMvno(DOMString mvnoType, DOMString matchData);| for certified apps for this purpose. But imsi is critical data and we have security concerns on exposing the value to non-certified apps... so we will need to work with security team and see how we could provide it to 3rd party app... ...
Ok, well, the SPN in LastKnownHomeNetwork should be enough for now - we might need to have a conversation about how we handle other MVNOs that use a different data to differentiate themselves, but that doesn't necessarily block us *now*.

I still need a congstar and/or DT SIM to test this properly, but I added the code to use the SPN to detect MVNOs, starting with congstar in Germany: https://github.com/mozilla/fireplace/pull/585
Thanks for the explanations.  That's good information to know about IMSI and GID.

I filed bug 1056951 to get the MVNO identification type on our operator intake form so we'll get an early heads up about this next time.  Thanks.
Status: NEW → ASSIGNED
Fixed in https://github.com/mozilla/fireplace/commit/e7d8233a3c993676ba7502425e345f4fa0a537da

I'm marking this as QA+ to get attention from krupa and see if she has ideas about how to QA this. I tested it myself with a congstar & DT SIM, and it works, but it'd be nice to have real QA.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [qa+]
Target Milestone: --- → 2014-09-02
blocking-b2g: 2.1? → ---
So, the ideal way to test this would be to have a Congstar and german DT SIM. I don't think anyone else other than me has one, so just verify using the query string parameters:

- When going to https://marketplace.firefox.com/?mcc=262&mnc=1&spn=congstar and then :debug page, you should see the region set to germany and carrier set to congstar

- When going to https://marketplace.firefox.com/?mcc=262&mnc=1&spn=congstar.de and then :debug page, you should see the region set to germany and carrier set to congstar

- When going to https://marketplace.firefox.com/?mcc=262&mnc=1 and then :debug page, you should see the region set to germany and carrier set to deutsche_telekom

- When going to https://marketplace.firefox.com/?mcc=262&mnc=2 and then :debug page, you should see the region set to germany and carrier set to deutsche_telekom

If all four work then it's verified.

Side note: unfortunately when this patch was made I was working under the assumption that we were going to push the real packaged app in Firefox OS 2.1. If that's not the case, then we'll need to re-open to patch the packaged iframe as well.
Verified all scenarios and everything worked as expected.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.