[asterisk-bugs] [Asterisk 0012013]: SIP with canreinvite=yes through multiple Asterisk instances fails

Thu Apr 9 14:26:19 CDT 2009

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12013 
====================================================================== 
Reported By:                alx
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   12013
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.18 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2008-02-17 20:55 CST
Last Modified:              2009-04-09 14:26 CDT
====================================================================== 
Summary:                    SIP with canreinvite=yes through multiple Asterisk
instances fails
Description: 
This is an update to issue http://bugs.digium.com/view.php?id=10481 which was
closed [apologies if there's
another way to report this against the original bug]

The problem relating to 'reinvite glare' as originally reported in 10481
seems to still be present with asterisk 1.4.18. The only difference is that
instead of the call being torn down, the 491 results in 'reinvites' being
lost. The result is that the call stays up, but the media path is not
modified to go directly between the two endpoints involved in the call.

The scenario we are testing is as follows:
SIP phone A ---> Asterisk A ---> Asterisk B ---> SIP phone B

"canreinvite=yes" is set on SIP phone A and SIP phone B. The connection
between Asterisk A and Asterisk B is a 'Custom' trunk. Both Asterisk boxes
are running 1.4.18.

The call proceeds as follows:
SIP Phone A     Asterisk A     Asterisk B      SIP Phone B
     -----INVITE--->     
     <--100 Trying--      ------INVITE-->  
                          <--100 Trying--  -----INVITE-->
                                           <--100 Trying-
                                           <--180 Ringing-
                          <--180 Ringing--
     <--180 Ringing
                                           <--200 OK
                          <--200 OK        --ACK-->
     <--200 OK
     --ACK-->                  
               --INVITE----> 
               <--INVITE----
               <--491 ------
               --491------->
               ---ACK------>
               <--ACK-------

At this point, the two Asterisk boxes just sit idle. No further reinvites
take place until the call is released. The media path remains pinned
between Asterisk A and Asterisk B, instead of going between SIP Phone A and
SIP Phone B.

[[Will attach SIP debug output once I figure out how to do so in this
reporting form]]

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
duplicate of        0013638 Audio not passing between two Asterisk ...
related to          0010481 SIP with canreinvite=yes through multip...
====================================================================== 

---------------------------------------------------------------------- 
 (0103046) svnbot (reporter) - 2009-04-09 14:26
 http://bugs.digium.com/view.php?id=12013#c103046 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 187531

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

------------------------------------------------------------------------
r187531 | dvossel | 2009-04-09 14:26:17 -0500 (Thu, 09 Apr 2009) | 23
lines

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

................
  r185846 | dvossel | 2009-04-01 14:03:32 -0500 (Wed, 01 Apr 2009) | 16
lines

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

  ........
    r185845 | dvossel | 2009-04-01 14:02:00 -0500 (Wed, 01 Apr 2009) | 10
lines

    Fixes issue with dropped calles due to re-Invite glare and re-Invites
never executing after a 491

    Acknowledgement for 491 responses were never being processed because
it didn't match our pending invite's seqno.  Since the ACK was never
processed, the 491 frame would continue to be retransmitted until
eventually the call was dropped due to max retries.  Now during a pending
invite, if we receive another invite, we send an 491 and hold on to that
glare invite's seqno in the "glareinvite" variable for that sip_pvt struct.
 When ACK's are received, we first check to see if it is in response to our
pending invite, if not we check to see if it is in response to a glare
invite.  In this case, it is in response to the glare invite and must be
dealt with or the call is dropped.  I've changed the wait time for
resending the re-Invite after receving a 491 response to comply with RFC
3261.  Before this patch the scheduled re-Invite would only change a flag
indicating that the re-Invite should be sent out, now it actually sends it
out as well. 

    (closes issue http://bugs.digium.com/view.php?id=12013)
    Reported by: alx

    Review: http://reviewboard.digium.com/r/213/
  ........
................

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

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

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