Host reachable via WiFi periodically reported as being reachable via WWAN and back

Hello.

Our app uses WiFi to communicate with VoIP server (in both fore- and background), periodically connecting to a dedicated server asking for data updates. The problem occurs only when WiFi doesn't have Internet connectivity and Cell data may have one. It's been noticed that VoIP server connection can't be established sporadically (in some cases - periodically, approx. once per minute) with different error event codes reported.

We've added use of Reachability notifications to monitor:

- WiFi connectivity (using reachabilityForLocalWiFi reachability instance)

- Server host reachability (using reachabilityWithAddress reachability instance)

Both instances' network status is verified upon receiving ReachabilityChangedNotification.

On some devices (iPhone 5s, iOS 8.3) the following happens periodically:

- Wifi NotReachable status is returned by reachabilityForLocalWiFi instance

- Host is ReachableViaWWAN status is returned by reachabilityWithAddress instance

Within a couple of seconds notification handler is called again with same WiFi state, but Host is ReachableViaWiFi. The entire sequemce cycles periodically (approx. once per minute).

- Is there a reasonable explanation of such behavior on iOS part, i.e. what could be causing intermittent Host reachability "jumping" to WWAN and back?

- Is there a way to force App to stick to WiFi connection without swithing to WWAN?


Thanks in advance,

Alex

Replies

Our app uses WiFi to communicate with VoIP server (in both fore- and background), periodically connecting to a dedicated server asking for data updates.

I have two big picture questions here:

  • I presume you're using the original VoIP architecture, as opposed to the PushKit architecture we introduced in iOS 8?

  • When you say "uses WiFi to communicate with VoIP server", does that mean the VoIP server is only available on Wi-Fi? That is, is the VoIP server available on WWAN at all?

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

The answers are:

  • Yes, the original VoIP arch is used
  • Yes, VoIP server is only available over WiFi being a part of LAN within a Company infrastructure, it's not exposed externally, so not accessible via WWAN

Thanks,

Alex

Yes, VoIP server is only available over WiFi being a part of LAN within a Company infrastructure, it's not exposed externally, so not accessible via WWAN

Alas, that is not a model that's well supported by iOS's VoIP architecture (either old or new). The VoIP architecture assumes that, if a device has a working WWAN, the VoIP app will be able to contact the VoIP server via WWAN.

IMPORTANT: There are good reasons for this. Specifically, this assumption allows iOS on WWAN-capable devices to disassociate from the Wi-Fi while sleeping, which saves significant amounts of power.

Having said that, the new VoIP architecture might help here. The normal flow for the new architecture is:

  1. server sends app a push notification

  2. app wakes up in the background

  3. app contacts server to decide what to do

  4. if necessary, app alerts the user about a phone call

  5. user brings app to front and answers call

If you remove step 3 then this approach will work for a server that's only available on Wi-Fi (because step 5 requires an unlock and that will result in the device associating with Wi-Fi). The downside is that your app has less flexibility in how it decides whether to ring the phone; it has to make its decision based solely on the contents of the push notification.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"