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

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10481 
====================================================================== 
Reported By:                mavetju
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10481
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.10.1  
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 79553 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             08-17-2007 08:50 CDT
Last Modified:              08-17-2007 08:51 CDT
====================================================================== 
Summary:                    SIP with canreinvite=yes through multiple Asterisk
instances fails
Description: 
The story at http://www.mavetju.org/~edwin/asterisk-sip-reinvite.html
describes a problem I experienced with calls coming from one of our
providers where during the SIP handshake our equipment was reinviting
the SIP session: The RTP stream was never setup. We experienced
this after the upgrade from 1.2 to 1.4 (the latest SVN version),
before that it always has worked.

To simulate this problem, I have setup one SIP phone, three identical
Asterisk instances and a connection towards the end-point: A Cisco
Call Manager. The only varying factor in the experiments was the
option "canreinvite": When using "canreinvite=no", it always worked
fine, but when using "canreinvite=yes", it broke down after two
hops.

I have written down the whole setup, the configurations, the scenarios
and the results at http://www.mavetju.org/~edwin/c2-flow.txt.
Attached to each scenario are the SIP packets (captured with ngrep
and processed into a flow visualiser).
====================================================================== 

---------------------------------------------------------------------- 
 mavetju - 08-17-07 08:51  
---------------------------------------------------------------------- 
According to Raj Jain (at
http://lists.digium.com/pipermail/asterisk-dev/2007-August/029063.html):

You are running into a RE-INVITE "glare" scenario. The Asterisk boxes
facing each other are racing to send RE-INVITE to each other to drop
the RTP hairpin. The Asterisk 1.4 does not retransmit a RE-INVITE on
receving a 491 response. It is treating 491 as a permanent failure and
therefore dropping the call.

I don't know what changed between 1.2 and 1.4 to explain why you are
seeing this only in 1.4 and not in 1.2. Since this is a race
condition, I'd imagine that this could occur in 1.2 as well and has
just not occured in your setup yet. Maybe some additional processing
in 1.4 is causing the race condition to occur more frequently.

Your Mantis bug report would basically ask for correct 491 processing
in Asterisk SIP channel. Here is how RFC 3261 (Section 14.1)
recommends this condition should be resolved:

   If a UAC receives a 491 response to a re-INVITE, it SHOULD start a
   timer with a value T chosen as follows:

      1. If the UAC is the owner of the Call-ID of the dialog ID
         (meaning it generated the value), T has a randomly chosen value
         between 2.1 and 4 seconds in units of 10 ms.

      2. If the UAC is not the owner of the Call-ID of the dialog ID, T
         has a randomly chosen value of between 0 and 2 seconds in units
         of 10 ms.

   When the timer fires, the UAC SHOULD attempt the re-INVITE once more,
   if it still desires for that session modification to take place.  For
   example, if the call was already hung up with a BYE, the re-INVITE
   would not take place. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-17-07 08:51  mavetju        Note Added: 0068985                          
======================================================================