Closed Bug 729440 Opened 12 years ago Closed 12 years ago

B2G 3G: Automatically configure datacall parameters

Categories

(Core :: DOM: Device Interfaces, defect)

Product:
Core
Component:
DOM: Device Interfaces
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: philikon, Assigned: allstars.chh)

References

Details

Attachments

(2 files, 1 obsolete file)

[WIP] Part 1 : Add serviceproviders.json
409.34 KB, patch
philikon
: feedback-
Details | Diff | Splinter Review
[WIP] Part 2: configure datacall parameters
6.47 KB, patch
Details | Diff | Splinter Review 
There are apparently databases with APN, username, password, etc. around, e.g. http://live.gnome.org/NetworkManager/MobileBroadband/ServiceProviders. We should see if we could ship with their data (especially if it's public domain).
It's public domain; I'm the maintainer. It's not actually a GNOME project, it just happened I had git rights on git.gnome.org.  The database is fairly frequently updated when users submit new APNs.

Happy to work with Mozilla if you guys need anything (within reason) added to the DTD.  Some random points:

1) we don't have a good list of MMS APNs; those would be great to have as well.  We don't have lists of WAP proxies and APNs because devices that are only WAP-capable aren't really the target of the database.

2) There are a number of APN databases floating around, including one from Cyanogen.  No database is complete, but at least we try to do some basic verification of the APN information and it's type (ie, prepaid, postpaid, etc) before adding it.  I think the Cyanogen stuff is just stored on a wiki that anyone can edit.

3) Devices may come with stored APNs.  When you run AT+CGDCONT=? you're getting a list in the *device's* NVRAM, not the SIM.  APNs are not stored on SIMs.  When you get a device from the operator, they will typically preconfigure the APNs for you, but that's not always the case.  Sometimes the settings get delivered via SMS message after you sign up, especially outside the US where unlocked phones are the norm.

4) You don't always need an APN; often you can start the connection with a blank APN and if the operator is set up correctly, the call will work because they map your IMSI to an APN in their backends if none is given.  This is called the "default APN".  But it depends on your provider.  T-Mobile in the US appears to support this from my testing.
More notes: listing DNS servers in the XML is actually pointless, I wish we hadn't done that.  Since your DNS servers are delivered by the radio anyway, and must be up-to-date on the operator side, it's pointless to have them statically specified.  Same for "gateway".

Also, if you get the IMSI from the RIL, you can use the first few digits to filter the list of providers based on MCC/MNC.  It's also quite helpful to know (by asking the SIM) how many digits the provider's MNC is: either 2  or 3.  Then you can further filter the list and show only APNs that are relevant to that user's SIM.

Alternatively, if the radio is already registered, you can grab the MCC/MNC and use that, as long as the user isn't roaming.
Dan, thanks for your helpful posts (and apologies for the late response.)

(In reply to Dan Williams from comment #1)
> It's public domain; I'm the maintainer. It's not actually a GNOME project,
> it just happened I had git rights on git.gnome.org.  The database is fairly
> frequently updated when users submit new APNs.

Perfect! On the website I couldn't find an obvious way to download the db... could you point us to the repository, perhaps?

> 3) Devices may come with stored APNs.  When you run AT+CGDCONT=? you're
> getting a list in the *device's* NVRAM, not the SIM.  APNs are not stored on
> SIMs.  When you get a device from the operator, they will typically
> preconfigure the APNs for you, but that's not always the case.

Interesting. Will have to check if the RIL exposes this as a request type. In any case it seems like a low-priority feature.

> Sometimes
> the settings get delivered via SMS message after you sign up, especially
> outside the US where unlocked phones are the norm.

Yup, I've seen operators in Germany do that. You click on a button on the website and it sends you a text tailoured to yoru phone. Would be nice to support that.

> 4) You don't always need an APN; often you can start the connection with a
> blank APN and if the operator is set up correctly, the call will work
> because they map your IMSI to an APN in their backends if none is given. 
> This is called the "default APN".  But it depends on your provider. 
> T-Mobile in the US appears to support this from my testing.

Oh, interesting! Would be useful to know how commonly that's supported.

