当你满怀期待地搭建好FreeSWITCH用两个软电话成功呼叫却发现通话总是在30秒左右莫名其妙地中断——别急这是SIP新手最常遇到的“经典Bug”。本文将为你抽丝剥茧彻底解决这个问题并附带其他可能引发通话异常中断的原因排查指南。一、现象描述使用SIP.js、JsSIP或其他SIP软电话注册到FreeSWITCH后通话能够正常建立双方也能听到声音但大约30秒有时是32秒后通话自动挂断控制台或日志中可能没有任何明显的错误提示。这个现象在本地环境localhost或局域网内测试时尤其常见但在跨网络环境如云服务器、NAT环境中也可能发生。二、核心原因ACK消息丢失导致SIP会话超时1. SIP三次握手回顾在SIP协议中一通正常的呼叫需要完成以下三次握手1INVITE主叫方向被叫方发起呼叫请求。2200 OK被叫方同意接听返回成功响应。3ACK主叫方收到200 OK后必须发送ACK确认至此通话才算正式建立。如果FreeSWITCH在发出200 OK后迟迟没有收到对方发来的ACK它就会认为会话没有真正建立于是在等待一段时间默认约32秒后主动发送BYE消息挂断通话释放资源。2. 为什么ACK会丢失ACK消息丢失的核心原因通常是SIP信令中携带的IP地址不正确导致ACK无法路由回FreeSWITCH。FreeSWITCH在生成SIP消息如200 OK时会在Contact和Via头域中填入自己的“外部”地址。这个地址可能来自1配置文件中的ext-sip-ip参数2全局变量external_sip_ip3自动检测的网络接口IP如果这个IP地址1是127.0.0.1而客户端在另一台设备上2是内网IP如192.168.1.x而客户端在公网3是某个不可达的地址4是错误自动检测的IP如云服务器的内网IP……那么客户端发送的ACK就会发往一个错误的目的地FreeSWITCH永远收不到最终超时挂断。3. 如何验证ACK丢失最直接的验证方法是抓包分析。1使用tcpdumpLinux/macOS或WiresharkWindows抓取SIP信令端口默认5060的数据包。2发起一次通话观察SIP交互过程主叫发INVITE → FreeSWITCH返回100 Trying → 被叫振铃 → FreeSWITCH返回180 Ringing → 被叫接听 → FreeSWITCH返回200 OK →此时应看到主叫发回ACK。3如果主叫发回的ACK的Request-URI或Via中的IP地址不是FreeSWITCH的真实地址或者根本没有ACK数据包则说明IP配置错误。另外在FreeSWITCH控制台中执行sofia status profile internal查看Contact字段显示的IP地址如果该地址不是正确的服务端IP也说明配置有问题。三、其他可能导致通话异常中断的原因除了ACK超时还有以下几种情况也可能导致通话在短时间内或不定时中断1. NAT穿透问题导致媒体流超时如果通话能听到声音但几十秒后中断也可能是RTP媒体流音频在NAT环境下不通。FreeSWITCH默认配置了rtp-timeout-sec参数通常为300秒但如果媒体流从未成功建立可能会导致更短时间的超时。常见场景客户端在公网FreeSWITCH在局域网未做端口映射RTP端口被防火墙阻断导致双方虽然信令通了但媒体流一直无法到达最终触发媒体超时。2. 注册超时导致会话被清理SIP客户端的注册REGISTER是有有效期的。如果客户端注册后由于网络波动、防火墙连接跟踪超时等原因导致注册刷新失败FreeSWITCH可能会在注册过期后清理该会话正在进行的通话也可能因此中断。默认注册有效期通常为3600秒1小时但如果客户端没有按时发送刷新请求或者FreeSWITCH收不到刷新则可能发生此问题。3. 编码Codec不匹配虽然通话已建立但如果双方协商的音频编码存在兼容性问题例如一方仅支持PCMU另一方仅支持opus且FreeSWITCH转码失败可能导致媒体流在短暂尝试后失败触发挂断。这种情况通常伴随着日志中的no codec match或transcoding failed等错误。4. 防火墙或代理的会话超时如果FreeSWITCH与客户端之间经过防火墙、NAT设备或反向代理这些中间设备可能对UDP或TCP会话设置了较短的空闲超时时间如30秒、60秒。当没有数据包通过时设备会清理会话导致后续信令或媒体无法到达。特别是当通话双方都静音时更容易触发。5. FreeSWITCH模块故障或配置错误某些模块如mod_dptools中的record_session、mod_conference如果配置不当可能在通话过程中触发异常导致挂断。这种情况通常会伴随明显的错误日志。四、解决30秒断线问题的具体方案方案一注释或正确配置外部IP这是最直接有效的办法。根据你的网络环境选择如果FreeSWITCH和客户端在同一局域网或测试环境编辑conf/sip_profiles/internal.xml找到以下两行并注释掉!-- param nameext-rtp-ip value$${external_rtp_ip}/ param nameext-sip-ip value$${external_sip_ip}/ --这样FreeSWITCH就不会主动使用外部IP而是直接使用本机监听的IP通常是0.0.0.0或sip-ip配置的地址。如果FreeSWITCH在云服务器或需要正确公网地址在conf/vars.xml中强制指定正确的公网IPX-PRE-PROCESS cmdset dataexternal_rtp_ip123.123.123.123/ X-PRE-PROCESS cmdset dataexternal_sip_ip123.123.123.123/将123.123.123.123替换为你的真实公网IP方案二在SIP Profile中直接指定Contact IP在internal.xml中添加或修改param namesip-ip value192.168.1.100/ !-- 本机监听IP -- param namesip-contact-ip value192.168.1.100/ !-- Contact头域IP -- param nameext-sip-ip value192.168.1.100/ !-- 外部SIP IP -- param nameext-rtp-ip value192.168.1.100/ !-- 外部RTP IP --注意sip-contact-ip的优先级最高可以单独设置。方案三禁用NAT检测在启动FreeSWITCH时添加-nonat参数禁用自动NAT检测FreeSwitchConsole.exe -nonat # Windows FreeSwitchConsole -nonat # Linux/macOS如果使用后台模式同样加上该参数FreeSwitchConsole.exe -nc -nonat验证修改是否生效1重新加载配置在fs_cli中执行reloadxml或重启FreeSWITCH。2检查Sofia状态执行sofia status profile internal查看Contact列显示的IP地址是否已经是你期望的正确地址。3再次发起通话观察是否还会在30秒左右挂断。4抓包确认用Wireshark抓包确认ACK消息能够成功往返。五、其他问题排查补充问题现象可能原因排查方法解决方案通话几秒后无声并挂断编码不匹配查看fs_cli中no codec match日志在internal.xml中添加param nameinbound-codec-prefs valuePCMU,PCMA,opus/等常用编码通话静音一段时间后中断防火墙/ NAT会话超时抓包查看是否有BYE来自防火墙开启NAT keep-aliveparam namenat-options-ping valuetrue/param namesip-force-contact valueNDLB/偶尔断线且日志显示Call is being cleaned up注册刷新失败查看fs_cli中unregister日志确保客户端定期刷新注册调整防火墙UDP超时时间通话建立后立即挂断早期媒体处理失败抓包看是否收到183 Session Progress配置action applicationring_ready/或action applicationbridge/时注意早期媒体处理六、总结30秒自动挂断是SIP通话中最常见的“入门级”问题本质上源于FreeSWITCH收不到ACK确认而ACK迷路又是因为SIP消息中的IP地址不正确。通过正确配置ext-sip-ip或禁用NAT检测可以轻松解决。在实际生产环境中网络环境更为复杂还可能遇到NAT穿透、防火墙策略、编码兼容性等问题。本文提供的排查思路和解决方案可以帮助你系统性地定位问题确保你的呼叫中心稳定运行。如果你在实施过程中遇到其他疑难杂症欢迎在评论区留言我们继续探讨。