[asterisk-gui] Strategy for fixing queues in the GUI

Wed May 1 12:00:59 CDT 2013

Nathan,

This is indeed the correct location for discussions of this nature, though this list is extremely low-traffic. Additionally, since Digium is not putting additional resources into Asterisk GUI, you may not find much of a discussion anywhere. Good luck in your endeavor! If you do end up reworking queue support in Asterisk GUI in a way that is appropriate for adding to the publicly-available Asterisk GUI repository, please consider submitting it as a patch to the Asterisk GUI (AGUI) project on http://issues.asterisk.org.

Thanks!

Erin Spiceland

----- Original Message -----
> From: "Nathan Anderson" <nathana at fsr.com>
> To: "asterisk-gui at lists.digium.com" <asterisk-gui at lists.digium.com>
> Sent: Wednesday, May 1, 2013 3:43:26 AM
> Subject: [asterisk-gui] Strategy for fixing queues in the GUI
> 
> Hello again,
> 
> Not sure if this is the right place to post this or not as it is
> kinda-sorta development related; my apologies if I have erred.  Is
> this only a users' forum, and GUI-related development topics should
> go to asterisk-dev, even though nobody there will probably be
> interested in anything related to the GUI? :)
> 
> As I've mentioned a couple of times in the past, I have been working
> on an embedded platform that I'm trying to create a turn-key
> Asterisk + Asterisk-GUI system for.  Along the way, I've had to
> engage in some bug-hunting.  While there have been a number of
> genuine bugs in the GUI code itself that I've encountered, I'd say
> that a sizable number of the issues I've found myself wrestling with
> are simply the result of underlying changes that happened to
> Asterisk between 1.4 and 1.8 that have not yet been accounted for in
> the GUI.  For the most part, to my own relief, I've found that the
> fixes for most of these issues (both the genuine bugs as well as the
> 1.8 incompatibilities) have turned out to be fairly straightforward
> to address, and not demanding of sweeping architectural changes or
> complete rewrites of large blocks of code.
> 
> But now I'm wrestling with queues, and at first glance they seem to
> be nothing short of a mess.  I'm trying to figure out the best ways
> to address the problems I'm seeing.  Both the "traditional"
> chan_agent/AgentLogin() queues and the callback-style queues are
> broken as things currently stand:
> 
> 1. Classic / AgentLogin()
> 
> AgentLogin() is broken on account of SVN changeset 5030, which, in an
> attempt to fix the callback-style queues for Asterisk 1.8, changed
> queues.js behavior so that it added the SIP channel for the agent as
> a member of the queue (in queues.conf) instead of the Agent channel
> for the agent, as before (so, "member = Agent/101" became "member =
> SIP/101", for example).  This makes sense (...kind of, as I'll
> address when I talk about the callback-style queue), but I suspect a
> better fix would have been to add *both* Agent/101 and SIP/101 as
> queue members, which would have allowed AgentLogin() to continue to
> work as before, instead of completely replacing the former with the
> latter.  (Either that or deprecate support of AgentLogin() in
> Asterisk-GUI altogether by removing the "Agent Login Extension"
> setting; its continued existence suggests that it should still work
> and be usable.)
> 
> 2. Callback-style
> 
> In Asterisk 1.4, adding Agent channels as static members of queues
> worked universally for both styles of queues, since the
> callback-style queue was implemented using AgentCallbackLogin().  As
> is well-known by now, AgentCallbackLogin() was deprecated in 1.6 and
> eliminated altogether in 1.8, and the official replacement for it
> was to implement your own callback queue within the dialplan itself,
> using AddQueueMember() and RemoveQueueMember() to dynamically add
> the actual user's channel to the queue -- whether that be SIP, IAX2,
> DAHDI, or whatever -- instead of statically adding a virtual
> pseudo-channel (such as Agent) that is bound to your real channel
> through a login process.  This is what Asterisk-GUI SVN changeset
> 5030 implemented: a replacement for AgentCallbackLogin() in the
> dialplan.  Aside from the fact that this implementation does not
> prompt for a password/PIN upon logging in (in contrast to both
> AgentLogin() and AgentCallbackLogin()), and also assumes that the
> agent ID
>   is equal to the extension # that the agent is logged on to
>   (something that AgentLogin() doesn't assume, and something that
>   AgentCallbackLogin() did not assume), the actual dialplan
>   implementation seems to work as designed.  But when combined with
>   the GUI itself and how it tracks queue members, it is not usable.
> 
> From the user's perspective, the main problem that one will face is
> that after 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 Callback Login Extension".  They will simply be
> told there was an error when they try.  Furthermore, they will find
> that they are actually logged into the 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.js adds a (for example, in the case of a SIP
> extension numbered 101) "member = SIP/101" to that queue's section
> in queues.conf.  What this does is add channel SIP/101 to the queue
> as a static member, and static queue members cannot be removed by
> RemoveQueueMember(); only members added via AddQueueMember() can be
> removed by the corresponding removal application.  So, in effect,
> when you configure a queue member using the GUI, that member can
> never log off, which kind of defeats the purpose of having an "Agent
> Callback Login 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 be
> unchecked.  But
>   at least the agent can log on and off at that point, although 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
> everything, but when a call enters the queue, it will not be sent to
> the active AgentLogin() 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 AgentLogin() session.
> 
> 2. If a user has "Is Agent?" checked in their user settings, but has
> not been 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 system that are getting calls sent to
> them.
> 
> 3. If an agent is added to a queue via the GUI, again, because doing
> so adds the agent's direct channel to the queue as a static member,
> they will find that they are permanently "logged in" to that
> particular queue.  Dialing the "Agent Callback Login Extension" will
> not log them out of that queue, but WILL have the effect of
> proceeding to add them to all other queues defined 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' having been set to 'yes'
> in users.conf, which chan_agent keys off of in addition 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 calls.
> 
> 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 uses AddQueueMember() and RemoveQueueMember() correctly, the
> GUI, which was originally written under the assumption that Agent
> channels needed to be static members of queues, was changed to
> merely add the agent's direct channel 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 extensive 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 queues, while the new method of implementing
> callback-style queues most emphatically cannot work that way.  This
> suggests that the state of a queue's member roster in the GUI cannot
> be held merely in the "member =" lines in queues.conf, as the GUI is
> attempting to do now, and needs to be stored elsewhere (a dialpla
>  n global variable, perhaps? Or -- better yet -- maybe a ${HASH()}?).
>   The deprecation of AgentCallbackLogin() really has caused
>  complications 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 ways that the problem could be solved that would not
> require extensive rewrites 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" struct to 1 in the
> reload_single_member() function).  This would effectively get rid of
> static queue members, and turn the "member =" lines in queues.conf
> into a default login state of sorts.  This would mean that the
> Asterisk-GUI could continue to utilize those "member" lines in the
> config file as the means of storing queue membership state.  The
> only possibly negative consequence 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 launch of Asterisk.  It
> would probably best to toggle this new behavior on and off with some
> ki
>  nd of new global setting in queues.conf that is off by default.
> 
> 2. RemoveQueueMember() cannot remove static members, but even static
> members can be paused and unpaused with PauseQueueMember() and
> UnpauseQueueMember().  Although this is probably not really how
> their designer(s) intended for them to be used, the AddQueueMember()
> application could be replaced in the dialplan with
> UnpauseQueueMember(), and RemoveQueueMember() with
> PauseQueueMember().  The only problem with this is that in order to
> determine whether 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_LIST()} function, which counts on the
> behavior of AddQueueMember() and RemoveQueueMember().  There is no
> function that app_queue exports which returns a list that only
> consists of queue members that are unpaused.  If such a function
> (say, ${QUEUE_MEMBER_UNPAUSED_LIST()}) were to be implemented in
> app_queue, then we could get away with pausing and unpausing queue
> members instead of dynamic
>  ally adding and removing them from queues entirely.  This would have
>  the same effect -- allowing the GUI queue member state to remain in
>  queues.conf -- as the previous suggestion, but unlike the previous
>  suggestion, would do so without eliminating the distinction between
>  static queue members and dynamic queue members.  It would also have
>  the same sole negative consequence, in that queue members would
>  find themselves logged in by default after an Asterisk restart.
> 
> And that's just in order to fix things such that they work again the
> way they (largely) used to work, and are supposed to work.  It
> doesn't address things 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 (which *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 that 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 other 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 to a
> SIP registrar with your own credentials).  Besides, what about other
> channel 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 begin 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 here for now and see if there are any comments (or a
> recommendation to take the discussion elsewhere!).
> 
> Thanks,
> 
> --
> Nathan Anderson
> First Step Internet, LLC
> nathana at fsr.com
> 
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-gui mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-gui
> 