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

Nathan Anderson nathana at fsr.com
Wed May 1 03:43:26 CDT 2013


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.



More information about the asterisk-gui mailing list