No subject

ter adding a user with "Is Agent?" checked to a queue, that user will find =
that he/she cannot log in or log out of the queue by dialing the "Agent Cal=
lback Login Extension".  They will simply be told there was an error when t=
hey try.  Furthermore, they will find that they are actually logged into th=
e queue, permanently.

This is because when you add an agent to a queue in the GUI by checking the=
 checkbox next to the agent's extension # in the queue's settings, queues.j=
s adds a (for example, in the case of a SIP extension numbered 101) "member=
 =3D SIP/101" to that queue's section in queues.conf.  What this does is ad=
d channel SIP/101 to the queue as a static member, and static queue members=
 cannot be removed by RemoveQueueMember(); only members added via AddQueueM=
ember() can be removed by the corresponding removal application.  So, in ef=
fect, when you configure a queue member using the GUI, that member can neve=
r log off, which kind of defeats the purpose of having an "Agent Callback L=
ogin Extension" as well as the entire 'queue-member-manager' apparatus that=
 was added to the dialplan.  queues.js links the state of that queue member=
's checkbox in the GUI to the "member" entry that it added to queues.conf, =
so if you remove that line from queues.conf, the checkbox in the GUI will b=
e unchecked.  But at least the agent can log on and off at that point, alth=
ough even that does not behave entirely as one might expect.

Here is the behavior of the system as things stand now:

1. "Agent Login Extension" doesn't work.  The agent can log in and everythi=
ng, but when a call enters the queue, it will not be sent to the active Age=
ntLogin() session.  If they have been added to a queue via the GUI, because=
 doing so adds the agent's direct channel to the queue as a static member, =
the queue will ring the phone directly, completely outside of their AgentLo=
gin() session.

2. If a user has "Is Agent?" checked in their user settings, but has not be=
en added as members to any queues via the GUI, that user can log in to ALL =
queues simultaneously by simply dialing the "Agent Callback Login Extension=
".  They will then begin to receive calls from all queues defined in the sy=
stem that are getting calls sent to them.

3. If an agent is added to a queue via the GUI, again, because doing so add=
s the agent's direct channel to the queue as a static member, they will fin=
d that they are permanently "logged in" to that particular queue.  Dialing =
the "Agent Callback Login Extension" will not log them out of that queue, b=
ut WILL have the effect of proceeding to add them to all other queues defin=
ed in the system, even though according to the GUI, they are not configured=
 to be members of them!

I think we can agree that this is broken.  This, I believe, is the expected=
 behavior of the system, and how things used to work:

1. You enable users to be agents via "Is Agent?" in that user's settings.  =
Doing so does not cause them to participate in any queues, but merely makes=
 them show up as an option when you go to add members to queues in the GUI =
(as well as defines an Agent channel for them, by virtue of 'hasagent' havi=
ng been set to 'yes' in users.conf, which chan_agent keys off of in additio=
n to parsing agents.conf)

2. If an agent dials the "Agent Login Extension", they will have an active =
session with the AgentLogin() application, which will send them calls *over=
 that existing session*; if they end the session, they will not get queue c=
alls.

3. If an agent dials the "Agent Callback Login Extension", their phone will=
 be sent calls only from queues that they were configured to be members of =
via the GUI, not ALL queues in the system.  Dialing it a second time should=
 cause them to no longer get any calls.

I believe the heart of the problem is that although the new dialplan code u=
ses AddQueueMember() and RemoveQueueMember() correctly, the GUI, which was =
originally written under the assumption that Agent channels needed to be st=
atic members of queues, was changed to merely add the agent's direct channe=
l as a static queue member instead, which is not a sufficient modification =
to accommodate the new callback method.  The GUI changes need to be more ex=
tensive than that to account for the new dialplan logic, especially if the =
desire is to continue to support both types of queues, since AgentLogin() *=
still* requires that Agent channels be static members of their respective q=
ueues, while the new method of implementing callback-style queues most emph=
atically cannot work that way.  This suggests that the state of a queue's m=
ember roster in the GUI cannot be held merely in the "member =3D" lines in =
queues.conf, as the GUI is attempting to do now, and needs to be stored els=
ewhere (a dialplan global variable, perhaps? Or -- better yet -- maybe a ${=
HASH()}?).  The deprecation of AgentCallbackLogin() really has caused compl=
ications that need to be worked through more thoroughly.

