Hello everybody,
To remind you, I'm trying to set a SIP architecture for NATTED SIP users without using any rtp proxy (because of lack of ressource). STUN is working very well between 2 users in 2 differents NATs. But when they are behing the same NAT, they cannot reach the other.. In the INVITE and 200Ok SDP fields, they have put their public address with a port reserved with STUN: it's not working! I think that it is because it's difficult for them to reach the public IPaddress/port where they should send the RTP stream from inside the NAT.
So my idea was: Why not rewriting SDP fields to put their private address when they are behind the same NAT But I don't know how to rewrite the SDP fields for both users. (I have the private address of both users in the location database)
Help would be very grateful... If you have any idea!
Best Regards
Marc,
perhaps force_rtp_proxy() is accepting instead of ip an avp, so u can query first the ip in an avp and then push it instead of connection ip.
For applying this only to requests behind the same nat router, you could try following code:
$avp(i:51) = $rd;
if (avp_check("$avp(i:51)","eq/$src_ip/i")){ force_rtp_proxy("c", "$avp(s:yourqueriedavp)"); };
Did not test the scenario, but could be an idea.
DanB
On 8/3/07, Marc LEURENT lftsy@free.fr wrote:
Hello everybody,
To remind you, I'm trying to set a SIP architecture for NATTED SIP users without using any rtp proxy (because of lack of ressource). STUN is working very well between 2 users in 2 differents NATs. But when they are behing the same NAT, they cannot reach the other.. In the INVITE and 200Ok SDP fields, they have put their public address with a port reserved with STUN: it's not working! I think that it is because it's difficult for them to reach the public IPaddress/port where they should send the RTP stream from inside the NAT.
So my idea was: Why not rewriting SDP fields to put their private address when they are behind the same NAT But I don't know how to rewrite the SDP fields for both users. (I have the private address of both users in the location database)
Help would be very grateful... If you have any idea!
Best Regards
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
El Friday 03 August 2007 11:15:57 Marc LEURENT escribió:
Hello everybody,
To remind you, I'm trying to set a SIP architecture for NATTED SIP users without using any rtp proxy (because of lack of ressource). STUN is working very well between 2 users in 2 differents NATs. But when they are behing the same NAT, they cannot reach the other.. In the INVITE and 200Ok SDP fields, they have put their public address with a port reserved with STUN: it's not working! I think that it is because it's difficult for them to reach the public IPaddress/port where they should send the RTP stream from inside the NAT.
So my idea was: Why not rewriting SDP fields to put their private address when they are behind the same NAT But I don't know how to rewrite the SDP fields for both users. (I have the private address of both users in the location database)
In NAT cases I compare the source IP of the caller with the IP where the called is:
NOTE: modparam("usrloc", "nat_bflag", 6)
if (nat_uac_test("19")) { ... setbflag(6); # NAT flag general if (method!="REGISTER") { fix_nated_contact(); setbflag(5); # NAT flag just for the caller
...
if (isbflagset(5)) { # Caller is behind NAT if ( $dd == $si ) { xlog("L_INFO", "Both users behind same NAT, so we dont use RtpProxy\n"); resetbflag(6); # Unset NAT flag general. } }
I think this is better choice than using RtpProxy and setting private IP's in SDP and Contact header.
Hi Iñaki,
in the case of STUN the connection information is already written with public ip, and could be that it is wrong detected (when it comes to port). Therefore u need a way to rewrite this info with the right IP as far as I understood (internal in this case, so the people behind the same NAT should send media directly to internal ip) . Maybe I am mistaken.
DanB
On 8/3/07, Iñaki Baz Castillo ibc@in.ilimit.es wrote:
El Friday 03 August 2007 11:15:57 Marc LEURENT escribió:
Hello everybody,
To remind you, I'm trying to set a SIP architecture for NATTED SIP users without using any rtp proxy (because of lack of ressource). STUN is working very well between 2 users in 2 differents NATs. But when they are behing the same NAT, they cannot reach the other.. In the INVITE and 200Ok SDP fields, they have put their public address with a port reserved with STUN: it's not working! I think that it is because it's difficult for them to reach the public IPaddress/port where they should send the RTP stream from inside the NAT.
So my idea was: Why not rewriting SDP fields to put their private address when they are behind the same NAT But I don't know how to rewrite the SDP fields for both users. (I have the private address of both users in the location database)
In NAT cases I compare the source IP of the caller with the IP where the called is:
NOTE: modparam("usrloc", "nat_bflag", 6)
if (nat_uac_test("19")) { ... setbflag(6); # NAT flag general if (method!="REGISTER") { fix_nated_contact(); setbflag(5); # NAT flag just for the caller
...
if (isbflagset(5)) { # Caller is behind NAT if ( $dd == $si ) { xlog("L_INFO", "Both users behind same NAT, so we dont use RtpProxy\n"); resetbflag(6); # Unset NAT flag general. } }
I think this is better choice than using RtpProxy and setting private IP's in SDP and Contact header.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
El Friday 03 August 2007 12:31:44 Dan-Cristian Bogos escribió:
Hi Iñaki,
in the case of STUN the connection information is already written with public ip, and could be that it is wrong detected (when it comes to port). Therefore u need a way to rewrite this info with the right IP as far as I understood (internal in this case, so the people behind the same NAT should send media directly to internal ip) . Maybe I am mistaken.
Sorry, you are absolutely right, with STUN the client acts as if he is has public IP, sorry.
But when they are behing the same NAT, they cannot reach the other.. In the INVITE and 200Ok SDP fields, they have put their public address with a port reserved with STUN: it's not working! I think that it is because it's difficult for them to reach the public IPaddress/port where they should send the RTP stream from inside the NAT.
Yes, it's an issue that you devices with STUN behind same NAT don't send RTP directly, but to their router IP public. Anyway it should work, it works in my network.
Of course the RTP traffic is sent to the IP public of the router, and the router rewrites that IP to the private IP of the other device. It works as it must work in a common NAT enviroment, it shouldn't be a problem the fact that both devices are behind the same NAT.
Do you have a Linux router where you could rnu a tcpdump or ngrep?
Unfortunately, I use CISCO ADSL routers for the nat...
So you have a working network using only stun? Do you still need nathelper? I suppose that you don't care about detecting the NAT, you send SIP pings to everybody to keep the SIP signaling active. If yes, could you share the corresponding part of your openser.cfg...
Best Regards,
Marc
Iñaki Baz Castillo a écrit :
El Friday 03 August 2007 12:31:44 Dan-Cristian Bogos escribió:
Hi Iñaki,
in the case of STUN the connection information is already written with public ip, and could be that it is wrong detected (when it comes to port). Therefore u need a way to rewrite this info with the right IP as far as I understood (internal in this case, so the people behind the same NAT should send media directly to internal ip) . Maybe I am mistaken.
Sorry, you are absolutely right, with STUN the client acts as if he is has public IP, sorry.
But when they are behing the same NAT, they cannot reach the other.. In the INVITE and 200Ok SDP fields, they have put their public address with a port reserved with STUN: it's not working! I think that it is because it's difficult for them to reach the public IPaddress/port where they should send the RTP stream from inside the NAT.
Yes, it's an issue that you devices with STUN behind same NAT don't send RTP directly, but to their router IP public. Anyway it should work, it works in my network.
Of course the RTP traffic is sent to the IP public of the router, and the router rewrites that IP to the private IP of the other device. It works as it must work in a common NAT enviroment, it shouldn't be a problem the fact that both devices are behind the same NAT.
Do you have a Linux router where you could rnu a tcpdump or ngrep?
El Friday 03 August 2007 13:08:33 Marc LEURENT escribió:
Unfortunately, I use CISCO ADSL routers for the nat...
Upss.
So you have a working network using only stun?
Not in fact, I have OpenSer behind NAT in same lan of SIP devices. I do a NAT test that doesn't test if the IP is a private ona, just test if the source IP differs form the IP of the Contact header. Devices are configured with no STUN, but I tryed some of them with STUN and they can communicate with no problem. Of course the RTP goes trough the NAT router.
Iñaki Baz Castillo writes:
if (isbflagset(5)) { # Caller is behind NAT if ( $dd == $si ) { xlog("L_INFO", "Both users behind same NAT, so we dont use RtpProxy\n"); resetbflag(6); # Unset NAT flag general. } }
if two sip UAs have same public ip address, it does not mean that they would be behind the same nat. there may be another nat box behind the first one. in fact, it is a very common case, when dsl modem includes nat and a few ethernet ports and you connect a wlan ap to one of them.
-- juha
El Friday 03 August 2007 13:26:40 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
if (isbflagset(5)) { # Caller is behind NAT if ( $dd == $si ) { xlog("L_INFO", "Both users behind same NAT, so we dont use RtpProxy\n"); resetbflag(6); # Unset NAT flag general. } }
if two sip UAs have same public ip address, it does not mean that they would be behind the same nat. there may be another nat box behind the first one. in fact, it is a very common case, when dsl modem includes nat and a few ethernet ports and you connect a wlan ap to one of them.
Yes, thanks, obviously my config is not for every NAT case XD
Anyway I'll try to add in a future a solution for that. I could test to if the caller Contact and called Contact are "similar" private IP. Anyway this is not 100% secure since we cannot know which netmask are they using, so we cannot know if they are in fact in same LAN. Any suggestion?
Regards.
-
Dan-Cristian Bogos -
Iñaki Baz Castillo -
jh＠tutpro.com -
Marc LEURENT