RTP 与 RTCP 协议简述

随着多媒体网络应用的发展，针对网络多媒体的通用、实时交互式应用的传输协议——实时传输协议（Real-Transport Protocol，RTP）与实时传输控制协议（Real-Transport Control Protocol，RTCP）应运而生。

一、RTP 协议特点

1. RTP 协议运行在 UDP 协议之上

RTP 通常运行在用户空间，它位于 UDP 协议之上。从工作流程来看，由于 RTP 运行在用户空间，并且与应用层协议链接，因此它看上去更像应用层协议。另一方面，它又是一个与具体应用无关的通用协议，它将应用层的多媒体数据封装后，再利用 UDP、IP 及低层协议实现多媒体数据的传输。

当应用程序开始一个 RTP 会话时，将使用两个端口：一个用于 RTP，另一个用于 RTCP。同时需要注意的是，与其他应用层协议都是分配一个熟知端口号不同，RTP 会话需要在临时端口号（1025～65 535 之间）中选择一个未使用的偶数 UDP 端口号。例如，RTP 选择的端口号为 1210，那么属于同一会话的 RTCP 就选择加 1 的奇数端口号，即 1211。因此，从 TCP/IP 协议体系的角度来看，它应该位于应用层之下、UDP 之上，是一种专用于有实时性要求的网络应用的传输层协议。

2. RTP 协议提供端–端的传输服务

多媒体数据由音频、视频、文本与其他可能的数据流组成。这些数据流被送到 RTP 库。RTP 库软件按音频、视频、文本数据流之间的关系，将它们压缩编码后复用到 RTP 报文（RFC 3550 使用的是“RTP Packet”），再加上套接字（Socket），通过 UDP 软件封装成一个 UDP 报文。目的主机将接收到的 RTP 报文封装的多媒体数据传送到应用层。应用层的播放器负责播放多媒体数据。

UDP 报文封装在普通的 IP 分组中传输，传输路径中的所有路由器不会对该分组提供任何特殊的服务。RTP 不强调需要资源预留协议（RSVP）的支持，RTP 为应用层的实时应用提供端–端的传输服务，不提供任何 QoS 保证。

二、RTP 协议的结构

RTP 报头由 12 字节的固定长度报头与可选的分信源标识符组成。长度为 12 字节的固定报头包括以下字段。

• 版本

版本字段长度为 2 比特，目前使用的是版本 2。

• 填充

填充（P）字段的长度为 1 比特。在某些特殊情况下，需要对应用层数据进行加密，这就要求每个数据块有确定的长度，必须是 4 字节的整数倍。在有填充字节的情况下，填充位 P=1。在数据部分的最后一个字节值用来表示填充的字节数。

• 扩展

扩展（X）字段的长度为 1 比特。X=1 表示 RTP 报头之后有扩展报头。实际上，RTP 很少使用扩展报头。

• 参与源数量

参与源（CSRC Counter，CC）字段的长度为 4 比特。CC 设置为最大值时，表示一次会话最多有 15 个参与源。

• 标记

标记（M）字段的长度为 1 比特。M=1 表示该 RTP 报文有特殊意义。例如，应用程序可以用该位表示视频流的每帧开始，也可以表示视频流传输结束。

• 有效载荷类型

有效载荷类型字段的长度为 8 比特。

• 序号

序号字段的长度为 16 比特，用来给 RTP 报文编号。在一次 RTP 会话中，第一个 RTP 报文的编号是随机产生的，后续的每个报文序号加 1。接收端可以根据序号来判断 RTP 报文是否丢失或乱序。

• 时间戳

时间戳字段的长度为 32 比特，用于指出 RTP 报文之间的时间关系。在一次会话开始时，第一个 RTP 报文的时间戳初始值是随机产生的。RTP 没有规定时间戳的粒度（Granularity），它取决于有效载荷类型。

• 同步源标识符

同步源标识符（Synchronous SouRCe identifier，SSRC）字段的长度为 32 比特，用来表示 RTP 流的来源。如果一次会话中只有一个源端，那么 SSRC 值就表示这个源端。

• 参与源标识符

参与源标识符（Contributing SouRCe identifier，CCRC）字段的长度为 32 比特，用来标识参与源的源端。从长度为 4 比特的 CC 字段可以知道，一次会话的参与源数量最多为 15 个。

三、RTCP 协议与 RTP 协议的关系

源端利用 RTCP 报文同步一次会话中的不同媒体流。例如，在一次视频会议应用中，每一个源端都产生两个独立的媒体流，一个用于传输视频，一个用于传输音频。这时，需要将这些 RTP 报文头中的时间戳与视频、音频采样时钟建立关联。由于源端发出的 RTCP 报文包含与它关联的 RTP 报文流的时间戳与真实时间，因此接收端可以通过 RTCP 报文提供的关联来同步视频与音频的播放。

• 实际上，RFC 3550 文档定义了两部分的内容。一部分是用于传输多媒体数据流的协议（RTP），另一部分是实时传输控制协议（RTCP）。

• RTCP 与 RTP 协议是相互配合的关系。RTP 与 RTCP 可以同时在一个多媒体应用中使用，都封装在 UDP 报文中传输。

• RTP 报文的有效载荷中封装音频、视频数据流，而 RTCP 报文不封装任何音频、视频数据流。

四、RTCP 报文类型

RTCP 报头中有一个长度为 8 比特的报文类型字段，不同报文类型字段值表示不同类型的 RTCP 报文。例如，报文类型字段值为 200，表示发送端报告的 RTCP 报文。

• 发送端报告（SR）

发送端与接收端的一次会话包含很多 RTP 流。发送端每次发送一个 RTP 流时，就会发送一个 SR 报文。

绝对时间对于多媒体传输是非常重要的。在传输一个视频信号时，实际上需要同时传输音频流与图像流。这样，在播放一个视频节目时，通过 RTP 报文的时间戳与绝对时间可实现音频流与图像流的同步。

• 接收端报告（RR）

接收端每次接收一个 RTP 流时，就会发送一个 RR 报文。接收端可以使用 RTCP 报文，周期性地向发送端反馈与 QoS 相关数据。发送端可以根据 RTCP 报文反馈的信息，了解网络当前的延时与延时抖动、丢包率，以便决定数据传输速率。如果网络通信状态良好，发送端可以动态改变编码算法，以提高多媒体信息的播放质量。

• 发送端描述报告（SDES）

发送端周期性地通过多播方式发送 SDES 报文，给出了会话参与者的规范名（Canonical Name）。规范名是会话参与者电子邮件地址的字符串。

• 结束（BYE）

结束（BYE）报文用来关闭一个数据流。在视频会议应用中，一个发送端通过结束报文宣布退出这次会议。

• 特定应用（APP）

特定应用（APP）报文用于应用程序定义一种新的 RTP 报文类型。

在通常情况下，RTCP 报文占用的网络带宽不应超过 5%。如果一个发送端正在以 2Mbps 速率发送视频流，那么该节点的 RTCP 报文占用带宽必须低于 100kbps。在具体的实现中，通常将这个带宽的 75%（75kbps）分配给接收端，剩余 25%（25kbps）留给接收端。如果在多播情况下有 n 个接收端，那么每个接收端用于发送 RTCP 报文的带宽应控制在 75/n（kbps）之内。