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 <[email protected] >: > 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]} <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]} <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, > 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!
