| Summary: | ASTERISK-17732: [patch] With multiple queues & agents, calls with the longest waiting time don't always get handled first | ||||
| Reporter: | laszlovl (lvl) | Labels: | patch | ||
| Date Opened: | 2011-04-21 05:33:27 | Date Closed: | |||
| Priority: | Minor | Regression? | No | ||
| Status: | Open/New | Components: | Applications/app_queue | ||
| Versions: | Frequency of Occurrence | ||||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) app_queue_1.8.diff | |||
| 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 | ||||
| Comments: | By: laszlovl (lvl) 2011-04-21 05:45:39 When we started development on this, there were no other tickets in the bugtracker referencing this issue. By now though, it seems there is another patch with a different approach to the problem: ASTERISK-17570 I'll leave it up to the Asterisk veterans to discuss which one is the better approach. By: silentaccord (silentaccord) 2011-04-21 16:08:04 I will try to test this when I get a chance but I'm curious about the queue groups. What's the purpose of them if you would typically put all of the queues in one group anyway? Does this approach work if an agent is not a member all queues within a group? For example, if Bob is a memeber of queue1 and queue2 but Bill is only a member of queue1, and both queues are part of the same group, will it still work? Thanks By: laszlovl (lvl) 2011-04-26 08:50:51 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 a member of. By: Alex Vishnev (avishnev) 2011-07-27 17:18:15.851-0500 I tried making the setup that is described. I have 10 agents and 6 queues. All agents are dynamic.I login the agent to each queue. I am using asterisk 1.8.5. While monitoring with queuemetrics i still find that callers with shorter durations gets sent to an agent prior to the callers with longer duration. My queue weight is setup to 1 for all queues so there is no prioritization. All of my queues belong to the same group. The strategy for the group is rrmemory. I found that this could be an issue. When the call center become busy and the agent become a constraint, i see that multiple callers are being tried for the same agent, while other agents could be available. What is needed to continue troubleshooting this issue. By: Sylvio Jollenbeck (sjollenbeck) 2011-09-10 19:29:08.200-0500 Hi, Guys Had the same problem with version 1.6.2.13 ~ 20. Anyone able to backport this patch to the 1.6.2.x tree? I need help! Thank you. By: dimitripietro (dimitripietro) 2012-05-25 15:49:19.952-0500 lvl, We are really interessted in getting this features into Asterisk. Anything we could do to get it done ? The FIFO problem with multiple queue is causing us more and more problem. Thx ! By: Curtis Raams (craams) 2013-09-02 07:57:29.897-0500 Could this be integrated to the core Asterisk? By: David Woolley (davidw) 2013-09-02 08:15:11.535-0500 I think I would want a fairly detailed analysis of the performance implications, and the completeness of the solution. (The current code for agents on multiple queues, only works for simple cases and is quite expensive in CPU time.) Also, although the patch still seems to be there, the description of its provenance suggests that it is a derivative of a patch that was never submitted to the bug tracker and therefore for which Digium never received a copyright licence grant. If that is the case, the first version of the patch needs to be properly submitted, by its original authors, before it could be progressed. Otherwise, someone will need to submtit a clean room, or first principles, re-implentation. By: Laszlo Varga (laszlo.varga) 2014-08-07 05:51:14.742-0500 Hi, I have asterisks 1.8.17 and 1.8.23 and it looks like this issue is still active in them. Can you please confirm/infirm this? If still active, is there a patch for 1.8? I found only patches for 1.4 and 1.6. thx Varga Laszlo By: David Brillert (aragon) 2015-01-27 10:42:28.748-0600 This is still an issue in the latest version 11 branch. Are there any plans to review https://issues.asterisk.org/jira/secure/attachment/39624/app_queue_1.8.diff or commit the code or any other patch to any Asterisk branch? By: Matt Jordan (mjordan) 2015-01-27 11:00:51.174-0600 Two points: # First, someone should actually respond to [~davidw]'s comments: {quote} I think I would want a fairly detailed analysis of the performance implications, and the completeness of the solution. (The current code for agents on multiple queues, only works for simple cases and is quite expensive in CPU time.) Also, although the patch still seems to be there, the description of its provenance suggests that it is a derivative of a patch that was never submitted to the bug tracker and therefore for which Digium never received a copyright licence grant. If that is the case, the first version of the patch needs to be properly submitted, by its original authors, before it could be progressed. Otherwise, someone will need to submtit a clean room, or first principles, re-implentation. {quote} That hasn't happened. # If someone wants the patch to be included faster, than they can submit the patch for code review. See [https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process] for more information. That being said: ** You'll be responsible for resolving any findings ** The first finding will be David's comment, which hasn't been addressed By: Sébastien Couture (sysreq) 2016-06-08 10:26:26.359-0500 Any chance the original poster would have ported this patch to Asterisk 11? We'd be willing to do performance testing. By: Nathan Bruning (nathanb) 2023-01-24 07:57:26.582-0600 I have pushed a much simpler approach to fix this here: https://gerrit.asterisk.org/c/asterisk/+/19793 | ||||