[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 02:41 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.
====================================================================== 

---------------------------------------------------------------------- 
 ibc - 05-28-08 02:41  
---------------------------------------------------------------------- 
If it can help I point to the RFC 3261 sections in which it's explained how
to match loop and spiral for an incoming request:

--------------------------------
16.3 Request Validation

   4. Optional Loop Detection check

      An element MAY check for forwarding loops before forwarding a
      request.  If the request contains a Via header field with a sent-
      by value that equals a value placed into previous requests by the
      proxy, the request has been forwarded by this element before.  The
      request has either looped or is legitimately spiraling through the
      element.  To determine if the request has looped, the element MAY
      perform the branch parameter calculation described in Step 8 of
      Section 16.6 on this message and compare it to the parameter
      received in that Via header field.  If the parameters match, the
      request has looped.  If they differ, the request is spiraling, and
      processing continues.  If a loop is detected, the element MAY
      return a 482 (Loop Detected) response.


16.6 Request Forwarding

      8. Add a Via header field value

         The proxy MUST insert a Via header field value into the copy
         before the existing Via header field values.  The construction
         of this value follows the same guidelines of Section 8.1.1.7.
         This implies that the proxy will compute its own branch
         parameter, which will be globally unique for that branch, and
         contain the requisite magic cookie. Note that this implies that
         the branch parameter will be different for different instances
         of a spiraled or looped request through a proxy.

         Proxies choosing to detect loops have an additional constraint
         in the value they use for construction of the branch parameter.
         A proxy choosing to detect loops SHOULD create a branch
         parameter separable into two parts by the implementation.  The
         first part MUST satisfy the constraints of Section 8.1.1.7 as
         described above.  The second is used to perform loop detection
         and distinguish loops from spirals.

         Loop detection is performed by verifying that, when a request
         returns to a proxy, those fields having an impact on the
         processing of the request have not changed.  The value placed
         in this part of the branch parameter SHOULD reflect all of
         those fields (including any Route, Proxy-Require and Proxy-
         Authorization header fields).  This is to ensure that if the
         request is routed back to the proxy and one of those fields
         changes, it is treated as a spiral and not a loop (see Section
         16.3).  A common way to create this value is to compute a
         cryptographic hash of the To tag, From tag, Call-ID header
         field, the Request-URI of the request received (before
         translation), the topmost Via header, and the sequence number
         from the CSeq header field, in addition to any Proxy-Require
         and Proxy-Authorization header fields that may be present.  The
         algorithm used to compute the hash is implementation-dependent,
         but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a
         reasonable choice.  (Base64 is not permissible for a token.)

         If a proxy wishes to detect loops, the "branch" parameter it
         supplies MUST depend on all information affecting processing of
         a request, including the incoming Request-URI and any header
         fields affecting the request's admission or routing.  This is
         necessary to distinguish looped requests from requests whose
         routing parameters have changed before returning to this
         server.

         The request method MUST NOT be included in the calculation of
         the branch parameter.  In particular, CANCEL and ACK requests
         (for non-2xx responses) MUST have the same branch value as the
         corresponding request they cancel or acknowledge.  The branch
         parameter is used in correlating those requests at the server
         handling them (see Sections 17.2.3 and 9.2).
------------------ 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-28-08 02:41  ibc            Note Added: 0087402                          
======================================================================