[Home]

Summary:ASTERISK-06269: [patch] queue timeout unexpected behaviour
Reporter:Nick Barnes (bcnit)Labels:
Date Opened:2006-02-07 09:54:15.000-0600Date Closed:2006-05-19 21:53:00
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) app_queue.c.patch-trunk
Description:If a queue is defined as:

-------------------8<---------------------
[queuename]
.
.
timeout=60
.
.
-------------------8<---------------------

and called with 'Queue(queuename||||30)' or 'Queue(queuename|n|||30)', the call times out after 60 seconds rather than the expected 30. If called with 'Queue(queuename||||90)', then the call times out after 120 seconds and not the expected 90.

The documentation of the Queue command says:

"The timeout will cause the queue to fail out after a specified number of seconds, checked between each queues.conf 'timeout' and 'retry' cycle."

Which is certainly what I am experiencing, but it doesn't make any sense - Surely the value of timeout passed to the Queue command should override the value of timeout in queues.conf, otherwise why bother having a timeout parameter to the Queue command? It also means that if you want to have different timeouts to the same group of people, you have to use multiple queues rather than just calling the one queue with a different timeout value.



****** ADDITIONAL INFORMATION ******

queues.conf
-------------------8<---------------------
[sales]
musiconhold = default
strategy = ringall
servicelevel = 60
timeout = 20
retry = 0
weight=0
wrapuptime=0
maxlen = 0
joinempty = yes
leavewhenempty = no
eventwhencalled = no
reportholdtime = no
memberdelay = 0
timeoutrestart = no
member => SIP/399
-------------------8<---------------------


extensions.conf
-------------------8<---------------------
.
.
exten => sales,n(answered),Set(CALLERID(name)=Sales)
exten => sales,n,Queue(sales|n|||10)
exten => sales,n,Queue(all||||15)
exten => sales,n,Playback(custom/pre-vm)
.
.
-------------------8<---------------------


Output
-------------------8<---------------------
   -- Executing Set("SIP/399-095f", "CALLERID(name)=Sales") in new stack
   -- Executing Queue("SIP/399-095f", "sales|n|||10") in new stack
   -- Started music on hold, class 'default', on channel 'SIP/399-095f'
   -- Called SIP/399
   -- SIP/399-9878 is ringing
   -- SIP/399-9878 is ringing
   -- SIP/399-9878 is ringing
   -- SIP/399-9878 is ringing
   -- SIP/399-9878 is ringing
   -- SIP/399-9878 is ringing
   -- SIP/399-9878 is ringing
   -- Nobody picked up in 20000 ms
   -- Stopped music on hold on SIP/399-095f
   -- Executing Queue("SIP/399-095f", "all||||15") in new stack
   -- Started music on hold, class 'default', on channel 'SIP/399-095f'
   -- Called SIP/399
   -- SIP/399-ffc2 is ringing
   -- SIP/399-ffc2 is ringing
   -- SIP/399-ffc2 is ringing
   -- SIP/399-ffc2 is ringing
   -- SIP/399-ffc2 is ringing
   -- SIP/399-ffc2 is ringing
   -- SIP/399-ffc2 is ringing
   -- Nobody picked up in 20000 ms
   -- Stopped music on hold on SIP/399-095f
   -- Executing Playback("SIP/399-095f", "custom/pre-vm") in new stack
-------------------8<---------------------
Comments:By: Fernando Romo (el_pop) 2006-02-09 10:16:55.000-0600

Is more critical than "feature", in fact the queue aplication with a full agent calls, start to dial directly to the agent extensions and not follow the dial plan script.
By: Peng Yong (ppyy) 2006-03-10 23:08:19.000-0600

it's not a bug.  pls refer to the wiki:

http://www.voip-info.org/wiki/index.php?page=Asterisk+cmd+Queue

'timeout' sets the time in seconds that a call will wait in the queue before it is routed to the next priority in the dialplan. It defaults to 300 seconds (5 minutes). NOTE: This doesn't do what you think it should do (in 1.2.4 anyway). Once a call is inside a queue, it is only checked to see if it is timed out every so often (depending on the value of 'timeout=' for that queue in queues.conf). This means that if queues.conf says 'timeout=10' and you call the queue with 'Queue(queuename,,,,5)', it will be ten seconds before the call times out. If you call the Queue with 'Queue(queuename,,,,11)', it'll be 20 seconds. I.E. the value of 'timeout' supplied to the command DOES NOT override the value of 'timeout=' in queues.conf. Don't think about changing the value of 'timeout=' in queues.conf to, say, 1 or the calls will get offered to the members for only one second at a time.
By: Tilghman Lesher (tilghman) 2006-03-10 23:30:55.000-0600

I agree.  While the documentation may not be as clear as we'd like it to be, it nevertheless is working exactly the way it should.
By: Nick Barnes (bcnit) 2006-03-11 06:24:00.000-0600

The reason it says this on the Wiki is because I WROTE THAT ENTRY. You can't close the bug just because it agrees with what is on the Wiki when what is on the Wiki is there to warn people about the action and not to document correct working behaviour.

