Subject: [Sip] Question on loop detection

From: "Elwell, John" <[email-masked]>
Date: Wed, 04 Feb 2009 16:31:25 +0000

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

---

From: Theo Zourzouvillys <[email-masked]>
Date: Wed, 4 Feb 2009 17:00:23 +0000

> have been taken to overcome it? If not, have I misinterpreted RFC 3261?

The behaviour as you described it is correct when the SBC device is a
B2BUA with a single UA core for all sessions flowing through it, which
it isn't - or at least probably isn't what you want.

if instead you considered an SBC to have multiple logical UA cores,
one for each target that it's currently being an SBC for, then that
behaviour would be incorrect (as matching would be done by comparing
all other ongoing transactions within the same UAS core), and both
calls would flow through correctly.

this is how we have had our SBC behaving for the last 3 years without
problem [1].

 ~ Theo

1 - standard SBCs don't exist and it's all in our heads disclaimer applies :)

-- 
Theo Zourzouvillys
Chief Technical Officer
VoIP.co.uk - Commerce House, Telford Road, Bicester, OX26 4LD
Tel: +44 1908 764 196

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 04 Feb 2009 17:24:30 +0000

Theo,

Thanks. That is indeed one solution, but I am not sure all B2BUAs
deployable in such situations behave in this way, so I would welcome
other opinions.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Theo Zourzouvillys
> Sent: 04 February 2009 17:00
> To: Elwell, John
> Cc: [email-masked]; Armenio, Joao
> Subject: Re: [Sip] Question on loop detection
>

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 04 Feb 2009 13:59:07 -0500

> deployable in such situations behave in this way, so I would welcome

I agree with Theo in results, though I'd phrase the answer differently
-- In this case, the SBC is acting as a pseudo-proxy, and so its loop
detection behavior must be different from what a true UAS would do; it
should be detecting loops in the same way that a proxy would.  Otherwise
you would get the functional problem that you describe.

Dale

---

From: Robert Sparks <[email-masked]>
Date: Wed, 4 Feb 2009 16:07:56 -0600

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:

> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

---

From: aayush bhatnagar <[email-masked]>
Date: Thu, 5 Feb 2009 03:43:43 +0000

I dont think the SBC will detect a loop. As per the RFC text above, a
loop situation will occur, only when the request does not match an
ongoing transaction at the UAS(as per the rules mentioned above), but
the call id, from tag and cseq match that of an ''ongoing''
transaction..
This situation will not arise in a parallel forking case, as each
forked branch creates a unique transaction of its own (and hence a
unique from tag).

i have a doubt on why a SBC should behave as a B2BUA? Should it not
behave as a proxy server between 2 sip domains?

aayush.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 05 Feb 2009 13:19:54 +0000

Aayush, 

> From: aayush bhatnagar [mailto:[email-masked]] 
> Sent: 05 February 2009 03:44
> To: Robert Sparks
> Cc: Elwell, John; [email-masked]; Armenio, Joao
[JRE] If an upstream proxy has forked, each branch will have the same
>From tag.

> behave as a proxy server between 2 sip domains?
[JRE] I believe in practice SBCs do behave as B2BUAs, but perhaps not in
this respect. Behaving as proxies in this respect would indeed solve
this problem.

The reason for my original question is that I am aware of a device that
is a UAS and sends 482 when it ought not to, although according to RFC
3261 it is correct in doing so. By behaving as several UASs rather than
a single UAS, it would avoid the problem. But that made me question
whether the problem would also arise in other situations, e.g., with
B2BUAs such as SBCs. The answers I received to date suggest that proxy
behaviour in this respect would get round the problem, so perhaps that
is how such devices work in practice.

John

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 05 Feb 2009 14:03:30 +0000

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 

> From: Robert Sparks [mailto:[email-masked]] 
> Sent: 04 February 2009 22:08
> To: Elwell, John
> > TCP transport the second INVITE request would need to 
> arrive before  
> > the

---

From: aayush bhatnagar <[email-masked]>
Date: Thu, 5 Feb 2009 21:15:04 +0530

>>[JRE] If an upstream proxy has forked, each branch will have the same

True..agreed.

Another thing regarding section 17.2.3. The branch parameter will be
different for each forked branch, as specified by you inline. However,
the transaction matching rules of 17.2.3 you quote inline are
applicable only if the branch parameter is absent, or does not have a
magic cookie. If you have a magic cookie present, the matching wont
fail as per 17.2.3..and subsequently as per 8.2.2.2, there will be no
loop detection.

I suppose your implementation is not following the magic cookie paradigm?

>>this respect. Behaving as proxies in this respect would indeed solve

Whether the SBC acts as a B2BUA or a proxy also depends on the
services that it is offering. If your SBC is handling media, QoS,
admission control,call screening and regulatory services such as
Lawful Intercept, then it will need to act as a B2BUA. It has no
choice.

However, if the SBC only needs to provide a point of interconnect
between trusted/non-trusted domains, then proxy behavior might be
sufficient.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 05 Feb 2009 16:47:46 +0000

Aayush, 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of aayush bhatnagar
> Sent: 05 February 2009 15:45
> To: Elwell, John
[JRE] Whether or not the branch parameter matches, the Request-URI will
not match. So therefore the transactions do not match and the rules for
182 come into play.

> Lawful Intercept, then it will need to act as a B2BUA. It has no
[JRE] I agree, but it might behave as a proxy with respect to this
particular issue.

John

> >> > Questions: Has this problem has been seen in practice? 
> If so, what
> >> > steps

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 05 Feb 2009 15:54:31 -0500

> conditions I describe are conditions for sending a 482 "loop detected".

RFC 3261 is correct but not at all clear in this regard.  There are
*two* error conditions, and RFC 3261 calls both "482 (Loop Detected)".
But in reality, there is "482 (Loop Detected)" and "482 (Merged
Request)".

482 Merged Request is generated by UASs, as described in section
8.2.2.2, and it is based on noticing that two incoming requests
originated as the same UAC request.  But the gotcha is that 8.2.2.2
describes UAS behavior, not proxy behavior.

482 Loop Detected is generated by proxies, as described in section 16.3
item 4, and is based on detecting that this request has an "upstream
ancestor" request that passed through this same proxy.

In regard to a B2BUA acting as an SBC, or a "quasi-proxy" as I like to
call it, it needs to apply the loop detection logic, not the merged
request logic.

Dale