Has anybody used the STUN functionality of the Acme SD? I posed the following questions to our SE and engineer, but if anybody has actual experience with it I'd be curious to know how it works. -Does it work? J -Re: performance, is STUN less costly than a very short registration refresh rate (<30 seconds)? Some impact on performance of a fully loaded SD 4000 would be appreciated. -Is it a better solution than their hosted NAT traversal? Thanks, Tyler 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.
Parkin, Tyler wrote:
Has anybody used the STUN functionality of the Acme SD? I posed the following questions to our SE and engineer, but if anybody has actual experience with it I?d be curious to know how it works.
-Does it work? J
-Re: performance, is STUN less costly than a very short registration refresh rate (<30 seconds)? Some impact on performance of a fully loaded SD 4000 would be appreciated.
-Is it a better solution than their hosted NAT traversal?
No, you'd be better off doing far-end NAT traversal on the Acme. You don't necessarily need to use frequent re-registrations for this if you think that it taxes the registrar; the Acme can, as most SIP network elements, send periodic OPTIONS pings to peers to determine if they're reachable, which also has the side effect of renewing the expiration timer on NAT gateways' state mappings for the UDP pinholes created by the registration and/or other activity. STUN is a giant science project, unless you have tight control over the CPE that the customers will use and it is very simple to provision it for STUN. Far-end NAT traversal, on the other hand, will work with almost anything. It is almost certain that the Acme can also do draft-comedia style media port detection[1], which is also necessary for far-end NAT traversal. Don't know about the performance metrics, but the ease of configurability and standardisation argument points solidly in favour of not using STUN, IMHO. STUN is not a common approach to this problem anymore for most service providers - at least, in my experience. I don't think most of my ITSP customers even remember what STUN is anymore. -- Alex [1] This is where the RTP port advertised in the SDP body received from the NAT'd endpoint is ignored, and the media relay agent instead waits to see what the *actual* source port of incoming media is before sending any of it sown, because that's where media needs to be sent in order to reach the endpoint. The SDP body will advertise the local source port (if the endpoint does symmetric RTP, which is generally the case), but the NAT gateway will remap it to some other port on the external interface. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
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. - 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. The bad news - STUN is a less stateful keepalive, i.e. when the endpoint fails to send a keepalive you cannot use forced un-registration or anything similarly clever to keep the presence on the softswitch in sync. - It requires client configuration whereas HNT is completely dynamic. My plan was to have both on tap, and make use of adaptive HNT for most customers but simply having a built-in STUN solution available as a tool for that 4-5% of customers might need it makes it absolutely worthwhile, however if you are in an environment where the access network is tightly controlled there is likely little need for it, but if you are broadband agnostic and just have to cope with whatever rinky-dink ISP/network setup the customer brings, then my advice is get as many tools in your toolbox as possible, just make sure you understand all of them inside and out or you will simply cause yourself unnecessary headache. On Tue, 2009-09-22 at 11:07 -0400, Parkin, Tyler wrote:
Has anybody used the STUN functionality of the Acme SD? I posed the following questions to our SE and engineer, but if anybody has actual experience with it I?d be curious to know how it works.
-Does it work? J
-Re: performance, is STUN less costly than a very short registration refresh rate (<30 seconds)? Some impact on performance of a fully loaded SD 4000 would be appreciated.
-Is it a better solution than their hosted NAT traversal?
Thanks,
Tyler
______________________________________________________________________ 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
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.
(..)
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.
(..)
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 <mailto: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.
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
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
participants (5)
-
abalashov＠evaristesys.com -
anorexicpoodle＠gmail.com -
lindsey＠e-c-group.com -
pchilds＠internode.com.au -
TParkin＠nuvox.com