Summary:	ASTERISK-17521: When transferring a call using the REFER command with replaces enabled, Asterisk drops the call.
Reporter:	Louis Carreiro (ltc)	Labels:
Date Opened:	2011-03-07 14:10:02.000-0600	Date Closed:	2011-06-07 14:04:49
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:	1.8.3	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) AsteriskDebug.txt
Description:	When transferring a call using the REFER command with replaces enabled, Asterisk drops the call with "SIP/2.0 481 Call leg/transaction does not exist". I have tried performing this on 1.4 SVN, 1.8.3, Trunk SVN 309404, and 1.8 SVN 309808. All have produced the same result. I have attached the debug logs with core and sip debugging on. Unfortunately I do not have a way to perform a successful transfer with REFER to compare against. Line 432 is where the REFER starts. Chan_sip.c starts to process the REFER but then later drops it on line 538 with the "SIP/2.0 481 Call leg/transaction does not exist".
Comments:	By: David Woolley (davidw) 2011-03-08 06:14:21.000-0600 Either that trace is incomplete, or Asterisk is correctly rejecting the REFER.  There is no previous instance of 21756586-526e-452e-ba52-d404e9d9781e in the trace. Could you possibly be trying to use Asterisk as a proxy, rather than a back to back user agent? REFER does work when done properly. By: Louis Carreiro (ltc) 2011-03-08 07:16:17.000-0600 The only part of the trace that was excluded was the initial phone call. Debugging was turned on after the call was established. I can post the entire log if requested. In this trace, the call was initiated by an extension on Asterisk (ext 1820) to extension 1173 on another IP-PBX. Once the call is established, extension 1173 then attempts to transfer the call to another extension (1265) on the same PBX. The REFER message is notifying Asterisk and 1820 that the transfer is to take place and that 1820 should now contact 1265. The problem also occurs if extension 1173 initiates the phone call and then transfers. In the debug I see the transferor sending the Replaces header field in the Refer-to header but it appears that Asterisk is trying to bridge channels together instead of sending the invite to the target. By: David Woolley (davidw) 2011-03-08 07:18:46.000-0600 Asterisk will try and bridge channels together.  It is a back to back user agent, not a proxy. As I said, the trace shows a REFER which is trying to replace a call which is not present in the trace. You need to provide a trace that includes the call leg that is being replaced for the bug report to possibly be valid. By: David Woolley (davidw) 2011-03-08 08:57:41.000-0600 Incidentally, as far as I can tell, Asterisk didn't drop the call; the phone dropped it when told its transfer had failed. By: Leif Madsen (lmadsen) 2011-04-14 10:24:35 Closed per davidw's analysis.