[asterisk-bugs] [Asterisk 0015213]: asterisk lock in sipsock_read for several seconds and drop sip packets

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15213 
====================================================================== 
Reported By:                schmidts
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15213
Category:                   Channels/chan_sip/General
Reproducibility:            random
Severity:                   block
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.25 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-05-28 09:47 CDT
Last Modified:              2009-06-17 23:27 CDT
====================================================================== 
Summary:                    asterisk lock in sipsock_read for several seconds
and drop sip packets
Description: 
i have around 1600 sip peers registered on this server with 2 sip trunks to
other asterisk server and after upgrading to 1.4 from 1.2 i had this
problem that the asterisk freeze for several seconds and drop all sip
packets.

with netstat -su i see that the amount of packet receive errors increase
by 800 pps while asterisk locks.

normal callflow actions like mysql and so on runs without any problem and
also active calls are not disconnected but new calls cant be opened.

i ve compiled with debug thread and dont optimize and see with core show
lock these lock helds:

=======================================================================
=== Currently Held Locks ==============================================
=======================================================================
===
=== <file> <line num> <function> <lock name> <lock addr> (times locked)
===
=== Thread ID: 1092675920 (do_monitor           started at [16595]
chan_sip.c restart_monitor())
=== ---> Lock https://issues.asterisk.org/view.php?id=0 (chan_sip.c): MUTEX
16264 sipsock_read &netlock
0x7f6d0e9d0700 (1)
=== -------------------------------------------------------------------
===
=======================================================================

and when it run again it show this: 

=======================================================================
=== Currently Held Locks ==============================================
=======================================================================
===
=== <file> <line num> <function> <lock name> <lock addr> (times locked)
===
=== Thread ID: 1092675920 (do_monitor           started at [16595]
chan_sip.c restart_monitor())
=== ---> Lock https://issues.asterisk.org/view.php?id=0 (chan_sip.c): MUTEX
16264 sipsock_read &netlock
0x7f6d0e9d0700 (1)
=== ---> Lock https://issues.asterisk.org/view.php?id=1 (chan_sip.c): MUTEX 4728
find_call &p->lock 0x374ffd0
(1)
=== ---> Lock https://issues.asterisk.org/view.php?id=2 (sched.c): MUTEX 220
ast_sched_add_variable &con->lock
0x1b2eee0 (1)
=== -------------------------------------------------------------------
===
=======================================================================

the system is a HP proliant DL 380 G5 2xXeon 2,3 Ghz with 6 GB Ram
OS: Debian Lenny v. 5.0.1 AMD 64 Bit Kernel 2.6.26-1
Asterisk version: 1.4.25
zaptel 1.4.12.1 is only need for meetme cause there is no isdn hardware in
this server.
libpri 1.4.10

i´ve allready tried to increase the linux udp buffer but without sucess.

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

---------------------------------------------------------------------- 
 (0106602) aragon (reporter) - 2009-06-17 23:27
 https://issues.asterisk.org/view.php?id=15213#c106602 
---------------------------------------------------------------------- 
Possibly related to tis revision?
I only began seeing this issue in 1.4.25, it did not occur in 1.4.24.1

2009-05-28 15:27 +0000 [r197588] Mark Michelson <mmichelson at digium.com>

    * main/rtp.c, channels/chan_sip.c, include/asterisk/rtp.h: Allow
      for media to arrive from an alternate source when responding to a
      reinvite with 491. When we receive a SIP reinvite, it is possible
      that we may not be able to process the reinvite immediately since
      we have also sent a reinvite out ourselves. The problem is that
      whoever sent us the reinvite may have also sent a reinvite out to
      another party, and that reinvite may have succeeded. As a result,
      even though we are not going to accept the reinvite we just
      received, it is important for us to not have problems if we
      suddenly start receiving RTP from a new source. The fix for this
      is to grab the media source information from the SDP of the
      reinvite that we receive. This information is passed to the RTP
      layer so that it will know about the alternate source for media.
      Review: https://reviewboard.asterisk.org/r/252 [^] 

I must concur with jvandal on his note
https://issues.asterisk.org/view.php?id=15213#105717
jvandal (reporter)
2009-05-29 10:28

	If I check on my server, the working revision for is r197562 but fail
with r197588

-ASTERISK_FILE_VERSION(__FILE__, "$Revision: 197562M $")
+ASTERISK_FILE_VERSION(__FILE__, "$Revision: 197588M $") 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-17 23:27 aragon         Note Added: 0106602                          
======================================================================