[svn-commits] mmichelson: branch 1.6.0 r208389 - in /branches/1.6.0: ./ channels/chan_sip.c

[SVN commits to the Digium repositories]

Author: mmichelson
Date: Thu Jul 23 14:35:27 2009
New Revision: 208389

URL: http://svn.asterisk.org/svn-view/asterisk?view=rev&rev=208389
Log:
Merged revisions 208388 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

................
  r208388 | mmichelson | 2009-07-23 14:34:49 -0500 (Thu, 23 Jul 2009) | 24 lines
  
  Merged revisions 208386 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4
  
  ........
    r208386 | mmichelson | 2009-07-23 14:24:21 -0500 (Thu, 23 Jul 2009) | 17 lines
    
    Fix a problem where a 491 response could be sent out of dialog.
    
    This generalizes the fix for issue 13849. The initial fix corrected the
    problem that Asterisk would reply with a 491 if a reinvite were received
    from an endpoint and we had not yet received an ACK from that endpoint
    for the initial INVITE it had sent us. This expansion also allows Asterisk
    to appropriately handle an INVITE with authorization credentials if Asterisk
    had not received an ACK from the previous transaction in which Asterisk had
    responded to an unauthorized INVITE with a 407.
    
    (closes issue #14239)
    Reported by: klaus3000
    Patches:
          14239.patch uploaded by mmichelson (license 60)
    Tested by: klaus3000
    	  
  ........
................

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

Propchange: branches/1.6.0/
------------------------------------------------------------------------------
Binary property 'trunk-merged' - no diff available.

Modified: branches/1.6.0/channels/chan_sip.c
URL: http://svn.asterisk.org/svn-view/asterisk/branches/1.6.0/channels/chan_sip.c?view=diff&rev=208389&r1=208388&r2=208389
==============================================================================
--- branches/1.6.0/channels/chan_sip.c (original)
+++ branches/1.6.0/channels/chan_sip.c Thu Jul 23 14:35:27 2009
@@ -17563,17 +17563,18 @@
 	}
 
 	if (!req->ignore && p->pendinginvite) {
-		if (!ast_test_flag(&p->flags[0], SIP_OUTGOING) && ast_test_flag(&p->flags[1], SIP_PAGE2_DIALOG_ESTABLISHED)) {
-			/* We have received a reINVITE on an incoming call to which we have sent a 200 OK but not yet received
-			 * an ACK. According to RFC 5407, Section 3.1.4, the proper way to handle this race condition is to accept
-			 * the reINVITE since we have established a dialog.
+		if (!ast_test_flag(&p->flags[0], SIP_OUTGOING) && (p->invitestate == INV_COMPLETED || p->invitestate == INV_TERMINATED)) {
+			/* What do these circumstances mean? We have received an INVITE for an "incoming" dialog for which we
+			 * have sent a final response. We have not yet received an ACK, though (which is why p->pendinginvite is non-zero).
+			 * We also know that the INVITE is not a retransmission, because otherwise the "ignore" flag would be set.
+			 * This means that either we are receiving a reinvite for a terminated dialog, or we are receiving an INVITE with
+			 * credentials based on one we challenged earlier.
+			 *
+			 * The action to take in either case is to treat the INVITE as though it contains an implicit ACK for the previous
+			 * transaction. Calling __sip_ack will take care of this by clearing the p->pendinginvite and removing the response
+			 * from the previous transaction from the list of outstanding packets.
 			 */
-
-			/* Note that this will both clear the pendinginvite flag and cancel the 
-			 * retransmission of the 200 OK. Basically, we're accepting this reINVITE as both an ACK
-			 * and a reINVITE in one request.
-			 * */
-			__sip_ack(p, p->lastinvite, 1, 0);
+			__sip_ack(p, p->pendinginvite, 1, 0);
 		} else {
 			/* We already have a pending invite. Sorry. You are on hold. */
 			p->glareinvite = seqno;