[VoiceOps] acme nat traversal clue

Alex Balashov abalashov at evaristesys.com
Fri Oct 2 19:53:32 EDT 2009

OpenSER + media proxy (not necessarily mandatory, depending on the 
situation) for far-end NAT traversal is also a viable option here, 
depending on the precise requirements.

Scott Berkman wrote:

> 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 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. To troubleshoot why theirs isn’t would 
> require seeing the configuration and looking at any manipulations they 
> have in place on the relevant SIP Interfaces, realms, and local-policies.
> 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.
>                 -Scott
> *From:* voiceops-bounces at voiceops.org 
> [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *milosz
> *Sent:* Friday, October 02, 2009 7:09 PM
> *To:* VoiceOps
> *Subject:* [VoiceOps] acme nat traversal clue
> hi guys,
> need a bit of help... have never touched an acme before so i'm not sure 
> what to tell the people i am dealing with, and they seem incapable of 
> resolving the problem themselves.  trying to explain the difference 
> between layer 3 and layer 7 is not working.
> setup: i have an ip pbx with a single interface at, and a 
> netscreen 50 with a static routable ip natted to the pbx at (sip 
> alg is off).  my itsp has an acme at
> this is what an inbound call looks like right now:
> -> invite sip:xxxxxx at <mailto:sip%3Axxxxxx at>
> -> 100 trying
> -> 200 ok (contact: sip:xxxxxx at 
> <mailto:sip%3Axxxxxx at>)
> -> ack sip:xxxxxx at 
> <mailto:sip%3Axxxxxx at>
> so obviously it breaks at this point.
> according to them, they are unable to configure the acme to respond to 
> the originating routable ip instead of the nonroutable ip in the sip 
> contact.
> this is what someone at acme told them:
> It’s not a configuration issue, the endpoint at has set it’s 
> contact header address to in it’s 200 OK response back to 
> (SBC). The SD will look at the Contact header in order to 
> determine where to send future in-dialog requests such as ACK, BYE, 
> Re-INVITEs etc (according to RFC3261). Please can you check why 
> would be doing so?
> this sounds irrelevant to me, since any sip endpoint will set its 
> contact header address to its own ip.  sounds like this guy is saying 
> "well it's natted so that won't work, tell them to fix it."  i certainly 
> can't configure my pbx to respond with a modified contact header.
> can anyone provide some guidance here?  or maybe i am just wrong and it 
> is impossible to make this work.  but it looks like a basic hnt 
> situation to me.
> thanks,
> milosz
> ------------------------------------------------------------------------
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops

Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671

More information about the VoiceOps mailing list