Kyriakos wrote: > It would be nice to add an option of choosing to answer the call with the > longest waiting time, or answer randomly, or round robin, etc... > > > Agreed, but, understand that each queue defined in app_queue is separate. The way the weights work is only by instructing a thread to go into another queue's data space (while holding a mutex lock to make sure multiple threads aren't walking on the same space) and make sure there aren't calls waiting where that queue has a higher weight than the one currently processing before it decides whether or not it can serve up calls to an available member. There is not one large, consolidated, pool of calls waiting for consideration when you are dealing with multiple queues in the current design of app_queue. As a result, true skills based routing with the existing app_queue is, difficult, at best.
The queue application does a fairly good job for what most people need for it to do, but when you start getting into these more complex call/queue routing scenarios, you're defining a scope of requirements that the original app_queue just wasn't designed for. Features like queue weight were/are band aids to try to get you closer to the end run goal, but that band aid and others like it has come with its own costs as well (mutex deadlocks,etc) that many people here have complained about in the past. -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
