Summary:	ASTERISK-06266: SIP transfers of queued calls doesn't make agent available neighter makes new agent busy
Reporter:	Amilcar S Silvestre (amilcar)	Labels:
Date Opened:	2006-02-07 07:39:21.000-0600	Date Closed:	2006-05-31 08:55:30
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	SIP transfers of calls that are answered out of a queue (with or without 't' option) result in the Agent remaining affiliated with the call until its eventual termination, preventing that agent from being offered another call AND makes Asterisk keeps offering another calls to Agent that was taken the transfered call. Asterisk '#' transfers (enabled with the 't' option) works fine.
Comments:	By: Olle Johansson (oej) 2006-03-04 17:05:22.000-0600 So a SIP REFER of the call away from the agent does not free the agent? Interesting. That's an interesting dilemma to solve. By: Fernando Romo (el_pop) 2006-03-10 18:39:54.000-0600 Is anoing... Is problem of the chan_sip or app_queue? In a call center with Sip Softphone the ACD agent receive one call, and seconds later appear another call (The agent is alredy busy) and make the abandon rate grow. I notice this in all recent versions of Asterisk 1.2.x and Trunk. Let me try with IAX and see the results By: Tilghman Lesher (tilghman) 2006-03-11 09:36:28.000-0600 el_pop:  your issue is different:  you need to have call-limit set to 1 for your agent in sip.conf. By: Amilcar S Silvestre (amilcar) 2006-03-21 08:11:28.000-0600 oej, can this dilemma be solved by the new SIP TRANSFER code (/team/oej/siptransfer/)? By: Serge Vecher (serge-v) 2006-05-04 16:47:23 amilcar: why don't you try the code for yourself? By: BJ Weschke (bweschke) 2006-05-08 09:42:47 I've seen this behavior when the SIP UA is not on the same machine as to where the queue is running, and the reason for this is because we don't have device state change notification going from one machine to the other to tell them that the original endpoint (before the transfer) is no longer part of the call (that is still up after the transfer). I've not seen this though when the SIP UA is on the same machine as to where the queue is running. There, the device state notification is coming back and the agent is freed. What condition are you having? If it's the SIP UA and queue are on the same machine, we need more info as to your dial plan and DEBUG VERBOSE traces to see what's going on. By: Serge Vecher (serge-v) 2006-05-23 16:14:46 is this an issue in 1.2.7.1? By: Serge Vecher (serge-v) 2006-05-31 08:55:29 Please feel free to reopen, if this is an issue in 1.2.8 and you have debugging information available as per bweschke. Thank you.