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
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.
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.
On Feb 25, 2004 at 18:56, Klaus Darilion klaus.mailinglists@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
[...]
Andrei Pelinescu-Onciul wrote:
On Feb 25, 2004 at 18:56, Klaus Darilion klaus.mailinglists@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.
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
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@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.
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
-
Andrei Pelinescu-Onciul -
Jan Janak -
Klaus Darilion