Hi All,
I am trying to setup kamailio 1.5.3-notls for use with rtpproxy 1.2.1. I have a partially working setup, however, when I have a softphone configured behind nat it appears that rtpproxy is using the internal ip (prior to nat) to setup the sdp ports.
I have rtpproxy configured in bridge mode as follows:
rtpproxy -f -F -l public_ip/internal_ip -s udp:*:11211
I have kamailio's nathelper module setup as follows:
modparam("nathelper", "rtpproxy_sock", "udp:internal_ip:11211")
I then use a softphone (x-lite) behind a nat firewall (ip = 192.168.11.2) to establish a call, and the log of rtpproxy is as follows:
INFO:handle_command: new session ZmRkNjRlNjM0NzExZjQ5MWUxYjllOTFhZWFmZGZkMjY., tag 8330585e;1 requested, type strong INFO:handle_command: new session on a port 52572 created, tag 8330585e;1 INFO:handle_command: pre-filling caller's address with 192.168.11.2:35498 INFO:handle_command: lookup on ports 52572/40380, session timer restarted INFO:handle_command: pre-filling callee's address with internal_ip:11250 INFO:handle_delete: forcefully deleting session 1 on ports 52572/40380 INFO:remove_session: RTP stats: 906 in from callee, 0 in from caller, 906 relayed, 0 dropped INFO:remove_session: RTCP stats: 3 in from callee, 0 in from caller, 3 relayed, 0 dropped INFO:remove_session: session on ports 52572/40380 is cleaned up
In the log above it looks like rtpproxy is using 192.168.11.2:35498 as the remote ip/port combination to contact for the sdp session of the x-lite softphone. I would have thought that it would use the IP address that initial request was received from to establish this connection (via the fix_nated_contact() function).
My route logic in kamailio is a slightly modified default configuration that is installed with kamailio :
route{
. . .
# NAT detection route(4);
. . .
route(1); }
route[1]{ if (check_route_param("nat=yes")) { setbflag(6); } # if (isflagset(5) || isbflagset(6)) { route(5); # }
/* example how to enable some additional event routes */ if (is_method("INVITE")) { #t_on_branch("1"); t_on_reply("1"); t_on_failure("1"); }
if (!t_relay()) { sl_reply_error(); } exit; }
route[4]{ force_rport(); if (nat_uac_test("19")) { if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); } setflag(5); } return; }
Would the "fix_nated_contact" function in the "nat detection" route not fix the contact before passing over the request to rtpproxy to establish the sdp session?
route[5] { if (is_method("BYE")) { unforce_rtp_proxy(); } else if (is_method("INVITE")){ # force_rtp_proxy(); if(src_ip==internal_ip_of_media_server) force_rtp_proxy("ocfaei"); else force_rtp_proxy("ocfaie"); } if (!has_totag()) add_rr_param(";nat=yes"); return; }
onreply_route[1] { xdbg("incoming reply\n");
# if ((isflagset(5) || isbflagset(6)) && status=~"(183)|(2[0-9][0-9])") { if (status=~"(183)|(2[0-9][0-9])") { # force_rtp_proxy(); if(src_ip == internal_ip_of_media_server) force_rtp_proxy("ocfaei"); else force_rtp_proxy("ocfaie"); } if (isbflagset(6)) { fix_nated_contact(); } }
failure_route[1] { if (is_method("INVITE") && (isbflagset(6) || isflagset(5))) { unforce_rtp_proxy(); }
if (t_was_cancelled()) { exit; } }
Any pointers would be greatly appreciated.
Thanks Bruce
Hi All,
Just an update to this, if I use a Cisco 7960 with nat traversal enabled, the bridging works. It looks like rtpproxy fills the callers address with the correct ip details of the UA. See the log below:
INFO:handle_command: new session 000f23e7-18db0016-7f899e0c-62e77522@188.141.20.76, tag 000f23e718db1a5a307d0789-26be63fe;1 requested, type strong INFO:handle_command: new session on a port 63638 created, tag 000f23e718db1a5a307d0789-26be63fe;1 INFO:handle_command: pre-filling caller's address with 188.141.20.76:19340 INFO:handle_command: adding strong flag to existing session, new=1/0/0 INFO:handle_command: lookup on ports 63638/0, session timer restarted INFO:handle_command: lookup on ports 63638/61436, session timer restarted INFO:handle_command: pre-filling callee's address with 10.7.0.57:10602 INFO:handle_delete: forcefully deleting session 1 on ports 63638/61436 INFO:remove_session: RTP stats: 186 in from callee, 186 in from caller, 372 relayed, 0 dropped INFO:remove_session: RTCP stats: 0 in from callee, 0 in from caller, 0 relayed, 0 dropped INFO:remove_session: session on ports 63638/61436 is cleaned up
Where the following represents:
188.141.20.76 = IP of firewall/UA 10.7.0.57 = media server address.
The call completes successfully.
I can only assume that I am missing something with the nating when I use the softphone and rtpproxy, as with the log below it shows the internal IP address of the softphone as apposed to the external ip of my firewall.
Where does rtpproxy extract the source ip from when it is populating the caller/calle addreses?, is it from the contact address?
Any suggestions would be appreciated.
Thanks Bruce
Bruce McAlister wrote:
Hi All,
I am trying to setup kamailio 1.5.3-notls for use with rtpproxy 1.2.1. I have a partially working setup, however, when I have a softphone configured behind nat it appears that rtpproxy is using the internal ip (prior to nat) to setup the sdp ports.
I have rtpproxy configured in bridge mode as follows:
rtpproxy -f -F -l public_ip/internal_ip -s udp:*:11211
I have kamailio's nathelper module setup as follows:
modparam("nathelper", "rtpproxy_sock", "udp:internal_ip:11211")
I then use a softphone (x-lite) behind a nat firewall (ip = 192.168.11.2) to establish a call, and the log of rtpproxy is as follows:
INFO:handle_command: new session ZmRkNjRlNjM0NzExZjQ5MWUxYjllOTFhZWFmZGZkMjY., tag 8330585e;1 requested, type strong INFO:handle_command: new session on a port 52572 created, tag 8330585e;1 INFO:handle_command: pre-filling caller's address with 192.168.11.2:35498 INFO:handle_command: lookup on ports 52572/40380, session timer restarted INFO:handle_command: pre-filling callee's address with internal_ip:11250 INFO:handle_delete: forcefully deleting session 1 on ports 52572/40380 INFO:remove_session: RTP stats: 906 in from callee, 0 in from caller, 906 relayed, 0 dropped INFO:remove_session: RTCP stats: 3 in from callee, 0 in from caller, 3 relayed, 0 dropped INFO:remove_session: session on ports 52572/40380 is cleaned up
In the log above it looks like rtpproxy is using 192.168.11.2:35498 as the remote ip/port combination to contact for the sdp session of the x-lite softphone. I would have thought that it would use the IP address that initial request was received from to establish this connection (via the fix_nated_contact() function).
My route logic in kamailio is a slightly modified default configuration that is installed with kamailio :
route{
. . .
# NAT detection route(4);
. . .
route(1); }
route[1]{ if (check_route_param("nat=yes")) { setbflag(6); } # if (isflagset(5) || isbflagset(6)) { route(5); # }
/* example how to enable some additional event routes */ if (is_method("INVITE")) { #t_on_branch("1"); t_on_reply("1"); t_on_failure("1"); } if (!t_relay()) { sl_reply_error(); } exit;
}
route[4]{ force_rport(); if (nat_uac_test("19")) { if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); } setflag(5); } return; }
Would the "fix_nated_contact" function in the "nat detection" route not fix the contact before passing over the request to rtpproxy to establish the sdp session?
route[5] { if (is_method("BYE")) { unforce_rtp_proxy(); } else if (is_method("INVITE")){ # force_rtp_proxy(); if(src_ip==internal_ip_of_media_server) force_rtp_proxy("ocfaei"); else force_rtp_proxy("ocfaie"); } if (!has_totag()) add_rr_param(";nat=yes"); return; }
onreply_route[1] { xdbg("incoming reply\n");
# if ((isflagset(5) || isbflagset(6)) &&
status=~"(183)|(2[0-9][0-9])") { if (status=~"(183)|(2[0-9][0-9])") { # force_rtp_proxy(); if(src_ip == internal_ip_of_media_server) force_rtp_proxy("ocfaei"); else force_rtp_proxy("ocfaie"); } if (isbflagset(6)) { fix_nated_contact(); } }
failure_route[1] { if (is_method("INVITE") && (isbflagset(6) || isflagset(5))) { unforce_rtp_proxy(); }
if (t_was_cancelled()) { exit; }
}
Any pointers would be greatly appreciated.
Thanks Bruce
sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
On 12/14/09 1:24 PM, Bruce McAlister wrote:
Hi All,
I am trying to setup kamailio 1.5.3-notls for use with rtpproxy 1.2.1. I have a partially working setup, however, when I have a softphone configured behind nat it appears that rtpproxy is using the internal ip (prior to nat) to setup the sdp ports.
I have rtpproxy configured in bridge mode as follows:
rtpproxy -f -F -l public_ip/internal_ip -s udp:*:11211
depending on flags, the public or internal IP is used to update the sdp. If you get it in the wrong order, then change the flags e and i in force_rtp_proxy() call.
It is ok to have the internal ip in the sdp going to the phone in internal network.
Cheers, Daniel
I have kamailio's nathelper module setup as follows:
modparam("nathelper", "rtpproxy_sock", "udp:internal_ip:11211")
I then use a softphone (x-lite) behind a nat firewall (ip = 192.168.11.2) to establish a call, and the log of rtpproxy is as follows:
INFO:handle_command: new session ZmRkNjRlNjM0NzExZjQ5MWUxYjllOTFhZWFmZGZkMjY., tag 8330585e;1 requested, type strong INFO:handle_command: new session on a port 52572 created, tag 8330585e;1 INFO:handle_command: pre-filling caller's address with 192.168.11.2:35498 INFO:handle_command: lookup on ports 52572/40380, session timer restarted INFO:handle_command: pre-filling callee's address with internal_ip:11250 INFO:handle_delete: forcefully deleting session 1 on ports 52572/40380 INFO:remove_session: RTP stats: 906 in from callee, 0 in from caller, 906 relayed, 0 dropped INFO:remove_session: RTCP stats: 3 in from callee, 0 in from caller, 3 relayed, 0 dropped INFO:remove_session: session on ports 52572/40380 is cleaned up
In the log above it looks like rtpproxy is using 192.168.11.2:35498 as the remote ip/port combination to contact for the sdp session of the x-lite softphone. I would have thought that it would use the IP address that initial request was received from to establish this connection (via the fix_nated_contact() function).
My route logic in kamailio is a slightly modified default configuration that is installed with kamailio :
route{
. . .
# NAT detection route(4);
. . .
route(1); }
route[1]{ if (check_route_param("nat=yes")) { setbflag(6); } # if (isflagset(5) || isbflagset(6)) { route(5); # }
/* example how to enable some additional event routes */ if (is_method("INVITE")) { #t_on_branch("1"); t_on_reply("1"); t_on_failure("1"); } if (!t_relay()) { sl_reply_error(); } exit;
}
route[4]{ force_rport(); if (nat_uac_test("19")) { if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); } setflag(5); } return; }
Would the "fix_nated_contact" function in the "nat detection" route not fix the contact before passing over the request to rtpproxy to establish the sdp session?
route[5] { if (is_method("BYE")) { unforce_rtp_proxy(); } else if (is_method("INVITE")){ # force_rtp_proxy(); if(src_ip==internal_ip_of_media_server) force_rtp_proxy("ocfaei"); else force_rtp_proxy("ocfaie"); } if (!has_totag()) add_rr_param(";nat=yes"); return; }
onreply_route[1] { xdbg("incoming reply\n");
# if ((isflagset(5) || isbflagset(6))&&
status=~"(183)|(2[0-9][0-9])") { if (status=~"(183)|(2[0-9][0-9])") { # force_rtp_proxy(); if(src_ip == internal_ip_of_media_server) force_rtp_proxy("ocfaei"); else force_rtp_proxy("ocfaie"); } if (isbflagset(6)) { fix_nated_contact(); } }
failure_route[1] { if (is_method("INVITE") && (isbflagset(6) || isflagset(5))) { unforce_rtp_proxy(); }
if (t_was_cancelled()) { exit; }
}
Any pointers would be greatly appreciated.
Thanks Bruce
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Hi Daniel,
depending on flags, the public or internal IP is used to update the sdp. If you get it in the wrong order, then change the flags e and i in force_rtp_proxy() call.
I think I have the flags setup correctly because I am able to get calls working if I setup a phone to send out its details as having my firewall ip address. If I change the ei/ie parameters in force_rtpproxy then the calls dont work at all.
I will try to explain my scenario below.
I have a soft phone (x-lite) on my pc who's internal IP address is 192.168.11.2. When I initiate a call from my softphone the contact address is setup as 192.168.11.2, kamailio then adds the rport and received parameters as my external firewall ip and port.
When I force the rtpproxy setup, it looks like rtpproxy is setting up the correct ports on our publice ip, but it looks like rtpproxy wants to talk to my softphone using ip address 192.168.11.2 instead of the ip address that is in the recevied parameter.
INFO:handle_command: pre-filling caller's address with 192.168.11.2:14880
My external IP of my firewall is 188.141.20.76, I would have expected the rtpproxy line to look like this:
INFO:handle_command: pre-filling caller's address with 188.141.20.76:14880
The media server on the other side of the rtpproxy bridge is able to send traffic to rtpproxy, but it looks like rtpproxy is not able to contact the softphone as it is a private address.
If I do the same test using a Cisco 7960 which has "nat-traversal" enabled in its configuration then the call works, rtpproxy sets up the correct ports on the internal nic for the media server to talk to and it sets up a port pair on its external nic to talk to the cisco phone. This works.
I suspect my problem lies with nat somewhere and telling rtpproxy to use the "recieved" ip address of my firewall to talk to my x-lite.
I hope I am explaining my scenario better. Any comments suggestions would be appreciated.
Thanks Bruce
Hello,
On 12/14/09 4:54 PM, Bruce McAlister wrote:
Hi Daniel,
depending on flags, the public or internal IP is used to update the sdp. If you get it in the wrong order, then change the flags e and i in force_rtp_proxy() call.
I think I have the flags setup correctly because I am able to get calls working if I setup a phone to send out its details as having my firewall ip address. If I change the ei/ie parameters in force_rtpproxy then the calls dont work at all.
I will try to explain my scenario below.
I have a soft phone (x-lite) on my pc who's internal IP address is 192.168.11.2. When I initiate a call from my softphone the contact address is setup as 192.168.11.2, kamailio then adds the rport and received parameters as my external firewall ip and port.
When I force the rtpproxy setup, it looks like rtpproxy is setting up the correct ports on our publice ip, but it looks like rtpproxy wants to talk to my softphone using ip address 192.168.11.2 instead of the ip address that is in the recevied parameter.
INFO:handle_command: pre-filling caller's address with 192.168.11.2:14880
My external IP of my firewall is 188.141.20.76, I would have expected the rtpproxy line to look like this:
INFO:handle_command: pre-filling caller's address with 188.141.20.76:14880
The media server on the other side of the rtpproxy bridge is able to send traffic to rtpproxy, but it looks like rtpproxy is not able to contact the softphone as it is a private address.
If I do the same test using a Cisco 7960 which has "nat-traversal" enabled in its configuration then the call works, rtpproxy sets up the correct ports on the internal nic for the media server to talk to and it sets up a port pair on its external nic to talk to the cisco phone. This works.
I suspect my problem lies with nat somewhere and telling rtpproxy to use the "recieved" ip address of my firewall to talk to my x-lite.
I hope I am explaining my scenario better. Any comments suggestions would be appreciated.
in order to connect the rtp stream, rtpproxy needs to receive an audio packet (rtp) from each side. rtpproxy main job is to give addresses and ports to fill in SDP of INVITE and 200OK reply.
If you can get an ngrep trace with such call, I can give more hits about whether is ok or not.
Cheers, Daniel
Hi All,
With the guidance of Daniel, I managed to fix this issue, it had to do with symmetric vs asymmetric nat.
I had to change the "ofcaie" parameters in the call to force_rtp_proxy to remove the "a" and replace it with a "w".
See nathelper module for more info on the flags :)
Thanks Bruce