879798 - B2G MMS: Determine correctly whether MMS or SUPL traffic has to be routed through the default APN

Status: RESOLVED WORKSFORME

(Core :: DOM: Device Interfaces, defect)

Description

[José Antonio Olivera Ortega [:jaoo]]

For Telefonica Movistar Spain subcribers we are routing all MMS and SUPL traffic through the default APN (data one) and this is wrong. The `usingDefaultAPN()` function in RadioInterfaceLayer.js file assumes the traffic for MMS also has to be routed through the default APN because the APN name for both MMS and data calls is the same. See at [1] the APNs for Telefonica Movistar Spain subcribers. IHMO the `usingDefaultAPN()` function should not consider that two APNs are the same by comparing only the APN name.

[1] https://github.com/mozilla-b2g/gaia/blob/master/shared/resources/apn.json#L140-L144

Comment 1

[Dietrich Ayala (:dietrich)]

Thanks jaoo. What is the user effect? Should this block the release?

Comment 2

[Maria Angeles Oteo (:oteo)]

I think it may have effects in the user customer bill, requesting needinfo to Beatriz too so she or Jose Antonio can confirm it,

Comment 3

[Beatriz Rodríguez [:brg]]

This is a blocker for the release.
MMS must be sent through MMS APN, it is needed to bill correctly the customer.

Comment 4

[Beatriz Rodríguez [:brg]]

Setting the suitable flag.

Comment 5

[José Antonio Olivera Ortega [:jaoo]]

Go for it!

Comment 6

[José Antonio Olivera Ortega [:jaoo]]

After being a few days poking around this issue I've decided to resolve it as WORKSFORME. I did a small patch for the `usingDefaultAPN()` function to check whether two APN sets are the same by comparing all the APN attributes not only the APN names as the `usingDefaultAPN()` function does right now. The result was that a second setupDataCall() call is performed but in the case the name, user and password attributes are the same for both APN sets (for data and mms usage) the RIL doesn't bring up a second network interface so there is no a new network interface for routing the MMS traffic through.

AOSP setups a new data call even being the name, user and password attributes the same for both APN sets. To best of my knowledge that wouldn't be necessary but maybe I might be missing something. I'll reopen this bug if that second data call is truly necessary.

We might improve the `usingDefaultAPN()` function a bit by comparing all the APN attributes not only the APN names as the `usingDefaultAPN()` but after taking a look at the apn.json database carriers with different APN sets for data and MMS hardly ever have the same APN name for both. To be honest I think it's not needed.

FYI: The new APN setting architecture will make a nice improvement here by merging the APN sets that have the same value for the name, user and password attributes into a single APN.