PJPROJECT项目中处理已确认状态下的二次INVITE请求问题分析

背景介绍

在基于PJPROJECT（PJSIP）实现的SIP客户端开发过程中，我们遇到了一个关于媒体协商的典型问题。当SIP呼叫处于已确认(CONFIRMED)状态时，如果收到对端发来的二次INVITE请求（即re-INVITE），且该请求包含多个音频媒体流描述时，系统会出现媒体流异常问题。

问题现象

从日志分析可以看出，当呼叫建立后处于CONFIRMED状态时，对端发送了一个包含两个m=audio行的SDP offer：

1. 第一个媒体行使用RTP/AVP协议
2. 第二个媒体行使用安全的RTP/SAVP协议

PJSIP选择了第二个媒体行（索引1）进行协商，但最终该媒体流却被标记为"Local hold"（本地保持）状态，导致音频传输中断。

技术原理

在PJSIP中，pjsua_call_setting结构体控制着呼叫的媒体设置，其中有两个关键参数：

1. aud_cnt：指定允许的音频流数量，默认为1
2. media_dir数组：指定每个媒体流的方向（发送、接收或双向）

当收到包含多个音频媒体描述的re-INVITE时，如果aud_cnt设置为1（默认值），PJSIP只会处理其中一个媒体流，其他媒体流将被忽略或设置为非活动状态。

解决方案

要正确处理这种情况，需要在发起或应答呼叫时正确配置媒体设置：

1. 将aud_cnt设置为期望支持的音频流数量（如2）
2. 为每个媒体流明确设置方向，通常设为PJMEDIA_DIR_ENCODING_DECODING（双向）

示例配置代码：

pjsua_call_setting call_opt;
pjsua_call_setting_default(&call_opt);
call_opt.aud_cnt = 2;  // 支持两个音频流
call_opt.media_dir[0] = PJMEDIA_DIR_ENCODING_DECODING;
call_opt.media_dir[1] = PJMEDIA_DIR_ENCODING_DECODING;

深入分析

这种设计源于SIP协议对媒体协商的灵活性要求。在实际应用中，可能会遇到以下场景：

1. 对端同时提供普通和安全版本的媒体流
2. 对端提供不同编解码的多个媒体流选项
3. 对端尝试更新媒体参数或增加新的媒体流

PJSIP通过pjsua_call_setting结构体提供了细粒度的控制能力，开发者可以根据实际需求配置媒体处理策略。当收到re-INVITE时，PJSIP会基于这些设置决定如何处理每个媒体流。

最佳实践

1. 在开发支持复杂媒体场景的SIP客户端时，应预先评估可能遇到的媒体流数量
2. 对于需要支持多种媒体配置的场景，适当增加aud_cnt值
3. 明确设置每个媒体流的方向，避免使用默认值
4. 在处理re-INVITE时，检查当前媒体设置是否满足需求

总结

PJPROJECT作为成熟的SIP协议栈，提供了灵活的媒体处理机制。理解并正确配置pjsua_call_setting参数是解决此类媒体协商问题的关键。通过合理设置音频流数量和方向，可以确保在各种网络环境和SIP服务器配置下都能正确处理re-INVITE请求，维持稳定的媒体通信。