RTP协议分析

整理记录****

版本	时间	内容	整理人
V1.0	2008-03-31	RTP协议分析初稿	彭令鹏

RTP 协议分析

第1章. RTP概述

1.1. RTP是什么

RTP的全名为Real-time Transport Protocol（实时传输协议）。它是由IETF提出的标准化协议，并以RFC3550为其主要参考文档（其中1889号已过时）。RFC3550仅明确了该协议的基本框架，并进一步补充明确了配套的相关控制协议RTCP（Real-time Transport Control Protocol）。该协议能够为互联网上的语音、图像和传真等多种实时性要求的数据提供端到端的实时传输服务。尽管RTP提供了时间戳信息并实现了数据同步功能，在服务保障方面则依赖于另一个相关的控制协议RTCP。

1.2. RTP的应用环境

RTP主要用于实现单一或者多种网络传输模式下的实时性数据传输功能；其典型应用场景主要包括以下几个方面：首先是视频会议系统；其次是在线教育平台；最后是虚拟现实应用等场景。

基础型多播音频会议。该语音通信系统采用一个多播地址与一对端口进行数据传输。其中一部分负责传输音频数据（RTP），另一部分负责传输控制包（RTCP）。

基础型多播音频会议。该语音通信系统采用一个多播地址与一对端口进行数据传输。其中一部分负责传输音频数据（RTP），另一部分负责传输控制包（RTCP）。

在一次集会上若同时采用了音频与视频的会面形式则它们各自会在独立的RTP会话中采用独特的传输地址（IP地址＋端口）。对于同一个参与者而言若同时参与了两个RTP会话那么每个对应位的信息将被规范化命名以CNAME（Canonical Name）的形式标识。通过RTCP包中的CNAME字段参与者能够定位到相应的音频流与视频流而借助这些计时信息（Network Time Protocol）则能够确保不同媒体流之间的同步播放。

译码器与合流器均属于RTP级的中继系统。译码器应用于那些通过IP广播无法直接到达的目标区域（例如发送端与接收端之间存在防火墙）。当参与者所接受的音频编码格式不一致时（比如有一个参与者通过一条低速链路接入到高速会议），就会采用合流器进行处理。所有经合流处理后的数据包需以该合流设备作为同步源（SSRC）进行识别（见RTP封装中的SSRC定义）。这些经过重构的数据包随后将被合并并采用另一种音频编码方式进行编码后转发新的RTP报文。所有输出的数据包都需要标明其同步源信息（SSRC），可以通过贡献源列表（CSRC表）来进行确认

1.3. 相关概念

1.3.1. 流媒体

流媒体即为基于持续性实时传输技术的连续时间基媒介。当前在互联网上主要采用分段下载与持续性实时传输相结合的方式传递音频与视频等信息。

在获取完整内容方面存在限制的情况下，在线用户必须先从外部源获取并下载整个媒体文件到本地设备中存储空间才能完成其观看。然而，在视频流媒体服务中，在线用户无法实时接收完整内容的原因在于，在线生成完整内容的过程必须等待直到流媒体服务的实际提供者完成数据传输任务才可实现。

流式传输被视为构建现代流媒体系统的核心技术。
通过采用分组化传输机制，在接收端观众即可实时收看节目内容。
由于Internet是基于分组传输的网络架构设计而成，
因此，在接收端的数据包可能会出现延迟或顺序混乱（因为流式传输依赖于UDP协议）。
要确保数据流畅播放，
主要关注如何降低延迟并恢复数据包的时间顺序。
在发送端进行优化，
为减少延迟，
常常会对原始数据进行预处理以提高播放质量（如压缩编码）。
在接收端则采取缓冲机制来恢复时间顺序，
而为了实现媒体的流畅播放，
则采用了播放缓冲。

通过接收缓冲机制，在服务器端实现数据缓存功能，并对接收到的乱序数据进行排序处理。具体来说，在接收过程中需要分析封装信息属性（例如：序号字段和时间戳字段），然后对这些信息进行比对分析以识别出错乱的数据块。在此基础上完成排序后的内容会被添加到播放缓冲区中供播放使用。

