[asterisk-bugs] [Asterisk 0019161]: [patch] With multiple queues & agents, calls with the longest waiting time don't always get handled first

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=19161 
====================================================================== 
Reported By:                lvl
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   19161
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           SVN 
JIRA:                       SWP-3379 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): 1.8 
SVN Revision (number only!): 314594 
Request Review:              
====================================================================== 
Date Submitted:             2011-04-21 05:33 CDT
Last Modified:              2011-04-26 08:50 CDT
====================================================================== 
Summary:                    [patch] With multiple queues & agents, calls with
the longest waiting time don't always get handled first
Description: 
If you have an Asterisk setup with multiple queues, and agents that are
logged into more than one queue, Asterisk will not always handle the
longest waiting call first.

For example, if agent "Bob" is a member of "queue1" and "queue2", queue1
has a call waiting for 5 minutes, and queue2 has a call waiting for 10
minutes, Asterisk will connect Bob with one of those callers/queues at
random, rather than always processing the 10-minute-waiting call first.

This is a long standing bug/issue in Asterisk that affects multiple users,
you can find mentions of this issue on for example
http://www.fonality.com/trixbox/forums/trixbox-forums/trixbox-ce-project-bounties/bounty-queue-priority,
http://www.voip-info.org/wiki/index.php?page_id=448&tk=19bdb4d0e35e7b018f8c&comments_page=1
or
http://lists.digium.com/pipermail/asterisk-users/2010-January/243598.html

To address this, we took the patch discussed at
http://lists.digium.com/pipermail/asterisk-users/2010-January/243598.html
and rewrote it for the current Asterisk trunk. A patched Asterisk is now
running on our development servers - the problem is fixed and no additional
issues have arisen.

This patch introduces the concept of "queue groups". Your queues.conf
should no longer specify a strategy, but instead a group:

[queue1]
group=all
...

[queue2]
group=all
...

A new file, queuegroups.conf, should list these groups and specify a
strategy for them (all queues that you want to group together, typically
all of your queues, should be set to the same queue group):

[all]
strategy=ringall
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0018986 [patch] queue does not handle longest w...
====================================================================== 

---------------------------------------------------------------------- 
 (0134124) lvl (reporter) - 2011-04-26 08:50
 https://issues.asterisk.org/view.php?id=19161#c134124 
---------------------------------------------------------------------- 
A situation where you wouldn't put all of your queues in the same group is
when you don't want the same strategy for all of your queues.

I've tested a situation similar to what you're describing (two queues, in
the same group, and an agent who is only a a member of one of the queues),
and it doesn't produce any issues: the agent will only receive calls from
the one queue that he's logged in to. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-04-26 08:50 lvl            Note Added: 0134124                          
======================================================================