My main experience is with the Linksys/Cisco (sipura) SPA-2102 ATA. I always disable ALG in the router. I turn on NAT ping of 15 seconds in the Linksys. And.. here's the variable part - I also turn on 2-5 of the VIAs. I haven't really pinned that one down. This is not strictly NAT related... but has bit me a few times: devices by default want to use :5060 for their SIP. Not all are smart enough to see something else is using it and try a different port automatically. And for your peace of mind, try to never need NAT on the server. -Avi On Sun, Dec 16, 2012 at 7:15 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Hi Sean,
Thank you for the detailed reply.
The more info we can get about individual NAT experiences, the better - I'm hoping others will follow suit!
Cal
On Sun, Dec 16, 2012 at 4:57 PM, Sean Devoy <sdevoy@bizfocused.com> wrote:
I have spent many hours working on *NAT issues on client end*, my server has a public address. ****
** **
With CISCO brand phones I did not need any non-standards compliant settings, just turning on all the choices in the CISCO web setup NAT section. However, with Polycom 335 phones (as of Dec 2012) I could not get registered or get audio without the following:****
* NDLB-connectile-dysfunction****
* NDLB-force-rport****
* Enable SIP ALG on my FIOS router.****
With those setting however, this has worked perfectly. Also note that when I turned on SIP ALG, my Cisco phones quite working until I added the NDLB parameter/variable to the Cisco <user> in the directory. They seem to be quite complimentary but seem be requirements for each other.****
** **
I really tried to stay away from SIP ALG because so many posts were so negative about it. Without the NDLB “flags” I could never see any difference when enabling SIP ALG. The combination for me has been fantastic.****
** **
HOWEVER, since there are so many different versions of “success” in the IRC and Wiki, I am pretty sure that other router brands with different SIP ALG implementations and/or other phone brands or even firmware versions may need different configurations. It is almost like we just need a checklist that says try these combinations until you find one that fits your site.* ***
** **
HTH,****
sean****
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Cal Leeming [Simplicity Media Ltd] *Sent:* Sunday, December 16, 2012 11:15 AM *To:* FreeSWITCH Users Help *Subject:* [Freeswitch-users] NAT traversal - the final say..!****
** **
*Any and all feedback on this thread would be much welcomed.*****
** **
Hello,****
** **
There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. ****
** **
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.****
** **
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.****
** **
The following REGISTER is sent from a phone.****
** **
REGISTER sip:1.2.3.4:5060 SIP/2.0****
Via: SIP/2.0/UDP 192.168.1.102:57787 ;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport****
Max-Forwards: 70****
Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513<https://mail.google.com/_/mail-static/_/js/main/m_i,t,it/rt=h/ver=dQ95YePrryI.en./sv=1/am=!rQczwx1unpD1BO2bNKsLUpXXtiIjaa01SgsJmP23wMtqPKKB37R0dPvFB_9tzlm4wJdbIQ/d=1>
****
To: "foxx"<sip:2000@1.2.3.4:5060>****
From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448****
Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI.****
CSeq: 7 REGISTER****
Expires: 120****
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE****
Supported: replaces****
User-Agent: 3CXPhone 6.0.25732.0****
Content-Length: 0****
** **
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being; ****
** **
* NDLB-connectile-dysfunction****
* NDLB-force-rport****
* apply-nat-acl****
* sip-force-contact****
** **
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.****
** **
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.****
** **
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.****
** **
So, I'd like to present the following arguments;****
** **
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?****
** **
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.****
** **
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.****
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org