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.
I had raised a similar post got a reply that it may be due to network delay. But network delay can cause the delivery of voip push to be delayed only by few seconds or minutes. But in our case voip push is getting delivered hours after the voip call was attempted.
Steps to reproduce:
- Put our voip app in background and lock iPhone. As app is put in background, socket connections gets disconnected from server.
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. 3) 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.
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:
-
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.
-
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:
- 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
