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)
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.
Updated•10 years ago
|
Assignee: nobody → mpillard
Assignee | ||
Comment 1•10 years ago
|
||
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)
Reporter | ||
Comment 2•10 years ago
|
||
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)
Comment 3•10 years ago
|
||
(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)
Comment 4•10 years ago
|
||
My only datapoint was from DT who provided us with HEX. I need to verify with TEF as well if they do so.
Reporter | ||
Comment 5•10 years ago
|
||
-> 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
Comment 6•10 years ago
|
||
Adding Karen and Tony A to the thread as well
Reporter | ||
Comment 7•10 years ago
|
||
[Blocking Requested - why for this release]: This is needed to differentiate networks.
blocking-b2g: --- → 2.1?
Reporter | ||
Comment 8•10 years ago
|
||
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.
Comment 9•10 years ago
|
||
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".
Assignee | ||
Comment 10•10 years ago
|
||
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)
Comment 11•10 years ago
|
||
(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!
Comment 12•10 years ago
|
||
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).
Comment 13•10 years ago
|
||
(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
Assignee | ||
Comment 14•10 years ago
|
||
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" ?
Comment 15•10 years ago
|
||
(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... ...
Assignee | ||
Comment 16•10 years ago
|
||
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
Reporter | ||
Comment 17•10 years ago
|
||
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.
Assignee | ||
Updated•10 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 18•10 years ago
|
||
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
Updated•10 years ago
|
blocking-b2g: 2.1? → ---
Assignee | ||
Comment 19•10 years ago
|
||
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.
Comment 20•10 years ago
|
||
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.
Description
•