9 Jul
2004
9 Jul
'04
11:22 a.m.
Hi,
nat_uac_test can be call with parameter :
"1" : via adress is compared to signaling IP
"2" : test if RFC1918 adress
But in some configuration, i see "3". What is it for ? I can't find it in
the nathelper code.
Another question, what happen if two people on the SAME LOCAL network try to call each
other via my SER server ?
Their adress will be detected as private and rtpproxy will be use, but it's not needed
as they are visible for each other.
How could i prevent this ?
Thanks
9 Jul
9 Jul
11:29 a.m.
hello ser :-),
see comments inline.
bogdan
ser wrote:
Hi,
nat_uac_test can be call with parameter :
"1" : via adress is compared to signaling IP
"2" : test if RFC1918 adress
But in some configuration, i see "3". What is it for ? I can't find it in
the nathelper code.
3 means to do both tests.
Another question, what happen if two people on the SAME
LOCAL network try to call each other via my SER server ?
Their adress will be detected as private and rtpproxy will be use, but it's not needed
as they are visible for each other.
How could i prevent this ?
for the moment you cannot. maybe in the next release will be available a
function that tells you if both nated users (callee and caller) are
behind the same NAT.
Thanks
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
11:41 a.m.
Thanks.
It's a real problem!
If a company have employee using my SER server to make calls to the PSTN via my gateway,
and they want to be able to make internall call too, all their calls will go via my
rtpproxy ?
No idea on how configure ser to prevent this ?
----- Message d'origine -----
De: Bogdan-Andrei IANCU <iancu(a)fokus.fraunhofer.de>
Date: Fri, 09 Jul 2004 11:29:00 +0200
Sujet: Re: [Serusers] Nathelper question
À: ser <ser(a)plexid.com>
Cc: serusers(a)iptel.org
hello ser :-),
see comments inline.
bogdan
ser wrote:
Hi,
nat_uac_test can be call with parameter :
"1" : via adress is compared to signaling IP
"2" : test if RFC1918 adress
But in some configuration, i see "3". What is it for ? I can't find it in
the nathelper code.
3 means to do both tests.
Another question, what happen if two people on the
SAME LOCAL network try to call each other via my SER server ?
Their adress will be detected as private and rtpproxy will be use, but it's not needed
as they are visible for each other.
How could i prevent this ?
for the moment you cannot. maybe in the next release will be available a
function that tells you if both nated users (callee and caller) are
behind the same NAT.
Thanks
_______________________________________________
Serusers mailing list
Serusers(a)iptel.org
http://mail.iptel.org/mailman/listinfo/serusers
12:24 p.m.
ser wrote:
Thanks.
It's a real problem!
If a company have employee using my SER server to make calls to the PSTN via my gateway,
and they want to be able to make internall call too, all their calls will go via my
rtpproxy ?
for the moment no, the limitation is in nathelper, not in rtpproxy. you
can add a small function in nathelper that test if the src_ip on request
is the same with the one in RURI ( after you did lookup("location") in
script); be sure that both caller and callee are nated.
bogdan
No idea on how configure ser to prevent this ?
----- Message d'origine -----
De: Bogdan-Andrei IANCU <iancu(a)fokus.fraunhofer.de>
Date: Fri, 09 Jul 2004 11:29:00 +0200
Sujet: Re: [Serusers] Nathelper question
À: ser <ser(a)plexid.com>
Cc: serusers(a)lists.iptel.org
hello ser :-),
see comments inline.
bogdan
ser wrote:
Hi,
nat_uac_test can be call with parameter :
"1" : via adress is compared to signaling IP
"2" : test if RFC1918 adress
But in some configuration, i see "3". What is it for ? I can't find it in
the nathelper code.
3 means to do both tests.
Another question, what happen if two people on the
SAME LOCAL network try to call each other via my SER server ?
Their adress will be detected as private and rtpproxy will be use, but it's not needed
as they are visible for each other.
How could i prevent this ?
for the moment you cannot. maybe in the next release will be available a
function that tells you if both nated users (callee and caller) are
behind the same NAT.
Thanks
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
10 Jul
10 Jul
7:31 a.m.
The following routine should give you a general idea how to handle this
situation. Basically, don't do rtp proxy when both caller and callee are
behind same NAT. Just change their contact address for signalling.
Flag 4 is set when the caller is behind NAT.
Flag 5 is set when the callee is behind NAT.
if (method=="INVITE") {
if (isflagset(4) && isflagset(5)) { /* NAT source & NAT dest. */
if (!exec_msg('echo $SIP_RURI | cut -d: -f2 | cut -d@ -f2 | grep
"$SIP_SRCIP" > /dev/null')) {
xlog("L_NOTICE", "UAs behind different NAT devices, forcing
rtpproxy\n");
force_rtp_proxy();
t_on_reply("2");
} else {
xlog("L_NOTICE", "UAs behind same NAT devices\n");
t_on_reply("3");
}
... Other situation, NAT -> Public, Public -> NAT ...
}
onreply_route[2] {
if (t_check_status("200") || t_check_status("183")) {
if (isflagset(5)) {
fix_nated_contact();
};
force_rtp_proxy();
};
};
onreply_route[3] {
if (t_check_status("200") || t_check_status("183")) {
if (isflagset(5)) {
fix_nated_contact();
};
};
};
Another question, what happen if two people on the SAME LOCAL
network try to call each other via my SER server ?
Their adress will be detected as private and rtpproxy will be
use, but it's not needed as they are visible for each other.
How could i prevent this ?
Thanks
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
12:36 p.m.
--On 10 July 2004 15:31 +1000 Zeus Ng <zeus.ng(a)isquare.com.au> wrote:
if (method=="INVITE") {
if (isflagset(4) && isflagset(5)) { /* NAT source & NAT dest. */
if (!exec_msg('echo $SIP_RURI | cut -d: -f2 | cut -d@ -f2 | grep
"$SIP_SRCIP" > /dev/null')) {
xlog("L_NOTICE", "UAs behind different NAT devices, forcing
rtpproxy\n");
force_rtp_proxy();
t_on_reply("2");
} else {
xlog("L_NOTICE", "UAs behind same NAT devices\n");
t_on_reply("3");
}
... Other situation, NAT -> Public, Public -> NAT ...
}
For the sake of pedantry, I think that test will give a false positive
(i.e. wrongly treat caller and callee as being behind the same NAT)
in situations similar to:
10.0.0.1 A -> NAT1 -192.168.0.1 \
|--> NAT3 --> 195.1.1.1 Internet
10.0.0.2 B -> NAT2 -192.168.0.2 /
Alex
3:59 p.m.
Alex,
Can you redraw your diagram and place ser in the path as well. I don't
understand what you are trying to illustrate.
Personally, I've tried UAs behind two / three layers of NAT and it works, if
it's what you are trying to say.
Yes, there are situations where the logic break. Mostly, if one UA is behind
two NAT, one inner and one outer. The second UA is behind the same outer
NAT. As a service provider, it's not my problem. My logic perfectly handles
the outer NAT. As for the inner NAT, the client has to figure it out
internally.
Zeus
-----Original Message-----
From: Alex Bligh [mailto:alex@alex.org.uk]
Sent: Saturday, 10 July 2004 8:36 PM
To: Zeus Ng; 'ser'
Cc: serusers(a)lists.iptel.org; Alex Bligh
Subject: RE: [Serusers] Nathelper question
--On 10 July 2004 15:31 +1000 Zeus Ng <zeus.ng(a)isquare.com.au> wrote:
if (method=="INVITE") {
if (isflagset(4) && isflagset(5)) { /* NAT source & NAT dest. */
if (!exec_msg('echo $SIP_RURI | cut -d: -f2 | cut -d@
-f2 | grep
"$SIP_SRCIP" > /dev/null')) {
xlog("L_NOTICE", "UAs behind different NAT devices, forcing
rtpproxy\n");
force_rtp_proxy();
t_on_reply("2");
} else {
xlog("L_NOTICE", "UAs behind same NAT devices\n");
t_on_reply("3");
}
... Other situation, NAT -> Public, Public -> NAT ...
}
For the sake of pedantry, I think that test will give a false
positive (i.e. wrongly treat caller and callee as being
behind the same NAT) in situations similar to:
10.0.0.1 A -> NAT1 -192.168.0.1 \
|--> NAT3 --> 195.1.1.1
Internet 10.0.0.2 B -> NAT2 -192.168.0.2 /
Alex
12 Jul
12 Jul
11:39 a.m.
--On 10 July 2004 23:59 +1000 Zeus Ng <zeus.ng(a)isquare.com.au> wrote:
Can you redraw your diagram and place ser in the path
as well. I don't
understand what you are trying to illustrate.
10.0.0.1 A -> NAT1 -192.168.0.1 \
|--> NAT3 --> 195.1.1.1 Internet -> Ser
10.0.0.2 B -> NAT2 -192.168.0.2 /
Personally, I've tried UAs behind two / three
layers of NAT and it works,
if it's what you are trying to say.
Yes, there are situations where the logic break. Mostly, if one UA is
behind two NAT, one inner and one outer. The second UA is behind the same
outer NAT. As a service provider, it's not my problem. My logic perfectly
handles the outer NAT. As for the inner NAT, the client has to figure it
out internally.
Indeed - I was trying to illustrate a situation where the two UAs
are behind the same outer NAT but not behind the same inner NAT. As far
as I can see the test uses the heuristic that the UAs are behind the
same LAN if the packet source/dest IP (i.e. routable addresses) are the
same. This heuristic fails when they are behind the same outer NAT
(same routable IP) but not behind the same inner NAT. It also fails
in circustances like this (AFAICS):
10.0.0.1 A -\ 10.0.0.0/8
|
| 195.1.1.1/24
NAT ---------------> Internet -> Ser
|
|
192.168.0.1 B -/ 192.168.0.0/16
i.e. where you have a dual-private-ported NAT (for instance a corporate LAN
and a lab LAN) with the same external IP.
Alex
13 Jul
13 Jul
2:16 a.m.
Certainly, I agree with you that the checking has its own weakness, I admit
it and I'm well aware of it.
This applies to some cable ISP as well as large organisation. For the
majority DSL users, I rarely have any trouble.
For users using cable ISP that NATed their internet connection, I do have
logic to check that and will force rtp proxying. However, they still have
trouble with other P2P applications. One by one, these users are moving away
from this kind of cable.
As for large organisation, most of them are deploying this kind of service
in-house. Also, they are responsible to maintain reasonable routing within
their organisation. If they are using two NATs to prevent communication from
one network to another network, I don't want to be the middle man helping
their users to violate their company policy.
Hopefully, all those whose adopt my logic understand what they are doing.
Zeus
--On 10 July 2004 23:59 +1000 Zeus Ng
<zeus.ng(a)isquare.com.au> wrote:
Can you redraw your diagram and place ser in the
path as
well. I don't
understand what you are trying to illustrate.
10.0.0.1 A -> NAT1 -192.168.0.1 \
|--> NAT3 --> 195.1.1.1
Internet -> Ser 10.0.0.2 B -> NAT2 -192.168.0.2 /
Personally, I've tried UAs behind two / three
layers of NAT and it
works, if it's what you are trying to say.
Yes, there are situations where the logic break. Mostly, if
one UA is
behind two NAT, one inner and one outer. The
second UA is
behind the
same outer NAT. As a service provider, it's
not my problem.
My logic
perfectly handles the outer NAT. As for the inner
NAT, the
client has
to figure it out internally.
Indeed - I was trying to illustrate a situation where the two
UAs are behind the same outer NAT but not behind the same
inner NAT. As far as I can see the test uses the heuristic
that the UAs are behind the same LAN if the packet
source/dest IP (i.e. routable addresses) are the same. This
heuristic fails when they are behind the same outer NAT (same
routable IP) but not behind the same inner NAT. It also fails
in circustances like this (AFAICS):
10.0.0.1 A -\ 10.0.0.0/8
|
| 195.1.1.1/24
NAT ---------------> Internet -> Ser
|
|
192.168.0.1 B -/ 192.168.0.0/16
i.e. where you have a dual-private-ported NAT (for instance a
corporate LAN and a lab LAN) with the same external IP.
Alex
7416
days inactive
7420
days old
8 comments
4 participants
participants (4)
-
Alex Bligh -
Bogdan-Andrei IANCU -
ser -
Zeus Ng