Hi,
it's hard to track the actual state of the client in mobile scenarios. You can achieve a better precision if you use tcp (tls) and Kamailio's tcpops functionalities to track socket status and trigger deletion of the usrloc entry, but even this is not 100% reliable. The simplest solution, imho, is to relay the INVITE to the contacts you have in your usrloc table AND send the push notification request as well. As you said, if the client is already registered the push won't trigger a new registration but the client will receive the INVITE on the "straight" path. On the other hand ,if it is not the push will trigger a REGISTER and the first branch you sent out will either be cancelled if the new branch triggered by registration is answered, either it will timeout as in a normal scenario.
Hope this helps.

Cheers,

Federico

On Fri, Apr 17, 2020 at 8:46 AM Hubert Odziemczyk <hubert.odziemczyk@cern.ch> wrote:
Hello!

We are trying to setup a call-flow with TSILO and Push Notifications for solution with a mobile SIP client (Linphone), based on presentation by Federico Cabiddu (http://www.kamailio.org/events/2015-KamailioWorld/Day2/20-Federico.Cabiddu-Kamailio-In-A-Mobile-World.pdf).

We have an issue with "managing" state of the client (active or not) when there is a call coming. To be more specific, lookup in location table doesn't always give a proper answer, as contact expiration is different from actual lifetime of the app (which also differs between iOS and Android).
One of proposed solutions is setting Expires=1 for REGISTER and then always rely on Push Notifications, but this scenario seems to be unreliable with some clients that are in foreground, as Push Notification doesn't trigger REGISTER again.

Question is: did you perceive similar problems? What are your solutions to deal with them?

Thank you in advance!

Best regards,
Hubert
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users