<p>don't proxy media when dealing with NAT. Set up a profile specifically for remote endpoints that doesn't bypass media.</p>
<p>Brian Foster<br>
Endigo Computer LLC</p>
<p>Sent from a mobile device.</p>
<div class="gmail_quote">On Jul 24, 2012 1:28 PM, "Phil Quesinberry" <<a href="mailto:philq@qsystemsengineering.com">philq@qsystemsengineering.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<u></u>
<div>
<p dir="LTR"><span lang="en-us"><font face="Calibri">Hi,</font></span><span lang="en-us"></span></p>
<p dir="LTR"><span lang="en-us"><font face="Calibri">Is this a bug? (just kidding)</font></span><span lang="en-us"></span></p>
<p dir="LTR"><span lang="en-us"><font face="Calibri">As</font></span><span lang="en-us"> <font face="Calibri">the number of extensions we serve increase</font></span><span lang="en-us"><font face="Calibri">s</font></span><span lang="en-us"><font face="Calibri">, w</font></span><span lang="en-us"><font face="Calibri">e</font></span><span lang="en-us"><font face="Calibri">’</font></span><span lang="en-us"><font face="Calibri">re trying to avoid</font></span><span lang="en-us"> <font face="Calibri">saturating our</font></span><span lang="en-us"> <font face="Calibri">local</font></span><span lang="en-us"> <font face="Calibri">bandwidth by</font></span><span lang="en-us"> <font face="Calibri">proxying all of the media between endpoints</font></span><span lang="en-us"><font face="Calibri">. This seems to work fine with the Link</font></span><span lang="en-us"><font face="Calibri">s</font></span><span lang="en-us"><font face="Calibri">ys devices but not with Aastra</font></span><span lang="en-us"><font face="Calibri"> in all scenarios.</font></span><span lang="en-us"><font face="Calibri"> The Aastras are configured with the NAT IP</font></span><span lang="en-us"> <font face="Calibri">field populated</font></span><span lang="en-us"><font face="Calibri"> appropriately</font></span><span lang="en-us"><font face="Calibri"> and Rport (RFC 3581) enabled.</font></span><span lang="en-us"></span></p>
<p dir="LTR"><span lang="en-us"><font face="Calibri">The FS</font></span><span lang="en-us"><font face="Calibri"> server is behind a NAT firewall with SIP and RTP port</font></span><span lang="en-us"><font face="Calibri"> ranges</font></span><span lang="en-us"><font face="Calibri"> forwarded to it. There are endpoints here</font></span><span lang="en-us"> <font face="Calibri">on the same network as the switch, and there are remote endpoints behind their o</font></span><span lang="en-us"><font face="Calibri">wn NAT firewalls. Everything works</font></span><span lang="en-us"> <font face="Calibri">fine in Proxy Media mode</font></span><span lang="en-us"><font face="Calibri"> but</font></span><span lang="en-us"><font face="Calibri"></font></span><span lang="en-us"> <font face="Calibri">i</font></span><span lang="en-us"><font face="Calibri">n bypass mode</font></span><span lang="en-us"><font face="Calibri"> we see the following behavior</font></span><span lang="en-us"><font face="Calibri">:</font></span></p>
<p dir="LTR"><span lang="en-us"></span></p>
<p dir="LTR"><span lang="en-us"><font face="Calibri">Scenario 1</font></span><span lang="en-us"><font face="Calibri">:</font></span></p>
<p dir="LTR"><span lang="en-us"><font face="Calibri">Remote</font></span><span lang="en-us"> <font face="Calibri">endpoint places a call to PSTN, FS negotiates bypass media between remote endpoint and</font></span><span lang="en-us"> <font face="Calibri">PSTN gateway. Call</font></span><span lang="en-us"> <font face="Calibri">succeeds</font></span><span lang="en-us"><font face="Calibri">.</font></span></p>
<p dir="LTR"><span lang="en-us"><font face="Calibri">Scenario 2:</font></span></p>
<p dir="LTR"><span lang="en-us"><font face="Calibri">Remote endpoint places a call to another remote endpoint on same LAN</font></span><span lang="en-us"><font face="Calibri">. Call succeeds.</font></span></p>
<p dir="LTR"><span lang="en-us"><font face="Calibri">Scenario 3:</font></span></p>
<p dir="LTR"><span lang="en-us"><font face="Calibri">Local endpoint places a call to PSTN gateway. Call succeeds.</font></span></p>
<p dir="LTR"><span lang="en-us"><font face="Calibri">Scenario</font></span><span lang="en-us"> <font face="Calibri">4</font></span><span lang="en-us"><font face="Calibri">:</font></span></p>
<p dir="LTR"><span lang="en-us"><font face="Calibri">Remote endpoint places a call to local endpoint</font></span><span lang="en-us"><font face="Calibri"> (or vice versa)</font></span><span lang="en-us"><font face="Calibri">. Call</font></span><span lang="en-us"><font face="Calibri"> fails with no audio</font></span><span lang="en-us"><font face="Calibri"> with Aastra devices</font></span><span lang="en-us"><font face="Calibri"> on both ends</font></span><span lang="en-us"><font face="Calibri">, but if one of the endpoints</font></span><span lang="en-us"><font face="Calibri"></font></span><span lang="en-us"> <font face="Calibri">is a LinkSys,</font></span><span lang="en-us"> <font face="Calibri">the</font></span><span lang="en-us"> <font face="Calibri">cal</font></span><span lang="en-us"><font face="Calibri">l succeeds</font></span><span lang="en-us"><font face="Calibri">.</font></span></p>
<p dir="LTR"><span lang="en-us"><font face="Calibri">I realize that I should be able to solve this problem with a</font></span><span lang="en-us"> <font face="Calibri">local</font></span><span lang="en-us"> <font face="Calibri">SBC</font></span><span lang="en-us"><font face="Calibri"> like OpenSIPS/RTPproxy</font></span><span lang="en-us"><font face="Calibri">,</font></span><span lang="en-us"><font face="Calibri"> but</font></span><span lang="en-us"> <font face="Calibri">in the meantime I</font></span><span lang="en-us"> <font face="Calibri">was hoping that</font></span><span lang="en-us"> <font face="Calibri">there</font></span><span lang="en-us"> <font face="Calibri">might be a setting that I was overlooking with the Aastra.</font></span><span lang="en-us"><font face="Calibri"> When I look at the SIP traffic for the call, FS appears to be negotiating the addresses/ports properly so I</font></span><span lang="en-us"><font face="Calibri"> suspect that this problem is related to</font></span><span lang="en-us"> <font face="Calibri">Aastra</font></span><span lang="en-us"><font face="Calibri">’</font></span><span lang="en-us"><font face="Calibri">s inability to deal with</font></span><span lang="en-us"> <font face="Calibri">symmetric NAT. The</font></span><span lang="en-us"> <font face="Calibri">Linksys</font></span><span lang="en-us"> <font face="Calibri">devices</font></span><span lang="en-us"><font face="Calibri"> seem to</font></span><span lang="en-us"> <font face="Calibri">be able to</font></span><span lang="en-us"> <font face="Calibri">deal with it</font></span><span lang="en-us"><font face="Calibri"> with FS</font></span><span lang="en-us"><font face="Calibri">’</font></span><span lang="en-us"><font face="Calibri"> help, presumably by doing some</font></span><span lang="en-us"> <font face="Calibri">UDP</font></span><span lang="en-us"> <font face="Calibri">hole-punching.</font></span><span lang="en-us"></span></p>
<p dir="LTR"><span lang="en-us"><i></i></span><span lang="en-us"><i></i></span><i><span lang="en-us"></span></i><i><span lang="en-us"><font face="Times New Roman">Phil Quesinberry</font></span></i><span lang="en-us"></span><span lang="en-us"></span><span lang="en-us"></span></p>
<p dir="LTR"><span lang="en-us"><font face="Arial">Q Systems Engineering, Inc.</font></span></p>
<p dir="LTR"><span lang="en-us"><font face="Arial">Electronic Controls and Embedded Systems Development</font></span></p>
<p dir="LTR"><span lang="en-us"><font face="Arial"><a href="tel:%28410%29%20969-8002" value="+14109698002" target="_blank">(410) 969-8002</a></font></span></p>
<p dir="LTR"><span lang="en-us"></span><a href="http://www.qsystemsengineering.com" target="_blank"><span lang="en-us"></span><span lang="en-us"><u></u></span><u><span lang="en-us"></span></u><u><span lang="en-us"><font color="#0000FF" face="Arial">http://www.qsystemsengineering.com</font></span></u><span lang="en-us"></span></a><span lang="en-us"></span><span lang="en-us"></span><span lang="en-us"></span></p>
<p dir="LTR"><span lang="en-us"></span></p>
</div>
<br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
Join Us At ClueCon - Aug 7-9, 2012<br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div>