Summary:ASTERISK-18588: Static queue agent penalty not respected (rrmemory)
Reporter:Dave Bouchard (drykod)Labels:
Date Opened:2011-09-20 10:25:48Date Closed:2011-11-01 08:26:05
Versions: Frequency of
duplicatesASTERISK-18662 Member penalty ignored because wrong queue membercount

we have a problem where calls often/constantly go to static agents with higher penalty instead of the available lower.

we use the rrmemory strategy and asterisk


default-support has 0 calls (max unlimited) in 'rrmemory' strategy (0s holdtime, 0s talktime), W:0, C:0, A:7, SL:0.0% within 60s
     Local/250@default-agent/n with penalty 2 (Not in use) has taken no calls yet
     Local/2222@default-agent/n with penalty 1 (Not in use) has taken no calls yet
     Local/240@default-agent/n with penalty 2 (In use) has taken no calls yet
     Local/272@default-agent/n with penalty 1 (Not in use) has taken no calls yet
     Local/271@default-agent/n (Not in use) has taken no calls yet
  No Callers


We expect 240 and 250 to never get the call unless 271, 272 and 2222 are unavailable or already in use.

Comments:By: Leif Madsen (lmadsen) 2011-09-21 09:26:43.801-0500

I'm not sure this snippet of console output really shows what happened.

I'd suggest you provide the console output showing this happening (debug information as well since it will show what the Queue() is doing). Also please provide a simple configuration so this can be setup easily and reproduced.


By: Dave Bouchard (drykod) 2011-10-04 11:17:37.361-0500

I guess issue has just been reported with root cause (and it includes a workaround) :

By: Leif Madsen (lmadsen) 2011-11-01 08:25:03.283-0500

Honestly this is a bit of a failed configuration / incorrect best practices.

If you're going to use Local channels in the Queue(), then you need to tell the queue application which end point to track for device state (and it needs to be a SIP end point) in order to get accurate state information. Asterisk will make a best effort using Local channels, but it cannot be relied upon.

I'm closing this issue in favour of the other issue.