Hi,
There are multiple scenarios and possibilities for this behavior, please check,
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?
2. How many distinct SIP re-registers (SQL Updates) you have at a time? Please also check if they are lower then actual endpoints.
Thank you.
And another question that goes along with this:
Do I need `db_timer_clean` to make db_mode 2 work as expected?
A reasonable person would conclude from the documentation for
`timer_interval` and `db_mode 2` ...
"2 - Write-Back scheme. This is a combination of previous two
schemes. All changes are made to memory and database synchronization
is done in the timer. The timer deletes all expired contacts and
flushes all modified or new contacts to database."
"The module uses a timer to delete expired contacts, synchronize with
database and other tasks, that need to be run periodically."
... that deletion of expired contacts is propagated to underlying DB
storage (passed through the logic of whichever db_mode) in the form of
periodic deletions of expired contacts.
It appears not to be enabled by default. DELETE statements appear to be
issued periodically from usrloc even though it's not enabled.
So, what's that setting for? When and why do I need it?
-- Alex
On Fri, Mar 06, 2020 at 12:58:16PM -0500, Alex Balashov wrote:
> Hi,
>
> On 4.4.7, since switching to db_mode 2 for usrloc with the following settings:
>
> modparam("usrloc", "db_mode", 2)
> modparam("usrloc", "timer_procs", 2)
> modparam("usrloc", "skip_remote_socket", 1)
> modparam("usrloc", "timer_interval", 30)
> modparam("usrloc", "matching_mode", 0)
>
> I seem to run into a situation where, despite starting from zero local
> registrations and an empty DB `location` table, out of ~1700
> registrations visible in the runtime usrloc table, about 60-80 never
> make it into the database.
>
> This is because they're being continuously UPDATE'd rather than
> INSERT'd, so there is some presumption that they should already be in
> the Postgres database. But they're not.
>
> This gap seems to very slowly grow over time.
>
> I understand that this option is intended to deal with a scenario like
> that:
>
> https://kamailio.org/docs/modules/5.3.x/modules/usrloc.html#usrloc.p.db_check_update
>
> but the documentation doesn't say it needs to be on for db_mode 2 to
> work correctly, and it's off by default.
>
> I'm wondering what causes certain registrants to get into this state in
> the first place, where the registrar presumes that they've already been
> synced to the DB and only need to be update'd on renewal, where in fact
> they have not been synced.
>
> Causes I've ruled out:
>
> 1) The contacts being ignored due to non-local socket or other
> invalidation;
>
> 2) Contacts being explicitly deleted by an outside process.
>
> Any ideas appreciated!
>
> -- Alex
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users