Aayush, > -----Original Message----- > From: aayush bhatnagar [mailto:[email protected]] > Sent: 05 February 2009 03:44 > To: Robert Sparks > Cc: Elwell, John; [email protected]; Armenio, Joao > Subject: Re: [Sip] Question on loop detection > > I dont think the SBC will detect a loop. As per the RFC text above, a > loop situation will occur, only when the request does not match an > ongoing transaction at the UAS(as per the rules mentioned above), but > the call id, from tag and cseq match that of an ''ongoing'' > transaction.. > This situation will not arise in a parallel forking case, as each > forked branch creates a unique transaction of its own (and hence a > unique from tag). [JRE] If an upstream proxy has forked, each branch will have the same >From tag.
> > i have a doubt on why a SBC should behave as a B2BUA? Should it not > behave as a proxy server between 2 sip domains? [JRE] I believe in practice SBCs do behave as B2BUAs, but perhaps not in this respect. Behaving as proxies in this respect would indeed solve this problem. The reason for my original question is that I am aware of a device that is a UAS and sends 482 when it ought not to, although according to RFC 3261 it is correct in doing so. By behaving as several UASs rather than a single UAS, it would avoid the problem. But that made me question whether the problem would also arise in other situations, e.g., with B2BUAs such as SBCs. The answers I received to date suggest that proxy behaviour in this respect would get round the problem, so perhaps that is how such devices work in practice. John > > aayush. > > On 2/4/09, Robert Sparks <[email protected]> wrote: > > You are describing a merge, not a loop, and as Dale pointed out, if > > the B2BUA is > > playing the role of a proxy, it shouldn't merge detect. If > it's being > > more than a proxy, > > then it needs to choose one and reject the other with the > same kind of > > local-policy > > logic an actual endpoint would use. > > > > RjS > > > > > > On Feb 4, 2009, at 10:31 AM, Elwell, John wrote: > > > >> Apologies if this has been discussed in the past. > >> > >> Consider a domain proxy that is configured to parallel > fork an INVITE > >> request to two targets. As a result it would forward the INVITE > >> request > >> twice, and as far as I can see the two forwarded requests would in > >> general differ only in the following respects: > >> - different Request-URIs (the respective contact URIs); > >> - different top Via header field entries (different branch > >> parameters); > >> - if applicable, different History-Info header field values. > >> > >> Supposing the two new targets are both reachable via the same edge > >> "proxy", which is actually implemented as a B2BUA (e.g., > an SBC). The > >> edge B2BUA would receive one request and shortly afterwards would > >> receive the other request. The similarity and differences > between the > >> two requests are such that, in accordance with RFC 3261, the second > >> request would be treated by the B2BUA (acting as a UAS) as a loop > >> and be > >> rejected with 482, assuming it arrives within a given time > period. For > >> TCP transport the second INVITE request would need to arrive before > >> the > >> ACK relating to the first INVITE request, but for UDP transport the > >> window is extended by T4 seconds. > >> > >> The text concerned in RFC 3261 is in 8.2.2.2: > >> "If the request has no tag in the To header field, the UAS > core MUST > >> check the request against ongoing transactions. If the From tag, > >> Call-ID, and CSeq exactly match those associated with an ongoing > >> transaction, but the request does not match that > transaction (based > >> on the matching rules in Section 17.2.3), the UAS core SHOULD > >> generate a 482 (Loop Detected) response and pass it to the server > >> transaction." > >> in 17.2.3: > >> "The INVITE request matches a transaction if the > Request-URI, To tag, > >> From tag, Call-ID, CSeq, and top Via header field match > those of the > >> INVITE request which created the transaction. In this case, the > >> INVITE is a retransmission of the original one that created the > >> transaction." > >> and in 17.1.2.2: > >> "Once the client transaction enters the "Completed" state, > it MUST set > >> Timer K to fire in T4 seconds for unreliable transports, and zero > >> seconds for reliable transports. The "Completed" state exists to > >> buffer any additional response retransmissions that may > be received > >> (which is why the client transaction remains there only for > >> unreliable transports). T4 represents the amount of time the > >> network > >> will take to clear messages between client and server > transactions. > >> The default value of T4 is 5s." > >> > >> Questions: Has this problem has been seen in practice? If so, what > >> steps > >> have been taken to overcome it? If not, have I misinterpreted RFC > >> 3261? > >> > >> John > >> _______________________________________________ > >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use [email protected] for questions on current sip > >> Use [email protected] for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use [email protected] for questions on current sip > > Use [email protected] for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
