[asterisk-bugs] [Asterisk 0013849]: problem handling race condition - reINVITE before ACK

Thu Apr 9 14:14:39 CDT 2009

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13849 
====================================================================== 
Reported By:                klaus3000
Assigned To:                mmichelson
====================================================================== 
Project:                    Asterisk
Issue ID:                   13849
Category:                   Channels/chan_sip/General
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 154926 
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2008-11-06 11:35 CST
Last Modified:              2009-04-09 14:14 CDT
====================================================================== 
Summary:                    problem handling race condition - reINVITE before
ACK
Description: 
Hi! 

Asterisk has problems handling incoming reINVITE if the ACK of the
incoming INVITE is still missing. Although this a pssobile scenario, e.g:

client   proxy     Asterisk
  --INV--->
           ----INV----->
           <---200 ok---
  <-200 ok-
  --ACK--->
  -reINV-->
            --reINV----->
            --ACK------->

This is a scearion which can really happen, e.g. as the processing of the
ACK in the proxy may takes more time. It can also happen without proxy (an
packet can overtake another packet).

The problem is:
1. Asterisk does not accept the reINVITE but sends 491 request pending
Sending 491 is only allowed if the request is in a pending state. But as
the request is finished (200 is already sent) there can not be 491. The
proper solution would be to accept the reINVITE - as this reINVITE is an
implicit ACK to the previous INVITE. Receiving the reINVITE means, that the
caller has received the 200 ok.

2. Asterisk does not accept the ACK to the 491, it goes on resending the
491.

3. My client then tries to reINVITE again, which is accepted by Asterisk.
But then, if the call is hang up from the other side (in this case DHADI),
Asterisk does not send BYE

It happends with pedantic= yes and no.
====================================================================== 

---------------------------------------------------------------------- 
 (0103044) svnbot (reporter) - 2009-04-09 14:14
 http://bugs.digium.com/view.php?id=13849#c103044 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 187495

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c

------------------------------------------------------------------------
r187495 | mmichelson | 2009-04-09 14:14:39 -0500 (Thu, 09 Apr 2009) | 31
lines

Merged revisions 187488 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

................
  r187488 | mmichelson | 2009-04-09 13:58:41 -0500 (Thu, 09 Apr 2009) | 24
lines

  Merged revisions 187484 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4

  ........
    r187484 | mmichelson | 2009-04-09 13:51:20 -0500 (Thu, 09 Apr 2009) |
18 lines

    Handle a SIP race condition (reinvite before an ACK) properly.

    RFC 5047 explains the proper course of action to take if a 
    reINVITE is received before the ACK from a previous invite
    transaction. What we are to do is to treat the reINVITE as
    if it were both an ACK and a reINVITE and process it normally.

    Later, when we receive the ACK we had been expecting, we will
    ignore it since its CSeq is less than the current iseqno of
    the sip_pvt representing this dialog.

    (closes issue http://bugs.digium.com/view.php?id=13849)
    Reported by: klaus3000
    Patches:
          13849_v2.patch uploaded by mmichelson (license 60)
    Tested by: mmichelson, klaus3000
  ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=187495 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-09 14:14 svnbot         Checkin                                      
2009-04-09 14:14 svnbot         Note Added: 0103044                          
======================================================================