One thing you might want to consider is what distribution strategy to use for
the queues. Note that Asterisk Queues use FIFO methodology to handle calls and
distribute them to the agents.
Say you have one queue and round robin strategy. When 5 calls come in and only 2
agents are available, the first caller in the queue will wait until one of the
agents answers (or a timeout or any other exit strategy you may have defined).
This will cause all other 4 callers to wait until that first caller gets
handled. This is the behavior anyone expects from Asterisk's queues.
However, when you have 10 queues and 5 agents and all 5 agents are members of
all 10 queues, the way Asterisk handles it is a bit
surprising/shocking/unexpected to some of us (me included). When 20 calls come
in (say 2 for each queue), because all agents are members of all queues,
Asterisk sees them as one shared resource pool of agents and therefore, treats
all 20 calls as one large FIFO queue. You still get all the benefit of
individual queues. However, the second caller (regardless of queue) will have to
wait until the first caller (regardless of queue) is handled.
When you multiply this times 200 queues, the behavior could be VERY surprising.
This has been my experience. Basically, I have not seen Asterisk distribute
calls from multiple queues to shared agents in parallel.
Good luck and please do post your experiences as well.
- Daniel
On Wed, January 3, 2007 6:07 pm, Richard Lyman <pchammer@dynx.net> said:
> lenz wrote:
>> Hello list,
>> one of our clients is going to be deploying a system with over 200
>> differently composed queues and 100 agents. We are going to do a full
>> test of the viability of this solution before deployment, but I was
>> wondering if anyone has experience of such a setup and if there are
>> any obvious problems or no-nos.
>> Any suggestion welcomed,
> one of our sites likes to micro manage things to the point of 38 queues.
>
> the thing you will find is that if your agents are members of various
> queues....
>
> each member instance of each queue will get QueueMemberStatus events.
> (i've commented mine out because of flooding that occurs of the manager
> interface)
>
> deadlocks would be the thing to watch for.
>
> just food for thought.
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>