Hi all,
I'm running ser 0.8.14 with nathelper+rtpproxy. I can initiate calls from UA behind NAT to UA in public without problem. But, I can't initiate a call from public to private even if the NATed client has been registered.
Please advise.
Here is the snippet of my ser.cfg ------------------------begin---------------------------------- #-----Nathelper parameters----- modparam("registrar", "nat_flag", 6) # indicates that a registered client is behind NAT modparam("nathelper", "natping_interval", 60) #ping interval 30s modparam("nathelper", "ping_nated_only", 1) #ping only clients behind NAT . . if (nat_uac_test("3")) { log(1, "src address different than via header->NAT detected\n"); log(1, "force_rport and fix_nated_contact and setflag(5)\n"); if (method=="REGISTER" || ! search("^Record-Route:")) { fix_nated_contact();# Rewrite contact with source IP of signalling if (method=="INVITE") { fix_nated_sdp("1");# Add direction=active to SDP }; force_rport();# Add rport parameter to topmost Via setflag(6);# Mark as NATed }; append_hf("P-hint: fixed NAT contact for request\r\n"); }; . .
route[1] { # !! Nathelper if (uri=~"[@:](192.168.|10.|172.(1[6-9]|2[0-9]|3[0-1]).)" && !search("^Route:")){ sl_send_reply("479", "We don't forward to private IP addresses"); break; }; # if client or server know to be behind a NAT, enable relay if (isflagset(6)) { force_rtp_proxy(); }; # NAT processing of replies; apply to all transactions (for example, # re-INVITEs from public to private UA are hard to identify as # NATed at the moment of request processing); look at replies t_on_reply("1"); # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP
if (!t_relay()) { sl_reply_error(); }; }
# NATed transaction ? onreply_route[1] { if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") { fix_nated_contact(); force_rtp_proxy(); } else if (nat_uac_test("1")) { fix_nated_contact(); }; } ----------------------------end---------------------------------------- Regards.
I have the very same problem. I'd be keen to find out the solution!
----- Original Message ----- From: iw03_amn@it.kth.se To: serusers@lists.iptel.org Sent: Sunday, February 20, 2005 8:34 AM Subject: [Serusers] SER, Rtpproxy, NAT.
Hi all,
I'm running ser 0.8.14 with nathelper+rtpproxy. I can initiate calls from UA behind NAT to UA in public without problem. But, I can't initiate a call from public to private even if the NATed client has been registered.
Please advise.
Here is the snippet of my ser.cfg ------------------------begin---------------------------------- #-----Nathelper parameters----- modparam("registrar", "nat_flag", 6) # indicates that a registered client is behind NAT modparam("nathelper", "natping_interval", 60) #ping interval 30s modparam("nathelper", "ping_nated_only", 1) #ping only clients behind NAT . . if (nat_uac_test("3")) { log(1, "src address different than via header->NAT detected\n"); log(1, "force_rport and fix_nated_contact and setflag(5)\n"); if (method=="REGISTER" || ! search("^Record-Route:")) { fix_nated_contact();# Rewrite contact with source IP of signalling if (method=="INVITE") { fix_nated_sdp("1");# Add direction=active to SDP }; force_rport();# Add rport parameter to topmost Via setflag(6);# Mark as NATed }; append_hf("P-hint: fixed NAT contact for request\r\n"); }; . .
route[1] { # !! Nathelper if (uri=~"[@:](192.168.|10.|172.(1[6-9]|2[0-9]|3[0-1]).)" && !search("^Route:")){ sl_send_reply("479", "We don't forward to private IP addresses"); break; }; # if client or server know to be behind a NAT, enable relay if (isflagset(6)) { force_rtp_proxy(); }; # NAT processing of replies; apply to all transactions (for example, # re-INVITEs from public to private UA are hard to identify as # NATed at the moment of request processing); look at replies t_on_reply("1"); # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP
if (!t_relay()) { sl_reply_error(); }; }
# NATed transaction ?
onreply_route[1] { if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") { fix_nated_contact(); force_rtp_proxy(); } else if (nat_uac_test("1")) { fix_nated_contact(); }; } ----------------------------end---------------------------------------- Regards.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I have done some more debugging, and can see that the CALLED UA (nathelper) is responding with it's PRIVATE IP address, hence the lack of resultant RTP stream.
I assume that I need to use fix_nated_sdp somewhere? Is this correct?
----- Original Message ----- From: iw03_amn@it.kth.se To: serusers@lists.iptel.org Sent: Sunday, February 20, 2005 8:34 AM Subject: [Serusers] SER, Rtpproxy, NAT.
Hi all,
I'm running ser 0.8.14 with nathelper+rtpproxy. I can initiate calls from UA behind NAT to UA in public without problem. But, I can't initiate a call from public to private even if the NATed client has been registered.
Please advise.
Here is the snippet of my ser.cfg ------------------------begin---------------------------------- #-----Nathelper parameters----- modparam("registrar", "nat_flag", 6) # indicates that a registered client is behind NAT modparam("nathelper", "natping_interval", 60) #ping interval 30s modparam("nathelper", "ping_nated_only", 1) #ping only clients behind NAT . . if (nat_uac_test("3")) { log(1, "src address different than via header->NAT detected\n"); log(1, "force_rport and fix_nated_contact and setflag(5)\n"); if (method=="REGISTER" || ! search("^Record-Route:")) { fix_nated_contact();# Rewrite contact with source IP of signalling if (method=="INVITE") { fix_nated_sdp("1");# Add direction=active to SDP }; force_rport();# Add rport parameter to topmost Via setflag(6);# Mark as NATed }; append_hf("P-hint: fixed NAT contact for request\r\n"); }; . .
route[1] { # !! Nathelper if (uri=~"[@:](192.168.|10.|172.(1[6-9]|2[0-9]|3[0-1]).)" && !search("^Route:")){ sl_send_reply("479", "We don't forward to private IP addresses"); break; }; # if client or server know to be behind a NAT, enable relay if (isflagset(6)) { force_rtp_proxy(); }; # NAT processing of replies; apply to all transactions (for example, # re-INVITEs from public to private UA are hard to identify as # NATed at the moment of request processing); look at replies t_on_reply("1"); # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP
if (!t_relay()) { sl_reply_error(); }; }
# NATed transaction ?
onreply_route[1] { if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") { fix_nated_contact(); force_rtp_proxy(); } else if (nat_uac_test("1")) { fix_nated_contact(); }; } ----------------------------end---------------------------------------- Regards.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers