Issue related to APNS is delivering expired voip push notification.

So there are actually two different issues at play here. The broad issue here:

Hi, am facing an issue related to voip push notifications getting delivered 1-2 hours after apns-expiration to 0 and apns-priority to 10.

...is a long standing issue with APNS. Basically, if a push is prepped for delivery (because the server believes delivery is possible) but delivery fails, that push can end up being "left" in the queue and then delivered much later if/when the client device is again able to reconnect.

I'd appreciate you taking the time to file a bug on this and then posting the bug number back here. I'd like to see us address this but, unfortunately, there have been a lot fewer bugs filed about it than you'd expect.

The second issue is here:

Now if a caller makes call to this app, the call should be delivered through voip push. 2) Voip push should ideally be received even if app is in background and iPhone is locked. It is connected to a good wifi network. But it does not receive the voip push.

The exact details vary, but the general issue here is that the WiFi network is broken. Exactly HOW it's broken varies but here are two real world examples:

1. Some WiFi access points can be configured to ask client to disassociate after a fixed time period. If that happens while the device is locked and sleeping, then iOS can end up disconnecting from the AP, leaving it with no network connection.

2. I've scene a few cases where NAT servers were intentionally breaking connections without notifying both ends that the connection was closed. Typically this means they disconnect the WAN side (APNS server side) but don't notify the LAN side (iOS device). APNS may or may not (depending on what the NAT server did) know there is a problem, but it can't do anything about it, since only the client can reach out.

In both cases, waking/unlocking the device gets "everything" working again as the device reconnects to WiFi and/or starts realizing that connections aren't working properly.

My big warning here is that, in my experience, Wifi only VOIP does NOT "just work". It LOOKS like (and often does) it works fine on small scale test networks and/or well configured and surveyed enterprise networks. It doesn't work well on many enterprise/small business networks. In basically "all" the cases I've looked at, this is because the network did NOT in fact work properly and APNS just happened to be the thing they noticed was broken.

I do have one question here:

1. After 1-2 hours user unlocks iPhone and opens voip app. As soon as user opens app, the voip push is received and phone starts ringing.

Is it necessary to specifically open the app or it just unlocking the device? If it requires opening the app, then that could indicate that there was an issue with your app as well.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi,

Thanks for replying. I filed a bug FB17104567.

And regarding the question you asked. It is not necessary to open the app. Just reconnecting to internet is enough. The voip push is delivered immediately after internet is available. No need to unlock iPhone or open the app.

Thanks for replying. I filed a bug FB17104567.

Thank you and your bug did raise one issue that you should address on your side. In your bug, you said:

"Ideally above mentioned issue should not happen as we have set 'apns-expiry' to a short time period like 30 seconds."

All voip pushes should be sent with "apns-expiry=0". That's because:

1. Using a non-zero expiration only has a marginal impact on the total reported calls. Basically, you go from ring on "all devices currently connected to APNS" to ringing on "all currently connected devices" + "devices that happened to connect in the last + X". That is some additional calls, but unless lots of your users have terrible connectivity it won't be THAT many.

2. Related to that point, the number of additional calls that SUCCEED (meaning, the user is able to connect and talk to the other person) will be significantly less than the new rings created by #1. If you stare at enough failed call traces, you quickly notice that it's fairly common for the push connection to cycle between connect/fail/connect/fail multiple times before establishing a stable connection or failing completely again. The connection failed because the device was out of cellular range and it's common for connectivity to be weak/unstable as the device comes back into range.

3. Because of how pushes are queued for delivery (which I was causes this issue in the first place), any value besides "apns-expiry=0" will dramatically increase the possibility of expired push deliver.

In other words, increasing the expiration time actually ends up significantly increasing the number of failed calls (either because of poor connectivity or push expiration) and only modestly increasing connected calls (if at all).

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware