Summary:	ASTERISK-00302: leastrecent and fewestcalls methods keep on trying on one member channel, even that it is not answering,
Reporter:	asker (asker)	Labels:
Date Opened:	2003-09-24 12:44:37	Date Closed:	2011-06-07 14:10:09
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	leastrecent and fewestcalls methods keep on trying on one member channel, even that it is not answering, giving too much waiting to a user. When the channels times out, it waitsfor the retry and then goes to the same channel, instead of trying another member.
Comments:	By: Brian West (bkw918) 2003-09-24 13:07:58 http://bugs.digium.com/bug_view_page.php?bug_id=0000045 Round robin was fixed in that bug.. but the leastrecent and fewest calls was still broken at the close of that ticket.  Because mark wanted input on how that should be done and we never worked on it beyond that. By: John Todd (jtodd) 2003-09-30 23:01:46 Brian, you and several others were working feverishinly on the call queue stuff - can you bring up that discusion again with the interested parties and come to a resolution on advising Mark how to handle leastrecent/fewestcalls so this can be fixed? By: Brian West (bkw918) 2003-09-30 23:06:20 Personally I think fewestcalls and leastrecent should have pref for the fewest/leastrecent first then move along to the next agent as in roundrobin.  That sounds more logical.  Because a lazy/away agent that forgot to logout could hold your entire call queue up. By: Brian West (bkw918) 2003-12-14 12:38:37.000-0600 These function as designed.  So should we wait for the new agents and queues framework? By: Brian West (bkw918) 2004-01-07 00:07:08.000-0600 These work as designed.  I think the new agent and queues framework will allow more flexability.