FreeSwitch Auto NAT

比眉伴天荒 2022-08-13 13:53 1010阅读 0赞

# 说明 #

FreeSWITCH的自动穿透机制使用NAT-PMP或者UPnP发现外部IP地址（external IP address），不再需要搜寻STUN服务。实现NAT功能的设备（如路由器等）必须支持UPnP或NAT-PMP，以便FreeSWITCH的自动穿透机制正常使用。在自动穿透机制正常运转后，要做的只是简单的配置一下sip profile文件。

**注意：**

1、仍推荐你为你的sip服务器提供商准备第二份配置文件。默认的conf/sip\_profiles/external.xml文件是特别为（sip服务）提供商而准备的。

2、nat自动穿透机制只应用NAT-PMP与UPnP。如果应用失败，则不会再回滚应用nat机制。

如需使用 STUN，需要设置外部 rtp地址（ external rtp）和外部 sip地址（external sip）。

3、从SVN版本15916开始，在/usr/local/freeswitch/conf/sip\_profile/internal.xml 和 external.xml中使用新的设置项：autonat：IP，如下所示：

这对于NAT-PMP 和UPnP 机制总是出问题的路由器来说非常有用。

# 安装步骤 #

从一个默认配置文件开始：

* 如果你的配置文件版本比较老（在 r13618 之前），在conf/sip\_profiles/internal.xml 找到下面两行：

*  取消下面两行的注释，并修改如下：

*  重启 FreeSWITCH 。输入命令“ sofia status” ，得到的输出如下所示：

API CALL \[sofia(status)\] output:   
Name Type Data State   
=================================================================================================   
internal profile sip:mod\_sofia@192.168.1.103: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

*  输入命令“ **sofia status profile internal** ” ，输出如下所示：

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 67.182.63.90   
SIP-IP 192.168.1.103   
Ext-SIP-IP 67.182.63.90   
URL sip:mod\_sofia@192.168.1.103:5060   
BIND-URL sip:mod\_sofia@192.168.1.103: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   
Registrations:   
=================================================================================================   
=================================================================================================

*  注意命令输出中含有“ Ext-RTP-IP” 和“ Ext-SIP-IP” 的两行，如下所示：

Ext-RTP-IP 67.182.63.90
 
 
 Ext-SIP-IP 67.182.63.90

*  如果上面的输出中含有公共 IP 地址（即路由器对外公布的地址），则代表自动穿透正在运行。通过检查 nat 设置可以看出通过 UPnP/NAT-PMP 获取的公共 IP 地址就是
    
    路由器等网络设备与外部交互的地址。

输入命令“ nat\_map status" ，来判断 nat\_map 是否在工作。输入如下所示：

Nat Type: UPNP, ExtIP: 76.237.11.11
 
 port,proto,proto_num,sticky
 
 5060,udp,0,0
 
 5060,tcp,1,0
 
 5080,udp,0,0
 
 5080,tcp,1,0
 
 4 total.

通过查看启动过程中的输出的一条调试信息来确定外部 IP 地址有没有被检测到：

2009-09-11 09:42:55.962276 [INFO] switch_nat.c:406 NAT detected type: upnp, ExtIP: '83.59.46.46'

**NOTE**  : 不管上面怎么配置都会启动 NAT 检测。如需关闭，使用 "-nonat" 选项启动 freeswitch 即可。

# 拨打电话测试 #

在这个测试中我使用的是 portaudio, 当然你也可以注册 sip 电话来测试。

我们将会使用 FreeSWITCH 公共会议回声测试，来验证两个方向的语音。如果拨打的电话能听到自己的回声，证明一切正常。下面是一个样例：

freeswitch> pa call sip:9196@conference.freeswitch.or
 
 
 2009-06-04 13:24:57 [NOTICE] switch_channel.c:602 switch_channel_set_name() New Channel portaudio/sip:9196@conference.freeswitch.org [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:9196@conference.freeswitch.org] has been answered
 
 
 API CALL [pa(call sip:9196@conference.freeswitch.org)] 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:9196@conference.freeswitch.org in context default
 
 
 2009-06-04 13:24:58 [NOTICE] switch_channel.c:602 switch_channel_set_name() New Channel sofia/internal/9196@conference.freeswitch.org [b34bd3c1-11ba-c54c-a518-4ca11f756726]
 
 
 2009-06-04 13:24:58 [NOTICE] sofia.c:3605 sofia_handle_sip_i_state() Channel [sofia/internal/9196@conference.freeswitch.org] has been answered

在此时你应该可以听见自己的回声。如果没有听到则需要检查网络配置。

下一步挂断电话：

freeswitch> pa hangup
 
 
 2009-06-04 13:25:07 [NOTICE] mod_PortAudio.c:1549 hangup_call() Hangup portaudio/sip:9196@conference.freeswitch.org [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 sofia/internal/9196@conference.freeswitch.org [CS_EXCHANGE_MEDIA] [
 
 
 NORMAL_CLEARING]
 
 
 2009-06-04 13:25:07 [NOTICE] switch_core_session.c:1085 switch_core_session_thread() Session 7 (sofia/internal/9196@conference.freeswitch.org) Ended
 
 
 2009-06-04 13:25:07 [NOTICE] switch_core_session.c:1087 switch_core_session_thread() Close Channel sofia/internal/9196@conference.freeswitch.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:9196@conference.freeswitch.org) Ended
 
 
 2009-06-04 13:25:08 [NOTICE] switch_core_session.c:1087 switch_core_session_thread() Close Channel portaudio/sip:9196@conference.freeswitch.org [CS_DESTROY]

恭喜！如果你看到上面的输出信息，证明你已经摆脱了其他人正在忍受的NAT 噩梦。

# Making A Test Call and bridging to a SIP phone #

下面的测试将会呼叫会议，并拨打位于默认域中用户 105 的 sip 电话，命令如下：

originate sofia/internal/9996@conference.freeswitch.org &bridge(user/105@default)

# 双 NAT 测试 #

1 ）双 NAT 场景主要表现在两个电话 endpoints 都位于它们各自的 NAT 设备之后。两个 FreeSWITCH 服务器各自都位于 UPnP/NAT-PMP 之后，如下所示：

FS1 <> NAT <> Internet <> NAT <> FS2

在这种情况下 FreeSWITCH 的自动穿透机制就派上了用场。像上面一样配置 FreeSWITCH ，然后分别将 FreeSWITCH 服务器注册到另一个服务器上。

2 ）使用 eyebeam/snom 的双 nat 网络，如下：

Eyebeam/snom1 <> NAT <> Internet <> NAT <> FS

和

Eyebeam/snom2 <> Internet <> NAT <> FS

两个客户端使用两个方式进行语音通话。 snom1 可以拨打 snom2, 反之亦然。发现这种一种现象：软电话收到“ BYE” 消息后挂断， FS 给的原因是“ACK timeout” （确认超时），尽管此时 FS 已经接收到“ ACK” 消息（此时仍有语音流，所以不应该是 RTP 超时）。不确定是否因为安装步骤错误导致的这个问题。一旦确定是该问题将立即升级。 Eyebeam 同时也开启了 stun服务。 FS 的 stun 不可用， autonat 可用。路由器是 netgear FVS318 无线路由器。 Snom 320 也存在同样问题。

# Troubleshooting #

<stub>

Upnp 部分 :

*  带有 autonat 功能的 FS 在启动时会开启 SIP 端口，同时也会动态的开启 RTP 端口。

*  路由器必须支持 upnp 。有一些路由器，如 FVS318 无线路由器，会被类似于 FS 的 upnp 设备在路由器上创建一张 upnp 端口映射表。通过该方式可以检验端口是否被正常的开启。

*  对于 FS 端，可以在 FS 的命令行中输入 "nat\_map add 1234 udp" ，检查路由器上的端口是否被开启。如果路由器有显示 upnp 端口映射表的功能最好，否则可以使用命令“ nat\_map add 1234 tcp" ，然后从外网 telnet 1234 端口，检查端口是否开启。

( 在测试完上面的命令后，可以使用命令 "delete" 代替“ add” ，手工的删除端口。如 nat\_map delete 1234 tcp ).

*  对于 FS 日志，可以检查 debug 模式下的日志。当通话正在进行中时，查看是否有 switch\_nat\_add\_mapping\_upnp() 用于增加端口，switch\_nat\_del\_mapping\_upnp() 用于删除端口。

*  使用源代码中的测试程序 miniupnpc 。进入 libs/miniupnpc 目录，输入make 进行编译，将会产生一个名为 "upnpc-static" 的文件。使用 "-l"选项列出现存的端口映射。同样，你也可以在网关设备上新建或删除映射的端口条目。

*  从 download.com 网站上下载工具 "UPnP port works" 。使用这个工具可以查看端口列表，新增、删除端口。使用该工具检查路由器上的UPnP 是否可用。（有时无法正常使用，但是只要先运行 BaUPnP ，再来使用的话则一切正常）。 该工具甚至可以用于转发 sip 端口，不过需要注意的是最终的目的是要 FS 可以正常的增删端口，不是端口转发。并且不能用来转发 RTP 端口，转发后也听不到声音。

*  使用 tcpdump 和 wireshark 抓取 UPnP 或 NAT-PMP 的数据包。UPnP 的过滤字符串是“ host 239.255.255.250” 。 NAT-PMP 的过滤字符串是“ host 224.0.0.1” 。

总之 :

*  在开始点对点通话前，先进行回声测试。测试失败了，就先解决回声的问题。

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.

# 支持 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: 2.11.62.2(RE0.C2D)3.10.16.0

# 支持自动穿透的 NAT-PMP 设备列表 #

*  Apple Airport Extreme with Firmware 7.4.2

Please update this wiki with list of routers as you test them

# 什么时候不使用穿透 #

FreeSwitch 搭建在公网，并且启动模式为“ nonat” 。就我所知， fs 仍针对那些位于 nat 设备后面的 ip 电话使用 nat 。（不是百分之百确定）。