iOS 10 VoIP background mode no longer supported?

I'm using VoIP background mode in our App, I'm now using iOS 10 developer beta with Xcode 8 beta, I found this print

after calling

- (BOOL)setKeepAliveTimeout:(NSTimeInterval)timeout handler:(void(^ __nullable)(void))keepAliveHandler


"Legacy VoIP background mode is deprecated and no longer supported"

I know this API is depricated since iOS 9, I want to make sure, does it mean this API will not work at all in iOS 10 and later?

Accepted Reply

In iOS 10, you should be using PushKit for handling push notifications for incoming VoIP calls. So when you build your app against the iOS 10 SDK, you need to move over to PushKit (which can be supported all the way back to iOS 8, but once you move to iOS 10 our recommendation is to update your minimum deployment target to iOS 9).

Replies

In iOS 10, you should be using PushKit for handling push notifications for incoming VoIP calls. So when you build your app against the iOS 10 SDK, you need to move over to PushKit (which can be supported all the way back to iOS 8, but once you move to iOS 10 our recommendation is to update your minimum deployment target to iOS 9).

As was stated in a similar thread before, while PushKit might satisfy the need of any actual online server based solution, this leaves a giant hole for VoIP apps that are supposed to work in closed networks or with server hardware that can not easily be update to follow any new concept.

I do agree on deprecating interfaces, when a proper solution has been provided for a long enough time, however, PushKit in no way satisfies as a replacement to the previous background mode and its capabilities.


So, is Apple oficially not interested in supporting any VoIP applications other than those tied to their push servers?

We are running into similar issues. Some of our customers use the App to connect to generic SIP servers/PBXs, even in closed networks where neither server nor client have a connection to the internet.

Using iOS 10 will render our App useless for these customers as we can't use PushKit without internet connectivity.

Also, connecting to generic SIP servers which are not under our control is becoming impossible because we can't implement a push infrastructure on these servers.


We fully understand the disadvantages of the legacy API and the advantages of PushKit and we do want to use PushKit were it is possible. But there simple are use cases where using PushKit is not an option due to infrastructure restrictions and for these, we still need the legacy API to continue working.

I have also the same opinion.


For the majority of case, PushKit (starting iOS9) a great experience. It works fine and you don't need to spend data and energy to maintain connection.

(Legacy VoIP may cause battery issue especially if you have several app doing VoIP)


However I have a use case where the VoIP app is communicating direclty to the SIP server. And it works without acces to Internet.

Additionaly legacy VoIP appears to be a little faster.


The best situation woule be to keep this method for special cases (logs in iOS10 talks about "VoIP Legacy entitlement")

Hi,


Understood that at client we shall use Pushkit to receive VOIP notifications. There is some confusion with the usage of "aps" key at server. Can you confirm if by default all pushes sent using SSL certificate with voip extension are high priority pushes?


If not, & we need to set priority as high, doc says can't use high priority alone with "content_available". Does that mean silent notifications shall always be low priority even for VOIP?


If above things are valid, that means for VOIP, to make pushes high priority, its mandatory to send one of alert/sound/badge along with content-available for high priority VOIP notifications?


Shall really appreciate your clarification on the same.


Regards,

_Ayush

Yes, from the documentation for Voice Over IP (VoIP) Best Practices:


  • VoIP pushes are considered high-priority notifications and are delivered without delay.
  • Unlike standard push notifications, which the user must respond to before your app can perform an action, VoIP pushes go straight to your app for processing.

Hi,


Thankyou so much for the clarification.


That means, "apns-priority" & "aps" key 'content-available' are irrelevant in the context of Voip Push.


Also, as per the link you shared, "VoIP pushes can include more data than what is provided with standard push notifications." Do you mean Voip push can have more than 4k bytes?


Regards,

_Ayush

I am still missing a clear answer as to wether the VOIP background mode will continue working or not with iOS 10


We currently have a VOIP app in the App Store using the VOIP background mode. This realease continues to work when downloaded from the App Store on iOS 10.

However, when I rebuild the same App using XCode 8 beta 6, I curently fail to get background mode support.

