VoIP Mailing List Archives

[maillisting at gmail.com]

HI all,
I have set up a queue with 2 members (A & B). 1st call is waiting
in the queue and a queue member A is ringing but don't take the call.
Member A keeps ringing. Then 2nd call is also get into the queue but
I found that queue member B doesn't ring. That's mean member B is
available to take call but somehow it can't get a call in the queue.
After that, member A takes the call of the 1st caller and member B gets ring.
Question:
-Why the 1st call will be stick the queue even there are many call behind?
-Is it a bug of the queue or just a setting of the queue to solve the problem?
5000 has 2 calls (max unlimited) in 'rrmemory' strategy (24s
holdtime), W:0, C:1, A:1, SL:100.0% within 120s
Members:
Local/2002 at sipauth (dynamic) (Not in use) has taken no calls yet
Local/2001 at sipauth (dynamic) (Unknown) has taken 1 calls (last
was 76 secs ago)
Callers:
1. SIP/2003-02cf0940 (wait: 0:47, prio: 0)
2. SIP/10.100.0.109-e4096dc0 (wait: 0:15, prio: 0)

[dpobanz at hastingsuti...]

Rilawich Ango Thursday, April 10, 2008 3:28 AM

[maillisting at gmail.com]

Thanks. I have checked that the queue.conf. I keep the default
setting as autofill=yes in my tests. That's mean even autofill=yes,
the 1st caller will still stick the whole queue.
asterisk version : 1.4.18

--queue.conf--
; AutoFill Behavior
; The old/current behavior of the 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. The new behavior, enabled by setting
; autofill=yes 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. This is
; probably more along the lines of how a queue should work and
; in most cases, you will want to enable this behavior. If you
; do not specify or comment out this option, it will default to no
; to keep backward compatibility with the old behavior.
;
autofill = yes
On Thu, Apr 10, 2008 at 8:57 PM, Don Pobanz
<dpobanz at hastingsutilities.com> wrote:

[bweschke at gmail.com]

Rilawich Ango wrote:

[drew at oanda.com]

BJ Weschke wrote:

[maillisting at gmail.com]

Do you mean autofill works in 1.4.x? But it doesn't work even I set it.

On Fri, Apr 11, 2008 at 11:07 AM, BJ Weschke <bweschke at gmail.com> wrote:

[maillisting at gmail.com]

Anyone can update me about the queue sticking by a caller? Is it
solved in version 1.4.x? How?

On Sat, Apr 12, 2008 at 9:42 AM, Rilawich Ango <maillisting at gmail.com> wrote:

[m at orderlysoftware.com]

Two use-cases where autofill=no is desirable:

1) If it's important that you answer your callers in strict order (i.e.
in order to meet estimated wait time commitments etc).

2) If your queue members/agents are local channels (as local channels
are always available, so call attempts will be made regardless of who's
talking).

Kind regards,

Matt.

BJ wrote

[bweschke at gmail.com]

With regard to (1), yes, very good point there and certainly reason
enough to leave it alone. I had completely forgotten about a use case
like that.

With regard to (2), I'm pretty sure there's been work done in the
recent past to make chan_local more state aware so that this might not
be the case any more depending on what version you are using. I might be
wrong there, but I know I've got a patch or two hanging around that did
make this work.

Matt King wrote:

[atis at iq-labs.net]

Hey,

I just found out today that it doesn't work on Asterisk 1.4.19 (at
least for realtime queues) if you have autofill=yes in queues.conf.
However it works if you add it in queue settings for each queue, for
realtime that would be
ALTER TABLE queue_table ADD COLUMN autofill TINYINT(1) UNSIGNED DEFAULT 1;

For following this issue, see http://bugs.digium.com/view.php?id=12445

Regards,
Atis
On Sat, Apr 12, 2008 at 4:42 AM, Rilawich Ango <maillisting at gmail.com> wrote:

[dbc_asterisk at advan.ca]

[maillisting at gmail.com]

Yup, I am using realtime queue. Do you mean the global setting in
queue.conf is useless and you have to set every thing in each queue to
activate the settings? If it is true, does it also apply to other
realtime settings?

On Tue, Apr 15, 2008 at 8:21 PM, Atis Lezdins <atis at iq-labs.net> wrote: