PJSIP项目中SRTP/DTLS协议解析错误问题分析与解决方案

问题背景

在PJSIP项目中，当使用Linphone作为客户端与基于PJSIP的应用进行DTLS加密通话时，发现系统会定期出现SRTP解析错误。虽然通话能够建立且音频流看似正常传输，但日志中每隔约1秒就会出现"Failed to unprotect SRTP"的错误提示。

技术分析

错误现象

错误发生在srtp.c文件的srtp_unprotect_mki函数中，该函数返回srtp_err_status_parse_err错误。具体表现为：

• RTP头部信息异常：hdr->cc == 0，hdr->x == 0
• 数据包长度异常：pkt_octet_len == 20
• 加密验证标签长度：tag_len == 10
• MKI大小：mki_size == 0

根本原因

经过深入分析，发现这些错误数据包实际上是STUN协议包（Session Traversal Utilities for NAT），而非真正的SRTP数据包。具体表现为：

1. 数据包版本号异常（version = 0），不符合RTP/RTCP标准（应为2）
2. 数据包长度不足（20字节），无法满足SRTP最小长度要求（至少22字节）
3. 数据包类型（pt = 1）不符合RTCP标准（应≥200）

解决方案

临时解决方案

1. 启用RTCP多路复用：通过配置enable_rtcp_mux参数，可以避免RTCP通道的DTLS协商问题，使Linphone正确识别加密状态。

2. 降级Linphone版本：测试发现Linphone 5.0.15版本无此问题，而5.2.1版本存在该问题，可考虑使用旧版本作为临时解决方案。

长期建议

1. 增强协议识别：在PJSIP中增加对数据包版本的严格检查，过滤掉不符合标准的数据包。

2. 错误处理优化：改进错误日志信息，明确区分不同类型的解析失败，便于问题定位。

3. 兼容性测试：建议PJSIP开发团队与Linphone团队协作，确保DTLS-SRTP实现的互操作性。

技术细节

DTLS-SRTP协商过程

正常的DTLS-SRTP协商应包含两个独立通道：

1. RTP通道协商
2. RTCP通道协商

当RTCP多路复用禁用时，两个通道需要分别完成DTLS握手。问题出现在RTCP通道的握手过程中，Linphone错误地将DTLS握手包识别为RTCP包并丢弃，导致握手失败。

错误数据包示例

典型的错误数据包特征：

Frame: 62 bytes
User Datagram Protocol
    Source Port: 60447
    Destination Port: 4000
Session Traversal Utilities for NAT
    Message Type: Binding Request
    Message Length: 0
    Message Cookie: 2112a442
    Message Transaction ID: 99649ca1be7804e432ef3404

结论

该问题主要是由于Linphone新版本中对DTLS握手包的错误处理导致。虽然不影响基本通话功能，但会影响加密状态的正确显示。建议用户根据实际情况选择上述解决方案，并关注后续版本更新。

对于PJSIP开发团队，可以考虑增强协议兼容性，添加更严格的协议检查机制，以提高与各种SIP客户端的互操作性。