<div dir="ltr"><div>Hi,</div><div><br></div><div>There are multiple scenarios and possibilities for this behavior, please check,<br></div><div><br></div><div>1. What kind of sip endpoints you have? Any TCP based transport e.g. TLS or WSS endpoint? Are they mobile apps (especially iOS devices) with push notification and "backgrounding" support?<br></div><div><br></div><div>2. How many distinct SIP re-registers (SQL Updates) you have at a time? Please also check if they are lower then actual endpoints.<br></div><div><br></div><div>Thank you.<br></div><div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 6, 2020 at 7:32 PM 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">And another question that goes along with this:<br>
<br>
Do I need `db_timer_clean` to make db_mode 2 work as expected?<br>
<br>
A reasonable person would conclude from the documentation for<br>
`timer_interval` and `db_mode 2` ...<br>
<br>
   "2 - Write-Back scheme. This is a combination of previous two <br>
   schemes. All changes are made to memory and database synchronization <br>
   is done in the timer. The timer deletes all expired contacts and <br>
   flushes all modified or new contacts to database."<br>
<br>
   "The module uses a timer to delete expired contacts, synchronize with<br>
   database and other tasks, that need to be run periodically."<br>
<br>
... that deletion of expired contacts is propagated to underlying DB<br>
storage (passed through the logic of whichever db_mode) in the form of<br>
periodic deletions of expired contacts.<br>
<br>
It appears not to be enabled by default. DELETE statements appear to be<br>
issued periodically from usrloc even though it's not enabled. <br>
<br>
So, what's that setting for? When and why do I need it?<br>
<br>
-- Alex<br>
<br>
On Fri, Mar 06, 2020 at 12:58:16PM -0500, Alex Balashov wrote:<br>
<br>
> Hi,<br>
> <br>
> On 4.4.7, since switching to db_mode 2 for usrloc with the following settings:<br>
> <br>
>    modparam("usrloc", "db_mode", 2)<br>
>    modparam("usrloc", "timer_procs", 2)<br>
>    modparam("usrloc", "skip_remote_socket", 1)<br>
>    modparam("usrloc", "timer_interval", 30)<br>
>    modparam("usrloc", "matching_mode", 0)<br>
> <br>
> I seem to run into a situation where, despite starting from zero local<br>
> registrations and an empty DB `location` table, out of ~1700<br>
> registrations visible in the runtime usrloc table, about 60-80 never<br>
> make it into the database.<br>
> <br>
> This is because they're being continuously UPDATE'd rather than<br>
> INSERT'd, so there is some presumption that they should already be in<br>
> the Postgres database. But they're not.<br>
> <br>
> This gap seems to very slowly grow over time. <br>
> <br>
> I understand that this option is intended to deal with a scenario like<br>
> that:<br>
> <br>
>    <a href="https://kamailio.org/docs/modules/5.3.x/modules/usrloc.html#usrloc.p.db_check_update" rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.3.x/modules/usrloc.html#usrloc.p.db_check_update</a><br>
> <br>
> but the documentation doesn't say it needs to be on for db_mode 2 to<br>
> work correctly, and it's off by default.<br>
> <br>
> I'm wondering what causes certain registrants to get into this state in<br>
> the first place, where the registrar presumes that they've already been<br>
> synced to the DB and only need to be update'd on renewal, where in fact<br>
> they have not been synced.<br>
> <br>
> Causes I've ruled out:<br>
> <br>
> 1) The contacts being ignored due to non-local socket or other<br>
> invalidation;<br>
> <br>
> 2) Contacts being explicitly deleted by an outside process.<br>
> <br>
> Any ideas appreciated!<br>
> <br>
> -- Alex<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>
<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></div>