当需要为 RTP 和 RTCP 报文提供加密服务时，所有传输的内容都会在下层报文那里进行加密。对于 RTCP 来说，需要一个 32-bit 的随机数作为前缀。而 RTP 报文不需要前缀，取而代之的是随机序列号和时间戳偏移。因为随机部分很少，所以可以说这是一个非常弱的初始向量。此外，SSRC 也可被破解者修改，这是这个加密方案的另一个薄弱的环节。
对于 RTCP 来说，可能会将一个复合包分成两批，第一批加密，后一批明文发送。例如，SDES 部分的信息可能加密，而接收报告部分不加密就发送出去，因为只有这样那些第三方监控器才能在不知道密钥的情况下统计网络状况。如下图所示，SDES 信息必须跟在一个空的 RR 后，并且要有一个随机前缀。
RTP 协议使用的 Data Encryption Standard (DES) 算法，使用 cipher block chaining (CBC) 模式，这需要数据填充到 64-bit 对齐。密码算法使用零作为初始向量，因为 RTCP 报文中已经有一个随机前缀了。
RTP 之所以选择这个默认协议是因为它用起来很容易，但是因为 DES 太容易破解了。所以推荐预设中使用更健壮的加密算法来替换这个默认方案，例如 Triple-DES。这些算法普遍需要一个随机初始化块，RTCP 使用了 32-bit 的随机数作为前缀，RTP 使用了时间戳和序列号的随机偏移，可是相邻的 RTP 报文之间的随机性就很差。需要注意的是，无论是 RTCP 还是 RTP，它们的随机性都有限。加密型更好的应用，需要考虑更多的保密措施。例如 SRTP 配置文件，就基于 AES 来加密，它的加密方案就更完备，选择这个预设来使用 RTP 就挺不错的。
前面提到过也可以用 IP 级的加密方案或者 RTP 级的加密，一些预设可能会定义别的 payload 类型来加密。这种方案，可能只加密 payload 部分而头部分使用明文，因为只有 payload 部分才是应用真正需要的内容。这可能对硬件设备来说非常有用，它既处理解密过程，又处理解码过程。
身份认证和消息完整性RTP 协议这一层没有身份认证和消息完整性服务，因为有些上层服务可能没有认证就能使用。而消息完整性服务依赖下层协议来实现。
RTP 下的网络层和传输层协议RTP 需要下层协议提供多路复用机制。对于 UDP 这类应用，推荐 RTP 应该使用一个偶数端口传输数据，和它相关的 RTCP 流应该是用高一位的奇数端口。在单播模式下，每个参与者都需要一对端口来传输 RTP 和 RTCP 报文。两个参与者可能使用相同的端口。绝对不能以接收到的报文网络地址直接作为目标地址发送报文。
建议层编码模式是，使用相邻的端口，因此对于层 N 来说，数据端口是 P+2N，控制端口是 P+2N+1。对于 IP 组播来说，可能不会得到相邻的组播地址。
RTP 数据报文没有描述报文长度的信息。所以 RTP 报文依赖下层协议提供长度标识。所以一个 RTP 报文的最大长度由下层协议限制。
如果 RTP 报文使用的下层协议是流传输协议的话，必须定义一套数据帧分割机制。
参考[1] rfc3550
阅读作者的更多文章，关注作者个人公众号：贝贝猫技术分享
作者的个人博客：https://www.beikejiedeliulangmao.top/
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。