显然由于网络环境未必理想且对数据包排序涉及处理延迟因此接收的有序数据包之间存在不均的时间间隔.若无播放缓冲机制这将导致播放效果会出现卡顿现象.为了有效缓解这一问题我们采用播放缓冲机制在启动播放时先积累一定数量的数据包（例如PPLIVE）从而能够有效地平衡各段落之间的时长差异进而保障流媒体的流畅播放.这种方法在既不显著牺牲实时性前提下能够实现高质量的在线观看体验.

到目前为止,互联网上应用广泛流媒体视频格式主要包括以下几种类型:采用RealMedia技术的产品,基于QuickTime平台的应用程序以及微软公司采用AS/AF标准的技术方案。

在讨论接收缓冲时提到了关于流媒体数据包的封装细节（如序号和时间戳等），这些内容也会在后续的RTP封装过程中有所体现。值得注意的是，在编解码方面尽管RealMedia和其他流式媒体格式存在差异性但就RTP而言它们都需作为待封装传输的数据源并无特殊区别。

第2章. RTP详解

2.1. RTP的协议层次

2.1.1. 传输层的子层

RTP（Real-Time Transmission Protocol），它旨在实现实时数据的传送，并被设计为通信网络中的一种关键机制。因此，在网络通信层次中被识别为一个重要的子层。图1展示了流媒体应用中一个典型的数据流架构。

图 1 流媒体体系结构

通过查看图表可知，在传输层中可以看到RTP被划分出来，并且其基础架构与UDP相似。为了提供其实时传输功能需求，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位，并表示该数据包中的首字节被采样的精确时刻。当会话启动时，在此字段中存储了一个初始值。即便没有任何信号传输发生，在此字段中的数值也会持续递增（因为随着时间流逝）。其核心作用在于消除数据抖动并确保系统同步。

同步源ID（SSRC）：32位数值，在同一RTP会话中所有使用的SSRC值必须互不相同。同步源指的是RTP数据包流的唯一来源标识。RFC1889标准建议采用MD5算法来生成这些随机唯一的同步源标识符。

贡献源列表（CSRC List）包含从0到15的共计16个字段字段每个字段占用32位用于标识标示参与 RTP 流传输送的所有相关方的所有相关方的信息通过 RTP 混合器将所有具有贡献的 SSRC 标识码记录在列表中这样接收端就能够明确识别参与对话的所有两端

2.3. RTCP的封装

RTP基于RTCP来保障其服务质量，并且由此可见下面将介绍RTCP的相关知识

RTCP的核心功能包括服务质量的监控与反馈机制、媒体间的同步操作以及多播组成员标识管理等方面。在RTP会议期间内，各参与方会定期发送RTCP包。这些RTCP包中包含了当前已发送的数据包数量、 yet yet yet yet yet yet yet yet yet lost data packet的数量等相关统计信息。通过这些数据统计信息, 各参与方能够动态地调整传输速率, 并根据需要更换有效负载类型以优化资源使用效率. RTP协议与RTCP协议协同工作, 它们能够在高效利用反馈机制的同时实现最低通信开销, 因此特别适用于实时数据传输场景。

如图1所示, RTCP虽然也是基于UDP协议实现数据传输,但其核心仅包含少量控制信息,因此每个分组长度都较短.从而允许多个RTCP分组被合并到一个UDP报文中.此外, RTCP支持以下五种不同的分组类型.

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

表 1 RTCP的5种分组类型

上述五种分组的封装形式基本一致，在此仅限于介绍SR类型的实现细节

发送端报告分组SR（Sender Report）用于通过广播机制向所有接收端发送端报告其实时状态。该报告包主要包含以下信息：对应的SSRC字段、记录最新生成的RTCP分组的时间戳及所属NTP服务器的信息、RTCP流所包含的所有RTCP分组总数以及总传输数据量等关键参数。其中的具体组成包括：与当前RTCP流相关的SSRC标识符、RTCP分组产生时间及其所属NTP服务器标识符、该RTCP流下累积存在的全部RTCP分组数量以及总的比特数据量等详细信息。这些数据通过特定编码方式被组织并打包形成一个完整的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包发送时刻所携带的精确时间戳。该协议用于同步不同媒体流。

