force_rtp_proxy() usage with IP that is not natively homed

[Alex Balashov]

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]

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Klaus Darilion-2]

Hi Alex!

This sounds like you need fix_nated_sdp("2","4.4.4.4") after
force_rtp_proxy(). With K1.5 this is not possible (probably a crash will
happen as both functions mangle the SDP).

I 3.0 you could use msg_apply_changes() between the two function calls:
http://sip-router.org/docbook/sip-router/branch/master/modules_k/textops/textops.html#id2996272


regards
klaus

Alex Balashov schrieb:

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

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[miconda]

Hello,

On 02.11.2009 8:09 Uhr, Klaus Darilion wrote:
> Hi Alex!
>
> This sounds like you need fix_nated_sdp("2","4.4.4.4") after
> force_rtp_proxy(). With K1.5 this is not possible (probably a crash
> will happen as both functions mangle the SDP).
>
> I 3.0 you could use msg_apply_changes() between the two function calls:
> http://sip-router.org/docbook/sip-router/branch/master/modules_k/textops/textops.html#id2996272 
>
in 1.5 can be looped back or use another instance on a different ip or
port just for updating the sdp.

Cheers,
Daniel

>
>
> regards
> klaus
>
> Alex Balashov schrieb:
>> 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!
>>
>
> _______________________________________________
> Kamailio (OpenSER) - Users mailing list
> Users@...
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>

--
Daniel-Constantin Mierla
* http://www.asipto.com/


_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Alex Balashov]

Daniel,

Daniel-Constantin Mierla wrote:

> in 1.5 can be looped back or use another instance on a different ip or
> port just for updating the sdp.

But replies cannot be looped back ...?

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

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Klaus Darilion-2]

Alex Balashov schrieb:
> Daniel,
>
> Daniel-Constantin Mierla wrote:
>
>> in 1.5 can be looped back or use another instance on a different ip or
>> port just for updating the sdp.
>
> But replies cannot be looped back ...?

They will be looped back automatically due to Via headers

klaus

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Alex Balashov]

Klaus Darilion wrote:

>
>
> Alex Balashov schrieb:
>> Daniel,
>>
>> Daniel-Constantin Mierla wrote:
>>
>>> in 1.5 can be looped back or use another instance on a different ip
>>> or port just for updating the sdp.
>>
>> But replies cannot be looped back ...?
>
> They will be looped back automatically due to Via headers

Oh, I see.  You are implying that if I loop the initial requests
(perhaps with Record-Route), then the replies will be similarly looped.

Yeah, this is possible, I suppose, although I am concerned about the
impracticality of setting up a concurrent Kamailio instance on the
same system from an administrative perspective.


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

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[miconda]

On 02.11.2009 10:44 Uhr, Alex Balashov wrote:

> Klaus Darilion wrote:
>>
>>
>> Alex Balashov schrieb:
>>> Daniel,
>>>
>>> Daniel-Constantin Mierla wrote:
>>>
>>>> in 1.5 can be looped back or use another instance on a different ip
>>>> or port just for updating the sdp.
>>>
>>> But replies cannot be looped back ...?
>>
>> They will be looped back automatically due to Via headers
>
> Oh, I see.  You are implying that if I loop the initial requests
> (perhaps with Record-Route), then the replies will be similarly looped.

record-routing will help you with re-INVITEs, otherwise it could be
skipped, replies are routed back based on Via headers.

Cheers,
Daniel

>
> Yeah, this is possible, I suppose, although I am concerned about the
> impracticality of setting up a concurrent Kamailio instance on the
> same system from an administrative perspective.
>
>

--
Daniel-Constantin Mierla
* http://www.asipto.com/


_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users