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

[Alex Balashov]

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.

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