25 Feb
2004
25 Feb
'04
6:26 p.m.
Hi!
Once again I'm stucked in the loose routing topic, maybe some can answer
my question!
I have ser configured to use RR. At the top of my ser.cfg I have:
# loose-route processing
log(1, "check loose_route ...");
if (loose_route()) {
log(1, "loose_route processing, finished routing!\n");
t_relay();
break;
};
log(1, "no loose_route processing\n");
...
Client A is xlite, which is a loose router, and Client B is Windows
Messenger 4.7, which is a strict router. One client calls the other
client, which accepts the call. Then the client hangs up.
If client A hangs up (xlite, loose router) the loose_route(){...} block
will not be processed and the BYE is handled by the following routing
logic. If client B (strict router) hangs up, the loose_route(){...}
block will be executed.
So, why is the request from xlite (loose router) not treated in the
loose_route block?
IMHO, I would suggest that both requests (loose and strict) should be
handled be the loose_route block. Also RFC3261 (16.4) says that "strict
router" request should be transformed into a loose routing request
(writing the last Route header field into the req-URI and remove this
route header field) and than be handled like all other requests.
Maybe I've missed something.
Regards,
Klaus
25 Feb
25 Feb
6:41 p.m.
On 25-02 17:26, Klaus Darilion wrote:
Hi!
Once again I'm stucked in the loose routing topic, maybe some can answer
my question!
I have ser configured to use RR. At the top of my ser.cfg I have:
# loose-route processing
log(1, "check loose_route ...");
if (loose_route()) {
log(1, "loose_route processing, finished routing!\n");
t_relay();
break;
};
log(1, "no loose_route processing\n");
...
Client A is xlite, which is a loose router, and Client B is Windows
Messenger 4.7, which is a strict router. One client calls the other
client, which accepts the call. Then the client hangs up.
If client A hangs up (xlite, loose router) the loose_route(){...} block
will not be processed and the BYE is handled by the following routing
logic. If client B (strict router) hangs up, the loose_route(){...}
block will be executed.
So, why is the request from xlite (loose router) not treated in the
loose_route block?
IMHO, I would suggest that both requests (loose and strict) should be
handled be the loose_route block. Also RFC3261 (16.4) says that "strict
router" request should be transformed into a loose routing request
(writing the last Route header field into the req-URI and remove this
route header field) and than be handled like all other requests.
First of all loose routing or strict routing (depends on the Route
header fields) is performed even if loose_route function returns 0.
There are some situations in which the message will have the IP
address of the server in the Request-URI and the message, in fact,
will be routed elsewhere (to the IP in the topmost Route header
field).
In this case subsequent if (uri==myself) would match which is wrong.
Therefore loose_route will return 1 in this situation. Note well that
inside the if (loose_route()) condition the message will be not sent
to the host from Request-URI (!).
loose_route function is RFC3261 compliant, it performs both loose and
strict routing, depending on the routeset.
Please speak up if I did not explain it clearly enough and I will try to
make some examples. I am aware that this is hard to understand but you
should understand it well otherwise you might introduce some security
holes to your config (especially when routing to a PSTN gateway).
Jan.
7:56 p.m.
I'm still confused. I try to write it down in my own words as far as I
understand it and hope that somebody will confirm or correct my statements:
So, loose_route does the rewritting of the req-URI (strict routing) and
removing of route headers if there are Route: headers in the request.
After that, the request should be routable by t_relay.
The loose_route function will rewrite the req-URI of "strict_routing"
messages. So the if(uri==myself) statement shouldn't be TRUE anymore, or
does this statement checks the original req-URI?
What is the reason why the BYE message from xlite (loose route) does not
trigger the execution of the (loose_route()){...} block. This would be
nice, so I could do the security checks before forwarding to the PSTN
gateway for both UAs at the same place. Otherwise I would have to do it
2 times (1x for Messenger in the loose_route{ } block, and 1x for xlite
after the loose_route{ } block.
regards,
klaus
Jan Janak wrote:
On 25-02 17:26, Klaus Darilion wrote:
Hi!
Once again I'm stucked in the loose routing topic, maybe some can answer
my question!
I have ser configured to use RR. At the top of my ser.cfg I have:
# loose-route processing
log(1, "check loose_route ...");
if (loose_route()) {
log(1, "loose_route processing, finished routing!\n");
t_relay();
break;
};
log(1, "no loose_route processing\n");
...
Client A is xlite, which is a loose router, and Client B is Windows
Messenger 4.7, which is a strict router. One client calls the other
client, which accepts the call. Then the client hangs up.
If client A hangs up (xlite, loose router) the loose_route(){...} block
will not be processed and the BYE is handled by the following routing
logic. If client B (strict router) hangs up, the loose_route(){...}
block will be executed.
So, why is the request from xlite (loose router) not treated in the
loose_route block?
IMHO, I would suggest that both requests (loose and strict) should be
handled be the loose_route block. Also RFC3261 (16.4) says that "strict
router" request should be transformed into a loose routing request
(writing the last Route header field into the req-URI and remove this
route header field) and than be handled like all other requests.
First of all loose routing or strict routing (depends on the Route
header fields) is performed even if loose_route function returns 0.
There are some situations in which the message will have the IP
address of the server in the Request-URI and the message, in fact,
will be routed elsewhere (to the IP in the topmost Route header
field).
In this case subsequent if (uri==myself) would match which is wrong.
Therefore loose_route will return 1 in this situation. Note well that
inside the if (loose_route()) condition the message will be not sent
to the host from Request-URI (!).
loose_route function is RFC3261 compliant, it performs both loose and
strict routing, depending on the routeset.
Please speak up if I did not explain it clearly enough and I will try to
make some examples. I am aware that this is hard to understand but you
should understand it well otherwise you might introduce some security
holes to your config (especially when routing to a PSTN gateway).
Jan.
9:08 p.m.
On Feb 25, 2004 at 18:56, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
I'm still confused. I try to write it down in my
own words as far as I
understand it and hope that somebody will confirm or correct my statements:
So, loose_route does the rewritting of the req-URI (strict routing) and
removing of route headers if there are Route: headers in the request.
After that, the request should be routable by t_relay.
The loose_route function will rewrite the req-URI of "strict_routing"
messages. So the if(uri==myself) statement shouldn't be TRUE anymore, or
does this statement checks the original req-URI?
No, it checks the "new" uri, so in the strict router case you are right,
it won't match (of course assuming the new uri!= proxy).
In the loose router case, the message will be sent to the loose route
uri (not to the request uri) and the request uri will not be changed,
so your uri==myself could match although the message will be sent
elsewhere.
Andrei
[...]
26 Feb
26 Feb
6:23 p.m.
Andrei Pelinescu-Onciul wrote:
On Feb 25, 2004 at 18:56, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
I'm still confused ... the BYE request from Windows Messenger with a
route-set will be handled be the if(loose_route()){...} block, but not
the BYE request from Xlite with a route-set. But shouldn't also the BYE
from Xlite be processed in the if(loose_route()){...} block? I don't
want to care about in-dialog requests in my routing logic which deals
with voicemail, hunt groups ...
An other possibility would be to remove the t_relay in the loose_route
block, so that all in-dialog requests (Messenger and xlite) are
processed by the following routing logic.
thanks,
klaus
I'm still confused. I try to write it down in
my own words as far as I
understand it and hope that somebody will confirm or correct my statements:
So, loose_route does the rewritting of the req-URI (strict routing) and
removing of route headers if there are Route: headers in the request.
After that, the request should be routable by t_relay.
The loose_route function will rewrite the req-URI of "strict_routing"
messages. So the if(uri==myself) statement shouldn't be TRUE anymore, or
does this statement checks the original req-URI?
No, it checks the "new" uri, so in the strict router case you are right,
it won't match (of course assuming the new uri!= proxy).
In the loose router case, the message will be sent to the loose route
uri (not to the request uri) and the request uri will not be changed,
so your uri==myself could match although the message will be sent
elsewhere.
27 Feb
27 Feb
12:23 a.m.
In some situations ser inserts two Route header fields (for example
UDP->TCP traversal). Such route header fields have a special parameter
so that ser knows that there are two of them and it should remove both
of them when processing the message, example:
Route: <sip:12@ser.host;lr;r2>
Route: <sip:23@ser.host;lr;r2>
Unfortunately there are many broken implementations that remove unknown
parameter from Route header fields and even such that remove lr
parameter so ser can receive:
Route: <sip:12@ser.host>
Route: <sip:23@ser.host>
If a previous host was a strict router, you will receive:
METHOD sip:12@ser.host SIP/2.0
Route: <sip:23@ser.host>
loose_route will rewrite the Request-URI with the route header field and
you will have a message with the IP of your server in the Request-URI.
Now imagine what happends if uri == myself follows.
That's one case, another case is when you receive message like this:
METHOD sip:1.2.3.4@callee
Route: <sip:your_server;lr>
Route: <sip:foreing_server;lr>
Route containing your_server will be removed because it belongs to your
server and the message will be forwarded to "foreign_server". But the
Request-URI does contain a different value -- so all subsequent tests in
the config file which operate on the Request-URI will be wrong.
loose_route returns 1 in those two cases and 0 in all other. When
loose_route returns 1, you know that you should just apply all security
restrictions (like when forwarding to a PSTN gateway) and send the
message. All the tests and modification which are performed when you are
processing a request establishing a dialog should not be applied here.
Jan.
On 26-02 17:23, Klaus Darilion wrote:
Andrei Pelinescu-Onciul wrote:
On Feb 25, 2004 at 18:56, Klaus Darilion
<klaus.mailinglists(a)pernau.at>
wrote:
I'm still confused ... the BYE request from Windows Messenger with a
route-set will be handled be the if(loose_route()){...} block, but not
the BYE request from Xlite with a route-set. But shouldn't also the BYE
from Xlite be processed in the if(loose_route()){...} block? I don't
want to care about in-dialog requests in my routing logic which deals
with voicemail, hunt groups ...
An other possibility would be to remove the t_relay in the loose_route
block, so that all in-dialog requests (Messenger and xlite) are
processed by the following routing logic.
thanks,
klaus
I'm still confused. I try to write it down in
my own words as far as I
understand it and hope that somebody will confirm or correct my
statements:
So, loose_route does the rewritting of the req-URI (strict routing) and
removing of route headers if there are Route: headers in the request.
After that, the request should be routable by t_relay.
The loose_route function will rewrite the req-URI of "strict_routing"
messages. So the if(uri==myself) statement shouldn't be TRUE anymore, or
does this statement checks the original req-URI?
No, it checks the "new" uri, so in the strict router case you are right,
it won't match (of course assuming the new uri!= proxy).
In the loose router case, the message will be sent to the loose route
uri (not to the request uri) and the request uri will not be changed,
so your uri==myself could match although the message will be sent
elsewhere.
7578
days inactive
7579
days old
5 comments
3 participants
participants (3)
-
Andrei Pelinescu-Onciul -
Jan Janak -
Klaus Darilion