Summary:	ASTERISK-07580: Attended SIP Transfer Call Teardown Issue
Reporter:	Curt Moore (jcmoore)	Labels:
Date Opened:	2006-08-22 20:45:40	Date Closed:	2011-05-27 10:45:09
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 7784_patched.pcap ( 1) 7784_unpatched.pcap ( 2) full_patched_server_a.txt ( 3) full_patched_server_b.txt ( 4) full_server_a_200609201121.txt ( 5) full_server_b_200609201121.txt ( 6) full_unpatched_server_a.txt ( 7) full_unpatched_server_b.txt ( 8) sip_attended_xfer_patch.diff.txt
Description:	When attempting an attended SIP transfer which spans multilple Asterisk servers, ie. INVITE w/ Replaces, the call on one of the phones does not receive a BYE.   For example, in a call scenario from A->B->C, where A calls B, B then attended transfers the call to C, the call on B is present even after the call between A and C has been bridged.  The audio is correctly bridged between A and C, there is no audio on B. The issue is that instead of deferring the BYE, as is currently being done in handle_invite_replaces(), the BYE needs to proceed as normal so the call on B will hangup while preserving the sip_pvt structure so that the INVITE w/ Replaces can have a basis from which to create the new outbound INVITE. ****** ADDITIONAL INFORMATION ****** The attached patch is the way OEJ originally handled the SIP transfer code when he was developing this for the 1.2 branch.  Instead of deferring the BYE, the BYE was sent as normal and the sip_pvt structure was kept around so that the outbound INVITE could be created. There could be, and probably is, a better way of doing this in trunk/1.4, if so, please modify this patch accordingly. This patch also removes a duplicate prototype for handle_invite_replaces(). OEJ/Others: If you need further information, please let me know.
Comments:	By: Serge Vecher (serge-v) 2006-09-06 12:46:22 tgrman: can you please enable SIP debug enabled and show the difference in call-flows with with and without your patch. By: Curt Moore (jcmoore) 2006-09-07 14:07:53 I have attached 2 PCAP captures of the associated SIP call flows, 1 with the patch and 1 without the patch.   If you use the Statistics->VoIP Calls->Graph option in Ethereal/Wireshark on each of the captures and compare them side by side, it's pretty clear what is going on and where the BYE is missing in the unpatched capture. I can get the requested Asterisk SIP debug information but it's much easier to see what's going on in this instance if you use the SIP ladder diagram in Ethereal/Wireshark, for me at least. Please let me know if further information is needed. By: Serge Vecher (serge-v) 2006-09-07 14:23:40 tgrman: these are helpful, but a SIP debug contains information that helps a developer navigate more than half-a-meg of C code. So, please do produce those sip debugs. Thanks. By: Curt Moore (jcmoore) 2006-09-07 15:25:14 I have attached a bzip file containing the debug information from both Asterisk servers involved in the attended transfer.  Since this bug involves an attended SIP transfer between 2 different Asterisk servers, it's necessary to look at the logfiles from both servers to see how chan_sip is handling the INVITE w/ Replaces. By: Serge Vecher (serge-v) 2006-09-07 15:40:13 thanks, tgrman, I moved files out of the archive for ease of review. Moving to acknowledged. By: Olle Johansson (oej) 2006-09-08 11:14:02 I can confirm there's an issue here I'm trying to solve in various ways since my original patch wasn't approved by higher authorities... By: Olle Johansson (oej) 2006-09-09 08:45:36 Please try again with latest svn trunk. Thanks. By: Curt Moore (jcmoore) 2006-09-14 13:46:31 I'm still seeing the same behavior even with the latest SVN trunk, r42929.  The call on B is still there after B completes the attended transfer of A to C.  As before, the audio is fine between A and C. Let me know if any further debug info is needed. By: Serge Vecher (serge-v) 2006-09-18 09:03:02 tgrman: please go ahead and produce a new SIP debug from a fresh SVN trunk installation. Thanks. By: Curt Moore (jcmoore) 2006-09-20 11:25:59 As requested I have attached updated logfiles using the latest SVN trunk, r43322.  The logfiles are full_server_a_200609201121.txt and full_server_b_200609201121.txt. Please let me know if further information is needed. By: jmls (jmls) 2006-11-01 06:48:13.000-0600 oej, were you able to solve this issue ? By: Anthony LaMantia (alamantia) 2006-11-09 11:40:47.000-0600 tgrman, is this issue still effecting you using the latest 1.2svn release? By: Curt Moore (jcmoore) 2006-11-09 12:15:01.000-0600 alamantia: oej's code for attended SIP transfers is not in SVN-1.2, this is a 1.4/trunk issue only. Unless oej has committed something that fixes this, then it is still happening in 1.4/trunk.  I'm running my modifiations in the patch I submitted so I personally am not seeing the issue. I will test to see if it is still happening in 1.4 By: Olle Johansson (oej) 2006-11-12 14:58:11.000-0600 Please check with latest trunk version. Thanks. By: Serge Vecher (serge-v) 2007-01-09 12:59:36.000-0600 tgrman: if you are able to reproduce this with the latest trunk and without your mods, please reopen the bug with a new debug log attached. Thanks.