Now that we kind of understand how it works, we can look at other ways to trigger the NAT detection. In some cases, the ACL is not enough because maybe a sneaky ALG has messed up the packet or maybe the traffic is passing over a proxy or the phone may think it's handling the NAT case itself but it's not doing it quite right.

We have another option that is not enabled by default because it laughs in the face of the fourth pitfall and basically thinks almost anything slightly out of the ordinary is NAT. This parameter is dangerous but effective in cases where you have no other choice. The name of the parameter is aggressive-nat-detection and setting it to true in your SIP profile will enable it for all traffic. Basically it looks at the SIP packets and if it sees a variety of IP addresses in various headers, it uses logical deduction to figure out which one is the source address. From there it does the same thing that the ACL based one does, only it may not always be the source address that it writes into the database.

<param name="aggressive-nat-detection" value="true"/> 

The following diagram illustrates such a case:

FreeSWITCH has a family of parameters we refer to as "No Device Left Behind" or NDLB. These parameters denote situations where we completely mimic or accept a flaw in a device and pretend everything is peachy or make provisions for the device so it can still work despite the fact that we are utterly offended that we actually had to make it work by modifying the code. Those are especially useful when dealing with old clients that are not completely conform to SIP specifications.

One such parameter that is particularly effective in the battle against NAT is called force-rport. The purpose of the rport attribute in SIP is a minimal attempt to conquer NAT by appending ;rport to the request. When FreeSWITCH sees this attribute, it will respond in kind with a rport=host:ip attribute so the phone will realize it's behind NAT. The funny thing is, some phones can react properly when they see the rport in the response but never request it. The force-rport parameter causes FreeSWITCH to pretend that every device we talk to has supplied an rport parameter so we respond as if they did and hence unlock the functionality that would otherwise be unobtainable.

This parameter is also not enabled by default, as is the case for most NDLB options. It also opens up vulnerability to the fourth pitfall, since it can break many devices. You can either set it to true to always assume rport or set it to safe to only enable it for devices where we know it's required to make things work. You can also set it to client-only or server-only to only do it depending on the direction of the call but with any luck you will never need those options.