15 Jun
2007
15 Jun
'07
2:32 p.m.
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);
};
--
Andreas Sikkema
15 Jun
15 Jun
2:39 p.m.
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
2:39 p.m.
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 -- use
From=id next time (gw)");
exit;
};
};
if (is_uri_host_local())
{
log("ATS: incoming message is for a local host ($tu)");
route(3);
};
3:04 p.m.
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
18 Jun
18 Jun
9:21 a.m.
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...
19 Jun
19 Jun
12:29 a.m.
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(a)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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6346
days inactive
6349
days old
5 comments
3 participants
participants (3)
-
Andreas Sikkema -
Klaus Darilion -
Max Gregorian