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

[Scott Berkman]

Simply put, if you want to do NAT traversal at the CPE, you must be 100%
certain that there is nothing that can even possibly considered an ALG or
Firewall in front of your NAT traversal device.

Many of the "SOHO" routers that the RBOCs deploy for business customers have
ALG's, and I have seen some (such as the Netopia's) where the ALG is
basically undocumented and cannot even be controlled via the GUI.

	-Scott

-----Original Message-----
From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org]
On Behalf Of Darren Schreiber
Sent: Saturday, August 21, 2010 2:37 PM
To: Alex Balashov
Cc: voiceops at voiceops.org
Subject: Re: [VoiceOps] "...but it works with Packet8"

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