1. 简介 (Introduction)

本备忘录指定了实时传输协议（RTP），它为具有实时特性的数据（如交互式音频和视频）提供端到端的传输服务。这些服务包括有效载荷类型标识、序列编号、时间戳和传输监控。应用程序通常在UDP之上运行RTP，以利用其多路复用和校验和服务；两种协议都为传输协议功能贡献了部分内容。

本文档定义了RTP，包括两个密切相关的部分：

• 实时传输协议（RTP），用于传输具有实时属性的数据。
• RTP控制协议（RTCP），用于监控服务质量并传达有关正在进行的会话中的参与者的信息。

RTCP的后者方面可能足以支持"松散控制"的会话，即没有明确的成员控制和设置，但不一定支持应用程序的所有控制通信需求。这一功能可能完全或部分由一个单独的会话控制协议所取代，该协议超出了本文档的范围。

RTP代表了一种新风格的协议，遵循Clark和Tennenhouse提出的应用层帧和集成层处理的原则。也就是说，RTP旨在为特定应用提供所需的信息，通常会集成到应用处理中，而不是作为一个单独的层来实现。RTP是一个有意不完整的协议框架。本文档指定了预计在所有适用于RTP的应用中都是通用的那些功能。

与传统协议不同，其中额外的功能可能通过使协议更通用或通过添加一个需要解析的选项机制来适应，RTP旨在通过对头部进行修改和/或添加来进行定制。第5.3节和第6.4.3节给出了示例。

因此，除了本文档外，针对特定应用的RTP的完整规范还需要一个或多个配套文档（参见第13节）：

• 配置文件规范文档，定义了一组有效载荷类型代码及其映射到有效载荷格式（如媒体编码）。
• 有效载荷格式规范文档，定义了如何在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实现的要求级别。