diff options
author | bweschke <bweschke@f38db490-d61c-443f-a65b-d21fe96a405b> | 2006-05-03 20:01:30 +0000 |
---|---|---|
committer | bweschke <bweschke@f38db490-d61c-443f-a65b-d21fe96a405b> | 2006-05-03 20:01:30 +0000 |
commit | 165047114fbc2f8e592c1623ecf98dcc01ddd9ea (patch) | |
tree | 511130a4898434adefb6054f2d2fb0cdce88a2b2 /UPGRADE.txt | |
parent | b8de621a5e1207b137ccdc10f3f459b7aba0205a (diff) |
Fix autofill behavior in app_queue and document it's functionality in queues.conf.sample and UPGRADE.txt
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@24543 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'UPGRADE.txt')
-rw-r--r-- | UPGRADE.txt | 20 |
1 files changed, 20 insertions, 0 deletions
diff --git a/UPGRADE.txt b/UPGRADE.txt index e6c52bff0..b6539d60e 100644 --- a/UPGRADE.txt +++ b/UPGRADE.txt @@ -73,6 +73,26 @@ Applications: queue member channel that is taking the call. This is useful when trying to link recording filenames back to a particular call from the queue. +* The old/current behavior of app_queue has a serial type behavior + in that the queue will make all waiting callers wait in the queue + even if there is more than one available member ready to take + calls until the head caller is connected with the member they + were trying to get to. The next waiting caller in line then + becomes the head caller, and they are then connected with the + next available member and all available members and waiting callers + waits while this happens. This cycle continues until there are + no more available members or waiting callers, whichever comes first. + The new behavior, enabled by setting autofill=yes in queues.conf + either at the [general] level to default for all queues or + to set on a per-queue level, makes sure that when the waiting + callers are connecting with available members in a parallel fashion + until there are no more available members or no more waiting callers, + whichever comes first. This is probably more along the lines of how + one would expect a queue should work and in most cases, you will want + to enable this new behavior. If you do not specify or comment out this + option, it will default to "no" to keep backward compatability with the old + behavior. + Manager: * After executing the 'status' manager action, the "Status" manager events |