假设一条客服热线能正常接通，双向语音也没问题，但长一点的通话总在相近时长断开。短呼叫测试全部通过，运营却不断反馈掉话。这时除了看媒体，还应检查 SIP 会话刷新有没有完成。
这里讨论 FreeSWITCH 经话机、SBC 或运营商中继建立的 SIP 通话，适合负责联调和运维的同事。
先确认这通电话有没有协商刷新
SIP 会话定时器用于确认会话仍然有效。RFC 4028 定义了通过 re-INVITE 或 UPDATE 刷新会话的机制。抓包时关注 Session-Expires 中的间隔和 refresher 参数，并结合该次请求的方向判断由谁负责刷新。
不要只看发出的初始请求，要核对成功响应中实际协商的结果。Min-SE 表示允许的最小间隔，不是通话到这个秒数就必须挂断。也不要把注册有效期当作正在进行的通话时长限制。
在已经启用会话定时器的流程里，刷新请求发出并不代表刷新成功，还要看到对应的成功响应。检查时间线时，应从最近一次成功刷新继续往后看，而不是始终只从接听时刻计算。
正常挂断记录也可能藏着刷新失败
Cisco 的故障说明指出，Meeting Server 自己因刷新失败结束呼叫时，会记录对应超时原因；若对端先发来 BYE，本端可能只看到正常的远端挂断。这个例子提醒我们：最终挂断标签不足以解释之前发生了什么。
可以把同一通话在 FreeSWITCH 与 SBC 两侧的信令对起来。负责刷新的设备有没有发请求，对端有没有收到，响应有没有返回？如果某一侧看到请求，另一侧没看到，继续核对中间设备的路由、过滤与连接状态，而不是直接修改所有超时参数。
若收到错误响应，保留状态码和后续处理过程。一次请求被拒绝、随后正确重试，与一直没有成功响应，处理方向不同。只截取掉线前的 BYE，往往会漏掉更早的异常。
配置要与线上消息一起看
FreeSWITCH 当前 Sofia 文档列出了 enable-timer、session-timeout 和 minimum-session-expires。它们分别涉及是否启用、会话间隔与可接受的最小间隔。文档是核对入口，不能说明你正在运行的版本和 Profile 已经采用这些值；应结合版本、实际加载配置和抓到的消息确认。
国内项目涉及多个供应商时，建议共同确认刷新由谁发起、经过哪些节点、失败怎样记录。不要为了暂时不掉话就全局关闭刷新，也不要把加长间隔当作已经解决问题。任何变更都应保留原配置，先在测试环境验证，再安排可恢复的上线步骤。
可以在一个非生产项目上试点，检查三点：正常长通话是否跨过多个协商刷新周期；保持和恢复通话后刷新是否继续成功；模拟刷新失败时，双方日志能否解释终止原因。测试时长按实际协商值安排。