On 02-01 14:46, Franz Edler wrote:
Hi all again,
from various examples in the SER admin_guide and my own SIP knowledge-base I
conclude, that the action "loose-route()" is responsible for correct routing
of those requests, that are not destined to the proxy (host of Request-URI
is not the proxy) and that have a proper Route-header indicating
"loose-routing".
Not really. loose_route() implements record routing. Because it must
be backwards compatible with strict routers, it implements both, loose
routing and strict routing.
It should process all messages that contain Route header fields, even
those that have hostname or IP of the proxy in Request-URI (it can
happen).
You should call loose_route() on every message unless you know what
you are really doing.
As such the action "loose_route()" should be
sufficient to modify the
Request in such a way, that the following action "t-relay()" finishes
processing of the request. Therefore the action short sequence
... if (loose_route()) { t_relay(); break; };
does all, what is necessary for loose routing of those requests.
I think that this one deserves some explanation. The reason why
if (loose_route()) {
t_relay();
}
is needed and why just loose_route(); is not sufficient is as follows:
In some situations, SER needs to insert two Route header fields -- we
call this double record-routing. It is necessary, for example, when a
request comes over UDP and ser sends it over TCP. Suppose the
following situation:
A -- UDP -- SER -- TCP -- B
A sends a SIP message over UDP to ser and ser forwards the message
over TCP to B. Later if B sends a message within dialog, you usually
want it to go the same way -- that means it should be sent over TCP to
ser and ser forwards it over UDP to be.
To achieve this, ser needs to add two Record-Route header fields, one
with UDP transport and one with TCP transport, they will look like
this:
Record-Route: <sip:ser@1.2.3.4;r2;transport=TCP>
Record-Route: <sip:ser@1.2.3.4;r2>
(the only difference is in the parameters). Client B sees the "TCP"
Record-Route first and sends the further messages over TCP. Client A
reverses the order of the header fields and sees the "UDP" Route
first.
Because the ser in the middle created both headers, it also has to
remove both resulting Route header fields. That's what r2 parameter is
for -- it tells ser that another Route header field follows and it should
be removed as well.
Unfortunately there are broken implementations in the wild that strip
parameters that they don't know -- in this case the r2 parameter. ser
will not remove the 2nd Route if the parameter is missing, instead it
would forward the message to it. In some cases it doesn't harm -- the
message will just spiral through the same proxy one more time.
Now the tough part -- in some cases it does harm -- for example when
there are some strict routers along the path. In this case the message
would contain the IP address of ser in the Request-URI (from the 2nd
Route).
In most config files, loose_route() is usually followed by a condition
like this:
if (uri==myself)
and that condition would match (because there is the IP of ser in the
Request-URI). That's wrong, because mid-dialog requests should
not be processed in this part of script.
loose_route() returns true in this case and you must make sure that
if (uri==myself) is not reached.
That's the reason why t_relay() is called inside the condition --
message contained Route headers and shouldn't be processed by the script.
My problem is, that I could not produce a condition,
where "loose_route()"
evaluates to true, so that the action block { t_relay(); break; } is
executed. I expect, that in a simple call-scenario with one record-routing
SIP proxy (SER) the routing of the ACK- and the BYE-method should trigger
the above mentioned "loose_route()" action. But unfortunately it does not.
Why?
See above, this condition is a sort of safety net and normaly it is not
triggered.
You should have t_relay(); at the end of your script which will take
care of all other record-routed requests. See the default config file
for more details.
Jan.