Request for Feedback: Queues, Penalties, RINGALL, and Use Cases

[bford]

Hey everyone,

I’m working in the queue code and have stumbled across a weird scenario involving penalties and queue rules. If two agents have penalties 0 and 1 in a RINGALL queue, then only the agent with penalty 0 will be called. If I try raising the QUEUE_MAX_PENALTY to say, 5, I would expect the agent with a penalty of 1 to also be called. This is not the case, however. There’s one line of code that checks an agent’s priority to be called (aka metric), and it is based on penalty. Finding the best agent to call is based on the lowest metric value, which will always be the agent with the lowest penalty with current Asterisk. Changing this line to always have the metric be 0 for RINGALL allows the other agent to be called once its penalty falls within the allowable range (between QUEUE_MIN_PENALTY and QUEUE_MAX_PENALTY).

Are there any use cases that this would break? Is there something I’m not thinking of that you guys are using this for? I would like as much feedback as possible so that any change made does not cause problems for others, since the code is rather old.

Thanks in advance!

[penguinpbx]

I agree on the need for dusting off apps from time to time. For instance the naming of penalties in queues is confusing IMO. Who is getting penalized ? Everybody ? Maybe a more positive approach for naming could be helpful to sort it out ? Something like a “reward” program to complement the “penalty” ? More carrot less stick ?

Anyhow, I think this change might break some expected behaviour. And I believe the goal can be accomplished in plain text configuration files…

queuerules.conf:

[general]
[self_rule]
penaltychange => 10,+1,,+1

queues.conf:

[general]
[free-folk-help-desk]
strategy = ringall
timeout = 8
retry = 4
defaultrule = self_rule
member => PJSIP/700,0,Jon
member => PJSIP/701,1,Ygritte

extensions.ael:

context default {
  555 => {
    Set(QUEUE_MIN_PENALTY=0);
    Set(QUEUE_MAX_PENALTY=0);
    Set(QUEUE_RAISE_PENALTY=0);
    Queue(free-folk-help-desk);
  }
}

Dial 555 from another extension, and it rings the first phone (Jon x700) for eight seconds, waits four seconds, then rings both phones (Jon x700 and Ygritte x701) forever, in twelve second loops – at least in a recent Asterisk 16 I tested on.

[bford]

Yes, this would definitely work for 16! Users on 13 don’t have access to QUEUE_RAISE_PENALTY, so I believe that the correct approach here is to do what you’ve mentioned and use 16 to accomplish the same goal.

[penguinpbx]

Great, I did not realize QUEUE_RAISE_PENALTY was so new! But I’ll definitely be using it in the future, particularly to replace/upgrade some “waterfall” multi-queue strategies that look a little sloppy at times.

Also I opened a ticket #28544 and submitted a patch against the Basic PBX configuration files for Super Awesome Company to implement appropriate queue configurations of the sort that we’ve discussed here.