Re: RFC: Ubuntu Touch, MMS, and Provisioning

[Tony Espy <espy@canonical.com>]

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

On 03/04/2014 10:13 PM, Denis Kenzior wrote:
> Hi Tony,
>
>  > Now perhaps I missed something and there is a way to represent a
>> combined usage APN ( maybe using TYPE_ANY? ), but I couldn't see how to
>> accomplish without changes to the core gprs code.

Thanks for the reply Denis.

> oFono is not designed to handle combined usage APNs.

Understood...

> If the APN for MMS
> and Internet is the same, we would simply 'double-activate' the same APN
> using multiple contexts. e.g. you would have an Internet context and an
> MMS context with the same APN.  This of course requires your underlying
> modem driver to be able to use multiple contexts simultaneously (e.g.
> multiple gprs_context atoms present.)

OK, applying this logic to the apns-conf db ( I'll get to Marcel's 
second reply focused on this apns shortly ):

1. The provision plugin would need to create separate contexts for each 
type found in an apn's "type" attribute.  This would work when there are 
exact matches between ofono and the apn types ( eg. default=internet, mms ).

2. Regarding multiple contexts supported in the rilmodem.  We're 
planning on doing this anyways, as we need to support the case where a 
MMS apn is stand-alone.

3. For the shared case, the driver context code could be optimized to 
recognize that a context being activated has the same apn as an already 
activated context and just mark the new context activated, borrowing the 
'Settings' from the first.

So this seems do-able, however it does seem like a fair amount of 
overhead, especially when you start to consider apns that are configured 
for more than just "default" & "mms" ( "dun" and "supl" are other types 
supported in apns-conf ).

This precludes creation of apn types that don't match current ofono 
types ( eg. "dun" & "supl" ).  Neither of these are all that important 
to us currently, however if that changes, we'd have a problem supporting 
them without adding new types.


> If you want to go through the trouble of adding hybrid behavior, then
> patches are welcome.

Sure, although I have no doubts this will be easy given some of the 
competing opinions.  ;)

I think the most minimal implementation of shared contexts would be apns 
that support just INET and MMS.  Unless I'm wrong, I think my changes 
that make it allow-able for MessageCenter and MessageProxy to be set on 
a either context type accomplish this.  None of my other changes are 
required for this type of minimal sharing.

I think the larger question of whether this should be more generic has 
yet to be answered...

>> 2. No way to disable core ofono TYPE_MMS network config.
>>
>> The core gprs_context code has special logic for TYPE_MMS contexts which
>> configures the HTTP proxy using networking ioctl requests.  We have an
>> external download manager that handles the actual download of content
>> from the message center.  As it has logic to handle HTTP proxies
>> already, if we use TYPE_MMS, we'd need a way to disable ofono's builtin
>> logic.
>>
>> Would it make sense to add a command-line option to control this
>> behavior?
>
> oFono only sets up a route and runs the equivalent of ifconfig.  It
> doesn't do any proxying.

Got it, I guess I got confused by the function gprs.c::pri_setproxy() 
which sets up a host route for the proxy if configured.  As per Marcel's 
first reply, a proxy is always used for MMS downloads so this will 
always occur.

> This logic is there because ConnMan explicitly
> ignores contexts of type=mms.  So someone must take care of bringing up
> the interface, assigning IP, etc.

Sure, makes sense.  In our case, we'd decided to have NetworkManager 
handle this work for INET or MMS contexts, so again it would be nice if 
this behavior were configurable.

> You might also want to check out the mmsd project since that already
> works with oFono.

We initially had planned to use mmsd, however decided to extend our 
exisitng Download Manager to support downloading MMS content.

>> 3. No way to associate additional APN properties with a gprs_context.
>>
>> apns-conf.xml has many additional APN attributes which don't map
>> directly to gprs_context properties ( eg. authtype, mvno_type, ... ).
>>
>
> If you have usecases in mind for some of these properties, feel free to
> suggest extensions to the oFono API.

Other than "types" ( which has already been discussed ), the only two 
that might make immediate sense are "authtype" ( ie. none, PAP, CHAP, 
both ) and "roaming_protocol"?

I guess from my perspective it felt wrong to just throw away all of 
these extra attributes while provisioning, and thus the dictionary 
property was an approach to preserve them without being too intrusive ( 
although the settings code did complicate things a little ).

Also precedence, as there's additional apn information from mbpi which 
is ignored during provisioning ( <plan>, <usage>, <dns> ).

>> "types" is especially important, as without it, we can't tell exactly
>> which services are supported by the APN ( as the plugin sets the type to
>> TYPE_INTERNET ).
>
> As mentioned above, you'd simply create multiple contexts with the same
> APN and different types if you wanted to accomplish this easily.

Understood, although the resulting number of contexts could result in 
overload to a user if exposed in a settings UI.

Regards,
/tony