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(a)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(a)evaristesys.com> >> To: kamailio <users(a)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(a)lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >> > > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev