inline. Sachin Shenoy wrote:
Please find my comments inline.
That is coupled with the fact that such loop conditions will probably be rare in deployed networks. Unlike IP routing, SIP routing is considerably more static, and I consider the likelihood of real loops a rare one outside of a lab. Thus, its appropriate to handle them in a way which perhaps consumes more resources, at the cost of much lower complexity, and more importantly, proper operation in the normal case. Thats the max-forwards mecahnism. It is much easier to implement, always correct in the normal case (i.e., it won't mis-detect loops), and much more interoperable.
I have to take your word on this (that loops are rare). But sure it creates havoc once
it happens. (Simple tests where request from UA looped between 2 proxies ran for more
than 10 minutes.
That should not happen. Max-Forwards should be preventing that.
Where re transmissions of original INVITE from UA, the "Too Many hops" response and ACK for this just kept on circulating).The INVITE should not be retransmitted once the final response has arrived.
Not for any valid loop detection algorithm.I am at a loss as to why you believe this will solve all the ails of loop detection. It is very easy to combine the functions of unique identification along with the change-detection functions of loop detections. You merely include a transaction ID as part of the long hash you are already doing. I fail to see why that is hard.
Here I was trying to address (solve) a particular problem where stateless
proxies cannot do loop detection. (There was an earlier mail which stated the
problem subject:"[Sip] BranchID in CANCEL & INVITE"). Stateless proxies
have to maintain same branch for CANCEL & INVITE. Now if stateless proxies
try to do loop detection, the branch could turn out to be different for CANCEL
& INVITE. (Loop detection part calculated for CANCEL could be different from
the loop detection part calculated for INVITE).