[VoiceOps] Acme Adaptive Hosted NAT Traversal

[anorexicpoodle]

Using it in production now, and I recommend using it from day 1, using a
fixed nat traversal interval will chew up CPU on your acme when you have
large amounts of HNT traffic. In switching from HNT to AHNT i saw a
10-12% drop in CPU usage and absolutely no negatives. I have found that
most endpoints will land in a 90-120 second nat timer which reduces the
total volume of registration traffic the SD must handle by 75% over the
non-adaptive method. 

Just be aware of how your endpoints calculate their re-registration
timer since you may need to tweak it by a few seconds to get the 1st HNT
test to not collide with your endpoints short re-registration interval. 

On Tue, 2009-09-29 at 13:08 -0400, Parkin, Tyler wrote:
> Thanks for the feedback on Acme/STUN, guys.  
> 
>  
> 
> On a similar note, does anybody currently use Acme’s (A)HNT?  It seems
> like an effective way to eek out the longest registration possible for
> a NAT’d endpoint, and tests out pretty well in our lab, I’m just
> wondering how well it scales in a production environment.
> 
> 
>  
> 
> Tyler Parkin
> 
> tparkin at nuvox.com
> 
>  
> 
> 
> 
>  
> 
> 
> From: anorexicpoodle [mailto:anorexicpoodle at gmail.com] 
> Sent: Wednesday, September 23, 2009 12:28 AM
> To: Peter Childs
> Cc: Parkin, Tyler; voiceops at voiceops.org
> Subject: Re: [VoiceOps] Acme STUN
> 
> 
> 
>  
> 
> Most of the poorly implemented ALG's ive found, namely some of the
> integrated modem/router combos Verizon and Comcast are distributing,
> and many of the newer linksys devices, where the ALG is good enough to
> not trigger HNT but doesn't keep the NAT pinhole open, or they mangle
> the traffic in some way that cannot be corrected on the service
> provider side, use regex matching to replace private addressing at
> layer 5, so if the layer 5 addressing has been pre-mangled by STUN the
> ALG doesnt touch it since it isnt in the expected pattern, and things
> work normally. 
> 
> The multi-nat problem is something I have typically seen in hosted PBX
> deployments into managed network office buildings where the managed
> network is behind some kind of nat device, then each tenant drops in
> their own soho router, so inter-office calling breaks since the SDP
> the Acme sees isn't correct. You could correct around this by not
> releasing media for same-IP traffic but thats a change with big impact
> for a small problem that has other solutions. Of course YMMV.
> 
> 
> On Wed, 2009-09-23 at 13:25 +0930, Peter Childs wrote: 
> 
> 
>  
> On 23/09/2009, at 2:49 AM, anorexicpoodle wrote:
>  
> > I have been looking at this as well, and yes there are some  
> > advantages but you really have to have the need.
> > 
> > The good news:
> > 
> > - STUN will result in lower CPU on the SD since the keepalives dont  
> > need to be responded to. Chances are this will not be a factor.
> > - Can be used when the customers endpoint is behind multiple layers  
> > of NAT, Acme HNT falls flat on its face in this environment.
>  
> I have endpoints behind multiple layers of NAT working fine.    HNT  
> finds the smallest pinhole existing on the NAT path.
>  
> > - STUN mangled traffic will not trigger the broken ALG's in many  
> > newer home routers since it doesnt match the lan-side network any  
> > longer. If you have had the displeasure of experiencing these broken  
> > ALG's in customer routers (linksys, dlink etc etc), and the fact  
> > that they quite often cannot be disabled, it can lead to a very  
> > frustrating customer experience. Once again HNT and poorly  
> > implemented ALG's do not make for happy customers.
>  
>  
> (..)
>  
> 
> ______________________________________________________________________
> This email and any attachments ("Message") may contain legally
> privileged and/or confidential information. If you are not the
> addressee, or if this Message has been addressed to you in error, you
> are not authorized to read, copy, or distribute it, and we ask that
> you please delete it (including all copies) and notify the sender by
> return email. Delivery of this Message to any person other than the
> intended recipient(s) shall not be deemed a waiver of confidentiality
> and/or a privilege.
> 
> 
> 
> _______________________________________________
> 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/20090929/7b20e15d/attachment.html>