[SR-Users] Re: No access to variables within timer route

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?