Short rings for extensions when part of the Queue

Home » Asterisk Users » Short rings for extensions when part of the Queue
Asterisk Users 8 Comments

Hi Everyone,

We have three different Queues set to “leastrecent” strategy and from time
to time I hear someone complain that they receive short rings (partial ring
cycle) and since it’s not their turn even if they pickup the phone the call
is not given to them since the Queue is actually hitting someone else at the
same time.

Is this short ring an indication of some sort for “leastrecent” strategy.
Like maybe you are next in turn or something?

It’s annoying and odd that I don’t see a pattern to it. If it’s a feature
please let me know.

Using Asterisk 1.4x

Thanks

8 thoughts on - Short rings for extensions when part of the Queue

  • On Thu, 4 Nov 2010 20:12:54 -0400
    Bruce B wrote:

    We have the same issue, and I think I’ve figured out what’s causing it,
    by watching the SIP debug output.

    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. I haven’t had time to tweak it yet, so that’s all
    I can tell you. I don’t know how hard it would be to get the timeouts
    to jive perfectly, but I’m sure it can be done.

    Mind you, this is based on only one observation, so I may be
    wrong… It’s only a minor annoyance, and I have bigger fish to fry
    right now. Speaking of which, one of them is almost burnt, so I have
    to go. 😉

    I’d be interested to hear your findings…

  • Chad,

    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.

    My issue might be solved but for those call centers where you want the Queue
    to move onto the next agent or if you don’t want to ring for ever and take a
    Retry break then it will still remain an issue. I will report back if
    setting to ring Unlimited doesn’t work.

    Warren,
    The CLI shows the regular stuff. Nothing out of the ordinary but that it
    move on to the next agent because the first agent has timed-out for two
    seconds.

    Regards,
    Bruce

  • Have you considered setting the queue timeout to 14 or 16 seconds and
    retry to 2 seconds? This way the timeout and the retry should line up
    better.

  • Sorry, I am not following. If an extension rings for 15 or 16 seconds and
    then waits for 2 or three seconds what difference does the being divisible
    make?

    Is there something internal to Asterisk that makes the Retry time dependent
    on Time Out (also known as Ring Time)?

    P.S. I think the 15 seconds is just three rings complete.

    Thanks,
    Bruce

  • On Fri, 5 Nov 2010 01:18:30 -0400
    Bruce B wrote:

    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!