[VoiceOps] acme nat traversal clue
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.
> *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 126.96.36.199 (sip
> alg is off). my itsp has an acme at 188.8.131.52.
> this is what an inbound call looks like right now:
> 184.108.40.206 -> 220.127.116.11 invite sip:xxxxxx at 18.104.22.168 <mailto:sip%3Axxxxxx at 22.214.171.124>
> 10.0.1.80 -> 126.96.36.199 100 trying
> 10.0.1.80 -> 188.8.131.52 200 ok (contact: sip:xxxxxx at 10.0.1.80
> <mailto:sip%3Axxxxxx at 10.0.1.80>)
> 184.108.40.206 -> 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
> this is what someone at acme told them:
> It’s not a configuration issue, the endpoint at 220.127.116.11 has set it’s
> contact header address to 10.0.1.80 in it’s 200 OK response back to
> 18.104.22.168 (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 22.214.171.124
> 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.
> VoiceOps mailing list
> VoiceOps at voiceops.org
Alex Balashov - Principal
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
More information about the VoiceOps