[asterisk-bugs] [Asterisk 0012215]: [patch] Asterisk returns 482 Loop Detected upon receiving re-invite

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12215 
====================================================================== 
Reported By:                jpyle
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12215
Category:                   Channels/chan_sip/General
Reproducibility:            random
Severity:                   minor
Priority:                   normal
Status:                     confirmed
Asterisk Version:           1.4.18 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-03-14 11:45 CDT
Last Modified:              2008-11-18 11:02 CST
====================================================================== 
Summary:                    [patch] Asterisk returns 482 Loop Detected upon
receiving re-invite
Description: 
Asterisk sends a 482 Loop Detected upon receiving a presumably valid
re-INVITE.  Pedantic is enabled globally in sip.conf.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
duplicate of        0007403 [patch] allow SIP Spiral to work instea...
====================================================================== 

---------------------------------------------------------------------- 
 (0094987) mneuhauser (reporter) - 2008-11-18 11:02
 http://bugs.digium.com/view.php?id=12215#c94987 
---------------------------------------------------------------------- 
You are right, asterisk-1.4.19-chan_sip-loop-detection-fix-v2.patch has
some serious problems.

I have now found a way to reliable trigger the loop detection in a
re-INVITE situation
(asterisk-1.4.19-app_dial-force-loop-misdetection.patch). With this I was
able to verify that just accepting the re-INVITE, even if the channel is
not UP (i.e. what asterisk-1.4.19-chan_sip-loop-detection-fix-v2.patch
does), is not the way to go. I didn't see the same behaviour as in your
case, but it was definitely not OK (e.g., channel never went away).

Without changing the way OK/AST_CONTROL_ANSWER is handled completely, I
can only think of two things to do in chan_sip's handle_request_invite() if
a re-INVITE is received but the channel is not UP:
1) clean(?): decline re-invite with "488 Not acceptable here"; the call
   will continue with an unchanged RTP-path, but at least it will not be
   terminated
2) hack: just ignore the re-INVITE request and hope that the other side
   retransmits the request and that our channel is UP when the
re-transmitted
   packet is received by us; this allows the re-INVITE to happen, if
everything
   goes like expected. The problems with this approach:
   * we do something that is not 100% SIP-RFC conform
   * requests are not ignored anywhere else in chan_sip (at least to
     my knowledge) and so I did not have a template of how to do it, so
there
     could be side effects that I have missed
   * I haven't tested what happens if the other side does NOT retransmit
its
     re-INVITE, but Asterisk should already be able to handle this
(connectivity
     to a SIP UA can be lost any time ...)
   * 1.6 outlook: I do not know if re-INVITES are re-transmitted if TCP
     transport is used

The new asterisk-1.4.19-chan_sip-loop-detection-fix-v3.patch patch
implements
Method 2. I've tested it with the aid of
asterisk-1.4.19-app_dial-force-loop-misdetection.patch and had no problems
(re-invite works, no hung channels). Would be great if you could give it a
try. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-11-18 11:02 mneuhauser     Note Added: 0094987                          
======================================================================