1. 引言 (Introduction)
本备忘录规定了实时传输协议 (Real-time Transport Protocol, RTP). RTP 为具有实时特性的数据提供端到端传送服务, 例如交互式音频和视频. 这些服务包括负载类型标识, 序列编号, 时间戳以及传送监测. 应用程序通常在 UDP 之上运行 RTP, 以利用 UDP 的复用和校验和服务; 这两个协议共同承担传输协议功能的一部分. 不过, RTP 也可以与其他合适的底层网络协议或传输协议一起使用 (见第 11 节). 如果底层网络支持组播分发, RTP 支持将数据传输到多个目的地.
需要注意, RTP 本身不提供任何机制来确保及时传送, 也不提供其他服务质量保证, 而是依赖较低层服务来完成这些工作. 它不保证传送, 不防止乱序传送, 也不假定底层网络是可靠的并按序交付数据包. RTP 中包含的序列号允许接收者重建发送者的数据包序列, 但序列号也可以用于确定某个数据包的正确位置, 例如在视频解码中, 不一定要求按序解码数据包.
虽然 RTP 主要设计用于满足多参与者多媒体会议的需求, 但它并不限于这一类应用. 连续数据的存储, 交互式分布式仿真, 主动徽章 (active badge), 以及控制和测量应用也可能适用 RTP.
本文档定义的 RTP 由两个紧密相关的部分组成:
-
实时传输协议 (RTP), 用于承载具有实时属性的数据.
-
RTP 控制协议 (RTP Control Protocol, RTCP), 用于监测服务质量, 并传递正在进行的会话中参与者的信息. RTCP 的后一个方面可能足以支持"松散控制"会话, 即没有显式成员控制和建立过程的会话, 但它不一定旨在支持某个应用程序的所有控制通信需求. 该功能可以完全或部分由单独的会话控制协议承担, 这超出本文档范围.
RTP 代表了一种遵循 Clark 和 Tennenhouse [10] 所提出的应用层成帧 (application level framing) 和集成层处理 (integrated layer processing) 原则的新型协议风格. 也就是说, RTP 旨在具有可塑性, 以提供特定应用所需的信息, 并且通常会被集成到应用程序处理之中, 而不是作为单独的层实现. RTP 是一个有意保持不完整的协议框架. 本文档规定了预期在所有适合使用 RTP 的应用中通用的功能. 与传统协议不同, 传统协议可能通过让协议更通用或增加需要解析的选项机制来容纳附加功能; RTP 则旨在根据需要通过修改和/或添加头部来定制. 第 5.3 节和第 6.4.3 节给出了示例.
因此, 除本文档之外, 针对特定应用的完整 RTP 规范还需要一个或多个配套文档 (见第 13 节):
-
配置文件 (profile) 规范文档, 定义一组负载类型代码及其到负载格式 (例如媒体编码) 的映射. 配置文件也可以定义特定应用类别专用的 RTP 扩展或修改. 通常, 一个应用程序只在一个配置文件下运行. 音频和视频数据的配置文件可见配套 RFC 3551 [1].
-
负载格式 (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 实现的需求级别.