Summary:	ASTERISK-08902: Extend RRMEMORY strategy to use penalty (1.4.0 and 1.2.15)
Reporter:	x893 (x893)	Labels:
Date Opened:	2007-02-27 23:49:21.000-0600	Date Closed:	2011-06-07 14:03:11
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) app_queue.1.2.15.patch ( 1) app_queue.1.2.15.txt ( 2) app_queue.1.4.0.patch ( 3) app_queue.1.4.0.txt ( 4) app_queue.trunk.55220.patch
Description:	As for now if RRMEMORY startegy is chosen Queue calls only members with lowest penalty. It will never call member if any member with lower penalty is available, even if it doesn't answer. For example, we have 4 members in queue: Member 1 with Penalty 0 Member 2 with Penalty 0 and Member 3 with Penalty 1 Member 4 with Penalty 1 Member 3 & 4 will never be called if Member 1 and Member 2 don't answer the phone. Queue will try to call Member 1 and Member 2 forever. I added new strategy called XRRMEMORY which can be chosen in queue.conf. Using this strategy Queue will try all members with penalty=0 then it will try members with penalty=1 and so on. Moreover it remembers the members it called last time for each peanlty and next time if it reaches this penalty it will dial next member. This strategy support penalty from 0 to 9 (you can change #define MAX_QUEUE_PENALTY  9 constant in app_queue.c)
Comments:	By: Serge Vecher (serge-v) 2007-02-28 08:15:02.000-0600 1. Could you please get a disclaimer on file (see bottom of http://bugs.digium.com/main_page.php) and confirm with a note here when done? 2. Since this is a new feature, please upload your change as a patch against trunk. See  http://www.asterisk.org/developers/Patch_Howto By: Serge Vecher (serge-v) 2007-02-28 10:22:39.000-0600 x893, please upload the patch against the trunk, not 1.2.15 or 1.4.0. Also, confirm your disclaimer status By: Jason Parker (jparker) 2007-02-28 12:57:19.000-0600 This could easily be done with very basic dialplan logic... By: x893 (x893) 2007-03-01 00:41:03.000-0600 Really this strategy can change RRMEMORY strategy. By: Andrey Solovyev (corruptor) 2007-03-01 04:48:51.000-0600 Sure, this could be done using several queues as I understand but i think this behaviour of the queue is quite popular. For example we want simple circular call distribution and we want that agent1 is always called first then agent2 is called and so on (same as rrmemory but actually without memory) and we 20 such agents. Should we create 20 queues? That's quite inconvinient. For example I set variable QUEUE_MAX_PENALTY to 5 (by default it's 0,). Is it normal that queue dials only members with penalty=0 if dialstatus of at least one of them is NOANSWER? By: Olle Johansson (oej) 2007-05-15 11:34:26 Ok, we do need a disclaimer on this code, otherwise we can't consider it for inclusion in Asterisk. As soon as you have confirmed that you have sent the disclaimer, someone will look at this. If you have questions, please find someone in #asterisk-dev or #asterisk-bugs on IRC freenode. Instructions and templates for the disclaimer can be found in the bug guidelines on the bug trackers home page. Thanks for contributing to Asterisk! By: chrishardie (chrishardie) 2007-05-28 17:57:02 I realize this is still awaiting a disclaimer, but wanted to add that I applied the patch against the 1.4.2 codeline and am now successfully using it in production.  I searched far and wide for something to facilitate this queue strategy, and find this patch quite useful.  I hope it makes its way into the next release! By: Jason Parker (jparker) 2007-05-29 13:40:15 No, you would only need 1 queue.  Please see doc/queues-with-callback-members.txt for examples of how this is done at Digium.  It's really very trivial to do, and doesn't require more needless complexity in app_queue. By: Jason Parker (jparker) 2007-08-22 16:34:46 Closing. Please reopen once you've submitted a license agreement via mantis, and reupload the patches.