12 Jul
2007
12 Jul
'07
6:39 a.m.
On Thursday 12 July 2007 09:03:39 Klaus Darilion wrote:
No. The To-tag is not enough as criteria for in-dialog. And unfortunately the
presence of Route isn't as well.
You can basically have these type of ACKs (ACKs illustrate the worst case):
- the UAC uses an outbound proxy without a Route header
- the in-dialog ACK will have a To-tag and a Route header
- the out-of-dialog ACK will have a To-tag and no Route header
- the UAC uses a Route header for its outbound proxy
- then in-dialog ACK will have a To-tag and a Route header (same as above)
- the out-of-dialog ACK will have a To-tag and a Route header (and this is
the problematic case!)
The only thing which distinguishes the in-dialog ACKs from the last
out-of-dialog ACK might be the length of the Route header. If the Route
header has the length one it might be an out-of-dialog ACK. But in the worst
case this is equal to an in-dialog ACK with only one Route header. In this
case the only difference will be the RURI.
Martin Hoffmann wrote:
This was the assumption of the old, and it is unfortunately totaly wrong! See
below for more details.
In most cases this is what you want, because the
presence of Routes
indicates an in-dialog message which you want to treat differently (In
Here we see the root problem of the loose_route function: it's naming
and it's usage.
To identify in-dialog messages the only thing to worry about is the
to-tag. Nothing more, nothing less. practice, most
UAs just forward the message to the outgoing proxy
without adding a Route header, which is perfectly legal as well). The
proper test for this, of course, is to check for the presence of a To
tag. But it seems to be common to all SER configs I have seen to misuse
loose_route() in this way.
Yes.
Changing the behaviour of loose_route() yet again
would mess up a lot of
configs as the earlier change messed up a lot of configs (it certainly
cost me a couple of hours debugging). Having another function would
probably be a better approach. Especially, since loose_route() is
actually the wrong name. The function does both loose and static record
routing.
I totally agree with you, e.g:
if (in_dialog()) { # probably an alias to has_totag() process_routes(); # may have different return
values
# -1: no routes found
# -2: only a single route pointing to "myself"
# 1: loose routing done
# 2: strict routing done
... NAT traversal, security checks, ....
t_relay();
exit;
}
process_routes();
# here proceed according to policy, e.g.
# -1, -2: handle now incoming request
# 1, 2: reject out-of-dialog loose/strict-route request
...
Ok, what would be the difference then between this new process_routes()
function and adding more different return values to the existing
loose_route() function?
Nils