FreeSWITCH无法呼叫热点/WiFi注册用户问题求助

核心问题梳理 #

用户B（4G网络）呼叫A正常，但FreeSWITCH通过bgapi originate user/B &echo主动呼叫B时多数失败，触发RECOVERY_ON_TIMER_EXPIRE挂断，抓包显示FS发送的INVITE未到达B。已配置apply-nat-acl、auto-nat及正确的公网IP，但问题未解决。

针对性排查与解决步骤 #

1. 验证注册信息与NAT绑定时效性 #

• 执行show registrations查看用户B的注册详情：
  • 确认Contact字段的IP/端口（123.116.254.94:4392）是否与FS记录一致
  • 检查expires值，4G网络NAT超时通常较短，建议在用户配置中缩短注册过期时间：

    <param name="expire-seconds" value="60"/>
    

    让终端更频繁更新NAT映射，避免FS使用失效的端口/IP发起呼叫。

2. 启用NAT保活机制 #

在sip_profile/internal.xml中添加NAT探测配置，维持4G网络的NAT映射：

<param name="nat-options-ping" value="true"/>
<param name="ping-interval" value="30"/>

通过定期发送OPTIONS包，防止运营商NAT回收端口映射，确保FS主动呼叫时数据包能穿透NAT。

3. 调整主动呼叫的路由参数 #

• 尝试直接用注册时的公网IP/端口发起呼叫，绕过FS内部路由验证：

  bgapi originate sofia/internal/sip:B@123.116.254.94:4392 &echo
  

  若能接通，说明FS内部路由解析存在问题，需检查用户匹配规则或DNS配置。
• 强制指定INVITE的Domain为FS公网IP：

  bgapi originate user/B &echo sip_invite_domain=你的公网IP
  

  避免INVITE携带内部IP导致NAT拦截。

4. 处理对称NAT限制（4G常见场景） #

4G网络多为对称NAT，仅允许主动发起连接的一方接收后续数据包：

• 在终端配置STUN服务器（如stun.l.google.com:19302），让B注册时上报公网IP/端口而非本地地址
• 在FS的sip_profile/internal.xml中启用STUN支持：

  <param name="stun-server" value="stun.l.google.com:19302"/>
  <param name="force-stun" value="true"/>
  

  确保FS能获取到B的真实公网映射信息。

5. 优化SIP重传策略 #

调整sip_profile/internal.xml中的重传参数，提高穿透NAT的概率：

<param name="sip-invite-retransmit-max" value="10"/>
<param name="sip-invite-retransmit-timeout" value="2000"/>

增加重传次数和超时时间，降低因数据包丢失导致的呼叫失败。

6. 深度日志与抓包分析 #

• 开启FS调试日志：fs_cli -x "loglevel 7"，发起呼叫后检查SIP消息的Via、Contact、To头，确认目标IP/端口是否正确
• 若条件允许，在用户B的终端抓包，验证是否真的未收到INVITE：
  • 若终端未收到：问题出在运营商NAT或FS的公网IP配置
  • 若终端收到但未响应：检查终端的SIP过滤规则

内容的提问来源于stack exchange，提问作者bookyao