[sr-dev] force_rtp_proxy() usage with IP that is not natively homed

[Alex Balashov]

But, it doesn't.  See my initial message.  This parameter seems to 
only be meaningful for an IP address that rtpproxy is bound to (e.g. 
bridge mode);  specifying an arbitrary IP address, e.g.

    force_rtp_proxy("", "4.4.4.4");

has no effect on the SDP body.

Klaus Darilion wrote:

> He guys!
> 
> Seems like it works out of the box:
> http://www.kamailio.org/docs/modules/1.5.x/nathelper#id2468157
> 
> force_rtp_proxy([flags [, ip_address]])
>                        ^^^^^^^^^^^^^^^^
>                        ^^^^^^^^^^^^^^^^
>                        ^^^^^^^^^^^^^^^^
> 
> 
> klaus
> 
> 
> 
> vallimamod abdullah schrieb:
>> Hi Alex,
>>
>> I had the same exact issue some time ago with a nated server and I
>> solved it with a hacked mediaproxy. I have made it send the public sdp
>> IP for outgoing sessions (for the clients to send rtp to the public
>> IP) and local IP for incoming session so that the gateway can send the
>> rtp to the lan IP.
>>
>> It was a quick and dirty hack that worked well for my needs. If you
>> are interested, I can send it to you.
>>
>> Cheers,
>> - vma
>> .
>>
>>
>> On Mon, Nov 2, 2009 at 7:38 AM, Alex Balashov 
>> <abalashov at evaristesys.com> wrote:
>>> Sorry for cross-posting from k-users; was hoping maybe someone here 
>>> has some
>>> insights, as rtpproxy is a sparsely documented topic.
>>>
>>> -------- Original Message --------
>>> Subject: force_rtp_proxy() usage with IP that is not natively homed
>>> Date: Mon, 02 Nov 2009 01:23:40 -0500
>>> From: Alex Balashov <abalashov at evaristesys.com>
>>> To: kamailio <users at lists.kamailio.org>
>>>
>>> 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
>>>
>>>
>>> -- 
>>> Alex Balashov - Principal
>>> Evariste Systems
>>> Web     : http://www.evaristesys.com/
>>> Tel     : (+1) (678) 954-0670
>>> Direct  : (+1) (678) 954-0671
>>>
>>> _______________________________________________
>>> sr-dev mailing list
>>> sr-dev at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev


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