[Kamailio-Users] [SR-Users] Kamailio and RTPProxy

Bruce McAlister bruce.mcalister at blueface.ie
Mon Dec 14 15:47:20 CET 2009


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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> 
> 



More information about the Users mailing list