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

[Nils Ohlmeier]

On Wednesday 11 July 2007 21:57:15 Martin Hoffmann wrote:
> Indeed. The only way loose_route() can end up using tel URIs is when
> someone preloaded a message with a Route header and used a tel URI as
> Request-URI, which is perfectly legal.

Exactly.

> As for the return value of loose_route(), behaviour has changed over
> time a bit. In 0.8 it used to return true only if there was yet another
> Route header, ie., it returned false if this proxy was the last one in
> the chain of record routing. This changed sometime in 0.9 to the current
> behaviour to return true whenever there the topmost Route is this proxy.

Yes. My assumption was that loose_route() returns true if the message came to 
the proxy by the usage of Route headers. Or in other words: the routing of 
this message was completely handle by the loose_route function because of the 
presence of correct Route headers.

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

The realization of the fact that the presence or absence of To-tag is not 
enough to decide if a request belongs to a dialog or not. The big exception 
here is the ACK for negative replies. It has a To-tag but a dialog was not 
established.

> 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 agree, changing the return value again would not help. The big question is 
if a preloaded request should be "handled" by the loose_route function?

I guess the best solution would be to have one function preloaded() which 
returns true on preloaded requests and just consumes the Route header. And if 
this function returned true you could treat the request like any other 
incoming request from one of your UAs without a Route header.
Then you would call loose_route() only to take care of the remaining in-dialog 
request (no matter if it is loose or strict routing).

But such a seperation would mean a change in the behavior again, because 
currently preloaded requests are also handled by loose_route() (it returns 
true for these requests). So it would be only an option to change this in 
head.

Cheers
  Nils