force_rtp_proxy() usage with IP that is not natively homed

[Alex Balashov]

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 <[hidden email]>
To: kamailio <[hidden email]>

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) [phone]
Direct  : (+1) [phone]


--
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) [phone]
Direct  : (+1) [phone]

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[vma]

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 <[hidden email]> 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 <[hidden email]>
> To: kamailio <[hidden email]>
>
> 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) [phone]
> Direct  : (+1) [phone]
>
>
> --
> Alex Balashov - Principal
> Evariste Systems
> Web     : http://www.evaristesys.com/
> Tel     : (+1) [phone]
> Direct  : (+1) [phone]
>
> _______________________________________________
> sr-dev mailing list
> [hidden email]
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Klaus Darilion]

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 <[hidden email]> 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 <[hidden email]>
>> To: kamailio <[hidden email]>
>>
>> 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) [phone]
>> Direct  : (+1) [phone]
>>
>>
>> --
>> Alex Balashov - Principal
>> Evariste Systems
>> Web     : http://www.evaristesys.com/
>> Tel     : (+1) [phone]
>> Direct  : (+1) [phone]
>>
>> _______________________________________________
>> sr-dev mailing list
>> [hidden email]
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>
> _______________________________________________
> sr-dev mailing list
> [hidden email]
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[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
>> <[hidden email]> 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 <[hidden email]>
>>> To: kamailio <[hidden email]>
>>>
>>> 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) [phone]
>>> Direct  : (+1) [phone]
>>>
>>>
>>> --
>>> Alex Balashov - Principal
>>> Evariste Systems
>>> Web     : http://www.evaristesys.com/
>>> Tel     : (+1) [phone]
>>> Direct  : (+1) [phone]
>>>
>>> _______________________________________________
>>> sr-dev mailing list
>>> [hidden email]
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>
>>
>> _______________________________________________
>> sr-dev mailing list
>> [hidden email]
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

--
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) [phone]
Direct  : (+1) [phone]

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Klaus Darilion]

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
>>> <[hidden email]> 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 <[hidden email]>
>>>> To: kamailio <[hidden email]>
>>>>
>>>> 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) [phone]
>>>> Direct  : (+1) [phone]
>>>>
>>>>
>>>> --
>>>> Alex Balashov - Principal
>>>> Evariste Systems
>>>> Web     : http://www.evaristesys.com/
>>>> Tel     : (+1) [phone]
>>>> Direct  : (+1) [phone]
>>>>
>>>> _______________________________________________
>>>> sr-dev mailing list
>>>> [hidden email]
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>>
>>>
>>> _______________________________________________
>>> sr-dev mailing list
>>> [hidden email]
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev