1. 简介 (Introduction)

本备忘录规定了实时传输协议 (Real-time Transport Protocol, RTP), 它为具有实时特性的数据 (如交互式音频和视频) 提供端到端传送服务。这些服务包括负载类型标识、序列编号、时间戳以及传送监视。应用通常在 UDP 之上运行 RTP, 以利用其多路复用和校验和功能; 两个协议共同贡献了传输协议功能的一部分。然而, RTP 也可以与其他合适的下层网络或传输协议一起使用 (见第 11 节)。如果下层网络提供支持, RTP 支持使用多播 (multicast) 分发将数据传送到多个目的地。

请注意, RTP 本身不提供任何确保及时传送或其他服务质量 (quality-of-service) 保证的机制, 而是依赖下层服务来实现。它不保证传送, 也不防止乱序传送, 并且不假设下层网络是可靠的、能按序交付报文。RTP 中包含的序列号允许接收方重建发送方的报文序列, 但序列号也可能用于确定报文的正确位置, 例如在视频解码中, 不必按顺序解码报文即可定位。

虽然 RTP 主要是为满足多参与者多媒体会议的需求而设计的, 但它并不限于这一特定应用。连续数据的存储、交互式分布式仿真、活动徽章 (active badge) 以及控制和测量应用也可能发现 RTP 的适用性。

本文档规定了 RTP, 它由两个紧密相关的部分组成:

o 实时传输协议 (RTP), 用于承载具有实时特性的数据。

o RTP 控制协议 (RTCP), 用于监视服务质量并传送正在进行的会话中参与者的信息。RTCP 的后者特性对于 "松散控制 (loosely controlled)" 的会话可能已经足够, 即那些没有显式成员控制和建立过程的会话, 但它未必旨在支持应用所有控制通信需求。此功能可能被一个独立的会话控制协议全部或部分涵盖, 而该协议不在本文档范围内。

RTP 代表了遵循 Clark 和 Tennenhouse [10] 提出的应用层成帧 (application level framing) 与集成层处理 (integrated layer processing) 原则的一种新型协议。也就是说, RTP 的设计是可根据特定应用的需要进行塑造, 以提供该应用所需的信息, 并且通常会被集成到应用的处理逻辑中, 而不是作为一个独立的层来实现。RTP 是一个刻意不完整的协议框架。本文档规定了对于那些适合使用 RTP 的应用而言, 预期为它们所共有的那些功能。与那些可能通过使协议更通用或添加需要解析的可选机制来容纳附加功能的传统协议不同, RTP 旨在通过按需对头部进行修改和/或扩充来进行裁剪。相关示例见第 5.3 节和第 6.4.3 节。

因此, 除本文档外, 针对某一特定应用的 RTP 完整规范还需要一个或多个配套文档 (见第 13 节):

o 配置文件 (profile) 规范文档, 它定义一组负载类型代码及其到负载格式 (例如媒体编码) 的映射。配置文件也可以定义针对某一特定应用类别的、对 RTP 的扩展或修改。通常一个应用只在一个配置文件下运行。关于音频和视频数据的配置文件可在配套文档 RFC 3551 [1] 中找到。

o 负载格式 (payload format) 规范文档, 它定义某个特定负载 (例如某种音频或视频编码) 应如何在 RTP 中承载。

关于实时服务及其实现算法的讨论, 以及关于某些 RTP 设计决策的背景讨论, 可在 [11] 中找到。

1.1 术语 (Terminology)

本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照 BCP 14、RFC 2119 [2] 中的描述进行解释, 并指示符合规范的 RTP 实现所应满足的要求级别。