Summary:ASTERISK-07191: [patch] calc_metric and max_penalty
Reporter:dillec (dillec)Labels:
Date Opened:2006-06-16 18:43:39Date Closed:2006-07-13 15:46:09
Versions:Frequency of
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"


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.