Re: [Sip] Question on loop detection

["Elwell, John" <john.elwell at siemens.com>]

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:rjsparks at nostrum.com] 
> Sent: 04 February 2009 22:08
> To: Elwell, John
> Cc: sip at ietf.org; 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 sip-implementors at cs.columbia.edu for questions on current sip
> > Use sipping at ietf.org for new developments on the application of sip
> 
>