You may be interested in RFC 5393 too http://tools.ietf.org/html/rfc5393
On Thu, May 20, 2010 at 7:41 PM, Pandurangan R S <[email protected]> wrote: > This is a known bug against RFC3261. > > http://bugs.sipit.net/show_bug.cgi?id=648 > > On Thu, May 20, 2010 at 6:31 PM, Aaron Clauson <[email protected]> wrote: >> I have a problem understanding how RFC3261 would allow loop detection for a >> request that was bouncing between two or more proxies. >> >> Section 16.6.8 states: >> >> "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." >> >> That makes sense but then it goes on to state: >> >> "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." >> >> If the topmost Via header is included in the hash which is being used to >> construct the proxy's own Via header won't it only ever detect a loop if the >> request is returned to it without another Via header being added? >> >> So if Proxy 1 forwards to Proxy 2 which forwards back to Proxy 1 without any >> of the fields that impact processing of the request changing how would Proxy >> 1 be able to detect the loop given that the hash it creates the second time >> the request arrives will be different due to the topmost Via header? >> >> Aaron >> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
