From documentation for setKeepAliveTimeout:handler: method of UIApplication:
In iOS 8 and later, voice-over-IP (VoIP) apps register for UIRemoteNotificationTypeVoIP push notifications instead of using this method. Using push notifications eliminates the need for a timeout handler to check in with the VoIP service. Instead, when a calls arrives for the user, the VoIP service sends a VoIP push notification to the user’s device. Upon receiving this notification, the device launches or wakes the app as needed so that it can handle the incoming call.
But I can't find anything about it. Is this a thing?
If someone is also confused by this documentation, they probably mean PushKit Framework and PKPushTypeVoIP presented in WWDC 2014, Writing Energy Efficient Code, Part 2
Related
I have set up the latest linphone iOS code (version 3.16.6) and I am able to make audio and video calls but if my app is in background or killed, not getting calls.
Please guide me in details that what I have to do to get the calls even when app is in background or killed.
Please let me know if there is server interaction part also there.
You have to wake up your application with voip-notification, before receiving call on background.
So you can implement your solution which send notification before every call. Notification wake an app and app receive the call
You can use callkit for UI, but callkit itself doesn't handle any background or voip work.
Use some working solution for example FlexiSip from Belledonne
http://www.linphone.org/technical-corner/flexisip/overview
FlexiSip have builtin support for iOS push notification, but you will need to generate certificates and do some server work :)
EDIT
Voip notification process.
Before every SIP Invite you have send voip notification to target device. Voip notification wake application which will be ready for accepting SIP call.
I'm not sure if you use proxy or if you making just direct calls. If you are using proxy you can try FlexiSIP which should handle this logic for you (I didn't tried). Of course you will need to provide your voip certificates to it.
If you making direct calls without SIP proxy, source application should call same API of some web service which send voip notification for target device (For example Houston API). And after you can send SIP invite from source to target application.
if My app works at background, can I use silent push to wake app and get the VOIP call?
I used "jpush" to post a silent push which can work when connecting my idevice with Xcode and run APP.
If my idevice doesn't run APP with Xcode, I can not receive the silent push at background (only receive at foreground.)
Is it possible to use silent push to wake up APP and get VOIP call?
Did I get something wrong??
Yes. If your application does VoIP calling then it's possible to use PushKit:
Overview
The PushKit framework sends specific types of notifications — such as VoIP invitations, [...] — directly to your app for processing. [...]
Unlike user notifications, which are supported by the UserNotifications framework, PushKit notifications are never presented to the user — they don't present badges, alerts, or sounds.
PushKit notifications offer the following advantages over user notifications:
If your app isn't running, the system automatically launches it upon receiving the notification. [...] For more information, see Local and Remote Notification Programming Guide.
Your app is given runtime to process the notification, even if it's running in the background.
[...]
I am developing a VOIP app, and planning to use PushKit as our push engine. We are using it to send VOIP related push to application, allowing us to setup the call.
However, are we allowed to use the same push engine for other type of messages? like a trigger to refresh news, local database, etc in the background thread.
I mean will they approve this kind of "mixed usage" on app store?
Thanks
Starting on iOS 13, you are no longer able to do so.
Now you must always report a new incoming call when you receive a voip push notification. Not doing so will cause a crash. Repeatedly failing to do so will make your app ignore subsequent voip pushes.
I am working on an app that needs reliable push messages (like any voip) under ios9.
Here it says, that with IOS8+ one should use apns (registerForRemoteNotifications):
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplication_Class/index.html#//apple_ref/occ/instm/UIApplication/setKeepAliveTimeout:handler:
In the Optimize VOIP Apps document, Pushkit is preferred:
https://developer.apple.com/library/ios/documentation/Performance/Conceptual/EnergyGuide-iOS/OptimizeVoIP.html#//apple_ref/doc/uid/TP40015243-CH30-SW1
Does anybody have a clue on this?
Or do they run the same code in the background?
From the documentation for VoIP Push Notifications:
The device is woken only when VoIP pushes occur, saving energy.
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.
VoIP pushes are considered high-priority notifications
and are delivered without delay.
VoIP pushes can include more data
than what is provided with standard push notifications.
Your app is
automatically relaunched if it’s not running when a VoIP push is
received.
Your app is given runtime to process a push, even if your
app is operating in the background.
The biggest advantage of VoIP Push Notifications over regular ones is in my opinion, that the app gets relaunched if it was force-closed.
In general, if you wan't to use the push notifications for VoIP functionality, e.g. to notify about an incoming call, use PushKit. It was developed for this purpose. For all other cases, use regular push notifications. Your app won't go through the review if you use PushKit for an app without VoIP functionality anyways.
The first solution I can think of for the incoming call notification is Apple's Push Notification service. However, it is not guaranteed.. there's a relatively high chance it may get lost.. and in a VoIP app, the incoming call notification is so important that I can't afford to miss it too often...
Thus, I followed the tips and enabled the Background Mode to keep the app alive and listening to any incoming call invite. By right, I should just show local notification when the app gets the incoming call invite. This works pretty well when the app is in background/inactive. HOWEVER, when user kills the app manually, no code will get executed, so the app won't get any incoming call invite in such a condition... And because of this particular scenario, I still have to rely on remote push notification.
What I'm trying to achieve is.. waiting for remote notification first, if it arrives, then do not show local notification anymore. If it's lost, then show local notification so that user will always get notified.
The problem is... I have no way to tell if a remote notification has arrived.
I want to know what is the best practice to handle incoming call notifications for a VoIP app?
From appleDoc Apple Developer Docs. (Updated link)
In iOS 8 and later, voice-over-IP (VoIP) apps register for UIRemoteNotificationTypeVoIP push notifications instead of using this method. Using push notifications eliminates the need for a timeout handler to check in with the VoIP service. Instead, when a calls arrives for the user, the VoIP service sends a VoIP push notification to the user’s device. Upon receiving this notification, the device launches or wakes the app as needed so that it can handle the incoming call.
Just play a very long duration audio when a APNS comes.