Hi Nick,
Use also the "f" flag (to ignore the indication of another rtpp in the
message) - Razvan made a point in spotting the "a=nortpproxy:yes" in the
incoming 183 reply.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 30.06.2014 21:17, Nick Cameo wrote:
Hello Bogdan, I am not sure what autobridging is however, this is our
architecture:
SIP Server 192.168.2.20
RTPProxy Server 192.168.2.5
Outside IP (Changed for Security): 77.71.33.152
Origination Carrier (Changed for Security): 333.444.555.666
Termination Carrier (Changed for Security): 222.11.22.33
We start RTPProxy using the following command:
/usr/local/rtpproxy/bin/rtpproxy -s udp:192.168.2.5:7789
<http://192.168.2.5:7789> -l 192.168.2.5/77.71.33.152
<http://192.168.2.5/77.71.33.152> -m 8000 -M 65535 -u root root -F -d
INFO LOG_LOCAL0
RTPProxy Related Script in OpenSIPS Configuration:
modparam("rtpproxy", "rtpproxy_sock", "udp:192.168.2.5:7789
<http://192.168.2.5:7789>")
branch_route[1]
xlog("L_INFO","New Branch For: $ru at IP: $si\n");
if(has_body("application/sdp"))
rtpproxy_offer("roc","77.71.33.152");
onreply_route[1]
xlog("L_INFO","Incoming Reply Route: From=$fu, To=$tu, RU=$ru,
CI=$ci IP=$si\n");
if(has_body("application/sdp"))
rtpproxy_answer("roc","192.168.2.5");
I have attached three documents which contain the related slice
for the problematic call in question:
[i] SIP Trace
[ii] RTP Trace
[iii] RTP Proxy log
Not on [iii], as you know there are two sessions per call. The first
has packets relayed from both
caller and callee for the inbound part. The second session (ie,
outbound) has 0 packets relayed
because the firewall is burning the packets both ways.
Not to sound redundant, this is one of the very few cases where we
experience such problems.
All other calls work as expected under the same environment.
Thanks in Advance,
Nick.
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
