<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3">
</HEAD>
<BODY>
I think Gabriel is right on the money here. If you are complaining about CPE with ALG's messing with traffic, then just dodge the ALG's.<BR>
<BR>
Linksys, Cisco, D-link, 2-Wire, Actiontek etc are all including SIP ALG's in their products these days and they all suck and just break things. The easiest solution is to make your traffic look like something they shouldn't mess with. We have seen this problem too, and the solution is to just dodge it with unusual ports on UAS and UAC. <BR>
<BR>
On Sat, 2010-08-21 at 12:22 -0700, Gabriel Kuri wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
We've noticed that most devices that have a SIP ALG, simply look at packets on port 5060, generally they'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't have to worry about messing with the SIP ALGs at every site.<BR>
<BR>
Cheers,<BR>
Gabe<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
On Sat, Aug 21, 2010 at 11:36 AM, Darren Schreiber <<A HREF="mailto:d@d-man.org">d@d-man.org</A>> wrote:<BR>
<BLOCKQUOTE>
So we do most of what's below...<BR>
<BR>
The one thing that's a bit different about our service is we want to stay out of the media path and, "under the hood", send the customer direct to the carrier for most calls. That's the point of our "router" - it's also a SIP proxy.<BR>
<BR>
The problem is that, in our tests, our SIP Proxy properly "fixes" 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've lost control cause the packet is on it'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'm otherwise out of ideas for this strategy without constantly turning off SIP ALG...<BR>
<BR>
<FONT COLOR="#888888">- Darren</FONT>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BR>
<BR>
On Aug 21, 2010, at 11:27 AM, Alex Balashov wrote:<BR>
<BR>
> The formula for successful far-end NAT traversal is:<BR>
><BR>
> 1. CPE with symmetric NAT capability (most CPE these days).<BR>
><BR>
> 2. Far-end media relay and draft-comedia style media source port<BR>
> detection.<BR>
><BR>
> This one is really key. It is critical for the service provider to<BR>
> ignore the media ports advertised in the customer-side SDP and<BR>
> "listen" to the media stream for the "actual" source port that is<BR>
> translated by the NAT gateway. This requires a media gateway and/or<BR>
> relay that has the intelligence to wait at least one packetisation<BR>
> cycle for RTP received from the customer end before sending media back<BR>
> to it, and does assume symmetric RTP.<BR>
><BR>
> Most higher-end commercial SBCs can do this, but the option has to be<BR>
> explicitly turned on. The default behaviour here may account for the<BR>
> difference you see.<BR>
><BR>
> There is pretty much no way to solve this problem without media relay<BR>
> at the service provider end, i.e. in case you were hoping for a purely<BR>
> proxy-based solution.<BR>
><BR>
> 3. Yes, force rport.<BR>
><BR>
> 4. Yes, aggressive override of network and transport-layer identifying<BR>
> information in SIP headers.<BR>
><BR>
> 5. Disable all SIP ALGs on any firewalls and routers on the customer side.<BR>
><BR>
> --<BR>
> Alex Balashov - Principal<BR>
> Evariste Systems LLC<BR>
> 1170 Peachtree Street<BR>
> 12th Floor, Suite 1200<BR>
> Atlanta, GA 30309<BR>
> Tel: +1-678-954-0670<BR>
> Fax: +1-404-961-1892<BR>
> Web: <A HREF="http://www.evaristesys.com/">http://www.evaristesys.com/</A><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">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">https://puck.nether.net/mailman/listinfo/voiceops</A><BR>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<PRE>
_______________________________________________
VoiceOps mailing list
<A HREF="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</A>
<A HREF="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>