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