[Home]

Summary:ASTERISK-01045: Queue / Agent timeout logic issues
Reporter:billh (billh)Labels:
Date Opened:2004-02-17 16:45:50.000-0600Date Closed:2011-06-07 14:05:12
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:splat*CLI> show version
Asterisk CVS-01/30/04-13:56:04 built by root@splat.ccis.net on a i686 running Linux ----- Fedora Core1
==============================
Hi,

I suspect that this is either a bug or perhaps a bizarre feature :)

What seems to be broken is one or all of:

The "n" option in Queue()
agents.conf: autologoff=x
queues.conf: timeout=y

First the conf files:
extensions.conf
[supportq]
exten => 401,1,  Queue(support1)

agents.conf
[agents]
autologoff=15
ackcall=no
;wrapuptime=5000
musiconhold => default

queues.conf
general]
[support1]
music = default
strategy = leastrecent
;context = leavemessage
timeout = 300
retry = 2
maxlen = 0

Firstly, if one agent is logged in to the Q, and a call comes into the Q and he doesn't pick up. His phone will ring indefinitely and "autologoff=15" is ignored as the agent is never logged out. So the caller just stays in the Q indefinitely while the agent's phone rings indefinitely cycling through timeout=x and retry=x.

Secondly, when the first call comes into the Q for this agent, his phone rings as expected, and he does picks up the call. When the 2nd caller comes into the Q they will be in the Q indefinitely until the agent is free and never timesout, well CLI shows it timing out, but it just waits for the value in "retry" and then tries ringing the agents phone again, and again... indefinitely.

I thought that adding the "n" option to "Queue(support1|n)" would do the trick, it does in one sense because when the timeout is reached, the caller is ejected from the Q and sent to the next priority in the context *BUT* if there is only one agent logged in, as is in this example and he/she is busy on a call, the 2nd caller is timedout immediately upon being sent to the Q, hence not being "queued" at all.

What started this was that my desired result is that even though one agent is dynamically logged into the queue and is on a call, I would like the 2nd caller to stay in the queue for 5 minutes and then timeout to the next priority if the agent is still busy and can't get to the call. This way I can transfer the call offsite where someone is available. Same holds true if multiple agents are logged in and are all busy.

Some observations:
I have tried the "n" option with "queue" (if I don't the 2nd caller will stay in the queue indefinitely) eg:

exten => 401,1,Queue(support1|n)

The problem with using "n" is that with one agent logged into the queue and he is "busy" on a call, when the 2nd call is placed in the queue it immediately timesout and goes to the next priority in the context even if timeout=300 is set in queue.conf.

-end-
Comments:By: Mark Spencer (markster) 2004-02-27 02:20:14.000-0600

This is not actually a bug, but simply the lack of any sort of timeout of the nature you're describing.  This would have to be added as a feature.
By: purplehat (purplehat) 2004-03-04 16:52:42.000-0600

I'd like to add a "me too" for requesting per-queue maximum hold times. I think this is a critical feature for many ACD setups.

If I come up with a patch for this is it too late to make it into 1.0? It should be fairly unintrusive, and the default setting would be to make the hold time unlimited, so it shouldn't break any existing dialing plans.
By: Brian West (bkw918) 2004-04-17 23:37:18

cvs checkout ICD (its not a digium creation but its there to play with)

bkw