One problem with SIP ALG (apart from the varying implementations which mean some work much better than others) is that it absolutely cannot work with SIP TLS - for obvious reasons, it can't see inside or rewrite the encrypted data.
Fair enough if that's the only way you found that worked for you, and if isn't broken don't fix it. :o)
Still, I do suggest people at least try to get their SIP clients handling NAT traversal correctly first.
Unfortunately there's no one true answer to getting NAT traversal working. The reason is that different SIP clients, NAT, firewall settings and implementations mean what works somewhere might not work elsewhere. That of course makes it harder to manage clients at multiple sites, roaming clients, etc.
The first thing to try would be to disable SIP ALG (if your phone is handling NAT correctly some might then rewrite the correct packet breaking it) and enable STUN on your SIP client.
STUN is a useful mechanism where you can talk to the STUN server from your internal address (IP+port) and it will tell you what your external address (IP+port) is. You can then use a trick called UDP hole punching whereby any server online can send to that external address and the NAT mapping will deliver it to your internal address. So your SIP client can learn its external SIP and RTP addresses and fill in the correct Contact header and SDP values. (Assuming SIP ALG is either disabled or intelligent enough not to then rewrite the correct values and break it). FreeSWITCH then has valid addresses it can send SIP responses and RTP media to.
That makes some assumptions though:
1) Your SIP client supports STUN (not all do)
2) Your NAT implementation maps your internal address to the same external port talking to any server. Some don't, mapping to a different port for each server.
3) Your firewall will allow packets to that external port from servers it hasn't spoken to. Personally I have to reduce the security level of my home router's firewall (O2 Broadband) from '' to 'Standard'. I suspect this is why.
This all applies to a number of protocols the same approach to traverse NAT. P2P clients, VoIP, VPNs (tinc), online gaming (eg Call of Duty) etc. If you can get CoD to tell you your NAT type is 'Open' you're probably ok. ;o)
If you can't get the correct IPs in Contact & SDP, you have a few fallback options in FreeSWITCH.
1) NDLB-connectile-dysfunction will change the Contact to the address the INVITE came from. Probably correct in 99% of cases.
2) FreeSWITCH can auto-adjust its RTP address. It tells the client where to send RTP to, and when it receives it it changes the SDP address to send audio back to there. Again probably correct in 99% of cases, but with an unfortunate but unavoidable sideaffect that the caller will hear absolutely no audio until shortly after they send RTP. That probably won't be until the call is actually answered, so they will never hear ringback and the first second of the call might get lost.
NAT devices have a limited number of ports and memory. As such old/unused mappings get removed from the table. You therefore need to make sure you keep the port mapping active. During a call you'll want to enable SIP keepalives to send a SIP request periodically to keep the port open, so that you can receive call state updates. When registering you'll periodically send REGISTER to keep your registration active, so that'll do it for you. In any case though you want to make sure they're sent frequently enough that your particular NAT router doesn't timeout the mapping. Every 30s should be fine.
If absolutely all else fails, your other option is to use a VPN to bypass the NAT entirely. I find OpenVPN over UDP works very well for that, and is very easy to set up. If you want to save load/bandwidth on the VPN server you could also use bypass_media and tinc which is a P2P VPN - sites join any public node and using UDP hole punching can try to talk directly to one another even behind NAT, but if that fails can still route packets via the public nodes.