2011/12/15 Worley, Dale R (Dale) <[email protected]>: > The general concept is fine. I haven't checked whether the items that go > into your hash > include all the items recommended by the RFC(s), but you can check that > yourself. > > One difficulty is whether the items in the hash are everything that is > "significant" about > the call, that is, that could change how the call is routed. In principle, > the proxy could > examine some header field and sent it to some other proxy for modification, > and after that > is done, the request returns to your proxy, which will route it elsewhere > now, even though > the request-URI is the same. Worse, it is possible that some other proxy in > your universe > is making decisions based on that other header field. If this becomes > troublesome, you > need to include the other header field value in the hash. > > RFC 5393 gives some guidance: > > This second part MUST vary with any field used by the location > service logic in determining where to retarget or forward this > request. This is necessary to distinguish looped requests from > spirals by allowing the proxy to recognize if none of the values > affecting the processing of the request have changed. Hence, the > second part MUST depend at least on the received Request-URI and any > Route header field values used when processing the received request. > Implementers need to take care to include all fields used by the > location service logic in that particular implementation. > > > You need to compare the computed antiloop_id value with *all* the Via headers > in the > requests, because the request may have cycled through another proxy since the > last > time it passed through this proxy. > > You don't need to include the Call-Id in the antiloop_id, because you will > only be comparing > antiloop_id values that were computed from messages that have the same > Call-Id (various > instances of some one request).
Thanks Dale. Currently I don't consider the case of a loop between two proxies, I expect it to be too much error prune and difficult to design. In my experience most of the loops occur within a single proxy when they receive a request for a domain pointing to it without the proxy being aware of it For now I avoid just it. About the hash (the flow token value within the Record-Route URI username) it's basically a random token associated to the TCP connection, or the source IP:port encoded in someway in case of UDP. Thanks a lot. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
