[Home]

Summary:ASTERISK-03572: Agent groups not working
Reporter:dig (dig)Labels:
Date Opened:2005-02-23 11:05:19.000-0600Date Closed:2008-01-15 15:27:15.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When calling a queue that does ringall with agent groups....the queue will only call the first agent in the group. See config below.  If agent 104 and 105 are logged in (confimed via show agents on the CLI) When a call comes into the support queue, it should ring both of them, however, it will only ring 104.

****** ADDITIONAL INFORMATION ******


agents.conf
[agents]
group=1 ; Sales
agent => 102,55555
group=2 ; Billing
group=3 ; Support
agent => 104,55555
agent => 105,55555
agent => 106,55555

queue.conf
[support]
announce = queue-markq
strategy = ringall
timeout = 9
retry = 5
wrapuptime=15
announce-frequency = 90
announce-holdtime = yes
announce-round-seconds = 0
member => Agent/@3


exten => 3,1,SetVar(QUEUE_PRIO=10)
exten => 3,2,Queue(support-Q||||900)
exten => 3,3,VoiceMail(sb3)
exten => 3,4,Hangup

exten => 100,1,VoiceMailMain(@default)
exten => 100,2,Hangup

exten => 105,1,Dial(SIP/user,10)
exten => 105,2,VoiceMail(sb105)
exten => 105,3,Hangup

exten => 104,1,Dial(SIP/user,10)
exten => 104,2,VoiceMail(sb105)
exten => 104,3,Hangup

exten => 1,1,AgentCallbackLogin(${CALLERIDNUM},default)
Comments:By: Mark Spencer (markster) 2005-02-23 17:04:51.000-0600

That is not how groups work.  This is the normal behavior.  To do what you want, you will need to explicitly list each of the agents.  The grouping functionality can be thought of more as a hunt group (i.e. just any one of the available people)
By: dig (dig) 2005-02-24 13:41:59.000-0600

Can we reword the config file text so that it is more clear...below is a part of the files in question.. I would create a patch to do this however, I don't really understand how to use groups.

[queues]
member => Agent/@1              ; Any agent in group 1
[agents]
; Group memberships for agents (may change in mid-file)
;
;group=3
;group=1,2
;group=
By: Mark Spencer (markster) 2005-02-24 18:29:48.000-0600

It already says Any agent in group 1.  What do you want it to say?
By: dig (dig) 2005-02-24 18:38:14.000-0600

From the way I read it, it seems that it will call the agents in group 1 as if there were all members....So that when I want to add agents I can just edit the agents file and based on group membership the queue will call the group and the agents will go based off the group.   The way it is now, I must add agents to the agents file then edit the queue file and add the agent to the queue.  Why not handel it via groups?
By: Donny Kavanagh (donnyk) 2005-03-03 10:20:50.000-0600

I agree with the original poster, i too setup agent groups/queues and added just member => Agent/@1 to the queue and expirenced the same behavior.  ringall does what he said, random seemed to allways ring the same phone etc.

This functionality may be intended, but it doesnt make alot of sense.

How about offering groups some intelligence, such as:

member => Agent/@1 ; Any (which really is round robin from the top every time)
member => Agent/!1 ; ring all
member => Agent/*1 ; least recent
member => Agent/$1 ; fewest calls
member => Agent/%1 ; random
member => Agent/&1 ; rr w/memory

Is this a feisable solution?

edited on: 03-03-05 10:21
By: Kevin P. Fleming (kpfleming) 2005-03-03 10:26:42.000-0600

No, that's not feasible, because it would nullify the effect of the 'strategy' setting entirely if agent groups are in use.

Unfortunately this is just how agent groups are designed to work; it can't be easily changed because it would not be backwards compatible.
By: Donny Kavanagh (donnyk) 2005-03-03 11:04:26.000-0600

The strategy as defined in queues.conf only affects those members listed within queues.conf so, if i added two groups, set my queue to ringall, it will ring the first availble line in both groups.

What i was suggesting is to modify this behavior such that when the decision is made as which phone to dial within the group, (which in this case is allways the first available)  then to employ some strategy here such that we can control how the groups act.

eg, the queue is set to ringall and contains two groups 1 & 2.

As it stands right now, it will ring the first available line in both groups, but what if we could modify the group behavior such that we could set a ring all for both groups, making all the phones defined within the groups ring, or ring all on one group, and random with memory on another.

The change as i suggested would also be entirely backwords compatible, Agent/@1 would work as it allways did, the first available agent in the group.

edited on: 03-03-05 11:06
By: Kevin P. Fleming (kpfleming) 2005-03-03 11:25:55.000-0600

As I said on IRC (but I'll repeat here for everyone else's benefit): app_queue does not know who the members of an agent group are. When you use Agent/@1 in your queue, it sends the call to chan_agent requesting "any member of group 1".

If you want to implement this, it would have to duplicate all the queue strategy calculations in chan_agent, and if you mix agent groups and regular members in the queue it will work very, very poorly. It will also not work across groups; if you specify:

member => Agent/*1
member => Agent/*2

How would it pick the 'least recent' from those two groups?

Basically, when you make an agent group a _member_, that group _is_ the member; the members of the group do not become members of the queue.
By: Donny Kavanagh (donnyk) 2005-03-03 11:54:23.000-0600

Understood, i guess its a design issue and woudnt be solved without an overhaul of a number of things.

Thanks for the input.
By: dig (dig) 2005-03-03 16:06:52.000-0600

Ok, so why not if it sees that the member => agent has an @ sign in it to just expand the group so that it goes into the queues file as all the agents rather then just the first one.
By: Kevin P. Fleming (kpfleming) 2005-03-03 16:33:03.000-0600

Because app_queue has no idea how chan_agent works internally, and really shouldn't. If you're going to do that, you can just list the agents in queues.conf.
By: Donny Kavanagh (donnyk) 2005-03-03 18:35:52.000-0600

kp, rereading this, i thought again about your least recent argument.

chan_queue wouldn't have to be aware of which was least recent, you gave the example,

member => Agent/*1
member => Agent/*2

as long as chan_queue knows which group is least recent, it would then be up to chan_agent to take the '*' and decide who was least recent in the group.  This would of course lead to some redundant code between the two modules, but there may be a way to resolve that.  Either way, i still believe the design as it stands is flawed, and that there is no real purpose to groups what so ever at the moment.  The first few people in the group will end up with all the calls.
By: Mark Spencer (markster) 2005-03-03 18:57:34.000-0600

Updated documentation to be more explicit about the usefullness (or lack thereof) of agent groups.  You probably just want to use more than one queue :)
By: Russell Bryant (russell) 2005-03-11 00:42:00.000-0600

added the same doc change to 1.0
By: Digium Subversion (svnbot) 2008-01-15 15:26:52.000-0600

Repository: asterisk
Revision: 5134

U   trunk/configs/queues.conf.sample

------------------------------------------------------------------------
r5134 | markster | 2008-01-15 15:26:51 -0600 (Tue, 15 Jan 2008) | 2 lines

Update documentation on agent groups (bug ASTERISK-3572)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=5134
By: Digium Subversion (svnbot) 2008-01-15 15:27:15.000-0600

Repository: asterisk
Revision: 5162

U   branches/v1-0/configs/queues.conf.sample

------------------------------------------------------------------------
r5162 | russell | 2008-01-15 15:27:15 -0600 (Tue, 15 Jan 2008) | 2 lines

make docs on agent groups a little bit more clear (bug ASTERISK-3572)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=5162