The current API changes for iOS9 state that -setKeepAliveTimeout:handler: is deprecated.
Up to now, this was the only way that a VoIP SIP app on iOS could maintain its registration with the SIP-server.
This technique is used by various apps like LinPhone and others.
Does anybody have a view on the proposed alternatives by Apple ? Or will SIP be crippled starting from (post-)iOS9 ?
Apple document the alternative in the page you linked:
Discussion
In iOS 8 and later, voice-over-IP (VoIP) apps register for
UIRemoteNotificationTypeVoIPremote notifications instead of using this method.
It seems that you have to leak the signaling event to the apple push notification server by registering for https://developer.apple.com/library/prerelease/ios/documentation/UIKit/Reference/UIApplication_Class/index.html#//apple_ref/occ/instm/UIApplication/registerForRemoteNotifications .
This is quite unfortunate, but seems unavoidable. The idea behind this is probably to save battery by having fewer active network connections on the phone.
So this means that you have to leak the information that an event has reached your application to apple services. You can probably just send a 'wake' notification to your app and then handle loading the event type yourself - but this might incur too much latency, so you might need to leak more of the signaling information to apple services. :-/
From Apple's Docs:
In iOS 8 and later, voice-over-IP (VoIP) apps register for registerForRemoteNotifications remote notifications instead of using this method. Using remote 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 remote 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.
In the past, the setKeepAliveTimeout call used to allow a handler to be called a the end-time and would have a max of 10 seconds to exit or be forced to terminate, also calls to the handler are not guaranteed to be within the timeout value.
The new (registerForRemoteNotifications) would be ok to work with since the handler is internal (to IOS) and would in-turn call your app when a remote-event occurs (this would even wake your app if it's in-sleep).
Either way, both should do the same thing, the older version you would handle the code, and the new one, you would receive a notification (also handle it somewhere), but you will no longer control the timeout.
From Apple docs:
Call this method to initiate the registration process with Apple Push Notification service. If registration succeeds, the app calls your app delegate object’s application:didRegisterForRemoteNotificationsWithDeviceToken: method and passes it a device token. You should pass this token along to the server you use to generate remote notifications for the device. If registration fails, the app calls its app delegate’s application:didFailToRegisterForRemoteNotificationsWithError: method instead.
If you want your app’s remote notifications to display alerts, play sounds, or perform other user-facing actions, you must call the registerUserNotificationSettings: method to request the types of notifications you want to use. If you do not call that method, the system delivers all remote notifications to your app silently. Because the registration process takes into account the user’s preferred notification settings, requesting access to user-facing notification types also does not guarantee that they will be granted. To find out what notification settings are available, use the currentUserNotificationSettings method.
And Finally (for Un-Registration):
You should call this method in rare circumstances only, such as when a new version of the app removes support for all types of remote notifications. Users can temporarily prevent apps from receiving remote notifications through the Notifications section of the Settings app. Apps unregistered through this method can always re-register.
Not sure, but I hope this helps.
Regards,
Heider Sati
If we integrate PUSHKIT, it will take care of everything regarding wakeup the application. If you send the push notification while getting VoIP call with Push notification via PUSHKIT, it will work if its in backgroundstate. I have done same thing.
I hope this will help you.
© 2022 - 2024 — McMap. All rights reserved.
