|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|
|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|
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
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: 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.
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 starts attended xfer to C
B completes transfer of A to C
any hint monitoring extensions still see B as busy
B will show InUse
D calls B and hangs up (or waits for B to answer and then hangs up)
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.
By: Olle Johansson (oej) 2007-02-02 09:29:16.000-0600
thanks for testing so fast!