Hi,
Yesterday I noticed something strange happenign one on of our servers. Calls were being sent to servers within our VoIP platform by OpenSER without (as far as I can see) really being handled according to our OpenSER configuration.
When I looked into it, I found that the Request-URI contained the IP address of the internal server, instead of the IP address of our OpenSER machine or our SIP domain.
How can I check that the Request-URI contains only the SIP domain or the IP address of the OpenSER server?
Might this have something to do with the loose_route() block?
Here's (heavily edited) basically our INVITE handling code from openser.cfg:
if (loose_route()) { use_media_proxy();
t_relay(); exit; };
if (method=="INVITE") { t_on_reply("1");
rewritehost("SIP_DOMAIN");
# Check if it is international number format if (uri=~"^sip:00") { strip(2); };
if ( (method == "INVITE") ) { if (!proxy_authorize("SIP_DOMAIN", "subscriber")) { proxy_challenge("SIP_DOMAIN", "0"); exit; };
# let's check from=id ... avoids accounting confusion if (!check_from()) { sl_send_reply("403", "That is ugly -- use From=id next time (gw)"); exit; }; };
if (is_uri_host_local()) { log("ATS: incoming message is for a local host ($tu)");
route(3); };
Yesterday I noticed something strange happenign one on of our servers. Calls were being sent to servers within our VoIP platform by OpenSER without (as far as I can see) really being handled according to our OpenSER configuration.
What I forgot to emntion that the rewrites later in the config should have matched, but they are not being executed which suggests to me that an earlier statement in the config resulted in the message being sent directly to the server instead of first following the configuration.
Andreas Sikkema wrote:
Hi,
Yesterday I noticed something strange happenign one on of our servers. Calls were being sent to servers within our VoIP platform by OpenSER without (as far as I can see) really being handled according to our OpenSER configuration.
When I looked into it, I found that the Request-URI contained the IP address of the internal server, instead of the IP address of our OpenSER machine or our SIP domain.
Maybe someone sent a SIP message with the local IP address in the R-URI to your proxy. According to your config this should not matter as you rewrite the domain for every incoming SIP request - except for loose-route.
For loose-route I would suggest to check for a to-tag too. Then, the called SIP UA should reject the call. You could also use dialog module to see if a dialog exists before forwarding in loose_route.
regards klaus
How can I check that the Request-URI contains only the SIP domain or the IP address of the OpenSER server?
Might this have something to do with the loose_route() block?
Here's (heavily edited) basically our INVITE handling code from openser.cfg:
if (loose_route()) { use_media_proxy();
t_relay(); exit; };
if (method=="INVITE") { t_on_reply("1");
rewritehost("SIP_DOMAIN");
# Check if it is international number format if (uri=~"^sip:00") { strip(2); };
if ( (method == "INVITE") ) { if (!proxy_authorize("SIP_DOMAIN", "subscriber")) { proxy_challenge("SIP_DOMAIN", "0"); exit; };
# let's check from=id ... avoids accounting confusion if (!check_from()) { sl_send_reply("403", "That is ugly -- useFrom=id next time (gw)"); exit; }; };
if (is_uri_host_local()) { log("ATS: incoming message is for a local host ($tu)");
route(3);};
Klaus,
Maybe someone sent a SIP message with the local IP address in the R-URI to your proxy. According to your config this should not matter as you rewrite the domain for every incoming SIP request - except for loose-route.
The IP address in the Request-URI is one that for some reason (incorrect configuration?) is being sent by the SIP UA. This IP address is NOT the same machine as OpenSER...
The loose_route block could indeed be the culprit here. Is there a way I can see in an INVITE being sent to OpenSER that loose_route() will
return true?
This is the (sanitized) INVITE that is causing the problems:
INVITE sip:[NUMBER]@[WRONG_IP_ADDRES] SIP/2.0 Call-ID: 6181509477cc0df82db6313a276492d5@[SIP_DOMAIN] From: sip:[USERNAME]@[IPADDRESS_PROXY]:[PROXYPORT];tag=45fa8 To: "[NUMBER]" sip:[NUMBER]@[SIP_DOMAIN];tag=as52bb63c2 CSeq: 101 INVITE Via: SIP/2.0/UDP 10.1.2.71:5060;branch=z9hG4bK-45a33f186083645f5232ca79048af818 Contact: "[USERNAME]" sip:[USERNAME]@10.1.2.71:5060 Max-Forwards: 70 Route: sip:[IPADDRESS_PROXY]:[PROXYPORT];lr User-Agent: [USER_AGENT] Supported: timer Content-Type: application/sdp Content-Length: 151
(I've removed the body of the message; it's not very interesting here)
The problem is that the Request-URI contains [WRONG_IP_ADDRESS]. When this OpenSER receives an INVITE it should never forward the INVITE to an IP address a SIP UA has added to the Request-URI. OpenSER should be the one
to decide this.
So far we've never had any issues in this area, so I don't want to change too much in the config (like removing the whole loose_route() stuff) unless that is the only way I can solve this problem.
If the Request-URI would have been correct, [NUMBER] would have been rewritten to something usefull and the call would have succeeded.
For loose-route I would suggest to check for a to-tag too. Then, the called SIP UA should reject the call. You could also use dialog module to see if a dialog exists before forwarding in loose_route.
How would checking for a to_tag help? There is no existing Ddialog; this
is handling the initial INVITE message where it already goes wrong...
I do not think that this is a bad configuration. If the WRONG_IP_ADDRESS is the IP address of a gateway this would be a simple approach to bypass the billing logic in the SIP proxy to achieve free calls.
The INVITE is perfectly valid. For example, if a sip:alice@atlanta calls sip:bob@biloxy the Atlanta SIP proxy sees a similar request. (although usually the To URI would be the same as the RURI).
You could: screen the RURI for bad IP addresses (manually or by using the permission module).
regards klaus
Andreas Sikkema wrote:
Klaus,
Maybe someone sent a SIP message with the local IP address in the R-URI to your proxy. According to your config this should not matter as you rewrite the domain for every incoming SIP request - except for loose-route.
The IP address in the Request-URI is one that for some reason (incorrect configuration?) is being sent by the SIP UA. This IP address is NOT the same machine as OpenSER...
The loose_route block could indeed be the culprit here. Is there a way I can see in an INVITE being sent to OpenSER that loose_route() will
return true?
This is the (sanitized) INVITE that is causing the problems:
INVITE sip:[NUMBER]@[WRONG_IP_ADDRES] SIP/2.0 Call-ID: 6181509477cc0df82db6313a276492d5@[SIP_DOMAIN] From: sip:[USERNAME]@[IPADDRESS_PROXY]:[PROXYPORT];tag=45fa8 To: "[NUMBER]" sip:[NUMBER]@[SIP_DOMAIN];tag=as52bb63c2 CSeq: 101 INVITE Via: SIP/2.0/UDP 10.1.2.71:5060;branch=z9hG4bK-45a33f186083645f5232ca79048af818 Contact: "[USERNAME]" sip:[USERNAME]@10.1.2.71:5060 Max-Forwards: 70 Route: sip:[IPADDRESS_PROXY]:[PROXYPORT];lr User-Agent: [USER_AGENT] Supported: timer Content-Type: application/sdp Content-Length: 151
(I've removed the body of the message; it's not very interesting here)
The problem is that the Request-URI contains [WRONG_IP_ADDRESS]. When this OpenSER receives an INVITE it should never forward the INVITE to an IP address a SIP UA has added to the Request-URI. OpenSER should be the one
to decide this.
So far we've never had any issues in this area, so I don't want to change too much in the config (like removing the whole loose_route() stuff) unless that is the only way I can solve this problem.
If the Request-URI would have been correct, [NUMBER] would have been rewritten to something usefull and the call would have succeeded.
For loose-route I would suggest to check for a to-tag too. Then, the called SIP UA should reject the call. You could also use dialog module to see if a dialog exists before forwarding in loose_route.
How would checking for a to_tag help? There is no existing Ddialog; this
is handling the initial INVITE message where it already goes wrong...
Firstly, how about putting logging in the Loose route section to check for a) when it is entered b) if/when this particular R-URI enters the Loose route section (making sure you print out the R-URI using pseudo-variable just to be sure it is the right one).
Secondly, what about other sections of the script. Typically you would have things like *if (uri == myself)* in which case the *if (uri != myself)*might probably be handling other logic for when this condition is not true - perhaps not in this case though since you are using *if (is_uri_host_local())*.
Thirdly, could it be something you are doing the main routing section as is does not appear in the script excerpt provided? (i.e. the bit where you actually t_relay() to the destination.)
Finally is it possible the user has configured their device to use your OpenSER server as an outbound proxy? This may explain if/why the INVITE is being routed through the Loose route section (assuming it is).
On 15/06/07, Andreas Sikkema andreas.sikkema@bbeyond.nl wrote:
Klaus,
Maybe someone sent a SIP message with the local IP address in the R-URI to your proxy. According to your config this should not matter as you rewrite the domain for every incoming SIP request - except for loose-route.
The IP address in the Request-URI is one that for some reason (incorrect configuration?) is being sent by the SIP UA. This IP address is NOT the same machine as OpenSER...
The loose_route block could indeed be the culprit here. Is there a way I can see in an INVITE being sent to OpenSER that loose_route() will
return true?
This is the (sanitized) INVITE that is causing the problems:
INVITE sip:[NUMBER]@[WRONG_IP_ADDRES] SIP/2.0 Call-ID: 6181509477cc0df82db6313a276492d5@[SIP_DOMAIN] From: sip:[USERNAME]@[IPADDRESS_PROXY]:[PROXYPORT];tag=45fa8 To: "[NUMBER]" sip:[NUMBER]@[SIP_DOMAIN];tag=as52bb63c2 CSeq: 101 INVITE Via: SIP/2.0/UDP 10.1.2.71:5060;branch=z9hG4bK-45a33f186083645f5232ca79048af818 Contact: "[USERNAME]" sip:[USERNAME]@10.1.2.71:5060 Max-Forwards: 70 Route: sip:[IPADDRESS_PROXY]:[PROXYPORT];lr User-Agent: [USER_AGENT] Supported: timer Content-Type: application/sdp Content-Length: 151
(I've removed the body of the message; it's not very interesting here)
The problem is that the Request-URI contains [WRONG_IP_ADDRESS]. When this OpenSER receives an INVITE it should never forward the INVITE to an IP address a SIP UA has added to the Request-URI. OpenSER should be the one
to decide this.
So far we've never had any issues in this area, so I don't want to change too much in the config (like removing the whole loose_route() stuff) unless that is the only way I can solve this problem.
If the Request-URI would have been correct, [NUMBER] would have been rewritten to something usefull and the call would have succeeded.
For loose-route I would suggest to check for a to-tag too. Then, the called SIP UA should reject the call. You could also use dialog module to see if a dialog exists before forwarding in loose_route.
How would checking for a to_tag help? There is no existing Ddialog; this
is handling the initial INVITE message where it already goes wrong...
-- Andreas Sikkema BBeyond Software Engineer Planeetbaan 4 +31 (0)23 7074342 2132 HZ Hoofddorp
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-
Andreas Sikkema -
Klaus Darilion -
Max Gregorian