NAT Traversal
From FreeSWITCH Wiki
Some difficulties have been encountered with devices that have poor NAT support.
In order to aid FreeSWITCH in traversing NAT please see the External profile page.
Some routers perform ALG (Application Layer Gateway) which can prevent NAT traversal from working, see that page for more information including how to disable it.
Contents |
STUN
Enable STUN settings on your phone in order to correctly report you phone's contact information to FreeSWITCH when registering. Unfortunately, not all phones have a STUN client.
STUN Support by Phone Mfg.
- Snom: Yes
- Sipura: Yes
- Cisco: No
- Polycom: No ('planned future support')
STUN Servers
This site contains a list of STUN servers: http://dumbme.mbit.com.au/trixbox/stun_servers.htm
Note: stun.fwd.org is gone; also stun.freeswitch.org is never guaranteed to be up and running so use it in production at your own risk.
apply-nat-acl
You can add the apply-nat-acl param to your profile to always force NAT behavior when matching a certain access list
<param name="apply-nat-acl" value="rfc1918"/>
sip_sticky_contact
<action application="set" data="sip_sticky_contact=true"/>
sip_nat_detected
sip_nat_detected is set to true when NAT is detected. use it in your dialplan to handle NATted devices differently
<condition field="${sip_nat_detected}" expression="true">
sip-force-contact
The sip-force-contact variable can be used to activate NATHACK / TLSHACK registration (rewrite contact IP/port).
{EXAMPLE}
<user id="100" mailbox="100">
<params>
<param name="password" value="1234"/>
<param name="vm-password" value="4321"/>
</params>
<variables>
<variable name="sip-force-contact" value="NDLB-connectile-dysfunction"/>
</variables>
</user>
NDLB-connectile-dysfunction
Rewrites contact IP and port.
NDLB-tls-connectile-dysfunction
Rewrites contact port
Phone NAT Settings
Your phone may allow you to specify an IP to use when registering.
Polycom
<nat nat.ip="4.2.2.2" nat.signalPort="" nat.mediaPortStart="" nat.keepalive.interval=""/>
FreeSWITCH behind NAT
With FreeSWITCH behind NAT, freeswitch can only bind its ports to a local IP. However when connecting to FreeSWITCH from an external network, the external IP is needed. With the standard setup users may be able to register phones correctly, however the phones may not be reached and you may encounter no audio or one way audio when a call is set up. This is one working example for FreeSWITCH behind NAT:
vars.xml
<X-PRE-PROCESS cmd="set" data="bind_server_ip=my.domain.com"/> <X-PRE-PROCESS cmd="set" data="external_sip_ip=stun:stun.freeswitch.org"/> <X-PRE-PROCESS cmd="set" data="external_rtp_ip=stun:stun.freeswitch.org"/>
host:domain.example.com is another possible value; however this will not toggle the autonat flags. If you are behind nat, with dynamic dns (and stun doesn't work) you should write a script that determines your public IP address, makes the change and calls reloadxml. This also holds true for the external profile. No special processing happens to determine the IP address before the variable gets passed to the external profile.
host:domain.example.com may be used in places "where you have two interfaces in a box and one is public facing and one isn't, so one never has to tell the lies."
- source bwk on irc.
internal.xml
<param name="ext-rtp-ip" value="$${external_rtp_ip}"/>
external.xml
<param name="ext-sip-ip" value="$${external_sip_ip}"/>
<param name="ext-rtp-ip" value="$${external_rtp_ip}"/>
Do not set ext-rtp-ip to a domain name instead of an IP or stun-entry; you will encounter a "SIP/2.0 500 Cannot Get IP Address for Media" error
By default external_sip_ip and external_rtp_ip are set in vars.conf.xml to use the FreeSWITCH STUN server.
