Hello Matthias,

after a quick look to the code, it seems that the lookup_xavp indeed does not 
filter for expired contacts. At least the documentation is probably misleading 
here, I would also expect that it behaves similarly to the standard lookup 
function. We probably should fix this in the code, not sure if people really 
rely on the current behaviour.

For the reg_fetch_contact case you probably could manually check the expires 
value against the current time and not use the contact if it expires.

Cheers,

Henning

From: Mathias Schneuwly via sr-users <[email protected]>
Sent: Dienstag, 18. Februar 2025 10:32
To: [email protected]
Cc: Mathias Schneuwly <[email protected]>
Subject: [SR-Users] Outdated location information on deleted registrations

Hi

I'm using Kamailio 5.8.4 and the python KEMI module.

When I move the registration from one device to another, I can see for a while 
two entries with 'kamctl ul show' where the Expires parameter of the "old" 
registration is set to "deleted" and the "new" registration shows the seconds 
until the registration expires.

                      "Address":  "sips:[email protected]:42323;transport=tls",
                      "Expires":  "deleted",
--
                      "Address":  "sips:[email protected]:56374;transport=tls",
                      "Expires":  3600,

So far so good. When I try to fetch the actual registration address using 
"registrar.reg_fetch_contacts" or "registrar.lookup_xavp", I'm always getting 
the "old" deleted registration address instead of the new address as long as 
the deleted record is not removed.

Feb 18 10:05:51 ttel /usr/sbin/kamailio[2356327]: WARNING: {1 511 INVITE 
[email protected]<mailto:[email protected]>} <core> 
[core/kemi.c:157]: sr_kemi_core_log(): reg_fetch_contacts: 
sips:[email protected]:42323;transport=tls
Feb 18 10:05:51 ttel /usr/sbin/kamailio[2356327]: WARNING: {1 511 INVITE 
[email protected]<mailto:[email protected]>} <core> 
[core/kemi.c:157]: sr_kemi_core_log(): lookup_xavp: aor=200101, 
uri=sips:[email protected]:42323;transport=tls, 
socket=tls:10.0.1.1:5061<http://10.0.1.1:5061>, dsturi=None

I also see that the database is only updated after the deleted entry is 
removed. Until then, the database still contains the old address. Btw, I'm 
using "modparam("usrloc", "db_mode", 2)", which would explain the delayed 
persisting into the database.

62|uloc-67b44aae-23f48e-2|200101||sips:[email protected]:42323;transport=tls|||2460724.91858218|-1.0|[email protected]|2002|2460724.87691551|0|0|Grandstream
 GXV3350 
1.0.3.52|tls:10.0.1.1:5061|7135|<urn:uuid:00000000-0000-1000-8000-C074AD188038>|1|0|52|0|16

I'm asking myself whether the behavior is correct that 
"registrar.reg_fetch_contacts" and "registrar.lookup_xavp" are returning the 
deleted information instead of the "new" registration information? If yes, is 
there another way how I could get the "new" registration information? I'm not 
really interested in the old outdated information...

Best regards
Mathias
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- 
[email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the 
sender!

Reply via email to