Summary:	ASTERISK-08505: 1.4.0 has teardown/hangup issues after attended transfer
Reporter:	James Brindle (jamesb63)	Labels:
Date Opened:	2007-01-06 13:52:52.000-0600	Date Closed:	2007-02-02 09:29:27.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) chan_sip_diff.txt ( 1) verbosedebug.txt ( 2) verbosedebug-r52904m.txt
Description:	This may still be in progress, however, all searches point to version of 1.2 but this problem is definitely in 1.4.0 Scenario: SIP/1000 places call to SIP/1001 SIP/1001 performs attended transfer to SIP/1002 SIP/1001 appears to be removed from the call and the two are connected together. SIP/1002 hangs up SIP/1000 is disconnected CLI> show hints (this is how I found the problem) shows that SIP/1001 is still marked as "InUse" If "call-limit" is 1 so that users on any type of call show an inuse status, no calls can be placed to SIP/1001 and SIP/1001 cannot make any calls - only resolution, restart asterisk. If "call-limit" is not set, calling SIP/1001 and then hanging up clears the state. This problem occurs no matter the device type or if the call originates from an internal SIP device or from our external SIP provider. This is always reproducible ****** ADDITIONAL INFORMATION ****** Asterisk 1.4.0 in a data centre on public IP address All sip devices are behind firewalls so "nat=yes" in sip.conf
Comments:	By: Olle Johansson (oej) 2007-01-08 02:47:58.000-0600 Ok, seems like we do not release the inuse counter at transfer. By: James Brindle (jamesb63) 2007-01-08 03:07:17.000-0600 Excellent, I was hoping it wasn't going to be such a biggie. By: Serge Vecher (serge-v) 2007-01-08 13:56:25.000-0600 Can you please produce a SIP debug trace illustrating the problem with 1.4 code checked out from the svn as per following: 1) Prepare test environment (reduce the amount of unrelated traffic on the server); 2) Make sure your logger.conf has the following line:   console => notice,warning,error,debug 3) restart Asterisk with the following command:   'asterisk -Tvvvvvdddddngc | tee /tmp/verbosedebug.txt' 4) Enable SIP transaction logging with the following CLI commands: set debug 4 set verbose 4 sip debug 5) Trim startup information and attach verbosedebug.txt to the issue By: James Brindle (jamesb63) 2007-01-10 03:35:34.000-0600 Just a quick update: This machine is not production yet, there are a few of us working on preparing it for an upcoming deployment when we spotted the issue and reported it. Have now successfully got SVN version r50186 running and will produce the required debug logs shortly. By: James Brindle (jamesb63) 2007-01-10 04:34:29.000-0600 Slight problem, after installing 1.4-r50186, can't place calls to any extension on the system, have temporarily reverted to 1.4.0 release version. When placing a call keep getting the following message: *CLI> [Jan 10 10:34:02] NOTICE[29230]: chan_sip.c:13534 handle_request_invite: Unable to create/find SIP channel for this INVITE By: Serge Vecher (serge-v) 2007-01-10 10:38:33.000-0600 ok, please try to produce those logs -- if we can't get the logs, then we can't fix the problem. We need your help. By: James Brindle (jamesb63) 2007-01-10 13:21:00.000-0600 Debug log added as requested, this is from the release version of 1.4.0 as for some reason I cannot get any of the SVN branches to accept or place call at present. Let me know if there's anything else I can do. By: Serge Vecher (serge-v) 2007-01-10 15:09:02.000-0600 james, thanks; this should be sufficient for this issue. If you will, please open a new report with a debug as per instructions here so that we can diagnose those problems with placing calls in the latest 1.4 branch. By: James Brindle (jamesb63) 2007-01-11 02:55:15.000-0600 Will do, thanks, please let me know when there's a patch I can try or if there's anything further I can do. I'll download the latest branch again before trying as it'll be tomorrow before I can test it. Thanks By: Serge Vecher (serge-v) 2007-01-11 08:44:35.000-0600 File just posted the following in other transfer bug reports for 1.4. Can you please give 1.4 as of revision 50468 a try? Thanks! By: Curt Moore (jcmoore) 2007-01-30 10:46:40.000-0600 Could this be related to 7784?  I'm still seeing this behavior as of 1.4 r52859.  What I've found is that the call to set the SIP_DEFER_BYE_ON_TRANSFER flag in handle_invite_replaces() is not needed. If A calls B, then B attempts an attended transfer of A to C, after the call is up between A and C, the call leg from B to C is still showing on B. If the SIP_DEFER_BYE_ON_TRANSFER flag is not set, the call between A and C is setup and the call between B and C is successfully torn down. I've attached a diff which removes this call to set SIP_DEFER_BYE_ON_TRANSFER, chan_sip_diff.txt. By: James Brindle (jamesb63) 2007-01-30 12:56:19.000-0600 Have tried applying the chan_sip_diff.txt patch to both the standard 1.4 and 1.4r52904m branches and no success. Have attached appropriate debug log using r52904m. In the debug log i've done a couple of "show hints" commands as well A calls B B answers B starts attended xfer to C C answers B completes transfer of A to C any hint monitoring extensions still see B as busy show hints B will show InUse D calls B and hangs up (or waits for B to answer and then hangs up) show hints B will show Idle In the debug log, I called x1110 from x1001 and transferred call to x1003, call completes fine but x1110 still shows as inuse. Just throwing some possibilities out there: Is there not some function like decrement_inuse_counter that can be called at the completion of the transfer? If we're in that part of chan_sip.c at the time, can we do something manual there? Strange how calling the 'stuck' extension and hanging up clears it, you'd think it's counter would incrememt and then decrement leaving at its original status. By: Olle Johansson (oej) 2007-02-01 16:07:32.000-0600 Please test with latest 1.4 from subversion. THanks. By: James Brindle (jamesb63) 2007-02-02 07:28:14.000-0600 As of r53109 this issue appears to be resolved. A calls to B B answers and places A on hold and calls C B completes attended transfer to C A and C are joined B hangs up successfully A second or so later, the notify events appear on the console for changing the status of B back to Idle. After A and C are done, the notify events appear on the console clearing them both back down to Idle. Thank you very much. James By: Olle Johansson (oej) 2007-02-02 09:29:16.000-0600 thanks for testing so fast!