[asterisk-commits] mmichelson: branch 10 r366390 - in /branches/10: ./ channels/chan_sip.c

[SVN commits to the Asterisk project]

Author: mmichelson
Date: Mon May 14 14:16:36 2012
New Revision: 366390

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=366390
Log:
Fix broken reinvite glare scenario.

To make a long story short, reinvite glares were broken
because Asterisk would invert the To and From headers
when ACKing a 491 response.

The reason was because the initreq of the dialog was being
changed to the incoming glared reinvite instead of being
set to the outgoing glared reinvite. This change has three
parts

* In handle_incoming, we never will reject an ACK because it
has a to-tag present, even if we think the request may be out
of dialog.
* In handle_request_invite, we do not change the initreq when
receiving a reinvite to which we will respond with a 491.
* In handle_request_invite, several superflous settings up
pendinginvite have been removed since this is dones automatically
by transmit_response_reliable

Review: https://reviewboard.asterisk.org/r/1911
........

Merged revisions 366389 from http://svn.asterisk.org/svn/asterisk/branches/1.8

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

Propchange: branches/10/
------------------------------------------------------------------------------
Binary property 'branch-1.8-merged' - no diff available.

Modified: branches/10/channels/chan_sip.c
URL: http://svnview.digium.com/svn/asterisk/branches/10/channels/chan_sip.c?view=diff&rev=366390&r1=366389&r2=366390
==============================================================================
--- branches/10/channels/chan_sip.c (original)
+++ branches/10/channels/chan_sip.c Mon May 14 14:16:36 2012
@@ -23024,9 +23024,7 @@
 				}
 			}
 			transmit_response_reliable(p, "491 Request Pending", req);
-			p->pendinginvite = seqno;
 			check_via(p, req);
-			copy_request(&p->initreq, req);
 			ast_debug(1, "Got INVITE on call where we already have pending INVITE, deferring that - %s\n", p->callid);
 			/* Don't destroy dialog here */
 			res = INV_REQ_FAILED;
@@ -23046,7 +23044,6 @@
 		if (p->owner) {
 			ast_debug(3, "INVITE w Replaces on existing call? Refusing action. [%s]\n", p->callid);
 			transmit_response_reliable(p, "400 Bad request", req);	/* The best way to not not accept the transfer */
-			p->pendinginvite = seqno;
 			check_via(p, req);
 			copy_request(&p->initreq, req);
 			/* Do not destroy existing call */
@@ -23066,7 +23063,6 @@
 			sip_scheddestroy(p, DEFAULT_TRANS_TIMEOUT);
 			p->invitestate = INV_COMPLETED;
 			res = INV_REQ_ERROR;
-			p->pendinginvite = seqno;
 			check_via(p, req);
 			copy_request(&p->initreq, req);
 			goto request_invite_cleanup;
@@ -23171,7 +23167,6 @@
 			refer_locked = 0;
 			p->invitestate = INV_COMPLETED;
 			res = INV_REQ_ERROR;
-			p->pendinginvite = seqno;
 			check_via(p, req);
 			copy_request(&p->initreq, req);
 			goto request_invite_cleanup;
@@ -26024,13 +26019,13 @@
 			if (!req->ignore && req->method == SIP_INVITE) {
 				transmit_response_reliable(p, "481 Call/Transaction Does Not Exist", req);
 				/* Will cease to exist after ACK */
+				return res;
 			} else if (req->method != SIP_ACK) {
 				transmit_response(p, "481 Call/Transaction Does Not Exist", req);
 				sip_scheddestroy(p, DEFAULT_TRANS_TIMEOUT);
-			} else {
-				ast_debug(1, "Got ACK for unknown dialog... strange.\n");
-			}
-			return res;
+				return res;
+			}
+			/* Otherwise, this is an ACK. It will always have a to-tag */
 		}
 	}