1 背景

客户反馈一个问题：我们的设备进行 SRTP 加密时，无法听到 hold 的音乐。

作为音视频的攻坚者，特别喜欢这种挑战，所以就主动请缨申请加入攻坚小组协助分析，完成兼容性开发。

2 SRTP 是什么

SRTP 即安全实时传输协议(Secure Real-time Transport Protocol)，其相关协议可以参考 RFC：https://datatracker.ietf.org/doc/html/rfc3711

SRTPwiki 百科介绍如下：

SRTP 是在实时传输协议(Real-time Transport Protocol)基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。使用身份验证和加密，以最大程度地降低诸如拒绝服务之类的攻击风险。 它由 IETF（Internet 工程任务组）于 2004 年发布，名称为 RFC3711。SRTP 就像 DTLS 是用于 WebRTC 技术的安全协议一样。唯一的 MKI 和 RECOMMENDED 身份验证标签是唯一的 SRTP 定义的不在 RTP 中的字段。

于此同时，RTCP 也有其对应的保护机制，即 SRTCP（Secure Real-time Transport Control Protocol），wiki 百科介绍如下：

由于实时传输协议和实时传输控制协议（Real-time Transport Control Protocol 或 RTCP）有着紧密的联系，安全实时传输协议同样也有一个伴生协议，它被称为安全实时传输控制协议（Secure RTCP 或 SRTCP）；安全实时传输控制协议为实时传输控制协议提供类似的与安全有关的特性，就像安全实时传输协议为实时传输协议提供的那些一样。

对于 RTP 和 RTCP 应用程序来说, SRTP 和 SRTCP 是可选项, 而且即使使用了 SRTP 和 SRTCP 协议, 它们提供的各种功能(例如加密和认证) 也都是可以独立选择使用或者不使用的. 唯一的例外就是当使用 SRTCP 的时候消息认证(message authentication)是必选的.

虽然 SRTP 可以起到安全保护的作用，但是也有其自身的缺点，这里也需要说明一下：

SRTP 是用于给 IP 电话提供安全保障的传统加密协议，但是 SRTP 有一个核心问题，那就是密钥协商。SRTP 的密钥协商和预共享秘密设置起来复杂而繁琐。SRTP 也很容易受到中间人攻击，因此 SRTP 就概念上来说很不错，但是单独实施很困难，也不可靠。

3 尝试分析

依据个人习惯和逐步形成的方法论：

（1）一般碰到这种问题，会先进行本地复现；

（2）如果本地没有办法复现，通过客户提供的 log、抓包进行分析，再进行修改。

不过第二种办法效率就会低一些了，毕竟有些客户会有时差问题，有些不喜欢配合，有些不是技术人员即使有意愿也不好配合。

首先我们明确一下客户产生问题的背景：客户用了两台我们的 51X 设备，然后通过来源 SIP 服务器进行 SIP 语音通话，服务器中转然后将多媒体数据转发给另一端的设备，完成整个 VoIP 通信过程。

第一种场景：两台设备正常语音通话，该场景下是正常的

第二种场景：正常通话过程中使用 hold 功能，该功能也是正常的。

第三种场景：两台设备分别开启并使用 SRTP 加密服务，再次进行通话，语音功能是正常的。

问题描述：客户的问题是当开启 SRTP 加密后，再次使用 hold 功能时，呼叫方无法听到服务器发送的 hold 的音乐 。

3.1 本地复现

1. 第一步，首先我们进行了本地尝试，本地复现的结果：双方通话用 srtp 加密，但是 hold 之后，服务器发送 rtp 包，并且发送内容是大部分 FF 的填充包，这时候听音乐是正常的 hold 音乐，没有问题。而且本地复现也尝试了多台不同的服务器，以便排除服务器的干扰项（正是这个排除项，让我们走了一些弯路）。

3.2 沟通

由于没有办法进行本地复现，所以依靠和客户沟通，并猜测方式进行分析

首先猜测应该是 rtp 包当成 SRTP 包处理了，导致解密后播放，因此发生杂音；

这时和客户进行多次沟通，反复确认，发现猜测的原因并不正确。在沟通过程中依次确认场景，使用方法，使用的服务器，使用的网络等等内容。

虽然交流中没有找到问题点，但是和客户交流程中发现，服务器担当加密的角色，而不是两台话机直接加密的，所以之前的分析都是错误的，踩坑了。

然后客户提供了一份新的抓包，重新站在新的角度看当前问题，这个时候确实与刚才分析结果一致；

服务器发送音乐数据仍然是加密的包，导致播放异常

但是即使是加密的数据，按照协商的密钥正常应该可以正确解密才对呀？？？

3.3 发现问题

按照正常逻辑，以上的流程是没有问题，除非。。。。

好像找到问题了。

之后沿着这个思路重新整理思路，并修改了代码，提供客户验证。今天给了反馈，完美解决还问题。

3.4 原因总结

没错，对音视频了解的同学可能已经猜出来了，因为 hold 时候会再次发送一个 invite 信令，所以客户服务又发送了一个新的密钥，而 hold 的音乐就是用新的密钥进行解密的，而不是用原来的，所以这个地方我们需要判断一下当前密钥是否有发生变更，如果有变更，hold 音乐解密也需要更新一下，否则解密数据异常就无法听到音乐了。

那知道原因之后，剩下的就是对于代码的修改和兼容了，就是保存当前的密钥即可，这部分就不在累述了，有兴趣的同学可以自行尝试。

4 启发

这样问题解决了，有一些启发是可以借鉴的。

（1）我们产品是面向各种各样的客户，客户使用场景也是无法预料的，只能在实战中不断积累经验，完成武器库的升级。

（2）客户提供资料时候，对方可能不是专业人士，或者开发人员，所以提供的场景描述和使用习惯是干扰项，所以在沟通过程中需要有引导性的让客户帮忙达到我们的预期，否则沟通都是无效的。

欢迎点赞、评论、关注、转发；随时探讨，持续输出。