网络流媒体--RTP和RTCP协议

jimte_pro

已于 2022-10-18 16:40:26 修改

阅读量3.1k

点赞数

分类专栏：音视频基础文章标签：实时音视频音视频视频

于 2021-10-18 16:19:23 首次发布

本文链接：https://blog.csdn.net/jisuanji111111/article/details/120828440

版权

音视频基础专栏收录该内容

20 篇文章 22 订阅

订阅专栏

1、RTP和RTCP协议简介

RTP全名是Real-time Transport Protocol（实时传输协议）提供带有实时特性的端对端数据传输服务，RTP 原先的设计是用来满足多参与者的多媒体会议的需要，它没有限定于专门的应用。连续数据的储存，交互分布式仿真，动态标记，以及控制和测量应用程序也可能会适合使用 RTP。RTP协议定义见RFC3550（RFC1889为其过期版本），这份文档定义了包括RTP和RTCP。RTP和RTCP的简单描述如下：

RTP：实时传输协议，用于实时传输数据。
RTCP：实时传输控制协议，RTCP 协议提供实时传输过程中的统计信息，如网络延迟、丢包率等。在传统的实时通讯过程中，RTP 协议占用偶数位的端口，而 RTCP 协议占用随后的奇数位端口。不过如果接收方的 SDP 中包含 rtcp-mux 字段 6，即表明接收方支持 RTP 协议和 RTCP 协议共用同一个端口，即多路复用。在 Chrome 57 版本已经强制开启了 rtcp-mux 。

2、RTP协议介绍

RTP包（RTP packet）包括RTP包头和RTP负载两部分内容：
RTP包头：RTP包头包括一个固定的12字节的包头和可变包头；
RTP 负载(RTP payload)：通过 RTP 传输的包中的数据，例如，音频样本或压缩好的视频数据（RTP也可以用于传输其他类型的实时数据）。
RTP包头如下图所示：在这里插入图片描述

Version ：表示 RTP 协议的版本，目前版本为 2。
P：表示 RT(D)P 包末尾是否有 padding bytes，且 padding bytes 的最后一个 byte 表示 bytes 的数量。Padding 可以被用来填充数据块，比如加密算法可能会用到。
X：表示是否有头部扩展，头部扩展可以用于存储信息，比如视频旋转角度。
CC：表示跟在固定头后面 CSRC 识别符的数目，最多只能有 15 个 CSRC。
M ：表示当前数据是否与应用程序有某种特殊的相关性。比如传输的是一些私有数据，或者数据中的某些标志位具有特殊的作用。比如，在视频流的传输中，可以标识当前帧的结尾。
PT：表示 payload 的数据类型，音视频的默认映射格式可参见 RFC3551。
Sequence number：是递增的序列号，用于标记每一个被发送的 RTP 包，每发送一个RTP包，那么sqn就增加1。接收方可以根据序列号按顺序重新组包，以及识别是否有丢包。序列号的初始值应当是随机的，从而增加明文攻击的难度。
Timestamp ：即时间戳，接收方根据其来回放音视频。时间戳的间隔由传输的数据类型（或具体的应用场景）确定，比如音频通常以 125µs（8kHz）的时钟频率进行采样，而视频则以 90kHz 的时钟频率采样，对于这种周期性采样，那么将使用由采样时钟决定的名义上的采样时刻，而不是读取系统时间，这里时间戳的初始值也是随机选取的，是一种相对时间戳。在视频领域，同一个帧的时间戳是相同的。
SSRC：即同步源标识符。相同的RTP会话中的SSRC是唯一的（类似一个ID），且生成的 SSRC 也需要保持随机。该标识符是随机选取的 RFC1889推荐了MD5随机算法。
CSRC： CSRC 列表识别在此包中负载的所有贡献源，识别符的数目在CC域中给定。根据上述 CC 得知，我们最多可以同时混 15 路音视频流。
Extension header：若 RTP 头中的扩展比特位置 1，则一个长度可变的头扩展部分被加到 RTP 固定头之后。头扩展包含 16 比特的长度（单位是字，即4字节），不包括 4 个字节扩展头(因此零有效值)。RTP 固定头之后只允许有一个头扩展。为允许多个互操作实现独立生成不同的头扩展，或某种特定实现有多种不同的头扩展，扩展项的前 16 比特用以识别标识符或参数。这 16 比特的格式由具体实现的上层协议定义，基本的 RTP 并不定义任何头扩展本身。
下图展示了一个RTP包的原始数据（红圈部分）：

