[VoiceOps] acme nat traversal clue
Brad at broadcore.com
Fri Oct 2 19:58:49 EDT 2009
Assuming the SD is configured to do NAT traversal, my guess would be that the ALG on the fire wall is not completely off. In such case ACME would think that some other device is addressing the NAT traversal issue and would register the user agent as a non HNT device.
Checking the registration on the SD would confirm whether my guess is true or not. Run the command: "show registration sipd by-user <endpoint> detail
If you see a line including "acme_nat=......." Under "User Agent Info:", it means that the endpoint registered as an HNT device. Good luck,
From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of milosz
Sent: Friday, October 02, 2009 4:09 PM
Subject: [VoiceOps] acme nat traversal clue
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 220.127.116.11 (sip alg is off). my itsp has an acme at 18.104.22.168.
this is what an inbound call looks like right now:
22.214.171.124 -> 126.96.36.199 invite sip:xxxxxx at 188.8.131.52<mailto:sip%3Axxxxxx at 184.108.40.206>
10.0.1.80 -> 220.127.116.11 100 trying
10.0.1.80 -> 18.104.22.168 200 ok (contact: sip:xxxxxx at 10.0.1.80<mailto:sip%3Axxxxxx at 10.0.1.80>)
22.214.171.124 -> 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 126.96.36.199 has set it's contact header address to 10.0.1.80 in it's 200 OK response back to 188.8.131.52 (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 184.108.40.206 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the VoiceOps