音视频入门基础：RTP专题（7）—

一、引言

本文对RTP协议进行简介。在简介之前，请各位先下载RTP的官方文档《RFC 3550》和《RFC 3551》。《RFC 3550》总共有89页，《RFC 3551》总共有44页。本文下面所说的“页数”是指在pdf阅读器中显示的页数：

二、RTP协议简介

根据《RFC 3550》第5页，实时传输协议（Real-time Transport Protocol或简写RTP）为交互式音频和视频等具有实时特性的数据提供端到端的传输服务。这些服务包括有效载荷类型识别、序列编号、时间戳和传输监控。应用程序通常在 UDP 的基础上运行 RTP，以利用其多路复用和校验服务；这两个协议都贡献了部分传输协议功能。不过、RTP 也可与其他合适的底层网络或传输协议一起使用。如果底层网络提供多播分发功能，RTP 支持将数据传输到多个目的地。
请注意，RTP 本身并不提供任何机制来确保及时传输或提供其他服务质量保证，而是依靠底层服务来实现。它既不保证传送或防止无序传送，也不假定底层网络是可靠的并能按顺序传送数据包。RTP 中包含的序列号允许接收方重建发送方的数据包序列，但序列号也可用于确定数据包的正确位置，例如在视频解码中，不一定要按顺序解码数据包。虽然 RTP 主要是为了满足多方参与的多媒体会议的需求，但它并不局限于这一特定应用，连续数据存储、交互式分布式仿真、活动徽章以及控制和测量应用也可能适用 RTP：

三、Mixers和Translators

根据《RFC 3550》第7到第8页，到目前为止，我们假定所有网站都希望以相同的格式接收媒体数据。然而，这并不总是合适的。考虑这样一种情况：一个地区的与会者通过低速链路与大多数享有高速网络接入的与会者连接。与其强迫每个人都使用带宽较低、质量较差的音频编码，不如在低带宽区域附近放置一个称为混音器（Mixer）的RTP级中继器。混音器会重新同步传入的音频数据包，以重建发送方生成的20毫秒恒定间隔，这些数据包可以单播给单个接收者，也可以通过不同地址组播给多个接收者。RTP header包含一种混音器识别混合数据包来源的方法，以便在接收器上提供正确的通话者指示。

音频会议中的某些预期参与者可能使用高带宽链路连接，但可能无法通过 IP 组播直接到达。例如，他们可能位于应用级防火墙之后，无法通过任何 IP 数据包。在这种情况下，可以使用另一种称为翻译器（Translator）的 RTP 级中继。在防火墙两侧各安装一个翻译器，外部翻译器通过安全连接将接收到的所有组播数据包传送到防火墙内部的翻译器。防火墙内的翻译器将这些数据包作为组播数据包再次发送到仅限于网站内部网络的组播组。
混合器和翻译器的设计目的多种多样。例如，视频混合器可将独立视频流中的单个人物图像进行缩放，然后合成到一个视频流中，以模拟群体场景。其他转换的例子包括将一组只讲 IP/UDP 的主机连接到一组只懂 ST-II 的主机上，或对来自单个信号源的视频流进行逐包编码转换，而无需重新同步或混合：

根据《RFC 3550》第10页，Translator（翻译器，转换器）是转发 RTP 数据包并保持其synchronization source identifier（同步源标识符）不变的中间系统。Translator的例子包括不混合转换编码的设备、从组播到单播的复制器以及防火墙中的应用级过滤器：

Mixer（混音器，混合器）为从一个或多个来源接收 RTP 数据包的中间系统，可能会更改数据格式，以某种方式合并数据包，然后转发新的 RTP 数据包。由于多个输入源之间的定时一般不会同步，因此Mixer会对数据流进行定时调整，并为合并后的数据流生成自己的定时。因此，从Mixer发出的所有数据包都将被识别为以Mixer为同步源（synchronization source）：

四、RTP packet

根据《RFC 3550》第8页，RTP packet（RTP报文）是由固定的RTP头（RTP Fixed Header）、可能为空的贡献源（contributing sources，简称CSRC）列表和有效载荷数据（payload）组成的数据包。某些底层协议可能要求定义 RTP 数据包的封装。通常情况下，底层协议的一个数据包包含一个 RTP 数据包，但如果封装方法允许，也可能包含多个 RTP 数据包：

一个RTP packet = RTP header + RTP layload + 填充字节（可选）

五、RTP header

根据《RFC 3550》第12页，RTP header包含下图所示部分：

RTP header = RTP Fixed Header + contributing source（CSRC） identifiers + RTP Header Extension（可选）

六、RTP Fixed Header

RTP Fixed Header包含RTP header中必须存在的字段。RTP Fixed Header固定占12字节。

RTP Fixed Header = version + padding + extension + CSRC count + marker + payload type + sequence number + timestamp + SSRC

其中：

version：占2位，该字段标识 RTP 的版本，本规范（《RFC 3550》）定义的版本为'2'（目前都用2版本）。值'1'用于RTP的第一个草案版本，值'0'用于最初在 “vat ”音频工具中实施的协议）：

