Summary:ASTERISK-03133: SIP Calls aren't destroyed
Reporter:Trevor Peirce (trev)Labels:
Date Opened:2004-12-29 15:58:29.000-0600Date Closed:2011-06-07 14:05:07
Versions:Frequency of
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.


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.


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.


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.