[asterisk-commits] r205877 - svn:log

Fri Jul 10 12:53:35 CDT 2009

Author: mmichelson
Revision: 205877
Modified property: svn:log

Modified: svn:log at Fri Jul 10 12:53:35 2009
------------------------------------------------------------------------------

--- svn:log (original)
+++ svn:log Fri Jul 10 12:53:35 2009
@@ -1,22 +1,39 @@
-Merged revisions 205776 via svnmerge from 
-https://origsvn.digium.com/svn/asterisk/trunk
+Properly ACK 487 responses to canceled INVITEs.
 
-................
-  r205776 | mmichelson | 2009-07-10 10:56:45 -0500 (Fri, 10 Jul 2009) | 16 lines
-  
-  Merged revisions 205775 via svnmerge from 
-  https://origsvn.digium.com/svn/asterisk/branches/1.4
-  
-  ........
-    r205775 | mmichelson | 2009-07-10 10:51:36 -0500 (Fri, 10 Jul 2009) | 10 lines
-    
-    Ensure that outbound NOTIFY requests are properly routed through stateful proxies.
-    
-    With this change, we make note of Record-Route headers present in any SUBSCRIBE
-    request that we receive so that our outbound NOTIFY requests will have the proper
-    Route headers in them.
-    
-    (closes issue #14725)
-    Reported by: ibc
-  ........
-................
+From the review board request:
+The fix from review 298 has exposed a new bug in chan_sip.
+
+When we hang up an outgoing call, we first will dump all the outstanding 
+packets on the sip_pvt using __sip_pretend_ack. Then, if we can, we send 
+a CANCEL. The problem with this is that since destroyed all the outstanding 
+packets on the dialog, we cannot match the incoming 487 response to our 
+INVITE. Because we cannot match the response, we do not send an ACK.
+
+To correct this, instead of using __sip_pretend_ack, I have changed the code 
+to loop through the list of packets and call __sip_semi_ack on each one 
+instead. This causes us to stop retransmitting the requests, but we still have 
+them around in case we get responses for them.
+
+When discussing this earlier today with Josh Colp, we both agreed that in the 
+majority of cases, this would be enough of a fix. However, we also agreed that 
+we should have a safety net in place in case we never receive a response to 
+our initial INVITE. To handle this, I have modified __sip_autodestruct to 
+behave similar to the way it does in Asterisk 1.4. If there are outstanding 
+packets on the sip_pvt, the needdestroy flag is not set, and the last request 
+on the dialog was either a CANCEL or BYE, then we set the needdestroy flag and 
+reschedule destruction for 10 seconds in the future. If, though, the 
+needdestroy flag is set, then we use __sip_pretend_ack to kill the remaining 
+outstanding packets so that the monitor thread can destroy the sip_pvt.
+
+I ran two separate tests. First, I placed a call from my Aastra phone to my 
+Polycom phone. I hung up the Aastra before the Polycom answered. I verified 
+through sip debug output that Asterisk properly ACKed the 487 received from the 
+Polycom.
+
+For my second test, I set up a SIPp UAS scenario so that it would send a 200 OK 
+in response to a CANCEL but would not send a 487 for the original INVITE. I 
+verified that after about 40 seconds, Asterisk properly cleans up the outgoing 
+sip_pvt for the call.
+
+Review: https://reviewboard.asterisk.org/r/308
+


