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
