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

Klaus Darilion klaus.mailinglists at pernau.at
Mon Nov 2 22:07:06 CET 2009



Alex Balashov schrieb:
> 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.

I would extend the function to accept any IP addresses - probably much 
easier than making a loopback config.

regards
klaus

> 
> 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
> 
> 



More information about the sr-dev mailing list