[Home]

Summary:ASTERISK-11458: SIP with canreinvite=yes through multiple Asterisk instances fails
Reporter:Amruth Laxman (alx)Labels:
Date Opened:2008-02-17 20:55:55.000-0600Date Closed:2009-04-09 14:26:20
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 12013.diff
( 1) fulllog.txt
( 2) glarepending.1.4.diff
( 3) ServerOne.txt
( 4) ServerTwo.txt
Description:This is an update to issue ASTERISK-10105 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]]
               
                                   



****** ADDITIONAL INFORMATION ******

In looking at the fix for bug 10481, we noticed the following:
1) The code was modified to set a timer when a 491 is received. However the call to ast_sched_add() is using seconds instead of milliseconds. This causes the scheduled event to never fire (at-least a log entry placed in sip_reinvite_retry() is not seen).

Modifying the code to pass milliseconds to ast_sched_add() [by x1000 the seconds value], results in the timer firing, but still no reinvite processing.

2) Looking further at the change that was done for bug 10481, it appears that the only action taken is to set the 'NEED_REINVITE' flag. It is not clear how this will drive a re-send of the reinvite, since the NEED_REINVITE flag appears to be only checked when an event is received for the call. If the call is already stable, no event will be received.

We tried the following patch to kick the reinvite, by checking if the call is still up and if a BYE is not pending, and then calling check_pendings to send a reinvite. However, it is not clear to us whether this will cause any side-effects, especially since the sip_reinvite_retry is called from the scheduler and may run in a different thread than the original call (is this true?). At a minimum some locking may be needed of the sip_pvt structure.

--- chan_sip.c.save     2008-02-17 18:58:32.000000000 -0500
+++ chan_sip.c  2008-02-17 21:22:16.000000000 -0500
@@ -11950,9 +11950,20 @@
static int sip_reinvite_retry(const void *data)
{
       struct sip_pvt *p = (struct sip_pvt *) data;
+       if (option_debug)
+               ast_log(LOG_DEBUG, "Reinvite retry expired - %s\n",p->callid);

       ast_set_flag(&p->flags[0], SIP_NEEDREINVITE);
       p->waitid = -1;
+        /* If call is still up and BYE is not pending, send
+           the reinvite now */
+        if ((p->owner && p->owner->_state == AST_STATE_UP) &&
+            !(ast_test_flag(&p->flags[0], SIP_PENDINGBYE)))
+        {
+          if (option_debug)
+               ast_log(LOG_DEBUG, "Retry the reinvite that was defered - %s\n", p->callid);
+           check_pendings(p);
+        }
       return 0;
}

@@ -12266,7 +12277,7 @@
                               /* Reset the flag after a while
                                */
                               int wait = 3 + ast_random() % 5;
-                               p->waitid = ast_sched_add(sched, wait, sip_reinvite_retry, p);
+                               p->waitid = ast_sched_add(sched, wait*1000, sip_reinvite_retry, p);
                               if (option_debug > 2)
                                       ast_log(LOG_DEBUG, "Reinvite race. Waiting %d secs before retry\n", wait);
Comments:By: Amruth Laxman (alx) 2008-02-17 21:14:16.000-0600

Added sip debug log from "Asterisk A" in the above scenario. Search for "Reinvite race" to find the log statement corresponding to the 491.
By: Joshua C. Colp (jcolp) 2008-05-08 11:19:53

Give this a go.
By: Leif Madsen (lmadsen) 2008-12-05 09:37:50.000-0600

I started trying to reproduce this yesterday, and will continue on with it this afternoon to see if the patch resolves the issue.
By: Leif Madsen (lmadsen) 2008-12-10 10:48:58.000-0600

Reproduced. Testing fix.
By: Leif Madsen (lmadsen) 2008-12-10 10:53:12.000-0600

Hmmm... almost. The audio is now reinvited for me (it wasn't before), but still getting the 491 Request Pending issue, and the call is hung up. Will attach a SIP debug and history here shortly.
By: Leif Madsen (lmadsen) 2008-12-10 11:14:45.000-0600

Attached ServerOne.txt and ServerTwo.txt with sip debug and history. These are files generated after applying the attached 12013.diff patch.
By: Digium Subversion (svnbot) 2009-04-01 14:02:02

Repository: asterisk
Revision: 185845

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r185845 | dvossel | 2009-04-01 14:02:01 -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 ASTERISK-11458)
Reported by: alx

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


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

http://svn.digium.com/view/asterisk?view=rev&revision=185845
By: Digium Subversion (svnbot) 2009-04-01 14:03:33

Repository: asterisk
Revision: 185846

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r185846 | dvossel | 2009-04-01 14:03:33 -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 ASTERISK-11458)
 Reported by: alx
 
 Review: http://reviewboard.digium.com/r/213/
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=185846
By: Digium Subversion (svnbot) 2009-04-01 14:05:28

Repository: asterisk
Revision: 185847

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

------------------------------------------------------------------------
r185847 | dvossel | 2009-04-01 14:05:27 -0500 (Wed, 01 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 ASTERISK-11458)
   Reported by: alx
   
   Review: http://reviewboard.digium.com/r/213/
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=185847
By: Digium Subversion (svnbot) 2009-04-01 14:06:46

Repository: asterisk
Revision: 185848

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

------------------------------------------------------------------------
r185848 | dvossel | 2009-04-01 14:06:46 -0500 (Wed, 01 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 ASTERISK-11458)
   Reported by: alx
   
   Review: http://reviewboard.digium.com/r/213/
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=185848
By: Digium Subversion (svnbot) 2009-04-09 14:26:17

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 ASTERISK-11458)
   Reported by: alx
   
   Review: http://reviewboard.digium.com/r/213/
 ........
................

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

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