Add extra protection for reinvite glare scenario.

Testing proved that if Asterisk sent a connected line reinvite, and
the endpoint to which the reinvite were being sent sent a reinvite, Asterisk
would not properly respond with a 491 response.

The reason is that on connected line reinvites, we set the dialog's invitestate
to INV_CALLING to prevent Asterisk from sending a rapid flurry of connected line
reinvites. For other reinvites we do not do this. Because of the current invitestate,
when Asterisk received the reinvite, we interpreted this as a spiraled INVITE, and thus
did not behave properly.

The fix for this is to not enter the loop detection or spiral logic in handle_request_invite
if the channel state is currently up. This way, no mid-call reinvites will be misinterpreted,
no matter what the nature of the reinvite may have been.

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272090 65c4cc65-6c06-0410-ace0-fbb531ad65f3

diff --git a/channels/chan_sip.c b/channels/chan_sip.c
index fa03d9c43b97c70453f32705531f4aacdc189ce1..b3bf2cd017278f6d370cab357a65e479e27fec0f 100644 (file)
--- a/channels/chan_sip.c
+++ b/channels/chan_sip.c
@@ -20508,7 +20508,7 @@ static int handle_request_invite(struct sip_pvt *p, struct sip_request *req, int
        p->reqsipoptions = required_profile;
 
        /* Check if this is a loop */
-       if (ast_test_flag(&p->flags[0], SIP_OUTGOING) && p->owner && (p->invitestate != INV_TERMINATED && p->invitestate != INV_CONFIRMED)) {
+       if (ast_test_flag(&p->flags[0], SIP_OUTGOING) && p->owner && (p->invitestate != INV_TERMINATED && p->invitestate != INV_CONFIRMED) && p->owner->_state != AST_STATE_UP) {
                /* 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 */