Looping in some of our operator contacts... Jose, Markus: can you guys find out and and shed some light on points (3) and (4) from your point of view? Thanks!
The database is stored in git here:

http://git.gnome.org/browse/mobile-broadband-provider-info/

and periodically we do snapshots, though they are infrequent.  It's versioned by date since I don't think version numbers make a ton of sense here.  I suppose we could start kicking out monthly snapshots too just for some consistency.

If you find you need anything of the schema, feel free to ask and we can figure out how to provide that functionality.
Assignee: nobody → yhuang
(In reply to Philipp von Weitershausen [:philikon] from comment #3)
> > 3) Devices may come with stored APNs.  When you run AT+CGDCONT=? you're
> > getting a list in the *device's* NVRAM, not the SIM.  APNs are not stored on
> > SIMs.  When you get a device from the operator, they will typically
> > preconfigure the APNs for you, but that's not always the case.
> 
> Interesting. Will have to check if the RIL exposes this as a request type.
> In any case it seems like a low-priority feature.

After taking a quick look at this RIL does not expose this as request
type. Trying to figure it out much deepper the "AT+CGDCONT?" command should be
sent (I guess) by the RIL propietary implementation for the
RIL_UNSOL_DATA_CALL_LIST_CHANGED and RIL_REQUEST_DATA_CALL_LIST RIL requests. I
figured this out while surfing the RIL code (see [1]).

> > Sometimes
> > the settings get delivered via SMS message after you sign up, especially
> > outside the US where unlocked phones are the norm.
> 
> Yup, I've seen operators in Germany do that. You click on a button on the
> website and it sends you a text tailoured to yoru phone. Would be nice to
> support that.

This configuration mechanism is known as OTA -Over-The-Air programming, a method
of reprogramming smart phones and other mobile devices (source: wikipedia)- and
it has to be supported by the target device. I would be nice to support it on
B2G. What about to file a meta bug for this functionality?

A collegue of mine told me Telefonica supports it on every phone delivered by
the company but it needs confirmation.
 
> > 4) You don't always need an APN; often you can start the connection with a
> > blank APN and if the operator is set up correctly, the call will work
> > because they map your IMSI to an APN in their backends if none is given. 
> > This is called the "default APN".  But it depends on your provider. 
> > T-Mobile in the US appears to support this from my testing.
> 
> Oh, interesting! Would be useful to know how commonly that's supported.

I did not about that mechanism. It also needs confirmation because I do not know
if Telefonica supports it. I guess it does not because while playing with data
calls I could experience it is not supported. Sometimes I tried to establish a
data call without any APN configuration and it falied.

--
[1] https://github.com/mozilla-b2g/android-hardware-ril/blob/b2g-gingerbread/reference-ril/reference-ril.c#L305
(In reply to Philipp von Weitershausen [:philikon] from comment #3)
> Dan, thanks for your helpful posts (and apologies for the late response.)
> 
> (In reply to Dan Williams from comment #1)
> > It's public domain; I'm the maintainer. It's not actually a GNOME project,
> > it just happened I had git rights on git.gnome.org.  The database is fairly
> > frequently updated when users submit new APNs.
> 
> Perfect! On the website I couldn't find an obvious way to download the db...
> could you point us to the repository, perhaps?
> 
> > 3) Devices may come with stored APNs.  When you run AT+CGDCONT=? you're
> > getting a list in the *device's* NVRAM, not the SIM.  APNs are not stored on
> > SIMs.  When you get a device from the operator, they will typically
> > preconfigure the APNs for you, but that's not always the case.
> 
> Interesting. Will have to check if the RIL exposes this as a request type.
> In any case it seems like a low-priority feature.
> 
> > Sometimes
> > the settings get delivered via SMS message after you sign up, especially
> > outside the US where unlocked phones are the norm.
> 
> Yup, I've seen operators in Germany do that. You click on a button on the
> website and it sends you a text tailoured to yoru phone. Would be nice to
> support that.
> 
> > 4) You don't always need an APN; often you can start the connection with a
> > blank APN and if the operator is set up correctly, the call will work
> > because they map your IMSI to an APN in their backends if none is given. 
> > This is called the "default APN".  But it depends on your provider. 
> > T-Mobile in the US appears to support this from my testing.
> 
> Oh, interesting! Would be useful to know how commonly that's supported.
> 
> Looping in some of our operator contacts... Jose, Markus: can you guys find
> out and and shed some light on points (3) and (4) from your point of view?
> Thanks!

