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.
Related
How to send VOIP call decline information to server when the app is in background? When i am trying, i am getting network connection was lost.
There is PUSH mechanism created for wake up application. But it requires support from VOIP server side.
https://docs.wonderpush.com/docs/android-push-notifications-quickstart
(or just google "android push"/"ios push")
Maybe someone ever solve the problem with stable connection to server when application is in background? I need to transfer audio data from server to client app.
I know about all hacks for iOS how to keep alive application, but I need legal methods to solve this problem. Maybe you have any idea?
I found that I can send VoIP push to device that will wakeup my app and then establish tcp connect to my server but this socket will be keep alive about 30 seconds (as I see in log, every 3 seconds fires timer in iOS app that send data to server) this is not enough for me.
Maybe this project https://github.com/SmallSharpToolsOpenSource/Speakerbox will be helpful for someone.
And this video https://www.youtube.com/watch?v=lXJ1LDjL4Os
And official answer from Apple tech support:
PushKit is how voip apps can
reliable receive silent notifications, while CallKit is basically a UI
framework voip apps can use to notify the user about calls. Note that there
is NOT any direct connection within the APIs- for example, a voip app can
generate a local notification (instead of using CallKit) or simply do nothing
and “ignore” the notification entirely. Similarly, a voip app could “fake” a
call at anytime by simply telling CallKit that there was an incoming call (our
sample code for CallKit did exactly this).
Anything your app could previously have done when
it received voip socket traffic, it could also do when it received a PushKit
notification.
Standard voip apps
actually operate in two COMPETELY unrelated “modes”:
1) While waiting for an incoming call, the app is suspended until “something”
(PushKit OR a voip socket) wakes the app to tell it about the call.
2) Once a call has started, the app has an active audio session and is relying
an the standard “background audio” behavior of iOS, just like a wide variety
of other audio apps (for example, any streaming music app).
Can we integrate VoIP services through the new framework CallKit without using any server services or push notification?
I am really new to this concept, also checked the speaker box app as a sample app but didn't get much idea how it would be working.
Please, share your feedback if anyone has integrated CallKit.
Thanks
The CallKit framework provides programmatic access to VoIP functionality, as well as call blocking and identification. Apps can use CallKit to receive incoming calls and make outgoing calls using the native phone UI.
Reference for call kit.
Can we integrate VoIP services through new framework call kit without using any server services or push notification?
No we can't use it. You will need third parties like Twilio, Plivo, or ICELink and create your own server. Then provide CallKit the data required, it will handle the call and UI stuff. You can read the apple docs for more ideas.
If a CallKit app only intends to make outgoing calls, then it may be possible to not have a server component. But if the app intends to receive incoming calls while the app may not be running (e.g. when it is suspended), those incoming calls must be signaled via Push Notification, and those push notifications are typically sent by a backing server.
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
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.