[VoiceOps] acme nat traversal clue

[Scott Berkman]

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 10.0.1.80, and a
netscreen 50 with a static routable ip natted to the pbx at 1.1.1.1 (sip alg
is off).  my itsp has an acme at 2.2.2.2.

this is what an inbound call looks like right now:

2.2.2.2 -> 1.1.1.1 invite sip:xxxxxx at 1.1.1.1 <mailto:sip%3Axxxxxx at 1.1.1.1> 
10.0.1.80 -> 2.2.2.2 100 trying
10.0.1.80 -> 2.2.2.2 200 ok (contact: sip:xxxxxx at 10.0.1.80
<mailto:sip%3Axxxxxx at 10.0.1.80> )
2.2.2.2 -> 10.0.1.80 ack sip:xxxxxx at 10.0.1.80
<mailto:sip%3Axxxxxx at 10.0.1.80> 

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 1.1.1.1 has set it's contact
header address to 10.0.1.80 in it's 200 OK response back to 2.2.2.2 (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 1.1.1.1 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20091002/2d4e68c4/attachment-0001.html>