If you have a look at the history of that page, you will see that I added that text on the very same day that I posted this bug.

I still do not expect that this is reasonable behaviour and that this is a bug. If a timeout value is passed to the Queue() application, this SHOULD override the value of timeout in queues.conf. If it doesn't do this, then what on earth is the point of being able to send the value? Acting in the way I suggest means that less queues have to be created and the application works in a logical way.

Please do not close this again just because I've documented the bug elsewhere - have a think about what the application does and whether it's sensible or not. If there is a (good?) reason for it being the way it is then that's fine, but I've discussed this with a few people and we can't think of any.

Thank you.
By: Tilghman Lesher (tilghman) 2006-03-11 09:03:36.000-0600

The problem is that we never want to quit waiting while we're ringing an agent.  What we're talking about are two different timeouts, not one which is an override of the other.  The timeout in queues.conf is an AGENT timeout, while the timeout in the application is a CALLER timeout.  The caller timeout only makes sense to trigger while we're not waiting on an agent to answer, because the agent answering is exactly the type of event that we want to happen, even at the expense of the caller waiting a little bit longer.  After all, a queue is primarily meant to be answered.

I don't really understand why you have the timeout in queues.conf set so high.  The default is 15 -- that is, if an agent doesn't answer within 15 seconds, then the agent is likely not going to answer.  You must have agents who aren't sitting by the phone, if you're waiting 60 seconds for an agent to answer.
By: Nick Barnes (bcnit) 2006-03-12 03:23:08.000-0600

OK. We're talking about two different uses of the Queue() application. A couple of sites use Queue() to provide hunt groups and need some flexibility in how they are implemented. At these sites, the queues are defined with static members (the handset, rather than the agent) and it is quite possible and legitimate for a call not to be answered.

Rather than have several queues all with the same members, but with different timeouts, we would like to have one queue to which we can allocate a timeout when the Queue() application is called.

I can appreciate how your example is valid in some call centre configurations, but I can think of others where this could be invalid (e.g. premium rate numbers in the UK have an obligatory requirement that the call should be queued for no more than 15 seconds). But it all comes down to how you run your call centre - if you want agents to answer calls, then don't specify a timeout in the Queue() call - if you want to jump out of a queue at a definite and absolute time, then use the parameter, no?

All I (and others) need is a way to leave a queue at a certain time - exactly the way the timeout works for the Dial() application. The way the timeout works at the moment is understandable (after some thought), but it's hardly logical.

Perhaps we could implement an A(x) parameter to the Queue() application to provide an absolute timeout - e.g. Queue(huntall,A(10)r) instead?
By: Tilghman Lesher (tilghman) 2006-03-12 23:40:03.000-0600

If you're looking to do a huntgroup, why not take advantage of the Dial application's ability to take multiple channels as an argument?  That is the recommended way to do huntgroups.
By: Nick Barnes (bcnit) 2006-03-13 02:58:52.000-0600

For two reasons:

1 - You can't do a round-robin hunt group with the Dial() application

2 - When the first call comes in, the devices specified all ring. If a second call arrives before the first call is answered, then when the Dial() application dials, all the devices return 'busy'.

Using the Dial() application for hunt groups is simply not appropriate.
By: Ove Aursand (aurs) 2006-03-13 05:38:08.000-0600

A third reason why using the Dial() application for hunt groups is simply not appropriate:
Queue announcements will cause the caller to loose his position in the queue.
Our most common use of queues is not typical call-center scenarios.
I just want to confirm that bcnit is not the only one who would like an option to make the Queue() application behave different.
By: Gareth Palmer (gareth) 2006-03-13 22:32:09.000-0600

Attached patch that makes try_calling() choose the lowest ringing timeout from qe->parent->timeout or qe->expire - now.
By: Nick Barnes (bcnit) 2006-03-16 06:26:34.000-0600

Fantastic. I will do some testing over the weekend. Thank you.
By: Serge Vecher (serge-v) 2006-05-03 15:26:05

gareth: do you have a disclaimer on file?

bcnit: how is that testing going?
By: Gareth Palmer (gareth) 2006-05-03 22:37:34

vechers: I have faxed a disclaimer now
By: Serge Vecher (serge-v) 2006-05-04 08:41:47

gareth: thanks.
1) Please fix the formatting, if you will, as per the coding-guidelines (tabs instead of spaces, no curly brackets in single-line if-else contstructs).

Thanks!
By: Gareth Palmer (gareth) 2006-05-04 17:09:20

Fixed formatting. New patch is against trunk.
By: Serge Vecher (serge-v) 2006-05-12 12:36:21

BJ: could you please look at this patch also?

Thanks.
By: Kevin P. Fleming (kpfleming) 2006-05-19 21:52:58

In spite of the discussions to the contrary, I do consider this to be a bug. The highest-level timeout should always take precedence.

Fixed in branch-1.2 revision 28968 and trunk revision 28970. Thanks!