Kamailio中WebSocket订阅者异常断开导致NOTIFY发送失败问题分析

问题背景

在Kamailio SIP服务器的实际部署中，当多个WebSocket客户端订阅某个用户代理(UA)的状态信息时，如果其中一个订阅者突然断开连接（例如网页刷新），系统在调用pres_refresh_watchers()后无法正常发送NOTIFY消息。这个问题会导致有效的订阅者也无法收到状态更新通知。

问题现象

系统日志中会出现以下关键错误信息：

1. WebSocket的TCP/TLS连接找不到的警告
2. Via头构建失败的错误
3. UAC请求准备失败
4. 最终NOTIFY消息发送失败

根本原因分析

经过深入分析，发现问题的核心机制在于：

1. 连接状态管理缺陷：当WebSocket客户端异常断开时，旧的订阅者信息仍然保留在active_watchers表中，与新建立的连接共存。

2. 错误处理机制不完善：在发送NOTIFY消息时，系统会遍历所有订阅者。当遇到第一个无效连接时，由于Via头构建失败，整个处理流程会直接跳转到错误处理环节（goto done），导致后续有效的订阅者也被跳过。

3. WebSocket清理机制缺失：虽然系统提供了"websocket:closed"路由用于处理连接关闭事件，但缺乏相应的API来清理无效的订阅者信息。

技术影响

这个问题会导致：

• 状态更新通知无法及时送达有效订阅者
• 系统资源被无效连接占用
• 日志中产生大量错误信息，影响问题排查

解决方案

Kamailio开发团队已针对此问题提出了改进方案：

1. 流程优化：修改了NOTIFY发送逻辑，使其不会因为单个订阅者失败而中断整个处理流程。即使某个订阅者发送失败，系统仍会继续尝试发送给其他订阅者。

2. 连接清理建议：虽然当前版本尚未实现自动清理机制，但建议在"websocket:closed"路由中增加订阅者清理逻辑。

最佳实践建议

对于生产环境部署，建议：

1. 版本升级：采用包含此修复的Kamailio版本（5.8.2之后版本）

2. 监控机制：建立对active_watchers表的监控，及时发现并清理无效订阅

3. 异常处理：在客户端实现重连机制，减少异常断开的情况

总结

WebSocket长连接在SIP状态订阅场景中非常常见，但其异常处理需要特别注意。Kamailio通过改进NOTIFY发送逻辑，有效解决了因单个订阅者异常导致整体通知失败的问题，提高了系统的健壮性和可靠性。对于关键业务系统，建议结合自身业务特点进一步完善订阅者管理机制。