[prev in list] [next in list] [prev in thread] [next in thread] 

List:       serusers
Subject:    [SR-Users] Re: No access to variables within timer route
From:       dries--- via sr-users <sr-users () lists ! kamailio ! org>
Date:       2023-11-30 20:12:04
Message-ID: 170137512473.1570.11052193782945103037 () main ! kamailio ! org
[Download RAW message or body]

So the initial idea was to prolonge the expiry of the redis key within the timer. The \
expiration would be set to a value a bit higher than the timer interval. At each \
timer iteration, the key would be renewed. That way, if a call teardown occurs \
because of an unexpected event (so no BYE/CANCEL), the redis object would expire \
itself because the timer would stop running (and thus renewing the key) if the call \
transaction had ended? However, I can't do that since I need to get the \
call-id/extension within the timer route to pick the right key.

So my alternative would be to store the dialogs into redis and loop over those within \
the timer to compare them to the existing callstate keys. If a dialog would no longer \
be known, I could delete the matching callstate key. However, it appears that the \
dialogs aren't cleaned up during unexpected events so it's of no use neither?

Regards
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic