Summary:ASTERISK-21879: app_queue's autofill=yes effectively fails to deliver all calls when those calls are preceded by a call with a min/max penalty that can't be delivered
Reporter:Ksenia (ksy)Labels:
Date Opened:2013-06-07 06:26:30Date Closed:
Versions: 13.18.4 Frequency of
is related toASTERISK-19368 Queue penalty only work when QUEUE_MIN_PENALTY == QUEUE_MAX_PENALTY
is related toASTERISK-20862 Asterisk min and max member penalties not honored when set with 0
Environment:Gentoo Linux 3.0.65Attachments:( 0) channels_info.txt
( 1) full.log
Description:We have 2 queues - at-test and at-test1.
A user calls extension 8100 and after 20s timeout waiting in at-test we set QUEUE_MIN_PENALTY=20 for the call, then it goes to queue at-test1. We have an autofill parameter set to 'yes' in at-test1. Only agent Agent/903 from at-test1 can receive the call with minimal penalty set to 20. So, if this agent Agent/903 is busy or unavailable, the call is waiting in the queue. But if another user calls extension 8101, he has to wait untill that call with QUEUE_MIN_PENALTY=20 is answered or dropped, though autofill parameter is set to 'yes' and there are free agents 904 and 905. Is it a normal behavior?
P.S. I've fixed it using QUEUE_PRIO variable for extension 8101, but still it's very interesting to know why the calls have to wait in such circumstances.

exten => 8100,1,Answer()
exten => 8100,n,Queue(at-test,t,,,20)
exten => 8100,n,Set(QUEUE_MIN_PENALTY=20)
exten => 8100,n,Queue(at-test1,t,,,3600)
exten => 8100,n,Hangup()

exten => 8101,1,Answer()
exten => 8101,n,Queue(at-test1,t,,,3600)
exten => 8101,n,Hangup()

autofill = yes
setinterfacevar = yes
setqueuevar = yes
strategy = leastrecent
announce-frequency = 60
wrapuptime = 12
announce-round-seconds = 30
announce-holdtime = yes
announce-position = yes
queue-thankyou = no
reportholdtime = no
ringinuse = no
joinempty = yes
member => Agent/903,20,(903) Test Operator
member => Agent/904,,(904) Test Operator
member => Agent/905,,(905) Test Operator
Comments:By: Ksenia (ksy) 2013-06-07 06:39:02.749-0500

I've attached full log with core set verbose 5 and core set debug 5 and channels information (core show channel) for channels waiting in a queue

By: Rusty Newton (rnewton) 2013-06-20 17:19:31.877-0500

I reproduced this (in SVN-branch-1.8-r391778) following your description. I've talked with some of the developers here and it seems that it's a limitation of the current design.

Essentially app_queue is stuck on waiting to deliver the call with the min penalty since there are no members available that it can take it. Yes you would expect that with autofill=yes app_queue would then skip that call and attempt delivering the others. Apparently the penalties throws some confusion into the mix.

Good thing you found a workaround for now.

By: Rusty Newton (rnewton) 2013-06-20 17:21:41.844-0500

Linking to ASTERISK-19368 since they are both concerning relationships between min/max penalties and autofill=yes.

By: Matt Jordan (mjordan) 2014-03-04 06:30:06.603-0600

The issue reporter for ASTERISK-19368 just reported that their issue was fixed by r402646, which fixed a similar min/max penalty issue in {{app_queue}} for issue ASTERISK-20862. Do you mind testing with or 11.8.0 to see if this fixed this issue for you as well?

By: Rusty Newton (rnewton) 2014-03-19 09:49:19.575-0500

Pinging the reporter one more time

Do you mind testing with or 11.8.0 to see if this fixed this issue for you as well?

By: Ksenia (ksy) 2014-03-26 03:56:18.265-0500

Tested today with Asterisk 11.8.1 - just the same behavior.