Making RTPproxy work

In response to my previous post related to Kamailio as SBC for Media-Servers, I'm often asked to show how to make this whole setup work with RTPproxy. That means a successful two-way audio call. Remember that the original configuration found on Asipto-Blog is for Public-IPs only.

I had to do alot of hit-&-trial sort of testings with my configuration before making the configurations work for me, so I'll share all that I remember now.

UPDATE: Another new version of this page is available here.

STEP-I : Starting RTPproxy:
Start RTPproxy in bridging mode.

#/usr/sbin/rtpproxy -F -s udp:127.0.0.1:7722 -l PU.BL.IC.IP/10.1.1.1 -d DBUG:LOG_LOCAL0
STEP-II: Kamailio Configuration file:
Define RTPproxy controller port in modparams area.

#RTPproxy instance to be used: 7722 
#PU.BL.IC.IP<<=Transform=>> 10.1.1.1
modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:7722") 

Then in route[RTPPROXY] we need to know if the call is coming from WAN/internet side or from  LAN/Private Asterisk's side so I had to put the following lines in modparams area as well for DB connectivity. This is required to query the dispatcher tables in RTPPROXY route.

# ------- AVP-OPS params ---------
modparam("avpops","db_url", DBURL)
modparam("avpops","avp_table","dispatcher")

So finally in the route for RTPproxy we querry the DB table dispatcher for inbound or oubound call requests from/to media-servers.

# RTPProxy control
route[RTPPROXY] {
#!ifdef WITH_NAT
 xlog("L_NOTICE","$rm from $fu (IP:$si:$sp) in Route[RTPPROXY]\n");
 if (is_method("BYE")) {
  xlog("L_NOTICE","$rm from $fu (IP:$si:$sp) in Route[RTPPROXY] unforced RTP Proxy STATS='$rtpstat'\n");
  unforce_rtp_proxy();
 } else if (is_method("INVITE")){
#INCOMING CALL 
  if(avp_db_query("select destination from dispatcher where destination like '%$dd%'")){
   xlog("L_NOTICE","$rm from $fu (IP:$si:$sp) in route[RTPPROXY] RTPproxy with IE Flags\n");
#INCOMING CALL NEEDS TO GOTO PRIVATE-IP ASTERISK USE - IE
   rtpproxy_manage("rie");
 
 }
  else if(avp_db_query("select destination from dispatcher where destination='sip:$si:$sp'")){
   xlog("L_NOTICE","$rm from $fu (IP:$si:$sp) in route[RTPPROXY] RTPproxy with EI Flags\n");
#INCOMING CALL FROM PRIVATE-IP ASTERISK USE - EI
   rtpproxy_manage("rei");

  }
  else
  {
   rtpproxy_manage("r");
    xlog("L_NOTICE","$rm from $fu (IP:$si:$sp) in Route[RTPPROXY] Forcing RTPproxy\n");
  }

 }
 if (!has_totag()){ 
  add_rr_param(";nat=yes");
 }
#!endif
 return;
}

RTPproxy Bridging Network Scenario

Please note that the order of I and E flags. The sequence of these flags depends on the rtpproxy running in the background and the order of PUBLICIP and PRIVATEIP while starting RTPproxy.
#/usr/sbin/rtpproxy -F -s udp:127.0.0.1:7722 -l PU.BL.IC.IP/10.1.1.1 -d DBUG:LOG_LOCAL0

The flags sequence can get inverted if I execut rtpproxy like this.Note the order of Public Ip and Private IP.
#/usr/sbin/rtpproxy -F -s udp:127.0.0.1:7722 -l 10.1.1.1/PU.BL.IC.IP -d DBUG:LOG_LOCAL0

Once done changes in configurations file save it and restart kamailio. Make sure Kamailio detects the RTPproxy socket and announces that support for Rtpproxy is enabled.

Make calls and see the RTPproxy stats at the end of each call. 

Troubleshooting Tips:

Use "tcpdump" on Kamailio server and trace ALL the traffic on ALL the interfaces i.e WAN+LAN interfaces using the following command.

#tcpdump -i any -s 0 -w SIP-TRACE.pcap -vvvv

Once a call is completed stop the trace by hitting CTRL+C; download the pcap file to your windows desktop; open the file in wireshark; analyse VoIP call and see the flow of packets between caller and callee.Reading and understanding SIP/SDP INVITEs packets between caller to Kamailio and then from Kamailio to Media-server is very critical in understanding why we are having no-audio or one-way-audio for  a bad call.

Thats all for now,I'm thinking of exploring Media-Proxy as well. I hope someday I'll post about it too.