Seeking CallKit / iOS 13 advice for VOIP push notifications

[rwbayer]

Hi there! Less of a true "issue," but I was wondering if anyone from the twilio video team has any advice on the following scenario or any insights into your team's suggested workaround.

In iOS 13, Apple removed the ability to use VOIP pushes for anything other than reporting a new call. Previously, our app used VOIP pushes to cancel ongoing calls for certain cases: caller ends call before callee answers, callee answers on another device, callee declines call, etc.

In Apple's documentation, they specifically say we should not use VOIP pushes for this scenario:

After sending the initial push notification, don’t send additional push notifications to cancel the call or communicate new details to your app. Instead, communicate with the app directly over the network connection you established between it and your server. Using an existing network connection is generally faster than sending a push notification, and if network conditions are poor, APNs may be unable to deliver push notifications to the device anyway.

Since we are using twilio instead of a network connection to our servers directly, how do you suggest we communicate the cancel in these situations? I noticed the twilio voice team added a TVOCallInvite object that receives the updates in these cases (I'm assuming through a network connection to twilio's servers), but that case is a little different because I believe that product hosts the push notification service instead of this case where we are responsible for the push service.

I've thought about using regular pushes, but the potential delay and difficulty executing code reliably while your app is in the background (like it is when you are displaying the CallKit UI) are making that strategy difficult. I'm also considering following the twilio voice team's hack shown here by continuing to use VOIP pushes and reporting the call before ending it the next line down, but it was proposed as a fallback by the voice team in case the new push registration did not occur, and I'm worried about relying on that strategy long term.

Thanks so much in advance for any advice/insights!

[piyushtank]

@rwbayer Thanks for reaching out.

Our iOS Voice SDK ran into the same issue last fall. We followed Apple guidelines and shipped Voice iOS SDK version 5.x to support iOS 13 requirements. Your observation is correct, our Voice SDK creates a persistent connection with our infrastructure once the incoming call push notification is received. If the call is canceled by the Caller before called party could answer or reject, the called party receives Cancel via the its persistent connection with our infra.

Since Video SDK follows Room based model, you can use one of the following route to have incoming call feature -

1. Implement your own signaling using VoIP push notification - with this approach, you will have to make sure when a push notification is received, your app reports the received push to CallKit as a new incoming Call, and your app should create a persistent connection with your server to support cancel use case.

2. Use Voice SDK and Video SDK side by side in the same. Use Voice SDK to receive incoming call - once the called party take action on the incoming call, you should disconnect the Voice SDK Call. Some of our Video customers are using this work around to receive incoming calls.

Let me know how it goes.

[piyushtank]

I just wanted to add a note here that option (2) above is not a solution but a workaround. Managing two SDKs for one call adds lot of complexities in the app code, I would try to avoid it if possible and keep it as the last option.

[rwbayer]

@piyushtank thanks for the ideas! We're going to try a polling approach first. If that doesn't work, we'll try out a long poll/socket with our infra. As a last resort, I'll keep the Voice SDK option in mind. Thanks again for your help, I'll close this for now since that advice was exactly what I was looking for