PJSIP项目中Dialog订阅异常问题分析与解决方案

问题背景

在PJSIP项目（版本2.15）中，当Dialog事件订阅被终止后，系统会尝试重新订阅，但出现了订阅类型错误的问题。具体表现为：原本应该重新订阅Dialog事件，却错误地订阅了Presence事件。

问题现象分析

从日志中可以清晰地看到问题发生的全过程：

1. 初始阶段，客户端正确地向服务器发送了Dialog事件订阅请求：

   Event: dialog
   

2. 当订阅刷新时，服务器返回了481错误（Call/Transaction Does Not Exist），表示该事务不存在。

3. 随后系统触发了重新订阅机制，但错误地将订阅类型从Dialog变为了Presence：

   Event: presence
   

技术原理

在PJSIP项目中，事件订阅是通过pjsua_pres.c文件中的相关函数实现的。当订阅被终止后，系统会调用buddy_timer_cb回调函数来处理重新订阅逻辑。

当前实现的问题在于，buddy_timer_cb函数没有区分不同类型的订阅（如Dialog订阅和Presence订阅），导致无论原始订阅类型是什么，都会统一按照Presence订阅处理。

解决方案

正确的实现应该根据buddy的配置决定重新订阅的类型。具体修改方案如下：

1. 在buddy_timer_cb函数中增加订阅类型判断逻辑
2. 根据buddy的presence标志位决定是重新订阅Presence还是Dialog事件

修改后的核心逻辑应如下：

if (buddy->presence == PJ_TRUE) {
    pjsua_buddy_update_pres(buddy->index);
} else {
    pjsua_buddy_update_dlg_event(buddy->index);
}

影响范围

该问题会影响所有使用PJSIP进行Dialog事件订阅的客户端，特别是在以下场景：

• 订阅超时刷新时
• 网络中断恢复后
• 服务器端主动终止订阅时

验证方法

开发者可以通过以下方式验证修复效果：

1. 建立Dialog事件订阅
2. 模拟网络中断或等待订阅超时
3. 观察重新订阅时的Event头部字段
4. 确认重新订阅仍保持为Dialog类型而非变为Presence

总结

PJSIP项目中Dialog订阅的重新订阅机制存在类型判断缺失的问题，导致在订阅恢复时错误地使用了Presence订阅类型。通过增加订阅类型判断逻辑，可以确保系统在重新订阅时保持与原始订阅一致的类型，保证功能的正确性。该问题已在后续版本中得到修复。