PLATFORM AND VERSION iOS Development environment: Xcode 15.4, macOS 14.5 Run-time configuration: iOS 17.5.1
DESCRIPTION OF PROBLEM We use PushKit to push offline messages of Voip, and use Voip notifications to bind with CallKit to implement Voip call functions. During the test, we found that when the app is in the background or the screen is locked, Voip messages cannot reach the device stably. After several consecutive calls, the phone will not be able to receive new messages for a period of time. Only after the App is uninstalled and reinstalled can it continue to receive messages.
STEPS TO REPRODUCE
1: Open the app and log in successfully
2: Push the app to the background, kill it or lock the screen
3: Use another user to make a voip call to this device
4: Repeated calls
DESCRIPTION OF PROBLEM We use PushKit to push offline messages of Voip, and use Voip notifications to bind with CallKit to implement Voip call functions. During the test, we found that when the app is in the background or the screen is locked, Voip messages cannot reach the device stably. After several consecutive calls, the phone will not be able to receive new messages for a period of time. Only after the App is uninstalled and reinstalled can it continue to receive messages.
Are you absolutely certain that immediately calling "reportNewIncomingCall", as required by the iOS 13 CallKit requirements:
Important
On iOS 13.0 and later, if you fail to report a call to CallKit, the system will terminate your app. Repeatedly failing to report calls may cause the system to stop delivering any more VoIP push notifications to your app. If you want to initiate a VoIP call without using CallKit, register for push notifications using the User Notifications framework instead of PushKit. For more information, see User Notifications.
Not that this requirement does mean that the ONLY messages that can be sent through PushKit are incoming call messages. Control messages like:
We use PushKit to push offline messages of Voip
Should not be sent through PushKit unless you're willing to risk presenting an incoming call screen.
As a side note on that, some apps do have cases where they would prefer, when possible, to NOT present an incoming call screen if the user is already on another. Examples of those cases include:
-
Duplicate call reports caused by the report from the direct controll connection before PushKit arrives.
-
Blocking calls while the user is already on a call.
App should handle this case by calling reportNewIncomingCall and intentionally passing in the UUID of the existing call. When this occurs, the system will either:
-
Fail the call request and return "CXErrorCodeIncomingCallError.Code.callUUIDAlreadyExists". No other action is required if this occurs.
-
Report the call as a standard "new call", in which case you'll need to end the call yourself.
Using this approach will allow you to safely "hide" calls whenever possible, while also ensuring that your app is not killed for failing to report in cases where event timing means that the existing call has ended before your call report arrives.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
