15 Oct
2009
15 Oct
'09
9:02 p.m.
Alex Balashov wrote:
Alex Balashov wrote:
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
Alex Balashov wrote:
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?
Daniel-Constantin Mierla wrote:
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(a)208.52.173.7 208.52.173.7 11832
as214288b6;1"
INFO:handle_command: new session
5f1690462d84b3814915b05f65c626bd(a)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.
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.