<br><br><div class="gmail_quote">On Wed, Aug 24, 2011 at 2:24 AM, Saúl Ibarra Corretgé <span dir="ltr"><<a href="mailto:saul@ag-projects.com">saul@ag-projects.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<div class="im"><br>
<br>
> Good call, Saúl.<br>
> I had a _lot_ of problems getting MediaProxy to work initially so I ended up using someone else's config.<br>
><br>
> And this appears to be part of the problem - I'm using a config that works, but I don't know what it's up to. After removing all sorts of bits and pieces and adding stuff back I've found that if I remove the onreply_route that it _appears_ to work precisely as I expect it. OpenSIPS/MediaProxy is properly handling the media and no screwy ACKs.<br>
><br>
> The onreply_route was:<br>
> onreply_route[1] {<br>
> if (status =~ "(183)|(2[0-9][0-9])") {<br>
> if (client_nat_test("1")) {<br>
> fix_contact();<br>
> }<br>
> }<br>
> }<br>
><br>
> Will the removal of this cause any major issues? (The whole config is still here: <a href="http://pastebin.com/b2FGgTRX" target="_blank">http://pastebin.com/b2FGgTRX</a>).<br>
><br>
<br>
</div>If you want to use the separated functions you'll need to contemplate the case in which the caller it not behind NAT but the callee is. Also, Is the callee is behind NAT you need to fix the contact header for him, and you can only do this in the onreply_route.<br>
<br>
Your config looks simple, so why not go for engage_mediaproxy, which will call use_media_proxy and end_media_session automagically? In my experience, cases where no NAT traversal (at the RTP level) is needed are so narrow that it's usually better to just do it always.<br>
<br></blockquote><div>Hey Saul;<br><br>Actually, I did - the issue doesn't appear to be with mediaproxy being enabled but the nathelper doing fix_contact() twice. I've removed all of mediaproxy - problem still occurs. If I pull the above, and leave mediaproxy in (using engage_media_proxy() as you suggested which is, indeed, the nicer way to deal with it;) everything works exactly as expected.<br>
<br>I now understand what this section does, thank you. Would it not be up to the callee's SBC to correctly handle NAT headers for itself? (Keep in mind these calls are being sent to VoIP carriers like Bandwidth.com and Level3, so they should know what the heck they're doing)<br>
Or should I rephrase: Can I not rely upon our vendors, in this case, doing the right thing and taking the necessity for me to double-check them out... thereby fixing whatever it is that is on crack here?<br><br> - JP<br></div>
</div><br>