I have the following setup: real time agents with rrmemory strategy and when all agents are in call and a new call come in once an agent is becoming available again the waiting call is not forwarded to the agent. Only if a second call comes than the first call is pushed to the available agent. I had the same problem in Asterisk 1.6.x and now again in 1.8.7.
I don’t think this is a bug but more of a wrong setup.
Asterisk queue scheduling is done on the incoming call threads. They poll every second to see if an agent is available. That can produce some anomalies.
In my case this is a rule. Basically every time in this situation - when all agents are involved in a call and calls waiting in queue, once an agents become available we need a new call to enter in the queue in order to trigger the action.
There is no exception. My setup (queues.conf) with relevant parameters is:
eventmemberstatus=yes
timeoutrestart=yes
memberdelay=0
strategy=rrmemory (or anything except ringall)
Can I fix this somehow? Or if this is a bug, any workaround suggested?
The current workaround I use is to manually dial an extension which dials 2 sec in the respective queue(s) but I would prefer an automatic solution.
I’m currently testing with retry=5 but so far it doesn’t seems to solve the issue.
However is too soon for a conclusion.
I’ll come back asap. In the mean time any other suggestion is highly appreciated
I don’t want to stop it, I just need to have it working correctly. As a work around now I manually dial an extension which place a 2 sec call in the queue where there is a call waiting and available agents. That short call then trigger a “queue refresh” and the waiting call rang at the agents. This happens every time, not randomly.
But I need a permanent fix for this. I’m still suspecting a configuration mistake but to be honest I’m stuck.
What I said is that polls every second. What you asked is how to make it do that. My reply was that you don’t need to do anything to make it do that, and you cannot stop it from doing that. That is what makes your symptom strange.
Unfortunately you have a symptom that should be obvious to every queue user, but no-one else sees. All I can suggest is creating a very simple model, using 1.8.7.x and trying to reproduce the problem on that. If you can reproduce it on a simple model, try and understand what is unusual about that model, and submit a bug report, with maximum debugging turned on for app_queue.
I’m not sure how much debugging is available in app_queue.c, but turning it on your actual system may give a clue as to the problem. I doubt many here would want to trawl through a lot of logs, though.
Funnies with queues tend to happen if you have multiple queues sharing multiple agents, but none should result in entries getting stuck until another entry is added.
So far I didn’t had the time to go deep and try to debug this problem but I have found a better workaround which maybe will help digium developers to understand where the issue is.
If I type “queue show q-name” in CLI that push the waiting call to the agents. It seems to work all the time.
I have created a bash script which runs “queue show” for all queues and so far I’m quite happy with this solution.
I am having exactly this bad queue… I really did not observe if running the command queue show queuename push the waiting calls on queue to the agents. What I observe that problem is related to the login/logoff of the agent. When this problem occurs, the agents are getting out and in again in the queue. Maybe this process executes queue commands in the asterisk.
My asterisk is logging and verbosing .
Here is what I found:
[Mar 15 10:47:57] DEBUG[25647] app_queue.c: There is 1 available member.
[Mar 15 10:47:57] DEBUG[25647] app_queue.c: It’s not our turn (SIP/0227-00001225).
[Mar 15 10:47:57] DEBUG[25647] app_queue.c: SIP/0233 is available.
When this problem occurs… another bad issue happens too… the ring stategy does not respect the ring timeout setting. The phone agents rings one time or two… and stops… in the log… I see that the agent didnt answer in 2000 ms… ??? should be 30000 ms.
I am using Asterisk 1.6.2.6 and I tried to purchase commercial support from Digium… but… I cant. They just sell commercial support to Asterisk LTS 1.8, 10 or 11. I really dont feel that I need to move to 1.8 … reading this topic… I saw that go to 1.8 wont help my problem.