<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I vote for a new preloaded_route() in trunk. I also suggest a new alias
for loose_route (or rename and create loose_route as backwards
compatible name): in_dialog() returning true if and only if the message
being processed is and in-dialog message.<br>
g-)<br>
<br>
Nils Ohlmeier wrote:
<blockquote cite="mid:200707120044.58876.nils@iptel.org" type="cite">
<pre wrap="">On Wednesday 11 July 2007 21:57:15 Martin Hoffmann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Exactly.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
</blockquote>
</body>
</html>