Re: RFC: Ubuntu Touch, MMS, and Provisioning

[Tony Espy <espy@canonical.com>]

[-- Attachment #1: Type: text/plain, Size: 5625 bytes --]

On 03/05/2014 01:29 PM, Marcel Holtmann wrote:
> Hi Slava,
>
>>>> What do you think about extending org.ofono.ConnectionContext API with
>>>> Add/RemoveProperty calls and PropertyAdded/Removed signals to allow
>>>> platform/application specific properties of type string? Use cases
>>>> include marking connections as preferred/default or assigning priorities
>>>> to them, tracking the origin of the context (OTA, local provision or
>>>> manually edited) and who knows what else.
>>>>
>>>
>>> There are practical considerations that make this a bad idea, e.g. security concerns or the fact that our dbus bindings do not handle dynamic properties.  Putting that aside...
>>>
>>> Your suggestion would be completely against our three core design values, e.g. "Minimal and Complete"; "Consistent" and "Easy to Use".
>>>
>>> I'm open to adding additional properties the "old way" if you can argue good use cases for them.
>>
>> A couple of examples.
>>
>> Suppose, we have a UI that allows the user to switch between "Automatic" and "Custom" MMS or GPRS settings. One of the ways to implement that would be to create a new context marked as "manual" and allow the user to edit it. The old context remains but it's marked as "automatic" or whatever. Manual context has a precedence over the automatic one. Switching back to automatic means destroying the "manual" context or marking it as "disabled". All that stuff gets saved to the ofono SIM-specific gprs file so that these context properties don't get lost after swapping SIMs.
>>
>> Suppose, we have a different connection management system, which shows the entire list of available access points to the user and allows to choose which one to use. The selected context needs to be marked as "default" or something. Again, this context property needs to survive SIM swap. With a custom context property that's pretty easy to do.
>
> I am not even sure what’s your goal here? Are just trying to plain copy the horrible crap that Android puts in front of their users?
> You do realize that their list of APNs just purely exists since they never figured out on how to do the automatic provisioning properly and user friendly.

No, I didn't realize this.  I've generally had positive experiences with 
the Android phones ( mostly Nexus*, except for a G1 ) I've owned.

That said, apns-conf has a lot more content than mbpi, especially with 
regards to MMS support.  There are grand total of 16 MMS APNs defined in 
the latest version of mbpi:

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

> I have to second Denis here that time is better spent in creating a proper provision database instead of just copying what AOSP provides.

Sure, but how long has mbpi been around for, and why isn't it in better 
shape?  Also, as explained earlier Android supports combined contexts, 
which is not compatible with mbpi's schema.

I'm not against improving mbpi or even working to help create a new 
database.  For us right now, apns-conf is a viable alternative which 
gives us decent provisioning for both Internet and MMS, so we'd like to 
ensure we can support it.

> For example many operators are using SPN or IMSI prefixes to clearly identify their MNVO.
> We made the provisioning a plugin design for exactly that reason so that every product can provide its own database.

This is exactly what we're trying to do, however as my original email 
said, we ran into a few stumbling blocks...

> You might also think this through once more. What does default actually mean. Can every context have a default tag?

As far as I understand it, "default" indicates support for Internet.

Also, please understand that the UI examples that Slava included apply 
to Sailfish's UI, not Ubuntu Touch.

> Which one do you pick then? Who is making this policy and who is ensuring what is active at what time.

We give preference to the first context of type "default" ( for which we 
create an INET context ), unless this has been overriden by the user 
from a settings UI.  I'd considered making my new "ExtraData" propertly 
write-able, so that the UI could add some tag/attribute to denote this.

The other choice of course is to store this meta-data somewhere else... 
which would impact Network Manager, as it's the process responsible for 
activating/deactivating contexts for Touch.

> oFono is happily
> supporting multiple Internet contexts and have them all active. Our own modem hardware supports many contexts.
> We have run this with 4 Internet contexts at the same time (different and same ones).

Understood, as mentioned we need to support multiple contexts for the 
case where a MMS APN is not shared with any other type.

> And I have to note that oFono never establishes contexts by itself. The only thing that oFono does is attach to the GPRS (packet switched) part of network.
> The APN establishment is a policy enforced by ConnMan for Internet contexts and mmsd for MMS contexts.

In our case it's NetworkManager responsible for both, with help from a 
few other system components ( such as our Download Manager ).

> The simplest approach we found with our devices is to only provide one Internet context from the user interface.

Did you expose the MMS context anywhere in your user interface?

> If it is wrong for whatever reason or provisioning can not identify it, then the user gets asked once. If user wants to change it they can go through the APN setup process once more. Worked smoothly for us and is super user friendly.

Makes sense.

Regards,
/tony