<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><tt>Hi Nick,<br>
<br>
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.<br>
<br>
Regards,<br>
</tt>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a></pre>
On 30.06.2014 21:17, Nick Cameo wrote:<br>
</div>
<blockquote
cite="mid:CAGWRaZbKjE1uJb8jzvigpn9ajDqSih3gjhTT6G561HFWT7p6ig@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Hello Bogdan, I am not sure what autobridging is however,
this is our architecture:</div>
<div><br>
</div>
<div>SIP Server 192.168.2.20</div>
<div>RTPProxy Server 192.168.2.5</div>
<div>Outside IP (Changed for Security): 77.71.33.152</div>
<div>Origination Carrier (Changed for Security): 333.444.555.666</div>
<div>Termination Carrier (Changed for Security): 222.11.22.33</div>
<div><br>
</div>
<div>We start RTPProxy using the following command:</div>
<div><br>
</div>
<div>/usr/local/rtpproxy/bin/rtpproxy -s udp:<a
moz-do-not-send="true" href="http://192.168.2.5:7789">192.168.2.5:7789</a>
-l <a moz-do-not-send="true"
href="http://192.168.2.5/77.71.33.152">192.168.2.5/77.71.33.152</a>
-m 8000 -M 65535 -u root root -F -d INFO LOG_LOCAL0</div>
<div><br>
</div>
<div>RTPProxy Related Script in OpenSIPS Configuration:</div>
<div><br>
</div>
<div>modparam("rtpproxy", "rtpproxy_sock", "udp:<a
moz-do-not-send="true" href="http://192.168.2.5:7789">192.168.2.5:7789</a>")</div>
<div><br>
</div>
<div>branch_route[1]</div>
<div> xlog("L_INFO","New Branch For: $ru at IP: $si\n");</div>
<div> if(has_body("application/sdp"))
rtpproxy_offer("roc","77.71.33.152");</div>
<div><br>
</div>
<div>onreply_route[1]</div>
<div> xlog("L_INFO","Incoming Reply Route: From=$fu,
To=$tu, RU=$ru, CI=$ci IP=$si\n");</div>
<div> if(has_body("application/sdp"))
rtpproxy_answer("roc","192.168.2.5");</div>
<div><br>
</div>
<div><br>
</div>
<div>I have attached three documents which contain the related
slice</div>
<div>for the problematic call in question:</div>
<div><br>
</div>
<div>[i] SIP Trace</div>
<div>[ii] RTP Trace</div>
<div>
[iii] RTP Proxy log</div>
<div><br>
</div>
<div style="">Not on [iii], as you know there are two sessions
per call. The first has packets relayed from both</div>
<div style="">caller and callee for the inbound part. The second
session (ie, outbound) has 0 packets relayed</div>
<div style="">because the firewall is burning the packets both
ways.</div>
<div style=""><br>
</div>
<div style="">Not to sound redundant, this is one of the very
few cases where we experience such problems.</div>
<div style="">All other calls work as expected under the same
environment.</div>
<div style=""><br>
</div>
<div style="">Thanks in Advance,</div>
<div style=""><br>
</div>
<div style="">Nick.</div>
​</div>
</blockquote>
<br>
</body>
</html>