WebRTC连接FreeSWITCH时信令握手失败，如何排查局域网NAT与端口映射问题？

Question

WebRTC连接FreeSWITCH时信令握手失败（如INVITE无响应、408 Timeout或SDP交换中断），常源于局域网NAT与端口映射配置不当。典型表现：客户端能发REGISTER但无法建立媒体会话，或FreeSWITCH日志显示`no route to destination`、`ICE failed`、`STUN binding request timeout`。排查要点：① 确认FreeSWITCH的`external_ip`和`rtp-ip`在`vars.xml`中正确指向公网IP（非127.0.0.1）；② 检查防火墙是否放行SIP（5060/UDP/TCP）及RTP端口段（如16384–32768），并启用UPnP或手动配置路由器端口映射；③ 验证STUN/TURN服务可达（如`stun.l.google.com:19302`），通过Wireshark抓包确认STUN Binding Request是否发出及响应；④ 客户端WebRTC配置需启用`iceTransportPolicy: "all"`并设置有效`iceServers`；⑤ FreeSWITCH端启用`sofia global siptrace on`与`loglevel 7`，结合`fs_cli -x "sofia status profile internal"`核对NAT状态与联系地址。切忌忽略`local_network_acl` ACL配置导致内网地址被误判为外网。

Answer 1

```html

一、现象层：识别典型失败模式与日志指纹

WebRTC客户端可成功发送REGISTER请求并获200 OK，但后续INVITE无任何SIP响应（无100 Trying、无180 Ringing、无200 OK），或FreeSWITCH日志持续输出no route to destination、ICE failed、STUN binding request timeout。Wireshark可见客户端发出STUN Binding Request后无响应，或SIP INVITE被 silently dropped。此为NAT穿透失焦的“症状群”，非单一组件故障。

二、协议层：理解SIP信令流与ICE协商的耦合机制

• REGISTER仅建立逻辑注册关系，不触发媒体路径检测；而INVITE携带SDP需完成双向ICE候选交换、STUN连通性检查、RTP端口绑定
• FreeSWITCH的sofia profile internal在收到INVITE时，若external_ip未正确配置，将把内网地址（如192.168.1.100）写入Contact/SDP a=candidate，导致客户端向私有地址发包失败
• ICE Transport Policy设为"relay"或"none"会直接跳过host/candidate发现，加剧ICE failed

三、配置层：FreeSWITCH核心NAT参数校验清单

配置项	文件位置	正确值示例	错误典型
external_ip	conf/vars.xml	203.0.113.45（真实公网IP）	127.0.0.1 或 auto（未启用auto-detect）
rtp-ip	conf/vars.xml	203.0.113.45	$${local_ip_v4}（仍为内网）
local_network_acl	conf/autoload_configs/acl.conf.xml	rfc1918.auto + 显式添加192.168.0.0/16	缺失该ACL，导致FreeSWITCH将192.168.x.x误判为remote，禁用NAT优化

四、网络层：端口映射、防火墙与UPnP协同验证

执行以下命令链验证通路：

# 检查Linux iptables/nftables是否放行
sudo iptables -L INPUT | grep -E "(5060|16384:32768)"
# 验证路由器端口映射：外网IP:5060 → 内网FS_IP:5060（UDP/TCP双开）
# 测试STUN可达性（客户端侧）
curl -v "stun://stun.l.google.com:19302" 2>/dev/null | head -5
# 使用nmap探测外网端口开放状态（从第三方网络）
nmap -sU -p 5060,16384-16386 203.0.113.45

五、诊断层：全链路抓包与日志交叉分析法

graph LR
  A[WebRTC客户端] -->|1. STUN Binding Request| B(STUN Server)
  A -->|2. SIP REGISTER/INVITE| C[FreeSWITCH]
  C -->|3. SIP 408/No Response| A
  B -->|4. STUN Binding Success| C
  C -->|5. sofia status profile internal| D{NAT Status}
  D -->|nat-auto=TRUE & contact=203.0.113.45| E[路径正常]
  D -->|nat-auto=FALSE & contact=192.168.1.100| F[立即修正vars.xml]

六、客户端层：WebRTC RTCPeerConnection硬性配置要求

必须显式声明以下选项，缺一不可：

const pc = new RTCPeerConnection({
  iceTransportPolicy: "all", // 禁止设为"relay"或"none"
  iceServers: [
    { urls: "stun:stun.l.google.com:19302" },
    { 
      urls: "turn:turn.example.com:3478", 
      username: "user", 
      credential: "pass" 
    }
  ],
  bundlePolicy: "max-bundle",
  rtcpMuxPolicy: "require"
});

七、进阶陷阱：ACL误配引发的“伪NAT”故障

当local_network_acl未正确定义内网段时，FreeSWITCH的sofia模块会错误地认为客户端位于“远端网络”，从而强制启用nat-options策略（如rewrite Contact header为external_ip），但此时external_ip尚未正确设置，导致Contact头为空或非法，最终SIP栈丢弃INVITE并记录no route to destination。此问题在混合云部署中高频出现——K8s Service IP、Docker bridge IP均需纳入ACL。

八、验证闭环：五步终端确认法

1. 运行fs_cli -x "sofia status profile internal"，确认NAT Auto Enable为true且Contact Address显示公网IP
2. 执行fs_cli -x "sofia global siptrace on"后发起呼叫，检查siptrace中INVITE的Via/Contact/SDP含公网地址
3. 在客户端Chrome打开chrome://webrtc-internals，筛选iceCandidateType: "srflx"或"relay"，排除全为"host"
4. 抓包过滤ip.addr == 203.0.113.45 and (udp.port == 19302 or udp.port == 5060)，确认双向流量存在
5. 使用sngrep -l -d any "port 5060"实时观察SIP事务完整TID链

九、生产加固建议：自动化健康检查脚本

将以下逻辑封装为cron任务，每5分钟校验：

#!/bin/bash
# check_fs_nat.sh
EXT_IP=$(curl -s https://api.ipify.org)
FS_CONTACT=$(fs_cli -x "sofia status profile internal" | grep "Contact Address" | awk '{print $3}')
if [[ "$FS_CONTACT" != "$EXT_IP" ]]; then
  echo "[ALERT] FreeSWITCH Contact mismatch: expected $EXT_IP, got $FS_CONTACT" | logger -t fs-nat
  systemctl restart freeswitch
fi

十、延伸思考：WebRTC over QUIC与FreeSWITCH 2.0演进方向

当前SIP over UDP/TCP与ICE/STUN架构在高丢包、多NAT链路下存在固有延迟。FreeSWITCH 2.0已实验性支持SIP over QUIC及TURN over HTTP/3，可规避UDP黑洞与QoS策略干扰。但需注意：QUIC依赖ALPN协商，需在TLS证书中嵌入h3标识，且客户端WebRTC引擎（Chrome 120+）需启用--enable-features=WebRTC-QuicTransport标志。此路径虽非当前解法，却是未来三年NAT穿透演进的关键支点。

```