RTP Timestamp：与NTP时间戳一致，在单位以及起始值方面均保持一致。

Number of RTP packets sent by the sender: During the interval from when the sender began transmitting packets until the creation of this SR packet, a total number of RTP data packets were sent. Upon modification of the SSRC, this field is reset to zero.

Number of octets sent by the sender from the time when the sender began sending packets until the generation of this SR packet represents the total number of net payload data transmitted by the sender during that interval. When the sender changes its SSRC, this field must be reset to zero.

同步数据源n的SSRC标识符：此份报告记录了自该源接收的数据包总量统计信息。

自上一SR/RR分段后自同步源n(SSRC_n)接收以来经由该同步源n(Sync-Source n)传输出去的RTP数据包中出现丢失的比例

累积的数量是从自接收SSRC_n的所有RTP数据包开始计算至完成SR事件传输的所有RTP数据包传输中的丢失总数

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

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

上次SR时间戳（Last SR, LSR）：从SSRC_n中最近接收的SR包中选取其中一部分作为NTP时间戳。若当前尚未收到任何SR包，则该域的时间戳设为零值。

本次SR间隔（DLSR：Delay since last SR）是指自上一周期自SSRC_n接收SR数据包后至生成并发送本报告所经历的时间间隔。

2.4. RTP的会话过程

当程序启动一个RTP会话时

**1) ** RTP 协议通过上级获取媒体数据码流（如 H.263），将其打包为 RTP 数据报；RTCP 协议则从上级获取控制指令，并将其编码为 RTCP 控制标记。

**2) ** RTP 会将 RTP 数据包传输至 UDP 端口对中的指定的偶数端口号；RTCP 会将 RTCP 控制包传输至 UDP 端口对中的对应的接收端口号。

第3章. 相关的协议

3.1. 实时流协议RTSP

实时传输协议（Real-Time Transport Protocol, Rtp）是由IETF开发的一种通信协议体系框架，在该体系中其相关RFC文档包括RFC2362

根据图 1所示，在TCP/IP网络架构内运行的RTSP是一种应用层协议；它采用C/S分层模型设计；主要用于实现类似本地光盘一样的流媒体播放与控制功能；具体而言；它可以支持如暂停/继续、后退与前进等功能。

3.2. 资源预定协议RSVP

RSVP(Resource Reservation Protocol) is a protocol proposed by IETF, and the corresponding RFC document is RFC2208.

根据图 1所示，在IP层之上、传输层之下运行的一种网络控制协议是Rsvp。基于该协议，在路由器上预留了一定的带宽资源即可确保流媒体传输的服务质量。目前已有多种实际应用实例中都集成使用了该协议作为其核心数据报机制的基础

第4章. 常见的疑问

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

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

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

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

4.3. 声音和图像怎么同步

基于声音流与图像流之间的时序关系（具体指各RTP包的时间戳信息），以及它们各自的绝对时间（即对应RTCP包中的RTCP信息），理论上可以达成声音与图像的完美同步。

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

在第1.3.1节中描述，在技术规范书中指出接收缓冲的作用是纠正数据包顺序；而播放缓冲则通过平滑播放过程来保证均匀时间间隔的实现。

第5章. 实现方案

ID	Protocol	Captured contents
Account	password	Local telephone number	Opponents Telephone Number	audio	login	logout
36	Rtp	√

表 2 协议分析要求

如表2所示，在协议分析方面存在明确的要求。显然，在 RTP 音频包中提取音频信息非常简便——只需去除 R TP 包头即可完成这一操作。当然，在播放过程中解码所需的编码信息必须能够获得，并且这些信息可以从 RTP 包头的有效载荷类型字段（PT）中提取得到。

第6章. 参考资料

[1] RFC文档：RFC3550对应RTP/RTCP，RFC2362对应RTSP，RFC2208对应RSVP

[2] http://www.faqs.org/rfcs/，上面有全面的英文RFC文档

[3] http://www.cnpaf.net/，该站提供一定数量的协议分析资料，并也包含中文的RFC文件。整体而言，其质量不高。