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

Asterisk Bug Tracker noreply at bugs.digium.com
Fri May 1 19:01:01 CDT 2009


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-01 19:01 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.

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

---------------------------------------------------------------------- 
 (0104052) madkins (reporter) - 2009-05-01 19:01
 http://bugs.digium.com/view.php?id=15014#c104052 
---------------------------------------------------------------------- 
so it's the do_timing call of ao2_callback w/run_timer as an argument that
does it, apparently run_timer is called (a lot) to return a match value and
each time it is called it writes a byte to a pipe that is (afaik) never
read from

just duplicated the behavior w/nat=no throughout so that was a red
herring

there's also a pile of messages at the end after it locks up that make it
look like a call is in some sort of progress:

[May  1 16:58:59] DEBUG[13588] res_timing_pthread.c: write_byte(11)
[May  1 16:58:59] DEBUG[13588] res_timing_pthread.c: done writing byte 11
(65533)
[May  1 16:58:59] DEBUG[13588] res_timing_pthread.c: write_byte(11)
[May  1 16:58:59] DEBUG[13588] res_timing_pthread.c: done writing byte 11
(65534)
[May  1 16:58:59] DEBUG[13588] res_timing_pthread.c: write_byte(11)
[May  1 16:58:59] DEBUG[13588] res_timing_pthread.c: done writing byte 11
(65535)
[May  1 16:58:59] DEBUG[13588] res_timing_pthread.c: write_byte(11)
[May  1 16:58:59] DEBUG[13588] res_timing_pthread.c: done writing byte 11
(65536)
[May  1 16:58:59] DEBUG[13588] res_timing_pthread.c: write_byte(11)
[May  1 16:59:05] DEBUG[13585] chan_sip.c: **** Received REGISTER (2) -
Command in SIP REGISTER
[May  1 16:59:05] DEBUG[13585] chan_sip.c: Trying to put 'SIP/2.0 20' onto
UDP socket destined for 10.104.230.40:5060
[May  1 16:59:05] DEBUG[13582] devicestate.c: No provider found, checking
channel drivers for SIP - Batman
[May  1 16:59:05] DEBUG[13582] chan_sip.c: Checking device state for peer
Batman
[May  1 16:59:05] DEBUG[13582] devicestate.c: Changing state for
SIP/Batman - state 1 (Not in use)
[May  1 16:59:05] DEBUG[13582] devicestate.c: device 'SIP/Batman' state
'1'
[May  1 16:59:17] DEBUG[13585] acl.c: Found IP address for this socket
[May  1 16:59:17] VERBOSE[13585] netsock.c:   == Using SIP RTP CoS mark 5
[May  1 16:59:17] DEBUG[13585] chan_sip.c: Setting NAT on RTP to Off
[May  1 16:59:17] DEBUG[13585] chan_sip.c: Allocating new SIP dialog for
837895375 at 10.104.230.41 - INVITE (With RTP)
[May  1 16:59:17] DEBUG[13585] chan_sip.c: **** Received INVITE (5) -
Command in SIP INVITE
[May  1 16:59:17] DEBUG[13585] chan_sip.c: Setting NAT on RTP to Off
[May  1 16:59:17] DEBUG[13585] chan_sip.c: Trying to put 'SIP/2.0 40' onto
UDP socket destined for 10.104.230.41:5060
[May  1 16:59:17] DEBUG[13585] chan_sip.c: **** Received ACK (6) - Command
in SIP ACK
[May  1 16:59:17] DEBUG[13585] chan_sip.c: Stopping retransmission on
'837895375 at 10.104.230.41' of Response 1: Match Found
[May  1 16:59:17] DEBUG[13585] chan_sip.c: **** Received INVITE (5) -
Command in SIP INVITE
[May  1 16:59:17] DEBUG[13585] chan_sip.c: Setting NAT on RTP to Off
[May  1 16:59:17] DEBUG[13585] chan_sip.c: We're settling with these
formats: 0xc (ulaw|alaw)
[May  1 16:59:17] DEBUG[13585] chan_sip.c: Checking SIP call limits for
device Robin
[May  1 16:59:17] DEBUG[13585] chan_sip.c: Updating call counter for
incoming call
[May  1 16:59:17] DEBUG[13585] res_timing_pthread.c: pthread_timer_open()
[May  1 16:59:17] DEBUG[13585] res_timing_pthread.c: pipes:  19/20 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-01 19:01 madkins        Note Added: 0104052                          
======================================================================




More information about the asterisk-bugs mailing list