[VoiceOps] Acme Adaptive Hosted NAT Traversal

[Mark R Lindsey]

One of my active carrier clients uses it with 6k+ SIP endpoints, and  
they've been happy with it.

When using anything that lengthens registration times to the access  
side of the SBC, be sure to consider the maximum failure-recovery time  
you need. If you have to manage the SBCs in a way that loses the  
registration cache, then your entire population of users will have to  
re-register. (For example, certain Acme Packet SD software upgrades  
delete the registration cache.)

Until they all re-register, some of your users will have no service.  
So, how fast can your entire CPE population re-register? This is a  
function of the size of your population, the performance of your SBCs,  
capabilities of the core-side registrar (softswitch); you don't want  
the re-registration storm to crash the softswitch, or create  
congestion collapse. You want to minimize the re-registration time to  
minimize the outage duration, especially since there are some FCC  
outage reporting implications for certain US-based VoIP carriers.

But, to reduce extraneous signaling load on the SBC and for your  
subscriber devices, you want to maximize the re-registration interval.  
The dynamic-HNT feature of the Acme Packet helps you do this.

Tradeoffs are always interesting.

mark r lindsey at e-c-group.com http://e-c-group.com/~lindsey +12293160013


On Sep 29, 2009, at 1:08 PM, 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/83efca40/attachment-0001.html>