RTP协议分析

第1章.       RTP 概述

1.1.   RTP 是什么

RTP 全名是 Real-time Transport Protocol （实时传输协议）。它是 IETF 提出的一个标准，对应的 RFC 文档为 RFC3550 （ RFC1889 为其过期版本）。 RFC3550 不仅定义了 RTP ，而且定义了配套的相关协议 RTCP （ Real-time Transport Control Protocol ，即实时传输控制协议）。 RTP 用来为 IP 网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。 RTP 为 Internet 上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由 RTCP 来提供。

1.2.   RTP 的应用环境

RTP 用于在单播或多播网络中传送实时数据。它们典型的应用场合有如下几个。

简单的多播音频会议。语音通信通过一个多播地址和一对端口来实现。一个用于音频数据（ RTP ），另一个用于控制包（ RTCP ）。

音频和视频会议。如果在一次会议中同时使用了音频和视频会议，这两种媒体将分别在不同的 RTP 会话中传送，每一个会话使用不同的传输地址（ IP 地址＋端口）。如果一个用户同时使用了两个会话，则每个会话对应的 RTCP 包都使用规范化名字 CNAME （ Canonical Name ）。与会者可以根据 RTCP 包中的 CNAME 来获取相关联的音频和视频，然后根据 RTCP 包中的计时信息 (Network time protocol) 来实现音频和视频的同步。

翻译器和混合器。翻译器和混合器都是 RTP 级的中继系统。翻译器用在通过 IP 多 播不能直接到达的用户区，例如发送者和接收者之间存在防火墙。当与会者能接收的音频编码格式不一样，比如有一个与会者通过一条低速链路接入到高速会议，这 时就要使用混合器。在进入音频数据格式需要变化的网络前，混合器将来自一个源或多个源的音频包进行重构，并把重构后的多个音频合并，采用另一种音频编码进 行编码后，再转发这个新的 RTP 包。从一个混合器出来的所有数据包要用混合器作为它们的同步源（ SSRC ，见 RTP 的封装 ）来识别，可以通过贡献源列表（ CSRC 表，见 RTP 的封装 ）可以确认谈话者。

1.3.   相关概念

1.3.1.    流媒体

流媒体是指 Internet 上使用流式传输技术的连续时基媒体。当前在 Internet 上传输音频和视频等信息主要有两种方式：下载和流式传输两种方式。

下载情况下，用户需要先下载整个媒体文件到本地，然后才能播放媒体文件。在视频直播等应用场合，由于生成整个媒体文件要等直播结束，也就是用户至少要在直播结束后才能看到直播节目，所以用下载方式不能实现直播。

流式传输是实现流媒体的关键技术。使用流式传输可以边下载边观看流媒体节目。由于 Internet 是基于分组传输的，所以接收端收到的数据包往往有延迟和乱序（流式传输构建在 UDP 上）。要实现流式传输，就是要从降低延迟和恢复数据包时序入手。在发送端，为降低延迟，往往对传输数据进行预处理（降低质量和高效压缩）。在接收端为了恢复时序，采用了接收缓冲；而为了实现媒体的流畅播放，则采用了播放缓冲。

使用接收缓冲，可以将接收到的数据包缓存起来，然后根据数据包的封装信息（如包序号和时戳等），将乱序的包重新排序，最后将重新排序了的数据包放入播放缓冲播放。

为什么需要播放缓冲呢？容易想到，由于网络不可能很理想，并且对数据包排序需要处理时耗，我们得到排序好的数据包的时间间隔是不等的。如果不用播放缓冲，那么播放节目会很卡，这叫时延抖动。相反，使用播放缓冲，在开始播放时，花费几十秒钟先将播放缓冲填满（例如 PPLIVE ），可以有效地消除时延抖动，从而在不太损失实时性的前提下实现流媒体的顺畅播放。

到目前为止 ,Internet  上使用较多的流式视频格式主要有以下三种 :RealNetworks  公司的 RealMedia ,Apple  公司的 QuickTime  以及 Microsoft  公司的 Advanced Streaming Format (ASF)  。

上面在谈接收缓冲时，说到了流媒体数据包的封装信息（包序号和时戳等），这在后面的 RTP 封装中会有体现。另外， RealMedia 这些流式媒体格式只是编解码有不同，但对于 RTP 来说，它们都是待封装传输的流媒体数据而没有什么不同。

第2章.       RTP 详解

2.1.   RTP 的协议层次

2.1.1.    传输层的子层

RTP （实时传输协议），顾名思义它是用来提供实时传输的，因而可以看成是传输层的一个子层。 图  1 给出了流媒体应用中的一个典型的协议体系结构。