A rearchitecting of the GUI's queue support is probably the best way to go =
about a fix, but it also occurred to me that there are a couple of other wa=
ys that the problem could be solved that would not require extensive rewrit=
es to the GUI's queues support.  Instead, minor changes to Asterisk itself =
would be required:

1. Static queue members (that is, members defined in queues.conf) cannot be=
 removed from a queue with RemoveQueueMember().  But is there a good reason=
 why that is the case?  What if app_queue were modified to allow for that? =
 A brief study of app_queue.c suggests that this would effectively be a one=
-line change (basically, setting the "dynamic" member of the "member" struc=
t to 1 in the reload_single_member() function).  This would effectively get=
 rid of static queue members, and turn the "member =3D" lines in queues.con=
f into a default login state of sorts.  This would mean that the Asterisk-G=
UI could continue to utilize those "member" lines in the config file as the=
 means of storing queue membership state.  The only possibly negative conse=
quence this might have is that users added to queues in the GUI would find =
themselves logged into their respective queues by default after a fresh lau=
nch of Asterisk.  It would probably best to toggle this new behavior on and=
 off with some kind of new global setting in queues.conf that is off by def=
ault.

2. RemoveQueueMember() cannot remove static members, but even static member=
s can be paused and unpaused with PauseQueueMember() and UnpauseQueueMember=
().  Although this is probably not really how their designer(s) intended fo=
r them to be used, the AddQueueMember() application could be replaced in th=
e dialplan with UnpauseQueueMember(), and RemoveQueueMember() with PauseQue=
ueMember().  The only problem with this is that in order to determine wheth=
er someone is logged into a queue or not, the current dialplan logic checks=
 to see whether a channel is a member of a queue using the ${QUEUE_MEMBER_L=
IST()} function, which counts on the behavior of AddQueueMember() and Remov=
eQueueMember().  There is no function that app_queue exports which returns =
a list that only consists of queue members that are unpaused.  If such a fu=
nction (say, ${QUEUE_MEMBER_UNPAUSED_LIST()}) were to be implemented in app=
_queue, then we could get away with pausing and unpausing queue members ins=
tead of dynamically adding and removing them from queues entirely.  This wo=
uld have the same effect -- allowing the GUI queue member state to remain i=
n queues.conf -- as the previous suggestion, but unlike the previous sugges=
tion, would do so without eliminating the distinction between static queue =
members and dynamic queue members.  It would also have the same sole negati=
ve consequence, in that queue members would find themselves logged in by de=
fault after an Asterisk restart.

And that's just in order to fix things such that they work again the way th=
ey (largely) used to work, and are supposed to work.  It doesn't address th=
ings like:

1. ...giving agents a way to only be logged into certain queues, instead of=
 the current all-or-nothing approach
2. ...prompting agents for a PIN when they use the callback-style method (w=
hich *did* work in the past)
3. ...divorcing the agent ID from the extension number (which also used to =
be the case with the old callback system)

...although some might argue that #3 is not necessarily desireable, and tha=
t as a matter of principle, agents should be registering to Asterisk using =
their own credentials to begin with.  I'd agree, but it leaves too many oth=
er problems unresolved.  For example, that policy might work for softphones=
, but many (most?) SIP desk phones do not make switching between SIP users =
easy, or even possible (especially if the phone is locked-down); you can't =
normally sit down at one and punch in a few buttons to "log in" (register t=
o a SIP registrar with your own credentials).  Besides, what about other ch=
annel technologies, like DAHDI?  What if a call center has analog handsets,=
 and yet still needs for agents to be able to sit down at any desk and begi=
n to take calls rather than providing each agent with a designated phone?

Anyway, this write-up has gone on longer than I'd planned, so I'll stop her=
e for now and see if there are any comments (or a recommendation to take th=
e discussion elsewhere!).

Thanks,

--=20
Nathan Anderson
First Step Internet, LLC
nathana at fsr.com