Re: [SR-Users] Integrating Push Notifications with iOS

Hi Steve, many thanks for your verbose feedback! From what i understand you manage to send back an INVITE as soon as you are done with the REGISTER forth-and-back. This is precisely what we have been struggling with. A poor man’s proof-of-concept of doing a sleep after a push notification (and thus delaying the INVITE, hoping that REGISTER arrives in the meantime) kind of works on Android, but not at all on iOS. Therefore we are moving to use TSILO for handling the REGISTER OK quickly followed by an INVITE. cheers, Germán On 22 Apr 2020, at 13:32, Steve Davies <steve-lists-srusers@connection-telecom.com<mailto:steve-lists-srusers@connection-telecom.com>> wrote: 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@cern.ch<mailto:German.Cancio.Melia@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@cloudtalk.io<mailto:michal.popovic@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@cern.ch<mailto:German.Cancio.Melia@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@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users