Re: RFC: Ubuntu Touch, MMS, and Provisioning

[Tony Espy <espy@canonical.com>]

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

On 03/05/2014 09:41 PM, Marcel Holtmann wrote:
> Hi Tony,
>
>>>> We've been working on MMS support for Ubuntu Touch recently and have run into a couple of stumbling blocks, so I have a few questions about the current MMS logic in oFono ( we're still 1.12 based ), and in particular the provisioning/management of gprs-contexts.
>>>>
>>>> As part of this work, we're planning to switch from using the builtin gprs 'provision' plugin, to the new android-provision/apndb plugin ( originally written by Simon Busch ) which uses the file apns-conf.xml instead of mbpi's serviceproviders.xml.
>>>>
>>>> There are a couple of issues we ran into...
>>>>
>>>> 1. How to represent APNs that support multiple usages types?
>>>>
>>>> The "type" attribute in apns-conf.xml is a list vs. the single type defined by a gprs_context.
>>>>
>>>> The android-apndb plugin uses TYPE_INTERNET for APNs which support multiple types.  In order to properly support MMS, the core code needed to be modified to allow the MMS properties to be additionally be set on a TYPE_INTERNET context.  Thus if an APN supports both Internet and MMS, our DownloadManager can grab the additional MMS properties from the context and handle MMS traffic.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>
>>> you do realize that these are not actually standard HTTP proxies. You are suppose to talk to the MMS Proxy to reach the MMSC. That is how this works. You always go through the MMS Proxy.
>>
>> I haven't actually worked directly on the proxy support myself, and had assumed this was a standard HTTP proxy.  I will make sure my co-worker handling the support in our download manager realizes this, and point him at mmsd/connman's GWeb code for reference.
>>
>>> If you are mixing Internet proxies with MMS proxies, you end up in a really awkward configuration later down the road.
>>
>> Sorry, no intentions of mixing them.
>>
>>> As Denis mentioned we have been using this successfully within mmsd that we wrote.
>>
>> I saw that, we originally did a bunch of work with mmsd, however we decided instead to add MMS capability to our ubuntu-download-manager used in Touch.
>
> feels weird if a download manager handles delivery receipts and read receipts. Especially since there are so many MMS specific header in the HTTP request.

>>> The current design of oFono works just fine by activating the
>>> MMS context and then talking to the MMS proxy to reach the MMSC.
>>
>> Sure, although as I mentioned orginally, if we already have an active data connection and the apn happens to also support MMS, it seems odd not being able to share.
>
> If you have an active data connection you can just compare the TYPE_MMS context details (APN, username, passed)
> with the TYPE_INTERNET context ones and if they match, you choose not to activate the MMS one and just use the
> Internet one.

Sure, this is along the lines of what Denis suggested, however it does 
seem like a lot of overhead, when in theory the addition of MMS 
properties to a TYPE_INTERNET context would allow it be used for MMS.

> As I said in the other emails, oFono is activating contexts only on request.

Ack

> So either ConnMan requests theInternet context or mmsd requests the MMS context. oFono is not in the 
business of
> magically activating contexs. It only attaches to the GPRS part of the network.

I'm not proposing any kind of auto-activation either.  In our case it's 
NetworkManager that's responsible for activating one or more contexts 
for Internet and MMS on-demand when needed.

Again this is also dependent on our disabling ( probaly via a configure 
option ) the ofono MMS IP addr/static route code.  I will discuss this 
again with our NM maintainer though,

> The only problem with the Internet context usage for MMS is that you now also have to talk to ConnMan to figure out when the IP part of the context is successfully configured.

Well again, as we have Network Manager handling context activation, I 
don't think is an issue for us.

That said, in a default configuration where ConnMan is being used, 
couldn't ofono still setup the static route to the mms proxy if the 
context was combined, and let ConnMan do the rest?

> And here is where this gets complicated. And active context does not mean it is actively in use. You might actually use your WiFi and have an activated Internet context, but neither the IP or routing is set.
> Or in same case you are just on WiFi and have no Internet context activated.

If the Internet context is not activated due to insufficient signal, or 
mobile data is disabled, then all bets are off for MMS, and even we 
tried to activate an independent context in this case, it would fail.

If the Internet context is active, but WiFi was subsequently activated 
and is set as the default route, the static route to the MMS proxy 
should still be available for MMS messages.

I will review again internally to ensure we've covered our bases here.

> As you can see this can get extremely complex.

No argument there.

> We opted for just providing a MMS context type and an Internet context type. If the APN happens to be the same (not always the case btw.) then you just double activate that context. Send or receive your MMS and deactivate it.
> We have used this just fine. And in that case oFono does all the heavy lifting for you. You just need to talk to the MMS Proxy address that has been configured. That is it.'

As explained in a previous reply to Denis, double-activating the same 
context may not result in a new interface when talking to a rild 
implementation.

If we were to stay with this default behavior ( which I still would like 
to avoid by use of shared MMS/INET contexts ), we'd have to implement 
logic discussed previously ( ie. check for an already active context 
with the same APN/username/pw in the rilmodem ).

Thanks again for your comments/feedback Marcel.

Regards,
/tony