图   1   流媒体体系结构

从图中可以看出， RTP 被划分在传输层，它建立在 UDP 上。同 UDP 协议一样，为了实现其实时传输功能， RTP 也有固定的封装形式。 RTP 用来为端到端的实时传输提供时间信息和流同步，但并不保证服务质量。服务质量由 RTCP 来提供。这些特点，在 第 4 章 可以看到。

2.1.2.    应用层的一部分

不少人也把 RTP 归为应用层的一部分，这是从应用开发者的角度来说的。操作系统中的 TCP/IP 等协议栈所提供的是我们最常用的服务，而 RTP 的实现还是要靠开发者自己。因此从开发的角度来说， RTP 的实现和应用层协议的实现没不同，所以可将 RTP 看成应用层协议。

RTP 实现者在发送 RTP 数据时，需先将数据封装成 RTP 包，而在接收到 RTP 数据包，需要将数据从 RTP 包中提取出来。

2.2.   RTP 的封装

一个协议的封装是为了满足协议的功能需求的。从前面提出的功能需求，可以推测出 RTP 封装中应该有同步源和时戳等字段，但更为完整的封装是什么样子呢？请看图 2 。

图  2  RTP 的头部格式

版本号（ V ）： 2 比特，用来标志使用的 RTP 版本。

填充位（ P ）： 1 比特，如果该位置位，则该 RTP 包的尾部就包含附加的填充字节。

扩展位（ X ）： 1 比特，如果该位置位的话， RTP 固定头部后面就跟有一个扩展头部。

CSRC 计数器（ CC ）： 4 比特，含有固定头部后面跟着的 CSRC 的数目。

标记位（ M ）： 1 比特 , 该位的解释由配置文档（ Profile ）来承担 .

载荷类型（ PT ）： 7 比特，标识了 RTP 载荷的类型。

序列号（ SN ）： 16 比特，发送方在每发送完一个 RTP 包后就将该域的值增加 1 ，接收方可以由该域检测包的丢失及恢复包序列。序列号的初始值是随机的。

时间戳： 32 比特，记录了该包中数据的第一个字节的采样时刻。在一次会话开始时，时间戳初始化成一个初始值。即使在没有信号发送时，时间戳的数值也要随时间而不断地增加（时间在流逝嘛）。时间戳是去除抖动和实现同步不可缺少的。

同步源标识符 (SSRC) ： 32 比特，同步源就是指 RTP 包流的来源。在同一个 RTP 会话中不能有两个相同的 SSRC 值。该标识符是随机选取的  RFC1889 推荐了 MD5 随机算法。

贡献源列表（ CSRC List ）： 0 ～ 15 项，每项 32 比特，用来标志对一个 RTP 混合器产生的新包有贡献的所有 RTP 包的源。由混合器将这些有贡献的 SSRC 标识符插入表中。 SSRC 标识符都被列出来，以便接收端能正确指出交谈双方的身份。

2.3.   RTCP 的封装

RTP 需要 RTCP 为其服务质量提供保证，因此下面介绍一下 RTCP 的相关知识。

RTCP 的主要功能是：服务质量的监视与反馈、媒体间的同步，以及多播组中成员的标识。在 RTP 会话期   间，各参与者周期性地传送 RTCP 包。 RTCP 包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，各参与者可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。 RTP 和 RTCP 配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。

从 图  1 可以看到， RTCP 也是用 UDP 来传送的，但 RTCP 封装的仅仅是一些控制信息，因而分组很短，所以可以将多个 RTCP 分组封装在一个 UDP 包中。 RTCP 有如下五种分组类型。

类型	缩写表示	用途
200	SR （ Sender Report ）	发送端报告
201	RR （ Receiver Report ）	接收端报告
202	SDES （ Source Description Items ）	源点描述
203	BYE	结束传输
204	APP	特定应用

表  1  RTCP 的 5 种分组类型

上述五种分组的封装大同小异，下面只讲述 SR 类型，而其它类型请参考 RFC3550 。

发送端报告分组 SR （ Sender Report ）用来使发送端以多播方式向所有接收端报告发送情况。 SR 分组的主要内容有：相应的 RTP 流的 SSRC ， RTP 流中最新产生的 RTP 分组的时间戳和 NTP ， RTP 流包含的分组数， RTP 流包含的字节数。 SR 包的封装如图 3 所示。

图  3  RTCP 头部的格式

版本（ V ）：同 RTP 包头域。

填充（ P ）：同 RTP 包头域。

