Hi, On Thu, Dec 06, 2012 at 12:45:29PM +0100, Marcel Holtmann wrote: > > >>> If the device has retained parameters for a previously defined IP > > >>> context, is is probed via AT+CGDCONT?. > > >> > > >> this is really not a good idea. The AT+CGDCONT? settings are on a per > > >> device basis. That is not how oFono actually works. It operates on a per > > >> SIM card basis. And since you do not know to what SIM card these > > >> previous settings apply to, the only sensible thing to do is to ignore > > >> them. > > > > > > Okay, I was not aware of this. But surely the common case (i.e. the only > > > one > > > I've personally seen) is to have a single SIM card per device, and under > > > those > > > limited circumstances it is safe to assume that the settings are valid > > > for that > > > SIM. Would it be reasonable to implement such a fallback for this more > > > limited > > > case? > > > > > > > I admit your approach did make me chuckle for being so unorthodox :) > > However, I think your perception is slightly wrong, there are people who > > switch sim cards like crazy (e.g. frequent travelers) so this form of > > provisioning is not really a good idea in those cases. > > even if you switch your SIM card only once, it is a bad idea to start > out with a wrong context. Some operators do not include actually domain > names and a flatrate in one could mean pay as you go in another and > drain your bank account. Most operators should have their backends for > different billings fixed, but you never know. It is really the only > sensible way to bind the APN settings to your SIM card. > > Why the SIM card does not come with the APN settings stored is another > story. You need to blame the operators for that.
Fair enough. I suppose all this SIM card switching is more common outside of the US. > > > The alternative to pulling the data from the device is to provide a > > > mechanism > > > for specifying the APN policy for a particular fleet. (At least in > > > theory the > > > APN selection policy can vary from one fleet to the next.) I assume this > > > would > > > be implemented as a custom provisioning plugin that either hard-codes the > > > policy > > > for the fleet, or provides a configuration mechanism that is flexible > > > enough to > > > accommodate the needs of most fleets (probably using a provider -> APN > > > mapping, > > > assuming we can guess the provider e.g. using the > > > mobile-broadband-provider-info > > > database). > > > > I'm getting lost, why is the default mobile-broadband-provider-info > > plugin not good enough? And why don't you simply create your own > > database based on the providers you are targeting? To me it seems like > > you need X entries for all X providers you have. Unless the settings > > vary within a given provider somehow? > > The default mobile-broadband-provider-info database has too many > duplicate choices and in that case oFono can not auto-provision your SIM > card, but a specific smaller version of that database just target to > your fleet would make oFono auto-provision the settings and you get > exactly what you wanted in the first place. No extra code to be written. I think this approach makes sense (provided we never need to use different APNs for the same provider within a given fleet). > It is really a database problem that oFono backs out with the > auto-provision in most cases. That database is just overloaded. And in > case of oFono provision you also get the SPN information of your > provider if they provided it. I would trust the combination of MCC, MNC > and SPN more than anything stored via AT+CGDCONT. > > In addition you can write your own provisioning plugin in case you do > not like the XML format from mobile-broadband-provider-info. If we do end up needing this, it will be so we can make the APN selection policy dynamically configurable at runtime via an API (i.e. instead of via a configuration file). But hopefully we won't need that. ;) Thanks for your help. Regards, Forest -- Forest Bond http://www.alittletooquiet.net http://www.rapidrollout.com
signature.asc
Description: Digital signature
_______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
