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
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@fokus.fraunhofer.de Date: Fri, 09 Jul 2004 11:29:00 +0200 Sujet: Re: [Serusers] Nathelper question À: ser ser@plexid.com Cc: serusers@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@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
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@fokus.fraunhofer.de Date: Fri, 09 Jul 2004 11:29:00 +0200 Sujet: Re: [Serusers] Nathelper question À: ser ser@plexid.com Cc: serusers@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
--On 10 July 2004 15:31 +1000 Zeus Ng zeus.ng@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
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@lists.iptel.org; Alex Bligh Subject: RE: [Serusers] Nathelper question
--On 10 July 2004 15:31 +1000 Zeus Ng zeus.ng@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
--On 10 July 2004 23:59 +1000 Zeus Ng zeus.ng@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
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@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
-
Alex Bligh -
Bogdan-Andrei IANCU -
ser -
Zeus Ng