[Serusers] [Serdev] loose_route behaviour, detecting single Route with myself

[Klaus Darilion]

Nils Ohlmeier wrote:
> 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!)

Is it really necessary to differ this cases in ser.cfg? I usually just 
t_relay() the ACKs as tm module should know if this is a 2xx ACK or a 
non-2xx ACK.

If you need this information in ser.cfg, then having a function 
t_is_ack_local() would be useful.

regards
klaus

> 
> 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