Summary:	ASTERISK-03133: SIP Calls aren't destroyed
Reporter:	Trevor Peirce (trev)	Labels:
Date Opened:	2004-12-29 15:58:29.000-0600	Date Closed:	2011-06-07 14:05:07
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) console.txt ( 1) gdb.txt
Description:	Any call is placed and will comlete properly.  On the conclusion of the call, it seems to stick around in * forever until a killall -9 asterisk is run.  stop now doesn't work, but most other commands do. ****** ADDITIONAL INFORMATION ****** Attached is console verbose output and a backtrace.  I've cut down on the console output as I have a lengthly macro that checks for various things before a call is completed.  The problem seems to exist whether I bypass these checks or not. This is the the steps I took to create the backtrace: User A dials User B User A hears Ringing User B's phone rings User A hangs up User B's phone stops ringing Asterisk still keeps User A and User B's call in the system. It doesn't matter if the call is answered or not, it's just left there to rot when the conversation is over.
Comments:	By: Trevor Peirce (trev) 2004-12-29 16:01:55.000-0600 This should have been in console.txt after the call had ended. *CLI> show channels Dec 29 14:01:29 WARNING[12842]: channel.c:471 ast_channel_walk_locked: Avoided initial deadlock for 'SIP/bizname703-552c', 10 retries!        Channel  (Context    Extension    Pri )   State Appl.         Data 0 active channel(s) edited on: 12-29-04 16:03 By: Brian West (bkw918) 2004-12-29 16:02:39.000-0600 thats not all that is wrong its deadlocking.. this is a known issue.  We have all been looking at it most of the day. remove cdr_addon_mysql.so from the mix and try to narrow it down a bit. bkw By: Trevor Peirce (trev) 2004-12-29 16:10:03.000-0600 You know what... problem solved when I removed that file. Guess it's a bug with cdr_addon_mysql By: Brian West (bkw918) 2004-12-29 16:48:38.000-0600 well a deadlock in sip is still there but you may not be hitting that as often... keep an eye on it. bkw By: Mark Spencer (markster) 2004-12-29 17:24:14.000-0600 Clearly the backtrace indicates this is related to MySQL.  Please disable mysql logging and see if you can still duplicate the problem.  Thanks. By: Trevor Peirce (trev) 2004-12-29 18:21:02.000-0600 So.... cdr_addon_mysql - it hasn't changed but now it's broken.  Is this something to do with the addon, asterisk, or mysql? I've received and placed a couple dozen calls without the mysql CDRs and all seems well now.  I would like to have this fixed so I'm for hoping some pointers on where to go from here. By: Mark Spencer (markster) 2004-12-29 18:27:08.000-0600 The obvious first thing is to rebuild the addons having rebuilt asterisk.  If internal structures in asterisk change, they can require a recompile of the external module even if it hasn't changed itself. By: Trevor Peirce (trev) 2004-12-29 18:38:01.000-0600 Yes I thought about that and had tried a make clean; make; make install in the asterisk-addons folder... still the problems return... and cease when I delete cdr_addon_mysql.so By: Mark Spencer (markster) 2004-12-29 18:39:55.000-0600 Perhaps it is a configuration issue related to cdr_mysql or a change in the version of MySQL libraries and/or server? Whatever it is, it seems pretty clear it's buried deep in MySQL, so I'm increasingly not of the opinion that this is an asterisk bug. By: Trevor Peirce (trev) 2004-12-29 19:18:48.000-0600 Thanks markster.  It was a change in MySQL.  Someone (now the fun part to find out who) updated some RPMs on me.  I backed up to the mysql RPMs I know work and cdr_addon_mysql.so happily functions and writes CDRs again, without screwing up SIP calls. Is there any way problems like this can be handled a little more gracefully?  Seems like a royal PITA to discover the fairly trivial source of this. By: Trevor Peirce (trev) 2004-12-29 19:21:50.000-0600 Spoke too soon... still is a problem.  It must be a change in asterisk that affects the way cdr_addon_mysql works.  Am now using the same MySQL that we've been using (yes recompiled asterisk-addons). By: Mark Spencer (markster) 2004-12-29 19:22:37.000-0600 Unfortunately, given this is happening deep in a library, gdb was the way to find it.  Now you know what to look for in the future! By: Trevor Peirce (trev) 2004-12-29 19:24:14.000-0600 I will add that I am using realtime successfully for sipfriends and voicemail via ODBC to the same MySQL database.  That end of things is working fine.