I am developing a VoIP service. Usually, when receiving a VoIP Push, Callkit is exposed immediately after receiving the message and the app is designed to be used. However, there is an extremely intermittent phenomenon (not well reproduced) where the app does not wake up even when receiving a VoIP Push. And after a long time, the app wakes up and Callkit is activated. (A long time after receiving the call…)
Has anyone experienced the above phenomenon? I wonder if there are any reported parts depending on the OS version. (I have identified that it does not occur in the 17.x version, but it is difficult to guarantee because it occurs extremely intermittently)
The app is not running in the background, but... Could this be happening if there are a lot of pending operations in the background?
I need help urgently
I am developing a VoIP service. Usually, when receiving a VoIP Push, Callkit is exposed immediately after receiving the message and the app is designed to be used. However, there is an extremely intermittent phenomenon (not well reproduced) where the app does not wake up even when receiving a VoIP Push. And after a long time, the app wakes up and Callkit is activated. (A long time after receiving the call…)
Has anyone experienced the above phenomenon?
Yes. What you're describing is long standing behavior common to basically "all" voip apps. It's caused by the interaction between two different behaviors:
-
Network level issues can and will prevent normal push delivery. The EXACT cause varies widely but all of them are outside the apps control.
-
Due to the way APNS queues messages for delivery, it's possible for a push to be queued for delivery while the device was disconnected and then delivered well after it's expiration.
If you haven't already, I would encourage you to file a bug on #2, as the best behavior here would be for the system to simply discard these expired pushes. However, until that happens you're only option is to report an incoming call and then immediately end it.
I wonder if there are any reported parts depending on the OS version. (I have identified that it does not occur in the 17.x version, but it is difficult to guarantee because it occurs extremely intermittently)
I have two answers when it comes to identifying the "reason" behind this kind of failure:
-
IF you've identified a specific network where this is happening AND that network is critical to your business AND you have some ability to influence/control that network, then it is possible to determine and resolve these issue. Doing so generally requires very in depth analysis of the ENTIRE system, including the physical space, network infrastructure, user habits, etc. The key here is to start with the assumption that the problem in some external factor, NOT iOS or your app.
-
If you cannot meet the criteria of #1, then don't waste time thinking or trying to investigate it.
The problem here is that these issue are not "random" in that "something" is nearly always happening. However, that "something" is basically always some external factor like:
-
A particular network configuration is somewhat broken or at least "odd".
-
The user takes the subway every thursday.
-
Maintenance put in new venting directly in front of a critical AP.
...but those factors aren't something you'll find without REALLY digging into a specific failure in great detail, often in person and directly interacting with users. If you spend a lot of time focused entirely on your logging or other app/system level data, you'll find plenty of patterns... most of which are either noise or unrelated correlations.
The app is not running in the background, but... Could this be happening if there are a lot of pending operations in the background?
No.
And additionally, is there a way to actually check the time when the APNs VoIP Push was sent to the terminal?
Take a look at the "Push Notifications Console".
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware