The FreeSWITCH "auto-nat" feature allows FreeSWITCH to use NAT-PMP or UPnP to discover the external IP address. No STUN lookup is needed. The device performing the NAT must support UPnP or NAT-PMP for the auto-nat feature to work. When the auto-nat feature is fully functioning, only a single SIP profile is needed.
NOTE: It is still recommended that you use a second profile for your SIP providers. The default conf/sip_profiles/external.xml is set up specifically for use with providers.
The auto-nat feature will only perform NAT-PMP and UPnP requests and will NOT fall back in mechanisms like STUN. If you want to use STUN keep the option external rtp, external sip.
This is useful for those routers whose NAT-PMP or UPnP are not working reliably.
Warning Before You Get Started
One "feature" of UPnP is that it opens a hole in the firewall/NAT device that can (and often does) allow outside hosts to access your FreeSWITCH server. Do not use UPnP unless you absolutely have to. If you do use it, be sure to take protective measures like changing default passwords. You do not need UPnP if you have 1-to-1 NAT or if you have a static public IP address and can put it in your ext-sip-ip and ext-rtp-ip profile parameters.
Starting with a fresh default configuration:
- Edit lines in your SIP conf files and change them as follows:
<param name="ext-rtp-ip" value="auto-nat"/> <param name="ext-sip-ip" value="auto-nat"/>
- Start (or restart) FreeSWITCH. Issue the command sofia status and receive output like this:
API CALL [sofia(status)] output: Name Type Data State ================================================================================================= internal profile sip:email@example.com:5060 RUNNING (1) 192.168.1.103 alias internal ALIASED default alias internal ALIASED internal-ipv6 profile sip:mod_sofia@[::1]:5060 RUNNING (0) ================================================================================================= 2 profiles 2 aliases
- Issue the command sofia status profile internal and receive output like this:
API CALL [sofia(status profile internal)] output: ================================================================================================= Name internal Domain Name N/A DBName sofia_reg_internal Pres Hosts Dialplan XML Context public Challenge Realm auto_from RTP-IP 192.168.1.103 Ext-RTP-IP 18.104.22.168 SIP-IP 192.168.1.103 Ext-SIP-IP 22.214.171.124 URL sip:firstname.lastname@example.org:5060 BIND-URL sip:email@example.com:5060 HOLD-MUSIC local_stream://moh OUTBOUND-PROXY N/A CODECS G7221@32000h,G7221@16000h,G722,PCMU,PCMA,GSM TEL-EVENT 101 DTMF-MODE rfc2833 CNG 13 SESSION-TO 0 MAX-DIALOG 0 NOMEDIA false LATE-NEG false PROXY-MEDIA false AGGRESSIVENAT false STUN-ENABLED true STUN-AUTO-DISABLE false CALLS-IN 0 FAILED-CALLS-IN 0 CALLS-OUT 1 FAILED-CALLS-OUT 0
- Note the two lines with Ext-RTP-IP and Ext-SIP-IP:
Ext-RTP-IP 126.96.36.199 Ext-SIP-IP 188.8.131.52
- If these have public IP addresses then the auto-nat feature is working. You may wish to check the NAT device to confirm that the public IP address supplied via UPnP/NAT-PMP is the actual IP address that the Internet-facing side of the device is using.
You can also verify nat_map is working by issuing nat_map status which will give you output like:
Nat Type: UPNP, ExtIP: 184.108.40.206 NAT port mapping enabled. port,proto,proto_num,sticky 5060,udp,0,0 5060,tcp,1,0 5080,udp,0,0 5080,tcp,1,0 4 total.
During startup process you can look for a debug line to see what external IP is detected
2009-09-11 09:42:55.962276 [INFO] switch_nat.c:406 NAT detected type: upnp, ExtIP: '220.127.116.11'
NOTE : NAT detection happens irrespective of the above settings. To turn it off use "-nonat" to start freeswitch. If you still prefer to have NAT detection, but avoiding the port mapping using UPnP/NAT-PMP you can use "-nonatmap".
Making A Test Call
For this test I will use portaudio, but you can also register a SIP phone to make a test call - see below. We'll use the public FreeSWITCH conference echo test so that we can verify audio in both directions. If you make a call and can hear your voice echoed back to you then everything is working properly. Here's a sample console session:
freeswitch> pa call sip:firstname.lastname@example.org 2009-06-04 13:24:57 [NOTICE] switch_channel.c:602 switch_channel_set_name() New Channel portaudio/sip:email@example.com [77d54b4c-d395-af49-8950-2fe99635a0be] Pa_StartStream: waveInStart returned = 0x0. 2009-06-04 13:24:58 [NOTICE] mod_PortAudio.c:1773 place_call() Channel [portaudio/sip:firstname.lastname@example.org] has been answered API CALL [pa(call sip:email@example.com)] output: SUCCESS:4:77d54b4c-d395-af49-8950-2fe99635a0be 2009-06-04 13:24:58 [INFO] mod_dialplan_xml.c:252 dialplan_hunt() Processing FreeSWITCH->sip:firstname.lastname@example.org in context default 2009-06-04 13:24:58 [NOTICE] switch_channel.c:602 switch_channel_set_name() New Channel email@example.com [b34bd3c1-11ba-c54c-a518-4ca11f756726] 2009-06-04 13:24:58 [NOTICE] sofia.c:3605 sofia_handle_sip_i_state() Channel [firstname.lastname@example.org] has been answered
At this point you should be able to hear yourself echo. If not then you'll need to start doing network troubleshooting. See Reporting_Bugs for guidelines on collecting information and interacting with the mailing list and IRC channel.
Now hang up the call:
freeswitch> pa hangup 2009-06-04 13:25:07 [NOTICE] mod_PortAudio.c:1549 hangup_call() Hangup portaudio/sip:email@example.com [CS_EXECUTE] [NORMAL_CLEARING] API CALL [pa(hangup)] output: OK 2009-06-04 13:25:07 [NOTICE] switch_ivr_bridge.c:505 audio_bridge_on_exchange_media() Hangup firstname.lastname@example.org [CS_EXCHANGE_MEDIA] [ NORMAL_CLEARING] 2009-06-04 13:25:07 [NOTICE] switch_core_session.c:1085 switch_core_session_thread() Session 7 (email@example.com) Ended 2009-06-04 13:25:07 [NOTICE] switch_core_session.c:1087 switch_core_session_thread() Close Channel firstname.lastname@example.org [CS_DESTROY] WinMME StopStream: waiting for background thread. 2009-06-04 13:25:08 [NOTICE] switch_core_session.c:1085 switch_core_session_thread() Session 6 (portaudio/sip:email@example.com) Ended 2009-06-04 13:25:08 [NOTICE] switch_core_session.c:1087 switch_core_session_thread() Close Channel portaudio/sip:firstname.lastname@example.org [CS_DESTROY]
Congratulations! If you've gotten this far then you have been spared the brunt of the NAT horrors that others have endured.
Making A Test Call and bridging to a SIP phone
This will call the conference and ring the sip phone for user 105 in the default domain.
originate email@example.com &bridge(user/105@default)
Double NAT is a scenario where two endpoints are each behind their own respective NAT devices. In the case where two FreeSWITCH servers each are behind UPnP/NAT-PMP like this...
FS1 <> NAT <> Internet <> NAT <> FS2
... then FreeSWITCH's auto-nat can help. Set up each FreeSWITCH server like described above, then have one FreeSWITCH server register to the other.
SAMPLE SETUP FILES COMING SOON!!!
Doublenat with eyebeam/snom :
Eyebeam/snom1 <> NAT <> Internet <> NAT <> FS
Eyebeam/snom2 <> Internet <> NAT <> FS
Both "work" with audio both ways. snom1 could call snom2 and vice versa and also other phones on the LAN. Found that call is hung up with a "BYE" from FS stating reason is "ACK timeout" although "ACK" was being received at FS (and there was still audio, so shouldn't be due to RTP timeouts). Not sure if this is due to some wrong setup etc. Will update once it is clear. Eyebeam had stun enabled. FS had stun disabled and autonat enabled. Router was netgear FVS318 wireless. Same issue with snom 320 as well.
To turn it off use "-nonat" to start freeswitch. If you still prefer to have NAT detection, but avoiding the port mapping using UPnP/NAT-PMP you can use "-nonatmap".
Upnp part :
- FS with autonat opens SIP ports at startup and RTP ports dynamically
- Router must support upnp. Some routers like netgear FVS318 wireless, shows a table of upnp port mappings whey they are created by upnp devices like FS. Use this to check if ports are being opened properly.
- On FS side, you can do "nat_map add 1234 udp" on the console and check if the ports are getting opened in the router. If router has a feature of showing a table of mappings, use it. Otherwise perhaps you can use "nat_map add 1234 tcp", and then try to telnet from wan side of the router (if you can) and check if the port is open.
(You have to delete this mapping manually after issuing above command. To remove the mapping, use "delete" instead of "add").
- On FS logs, you can check in the console log (DEBUG) if when a call is placed and in progress it shows switch_nat_add_mapping_upnp() for adding, and switch_nat_del_mapping_upnp() for deleting ports.
- miniupnpc comes with a test program. cd into libs/miniupnpc and type "make". This will produce a file "upnpc-static". Use the "-l" option to list existing maps. You can also create/delete maps and get other information from the gateway device.
- Get the tool call "UPnP port works" (from download.com) Using this you can check the list of ports and even add/remove them. You can use this to test if the UPnP on the router works. (I have found this to not work sometimes, but if I run BaUPnP (download.com) first and then this it always worked.) Even if you forward the SIP ports, note that ultimately you want FS to be able to add / remove ports or it can't do this for RTP ports and you may not have audio.
- You can capture the UPnP or NAT-PMP traffic using tcpdump or wireshark. For UPnP, capture using a filter of 'host 18.104.22.168' and for NAT-PMP use a filter of 'host 22.214.171.124'.
- Always try echo test first before trying phone to phone. If echo test fails, then try to fix that first.
Issues with FS UPnP
- I have found that "UPnP port works" s/w was able to add / remove ports to the FS ip, but the nat_map command in the console did not. Please post similar experiences here and report to have them fixed.
Devices known to work with FS UPNP
- Linksys WRTxxx with dd-wrt or tomato firmware. dd-wrt version v24sp1 works functionally, but the UPNP UI page is always empty.
- Linksys WRT54GL with dd-wrt v24-sp2 10/10/09 std -or- v24 preSP2[Beta] Build 13064 (recommended) drops 5060 and 5080 tcp/upd mappings. The connections will be up for a minute or so, and then gone. (10/7/2010)
- above is also true for DD-WRT v24-sp2 (08/07/10) std. Tried adjusting timeouts in Administration->Management->IP Filter Settings (adjust these for P2P) with no joy.
- Tomato Version 1.28 on a wrt54gl works well (working for several weeks so far...).
- Linksys WRT54g2 with linksys firmware works with FS, but unreliable. FS can't open the ports sometimes. Please add your own experience.
- AT&T Uverse Residential gateway (by 2Wire) supports NAT-PMP. I am unable to find a status page that shows current mappings.
- Netgear FVS318 wireless supports upnp and shows a table of portmappings. Worked with FS autonat.
- Dlink DIR 655 wireless supports upnp, its "status"->"Internet sessions" shows "Local-NAT-Internet" port mappings. Please disable its "SIP ALG" feature under "Advanced"->"Firewall Settings"->"Application Level Gateway (ALG) Configuration", otherwise the SIP gateway registrations are not stable.
Note firmware 1.2.1 has UPNP bug, its UPNP function working for a while until after a couple of hours stopping work properly. new firmware 1.3.2NA seems to have corrected the UPNP bug per its claim, still keeping watching it on my DIR655.
DLINK DIR 655's UPNP is not stable even with firmware 1.3.2NA, not recommended for production use.
- Blanc Wireless G router BW54R11 Firmware 1.4.1 UPNP feature worked with FS auto-nat.
- Netgear wgt624 is a really bad router. Please stay away from it !
- Mikrotik routers: PC-based and RouterBoards with RouterOS v.3.25. Previous versions not tested (maybe working all 3.xx branch)
- Digicom wave 64 with firmware version: 126.96.36.199(RE0.C2D)188.8.131.52
- Asus WL-520GU with dd-wrt firmware v24sp2
NAT-PMP Devices known to work with auto-nat
- Apple Airport Extreme with Firmware 7.4.2
Please update this wiki with list of routers as you test them