Got a reply from the T-Mobile US guys. As of now APNs are preconfigured in the system
image. OTA configuration, "default" APN and APN on the SIM isn't supported by them.
hey guys:
Thanks for your responses, that helps me to know where to start with. 
I guess I'll go with:
1. get MCC[1] and MNC[2]: This value is the 3rd argument returned from REQUEST_OPERATOR, 
   or the prefix of IMSI, for retrieving MNC that means I need to get its length first, 
   the value is in the 4th byte of the response of EF_AD[3], 
   so I am gonna file a new Bug for getting EF_AD first.

2. If we can get MCC and MNC successfully, then I need to figure out how to lookup the apn, username and password from the service database by using MCC and MNC

thanks

[1]MCC: http://en.wikipedia.org/wiki/Mobile_Country_Code
[2]MNC: http://en.wikipedia.org/wiki/Mobile_Network_Code
[3]EF_AD: TS 31.102, clause 4.2.18
(In reply to Markus Neubrand from comment #6)
> (In reply to Philipp von Weitershausen [:philikon] from comment #3)
> > Dan, thanks for your helpful posts (and apologies for the late response.)
> > 
> > (In reply to Dan Williams from comment #1)
> > > It's public domain; I'm the maintainer. It's not actually a GNOME project,
> > > it just happened I had git rights on git.gnome.org.  The database is fairly
> > > frequently updated when users submit new APNs.
> > 
> > Perfect! On the website I couldn't find an obvious way to download the db...
> > could you point us to the repository, perhaps?
> > 
> > > 3) Devices may come with stored APNs.  When you run AT+CGDCONT=? you're
> > > getting a list in the *device's* NVRAM, not the SIM.  APNs are not stored on
> > > SIMs.  When you get a device from the operator, they will typically
> > > preconfigure the APNs for you, but that's not always the case.
> > 
> > Interesting. Will have to check if the RIL exposes this as a request type.
> > In any case it seems like a low-priority feature.
> > 
> > > Sometimes
> > > the settings get delivered via SMS message after you sign up, especially
> > > outside the US where unlocked phones are the norm.
> > 
> > Yup, I've seen operators in Germany do that. You click on a button on the
> > website and it sends you a text tailoured to yoru phone. Would be nice to
> > support that.
> > 
> > > 4) You don't always need an APN; often you can start the connection with a
> > > blank APN and if the operator is set up correctly, the call will work
> > > because they map your IMSI to an APN in their backends if none is given. 
> > > This is called the "default APN".  But it depends on your provider. 
> > > T-Mobile in the US appears to support this from my testing.
> > 
> > Oh, interesting! Would be useful to know how commonly that's supported.
> > 
> > Looping in some of our operator contacts... Jose, Markus: can you guys find
> > out and and shed some light on points (3) and (4) from your point of view?
> > Thanks!
> 
> Got a reply from the T-Mobile US guys. As of now APNs are preconfigured in
> the system
> image. OTA configuration, "default" APN and APN on the SIM isn't supported
> by them.

I think they're wrong, or not quite understanding what I mean.  Here's what I mean:

ETSI 27.007 v9.20, 10.1.1 (Define PDP Context +CGDCONT)
------------
Defined values:
...
<APN>: a string parameter which is a logical name that is used to select the GGSN or the external packet data
network.
If the value is null or omitted, then the subscription value will be requested.
------------

I've also seen this described as a "Network-provided APN".  I've just tested a blank APN my T-Moblie US SIM and a Sierra dongle:

AT+CGDCONT?
+CGDCONT: 1,"IP","INTERNET.COM","",0,0
+CGDCONT: 2,"IP","internet2.voicestream.com","",0,0
(remember, PDP contexts are stored on the device, not the SIM)
OK

AT+CGDCONT=2,"IP",""
(set a NULL/blank PDP context)
OK

AT+CGDCONT?
+CGDCONT: 1,"IP","INTERNET.COM","",0,0
+CGDCONT: 2,"IP","","",0,0
OK

AT+CGATT=1
(attach to the PS network)
OK

AT$QCPDPP=2,1,"fadfasdf","adfadf"
(the PAP/CHAP auth details for PDP context #2)
OK

AT!SCACT=1,2
(start the pseudo-ethernet interface using PDP context #2)
OK

(DHCP now happens wwan0)

at which point I'm perfectly able to use the connection to do anything I want.

This device is actually an unlocked, unbranded, Sierra USB 306 and did not come from T-Mobile, so there's no way that it can contain some APN stored on the device itself.  PDP context #1 (INTERNET.COM) is not a T-Mobile APN either, so there's no chance that context #1 is being used inadvertently.

Given ETSI 27.007 I'd say there's two options:

1) T-Mobile US *is* supplying the default/network-provided APN from the backend
2) The APN is somehow provisioned on the SIM and the device is picking it up automatically

(2) does not seem likely to me since AFAIK there is no provision on the EFS of the SIM for APN storage besides EFacl which is only an APN whitelist; I did find a link to an OMA spec from 2009 for storage of various WAP parameters including the APN (http://member.openmobilealliance.org/ftp/Public_documents/DM/CP/Permanent_documents/OMA-WAP-TS-ProvSC-V1_1-20090728-A.zip).  I'd guess the OMA spec isn't being used here.  I doubt EFacl is being used here because I've tested this same thing on an older T-Mobile US SIM from 2009 (long before epc.tmobile.com) and I was able to use epc.tmobile.com on that SIM even though at the time the T-Mobile APNs were [xxx].voicestream.com.
(In reply to Yoshi Huang[:yoshi] from comment #7)
> hey guys:
> Thanks for your responses, that helps me to know where to start with. 
> I guess I'll go with:
> 1. get MCC[1] and MNC[2]: This value is the 3rd argument returned from
> REQUEST_OPERATOR, 
>    or the prefix of IMSI, for retrieving MNC that means I need to get its
> length first, 
>    the value is in the 4th byte of the response of EF_AD[3], 
>    so I am gonna file a new Bug for getting EF_AD first.
> 
> 2. If we can get MCC and MNC successfully, then I need to figure out how to
> lookup the apn, username and password from the service database by using MCC
> and MNC
> 
> thanks
> 
> [1]MCC: http://en.wikipedia.org/wiki/Mobile_Country_Code
> [2]MNC: http://en.wikipedia.org/wiki/Mobile_Network_Code
> [3]EF_AD: TS 31.102, clause 4.2.18

The problem here is that you'll get many operators using the same MCC/MNC.  This is most common with MVNOs and you'll find it everywhere.  They sell branded SIMs but they don't own the network themselves, they buy data/minutes wholesale from the actual network.  And since the MCC/MNC is the same, you don't know whether say you're using say AldiTalk or blau.de, both of which use EPlus network in Germany.  Thankfully they both have the same APN at this time, but you can't count on that.  One thought here is to grab the SPN from the SIM and perhaps try to match that to something in the database, which would involve reading the SPN from a lot of SIMs and then adding the returned SPN to the correct entries in the DB.

It's unfortunately not simple, but the idea we had when starting the MBPI was that given the MCC/MNC from the SIM, you could at least narrow down the list of providers/plans/APNs and show the user perhaps *three* providers instead of 10.
To rule out device specifics, I tried this with a Huawei E1550 too, and got the same result.  Granted both it and the Sierra use Qualcomm chipsets, but I could try with an Icera-based device or an ST-Ericsson-based one.  I doubt the result would change though.
(In reply to Dan Williams from comment #9)
Hi Dan, 

> The problem here is that you'll get many operators using the same MCC/MNC. 

Thanks for addressing this.
Currently the RIL command REQUEST_OPERATOR
(which is AT Command : AT+COPS=3,0;+COPS?;+COPS=3,1;+COPS?;+COPS=3,2;+COPS?, +COPS: )
will return :
The operator name and MCCMNC code.
We may take these values to get more accurate result, or we could also try to get EF_SPN as you said. 
Or at least we should add API for setting apn manually.

> It's unfortunately not simple, but the idea we had when starting the MBPI

Pardon me , but can you tell me what's MBPI? 

Thanks
Currently there are two ways to get MCC/MNC
1. Read the 3rd argument returned from REQUEST_OPERATOR (AT+COPS).
2. Parse the prefix of IMSI.

But sometimes the result from case 1 may be different from case 2, i.e. in roaming.
For simplicity this bug will focus on non-roaming part, that is, to focus on case 2, retrieving and parsing IMSI. 

For that I'll file a new bug 
1. Fetch SIM record: At least now we need 
  a. EF_AD to get MNC's length 
  b. EF_SPN to get provider's name by Dan William's suggestions.(or perhaps EF_SPDI or EF_PNN)

thanks
File a new bug, Bug 736941 for getting simcard record.
Depends on: 736941
(In reply to Yoshi Huang[:yoshi] from comment #12)
> Currently there are two ways to get MCC/MNC
> 1. Read the 3rd argument returned from REQUEST_OPERATOR (AT+COPS).
> 2. Parse the prefix of IMSI.
> 
> But sometimes the result from case 1 may be different from case 2, i.e. in
> roaming.

Actually these are two completely different things.

#1 is the *registered* network that the device is currently communicating with, whether that's home network, a partner network, or a roaming network.  You should use this to determine the operator name display if none is given by the RIL.  The device will register automatically with this network based on the PLMN tables in the SIM card.

#2 is the MCC/MNC of the operator who sold you the SIM.  It has almost nothing to do with the registered network.  Many operators have multiple MNC codes, but the IMSI only has one MCC/MNC.  For example, when an operator buys another operator they may keep the old MCC/MNC for a while.  Others run multiple MCC/MNCs (US and India are two big examples).

You can only rely on #2 to autoconfigure the datacall parameters.  You cannot rely on #1 to do so because it may not map to the operator that supplied the SIM card.
(In reply to Dan Williams from comment #14)
Hi, Dan 
Great thanks to your explanation. :)
(In reply to Dan Williams from comment #14)
Hi, Dan.
  I got some questions when I try to parse the database.
1. One service provider named "Tatincom", an operator in Russia, it doesn't have mcc & mnc, is that normal?

2. In the provider tag, there's an attribute 'primary=true', I got an example here [1], 
In that case, one of T-Mobile's mcc-mnc has the same code with a provider called "Ben".(both mcc is 204, mnc is 16). So the attribute 'primary=true' is added to indicate that we should always select T-mobile when mcc & mnc got collisions. My question is, in this case, under what circumstance will the MVNO 'Ben' should really be selected, instead of the primary one(T-mobile)? 

Could you kindly help to answer my questions? 

thanks



[1]: https://bugzilla.gnome.org/show_bug.cgi?id=671372
Hi, 
I found the service provider in http://live.gnome.org/NetworkManager/MobileBroadband/ServiceProviders doesn't have entry for mmsc, this might have some problems for the upcoming mms module. 

I pull out apns-conf.xml from an Android phone, (not the apns-conf.xml inside gonk, it only has a few entries), and paste the result here http://pastebin.com/WjiD8V9p , it has met our demand(apn, username, password, mmsc,..etc) and quite simple, where as Gnome NetworkManager has at least 4~5 levels tree depth.

I have discussed with Thinker about this, he said the advantage of the Gnome NetworkManager is it's constantly updated, so we might consider the possibilities to try to add the mmsc, mmsport back to the Gnome NetworkManager(if they agree), and still use gnome NetworkManager as our service provider database.
Or maybe we don't use gnome NetworkManager, instead we push the apns-conf.xml onto device, and b2g will read this apns-conf.xml as normal Android does.

thanks
or we could do like 'extract-files.sh' does when we do 'make config-galaxy-s2',
we could exact out the original apns-conf.xml on device.
At least I think do we really need a constantly updated provider database?
(In reply to Yoshi Huang[:yoshi] from comment #17)
> I found the service provider in
> http://live.gnome.org/NetworkManager/MobileBroadband/ServiceProviders
> doesn't have entry for mmsc, this might have some problems for the upcoming
> mms module.

Yes. See Dan's comment 1: "1) we don't have a good list of MMS APNs;"

> I pull out apns-conf.xml from an Android phone, (not the apns-conf.xml
> inside gonk, it only has a few entries), and paste the result here
> http://pastebin.com/WjiD8V9p , it has met our demand(apn, username,
> password, mmsc,..etc) and quite simple, where as Gnome NetworkManager has at
> least 4~5 levels tree depth.

This information is Apache licensed which is bound to create legal headaches if we integrate it into Gecko. The Gnome database, otoh, is public domain and should allow us to reuse their information without any problems.

> I have discussed with Thinker about this, he said the advantage of the Gnome
> NetworkManager is it's constantly updated, so we might consider the
> possibilities to try to add the mmsc, mmsport back to the Gnome
> NetworkManager(if they agree), and still use gnome NetworkManager as our
> service provider database.

The other advantage is that we can ship this information as part of Gecko rather than making Gecko dependent on an external file (apns-conf.xml). I have no particular opinion on this matter. Both solutions have advantages and drawbacks...

> Or maybe we don't use gnome NetworkManager, instead we push the
> apns-conf.xml onto device, and b2g will read this apns-conf.xml as normal
> Android does.

That would be an option, yes. So long as the file is shipped separately from Gecko.
File a bug for adding mmsc support in Gnome NetworkManager Bugzilla,
Also provide patch for adding mmsc, mmsproxy and mmsport information

https://bugzilla.gnome.org/show_bug.cgi?id=673744
(In reply to Yoshi Huang[:yoshi] from comment #20)
> File a bug for adding mmsc support in Gnome NetworkManager Bugzilla,
> Also provide patch for adding mmsc, mmsproxy and mmsport information
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=673744

We're very happy to add MMS information; ideally split it into a few patches, the first updating the DTD with the various MMS attributes, and any additional ones to add the information for providers we know of.  Since the database does get frequently updated, smaller patches are often better than larger ones, since large ones tend to have lots of conflicts.
Note that we've already got a "mms" attribute for the the <apn> element, so we would likely use a format like this:

<apn value="some.mms.apn">
   <usage type="mms"/>
   --- add in other required attributes
</apn>

One suggestion for the attributes might be:

<mms mmsc="http://mmsc.cingular.com" proxy="wireless.cingular.com" port="80"/>
<mms mmsc="http://216.155.174.84/servlets/mms" proxy="216.155.165.050" port="8080"/>

or really however you want.
(In reply to Dan Williams from comment #21)
> We're very happy to add MMS information; ideally split it into a few
> patches, the first updating the DTD with the various MMS attributes, and any
> additional ones to add the information for providers we know of.  Since the
> database does get frequently updated, smaller patches are often better than
> larger ones, since large ones tend to have lots of conflicts.

Hi Dan,
So the 1st part of my part will be DTD. But what about the patch for serviceprovider.xml? 
Should I provide the mmsc patch 1 by 1 by operator? But in that case I guess there will be about 30~40 patches, I guess.
(In reply to Dan Williams from comment #22)

Hi Dan, 

> Note that we've already got a "mms" attribute for the the <apn> element, so
> we would likely use a format like this:
> 
> <apn value="some.mms.apn">
>    <usage type="mms"/>
>    --- add in other required attributes
> </apn>
> 
From Android, I notice that some apns can be 'mms,default,supl' (multiple types).
But from your database, you have only two types, 'internet' and 'mms'.
Also I notice that for those APNs which can have multiple types, your database has put them into type 'internet'. That's why my patch didn't do this as you suggest.


> One suggestion for the attributes might be:
> 
> <mms mmsc="http://mmsc.cingular.com" proxy="wireless.cingular.com"
> port="80"/>
> <mms mmsc="http://216.155.174.84/servlets/mms" proxy="216.155.165.050"
> port="8080"/>
> 
> or really however you want.
Like my comments above, can you be more specific about this? Where should I put the <mms>, under <apn> <usage type="mms"> ??

thanks
Depends on: 743336
Target Milestone: --- → mozilla14
Version: Trunk → Other Branch
Target Milestone: mozilla14 → ---
Version: Other Branch → Trunk
The serviceproviders.json is coverted from serviceproviders.xml,
but it's converted by using http://jsontoxml.utilities-online.info/,
I may need to also work on writing a script to do that.
(In reply to Yoshi Huang[:yoshi] from comment #25)
> Created attachment 618607 [details] [diff] [review]
> [WIP] Add serviceproviders.json
> 
it should be 
[WIP] Part 1 : Add serviceproviders.json
This patch is base on the patch from Bug 743336.
Also I remove the 'SET' string gwagner mentioned in Bug 743336 comment 22.

I use "ril.data.apn" to store those apns.
Attachment #618607 - Attachment description: [WIP] Add serviceproviders.json → [WIP] Part 1 : Add serviceproviders.json
Rebase to latest m-c.
Hi Philikon, 
Can you kindly help to give me some feedback about this patch ?
thanks.
Attachment #618611 - Attachment is obsolete: true
Attachment #619848 - Flags: feedback?(philipp)
Comment on attachment 618607 [details] [diff] [review]
[WIP] Part 1 : Add serviceproviders.json

Review of attachment 618607 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/system/gonk/Makefile.in
@@ +59,5 @@
>    net_worker.js \
>    ril_consts.js \
>    ril_worker.js \
>    systemlibs.js \
> +  serviceproviders.json \

Yeah, no, this doesn't belong into the JSM directory. We should add this to the omni.ja file using the jar.mn manifest. Top-level is fine by me, or we can invent a new directory name. I don't really care. See https://developer.mozilla.org/en/JAR_Manifests for more info.
Attachment #618607 - Flags: feedback-
Comment on attachment 619848 [details] [diff] [review]
[WIP] Part 2: configure datacall parameters

Review of attachment 619848 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/system/gonk/RadioInterfaceLayer.js
@@ +640,5 @@
> +  _apnDB: null,
> +  initApnDatabase: function initApnDatabase() {
> +    if (this._apnDB) {
> +      return;
> +    }

Why do we need to keep this DB in memory? I mean, how often do we need to look up this data? We don't support hot-swapping SIM cards anyway.

Also, the JSON file is pretty big. After JSON.parse()ing it, how much more memory does B2G allocate?

@@ +643,5 @@
> +      return;
> +    }
> +    let ril = this;
> +    let xhr = Cc["@mozilla.org/xmlextras/xmlhttprequest;1"].
> +        createInstance(Ci.nsIXMLHttpRequest);

Better done with NetUtil.asyncFetch(). See https://developer.mozilla.org/en/JavaScript_code_modules/NetUtil.jsm#asyncFetch%28%29

const SERVICE_PROVIDER_DB_URI = "resource://gre/mobileserviceproviders.json";

...

  let uri = Services.ui.newURI(SERVICE_PROVIDER_DB_URI, null, null);
  NetUtil.asyncFetch(uri, function (stream, result) {
    if (!Components.isSuccessCode(aResult)) {
      ... log etc.
      return;
    }
    try {
      let data = NetUtil.readInputStreamToString(stream, stream.available());
      this._apnDB = JSON.parse(data);
    } catch(ex) {
      ... log etc.
    }
  });

@@ +644,5 @@
> +    }
> +    let ril = this;
> +    let xhr = Cc["@mozilla.org/xmlextras/xmlhttprequest;1"].
> +        createInstance(Ci.nsIXMLHttpRequest);
> +    xhr.open("GET", "resource://gre/modules/serviceproviders.json", false);

As said before, we shouldn't put this files into the `modules` directory. I also suggest calling it mobileserviceproviders.json, to make clear what kind of service providers we're talking about here. Lastly, values like these should be const'ed!

@@ +654,5 @@
> +    };
> +    xhr.send(null);
> +  },
> +
> +  _getApnListWithPrimary: function _getApnListWithPrimary(mcc, mnc, primary) {

This function is extremely inefficient from the looks of it. We should be building one or several look-up tables to make the lookup faster. Unless I'm missing something. In any case, this code needs to be documented way better.
Attachment #619848 - Flags: feedback?(philipp)
(In reply to Yoshi Huang[:yoshi] from comment #24)
> (In reply to Dan Williams from comment #22)
> 
> Hi Dan, 
> 
> > Note that we've already got a "mms" attribute for the the <apn> element, so
> > we would likely use a format like this:
> > 
> > <apn value="some.mms.apn">
> >    <usage type="mms"/>
> >    --- add in other required attributes
> > </apn>
> > 
> From Android, I notice that some apns can be 'mms,default,supl' (multiple
> types).

With the Android list each APN can be multiple types, just like in the MBPD.  We'll probably need to add more types as well, like SUPL (location services) and maybe DUN if the operator requires it.  Each of these types may need specific attributes (like MMS) so we should add those to the DTD as appropriate.

I don't think 'default' maps to anything useful here since there's so many variables and the plans an such change every so often.  But if we can come up with some actual use, and there are multiple same-type APNs for each provider, we could tag one as 'default', whatever we determine that to mean.

> But from your database, you have only two types, 'internet' and 'mms'.
> Also I notice that for those APNs which can have multiple types, your
> database has put them into type 'internet'. That's why my patch didn't do
> this as you suggest.

It may be that the APN is actually used for both packet data and MMS.  But often there are also separate APNs which of course require a second PDP context activated for MMS.  At this point I think we only care about 3 APNs: internet, MMS, and (later) SUPL.

> 
> > One suggestion for the attributes might be:
> > 
> > <mms mmsc="http://mmsc.cingular.com" proxy="wireless.cingular.com"
> > port="80"/>
> > <mms mmsc="http://216.155.174.84/servlets/mms" proxy="216.155.165.050"
> > port="8080"/>
> > 
> > or really however you want.
> Like my comments above, can you be more specific about this? Where should I
> put the <mms>, under <apn> <usage type="mms"> ??

How about something like this?

<apn value="wap.cingular">
	<plan type="postpaid"/>
	<usage type="internet"/>
	<usage type="mms">
		<mms mmsc="http://mmsc.cingular.com" proxy="wireless.cingular.com" port="80"/>
	</usage>
	<name>MEdia Net (phones)</name>
</apn>

or, maybe we should just use the presence of a particular element to signify that it supports MMS like so, since we'd have to have the MMS bits anyway:

<apn value="wap.cingular">
	<plan type="postpaid"/>
	<usage type="internet"/>
	<name>MEdia Net (phones)</name>
	<mms mmsc="http://mmsc.cingular.com" proxy="wireless.cingular.com" port="80" />
	<wap proxy="whatever" port="blah" />
</apn>

I think the alternative of putting each thing as an attribute under <usage type="mms"> is almost too verbose.  THoughts?
blocking-basecamp: --- → -
So, I've been thinking about this for a bit. Instead of shipping this stuff with Gecko, I think we should expose the necessary information (MCC and MNC) to content and then leave the database and automatic configuration stuff up to the settings app or whatever. That way updates to the database can be pulled in much faster and we don't have a huge chunk of code and data that we have to maintain within Gecko forever.

I have filed bug 761482 for this. Yoshi, feel free to steal it from Marshall or work with him on it. It would be great if you could also work with Kaze on adapting your JSON database and configuration code for use in Gaia.
Status: NEW → RESOLVED
blocking-basecamp: - → ---
Closed: 12 years ago
Resolution: --- → WONTFIX
Sure, I'll take a look on this. 
thanks
(In reply to Dan Williams from comment #31)
I update the patch in https://bugzilla.gnome.org/show_bug.cgi?id=673744 as your suggested, with a little modification.
Would you kindly help to give me some feedback ?

Also since this bug has been changed to WONTFIX, do you mind we move the discussion to Gnome Bugzilla 673744? 

I think this may also speed up our discussion and maybe other members in mobile-service-provider can give me some suggestions.

Thanks
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: