On Thursday 12 July 2007 09:03:39 Klaus Darilion wrote:
Martin Hoffmann wrote:
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.
This was the assumption of the old, and it is unfortunately totaly wrong! See below for more details.
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()
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.
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