In bug 926343, nsIIccProvider is changed to support multi-sim. We may need to handle multi-sim scenario in PushService as well.

Bug 926343 comment #33: ---------------------------------- Thanks for the clarification. Is there a followup to add a helper that will just choose a 'good' sim? I don't know how multisim works, but for SimplePush, all I want is a valid data connection. Can there be multiple connections active at the same time? I'd just like to call a (fictional) GetDataConnectionInfo() and get icc connection info from the currently used SIM card (if there is such a thing). ---------------------------------- ni? me for tracking.

I wonder if SimplePush should know what the good sim is. Can it just follow same data connection scenario(just use the data connection established by system) as Browser?

Sorry for the late, I was stuck with other things. Please see my inline reply. (In reply to Edgar Chen [:edgar][:echen] from comment #1) > Bug 926343 comment #33: > ---------------------------------- > Thanks for the clarification. Is there a followup to add a helper that will > just choose a 'good' sim? I don't know how multisim works, but for > SimplePush, all I want is a valid data connection. Can there be multiple > connections active at the same time? I'd just like to call a (fictional) In DSDS (Dual SIM Dual Standby) scenario, there is only one connection active at the same time. > GetDataConnectionInfo() and get icc connection info from the currently used > SIM card (if there is such a thing). Actually you can get this information from NetworkManager. We have exposed this information in bug 925676. After get the active networkInterface from NetworkManager, if it is a data connection (not wifi), then the |serviceId| attribute will indicate this connection is from which sim service. Then you can use this attribute as the index for IccProvider's API. > ---------------------------------- > > ni? me for tracking. Please let me know if there is anything unclear. Thank you.

This should not be a blocker for release - DSDS committed feature scope doesn't include Simple Push to my understanding. We should only be blocking on critical DSDS features that are must haves for 1.3, not all DSDS features possible. We decided against this for mozPay for 1.3, so I think this should not block in alignment with the decision on mozPay.

It seems this bug is simply a placeholder, since for now PushService is not concerned with exactly which SIM is used, as long as the NetworkManager provides the relevant data, and a connection is available. So this should not be a blocker until the SIM information is actually required for some optimization in the service.

(In reply to Nikhil Marathe [:nsm] (needinfo? please) from comment #5) > It seems this bug is simply a placeholder, since for now PushService is not > concerned with exactly which SIM is used, as long as the NetworkManager > provides the relevant data, and a connection is available. So this should > not be a blocker until the SIM information is actually required for some > optimization in the service. Okay - moving to blocking- then.

Closing this out because Push used nsIIccProvider for UDP wake-up, which was removed in bug 1265914.