[Kamailio-Users] Having problems using RTPProxy to bridge internal/external networks

[Alex Balashov]

Daniel-Constantin Mierla wrote:
> 
> 
> On 15.10.2009 20:02 Uhr, Alex Balashov wrote:
>> Alex Balashov wrote:
>>> Alex Balashov wrote:
>>>> Alex Balashov wrote:
>>>>> Daniel-Constantin Mierla wrote:
>>>>>
>>>>>> IIRC, I use:
>>>>>>
>>>>>> if(dst_ip==private_ip)
>>>>>>       force_rtp_proxy("ocfaei");
>>>>>> else
>>>>>>       force_rtp_proxy("ocfaie");
>>>>>>
>>>>>> rtpproxy started with: -l external_ip/private_ip
>>>>>>
>>>>>> Probably is rtpproxy 1.1 -- cannot check right now.
>>>>>
>>>>> I just tried this and it works, from the point of view of SDP.  We 
>>>>> were already able to obtain this result.
>>>>>
>>>>> The problem is that the actual rtpproxy does not seem to forward 
>>>>> the packets that come into one interface toward the other, so no 
>>>>> media is exchanged.
>>>>>
>>>>
>>>> An additional note:  if I turn OFF /proc/sys/net/ipv4/ip_forward and 
>>>> then start the proxy in bridging mode, the following happens when it 
>>>> is invoked:
>>>>
>>>> DBUG:handle_command: received command "8725_4 UAIEc0,101 
>>>> 5f1690462d84b3814915b05f65c626bd at 208.52.173.7 208.52.173.7 11832 
>>>> as214288b6;1"
>>>> INFO:handle_command: new session 
>>>> 5f1690462d84b3814915b05f65c626bd at 208.52.173.7, tag as214288b6;1 
>>>> requested, type strong
>>>> Segmentation fault
>>>>
>>>> In other words, it seems to require ip_forward to be on in order to 
>>>> not crash, but when it is on, no packets are exchanged between the 
>>>> interfaces.
>>>>
>>>
>>> To be more precise:
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> create_listener (cf=0x7fff90524230, ia=0x0, port=0x7fff905241ac,
>>>     fds=0x7fff90524190) at rtpp_command.c:89
>>> 89        fds[i] = socket(ia->sa_family, SOCK_DGRAM, 0);
>>> (gdb) where
>>> #0  create_listener (cf=0x7fff90524230, ia=0x0, port=0x7fff905241ac,
>>>     fds=0x7fff90524190) at rtpp_command.c:89
>>> #1  0x0000000000408e09 in handle_command (cf=0x7fff90524230, 
>>> controlfd=6,
>>>     dtime=1255611428.2989011) at rtpp_command.c:789
>>> #2  0x000000000040324b in main (argc=<value optimized out>,
>>>     argv=<value optimized out>) at main.c:742
>>>
>>> Is rtpproxy even usable?  Or is it too buggy due to lack of 
>>> substantial evolution and maintenance since OpenSER 1.1/1.2 days?
>>>
>>
>> Never mind, I was invoking it improperly:
>>
>>    -l one.ip other.ip
>>
>> not:
>>
>>    -l one.ip/other.ip
>>
>> this is because I copy/pasted it straight from the process list, where 
>> its argv exposure does not match the actual invocation.
>>
>> It does not crash anymore, but it does continues to not bridge packets.
> 
> I don't remember if there is need to enable ip forward, but definitely 
> is working, version is openser 1.3 or kamailio 1.4, check with rtpproxy 
> 1.0 -- i havent followed the latest devel of rtpproxy closely since I 
> need it just for rtp relaying and latest versions has quite complex new 
> features.

Strange.  I have never gotten it to work well.

What are the plausible alternatives?  MediaProxy 2.0 is too complex 
and requires a bunch of Python dependencies that aren't always easily 
installable, and, the RTP proxy component coming into SR from the SER 
side looks interesting but I'm not holding my breath on the integration.

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