[svn-commits] mmichelson: branch 1.6.2 r194510 - in /branches/1.6.2: ./ channels/chan_sip.c

[SVN commits to the Digium repositories]

Author: mmichelson
Date: Thu May 14 17:23:54 2009
New Revision: 194510

URL: http://svn.asterisk.org/svn-view/asterisk?view=rev&rev=194510
Log:
Merged revisions 194496 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

................
  r194496 | mmichelson | 2009-05-14 17:20:51 -0500 (Thu, 14 May 2009) | 30 lines
  
  Merged revisions 194484 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4
  
  ........
    r194484 | mmichelson | 2009-05-14 17:17:55 -0500 (Thu, 14 May 2009) | 24 lines
    
    Fix a race condition where a reinvite could trigger a 482 response.
    
    The loop detection/spiral detection code in chan_sip used the owner
    channel's state as a criterion for determining if the incoming INVITE
    is a looped request. The problem with this is that the INVITE-handling
    code happens in a different thread than the thread that marks the owner
    channel as being up. As a result, if a reinvite were to come in very quickly,
    say from another Asterisk on the same LAN, it was possible for the reinvite
    to arrive before the owner channel had been set to the up state.
    
    This patch corrects the problem by using the invitestate of the sip_pvt
    instead, since that can be guaranteed to be set correctly by the time
    the reinvite arrives. Since there is a switch statement further in the
    INVITE-handling code, the AST_STATE_RINGING state also checks the invitestate
    of the sip_pvt in case we should actually be treating the channel as if it were
    up already.
    
    (closes issue #12215)
    Reported by: jpyle
    Patches:
          12215_confirmed.patch uploaded by mmichelson (license 60)
    Tested by: lmadsen
  ........
................

Modified:
    branches/1.6.2/   (props changed)
    branches/1.6.2/channels/chan_sip.c

Propchange: branches/1.6.2/
------------------------------------------------------------------------------
Binary property 'trunk-merged' - no diff available.

Modified: branches/1.6.2/channels/chan_sip.c
URL: http://svn.asterisk.org/svn-view/asterisk/branches/1.6.2/channels/chan_sip.c?view=diff&rev=194510&r1=194509&r2=194510
==============================================================================
--- branches/1.6.2/channels/chan_sip.c (original)
+++ branches/1.6.2/channels/chan_sip.c Thu May 14 17:23:54 2009
@@ -18737,7 +18737,7 @@
 	p->reqsipoptions = required_profile;
 
 	/* Check if this is a loop */
-	if (ast_test_flag(&p->flags[0], SIP_OUTGOING) && p->owner && (p->owner->_state != AST_STATE_UP)) {
+	if (ast_test_flag(&p->flags[0], SIP_OUTGOING) && p->owner && (p->invitestate != INV_TERMINATED && p->invitestate != INV_CONFIRMED)) {
 		/* This is a call to ourself.  Send ourselves an error code and stop
 	   	processing immediately, as SIP really has no good mechanism for
 	   	being able to call yourself */
@@ -19321,9 +19321,21 @@
 			p->invitestate = INV_PROCEEDING;
 			break;
 		case AST_STATE_RINGING:
-			transmit_response(p, "180 Ringing", req);
-			p->invitestate = INV_PROCEEDING;
-			break;
+			if (reinvite && (p->invitestate == INV_TERMINATED || p->invitestate == INV_CONFIRMED)) {
+			/* If these conditions are true, and the channel is still in the 'ringing'
+			 * state, then this likely means that we have a situation where the initial
+			 * INVITE transaction has completed *but* the channel's state has not yet been
+			 * changed to UP. The reason this could happen is if the reinvite is received
+			 * on the SIP socket prior to an application calling ast_read on this channel
+			 * to read the answer frame we earlier queued on it. In this case, the reinvite
+			 * is completely legitimate so we need to handle this the same as if the channel 
+			 * were already UP. Thus we are purposely falling through to the AST_STATE_UP case.
+			 */
+			} else {
+				transmit_response(p, "180 Ringing", req);
+				p->invitestate = INV_PROCEEDING;
+				break;
+			}
 		case AST_STATE_UP:
 			ast_debug(2, "%s: This call is UP.... \n", c->name);