PJPROJECT中TLS传输空闲超时问题的分析与解决方案

问题背景

在使用PJPROJECT（PJSIP）进行SIP通信时，开发者可能会遇到一个特定场景下的传输层问题：当账户配置为不进行注册（即仅用于订阅）时，TLS传输连接会在空闲一段时间后被自动销毁，导致后续无法接收NOTIFY消息。

问题现象分析

从日志中可以清晰地看到以下关键时间点：

1. 成功建立TLS传输连接
2. 完成SUBSCRIBE订阅并收到202 Accepted响应
3. 成功接收并处理NOTIFY消息
4. 约33秒后，系统日志显示"Transport is being destroyed due to timeout in idle timer"

技术原理

PJPROJECT的传输层管理机制包含以下重要特性：

1. 空闲超时机制：默认情况下，PJSIP会为每个传输设置一个空闲超时定时器（PJSIP_TRANSPORT_IDLE_TIME），当传输在一段时间内没有活动时，为节省资源会自动关闭。

2. 引用计数机制：通常，注册过程会增加传输的引用计数，防止其在活动期间被销毁。但对于仅用于订阅的场景，这一机制可能不适用。

3. TLS特性：TLS传输相比UDP/TCP需要更多资源维护，且需要双向认证，这使得连接重建成本更高。

解决方案

针对这一问题，开发者可以考虑以下几种解决方案：

方案一：调整传输层参数

1. 延长空闲超时时间：

   pjsip_cfg()->tsx.t1 = 60000;  // 设置传输层T1定时器为60秒
   pjsip_cfg()->tsx.t2 = 4000;   // 设置传输层T2定时器为4秒
   

2. 禁用空闲超时（不推荐用于生产环境）：

   pjsip_cfg()->tsx.disable_tcp_switch = PJ_TRUE;
   

方案二：实现传输保活

1. 启用TLS保活机制：

   pjsip_tls_setting.keep_alive_interval = 30;  // 每30秒发送保活数据
   

2. 应用层保活： 定期发送OPTIONS消息或空的SUBSCRIBE刷新来保持连接活跃。

方案三：优化订阅管理

1. 实现传输引用计数： 在订阅创建时手动增加传输引用：

   pjsip_transport_add_ref(transport);
   

2. 订阅刷新策略： 设置较短的订阅过期时间并定期刷新，确保传输持续活跃。

最佳实践建议

1. 对于长期订阅场景，建议结合使用传输保活和适当延长空闲超时时间。

2. 在移动端或NAT环境下，需要特别注意TCP/TLS连接可能被中间设备超时断开的问题。

3. 生产环境中，建议实现传输状态监控和自动恢复机制，以处理意外断开的情况。

4. 对于资源受限设备，需要在连接保持和资源消耗之间找到平衡点。

总结

PJPROJECT的传输层设计考虑了资源利用效率，这在大多数场景下是合理的。但在特定的仅订阅不注册场景下，特别是使用TLS传输时，开发者需要理解底层机制并适当调整参数或实现补充逻辑，以确保通信的可靠性。通过合理配置和适当的应用层设计，完全可以构建出稳定可靠的SIP订阅系统。