iOS 13 PushKit VoIP restrictions breaking SIP VoIP apps


We are a fairly large company providing smartphone and desktop applications for VoIP/UC together with PBX systems, on-premise as well as clourd offerings. All our app are talking to the telephony servers over SIP.

Up unitl now, our flow on iOS was:

  1. Receive PushKit VoIP notification
  2. REGISTER towards telephony server
  3. Receive INVITE
  4. reportIncomingCall

With the changes enforced and outlined in, the whole SIP concept will break.

We are now forced to report an incoming call so early that the user might accept the call before the REGISTER has completed and an INVITE has been received which will lead to a pretty bad user experience.

Even worse, we will report an incoming call even if there is no actual call. This might happen as the call has already been canceled on the remote end and we won't get an INVITE. Or if the registration fails due to network issues that prevents us from reaching the telephony server.

How does Apple expect us to deal with these situations?

It's not possible to perform the whole REGISTER/INVITE stuff "in the same run loop as pushRegistry:didReceiveIncomingPushWithPayload:forType:[withCompletionHandler:] without delay."

I'm not sure what our support and sales guys will do when they receive negative customer feedback with the changed implementation. Maybe tell existing and new customers to use Android smartphones instead of iPhones...

There has to be at least some way of delaying the reportIncomingCall so that an application can check against the telephony server if there is a call and report if there is none to avoid punishment for not reporting the call.

32 Replies

A lot of different issues have been raised in this thread, so I've loosely summarized them to the following 4 questions issues:

1) Reporting a call immediately does not work with the SIP register-invite flow

On iOS 13, there are cases where you will need to initiate a CallKit call that you previously would have silently ignored. However, in practice, this should not be the common case, particularly for truly “non-existent" calls, since that would mean you had been notifying the user of calls that did not exist.

The more common cases here are calls that have either already ended (because the caller hung up) or can't be completed (because network conditions prevent the call from connecting). While calls will be created for both of these cases, there are few different techniques that you can use to mitigate any disruptions:

While you must report an incoming call immediately, you are still free to decide the call has failed and tell the system later, asynchronously. To do this, call reportCallWithUUID:endedAtDate:reason:. This will tear down the incoming call UI even if the user has not answered the call.

If the user is particularly fast at tapping the accept call button, or if the network conditions are poor or there is otherwise a lot of latency, then you should simply wait until the necessary handshakes are complete before calling fulfill on the CXAnswerCallAction. To the user, it simply appears that the call is taking some time to connect, which is a common experience even with standard phone calls.

Note that the system takes a few seconds for the incoming call UI to animate in, during which the app has the opportunity to complete this handshake, so this will only have a user-visible impact if it takes a significant time for the handshake to complete.

At any time, you can asynchronously update the UI with the reportCallWithUUID:updated: API. That means that if you cannot put the caller ID info in the push payload, you can simply choose to present dummy information (like "Connecting Call..." for the caller name) and update it asynchronously once they get the real information from your server.

2) Sending a push to cancel an incoming call

While your app currently has an active call (ringing or answered), your app is not required to create additional calls for VoIP pushes received during this call. This is intended to be used to support advanced functionality like dynamic call priority, but it could also be used to cancel an incoming call.

Having said that, this is not an approach I would recommend or rely upon. The reality is that as soon as your app receives it's PushKit notification it should be connecting to your server, so unless network conditions are very poor, you should be able to communicate to your client through that connection faster than PushKit. More to the point, if network conditions mean that you can't connect to your server, then trying to handle this with another push isn't a great idea either, since poor connectivity (and timing generally) opens the door to edge cases you'd want to avoid - for example, a client receiving ONLY the cancelation and not the original call notification.

As a side note here, keep in mind that as part of adapting to the new requirements you'll want to make sure the VoIP notification has a short or zero "apns-expiration" to prevent newly available devices from being notified of out-of-date calls. This will also minimize the cancelation issue, since a “newly available device" (for example, a phone that was just powered on) will ONLY receive notifications about calls that are occurring at that particular instant.

3) Block-lists/Do Not Disturb

CallKit respects the system Do Not Disturb setting, so most apps will not have to worry about system-level Do Not Disturb functionality. If your app has it's own blocking/do not disturb system built in, you can also maintain that list server-side and not send pushes to the blocked devices. If you absolutely need to do "local" call blocking, then you can report a call and then end it. The call will be briefly visible to the user, but you can also configure the source of the call to communicate what's going on ("Blocked Call...").

4) Using VoIP pushes to trigger syncs or other non-VoIP use cases

VoIP pushes were always intended to specifically support call notifications and nothing else. The good news here is that using Notification Service Extension is the best substitute for most of the functionality that you previously handled with PushKit:

