Penalties Not Working

Queue configuration:

[6502]
strategy = wrandom
timeout = 10
wrapuptime = 0
autofill = yes
autopause = no
autofill = yes
reportholdtime = no
musicclass = AMSTesting
ringinuse = no
servicelevel = 20

I have agents with penalties 1 , 2 , 3. Agents are not getting calls like they should penalty based.

Agent 1 - Penalty 1
Agent 2 - Penalty 2
Agent 3 - Penalty 3

If agent 1 is on the phone agent 2 should get the call, however this is not the case. Sometimes agent 3 gets the call before agent 2.

Asterisk 1.8.7.1

If it is random, haw can you define that agent 2 should get the call before agent 3? It sounds like you may really want a different strategy instead of wrandom, perhaps leastrecent, linear or fewestcalls.

; wrandom - rings random interface, but uses the member’s penalty as a weight
; when calculating their metric. So a member with penalty 0 will have
; a metric somewhere between 0 and 1000, and a member with penalty 1 will
; have a metric between 0 and 2000, and a member with penalty 2 will have
; a metric between 0 and 3000. Please note, if using this strategy, the member
; penalty is not the same as when using other queue strategies. It is ONLY used
; as a weight for calculating metric.

Agent 1 - Penalty 1
Agent 2 - Penalty 2
Agent 3 - Penalty 3

We are looking for a queue strategy which says that if agent 1 is on a call then no matter what agent 2 should get the next call based on agent 2’s current penalty assignment. It should not be possible that agent 3 gets the call before agent 2 from the legend I posted above.

More information we are using Asterisk realtime from MySQL to hold our queue_member_table.

What I do for that is set the strategy as leastrecent, then set the penalty for each agent.

If you use leastrecent and set the penalties as you describe, then…

Agent 1 will get the call if available,
Agent 2 will get the call if Agent 1 is unavailable or busy
Agent 3 will get the call if Agent 1 and Agent 2 are both unavailable or busy.

At least that is how it works for me.

Not sure if the realtime aspect would change anything. I don’t use realtime, but did create a login/logout pause/unpause application for dynamic agents where the information is stored in MySQL. In some cases agents belong to multiple queues with different penalites and distribution order still works as expects.

I have tried this method but still our agents are getting calls out of order does anyone have this perhaps there example config as well?

Updated
Yes we did also try the method proposed but leastrecent throws it even more out of whack.

Here is my queues.conf

[lostandfound]
announce-frequency = 30
announce-holdtime = yes
announce-position = yes
autopause = all
joinempty = yes
leavewhenempty = no
ringinuse = no
strategy = leastrecent
timeout = 20
setqueueentryvar=yes
setqueuevar=yes

Here is the output of the Asterisk CLI ‘queue show’

lostandfound has 0 calls (max unlimited) in 'leastrecent' strategy (10s holdtime, 71s talktime), W:0, C:247, A:16, SL:0.0% within 0s
   Members: 
      SIP/3592 with penalty 10 (dynamic) (Not in use) has taken 32 calls (last was 239 secs ago)
      SIP/3506 with penalty 40 (dynamic) (Not in use) has taken 6 calls (last was 6883 secs ago)
      SIP/3500 with penalty 20 (dynamic) (Not in use) has taken 8 calls (last was 63 secs ago)
   No Callers

I reconfigured my test system with three agents and configured the queue with the agents instead of the devices as I had previously. I added a dial plan extension for logging agents in as well.

agents.conf

[general]

[agents]
agent => 1001,4321,Mark Spencer
agent => 1002,4321,Will Meadows
agent => 1003,4321,Dale Noll

queues.conf

[lostandfound]
announce-frequency = 30
announce-holdtime = yes
announce-position = yes
autopause = all
joinempty = yes
leavewhenempty = no
ringinuse = no
strategy = leastrecent
timeout = 20
setqueueentryvar=yes
setqueuevar=yes
member => Agent/1001,1
member => Agent/1002,2
member => Agent/1003,3

extensions.conf

exten	=> 650,1,NoOp(Testing AgentLogin)
 same	=> n(getloginidread),Read(LoginID,agent-user,,,3)
 same	=> n,AgentLogin(${LoginID})
 same	=> n,Playback(agent-loginok)
 same	=> n,Hangup()

I log into three separate devices with the three agent IDs defined in agents.conf and placed a bunch of test calls…

lostandfound has 0 calls (max unlimited) in 'leastrecent' strategy (0s holdtime, 33s talktime), W:0, C:18, A:0, SL:50.0% within 0s
   Members: 
      Agent/1001 with penalty 1 (Busy) has taken 6 calls (last was 272 secs ago)
      Agent/1002 with penalty 2 (Busy) has taken 8 calls (last was 18 secs ago)
      Agent/1003 with penalty 3 (Not in use) has taken 4 calls (last was 282 secs ago)
   No Callers

The calls all went to agent 1001 first, agent 1002 if agent 1001 was busy and then agent 1003 if the others were busy. If agent 1001 logged off, all calls went to agent 1002 first.

Have you tried this with dynamic queue members? I noticed that you were hard coding the flat config files with the queues members. We are using realtime agents from the database. Have you tried using any backend database mechanism and still had the same results?

David do you have any suggestions?

Here is the output of my CLI

