[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:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   14703
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
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-04-02 09:03 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:


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 on bug.


regards,
genie



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

---------------------------------------------------------------------- 
 (0102613) ravindrad (reporter) - 2009-04-02 09:03
 http://bugs.digium.com/view.php?id=14703#c102613 
---------------------------------------------------------------------- 
I am in totally sync with you Genie. I was commenting about the 491
response sent for the second invite with cseq =2, I think it is not handled
according to RFC 3261. The 491 response should be sent when you send an
outgoing invite which is not yet completed and at the same time you receive
incoming invite for the same session, this happens only in case of
reinvite. But here in asterisk it is handled bit differently.

RFC 3261, in section 14,2 he says "A UAS that receives a second INVITE
before it sends the final  response to a first INVITE with a lower CSeq
sequence number on the same dialog MUST return a 500 (Server Internal
Error) response to the   second INVITE and MUST include a Retry-After
header field with a randomly chosen value of between 0 and 10 seconds".

A UAS that receives an INVITE on a dialog while an INVITE it had sent on
that dialog is in progress MUST return a 491 (Request Pending) response to
the received INVITE

In case of incoming invite even the first invite is not completed, we can
allow the user to try "max retry" times for a call or transaction timeout.

If we take the above scenario, ack for the first invite is
dropped(cseq=1), Unaware of this UA sends invite with
authentcation(cseq=2). In this case asterisk should continue retransmit 401
until it receives ack for that and should process this 2nd invite. If the
max retries are reached and still the transaction are not completed then
call should be disconnected.

I already worked on the fix for it. It is working fine, needs some more
testing... Could not test it since got busy with some other things. I think
Monday I can update the patch for this. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-02 09:03 ravindrad      Note Added: 0102613                          
======================================================================