[Home]

Summary:ASTERISK-10968: [patch] Free agent and waiting callers
Reporter:Diego (equissoftware)Labels:
Date Opened:2007-12-04 06:02:46.000-0600Date Closed:2007-12-11 11:41:45.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents: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