[asterisk-bugs] [Asterisk 0014703]: sip call setup bug

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14703 
====================================================================== 
Reported By:                genie
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14703
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.0.6 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-03-19 08:04 CDT
Last Modified:              2009-03-30 11:12 CDT
====================================================================== 
Summary:                    sip call setup bug
Description: 
I'm testing SIP protocol on Asterisk. While performing tests on performance
with packet loss I came across a bug of Asterisk while call initiation. In
my Asterisk SIP configuration I have 'canreinvite=no' set. That is why
normal call setup looks like that:
student.agh.edu.pl/~genie/Visio-call_setup_no_reinvite.pdf

However, if the first ACK packet of the flow is lost and the ClientA who
does not know it sends Invite_with_authorisation packet the call will never
be set up, ending up with a infinte loop where client sends ACK messages
and asterisk '491 request pending' message. The wireshark files captured on
both ClientA and Asterisk can be found here: 
http://student.agh.edu.pl/~genie/asterisk/

regards,
genie



====================================================================== 

---------------------------------------------------------------------- 
 (0102395) ravindrad (reporter) - 2009-03-30 11:12
 http://bugs.digium.com/view.php?id=14703#c102395 
---------------------------------------------------------------------- 
Retransmission handling in asterisk for incoming requests are cancelled
only if the pending invite and Cseq of the acknowledgment request received
are same.

If the CSeq request received are higher than the current pending invite
CSeq the ack matching will fail and the retransmission continues even after
receiving ack.

So following patches fixes the bug retransmission. 
But I dont think 491 request pending should be generated for this
scenario. This 
is a valid scenario and when packet loss scenario happens in network,
calls  
will be dropped with this way of handling in asterisk. I already have
worked on a fix for it. Need some more testing. I should be able to update
the patch for this by tomorrow. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-30 11:12 ravindrad      Note Added: 0102395                          
======================================================================