From: Paul Kyzivat <[EMAIL PROTECTED]>
Yes, if the obfuscating proxy performs the loop checking based on its
own Via.
But if you have *two* obfuscating proxies in the loop then I think it
becomes impossible to detect the loop.
In a way, this is similar the a loop that includes both a sip leg and a
PSTN leg.
I don't have a good solution for either of these.
I think that we can/should add a restriction to the text that is
binding on "SBCs" to reduce the risks that they will unintentionally
defeat loop-detection. Of course, that is inherently impossible,
because the SBCs we are talking about are not proxies and don't have
to follow any particular rules. But, IMHO, if we write a restriction
that is workable, there will be some market pressure on SBC vendors
"to be compliant with RFC xxxx" -- not to mention that we will give
vendors some guidance on *how* to avoid defeating loop-detection, and
I've discovered that even if it is "straightforward" that a problem
exists and should be avoided, one cannot in general depend on software
engineers to notice that without being told.
Here is a first draft:
For the purposes of this section, we define "SBC" as: A SIP agent
(which may be a proxy or user agent) which primarily sends SIP
requests and responses in reaction to receiving similar SIP
requests and responses.
An SBC is said to be conformant to this specification if, in any
expected deployment, the universe of all SIP agents will be
divided into a number of sets, which we call "regions", and each
region possesses at least one of the following loop-detection
properties:
A) if all of the agents in the region are assumed to implement
this RFC, no propagating chain of requests can pass through the
same SIP agent in the region twice with the same routing
information without being detected by the mechanism of this RFC
(even if the chain passes through other regions in the meantime),
B) a propagating chain of requests can never enter the region more
than once from any other region while containig the same routing
information, due to cooperation by the SIP agents in the region
containing the SBC (by a mechanism outside the scope of this RFC),
or
C) the administrator of the SBC has positive knowledge that the
technical and/or administrative configuration of the SIP agents in
the region ensures that if a request enters the same SIP agent
twice with the same routing information that it will be rejected as
a looped request (by a mechanism outside the scope of this RFC).
Normally, an SBC (and its redundant cohorts) will divide the universe
into three regions: the SBC and its cohorts, the network "inside"
that they protect, and the public Internet. There seem to be three
ways to prevent loops within any region: (A) assume they implement
loop-detection, and require the SBC to propagate the loop-detection
information in requests when they enter/leave the region, (B) have the
SBCs do it somehow, or (C) *know* that the SIP agents in the region
implement some other form of loop detection.
I would particularly like to know what SBC vendors think of this.
Dale
_______________________________________________
Sip mailing list https://www1.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
