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@lists.kamailio.org> Sent: Thursday, November 30, 2023 8:30 AM To: sr-users@lists.kamailio.org Cc: dr...@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-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
