0
votes

I have feature of disconnect the video/voice call when the application is in foreground/background/kill states. Same as Voice Call in WhatsApp application

I used Callkit to display default incoming CallKit screen will trigger using VOIP push.

Scenario:

  1. Device A calls to Device B
  2. Device A disconnects call
  3. Device B will disconnect in foreground not in background and kill states because DidReceiveRemoteNotification delegate method will triggers in only foreground not in other states

Tried with Silent Push Notifications Content-Available = 1 and removed the values in Alert key while sending push payload. Still it didn't worked in Background and Kill State

Now the question is How can we trigger DidReceiveRemoteNotification in all states Or Do we have any other concept to achieve this feature.

Please give your valuable suggestions and let me know if you need more information.

1
Relying on a push notification to know when the call ends is no good practice, and there's no good way to solve the problem you are facing. Device B should get to know the call ended by a mean other than using push notifications. - pepsy
Thanks for the reply. As you said push notifications it’s not good practise, please suggest me If we have new approach to solve. - Chaitanya Dwarapudi

1 Answers

0
votes

It is important to understand that CallKit does not handle the call connection itself and also not all possible call states, even if it is involved in the whole process of call initiation and termination. So often you use some form of SIP implementation.

In any case, you must have some implementation of the call connection and audio/video streaming.
iOS and CallKit can not do that trivially for you out of the box.

While your app is notified of an incoming call through a push notification, your app is notified of the remote party hanging up through SIP or similar. But it should not be notified of call termination through a push notification. It would not really make so much sense to use a push notification, because you will already have an ongoing connection for the call anyways. This ongoing connection is then typically used to signal that either the local or remote party is hanging up, which is a feature of SIP anyways.

The reason for using push notifications in the beginning for the incoming call notification instead of a persistent SIP connection is that it saves battery life while no such benefit would result in using push notifications also for signaling call termination. So it would be best if you did not try to use push notifications to signal the call termination, but instead SIP's BYE message.

Your SIP handling code should then notify iOS through CallKit by reporting the call end through reportCall(with UUID: UUID, endedAt dateEnded: Date?, reason endedReason: CXCallEndedReason) and handle the actual call disconnection itself.

So since iOS/CallKit can not and will not handle your call connection / disconnection, you must always do this yourself or use a SIP library like PJSIP which will do a good part of that for you.