3、RTCP协议介绍

RTP 控制协议(RTCP)向会议中所有成员周期性发送控制包。它使用与数据包相同的传输机制。RTCP 提供以下四个功能：

基本功能是提供数据传输质量的反馈。这是 RTP 作为一种传输协议的主要作用，它与其他协议的流量和拥塞控制相关。反馈可能对自适应编码有直接作用，并且 IP 组播的实验表明它对于从接收端得到反馈信息以诊断传输故障也有决定性作用。
RTCP 为每个 RTP 源传输一个固定的识别符，称为规范名（CNAME）。由于当发生冲突或程序重启时 SSRC 可能改变，接收者要用 CNAME 来跟踪每个成员。接收者还要用 CNAME 来关联一系列相关 RTP 会话中来自同一个成员的多个数据流，例如同步语音和图像。
前两个功能要求所有成员都发送 RTCP 包，因此必须控制速率以使 RTP 成员数可以逐级增长。通过让每个成员向所有成员发送控制包，各个成员都可以独立地观察会议中所有成员的数目。此数目可以用来估计发包速率。
第四个可选的功能是传输最少的会议控制信息，例如在用户接口中显示参与的成员。这最可能在"松散控制"的会议中起作用，在"松散控制"会议里，成员可以不经过资格控制和参数协商而加入或退出会议。 RTCP 作为一个延伸到所有成员的方便通路，必须要支持具体应用所需的所有控制信息通信。
不同的RTCP包类型，可以传送不同的控制信息：
SR：发送者报告，描述作为活跃发送者成员的发送和接收统计数字；
RR：接收者报告，描述非活跃发送者成员的接收统计数字；
SDES：源描述项，其中包括规范名 CNAME。
BYE：表明参与者将结束会话。
APP：应用描述功能。
对齐要求和长度域使 RTCP 包可"堆栈"，
即可以将多个 RTCP 包形成一个复合 RTCP 包，在底层协议(如 UDP)中，通常都是将复合包作为一个包传输的。复合包中的每个 RTCP 单包可以单独处理，而无需考虑包复合的顺序。然而，为了实现某些协议功能，添加以下限制：
接收数据的统计信息(在 SR 或 RR 中)。只要带宽允许应尽可能经常的发送，以达到统计数字的最大分辨率，因此每个周期发送的 RTCP 包必须包含一个报告包。
新的参与者需要尽快接收一个源的规范名以识别数据源并与媒体建立会话。因此，每个包中必须包含源描述项中的规范名。
必须限制首次在复合包中出现的包类型的数目，以增加在第一个字中常数比特的数目，这样可以增加 RTCP 包的有效性，以区分误传的 RTP 包和其他无关的包。因此，所有 RTCP 包必须以复合包的形式发送。复合包中至少有两个单个的 RTCP 包。
加密前缀：当且仅当复合包被加密时，对每个 RTCP 复合包加 32 比特的前缀。
SR 或 RR：复合包中的第一个 RTCP 包必须是一个报告包。即使没有数据发送和接收，此时发送空的 RR 包，或者复合包中其他的唯一包是 BYE 包，也必须发送报告包。
附加的 RR：若被报告的接收统计源数目超过 SR/RR 包中最大允许的 31 个，附加的 RR必须跟在最初的报告包后面。
RTCP复合包格式如下：

下面分别介绍SR、RR、SDES、BYE和APP的包格式：
SR：

RR：

SDES:
SDES 提供了传递与会话成员有关的标识信息的载体，如用户名、邮件、电话等，包括 CNAME、NAME、EMAIL、PHONE、LOC 等源描述项。每个 RTCP 混合分组中必须有 SDES 分组。

BYE：

APP：

从上面5种类型的包可以发现，其实RTCP有一个类似下面格式的固定包头：

其中各自的含义如下表所示：