PJSIP项目中SDP协商不完整导致BYE消息未发送的问题分析

问题背景

在PJSIP项目中，当处理SIP呼叫时，如果遇到没有携带SDP信息的INVITE请求，并且在后续ACK消息中同样没有完成SDP协商的情况下，系统会出现BYE消息未能正确发送的问题。这种情况会导致呼叫状态异常，最终可能耗尽系统资源。

问题现象

当满足以下条件时会出现该问题：

1. 收到不包含SDP信息的INVITE请求
2. 系统返回200 OK响应（包含SDP信息）
3. 对方回复的ACK消息中仍然不包含SDP信息

此时系统会检测到SDP协商未完成，尝试发送BYE消息结束会话，但由于状态机处理顺序问题，BYE消息会被延迟发送，最终导致呼叫状态卡住。

技术分析

问题的核心在于inv_set_state函数中的状态处理逻辑。当呼叫状态变为CONFIRMED时，系统会检查SDP协商是否完成。如果未完成，则会尝试发送BYE消息结束会话。

但当前实现存在以下问题：

1. 状态检查在状态设置之前进行
2. 当检测到SDP未完成时直接返回，跳过了状态设置
3. BYE消息发送依赖于状态更新，形成死锁

解决方案

正确的处理顺序应该是：

1. 先更新状态为CONFIRMED
2. 然后检查SDP协商状态
3. 如果SDP未完成，再发送BYE消息

这种顺序可以确保状态机正确推进，避免BYE消息被错误地延迟。

影响范围

该问题会影响所有使用PJSIP处理SIP呼叫的场景，特别是：

1. 与某些特定SIP设备对接时
2. 处理不带SDP的INVITE请求时
3. 在早期版本的PJSIP中（如2.9版本）

最佳实践建议

1. 建议升级到最新版本的PJSIP，该问题在新版本中已修复
2. 在无法升级的情况下，可以考虑修改inv_set_state函数的处理顺序
3. 实现额外的超时机制，确保异常呼叫能够被及时清理
4. 在应用层增加对无SDP呼叫的特殊处理逻辑

总结

SDP协商是SIP呼叫建立过程中的关键环节。PJSIP在处理无SDP呼叫时出现的BYE消息未发送问题，揭示了状态机设计中的潜在缺陷。理解这一问题有助于开发者更好地处理SIP协议中的边缘情况，确保系统的稳定性和可靠性。