Index: channels/chan_sip.c
===================================================================
--- channels/chan_sip.c	(revision 179461)
+++ channels/chan_sip.c	(working copy)
@@ -14333,7 +14333,7 @@
 	}
 
 	/* 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->invitestate != INV_TERMINATED) {
 		/* 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 */
@@ -14748,9 +14748,22 @@
 			p->invitestate = INV_PROCEEDING;
 			break;
 		case AST_STATE_RINGING:
-			transmit_response(p, "180 Ringing", req);
-			p->invitestate = INV_PROCEEDING;
-			break;
+			/* 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.
+			 */
+			if (reinvite && p->invitestate == INV_TERMINATED) {
+				/* Don't do anything. Fall through to the AST_STATE_UP case */
+			} else {
+				transmit_response(p, "180 Ringing", req);
+				p->invitestate = INV_PROCEEDING;
+				break;
+			}
 		case AST_STATE_UP:
 			if (option_debug > 1)
 				ast_log(LOG_DEBUG, "%s: This call is UP.... \n", c->name);