接收报告计数器（ RC ）： 5 比特，该 SR 包中的接收报告块的数目，可以为零。

包类型（ PT ）： 8 比特， SR 包是 200 。

长度域（ Length ）： 16 比特，其中存放的是该 SR 包以 32 比特为单位的总长度减一。

同步源（ SSRC ）： SR 包发送者的同步源标识符。与对应 RTP 包中的 SSRC 一样。

NTP Timestamp （ Network time protocol ） SR 包发送时的绝对时间值。 NTP 的作用是同步不同的 RTP 媒体流。

RTP Timestamp ：与 NTP 时间戳对应，与 RTP 数据包中的 RTP 时间戳具有相同的单位和随机初始值。

Sender ’ s packet count ：从开始发送包到产生这个 SR 包这段时间里，发送者发送的 RTP 数据包的总数 . SSRC 改变时，这个域清零。

Sender`s octet count ：从开始发送包到产生这个 SR 包这段时间里，发送者发送的净荷数据的总字节数（不包括头部和填充）。发送者改变其 SSRC 时，这个域要清零。

同步源 n 的 SSRC 标识符：该报告块中包含的是从该源接收到的包的统计信息。

丢失率（ Fraction Lost ）：表明从上一个 SR 或 RR 包发出以来从同步源 n(SSRC_n) 来的 RTP 数据包的丢失率。

累计的包丢失数目：从开始接收到 SSRC_n 的包到发送 SR, 从 SSRC_n 传过来的 RTP 数据包的丢失总数。

收到的扩展最大序列号：从 SSRC_n 收到的 RTP 数据包中最大的序列号，

接收抖动（ Interarrival jitter ）： RTP 数据包接受时间的统计方差估计

上次 SR 时间戳（ Last SR,LSR ）：取最近从 SSRC_n 收到的 SR 包中的 NTP 时间戳的中间 32 比特。如果目前还没收到 SR 包，则该域清零。

上次 SR 以来的延时（ Delay since last SR,DLSR ）：上次从 SSRC_n 收到 SR 包到发送本报告的延时。

2.4.   RTP 的会话过程

当应用程序建立一个 RTP 会话时，应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成，有两个端口：一个给 RTP 包，一个给 RTCP 包，使得 RTP/RTCP 数据能够正确发送。 RTP 数据发向偶数的 UDP 端口，而对应的控制信号 RTCP 数据发向相邻的奇数 UDP 端口（偶数的 UDP 端口＋ 1 ），这样就构成一个 UDP 端口对。  RTP 的发送过程如下，接收过程则相反。

1)          RTP 协议从上层接收流媒体信息码流（如 H.263 ），封装成 RTP 数据包； RTCP 从上层接收控制信息，封装成 RTCP 控制包。

2)          RTP 将 RTP  数据包发往 UDP 端口对中偶数端口； RTCP 将 RTCP 控制包发往 UDP 端口对中的接收端口。

第3章.       相关的协议

3.1.   实时流协议 RTSP

实时流协议 RTSP （ Real-Time Streaming Protocol ）是 IETF 提出的协议，对应的 RFC 文档为 RFC2362 。

从 图  1 可以看出， RTSP 是一个应用层协议（ TCP/IP 网络体系中）。它以 C/S 模式工作，它是一个多媒体播放控制协议，主要用来使用户在播放流媒体时可以像操作本地的影碟机一样进行控制，即可以对流媒体进行暂停 / 继续、后退和前进等控制。

3.2.   资源预定协议 RSVP

资源预定协议 RSVP(Resource Reservation Protocol) 是 IETF 提出的协议，对应的 RFC 文档为 RFC2208 。

从 图  1 可以看出， RSVP 工作在 IP 层之上传输层之下，是一个网络控制协议。 RSVP 通过在路由器上预留一定的带宽，能在一定程度上为流媒体的传输提供服务质量。在某些试验性的系统如网络视频会议工具 vic 中就集成了 RSVP 。

第4章.       常见的疑问

4.1.   怎样重组乱序的数据包

可以根据 RTP 包的序列号来排序。

4.2.   怎样获得数据包的时序

可以根据 RTP 包的时间戳来获得数据包的时序。

4.3.   声音和图像怎么同步

根据声音流和图像流的相对时间（即 RTP 包的时间戳），以及它们的绝对时间（即对应的 RTCP 包中的 RTCP ），可以实现声音和图像的同步。

4.4.   接收缓冲和播放缓冲的作用

如 1.3.1 所述，接收缓冲用来排序乱序了的数据包；播放缓冲用来消除播放的抖动，实现等时播放。