On 04/09/2014 12:59 PM, Zsombor Egri wrote:
On Wed, Apr 9, 2014 at 5:50 PM, Tony Espy <e...@canonical.com <mailto:e...@canonical.com>> wrote: On 04/09/2014 01:43 AM, Zsombor Egri wrote: Hi, On Tue, Apr 8, 2014 at 10:49 PM, Tony Espy <e...@canonical.com <mailto:e...@canonical.com> <mailto:e...@canonical.com <mailto:e...@canonical.com>>> wrote: To test this change, you'll need to manually delete the gprs settings file created by ofono, as provisioning only occurs once, after which the required settings are read from this file. Have you thought about the case when the user sends an USSD command (or whatever other ways) to operator to get the GPRS/MMS configurations? Or when the operator pushes the new settings to the device? I've thought about it, but neither are currently in the plans for our first version of Touch. Ok. Consider also SIM Toolkit, that may also have apps to request configuration data. Or dialling to service numbers (SDN from SIM) may also result in receiving provisioning messages.
SIM Toolkit is fully supported by ofono, however at this point we're not planning on implmenting full STK support in Touch, as this requires platform and UI intgration work. I'm not saying it's something we'll never support, however a decision was made to defer this in our initial release.
In the case of the USSD command, the received settings should be configurable via the Access Point Names Settings UI ( when it's finished ). If you're proposing that we programatically handle the response, that's something we'd need to consider in the Messaging App. Also, as USSD commands are sometimes operator-specific, that may be tricky. I forgot to mention that operator may also push the settings - most operators in Europe do auto-provisioning when the SIM card is inserted into a given device. Basically they do a WAP push with the provisioning data whenever the SIM is registered with different IMEI. These messages (which may also be MMS ones) are usually handled on the backend side, however if not, Messaging app will need interaction with the provisioning data storing API. However ;) operators know what format the device supports, so they will send it straight in XML ;)
Again, we're not addressing push provisioning in our first release. If/when we begin to work with OEMs that require support of such features we'll address then, but for a generic unlocked phone, end-users will need to manually provision their phone if the our auto-provisioning fails. This is no different than what happens with some MVNO SIMs today.
The second case is something we will work on developing with the advice of our carrier advisory group. We decided not to invest cycles into push provisioning for our first release as there were many more important features ( like automatic provisioning for one ) that needed to be completed in order to make the phone usable. Well, we will receive the messages, but we will not be able to do anything with it.
That's correct.
Also, if operator sees that PICS does not have the auto-provisioning set, they will pre-configure the settings.
I'm not familiar with the term PICS. Please define.
Another way - as Symbian used to do - is to store a big set of operator specific APs in the phone, so whenever the SIM is registered the proper AP set will be used. How doable would that be?
I assume you're using AP and APN inter-changeably? If so, both mbpi and apns-conf.xml are big sets of APNs that are pre-configured for operators world-wide. As I described earlier, whenever the phone boots and a new SIM is detected, we query these APN sets based upon the MNC/MCC/SPN/IMSI read from the SIM and provision a number of APNs based upon this query. So unless I'm missing something, we're already doing what you're proposing.
Note, we also will also OEMs to customize the set of APNs we ship as part of our standard image.
Regards, /tony -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp