Hi, It is important to know that the scope of $var(...) is per-process[1], and timer functions run in a different process. When REFRESH_CALLSTATE_TIMER runs, it is not in response to any particular SIP message or call, and it does not know the context of any particular SIP message or call. -- Alex [1] Which also has unexpected consequences when a different SIP message hits the same process in which a $var() was set before; they are process-persistent, as the documentation notes. -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

From the rtimer documentation overview: It runs in it's own processes, and as Alex noted $var() is per process. It's not clear if the process re-spawns so setting a variable inside the timer action will be retained through multiple executions or not. As for $avp()s, along with $xavp()s and their assorted variants, these are scoped to a SIP transaction, and the timer shouldn't be handling a transaction. Shared variables and hashtables should be available inside this route, though. It might be good to clarify what your goal is (why you expect the variables to have values in this route). -----Original Message----- From: dries--- via sr-users <sr-users(a)lists.kamailio.org> Sent: Wednesday, November 29, 2023 3:36 PM To: sr-users(a)lists.kamailio.org Cc: dries(a)degendt.com Subject: [SR-Users] Re: No access to variables within timer route CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Sorry, please ignore the variable name typo in the "REFRESH_CALLSTATE_TIMER" route in my initial post. The issue still stands however. route[REFRESH_CALLSTATE_TIMER] { xlog("L_INFO", "Testvariable: $var(testvar)\n"); } I've also tried enabling the timer on start as well as attempting to use $avp instead. All called variables within the route are either 0 or null? __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

What I'm not clear on from your example is the use of the timer: - Kamailio gets an invite, write a record to redis where the key identifies the user. - On call teardown, find the key and delete it. What is the timer route doing? It should be able to read redis. -----Original Message----- From: dries--- via sr-users <sr-users(a)lists.kamailio.org> Sent: Thursday, November 30, 2023 8:30 AM To: sr-users(a)lists.kamailio.org Cc: dries(a)degendt.com Subject: [SR-Users] Re: No access to variables within timer route CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Ben, I'll try my best to explain the use case here. I have a direct trunk between our Asterisk and Kamailio servers. My goal is that when an agent is already in call, he doesn't get prompted with another incoming call on either of his devices. So Asterisk is supposed to perform a redis check each time a call goes through the Asterisk queue. Since Asterisk can't determine the device state here, I've set up a redis cluster which is supposed to keep track of the agent's call state. For each INVITE in Kamilio, I'm storing a key into redis based on the agent's number, for example "callstate_242680". The value is the call-id. When a BYE/CANCEL is received, I'm retrieving the particular key and comparing the current call-id agains the call-id in the redis object. If it matches, I'm deleting the object so the extension is "available" again. This works pretty good but sometimes the keys are stored way too long in case a BYE/CANCEL was missed (for example, restart of Kamailio process, network interruptions, ...). I was thinking of setting a redis expiration time for each key, which would be prolonged by the timer running in each call transaction. That way I could retrieve the agent's number and increase the expiration of the matching redis key. I don't think shared memory would be possible since I can't identify the call here. As an alternative, I'm thinking of keeping track of dialogs using dlg_manage() and also store these into a local redis server (since db_redis doesn't seem to have redis cluster support). That way I can use a timer block to retrieve all the stored dialogs and compare them to the stored callstate keys. I've noticed however that the tracking of dialogs also depends of that BYE/CANCEL however so I don't think it's very usefull. An alternative method could be to update the redis object in case of a periodic ACK but that's no guaruantee. I also don't want the agent to be wrongfully "busy" for too long. I'm still trying to fit all the pieces together, I was just hoping if anyone could confirm this is a correct approach? __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: