We&#39;ve noticed that most devices that have a SIP ALG, simply look at packets on port 5060, generally they&#39;re not doing any sort of layer 7 packet inspection. So in order to avoid any SIP ALG issues, we generally use a random unused port for all the SIP traffic (both UAS and UAC side) so we don&#39;t have to worry about messing with the SIP ALGs at every site.<br>
<br>Cheers,<br>Gabe<br><br><div class="gmail_quote">On Sat, Aug 21, 2010 at 11:36 AM, Darren Schreiber <span dir="ltr">&lt;<a href="mailto:d@d-man.org">d@d-man.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
So we do most of what&#39;s below...<br>
<br>
The one thing that&#39;s a bit different about our service is we want to stay out of the media path and, &quot;under the hood&quot;, send the customer direct to the carrier for most calls. That&#39;s the point of our &quot;router&quot; - it&#39;s also a SIP proxy.<br>

<br>
The problem is that, in our tests, our SIP Proxy properly &quot;fixes&quot; NAT packets from phones, but then when they hit the DSL router w/ SIP ALG, it goes and mucks them up again. At which point we&#39;ve lost control cause the packet is on it&#39;s way to the carrier directly. We DO NOT want to proxy or take on media if we can avoid it - this is critical to our design, and probably the fundamental root of our problems :-) I suspect the reality is Packet8 takes on all media so #2 is possible, where-as we must do this at the proxy level BEFORE it leaves the network.<br>

<br>
I am trying to take an alternative approach and having our router/proxy get smarter. I think we may just start ignoring everything after the @ symbol when re-mapping devices and calls from the outside. I&#39;m otherwise out of ideas for this strategy without constantly turning off SIP ALG...<br>

<font color="#888888"><br>
- Darren<br>
</font><div><div></div><div class="h5"><br>
<br>
On Aug 21, 2010, at 11:27 AM, Alex Balashov wrote:<br>
<br>
&gt; The formula for successful far-end NAT traversal is:<br>
&gt;<br>
&gt; 1. CPE with symmetric NAT capability (most CPE these days).<br>
&gt;<br>
&gt; 2. Far-end media relay and draft-comedia style media source port<br>
&gt; detection.<br>
&gt;<br>
&gt; This one is really key.  It is critical for the service provider to<br>
&gt; ignore the media ports advertised in the customer-side SDP and<br>
&gt; &quot;listen&quot; to the media stream for the &quot;actual&quot; source port that is<br>
&gt; translated by the NAT gateway.  This requires a media gateway and/or<br>
&gt; relay that has the intelligence to wait at least one packetisation<br>
&gt; cycle for RTP received from the customer end before sending media back<br>
&gt; to it, and does assume symmetric RTP.<br>
&gt;<br>
&gt; Most higher-end commercial SBCs can do this, but the option has to be<br>
&gt; explicitly turned on.  The default behaviour here may account for the<br>
&gt; difference you see.<br>
&gt;<br>
&gt; There is pretty much no way to solve this problem without media relay<br>
&gt; at the service provider end, i.e. in case you were hoping for a purely<br>
&gt; proxy-based solution.<br>
&gt;<br>
&gt; 3. Yes, force rport.<br>
&gt;<br>
&gt; 4. Yes, aggressive override of network and transport-layer identifying<br>
&gt; information in SIP headers.<br>
&gt;<br>
&gt; 5. Disable all SIP ALGs on any firewalls and routers on the customer side.<br>
&gt;<br>
&gt; --<br>
&gt; Alex Balashov - Principal<br>
&gt; Evariste Systems LLC<br>
&gt; 1170 Peachtree Street<br>
&gt; 12th Floor, Suite 1200<br>
&gt; Atlanta, GA 30309<br>
&gt; Tel: +1-678-954-0670<br>
&gt; Fax: +1-404-961-1892<br>
&gt; Web: <a href="http://www.evaristesys.com/" target="_blank">http://www.evaristesys.com/</a><br>
&gt; _______________________________________________<br>
&gt; VoiceOps mailing list<br>
&gt; <a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
&gt; <a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
<br>
<br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</div></div></blockquote></div><br>