[VoiceOps] acme nat traversal clue

milosz mewash at gmail.com
Fri Oct 2 20:44:29 EDT 2009


> Have you tried turning ON the SIP ALG on the NS?  This should fix the
> contact header as it gets NATed on the way out.

the sip alg on the netscreen is weak and pretty much only ever breaks
things.  naturally i did try turning it on =)

> The Acme should be able to handle the NAT, we do that every day, but
> everything on the Acme has to be set up for that, and they may not support
> NAT traversal by choice.

sure.  according to them, though, they -do- support nat traversal and
they have "many customers already using it."

> In my opinion, you are better off NOT depending on the provider’s Acme to
> handle the traversal for you.  It can work well with one phone at a remote
> site, but for a whole PBX you are probably better off using the ALG in your
> Netscreen or  getting a SIP proxy for your end like a SIPerator or Edgemarc.
> Also what would you do if the provider told you flat out they don’t support
> NAT traversal?  If all that fails you could always put a public on the PBX,
> assuming the PBX vendor has the ability to secure itself.

i am aware of these options, unfortunately they are cost-prohibitive
at the moment.  i have no problem throwing a public ip on the pbx,
since it would be behind the netscreen anyhow, but adding another
interface to this particular ippbx, or even changing the ip address,
is a serious undertaking.

fair enough about being better off not depending on their nat
traversal.  i have around 500 endpoints behind the pbx, and if people
agree that it's generally better for me to handle my own traversal
then, at least for production, that is what i'll do.  so, for a
general case, assuming that the engineers on the other end have a
clue, is it somehow less reliable for me to depend on hosted nat
traversal for an ippbx with several hundred endpoints?  are there
limitations i am not aware of?

anyone have any insight on which of the openser forks is
superior/superior for nat traversal use?

milosz


More information about the VoiceOps mailing list