padding：占1位，为填充位，表示用于RTP packet结束点的预留空间。如果设置了填充位（padding的值为1），该RTP packet的末尾就会包含一个或多个额外的填充八位位组（此时RTP packet末端会附加填充字节），这些八位位组不属于有效载荷的一部分。填充的最后一个八位位组包含应忽略多少个填充八位位组（包括其本身）的计数。某些具有固定块大小的加密算法或在下层协议数据单元中携带多个RTP packet时可能需要使用填充：

extension：占1位，为扩展位，如果扩展位被设置（extension的值为1），RTP Fixed Header后（CSRC之后）必须有一个扩展头（ RTP Header Extension）：

CSRC count：占4位，为CSRC的计数。指示RTP Fixed Header之后的CSRC标识符数量，即contributing source（CSRC） identifiers的数量：

marker：占1位，该marker（标记）的解释由配置文件（profile）定义。其目的是允许在数据包流中标记帧边界等重要事件。配置文件可定义额外的标记位，或通过改变有效载荷类型字段中的位数来指定没有标记位：

根据《RFC 3551》第30页，大多数视频编码规定，在视频帧的最后一个数据包中，RTP header的marker位应设置为 1，否则设置为0。因此，无需等待具有不同时间戳的后续数据包来检测是否应显示新帧（也就是说：对于视频，通常的规则是marker位的值为1时表示视频帧的最后一个数据包）：

根据《RFC 3551》第37页，音频静默后第一个数据包上设置marker位的要求级别从 “是 ”改为 “应该是”，并说明只有在故意不发送数据包时才设置标记位（也就是说：对于音频而言，常用的规则是marker位值为1时表示通话开始，即 “数据包未连续传输的静默期后的第一个数据包”）：

payload type：占7位，为PT值（有效载荷类型），根据该值确定 RTP 有效负载（payload）的格式，并决定应用程序对其的解释：

《RFC 3551》规定了一套初始的 “有效载荷类型”，本列表保留并扩展了该列表：

有效载荷标识符 96-127 用于会话期间动态定义的有效载荷。建议动态分配端口号，但端口号 5004 和 5005 已被注册，以便在不需要动态分配端口时使用配置文件。除了上表中明确指定PT值的负载类型，还有些负载类型由于诞生的较晚，没有具体的PT值，只能使用动态（dynamic）PT值，即96到127，比如普遍指定H264的PT值为96。

根据《RFC 6184》第11页（该文档描述了：RTP Payload Format for H.264 Video），对于H.264，必须通过所使用的配置文件或以动态方式分配有效载荷类型：

sequence number：占16位（2字节），为序列号。每发送一个 RTP数据包，序列号的值就会递增加1，接收方可利用序列号检测数据包丢失并恢复数据包序列。序列号的初始值应是随机的（不可预测的），这样即使信源本身没有加密，也能增加已知纯文本加密攻击的难度，因为数据包可能会流经translator （翻译器）进行加密：

timestamp：占32位（4字节），为产生payload的时间戳。时间戳反映RTP数据包中第一个字节的采样瞬间。采样瞬时必须来自一个在时间上单调线性递增的时钟，以便进行同步和抖动计算。与序列号一样，时间戳的初始值也应该是随机的：

synchronization source (SSRC) identifier：占32位（4字节），SSRC字段用于标识同步源（synchronization source，即RTP数据流的起源）。该标识符应随机选择，目的是使同一RTP 会话中没有两个同步源具有相同的SSRC标识符（在一个RTP会话中，每个数据流的SSRC都不同）。虽然多个信号源选择相同标识符的概率很低，但所有RTP实现都必须做好检测和解决碰撞的准备。如果源更改了源传输地址，它也必须选择一个新的SSRC标识符，以避免被解释为循环源：

七、CSRC list

在RTP Fixed Header之后的是CSRC list（CSRC列表），其包含0到15项contributing source（CSRC） identifiers，，每项占32位（4字节）。CSRC列表标识了该数据包所含有效载荷的贡献源（contributing sources）。标识符的数量由RTP Fixed Header的CSRC count（CC）字段给出。如果贡献源超过 15 个，则只能识别 15 个。CSRC 标识符由混合器（mixers）插入，使用贡献源的 SSRC 标识符。例如，在音频数据包中，会列出混合在一起创建数据包的所有信源的 SSRC 标识符，以便在接收机上正确显示通话者：

八、RTP Header Extension

根据《RFC 3550》第16页，RTP中提供了一种扩展机制，允许各实施机构尝试与有效载荷格式无关的新功能，这些功能需要在 RTP 数据包报头中携带额外的信息。设计该机制的目的是使其他未进行扩展的互操作实现可以忽略报头扩展。比如通过该RTP扩展，可以添加前向纠错码（FEC），发送冗余数据。使接收端在一定比例丢包的情况下可以恢复原始数据，提高传输的稳健性。
请注意，该报头扩展仅用于有限的用途。例如，RTP Fixed Header的特定配置文件扩展处理成本较低，因为它不是条件性的，也不在可变位置。特定有效载荷格式所需的附加信息不应使用这种标头扩展，而应放在数据包的有效载荷部分：