502 has 0 calls (max unlimited) in 'leastrecent' strategy (2s holdtime, 227s talktime), W:0, C:14114, A:1888, SL:85.7% within 20s
   Members: 
      1139 (SIP/1139) with penalty 2 (realtime) (In use) has taken 10 calls (last was 10 secs ago)
      1105 (SIP/1105) with penalty 3 (realtime) (In use) has taken 2 calls (last was 332 secs ago)
      1129 (SIP/1129) with penalty 5 (realtime) (paused) (Unavailable) has taken 18 calls (last was 48962 secs ago)
      1109 (SIP/1109) with penalty 6 (realtime) (Unavailable) has taken 17 calls (last was 55072 secs ago)
      1122 (SIP/1122) with penalty 3 (realtime) (Unavailable) has taken no calls yet
      1112 (SIP/1112) with penalty 3 (realtime) (Unavailable) has taken no calls yet
      1146 (SIP/1146) with penalty 4 (realtime) (Unavailable) has taken no calls yet
      1136 (SIP/1136) with penalty 1 (realtime) (paused) (Not in use) has taken 12 calls (last was 1019 secs ago)
      1126 (SIP/1126) with penalty 5 (realtime) (In use) has taken 18 calls (last was 469 secs ago)
      1116 (SIP/1116) with penalty 6 (realtime) (Not in use) has taken 13 calls (last was 21 secs ago)
      1106 (SIP/1106) with penalty 2 (realtime) (Unavailable) has taken no calls yet
      1133 (SIP/1133) with penalty 6 (realtime) (Unavailable) has taken 15 calls (last was 51373 secs ago)
      1123 (SIP/1123) with penalty 4 (realtime) (paused) (In use) has taken no calls yet
      1113 (SIP/1113) with penalty 3 (realtime) (In use) has taken 15 calls (last was 252 secs ago)
      1103 (SIP/1103) with penalty 3 (realtime) (paused) (Not in use) has taken 17 calls (last was 325 secs ago)
      1137 (SIP/1137) with penalty 2 (realtime) (In use) has taken 51 calls (last was 47 secs ago)
      1170 (SIP/1170) with penalty 1 (realtime) (Unavailable) has taken no calls yet
      1127 (SIP/1127) with penalty 3 (realtime) (Unavailable) has taken no calls yet
      1208 (SIP/1208) with penalty 2 (realtime) (paused) (Not in use) has taken 18 calls (last was 1899 secs ago)
      1140 (SIP/1140) with penalty 2 (realtime) (Unavailable) has taken no calls yet
      1120 (SIP/1120) with penalty 6 (realtime) (paused) (Unavailable) has taken 20 calls (last was 51127 secs ago)
      1110 (SIP/1110) with penalty 3 (realtime) (paused) (Not in use) has taken 21 calls (last was 642 secs ago)
      1134 (SIP/1134) with penalty 2 (realtime) (In use) has taken 33 calls (last was 48 secs ago)
      1124 (SIP/1124) with penalty 5 (realtime) (Unavailable) has taken 11 calls (last was 54881 secs ago)
      1158 (SIP/1158) with penalty 3 (realtime) (Unavailable) has taken no calls yet
      1171 (SIP/1171) with penalty 1 (realtime) (Unavailable) has taken no calls yet
      1128 (SIP/1128) with penalty 1 (realtime) (In use) has taken 26 calls (last was 61 secs ago)
      1118 (SIP/1118) with penalty 4 (realtime) (In use) has taken 51 calls (last was 137 secs ago)
      1108 (SIP/1108) with penalty 5 (realtime) (In use) has taken 18 calls (last was 310 secs ago)
      1131 (SIP/1131) with penalty 4 (realtime) (In use) has taken 16 calls (last was 281 secs ago)
      1111 (SIP/1111) with penalty 2 (realtime) (Unavailable) has taken no calls yet
      1145 (SIP/1145) with penalty 6 (realtime) (Unavailable) has taken 35 calls (last was 48171 secs ago)
      1101 (SIP/1101) with penalty 1 (realtime) (paused) (Unavailable) has taken 4 calls (last was 54339 secs ago)
      1135 (SIP/1135) with penalty 2 (realtime) (Unavailable) has taken no calls yet
      1125 (SIP/1125) with penalty 5 (realtime) (Unavailable) has taken no calls yet
      1115 (SIP/1115) with penalty 3 (realtime) (paused) (Unavailable) has taken 2 calls (last was 60285 secs ago)
   No Callers

My original posting is using dynamic queue members. I modified a test system and hardcoded the agents to verify operation of AgentLogin as opposed to AddQueueMember.

In my original config, when agent dials login extension, they are prompted for agent ID. That ID is retrieved from MYSQL and if valid (and optionally pin protected) they are added to appropriate queues with penalties defined within the database using AddQueueMember().

I just do not use the ‘realtime’ queues as the queues themselves are not really dynamic, just the agents. And they are not that dynamic either :wink:

Yes I’m not sure but I’m thinking that even though “Realtime” should be working , it is not we will probably be forced to open a commercial ticket for this but I thought I would give the forum post a little more time to see if someone had a similar environment to mine. :smiley:

So far the commercial route has the dCAP’s at Digium stumped for now. Who knew such a simple request would be so complicated? I am still open to anyone who thinks they may know the solution as we are having lots of business issues because of this and we are willing to try several different configs.

We are still awaiting a response from the commercial Digium dCAP’s on this issue, has anyone been able to successfully get this working?

Ok guys, here’s the solution to penalty members not working. I think I should have researched this a little better but here’s the link. Essentially you need to upgrade your version of Asterisk to at least 1.8.9 OR you can fool the queue by adding :
penaltymemberlimit = -1 in case you’re like me and are hesitant to upgrade.

issues.asterisk.org/jira/browse/ASTERISK-18662