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
