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" <[email protected]> > To: "[email protected]" <[email protected]> > 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 > [email protected] > > -- > _____________________________________________________________________ > -- 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 > -- _____________________________________________________________________ -- 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
