Aayush, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of aayush bhatnagar > Sent: 05 February 2009 15:45 > To: Elwell, John > Cc: [email protected]; Armenio, Joao > Subject: Re: [Sip] Question on loop detection > > >>[JRE] If an upstream proxy has forked, each branch will > have the same > >>From tag. > > True..agreed. > > Another thing regarding section 17.2.3. The branch parameter will be > different for each forked branch, as specified by you inline. However, > the transaction matching rules of 17.2.3 you quote inline are > applicable only if the branch parameter is absent, or does not have a > magic cookie. If you have a magic cookie present, the matching wont > fail as per 17.2.3..and subsequently as per 8.2.2.2, there will be no > loop detection. [JRE] Whether or not the branch parameter matches, the Request-URI will not match. So therefore the transactions do not match and the rules for 182 come into play.
> > I suppose your implementation is not following the magic > cookie paradigm? > > >>[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. > > Whether the SBC acts as a B2BUA or a proxy also depends on the > services that it is offering. If your SBC is handling media, QoS, > admission control,call screening and regulatory services such as > Lawful Intercept, then it will need to act as a B2BUA. It has no > choice. [JRE] I agree, but it might behave as a proxy with respect to this particular issue. John > > However, if the SBC only needs to provide a point of interconnect > between trusted/non-trusted domains, then proxy behavior might be > sufficient. > > On 2/5/09, Elwell, John <[email protected]> wrote: > > Robert, > > > > It is true this is a merge rather than a loop situation, but the > > conditions I describe are conditions for sending a 482 > "loop detected". > > > > John > > > >> -----Original Message----- > >> From: Robert Sparks [mailto:[email protected]] > >> Sent: 04 February 2009 22:08 > >> To: Elwell, John > >> Cc: [email protected]; Armenio, Joao > >> Subject: Re: [Sip] Question on loop detection > >> > >> 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 > _______________________________________________ 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
