[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:                putnopvut
====================================================================== 
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:              05-28-2008 11:11 CDT
====================================================================== 
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.
====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 05-28-08 11:11  
---------------------------------------------------------------------- 
Much appreciated. Yesterday, I managed to write a method which successfully
spiralled an INVITE through Asterisk. The problem is that my code is not
nearly robust enough (I'll get into why a bit later). I'll post the patch I
wrote and anyone can feel free to modify or critique it. I'll be actively
working on this more today as well.

The way this implementation works is quite different than the approaches
taken by others on this issue so far. Previous attempts changed the
find_call function of chan_sip in order to match the call-id and the tags
when run in pedantic mode. A spiralled INVITE would not match properly (due
to the fact that a spiralled INVITE will contain no To: tag but Asterisk
will have generated a local tag for the dialog already) and so a new dialog
would be established with the new recipient of the call.

In my implementation, I don't modify the find_call function at all.
Instead, I added a few lines to handle_request_invite(), inside the block
where loop detection happens. Since I imagine that about 95% of SIP spirals
are INVITEs where the request-URI is changed, I do a string comparison of
the old vs. new request URI. If the new request URI is different than the
old, then I treat this as a spiral. I then parse out the section between
"sip:" and the "@" of the request URI, and call create_addr() and
transmit_invite(). The result is that the existing dialog in Asterisk is
modified to have the proper routing information and the call can proceed.

As I said very early on, this method is not even close to being robust
enough to commit. It relies on several assumptions, some of which I'm fine
with and others I'm not so fine with.

1. Spiral detection is limited to INVITEs and will only be properly
detected if the Request URI has been modified. This is one of the
assumptions that I'm okay with since for one thing, Asterisk has never done
loop detection on any other request type, and also I estimate that 95% of
spirals (maybe more) are identifiable by inspecting the request URI.

2. The comparison of request-uri's is a simple string comparison. The URI
comparison should probably be more refined to take into account the fact
that there could be differences in the parameters of the Request-URI. Also,
there could be a strange case where the host portion of the URI is changed
textually, but from a routing perspective equates to no change (i.e. a
hostname is replaced with one of its IP addresses).

3. Most importantly, the code is written in a way that assumes that the
"user" section of the Request-URI is a peer registered to the local
Asterisk server. This is probably the most grievous of the assumptions made
in the code so far, and needs the most work towards being correct. I made
an adjustment at one point to attempt routing using the IP address and port
of the Requeust-URI, but there is some packet manipulation needed before
that will work correctly.

Okay, so as I said, I will be working on this more today to get it past
the bare-bones implementation that is there so far. Please don't laugh too
hard at the patch when I upload it :) 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-28-08 11:11  putnopvut      Note Added: 0087438                          
======================================================================