Hi,
I have a problem with openser and rtpproxy. I'm trying to use them as a gateway between the public internet and a LAN. Clients in the internet may be natted, so I'm using nathelper. Calls are only made from LAN to outside or vice versa, but not from LAN to LAN or from outside to outside. The following should illustrate my configuation:
----- ------------------ UAC1 --- | NAT | ------------- | OpenSER/rtpproxy | ----------------UAC2 ----- ------------------ | | | | | dynamic public IP 2.3.4.5 192.168.103.121 192.168.103.189 (e.g. 1.2.3.4)
UAC1 and UAC2 are both registered at OpenSER. Now I'm making a call from UAC1 to UAC2. SIP messages are passed just fine, but the RTP traffic from UAC2 to UAC1 is dropped at the NAT. I used tcpdump on the OpenSER/rtpproxy machine to figure out what happens to RTP and it shows the following (ports and IPs are just examples):
stream1: 1.2.3.4:10000 -> 2.3.4.5:35000 ->RTP is forwarded by rtpproxy-> 192.168.103.121:35000 -> 192.168.103.189:11000 stream2: 1.2.3.4:20000 <- 2.3.4.5:35000 <-RTP is forwarded by rtpproxy<- 192.168.103.121:35000 <- 192.168.103.189:11000
Port 20000 in stream2 is the RTP-port used internally by UAC1 behind the NAT (this port is found in the INVITE from UAC1 to OpenSER). I understand, that rtpproxy sends the first packets to port 20000. But, after receiving some packets from port 10000, shouldn't it change the destination port to 20000 so they can pass the NAT? rtpproxy is started like this: "./rtpproxy -l 192.168.103.121/2.3.4.5 -f ". It produces the following output:
[root@192 rtpproxy]# /usr/local/bin/rtpproxy -l 192.168.103.121/2.3.4.5 -f rtpproxy started, pid 22125 received command "UIE 9D740CB7-18A4-40B2-A96D-13FC3C5B27D3@192.168.103.189 192.168.103.189 49156 207860870326595;1" new session 9D740CB7-18A4-40B2-A96D-13FC3C5B27D3@192.168.103.189, tag 207860870326595;1 requested, type strong new session on a port 35000 created, tag 207860870326595;1 pre-filling caller's address with 192.168.103.189:49156 sending reply "35000 2.3.4.5 " received command "L 9D740CB7-18A4-40B2-A96D-13FC3C5B27D3@192.168.103.189 1.2.3.4 49154 207860870326595;1 5364140283;1" lookup on ports 35000/35000, session timer restarted pre-filling callee's address with 1.2.3.4:49154 sending reply "35000 192.168.103.121
In my openser.cfg I'm not really checking wheter a client is really natted, but I think it shouldn't be a problem to assume, that all clients are behind a NAT? I attached the openser.cfg to this mail (real public IP is changed to 2.3.4.5). Do you have any ideas how to fix this problem? Any help would be greatly appreciated!
Thanks, Christian
# $Id: nat-rtpproxy.cfg 51 2006-01-31 13:28:04Z /CN=Paul Hazlett/emailAddress=paul@onsip.org $
#/usr/local/bin/rtpproxy -l 192.168.103.121/2.3.4.5 -f debug=6 fork=yes log_stderror=no log_facility=LOG_LOCAL1
listen=192.168.103.121 # Internal IP listen=2.3.4.5 # External IP port=5060 children=4
dns=no rev_dns=no
#set module path mpath="/usr/local/lib/openser/modules/"
loadmodule "mysql.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "auth.so" loadmodule "auth_db.so" loadmodule "uri.so" loadmodule "uri_db.so" loadmodule "nathelper.so" loadmodule "textops.so" loadmodule "mi_fifo.so"
modparam("auth_db|uri_db|usrloc", "db_url", "mysql://xxx:yyy@192.168.103.122/openser") modparam("auth_db", "calculate_ha1", 1) modparam("auth_db", "password_column", "password")
modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "rtpproxy_sock", "unix:/home/sys/bin/rtpproxy.sock")
modparam("nathelper", "received_avp", "$avp(s:rcv)") modparam("registrar", "received_avp", "$avp(s:rcv)")
modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
modparam("usrloc", "db_mode", 2)
modparam("usrloc", "nat_bflag", 6)
modparam("rr", "enable_full_lr", 1)
route {
setflag(1); # log this msg
# ----------------------------------------------------------------- # Sanity Check Section # ----------------------------------------------------------------- if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); return; };
if (msg:len > max_len) { sl_send_reply("513", "Message Overflow"); return; };
# ----------------------------------------------------------------- # Record Route Section # ----------------------------------------------------------------- if (method!="REGISTER") { record_route(); };
if (method=="BYE" || method=="CANCEL") { unforce_rtp_proxy(); }
# ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- if (loose_route()) {
if ((method=="INVITE" || method=="REFER") && !has_totag()) { sl_send_reply("403", "Forbidden"); return; };
if (method=="INVITE") {
setflag(6); force_rport(); fix_nated_contact();
if (dst_ip == 192.168.103.121){ force_rtp_proxy("faie"); } else { force_rtp_proxy("faei"); } }; route(1); return; };
# ----------------------------------------------------------------- # Call Type Processing Section # ----------------------------------------------------------------- if (uri!=myself) { route(4); route(1); return; };
if (method=="ACK") { route(1); return; } else if (method=="CANCEL") { route(1); return; } else if (method=="INVITE") { route(3); return; } else if (method=="REGISTER") { route(2); return; };
lookup("aliases"); if (uri!=myself) { route(4); route(1); return; };
if (!lookup("location")) { sl_send_reply("404", "User Not Found"); return; };
route(1); }
route[1] {
# ----------------------------------------------------------------- # Default Message Handler # -----------------------------------------------------------------
t_on_reply("1");
if (!t_relay()) { if (method=="INVITE" && isflagset(6)) { unforce_rtp_proxy(); }; sl_reply_error(); }; }
route[2] {
# ----------------------------------------------------------------- # REGISTER Message Handler # ----------------------------------------------------------------
setflag(6); fix_nated_register(); force_rport();
sl_send_reply("100", "Trying"); if (!save("location")) { log(1,"Error :-(.\n"); sl_reply_error(); }; }
route[3] {
# ----------------------------------------------------------------- # INVITE Message Handler # -----------------------------------------------------------------
setflag(6); lookup("aliases"); if (uri!=myself) { route(4); route(1); return; };
if (!lookup("location")) { sl_send_reply("404", "User Not Found"); return; };
route(4); route(1); }
route[4] {
# ----------------------------------------------------------------- # NAT Traversal Section # -----------------------------------------------------------------
force_rport(); fix_nated_contact(); if (dst_ip == 192.168.103.121){ log(1,"INVITE 4 intern extern\n"); force_rtp_proxy("fie"); } else { log(1,"INVITE 4 extern intern\n"); force_rtp_proxy("fei"); } }
onreply_route[1] {
force_rtp_proxy("f"); fix_nated_contact(); }
Just in case anybody is facing the same problem: I found the solution for this configuration. rtpproxy handles the bridging mode in a way which doesn't fit my configuration. It assumes UAC1 is not behind a NAT. So you have to remove the following line from the rtpproxy code and recompile:
asymmetric = (bmode != 0) ? 1 : 0;
See also: http://lists.iptel.org/pipermail/serusers/2004-June/009305.html
I will ask on the rtpproxy mailing list for the reasons for this behaviour, as I think it may be a bug.
Christian Koch schrieb:
Hi,
I have a problem with openser and rtpproxy. I'm trying to use them as a gateway between the public internet and a LAN. Clients in the internet may be natted, so I'm using nathelper. Calls are only made from LAN to outside or vice versa, but not from LAN to LAN or from outside to outside. The following should illustrate my configuation: ----- ------------------ UAC1 --- | NAT | ------------- | OpenSER/rtpproxy | ----------------UAC2 ----- ------------------ | | | | | dynamic public IP 2.3.4.5 192.168.103.121 192.168.103.189 (e.g. 1.2.3.4) UAC1 and UAC2 are both registered at OpenSER. Now I'm making a call from UAC1 to UAC2. SIP messages are passed just fine, but the RTP traffic from UAC2 to UAC1 is dropped at the NAT. I used tcpdump on the OpenSER/rtpproxy machine to figure out what happens to RTP and it shows the following (ports and IPs are just examples):
stream1: 1.2.3.4:10000 -> 2.3.4.5:35000 ->RTP is forwarded by rtpproxy-> 192.168.103.121:35000 -> 192.168.103.189:11000 stream2: 1.2.3.4:20000 <- 2.3.4.5:35000 <-RTP is forwarded by rtpproxy<- 192.168.103.121:35000 <- 192.168.103.189:11000
Port 20000 in stream2 is the RTP-port used internally by UAC1 behind the NAT (this port is found in the INVITE from UAC1 to OpenSER). I understand, that rtpproxy sends the first packets to port 20000. But, after receiving some packets from port 10000, shouldn't it change the destination port to 20000 so they can pass the NAT? rtpproxy is started like this: "./rtpproxy -l 192.168.103.121/2.3.4.5 -f ". It produces the following output:
[root@192 rtpproxy]# /usr/local/bin/rtpproxy -l 192.168.103.121/2.3.4.5 -f rtpproxy started, pid 22125 received command "UIE 9D740CB7-18A4-40B2-A96D-13FC3C5B27D3@192.168.103.189 192.168.103.189 49156 207860870326595;1" new session 9D740CB7-18A4-40B2-A96D-13FC3C5B27D3@192.168.103.189, tag 207860870326595;1 requested, type strong new session on a port 35000 created, tag 207860870326595;1 pre-filling caller's address with 192.168.103.189:49156 sending reply "35000 2.3.4.5 " received command "L 9D740CB7-18A4-40B2-A96D-13FC3C5B27D3@192.168.103.189 1.2.3.4 49154 207860870326595;1 5364140283;1" lookup on ports 35000/35000, session timer restarted pre-filling callee's address with 1.2.3.4:49154 sending reply "35000 192.168.103.121
In my openser.cfg I'm not really checking wheter a client is really natted, but I think it shouldn't be a problem to assume, that all clients are behind a NAT? I attached the openser.cfg to this mail (real public IP is changed to 2.3.4.5). Do you have any ideas how to fix this problem? Any help would be greatly appreciated!
Thanks, Christian
Try to use flag 'w' when you use force_rtp_proxy(). http://www.openser.org/docs/modules/1.3.x/nathelper.html#AEN316
Regards, Ovidiu Sas
On Wed, May 21, 2008 at 8:23 AM, Christian Koch chri.koch.vier@googlemail.com wrote:
Just in case anybody is facing the same problem: I found the solution for this configuration. rtpproxy handles the bridging mode in a way which doesn't fit my configuration. It assumes UAC1 is not behind a NAT. So you have to remove the following line from the rtpproxy code and recompile:
asymmetric = (bmode != 0) ? 1 : 0;
See also: http://lists.iptel.org/pipermail/serusers/2004-June/009305.html
I will ask on the rtpproxy mailing list for the reasons for this behaviour, as I think it may be a bug.
Christian Koch schrieb:
Hi,
I have a problem with openser and rtpproxy. I'm trying to use them as a gateway between the public internet and a LAN. Clients in the internet may be natted, so I'm using nathelper. Calls are only made from LAN to outside or vice versa, but not from LAN to LAN or from outside to outside. The following should illustrate my configuation: ----- ------------------ UAC1 --- | NAT | ------------- | OpenSER/rtpproxy | ----------------UAC2 ----- ------------------ | | | | | dynamic public IP 2.3.4.5 192.168.103.121 192.168.103.189 (e.g. 1.2.3.4) UAC1 and UAC2 are both registered at OpenSER. Now I'm making a call from UAC1 to UAC2. SIP messages are passed just fine, but the RTP traffic from UAC2 to UAC1 is dropped at the NAT. I used tcpdump on the OpenSER/rtpproxy machine to figure out what happens to RTP and it shows the following (ports and IPs are just examples):
stream1: 1.2.3.4:10000 -> 2.3.4.5:35000 ->RTP is forwarded by rtpproxy-> 192.168.103.121:35000 -> 192.168.103.189:11000 stream2: 1.2.3.4:20000 <- 2.3.4.5:35000 <-RTP is forwarded by rtpproxy<- 192.168.103.121:35000 <- 192.168.103.189:11000
Port 20000 in stream2 is the RTP-port used internally by UAC1 behind the NAT (this port is found in the INVITE from UAC1 to OpenSER). I understand, that rtpproxy sends the first packets to port 20000. But, after receiving some packets from port 10000, shouldn't it change the destination port to 20000 so they can pass the NAT? rtpproxy is started like this: "./rtpproxy -l 192.168.103.121/2.3.4.5 -f ". It produces the following output:
[root@192 rtpproxy]# /usr/local/bin/rtpproxy -l 192.168.103.121/2.3.4.5 -f rtpproxy started, pid 22125 received command "UIE 9D740CB7-18A4-40B2-A96D-13FC3C5B27D3@192.168.103.189 192.168.103.189 49156 207860870326595;1" new session 9D740CB7-18A4-40B2-A96D-13FC3C5B27D3@192.168.103.189, tag 207860870326595;1 requested, type strong new session on a port 35000 created, tag 207860870326595;1 pre-filling caller's address with 192.168.103.189:49156 sending reply "35000 2.3.4.5 " received command "L 9D740CB7-18A4-40B2-A96D-13FC3C5B27D3@192.168.103.189 1.2.3.4 49154 207860870326595;1 5364140283;1" lookup on ports 35000/35000, session timer restarted pre-filling callee's address with 1.2.3.4:49154 sending reply "35000 192.168.103.121
In my openser.cfg I'm not really checking wheter a client is really natted, but I think it shouldn't be a problem to assume, that all clients are behind a NAT? I attached the openser.cfg to this mail (real public IP is changed to 2.3.4.5). Do you have any ideas how to fix this problem? Any help would be greatly appreciated!
Thanks, Christian
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Thanks!!! With that flag it works without modifying the rtpproxy code. I simply missed that flag.
Ovidiu Sas schrieb:
Try to use flag 'w' when you use force_rtp_proxy(). http://www.openser.org/docs/modules/1.3.x/nathelper.html#AEN316
Regards, Ovidiu Sas
On Wed, May 21, 2008 at 8:23 AM, Christian Koch chri.koch.vier@googlemail.com wrote:
Just in case anybody is facing the same problem: I found the solution for this configuration. rtpproxy handles the bridging mode in a way which doesn't fit my configuration. It assumes UAC1 is not behind a NAT. So you have to remove the following line from the rtpproxy code and recompile:
asymmetric = (bmode != 0) ? 1 : 0;
See also: http://lists.iptel.org/pipermail/serusers/2004-June/009305.html
I will ask on the rtpproxy mailing list for the reasons for this behaviour, as I think it may be a bug.
Christian Koch schrieb:
Hi,
I have a problem with openser and rtpproxy. I'm trying to use them as a gateway between the public internet and a LAN. Clients in the internet may be natted, so I'm using nathelper. Calls are only made from LAN to outside or vice versa, but not from LAN to LAN or from outside to outside. The following should illustrate my configuation: ----- ------------------ UAC1 --- | NAT | ------------- | OpenSER/rtpproxy | ----------------UAC2 ----- ------------------ | | | | | dynamic public IP 2.3.4.5 192.168.103.121 192.168.103.189 (e.g. 1.2.3.4) UAC1 and UAC2 are both registered at OpenSER. Now I'm making a call from UAC1 to UAC2. SIP messages are passed just fine, but the RTP traffic from UAC2 to UAC1 is dropped at the NAT. I used tcpdump on the OpenSER/rtpproxy machine to figure out what happens to RTP and it shows the following (ports and IPs are just examples):
stream1: 1.2.3.4:10000 -> 2.3.4.5:35000 ->RTP is forwarded by rtpproxy-> 192.168.103.121:35000 -> 192.168.103.189:11000 stream2: 1.2.3.4:20000 <- 2.3.4.5:35000 <-RTP is forwarded by rtpproxy<- 192.168.103.121:35000 <- 192.168.103.189:11000
Port 20000 in stream2 is the RTP-port used internally by UAC1 behind the NAT (this port is found in the INVITE from UAC1 to OpenSER). I understand, that rtpproxy sends the first packets to port 20000. But, after receiving some packets from port 10000, shouldn't it change the destination port to 20000 so they can pass the NAT? rtpproxy is started like this: "./rtpproxy -l 192.168.103.121/2.3.4.5 -f ". It produces the following output:
[root@192 rtpproxy]# /usr/local/bin/rtpproxy -l 192.168.103.121/2.3.4.5 -f rtpproxy started, pid 22125 received command "UIE 9D740CB7-18A4-40B2-A96D-13FC3C5B27D3@192.168.103.189 192.168.103.189 49156 207860870326595;1" new session 9D740CB7-18A4-40B2-A96D-13FC3C5B27D3@192.168.103.189, tag 207860870326595;1 requested, type strong new session on a port 35000 created, tag 207860870326595;1 pre-filling caller's address with 192.168.103.189:49156 sending reply "35000 2.3.4.5 " received command "L 9D740CB7-18A4-40B2-A96D-13FC3C5B27D3@192.168.103.189 1.2.3.4 49154 207860870326595;1 5364140283;1" lookup on ports 35000/35000, session timer restarted pre-filling callee's address with 1.2.3.4:49154 sending reply "35000 192.168.103.121
In my openser.cfg I'm not really checking wheter a client is really natted, but I think it shouldn't be a problem to assume, that all clients are behind a NAT? I attached the openser.cfg to this mail (real public IP is changed to 2.3.4.5). Do you have any ideas how to fix this problem? Any help would be greatly appreciated!
Thanks, Christian
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users