[VoiceOps] acme nat traversal clue

[Alex Balashov]

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 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
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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