[asterisk-commits] file: trunk r87343 - in /trunk: ./ channels/chan_sip.c

[SVN commits to the Asterisk project]

Author: file
Date: Mon Oct 29 12:22:16 2007
New Revision: 87343

URL: http://svn.digium.com/view/asterisk?view=rev&rev=87343
Log:
Merged revisions 87342 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r87342 | file | 2007-10-29 14:20:28 -0300 (Mon, 29 Oct 2007) | 6 lines

Fix issue where if both sides of the dialog cancelled the dialog at the same time chan_sip could kepe retransmitting a response for no reason.
(closes issue #9566)
Reported by: atca_pres
Patches:
      bug9566.patch uploaded by oej

........

Modified:
    trunk/   (props changed)
    trunk/channels/chan_sip.c

Propchange: trunk/
------------------------------------------------------------------------------
Binary property 'branch-1.4-merged' - no diff available.

Modified: trunk/channels/chan_sip.c
URL: http://svn.digium.com/view/asterisk/trunk/channels/chan_sip.c?view=diff&rev=87343&r1=87342&r2=87343
==============================================================================
--- trunk/channels/chan_sip.c (original)
+++ trunk/channels/chan_sip.c Mon Oct 29 12:22:16 2007
@@ -4111,6 +4111,7 @@
 					   INVITE, but do set an autodestruct just in case we never get it. */
 					needdestroy = 0;
 					sip_scheddestroy(p, DEFAULT_TRANS_TIMEOUT);
+					p->invitestate = INV_CANCELLED;
 				}
 				if ( p->initid != -1 ) {
 					/* channel still up - reverse dec of inUse counter
@@ -4123,6 +4124,7 @@
 					transmit_response_reliable(p, res, &p->initreq);
 				else 
 					transmit_response_reliable(p, "603 Declined", &p->initreq);
+				p->invitestate = INV_TERMINATED;
 			}
 		} else {	/* Call is in UP state, send BYE */
 			if (!p->pendinginvite) {
@@ -15560,7 +15562,16 @@
 		
 	check_via(p, req);
 	sip_alreadygone(p);
-	p->invitestate = INV_CANCELLED;
+
+	/* At this point, we could have cancelled the invite at the same time
+	   as the other side sends a CANCEL. Our final reply with error code
+	   might not have been received by the other side before the CANCEL
+	   was sent, so let's just give up retransmissions and waiting for
+	   ACK on our error code. The call is hanging up any way. */
+	if (p->invitestate == INV_TERMINATED)
+		__sip_pretend_ack(p);
+	else
+		p->invitestate = INV_CANCELLED;
 	
 	if (p->owner && p->owner->_state == AST_STATE_UP) {
 		/* This call is up, cancel is ignored, we need a bye */