This to me is confusing, as it seems that this mode should either be deprecated but still supported or unavailable for any app.


Is this likely an error on my part, building with XCode 8, or is this the expected behavior?

And what is to be expected with the iOS 10 release... will VOIP background mode apps already in the store continue working?

It is not uncommon for iOS to enable backwards compatibility (at least for some period of time). The operating system knows what version of the SDK your app was built against so it can determine "ah, you were built against iOS 9 or earlier so I'll preserve the functionality that this binary is expecting". This helps ensure that customer's apps don't spontaneously start failing.


However, since linking against iOS 10 is a conscious step and doing so means that you have to handle any changes in behavior that come with the new SDK. And in this case the VoIP background mode is being deprecated so when you link against iOS 10 that's what you need to adapt to.


So apps that are currently in the store (which today are all linked against iOS 9 or earlier, by definition) will continue to work. For how long? I don't know the answer to that question, but now that the VoIP background mode is deprecated that is your strong signal that it's time to move forward.


I hope that helps clarify the difference you're seeing with regard to the existing app store version and your locally built version.

Post not yet marked as solved Up vote reply of pdm Down vote reply of pdm

My question still stands (same as my unanswered bugreport):


How can we use an iOS 10 VoIP App (for CallKit support) in closed internal networks (dark data center) where no connetion to the internet is possible?

Clearly, we can't use PushKit as the servers can't be reached for obvious reasons. This are actual use cases for some customers and we can't force them to open up their network infrastructure.

My question still stands …

OK, let’s answer that.

How can we use an iOS 10 VoIP App (…) in closed internal networks (…) where no connetion to the internet is possible?

There’s no supported way to do this. To use CallKit you must link with the iOS 10 SDK, and if you link with the iOS 10 SDK you will not be able to use the legacy VoIP API.

It’s fine to file a bug about this, and it sounds like you’ve already done that. Thanks! What was your bug number?

As to what you can do right now, my recommendation is that you work with your customers to determine which of these requirements they’d prefer to give up.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Same scenario as other replys. We need to support users with closed network. As of iOS 10 GM seed, it looks like no changes made on this topic.


Is it official that on iOS 10 and later, any VoIP app which needs to support closed network connection between client and server will no longer be supported?

My company also suffers from the VoIP background mode deprecation. We develop secure VoIP solutions for public and law enforcement organisations. In this domain of VoIP communications, it's pretty typical to have a closed network without access to Apple Push Servers. We are happy to integrate CallKit + VoIP Push when it's possible, but what to do with all the existing installations in closed networks?!

Our company have a little different situation with push notifications. We are providing self hosted VOIP service.

Each client installs server on its own location. All clients are using one same app from AppStore, and then enter their endpoint in app.

This works great with VOIP sockets.


To adopt PushKit, we found 2 ways, but neither works for us:


1.) we ask our clients to open connections to APN servers and bundle our private APNS certificate into server side software to all clients.

This is big issue, if just one of our clients abuse certificate, our APNS certificate will be revoked and app will no longer work for any clients.



2.) we create gateway between clients servers and APNS and put certificate there.

All clients depends on our gateway, which is not acceptable for clients.


Any ideas / suggestions, how to solve this issue?

1.) we ask our clients to open connections to APN servers and bundle our private APNS certificate into server side software to all clients.

I would strongly recommend against that.

2.) we create gateway between clients servers and APNS and put certificate there.

That’s what I’d do in your situation.

All clients depends on our gateway, which is not acceptable for clients.

All you can do here is explain the current situation to your clients and have them decide what they want to do. The relevant factors include:

  • CallKit and the legacy VoIP architecture are mutually exclusive, at least as far as supported solutions are concerned.

  • The legacy VoIP architecture was effectively replaced in iOS 8, was officially deprecated with iOS 9, and is now only available as a compatibility feature.

  • While Apple hasn’t announced an official end-of-life date for the legacy VoIP architecture — and I can’t say when, or indeed if, that will happen — the previous point makes it patently clear that you should be planning for that eventuality.

  • You can file an enhancement request describing your unique requirements, and hope that Apple addresses this issue in the future, but you still have to plan for the possibility that that might not happen.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"