Jonathan R. wrote:
<snip>
> Of course, the easier thing is not to bother with loop detection.
A related question :
If a stateful proxy does not bother with loop detection and
goes the Max-Forwards way, how does it handle a CANCEL request
to such a loop. When the caller generates a CANCEL, each stateful
proxy in the loop sends a 200 OK to the CANCEL, and generates
one of its own. So, when the stateful proxy receives a CANCEL for
the first loop, it sends a 200OK and generates one. But when
it receives the CANCEL for the subsequent loops, how does the
transaction layer differentiate between this CANCEL and the
retransmissions of the CANCEL for the first loop. My point is
that the CANCEL for every leg in the loop looks exactly identical
(since it contains only one Via header, whose branch is the same)...
so how does it get matched to the corresponding transaction ?
Similarly, when a proxy detects the loop and sends a 484, each
proxy in the loop will send an ACK to the 484 and generate a 484 of
its own. In this case, when a stateful proxy receives an ACK, how does
the transaction layer distinguish whether it is a remote retransmission
for the 484 it sent for the outermost loop (and hence it can be quietly
ignored), or an ACK to a 484 of an inner loop (in which case the
retransmissions of the 484 should be stopped). Again the ACK for each
leg of the loop is identical to the previous, and the transaction layer
will not be able to match it to a unique transaction.
Please let me know if I am missing something here.
Subhash Nayak
Hughes Software Systems
http://www.hssworld.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
