All, I'm trying to configure queue agents w/ a DUNDi setup so that an agent can login to whatever server they please w/o any custom setup. In general this seems to work, agents login w/ AgentCallbackLogin into the incoming context (not a special queue context) and can receive queue calls. The problem is that since the incoming context is the same context as the normal incoming call context, they get sent to voicemail if they don't answer. I thought the solution would be as simple as defining a separate queue for the AgentCallbackLogin, and dumping calls to that queue. The problem that I see with that is I can no longer use DUNDi to route the call. If I do that and don't have their explicit extension in the [agentqueue] context, I get 'Extension XXXX is not valid for automatic login of agent YYYY' when they try to login. If I put a huge _XXXX match in the [agentqueue] then I can login, but it can't route the call properly because routing the call needs a DUNDi lookup which puts them back into stdexten. I *think* my solution is to basically create two DUNDi networks, one that I can route calls to from the agentqueue context, and the other from the inbound context. The agentqueue DUNDi network would then just not include the stdexten dialing and would only be called by queue calls. If anyone has a more simple solution I'm all ears. Hopefully I'm making this more complicated that it needs to be. :) My ideal setup is: 1. If a call comes into the queue, go to agent but don't ever go to voicemail (Just Dial(SIP/XXXX)) 2. If a call comes in for that same agent to their DID, route to stdexten macro 3. All calls routed w/ DUNDi so the system doesn't care about which server they log into -- Kyle Sexton http://www.mocker.org
On Tue, Sep 18, 2007 at 11:27:36AM -0500, Kyle Sexton wrote:> All, > > I'm trying to configure queue agents w/ a DUNDi setup so that an agent > can login to whatever server they please w/o any custom setup. In > general this seems to work, agents login w/ AgentCallbackLogin into the > incoming context (not a special queue context) and can receive queue > calls.Don't use AgentCallbackLogin() it's odd in some interesting ways (The whole agent stuff isn't very flexible in many ways if your users have multiple ways to get called outside of the Agent.) For example if you have users in queues represented as Agents with also direct numbers respresented as SIP/xxx elsewhere, you will have problems with call waiting and busy detection not working properly, i.e, when the user is making an outgoing call on their SIP extn, the agent stuff does not detect them as being busy, so you cannot use call waiting. An 'agent' can only accept one call at a time but SIP/xxx may have several calls. About your situation, you might be able to solve it by using "Local/xxx at context" to route the call to where you need it to go when a call comes in for an agent that you want to locate in the dialplan somewhere else. The thing you route to using "Dial(Local/xxx" must be something in the dialplan routable by the current context.) AgentCallbackLogin as I understand it, deprecated as of 1.4.x, and 1.2.x is no longer being actively developed, so I'm trying to get off it, however some stuff I do is not possible now without that feature that they don't seem all that concerned about fixing right now. :-( Rob -- Robert Lister - London Internet Exchange - http://www.linx.net/ sip:robl at linx.net - inoc-dba:5459*710 - tel: +44 (0)20 7645 3510