PJSIP项目中DTLS-SRTP协商过程中的线程死锁问题分析

问题背景

在PJSIP多媒体通信库的使用过程中，当处理DTLS-SRTP安全媒体传输时，可能会遇到线程死锁问题。这个问题主要出现在同时处理多个短时SAVP(Secure Audio/Video Profile)呼叫的场景中，特别是在呼叫快速建立后又立即断开的情况下。

问题现象

系统日志显示，当两个线程尝试加入同一个时钟线程(pj_thread_join(clock->thread))时会发生死锁。第一个线程成功加入后，第二个线程无法再加入该线程。这种情况通常发生在以下操作序列中：

1. 事件处理线程开始停止DTLS媒体传输
2. 媒体线程同时完成DTLS-SRTP协商
3. 两个线程都尝试停止并加入时钟线程

技术分析

死锁发生的根本原因

死锁的核心问题在于ssl_flush_wbio函数中的资源管理逻辑。当DTLS媒体停止时，该函数会尝试停止时钟线程，但在释放OpenSSL锁之前就进行了线程加入操作。如果另一个线程同时也在尝试相同的操作，就会导致竞争条件。

具体表现为：

1. 事件处理线程先获取了互斥锁并开始停止时钟线程
2. 媒体线程随后也尝试获取相同的互斥锁来停止时钟线程
3. 由于时钟线程已经被第一个线程停止，第二个线程的加入操作会无限期等待

相关代码路径

1. 事件处理线程路径：

   • dtls_media_stop()被调用
   • 线程尝试加入时钟线程
   • 发送DTLS关闭通知
   • 停止ICE传输

2. 媒体线程路径：

   • 完成DTLS-SRTP协商
   • 释放SSL锁
   • 尝试加入时钟线程处理数据包

解决方案

PJSIP开发团队已经针对此问题提出了修复方案，主要改进点包括：

1. 调整ssl_flush_wbio函数中的锁管理顺序，确保在尝试停止时钟线程前正确释放所有必要的锁
2. 优化线程同步机制，防止多个线程同时尝试停止同一个时钟线程
3. 增强资源清理的健壮性，确保即使在高并发场景下也能正确释放所有资源

影响版本

该问题主要影响PJSIP 2.13版本，使用OpenSSL 3.1.3作为加密后端的环境。虽然问题在2.13版本中最为明显，但在其他版本中也可能出现类似情况，特别是在高负载、短时呼叫频繁的场景下。

最佳实践建议

对于使用PJSIP开发实时通信应用的开发者，建议：

1. 及时应用官方提供的补丁
2. 在高并发场景下增加适当的延迟处理机制
3. 实现完善的资源监控，特别是线程和锁的状态监控
4. 考虑使用连接池技术管理短时呼叫，减少资源竞争

总结

PJSIP中的DTLS-SRTP线程死锁问题展示了多媒体通信系统中资源管理的复杂性。通过理解问题的根本原因和解决方案，开发者可以更好地构建稳定可靠的实时通信系统。这类问题的解决也体现了开源社区通过协作不断完善软件质量的价值。