Re: [Sip] Loop detection; Not a bad thing to have

["Sachin Shenoy" <sachins@netlab.hcltech.com>]

please find my comments inline.

> > 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.

Max-Forwards did work in this case. But didn't prevent the above mentioned
problem.

> > 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.
>
> It seems your problems are the result of faulty software, not an
> incorrect approach to handling loops.

Let me check and confirm these figures again (will take sometime).
But if I remember correctly the time taken for the request to go 70
hops forward & the "Too May Hops" response to take 70 hops
backwards was enough for the retransmissions to fireup.(Maybe
the implementation chose to queueup too many messages rather than
dropping them and as a result was not able to flush them out
properly). As you said this could be the case of faulty software,
I have to double check it.

> > 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).
>
> Not for any valid loop detection algorithm.

I think this is a known bug in the RFC3261 and has already been logged in
bugzilla.

http://www.sipwg.org/sipwg/show_bug.cgi?id=659


> CANCEL and INVITE will both share the same To, From, Call-ID, CSeq
> number, request-uri, route headers, and a whole bunch of other fields,
> pretty much anything that might be included in a loop detection hash
> (although i still feel that the whole process is brittle and unneeded).

CANCEL & INVITE need not share Require & Proxy-Require fields according
to RFC 3261. RFC 3261 explicilty states that CANCEL MUST NOT have
Require & Proxy-Require (Section 9.1), while INVITE may have them. An
implementation choosing to use these fields for calculating the
loop-detection
part would end up having different value for the hash. Placing this hash in
branch would break the transaction matching rules where CANCEL &
INVITE should have the same branch-id's (Section 9.1).