[Kamailio-Users] force_rtp_proxy() usage with IP that is not natively homed

Alex Balashov abalashov at evaristesys.com
Mon Nov 2 07:23:40 CET 2009


Greetings,

Please excuse the apparent silliness of this request, but I am curious 
  if there is a combination of flags passed to force_rtp_proxy() 
and/or rtpproxy invocation options that can allow force_rtp_proxy() to 
substitute an SDP endpoint IP that is not a physical device/interface 
on the host on which rtpproxy is running?

Let me explain further:

1. I have a host with a single network interface that has private IP 
192.168.1.254.

2. I am receiving an inbound call from outside the network, coming in 
on a public IP address 4.4.4.4 that is a 1-to-1 DNAT/SNAT to 
192.168.1.254.

3. The call is forwarded to a PBX on the same LAN as the native 
interface, e.g. 192.168.1.250.

4. I would like to set up SDP in such a way that 192.168.1.250 
sendsmedia to the 192.168.1.254 interface while the outside host 
initiating the call sends its media to 4.4.4.4.


Under normal circumstances in which both the public and private 
interface were physically present on the machine, this would call for 
the use of "bridging" mode (rtpproxy invoked with -l 
4.4.4.4/192.168.1.254 and use of "ie" and "ei" flags with 
force_rtp_proxy() - we have previously established that 
rtpproxy_offer/answer do not actually seem to work as advertised).

But is it possible to "bridge" to an IP that is not routed to the box?

I expected that force_rtp_proxy()'s second parameter - ip_address - 
would do this.  However, this does not appear to let me override the 
SDP endpoint with any IP address I want;  it seems that I am still 
limited to choosing from those IPs physically available on the 
rtpproxy host.  I would guess that this is because ip_address is 
passed as a parameter through rtpproxy's control API socket and is 
validated by rtpproxy itself, and if it is not a local existing 
address, is overridden with one that is.

Is there a clever combination of flags that can be used to accomplish 
this, or is it a lost cause?

Thanks!

-- 
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671




More information about the sr-users mailing list