Thanks for your reply Henning!
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. Good idea, that should be easily doable. I haven't seen that the variable "$ulc(profile=>addr)" is also iterable... I always used the top most element (without the square brackets) and that was the expired record.
Best regards Mathias
Am Di., 18. Feb. 2025 um 17:09 Uhr schrieb Henning Westerholt <hw@gilawa.com
:
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 sr-users@lists.kamailio.org *Sent:* Dienstag, 18. Februar 2025 10:32 *To:* sr-users@lists.kamailio.org *Cc:* Mathias Schneuwly mathias@schneuwlys.ch *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:200101@10.0.1.130:42323;transport=tls", "Expires": "deleted", -- "Address": " sips:200101@10.0.1.129: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 952600514-5060-52@BA.A.C.BCI} <core> [core/kemi.c:157]: sr_kemi_core_log(): reg_fetch_contacts: sips:200101@10.0.1.130:42323;transport=tls Feb 18 10:05:51 ttel /usr/sbin/kamailio[2356327]: WARNING: {1 511 INVITE 952600514-5060-52@BA.A.C.BCI} <core> [core/kemi.c:157]: sr_kemi_core_log(): lookup_xavp: aor=200101, uri=sips:200101@10.0.1.130:42323;transport=tls, socket=tls: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:200101@10.0.1.130:42323 ;transport=tls|||2460724.91858218|-1.0|482845299-5060-1@BA.A.B.BDA|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