[asterisk-bugs] [Asterisk 0015014]: Asterisk loses SIP phones, possible deadlock, 1.6.1.0

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=15014 
====================================================================== 
Reported By:                madkins
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15014
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.1.0 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-05-01 11:03 CDT
Last Modified:              2009-05-05 11:37 CDT
====================================================================== 
Summary:                    Asterisk loses SIP phones, possible deadlock,
1.6.1.0
Description: 
I have two Cisco 7905g SIP phones connected to an Asterisk 1.6.1.0 instance
running on a 64 bit Xen instance of Debian 4.0.  My initial configuration
was more complex, but I've removed a lot of the complexity searching for
the problem.

Basically, I can start the Asterisk server and pick up a SIP phone and
call either a test extension or the other phone.  Works fine.  If I leave
it alone for a time ... say over a long lunch or overnight ... I come back
and the phones won't connect to Asterisk.

This repeats reliably but at unknown intervals.

====================================================================== 

---------------------------------------------------------------------- 
 (0104231) madkins (reporter) - 2009-05-05 11:37
 http://bugs.digium.com/view.php?id=15014#c104231 
---------------------------------------------------------------------- 
yup, setting 'preload => res_timing_pthread.so' in modules.conf causes the
problem i've been having on the server to replicate on the desktop

without the specific ordering the problem won't occur, so i'm thinking
that perhaps this issue has been around all along but never showed up
before due to the directory ordering being different on different
platforms

to summarize, in modules.conf use:

[modules]
autoload=yes
preload => res_timing_pthread.so

and eventually the chan_iax2.so timer will fill up its outgoing thread,
unless (presumably) one actually has IAX communication

to fix, in modules.conf use:

noload => chan_iax2.so 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-05 11:37 madkins        Note Added: 0104231                          
======================================================================