[asterisk-bugs] [Asterisk 0007403]: [patch] allow SIP Spiral to work instead of causing a '482 Loop Detected' condition

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=7403 
====================================================================== 
Reported By:                stephen_dredge
Assigned To:                oej
====================================================================== 
Project:                    Asterisk
Issue ID:                   7403
Category:                   Channels/chan_sip/General
Reproducibility:            N/A
Severity:                   tweak
Priority:                   normal
Status:                     assigned
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 47646 
Disclaimer on File?:        No 
Request Review:              
====================================================================== 
Date Submitted:             06-21-2006 00:13 CDT
Last Modified:              12-24-2007 06:02 CST
====================================================================== 
Summary:                    [patch] allow SIP Spiral to work instead of causing
a '482 Loop Detected' condition
Description: 
A sip call originating from asterisk causes a '482 Loop Detected' response
when forwarded back to asterisk from a external proxy. This should be
allowed when the request URI has been changed by the proxy and the call is
now targeted at a different user.
====================================================================== 

---------------------------------------------------------------------- 
 alexh - 12-24-07 06:02  
---------------------------------------------------------------------- 
I patched 1.4.15 with the latest spiral_patch.

Although it works in preventing the 482, it exposes another issue: inbound
authentication doesn't work anymore. Apparently, the nonce is stored with
the first (unauthenticated) request. As the second request with
authentication info comes in it isn't matched to the first request (as it
should with this patch, because it is a new transaction) and authentication
fails. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-24-07 06:02  alexh          Note Added: 0075884                          
======================================================================