ubuntu-phone team mailing list archive

[Tony Espy <espy@xxxxxxxxxxxxx>]

On 04/09/2014 12:59 PM, Zsombor Egri wrote:
> On Wed, Apr 9, 2014 at 5:50 PM, Tony Espy <espy@xxxxxxxxxxxxx
> <mailto:espy@xxxxxxxxxxxxx>> wrote:
>     On 04/09/2014 01:43 AM, Zsombor Egri wrote:
>         Hi,
>
>         On Tue, Apr 8, 2014 at 10:49 PM, Tony Espy <espy@xxxxxxxxxxxxx
>         <mailto:espy@xxxxxxxxxxxxx>
>         <mailto:espy@xxxxxxxxxxxxx <mailto:espy@xxxxxxxxxxxxx>>> 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