<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#ffffff">
Depending on your business model simply telling the customer how their firewall should be configured may work, but its not something that i suspect will take you too far since you are leaving the ability to break your service in the hands of your customer, which ultimately means they will break it, then be cross at you for something they did. Not an enviable situation at all. <BR>
<BR>
We have had a great deal of success simply abandoning port 5060 and using port numbers over 10000 on the endpoint and SBC, since most ALG's simply do protocol detection based on port, this will dodge much of your ALG/fixup headaches straight away. There are of course still some CPE routers with a more clever ALG that will catch this, but it dramatically reduces your exposure. <BR>
<BR>
Also to any CPE hardware manufacturers out there reading this....STOP IT! You know who you are..... :)<BR>
<BR>
<BR>
-anorexicpoodle<BR>
<BR>
<BR>
<BR>
On Thu, 2011-06-09 at 00:12 -0400, Jon Radel wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
On 6/8/11 11:36 PM, Ujjval Karihaloo wrote:
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE TYPE=CITE>
Hi All:<BR>
<BR>
<BR>
<BR>
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.<BR>
<BR>
<BR>
<BR>
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.<BR>
<BR>
<BR>
<BR>
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?<BR>
<BR>
<BR>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
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
<PRE>
_______________________________________________
VoiceOps mailing list
<A HREF="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</A>
<A HREF="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>