On Fri, 2005-11-11 at 22:48 +0100, Jeroen van Bemmel wrote:
I disagree here. The proxy may not be able to determine whether the
requests
are perceived as being the same, but that is not what it should be
looking
at anyway. The loop check essentially determines if the proxy (and
possibly
its successors) would take the same routing decision the second time the
request passes by. There is no 100% guarantee that they would (there
could
be a stateful proxy responsible for the request URI domain making
arbitrary
decisions), but a request with no changes in headers that affect routing
has
a high probability of looping a third, fourth, etc time.
The difficulty is that the proxy cannot discern which headers might
affect routing in downstream proxies. Just because there are no changes
in headers that *this* proxy uses to determine routing does not mean
that a change has not been made that will avoid infinite looping.
Particularly problematic is when a request passes through a proxy B
which spirals the request back to an entry router A. That is, "source
-> A -> B -> A -> B -> destination". B may easily make a change that it
knows will cause itself to route the request differently when spiraled,
but A will reject it as a loop.
In that case, I would turn it around: it would be up to B to make sure it
changes something else too such that A won't reject the request as a loop. B
knows this based on the assumption that other proxies are RFC3261 compliant,
and therefore SHOULD reject if none of the set of headers defined by the
loop detection algorithm in RFC3261 have changed
Conversely, proxy A may assume that other proxies will change at least one
of the headers / request-URI that affect routing; if they don't, A SHOULD
reject it as a loop
Jeroen
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
