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
