Asterisk中PJSIP会话模块文件描述符轮询问题分析

问题概述

在Asterisk开源PBX系统中，当使用PJSIP协议栈处理多媒体会话时，存在一个可能导致CPU使用率飙升到100%的核心缺陷。该问题主要发生在SDP(会话描述协议)重新协商过程中，当多媒体流被移除时，系统仍会继续轮询已经不存在的文件描述符。

技术背景

Asterisk通过res_pjsip_session模块处理SIP会话，其中SDP协商是关键环节。SDP定义了会话中的媒体流特性，包括音频、视频等。在会话建立和修改过程中，双方会进行SDP协商以确定最终的媒体流配置。

问题根源

当初始SDP协商建立多个媒体流后，若后续协商中移除了某个流，系统会出现以下异常情况：

1. 在handle_negotiated_sdp函数中，系统会遍历pending_media_state中的read_callbacks
2. 这些回调是从active_media_state复制而来
3. 即使流已被移除，active_media_state仍保留着对应文件描述符的回调
4. 导致系统持续轮询无效的文件描述符

问题表现

该缺陷会导致以下明显症状：

• ast_waitfor_nandfds:ast_poll()函数快速返回
• bridge_channel_wait()函数进入高速循环
• 单个线程CPU使用率达到100%
• 系统整体性能显著下降

解决方案

修复方案的核心思路是在处理SDP会话媒体时重置read_callbacks：

1. 在handle_negotiated_sdp_session_media函数中
2. 在SDP处理器添加回调之前
3. 先清空现有的read_callbacks

这样可确保不会保留已被移除流的文件描述符回调，从而避免无效轮询。

影响范围

该问题影响多个Asterisk版本：

• 18.x系列
• 20.x系列
• 21.x系列
• master分支

主要出现在Linux操作系统环境中。

技术启示

这个问题揭示了多媒体会话处理中资源管理的复杂性，特别是在动态流变更场景下。开发者在实现类似功能时应注意：

1. 状态同步的完整性
2. 资源释放的及时性
3. 回调管理的精确性
4. 异常情况的健壮性处理

通过这个案例，我们可以更好地理解实时通信系统中状态管理和资源回收的重要性，特别是在处理动态变化的媒体会话时。