Summary:	ASTERISK-10968: [patch] Free agent and waiting callers
Reporter:	Diego (equissoftware)	Labels:
Date Opened:	2007-12-04 06:02:46.000-0600	Date Closed:	2007-12-11 11:41:45.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 11459.patch ( 1) CallTrace.txt ( 2) LogAgents.txt
Description:	I configure my queue with this options. autofill=yes strategy=leastrecent Is correct this behavior? 4 calls come into the queue 2 agents rings, the tirdh agent (free) not ring after one of other two answer a call.
Comments:	By: Mark Michelson (mmichelson) 2007-12-04 14:11:34.000-0600 In general, that is not correct behavior, but it's hard to tell just from what you  have provided if there is actually a bug or not. There are several environmental factors which could be causing this to happen. In order to diagnose this further, you'll need to provide full console output (with verbose and debug set to at least 3). This output will be very helpful in figuring out exactly what went wrong, if anything. Thanks! By: Diego (equissoftware) 2007-12-05 12:10:15.000-0600 In the attached file there is the full console output. I test 3 agents and 3 calls CLI> agent show online 217          available at '93@my-queue' (musiconhold is 'default') 001          available at '91@my-queue' (musiconhold is 'default') 010          available at '92@my-queue' (musiconhold is 'default') 3 agents online The calls are from 492113,456524 and 510049 510049 => Agent/001 is ringing 492113 => Agent/217 is ringing 456524 is waiting and Agent/010 is free without ringing. By: Mark Michelson (mmichelson) 2007-12-05 15:54:52.000-0600 I appreciate the log you have submitted, but you need to increase the debug value so that more debug messages are logged. From the Asterisk CLI, type "core set debug 3" and you'll see more messages being logged. Thanks! By: Diego (equissoftware) 2007-12-06 06:36:32.000-0600 Sorry, I didn´t understand... Now in CallTrace.txt there is the console output with 'core set debug 3' Thank you! By: Mark Michelson (mmichelson) 2007-12-06 16:14:56.000-0600 I think I have figured out what the problem is. I should be able to reproduce the problem here and fix it. When I do, I'll post a patch for you to try. Thank you very much for the call traces! By: Mark Michelson (mmichelson) 2007-12-06 17:53:44.000-0600 I have uploaded 11459.patch. I tested it locally and it seems to fix the problem. Please test and let me know if it helps you. By: Diego (equissoftware) 2007-12-10 08:32:20.000-0600 Great! It work very well. I test with 2 and 3 registered agents and 3 calls. Thanks a lot putnopvut! By: Digium Subversion (svnbot) 2007-12-11 11:39:51.000-0600 Repository: asterisk Revision: 92323 U   branches/1.4/apps/app_queue.c ------------------------------------------------------------------------ r92323 | mmichelson | 2007-12-11 11:39:50 -0600 (Tue, 11 Dec 2007) | 10 lines Fixing autofill to be more accurate. Specifically, if calls ahead of the current caller were ringing members (but not yet bridged) there could be available members and waiting callers who would not get matched up. The member availability checker was correctly determining the number of available members in this scenario, but the queue itself did not parallelly reflect this status on the pending calls. This commit corrects the issue. (closes issue ASTERISK-10968, reported by equissoftware, patched by me) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=92323 By: Digium Subversion (svnbot) 2007-12-11 11:41:45.000-0600 Repository: asterisk Revision: 92324 _U  trunk/ U   trunk/apps/app_queue.c ------------------------------------------------------------------------ r92324 | mmichelson | 2007-12-11 11:41:44 -0600 (Tue, 11 Dec 2007) | 18 lines Merged revisions 92323 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r92323 | mmichelson | 2007-12-11 11:42:25 -0600 (Tue, 11 Dec 2007) | 10 lines Fixing autofill to be more accurate. Specifically, if calls ahead of the current caller were ringing members (but not yet bridged) there could be available members and waiting callers who would not get matched up. The member availability checker was correctly determining the number of available members in this scenario, but the queue itself did not parallelly reflect this status on the pending calls. This commit corrects the issue. (closes issue ASTERISK-10968, reported by equissoftware, patched by me) ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=92324