Handle Expired Voip Push

How much runtime does an app get when it receives a Pushkit Voip Push?

is it documented by Apple how much time it does get to run when it receives the Voip push?

No, There is no official documents available about how much time you
have got, When received VoIP Push notification.

As per my personal experience, You will extends time up to 45 Sec
using long duration sound file if required.

Can the app find out how much time there is remaining? Or get some Waring that execution time is about to expire?

No, There is no official documents or do not available any delegate
method to find how much time remaining.

I have faced same issue, I was overcome above issue using multiple
VoIP Push with different parameters. You can achieved it as below.

As per my requirement, I have to display notification when user received
new incoming call. If user not picked up call then i have to give new notification
for missed call. I was achieved it as below.

1) Generate local notification when received first VoIP Push. 

2) Cancel already generated notification and generate new missed call notification for user.

I am not sure, but you can also use timer if working.

VOIP notification is being missing or delay

Actually, it seems that you aren't reporting a new incoming call for every VoIP push notification. It's true that when there is an active CallKit call, you can receive VoIP pushes without reporting a new incoming call, but it's not as simple as it might seem. Since CallKit and PushKit are asynchronous, you are not guaranteed that when you receive a push of type K.KEY.PUSHTOTALK or K.KEY.HANGUP the call has already started. Moreover, if dictPayload is nil, you fail to report a new incoming call.

Anyway, I think that the biggest problem in your code is that you're not calling the completion handler of the pushRegistry(:didReceiveIncomingPushWith...) method. You should do the following:

self.displayIncomingCall(uuid: appDelegate.uudiForCall, handle: (self.dictPayload!["handle"] as? String)!) { (error) in
    completion() // <---
}

and

CallProviderDelegate.sharedInstance.provider.reportNewIncomingCall(with: uuid, update: update, completion: { error in
    completion()
})
// or
CallProviderDelegate.sharedInstance.provider.reportNewIncomingCall(with: uuid, update: update, completion: completion)

iOS 13 Killing app because it never posted an incoming call to the system after receiving a PushKit VoIP callback

On this thread from apple forums, someone from apple staff explained this:

On iOS 13.0 and later, incoming Voice over IP calls must be reported
when they are received and before the didReceiceIncomingPush() method
finishes execution, using the CallKit framework, or the system will
terminate your app.

Repeatedly failing to report calls may prevent
your app from receiving any more incoming call notifications.

Basically, you can no longer use VoIP pushes for non VoIP messaging,
and will need to use regular push notifications for those.

This was
announced during the WWDC session "Advances in App Background
Execution" https://developer.apple.com/videos/play/wwdc2019/707/

---

I've been searching for answers on how to adapt an app for this change, and what I could gather is the following:

Voip Pushes

When your app receive this kind of push, it will need to report a new incoming call using CallKit. Therefore, this kind of push will be exclusive for calls that use CallKit.

It's recommended that you set the notification's apns-expiration to 0, so you won't receive a push and be forced to present a call screen for a call that already expired.

Push Notifications

Regular push notifications are another option. If your server has all the information you need to write the notification text, you can send notifications that won't even run your app in the background. If you need to modify the content of the notification before presenting it to the user, you can use a Notification Service app extension, and if you need your app to be woken up and execute something in background, you can send silent push notifications.

Notification Service App Extension

To use this, you must set your notification's mutable-content to 1. This way, your extension will receive the notification before it is presented to the user, allowing you to change its content, with a 30 seconds time limit.

The cons are that your app will stay in the background, only your extension will be allowed to run. This might mean that you will need to share information and code between your app and the extension, either by using user defaults, keychain, or by sharing your entire database (which might not be a simple task if your app is not prepared for that).

Silent Push Notifications

To send silent push notifications, you must set your notification's content-available to 1 and remove it's alert, badge and sound. This notification will wake up your app in the background, and call your app delegate's didReceiveRemoteNotification.

The downsides are quite annoying for this option:

• You will only get 30 seconds to run.
• These notifications must have a apns-priority of 5, which might cause them to be grouped and delivered in bursts, and even throttled or not delivered.
• If the user force closes the app, it will completely ignore all silent notifications until the user opens the app again.

Xamarin Android VOIP Push notification handling

We had to implement Push notification handling on Android by our own. You have to derive from FirebaseMessagingService, implement the interface. It will run as a service, which can handle your Push Notifs. But you have to manually implement the displaying of the notifications to the statusbar, or starting the activity.

VOIP Notifications require priority set to the highest.

---

Related Topics