[SR-Users] Integrating Push Notifications with iOS

Steve Davies steve-lists-srusers at connection-telecom.com
Wed Apr 22 13:32:11 CEST 2020


HI German,

We have some experience in this.   As someone far away in South Africa, we
are accustomed to very slow push.  For us, actually, Apple push is much
slower than Android - Google has made more effort to push their edge into
South Africa.

We have several thousand users on webrtc mobile clients.

On iPhone, especially if our app is shut down and the phone off, it can be
many seconds from sending the voip push to receiving a response from the
app so that you can "release" the invite.  When I say many seconds it can
certainly be more than 10 seconds.

Obviously longer on older, slower phones.

Unfortunately Callkit obliges you to present a ringing "call" as the push
is received which is sucky since at that time there is actually no call.
So if the user answers quickly you have to paste over the interim until
there is an actual INVITE to answer.  WhatsApp displays a "connecting"
screen; on our side we didn't deal with this gap properly yet.

This obviously is a poor experience but it's not really under our control
and Apple is determined that it's their way or the highway.

IOS will not put the app back to sleep in my experience.  However if an
issue causes your app to crash after the voip push has resulted in CallKit
"ringing", you can en up with a ringing call which isn't actually there.
We are using react-native-webrtc and components such as the incallmanager
and we have had bugs in these libraries causing this to happen.

I can attempt to get a distribution of the elapsed time from push to invite
released - never really looked at is statistically but now i am
interested....

We don't do all this with Kamailio (though we use Kamailio a lot).  But the
principle we use is to do this on a b2bua approach.  So we return a 100
trying back to the originator, then we send all the pushes to the
"registered" clients.  IIRC we send back 180 once we've sent a push.  We
then (hopefully) receive specially authenticated registers than we OK
without further authentication,  And that releases the INVITE.

As long as the caller waits (ie until we get a CANCEL) we'll deal with
incoming registers and release invites.  And if they wait long enough there
will hopefully be a 200 from a client and a call is set up.

Steve



On Wed, 22 Apr 2020 at 10:53, German Cancio <German.Cancio.Melia at cern.ch>
wrote:

> Michal,
>
> thanks for your reply - it’s more a general question on how much time
> there is on iOS between receiving the APNS on the client, doing the
> REGISTER cycle and getting back the INVITE. I’m thinking of possible
> delays/latency issues between these three steps that may cause calls to
> eventually fail because iOS decides to put the app back to sleep.
>
> cheers, Germán
>
>
> On 22 Apr 2020, at 08:55, Michal Popovic <michal.popovic at cloudtalk.io>
> wrote:
>
> Hi,
>
> why do you lost a call? Are you sending 100 Trying before you put
> transaction to TSILO?
>
> Bye,
> Michal Popovič
>
>
> On 22 Apr 2020, at 07:58, German Cancio <German.Cancio.Melia at cern.ch>
> wrote:
>
> Dear All,
>
> we are working on the integration of VoIP Push Notifications with iOS
> devices via Kamailio. From what we observe, the time window between
> receiving a VoIP APNS notification that wakes up the client app and the
> client app being sent back to the background by iOS is extremely narrow. It
> is around 1-2 seconds, with a (seemingly random) variance of say ~0.5s.
> So 1-2s is the time window available for getting the client app to
> properly REGISTER and to receive the INVITE back from Kamailio (using e.g.
> TSILO); otherwise the call is lost. (On Android, the equivalent time window
> extends to 10s or more.)
>
> Have others observed the same on iOS? We are using a client app that still
> uses the iOS 12 SDK (with Xcode10). Can we expect changes in that regard
> with iOS13/Xcode13?
>
> many thanks and cheers, Germán
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200422/f7054da0/attachment.html>


More information about the sr-users mailing list