Summary:	ASTERISK-07191: [patch] calc_metric and max_penalty
Reporter:	dillec (dillec)	Labels:
Date Opened:	2006-06-16 18:43:39	Date Closed:	2006-07-13 15:46:09
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) app_queue-calc-metric.patch
Description:	The code in app_queue related to the function calc_metric and "max_penalty" will restrict the penalty to a maximum of 0 unless someone specifies a higher value. The if clause is missing the second argument "&& qe->max_penalty" ****** ADDITIONAL INFORMATION ****** If you try to add an queue member with penalty > 0 he/she will be ignored unless ${QUEUE_MAX_PENALTY} in dialplan is set to a higher value
Comments:	By: BJ Weschke (bweschke) 2006-06-21 22:25:41 Isn't this by design? I thought the intent of this was to make an attempt at some skills based routing to determine which skillsets could answer an individual caller coming into the queue (set via ${QUEUE_MAX_PENALTY}. By: dillec (dillec) 2006-06-22 04:56:13 yes, thats design :-) But i think it is much better that an unset ${QUEUE_MAX_PENALTY} will make all penalty's read and only restrict it if it is set. By: Serge Vecher (serge-v) 2006-06-28 14:09:41 diLLec: please solicit some feedback on this on asterisk-dev mailing list or please join the #asterisk-dev channel on IRC and solicit some feedback there. Thanks By: dillec (dillec) 2006-07-02 03:45:07 i've reported this to asterisk-dev mailing list. hope someone answers :-) By: Kevin P. Fleming (kpfleming) 2006-07-06 07:55:09 No, this clearly was not the intent. If QUEUE_MAX_PENALTY is not set, the behavior should be identical to what it was before the max penalty support was added. It should only have an effect when it has been set. By: Kevin P. Fleming (kpfleming) 2006-07-13 15:44:21 This has been corrected in trunk. By: Serge Vecher (serge-v) 2006-07-13 15:46:09 r37515, for archival purposes.