QUEUE transfer with SIP phone does not release agent

padair · September 9, 2005, 3:33pm

I have a small switchboard, 3 agents, servicing two call queues. The agents and the rest of the office use UIP200 Uniden Sip Phones. Whenever an agent recieves a call from one of the Queues, they can then transfer the call, blind or attended, but once done the agent status still shows them talking to the Zap channel upon which the call landed. This happens for SIP refer or PBX transfers. After the RTP timeout occurs agent status then shows the agent to be logged in on the extension to which they transferred the call. Whenever the call is ended everything returns to normal. Problem is the agent cannot take calls until this happens. Any help would be appreciated.

elmono_acosta · November 3, 2005, 11:27am

We have the same problem…have you found any workarround ???

bziherl · February 6, 2006, 4:36pm

And we’re having the same problem, using ZAP though. Any solutions yet?

padair · February 6, 2006, 4:56pm

Work around the “chan agent” module it is a dog. It creates psuedo channels and does not allow them to be transferred, for fear they may be optimized away in certain circumstances. I did this by creating my own agent login and logout macros. I use the add/removequemember function, to dynamically add and remove the agents. Mine was not too complex as I ended up tying the treatment of the queue to the extension, and therefore the user to the extension. If you would want to be more like a true “hot-desking” setup, a more complicated algoritim would be necesary. One cool thing about this setup was that attaching the agent directly to the queue made call distribution work much more efficiently. Chan agent screwed up more than just transferring. Using the penalty parameter in the addqueuemember command worked beutifully. Once I got this off the ground the system was stable and worked perfectly, hope this helps.

[macro-LOGIN]
exten => s,1,Answer
exten => s,2,Ringing
exten => s,3,GOTOIF($[${ARG1} = 1000]?7:4)
exten => s,4,GOTOIF($[${ARG1} = 1002]?12:5)
exten => s,5,GOTOIF($[${ARG1} = 1003]?17:6)
exten => s,6,Hangup

;-------------------------------------------------------------------

[macro-LOGOUT]
exten => s,1,Answer
exten => s,2,Ringing
exten => s,3,GOTOIF($[${ARG1} = 1000]?7:4)
exten => s,4,GOTOIF($[${ARG1} = 1002]?12:5)
exten => s,5,GOTOIF($[${ARG1} = 1003]?17:6)
exten => s,6,Hangup

exten => s,7,RemoveQueueMember(OPERATOR|SIP/1000)
exten => s,8,RemoveQueueMember(SCHED|SIP/1000)
exten => s,9,RemoveQueueMember(NURSE|SIP/1000)
exten => s,10,Playback(agent-loggedoff);
exten => s,11,Hangup

exten => s,12,RemoveQueueMember(OPERATOR|SIP/1002)
exten => s,13,RemoveQueueMember(SCHED|SIP/1002)
exten => s,14,RemoveQueueMember(NURSE|SIP/1002)
exten => s,15,Playback(agent-loggedoff);
exten => s,16,Hangup

exten => s,17,RemoveQueueMember(OPERATOR|SIP/1003)
exten => s,18,RemoveQueueMember(SCHED|SIP/1003)
exten => s,19,RemoveQueueMember(NURSE|SIP/1003)
exten => s,20,Playback(agent-loggedoff);
exten => s,21,Hangup

gventer · February 6, 2006, 5:36pm

Hmmm that looks interresting but can you explain a bit more why did it work better please? Are you not using “CHAN AGENTS” anymore?

Thanks

padair · February 6, 2006, 6:21pm

Adding a queue member creates an interface directly to the queue. The agent function is used by creating a member that is an Agent, not a phone. Agent allows hotdesking such that the agent/1 is assigned the extension that the person is logging in on. If you setup an interface in your queue.conf “member=Agent/1”, when a call comes in the queue transfers the call to the appropriate “member”. If this member is an agent, the call is transferred to “chan agent” module, then the module finds the agent wherever that agent logged in at, ie sip/1000. Going through agent this way screws everything up. Since I had assigned desks for call handlers, I used the previously published macro. This allowed them to log in and out as members of the queues not of “chan agent”. I had three people servicing three queues, all queues had an order to which the members would be called, hence the different penalties in all logins. This link explains and links more detail about the different functions.

voip-info.org/wiki/view/Asterisk+call+queues

padair · February 6, 2006, 6:25pm

Just a note on the above, I had no members in my queues.conf file. They were all added dynamically with the login macro.

bziherl · February 6, 2006, 9:10pm

Thanks padair for the help! I will try that out. I have just one more question:

Is there a way where an agent could transfer his/her call to someone else, using Asterisk Manager API?

padair · February 7, 2006, 3:06pm

I could not tell you anything about the manager API, sorry. I have no experience with that aspect of the application. I will say this though, I was told to drop the “chan agent” module by Digium support. They told me to try and work around it with the dynamic additions.

Good Luck

gventer · February 7, 2006, 4:21pm

Thank you Padair - that does make a lot more sense. Given all the problems I encountered with the chan agent as well I decided to write an AGI to handle queues which I have completed about 50% but I will give this a shot and see.

Bziherl:

I think you will still achieve this with the redirect Manager API call but I will ahve to test it.

bziherl · February 8, 2006, 12:30pm

Thanks for the answers. The solution that was suggested by padair in fact really works much better!

I have just one more question: I have my Asterisk configured so that it distributes the calls from the queue to the agents that are in fact connected to a legacy PBX (via E1 card).

The problem is when two of these agents talk to one another. The Asterisk would still think that they are free and distribute the calls to them, eventhough they in fact aren’t. Is there a workaround for that? The same problem is when one of these agents makes an outgoing call to the PSTN too.

padair · February 8, 2006, 6:28pm

I no longer have access to the system with which I did this. But if memory serves me, my issues cleared up substantially when I got rid of “chan agent”. This module assumed that if a call did not get sent to the agent by the module, the agent could not be on the phone. The exact cause, I do not know, but that was the jist of how it operated. The members being the phones, it seemed that the distribution happened much more quickly, and I did not see a phone get pounded by the queue over an over again when it was busy. ONE important setup I had was CALL WAITING DISABLED on agent extensions. I don’t think it will notify the queue that the line is busy if call waiting is enabled.