| 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:30 | Date Closed: | |||||
| Priority: | Minor | Regression? | |||||
| Status: | Open/New | Components: | Applications/app_queue | ||||
| Versions: | 1.8.20.1 13.18.4 | Frequency of Occurrence | |||||
| Related Issues: |
| ||||||
| Environment: | Gentoo Linux 3.0.65 | Attachments: | ( 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() [at-test1] 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 1.8.26.0 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 {quote} Do you mind testing with 1.8.26.0 or 11.8.0 to see if this fixed this issue for you as well? {quote} By: Ksenia (ksy) 2014-03-26 03:56:18.265-0500 Tested today with Asterisk 11.8.1 - just the same behavior. | ||||||