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);