A few examples:

  • For general messaging, you can connect to your server in the extension delegate, download any missed messages, and then update the notification content as appropriate.
  • The same approach can be used to tell the user about calls missed while the device was offline and/or pending voicemails.
  • For non-user facing functionality, like data synchronization or other app maintenance, I would recommend checking out the new BackgroundTasks framework:

Kevin Elliott

Developer Technical Support

Core OS/Hardware


No answers but some more information.

We're experiencing all the same issues. Besides the risk of ghost calls we're finding that limiting the PushKit notifications is preventing us from implementing features of some other well known messaging/voip apps; exactly as others have mentioned.

One feature in particular for us kicked this off. How to mute a group chat/channel and not show any notifications. Yes we could have the server do it but it seemed simpler to have the client do it. So we started investigating how other apps did this. It lead to something interesting.

WhatsApp is a great example of a feature-rich messaging app and we always start these conversations with "what does WhatsApp do". When we looked we saw that it is using PushKit notifications in a seemingly unrestricted fashion. What does that mean? It appears to be using PushKit notifications for sending messages. Something that I'd have considered impossible given the restrictions in place. So we thought maybe it's still using Xcode10? We find that highly unlikely given the looming cut-off date. So a bit of digging (not that much when you consider the link and the question I asked)

This specific entitlement seems to be the reason that they are allowed to not report an incoming call:
I can't find any documentation regarding this entitlement, so I'm pretty sure they have been given a special permission by Apple.

So we started looking for this entitlement. Lookup source-code-walkthrough-of-telegram-ios-part-3-other-foundations-66ace05954a4 (the editor is refusing to let me post the URL)

As any abuse could cause a significant battery drain problem, Apple started to require apps to invoke CallKit after receiving VoIP notifications since the iOS SDK 13. But Telegram-iOS seems to survive from the new rule as it has got a special entitlement from Apple: The same undocumented entitlement can also be found in SignalApp.

So there does appear to be an entitlement available that provides seemingly unrestricted use of PushKit.

I completely understand why Apple wanted to restrict this feature but they should have vetted the apps and allowed access to trustworthy apps in a fashion similar to Critical Alerts. I'd be very happy to explain why we needed unrestricted voip and be prepared to justify it every so often. I'm slightly annoyed, but not surprised, that some apps seem to receive more access to the platform.

So I suggest you start asking your nearest Apple dealer about


How much is it fare to change the whole PBX programming? As some PBXes updates the clients at regular interval. If not responded back, deregisters the client. Re- Registering the client on wakeup with all subscribe and notify cycles, removes the generated incoming call. Please answer how to deal with these type of Situations.

I'm having similar issue. Did it worked for you ??

Hello, According to this announcement, can you confirm that we have until June 30 to complete the changes related to callkit? Thank you

I have the same problem with my xmpp app, do you found any alternative way to handle it?

Kevin, just so you are aware, this is a huge FAIL for those of us working in the enterprise domain. Losing the ability to activate an app in the background for data purposes is a dealbreaker for many apps.


Firstly thank you for this information,

Secondly, You mentioned not needing to report new calls when we already have a ringing or active call.
What happens if we get two voip pushes at the same time, for example from two different callers.
From our testings, (Xcode 10, not 11 yet) when the second push arrives, we still do not have an active or ringing call reported from the first push. Do we need to still report a call for the second push? Doing that resulted in both calls reporting succesfully and eventually failing after the user sometimes needing to respond to two incoming call screens one after the other.
Will this behaviour be rectified when building with xcode11?

Best Regards

Hi Ptank,
I Dont know "how to handle call cancellation scenario?"
This post explained Voip and sip call all kinds of details :

I hope this post will helps to you.

I do agree 100% with this.

There could be multiple reasons to reject the Incoming Call from SipStack when INVITE is recieved.

Showing GHOST incoming call in Apple CALLKIT UI, while call gets rejected from Sip Stack , as SDP in INVITE does not have attributes that could match.

It looks like the "call failed" issue has been fixed with iOS 13.2.

Did you ever find a solution to your problem with "Call Failed"? I'm experiencing this issue too.

The same to me. The callback is not called. But DTS think it's probably our Callkit code blindy do "action.fulfill()".

func provider(_ provider: CXProvider, perform action: CXStartCallAction) {

I change my code, but still have the problem.

There is another problem here.

AFAIK Apple won't approvel any application with Callkit in Chinese App Store as Chinese gov required, which means I can not use PushKit neither in Chinese App Store? These seems no way to use PushKit avoiding CallKit, am I corrected?

I'm facing the same issue: if a cellular call is in progress, it fails when a VoIP notification arrives (displaying alert "Call failed") and the delegate method pushRegistry:didReceiveIncomingPushWithPayload:forType:[withCompletionHandler:] is not called.