Re: 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