setting $xavp(reg=>max_contact) will limit new registration and updates, but not deleting existing ones

[amessina]

Description

I'd like to reduce the number of contacts per AOR for certain UAs, while maintaining a default higher limit.

modparam("registrar", "max_contacts", 10)
modparam("registrar", "xavp_cfg", "reg")

route[REGISTRAR] {
    if($ua=~"^Yealink") {
        $xavp(reg=>max_contacts)=1;
    }

    if(!save("location")) {
        sl_reply_error();
    }
    exit;
}

Expected behavior

https://www.kamailio.org/docs/modules/stable/modules/registrar#registrar.p.xavp_cfg states:

• max_contacts - the number of maximum contacts to be stored for the current registration AoR. It overwrites the 'max_contacts' module parameter value.

I expect that the UA will register with the new contact and have all others removed.

Actual observed behavior

$xavp(reg=>max_contacts) set to a value lower than the max_contacts modparam does not achieve the overwrites expectation from the documentation.

Log Messages

INFO: registrar [save.c:619]: test_max_contacts(): too many contacts for AOR <user@example.com>

Additional Information

• Kamailio Version - output of kamailio -v

version: kamailio 5.4.1-1.gite1d4ddcb6c.fc32 (x86_64/linux) 09fd6a
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 09fd6a 
compiled on 00:00:00 Sep  5 2020 with gcc 10.2.1

• Operating System:

Fedora 32, kernel-5.8.4-200.fc32.x86_64

[henningw]

The module behaves in another way, i think. The max_contacts parameter will disallow new registration and also update of existing registrations. But it will not remove old existing registrations by itself. The docs can be always extended to make it more clear, otherwise this is probably a feature request.

[amessina]

@henningw sorry I though I hit the feature request button when creating this.

[henningw]

@amessina No, actually i did a mistake in my reply, you filed it all right as feature request.

[miconda]

Because the registration process in sip is periodical, but each endpoint can select its expires interval, the oldest contact may hit a valid record, for example the case of a user with a fixed end point registering every 3600 seconds and another mobile one that registers every 5 min, but because of losing the wireless connectivity it keeps adding new contacts. That was the discussion where the limit of registration was decided to be done by rejecting new registrations.

Now, if you want to remove certain contacts, the oldest, older or newer, it is possible to do in config right now with reg_fetch_contacts(), then loop through contacts to decide which should be removed and do unregister() using the ruid field.

Note also that there is a flag for save() to store a single contact per user, removing the existing one -- maybe that can fit in some scenarios

Anyhow, if someone wants to make this option in the code controlled via modparam or function params, I am fine with it.

Given that it is already possible via config operations, this feature-request should be closed unless a developer engages in adding it and wants to track the evolution here. Otherwise, a PR with implementation in the C code for a simpler config can be just submitted at any time, no need to have the FR open.

[amessina]

Thank you @miconda. Based on your description, I was misunderstanding the documentation about the usage for this $xavp. I understood the documentation to mean that $xavp(reg=>max_contacts)=1 would function effectively like save("location", "0x04").