[asterisk-users] Short rings for extensions when part of the Queue
Chad Wallace
cwallace at lodgingcompany.com
Fri Nov 5 20:51:35 CDT 2010
On Fri, 5 Nov 2010 01:18:30 -0400
Bruce B <bruceb444 at gmail.com> wrote:
> > What I noticed is that when someone misses a call on the queue, it
> > switches over to the next person, but almost immediately (after a
> > short ring) it breaks off and cancels that call because of a
> > timeout. I think it's a matter of timing between the different
> > timeouts you can set in queues.conf.
>
> You are absolutely right on this one. I had setup the Queue time out
> for agent set to 15 seconds and retry to 2 seconds. So, I think
> during those two seconds Asterisk for some crazy reason hits another
> extension and then comes back to the same extension to ring again.
> So, I have setup the agents to ring for ever for this call center
> since their agents always have to present or logout if not present. I
> will see the behavior tomorrow as they test it.
Well, I just took a good look at my setup, which is based on the
instructions in doc/queues-with-callback-members.txt and uses Local
channels as queue members.
What's happening is that the Dial in the Local channel has the same
timeout as the queue itself: 15 seconds. So when the Local channel
returns NOANSWER after 15 seconds, it causes the queue to ring the next
member, at which point it notices the queue timeout of 15 seconds has
elapsed, and cancels the new call, cutting off the first ring.
So what I've done now is set timeout = 600 in queues.conf. I don't
know if there's a setting for unlimited (maybe 0?) but 600 is more than
the timeout in the Queue() call, at which point the caller goes to
another queue. So it's effectively unlimited.
I have a feeling that setting timeoutrestart = yes might fix it, too,
but I'm not sure, since it says it's for Busy and Congestion, and this
case involves NOANSWER.
But since the timeout in the Local channel does the same thing as the
timeout in queues.conf, it doesn't make sense to have both. So I think
taking the queues.conf timeout out of the equation is the right solution
here.
Well, thanks for bringing this up... Who knows how long I might have
let this one go, when the solution ended up being so simple!
More information about the asterisk-users
mailing list