app_queue - ringing extension blocks other calls

hi all,

i have encountered a not so good behaviour while using the asterisk queue implementation. Normally when there are calls waiting in the queue - and agents are free - then the calls will get connected to the free agent(s). What i have encountered is - that when asterisk is trying to transfer a call to a agent (agent is than in ringing state) - and the agent does not answer - then the queue application is blocked in the mean time. So it wont try to deliver the other calls to the other free agents - because of one agent who is not answering the phone.

This is really bad behaviour…

Does have anyone else already figured out the same problem ?

Any solution for this ?

Some more info:
Asterisk 1.2.4
Queue in rrmemory strategy
7 seconds agent timeout

regards,
Wolfgang

What ring method are you using ? There are/were problems with leastrecent not working.

i am using rrmemory

in 1.4, there will be a feature called autofill, which would probably do what you want - if you have three agents and four callers, the queue would take the first three calls and distribute one to each agent, so that you have three callers being connected to three agents, all at once. this may or may not apply to the ringall strategy only - i don’t know as i haven’t played with the feature that much.

in the meantime, have you considered changing your strategy to ringall? we use it (in conjuction with the ring-inuse patch) and our managers love it…it means that the first call in queue rings every available agent - whoever picks up first gets the call. obviously, we’re only sending one call at a time to the agent block, but it’s much faster than rrmemory.

the other thing you could set is autopause=yes - it will automatically pause any member that is not answering, so that future calls will not be delivered to them…

just a few thoughts - we’re also on 1.2.4 and use queues extensively (several thousand calls per day across 8 servers) so i know some of the frustrations you’re going through.

thanks for the hints…

upgrading to 1.4 and playing with the new features is not possible (production system…)
ringall strategy - i have also thought about this - i will discuss this with the managers here…

autopause is only avaiable for Queue Agents or i am wrong ?

Our Queue Agents are Dynamic Agents (an other system adds the agents to the queue by an asterisk manager interface call).

I am thinking (and trying) about an other solution - about not using and Agent or a Channel directly as Queue member - instead of this adding Loca/xxx@callQueueAgent Agents which then in turn are calling the real agent. (i thought that when i answer the call with a local channel - then the queue considers the call to be placed to an agent quite right). But this method does not seem to work well (you are loosing information about the state of your current queue members - because you can’t tell if the local channel is ringing - is in use - aso.). Has someone get it working with Local Channels ?

I also did already thought about writing my own queue implementation as extension logic - should be possible… What do you think ?

You are correct in regards to the local channel issue - again, in 1.4, there will be enhancements to this.

We also use addqueuemember to add dynamic agents, but we do not use the autopause feature, so I can’t tell you if it works or not, but from the documentation I have found, it appears that it would.