iOS push notification in delayed Network
We are developing iOS VOIP app it supposed work in 5/6 second delayed network in running background, Our observation is in 4 second delayed network any push notification does not arrive from Apples APNS server to our VoIP app as a result incoming call missed when it goes suspended.
Any help would be appreciated!
Thanks
You can not rely on push notification for such feature, push notification may never arrive.
if you want to use third party app i will suggest you to use
Sinch :https://www.sinch.com/downloads/
Related
Recently Apple changed its way of handling VoIP notifications. Now they force you to use CallKit in the same run loop in order not to throw your notification away. The trace I get is this one
Apps receving VoIP pushes must post an incoming call (via CallKit or IncomingCallNotifications) in the same run loop as pushRegistry:didReceiveIncomingPushWithPayload:forType:[withCompletionHandler:] without delay.
When you get this warning three times, the system is "dropping your notifications on the floor".
The problem here is that I'm developing a hybrid VoIP app using the phonegap-plugin-push, and I'm afraid that the on notification event is not fast enough (or at least not the same run loop) for iOS.
Did anyone face this issue?
I've thought of changing to regular push notifications, but I can't find a way to make my app relaunch when it's killed and execute some code (launch CallKit, for example).
Edit:
I'm trying this approach with push notifications and I already configured the background modes. I noticed that sending the "content-available" and some data, like "badge", or "alert" in the notification, the app is launched if it went to background recently. After 15 minutes in the background the push notification arrives but the app doesn't launch anymore
Thank you in advance.
Our app uses CallKit and push notifications, and it launches when a push notification arrives for a new incoming call. It has to be configured in the project build and run once to register with iOS for this, though.
I found a solution:
Since iOS changed its policy about handling voip push notifications, it forces you to report a new incoming call when receiving the voip: https://forums.developer.apple.com/thread/117939
This plugin does it: https://github.com/mattkhaw/cordova-plugin-callkit
It merges two plugins (WebsiteBeaver/CordovaCall and Hitman666/cordova-ios-voip-push). It worked for me. I just had to remove the receiveCall from the javascript and tweak a little bit the plugin.
The methods related to the voip notifications register are in the cordovaCall class, so it is pretty straightforward to work with.
I am using FCM notification for my app. When my app is in background or foreground I am receiving notification. But when my app is terminated that means closed from task then I am not receiving any notification. I searched about this and I am confused is it work when the app is terminated? I just need to know is it work or not when the app is terminated.
If it works when the app is terminated then I will go for next step for my app otherwise I will stop my implementation that's why I am not sharing any code. I followed this link
Beware with fcm on iOS, there are 2 ways of sending and receiving data; one is upstream/downstream messages the other is the push notifications. If you are using upstream/downstream messages the fcm connection is closed after the app is suspended, new messages will not wake your app. You may use push notifications instead but of course the downside is that they are push notifications you don't have much control over them.
Like many here, I was looking for a reliable way to deliver push notifications to an app for background processing. I finally decided to use PushKit and all works well and the app was accepted into the AppStore, even though it's not a VoIP application. I'm using the AWS SNS (Simple Notification Services) to handle the backend push processing. However, even VoIP notification delivery will be throttled by iOS if you send excessive push notifications. As a simple test, I can send several VoIP notifications over 2 - 3 min and they will deliver promptly and processed by the app in the background. After I wait about 10 minutes (after locking the iPad and waiting for the application to be put to sleep by iOS) a subsequent VoIP push won't be delivered promptly by iOS. AWS is pushing the notification, but iOS is not delivering it to the app. I know this because as soon as I plug in the device, the notification is processed by the application. As an aside, if the device is left plugged in, all notifications deliver and process promptly.
So my question is this: Have others noticed this behavior with VoIP pushes also? Even though the iOS docs indicate that VoIP pushes are delivered immediately, it appears that iOS does throttle them if it considers the pushes "excessive" over some period of time.
I guess, When you keep your app in background then you receives push notification. but when your app is in terminated then don't receive push notification.
Possibly your app gets crash when it is in killed ( terminated ) state.
Pushkit silent notification is always with higher priority and works well all the time.
Try below things to find out cause and solution.
(1) Debug your app in killed ( terminated ) state, like app is crashing or not
(2) Send silent notification with simple php code using pem and certificates ( Both case background and killed ( terminated ) )
(3) Check pushkit integration steps, if your app is not registered for VOIP, then it would not receive silent notification.
Debug pushkit notification in terminated state
Put debug pointer on delegate methods
Go to edit scheme
Select run option then Launch -> Wait for executable to be launched
Send push kit payload from back end
Once you get payload on device
it will automatically invoke and debug pointer will invoke at delegate methods.
Refer some material
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.