[VoiceOps] "...but it works with Packet8"

anorexicpoodle anorexicpoodle at gmail.com
Sat Aug 21 21:35:13 EDT 2010


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.

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. 

On Sat, 2010-08-21 at 12:22 -0700, Gabriel Kuri wrote:

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20100821/e6495caa/attachment.html>


More information about the VoiceOps mailing list