[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-04 17:54 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.

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

---------------------------------------------------------------------- 
 (0104176) madkins (reporter) - 2009-05-04 17:54
 http://bugs.digium.com/view.php?id=15014#c104176 
---------------------------------------------------------------------- 
No, that doesn't help.

This thing gets more and more twisted.  I'm seeing different behavior on
two different systems.  Both are running Debian 4.  I've downloaded source
for 1.6.1.0 and built per normal directions on both.

On my desktop, running 32-bit D4, I don't see the problem.  On the server,
running 64-bit D4, it is easily repeatable.

Right now it's looking like the order of loading of modules chan_iax2.so
and res_timing_pthread.so is changing the behavior between the two.  If
res_timing_pthread.so is loaded first then it is possible for chan_iax2.so
to add itself to the existing timing thread, otherwise it can't happen. 
When it adds to the existing timing thread (which happens on our server but
not my desktop) the timing thread fires repeatedly until the pipe is filled
up.

More questions to answer, I suppose. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-04 17:54 madkins        Note Added: 0104176                          
======================================================================