当前位置：首页 > news >正文

音视频入门基础：RTP专题（7）——RTP协议简介

news 来源：原创 2025/7/4 22:24:01

一、引言

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

二、RTP协议简介

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

三、RTP packet

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

四、RTP header

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

RTP header = RTP Fixed Header + CSRC list + RTP Header Extension（可选）

五、RTP Fixed Header

RTP Fixed Header包含RTP header中必须存在的字段。

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

其中：

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

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

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

CSRC count：占4位，为CSRC的计数。包含RTP Fixed Header之后的CSRC标识符数量：

marker：占1位，是用于应用等级以及其原型（profile）的定义。如果值不为零表示目前的资料有特别的程序解译：

payload type：占7位，确定 RTP 有效负载（payload）的格式，并决定应用程序对其的解释：

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

timestamp：占32位（4字节），为产生payload的时间戳：

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

六、CSRC list

在RTP Fixed Header之后的是CSRC list，其包含0到15项，占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 Fixed Header的特定配置文件扩展处理成本较低，因为它不是条件性的，也不在可变位置。特定有效载荷格式所需的附加信息不应使用这种标头扩展，而应放在数据包的有效载荷部分：

八、参考

《维基百科——实时传输协议》