Summary:	ASTERISK-05429: [patch][post-1.2] Make app_queue behave a little better
Reporter:	twisted (twisted)	Labels:
Date Opened:	2005-11-02 11:05:36.000-0600	Date Closed:	2006-05-03 15:19:15
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) app-queue-patch.diff ( 1) queue-stuff-v3.1.txt
Description:	What I have done is the following: 1) if autofill=yes in queues.conf in the queue in question, rather than waiting for the first call to be answered, we will respect our strategy and attempt to fill up the available queue members, regardless if our call was answered or not.  Basically this means if you have 5 queue members, and 6 callers around the same time, we will send 5 unique calls to 5 members, and the 6th call will remain in hold until a member frees up.   This does not break the ordering in the queue, so if an agent doesn't answer the phone, the call in slot 6 will be bumped to slot 2 assuming all 4 of the other calls were answered, and then the one that wasn't answered in slot 4 will become slot 1.   2)  if autopause=yes in queues.conf in the queue in question, if a member doesn't answer a call, they will become 'paused'.  I took the paused route rather than the removal route, simply because it's easier to see (for management purposes) who is paused from both the manager and the 'show queues' command.  Also, this allows the agent to "unpause" themselves with an extension that calls UnPauseQueueMember.   ****** ADDITIONAL INFORMATION ****** There is one small formatting change at the top.  I decided to remove the other formatting changes as it makes the code harder to glance at. Newest verison is v3.1, as I forgot to re-add the autopause config option back.
Comments:	By: jalsot (jalsot) 2005-11-03 04:44:23.000-0600 This is a great feature! I have tested and it works fine. Why is the queue not handled in this way by default? I'm just curious ;) Good job! Thanks! By: Kevin P. Fleming (kpfleming) 2005-11-07 21:07:29.000-0600 This is clearly a new feature; it's been marked as post 1.2 material. I also would prefer that we find a better name than 'fakefifo' :-) By: twisted (twisted) 2005-11-12 00:45:11.000-0600 queue-stuff-v3.txt is the new and improved version. see updated description for options change. By: twisted (twisted) 2005-12-14 10:17:29.000-0600 kpfleming, if you don't see any reason why not, I'd like to go ahead and merge this into trunk.  I'll update the configs accordingly as well, but I just want to OK it first. By: Jason Parker (jparker) 2006-01-02 11:56:20.000-0600 I like this patch...  Will try to test it tomorrow. If all goes well, I'd like to see this in trunk. By: BJ Weschke (bweschke) 2006-01-03 07:04:46.000-0600 I've got it running in production at a client. It's working real well. +1 to add to /trunk By: Jason Parker (jparker) 2006-01-04 15:00:18.000-0600 The autopause part works great.  I don't quite understand the autofill part though.  How is this different from normal functionality?  Does it normally only send one call to one queue member at a given time, then wait until there is an answer or not? By: twisted (twisted) 2006-01-05 08:59:21.000-0600 Yes. By: Jason Parker (jparker) 2006-01-06 12:18:35.000-0600 okay, I tested the autofill part. I have two agents logged in, and two calls in the queue.  One agent is on a call, so no calls will be sent to him.  The second agent is iaxcomm with two line appearances.  I'm seeing cases where iaxcomm will have two incoming calls from the same queue at a time.  Is this an issue? By: twisted (twisted) 2006-01-06 12:47:52.000-0600 basically what has happened there is that you've noticed a bug in app_queue that doesn't make itself as apparent without my patch.   The problem is that if you have a phone with more than 1 line appearance for the same device, the device will accept another call.  This is a problem with app_queue itself, and not my patch, as this same issue can be created (albeit not exactly the same time) witout it.  Set autofill to no, and the same thing will happen (a second call from the queue will come into that second line appearance) By: Jason Parker (jparker) 2006-01-07 13:40:03.000-0600 You're right.  If I call from iaxcomm (while the same iax account is in the queue) without this patch, it rings iaxcomm on the second appearance. I think since that's a seperate issue, this can go in safely. Now I need to hack up my dialplan macros to unpause members also. :p By: Matt O'Gorman (mogorman) 2006-01-13 10:40:28.000-0600 Committed revision 8060. into trunk along with config sample By: BJ Weschke (bweschke) 2006-02-13 18:16:14.000-0600 sorry to reopen this one, but it would appear that the current functionality of autofill=yes is causing some issues with app_queue. While the ordering of the queue isn't getting disrupted, because everyone is getting bumped into that second for loop with autofill=yes, we're getting calls that are getting taken out of order in the queue because their retry timeout on the 2nd loop is coming up before the first call in queue. I'll be looking at seeing if there is a "quick fix" to address this, but with a client's queue today where caller #1 in queue was on hold for 80 mins plus, and callers with 30 second wait times getting taken before that caller, I had to disable autofill=yes today there. By: James W. Brinkerhoff (jwb) 2006-04-18 19:21:11 Has there been any update regarding the problems bweschke mentioned? By: wes (whoiswes) 2006-04-19 09:29:46 FYI, for north's issue, it can be fixed through applying the patch in bug 6315.  the code was supposedly submitted to trunk a while back, but as of 1.2.7, it's not there yet. the patch is easy enough to apply manually, and it works great - agents that are on a queue call will NOT receive another one until finished, but they can receive a direct-dial call (if they have a second line, that is). here's another vote for this one to be included in the source - this is a GREAT feature!!! By: BJ Weschke (bweschke) 2006-04-28 07:59:37 Guys - try this patch too address the functionality issues that came about with the introduction of autofill. The intent here is to let only the number of callers out of the "waiting pen" for which there are available agents to answer. This makes sure that callers still get answered in order. The patch attached should apply cleanly against /trunk. By: BJ Weschke (bweschke) 2006-05-03 15:19:13 Changes implemented in /trunk as discussed in the 5/2 dev conf call. Closing now.