<div dir="ltr"><div dir="ltr">Hello ,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 14, 2020 at 4:16 AM Alex Balashov <<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 2020-09-11 08:19, sagar malam wrote:<br>
<br>
> Hello ,<br>
> I am using the usrloc module to store registrations. I could not find <br>
> any way to remove stale registrations before expires time. Most of the <br>
> registrations are mobile app so they wont run in background to save <br>
> battery of phone hence we end up having lots of registrations in <br>
> usrloc which were not removed because app was killed in background by OS <br>
> without letting it send unregister request.<br>
<br>
Are you sure that removing such registrations is the best thing to do?<br>
<br>
You don't know what the user is going to do; maybe they will be using it <br>
continuously, or maybe it'll be backgrounded. It's impossible to <br>
determine, so you can't assume any given registration is stale, and it <br>
is reasonable to attempt to contact the registrant for any given inbound <br>
call, even if the attempt is futile because it has gone unreachable.<br></blockquote><div>I am using the Keepalive to identify if any registration is stale. If KA OPTION does not get a reply then that registration is considered as stale. There is no point of keeping unreachable registration in usrloc irrespective of whether the app is in background or foreground because it will only add overhead to generate an invite which will ultimately timeout without any response.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Meanwhile, the moment the endpoint is "woken up"[1] via a push <br>
notification, it will re-register and overwrite the stale contact <br>
binding instead of adding an additional one, provided that the match <br>
mode[2] is set correctly.<br></blockquote><div>This is true for hard phones or any endpoint which has a stable internet. Here I am dealing with cellular networks so we cannot be sure if the app will be provided the same public IP and port(IP is same most of the time but not port) each time it will register with the server. So the same APP can register with the same call ID but different contact address which will create duplicate registration entries for the same APP. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- Alex<br>
<br>
[1] <br>
<a href="https://www.kamailio.org/events/2015-KamailioWorld/Day2/20-Federico.Cabiddu-Kamailio-In-A-Mobile-World.pdf" rel="noreferrer" target="_blank">https://www.kamailio.org/events/2015-KamailioWorld/Day2/20-Federico.Cabiddu-Kamailio-In-A-Mobile-World.pdf</a><br>
<br>
[2] <br>
<a href="https://kamailio.org/docs/modules/5.4.x/modules/usrloc.html#usrloc.o.contact-matching-algs" rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.4.x/modules/usrloc.html#usrloc.o.contact-matching-algs</a><br>
<br>
-- <br>
Alex Balashov | Principal | Evariste Systems LLC<br>
<br>
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)<br>
Web: <a href="http://www.evaristesys.com/" rel="noreferrer" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" rel="noreferrer" target="_blank">http://www.csrpswitch.com/</a><br>
<br>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Thanks,<div><br></div><div>Sagar</div></div></div></div>