[asterisk-bugs] [Asterisk 0012884]: [patch] Queue is treated as empty if it isn't, but no agents meet the QUEUE_MIN_PENALTY and QUEUE_MAX_PENALTY criteria

Asterisk Bug Tracker noreply at bugs.digium.com
Wed Oct 29 12:44:31 CDT 2008


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12884 
====================================================================== 
Reported By:                bcnit
Assigned To:                twilson
====================================================================== 
Project:                    Asterisk
Issue ID:                   12884
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           1.6.1-beta1 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-06-18 12:19 CDT
Last Modified:              2008-10-29 12:44 CDT
====================================================================== 
Summary:                    [patch] Queue is treated as empty if it isn't, but
no agents meet the QUEUE_MIN_PENALTY and QUEUE_MAX_PENALTY criteria
Description: 
In a situation where a call is placed into a queue as follows:

exten => s,n,Set(QUEUE_MAX_PENALTY=1)
exten => s,n,Set(QUEUE_MIN_PENALTY=1)
exten =>
s,n,Queue(${ORGCODE}_${ORGQUEUE},ih,,${ORGCODE}/announce-incoming)
)
The queue is deemed to be empty if there are no agents with a penalty of 1
as a member of the queue.

We use queuerules.conf to raise the QUEUE_MAX_PENALTY value to overflow
calls to other departments and in our case (and I can imagine, other
people's too), it is perfectly legitimate to have members with a penalty of
2 logged in and no members with penalty 1.

As a result of this, the function QUEUE_MEMBER() returns incorrect data
(i.e. QUEUE_MEMBER(free) may return the "number of logged-in members for
the specified queue available to take a call" as 10, but in reality and
because of the penalty issue, it is zero.

I have been able to work around this by checking QUEUE_MEMBER(count) after
I receive a JOINEMPTY bounce out, incrementing QUEUE_MAX_PRIORITY and
trying again, but this is far from ideal!
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0012880 Queue() uses cached information to dete...
====================================================================== 

---------------------------------------------------------------------- 
 (0094364) putnopvut (administrator) - 2008-10-29 12:44
 http://bugs.digium.com/view.php?id=12884#c94364 
---------------------------------------------------------------------- 
I discussed this with otherwiseguy and the patch meets my approval.

The only problems with the patch are silly things that are my fault like
trailing whitespace and some weird indentation on the comments near the
bottom of join_queue. Functionally, though, it's great! Thanks for picking
this one up. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-29 12:44 putnopvut      Note Added: 0094364                          
======================================================================




More information about the asterisk-bugs mailing list