[asterisk-bugs] [Asterisk 0015345]: SIP deadlock in 1.4 revision 199472

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15345 
====================================================================== 
Reported By:                aragon
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15345
Category:                   Channels/chan_sip/General
Reproducibility:            random
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.26-rc1 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 199472 
Request Review:              
====================================================================== 
Date Submitted:             2009-06-17 13:11 CDT
Last Modified:              2009-06-17 23:23 CDT
====================================================================== 
Summary:                    SIP deadlock in 1.4 revision 199472
Description: 
After some brief time SIP will lock and no calls will process.
====================================================================== 

---------------------------------------------------------------------- 
 (0106599) aragon (reporter) - 2009-06-17 23:23
 https://issues.asterisk.org/view.php?id=15345#c106599 
---------------------------------------------------------------------- 
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 

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