<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Jon is correct in that you may want to test "nat-traversal always" when the SIP-Via and transport addresses do not match. In fact, this is recommended (by Broadsoft) if you are using Broadworks as the SIP Registrar platform fronted by an SD. That being said, Jon also has a valid point that SIP ALG for IP PBX's has a known track record of compatibility issues. In some cases basic inbound/outbound call flow may work but calls forwarded or transferred to the PSTN may likely experience one way audio. There are some compensation measures that can be addressed on Cisco Pix/ASA firewalls that deal with this, but in most cases it's an unfortunate fact of life that the ITSP cannot force a customer to use a specific firewall and therefore has to go through rigorous testing and support for SIP Trunking validation on their network. This is where a true B2BUA may provide much better results and eliminate most the headache that is associated with testing/supporting SIP Trunking from an IP PBX into a Softswitch. On the surface most would think an IP PBX may be treated like any other SIP-HNT device or perhaps a SIP ALG would provide full interoperability, but this is usually not the case.<div><br></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 9px/normal Helvetica; "><span class="Apple-style-span" style="font-size: medium;"><font class="Apple-style-span" size="1"><span class="Apple-style-span" style="font-size: 9px;"><br></span></font></span></div><div><div><div>On Jun 8, 2011, at 9:12 PM, Jon Radel wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">
<br>
<br>
On 6/8/11 11:36 PM, Ujjval Karihaloo wrote:
<blockquote cite="mid:b1e8e2903d135abb373cb63e20fce388@mail.gmail.com" type="cite">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
<div class="WordSection1"><p class="MsoNormal">Hi All:</p><div> <br class="webkit-block-placeholder"></div><p class="MsoNormal"> We have seen many PBX NAT’ed behind a
Firewall that does not do the Sip ALG correctly. Most cases
putting the Private IP in the Contact header and the ACME
responds back to the Private IP.</p><div> <br class="webkit-block-placeholder"></div><p class="MsoNormal">Example call inbound to the PBX, the PBX
sends a 200 OK (as call is answered) with a Private IP in the
contact header. ACME sends the ACK back to the Private IP
blackholing it.</p><div> <br class="webkit-block-placeholder"></div><p class="MsoNormal">I have seen SBC’s that do adjust to the
Layer 3 IP:port if they notice Private IPs in the SIP
signaling. Is there a setting on ACME to do that?</p>
<br>
</div>
</blockquote>
Read up on<br>
nat-traversal always<br>
in the sip interface section of the config. I will note, however,
that that looks for the Contact-URI and topmost VIA to match and to
be different than the source address in layer 3 (IP), rather than
looking for RFC 1918 addresses. Of course, given that there are
umpteen hundred knobs to twist on an Acme, there's probably some way
of getting it to do this only for RFC 1918 addresses, but I'm not
sure there's value in doing that and certainly couldn't tell you how
to do it. My understanding is that "nat-traversal always" is the
"normal" way of doing what you appear to need.<br>
<br>
As an operational note, we've had more problems with various
customer firewalls doing pretty bad jobs with SIP, such as the one
that worked fine until somebody transferred a call at which point
the firewall just dropped all sorts of vital packets on the floor,
than we've ever had just letting our Acmes do NAT traversal. Our
standard recommendation is to turn all SIP aware proxies, fix-up,
etc. off.<br>
<br>
--Jon Radel<br>
</div>
_______________________________________________<br>VoiceOps mailing list<br><a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>https://puck.nether.net/mailman/listinfo/voiceops<br></blockquote></div><br></div></div></body></html>