翻译RFC3550－1.引言（introduction）

1.　引言（introduction）

　　本文档详细解说了RTP协议（real-time transport protocol 实时传输控制协议），该协议为点到点之间的实时数据（如交互性的音频和视频）传递提供了服务。这些服务包括：标识净荷类型（payload type identification），编序列号（sequence numbering），加时间戳（timestamping）和监视投递过程（delivery monitoring）。应用程序通常在UDP之上运行RTP，以便使用UDP提供的多路复用(multiplexing)和校验和（checksum）服务；因为尽管这两个协议都具有传输协议的部分功能，但RTP还应适当与其他下层网络或传输层协议结合起来使用（见章节11）。在下层网络支持多播发布(multicast distribution)时，RTP支持多个目的地址的数据传输。

　　请注意，RTP本身并不提供任何机制来确保及时传递和保障服务质量（Qos），而是依靠更低的网络分层来做到这些。它既不保证正确传递或阻止无序传递，也不假定下层网络会可靠有序地传递数据包。凭借包含在RTP里的序列号，接收方可以按顺序重建发送方的数据包，然而序列号也可以用于确定一个数据包恰当的位置，例如在视频解码时，就无需按顺序解码数据包。

　　尽管RTP设计成主要用于多个参与者的多媒体会议，但并不限于此，它还可用于：连续数据存储，分布式交互模拟，活动性徽章（active badge)，以及控制和测量应用。

　　本文档定义了RTP，它包括紧密关联的两个部分：

• 实时传输协议（RTP），用于传输实时数据。
• RTP控制协议（RTCP），用于监控服务质量（Qos）和传达当前会话中参与者的信息。后一方面（即“传达参与者信息”）应能胜任“松散控制”的会话（即会话中没有显式的会员资格控制和建立），但它没必要支持一个应用程序全部的通信控制需求。该功能可能全部或部分地包含于一个单独的会话控制协议中，相关内容不在本文档讨论范围。

　　RTP代表一种新式风格的协议，它遵循了Clark and Tennenhouse[10]提出的“应用层次分帧和集成分层处理”（application level framing and integrated layer processing）的原则。也就是说，RTP有意设计成具有展性来为特定应用程序提供信息，并且常被集成在应用程序的数据处理中，而不是作为一个独立的分层被执行。RTP只是一个协议框架，有意设计成不全面的。本文档详细说明了RTP在其适用的各种应用中的通用功能。传统协议为提供额外的功能，需要变得更通用，或增加需要解析的选项机制；与此不同，RTP有意设计成对报头（headers)的增添修改具有可裁剪性。例子见于第5.3和6.4.3部分。

　　因此，作为本文档的补充，对有关特定应用中RTP的完整说明还需要其他更多的文档（见章节13）：

• 一份详细配置的文档，该文档定义了净荷（payload)类型编码及对应的净荷格式（如，媒体编码）。配置文件可能还定义了特定应用中对RTP的扩展和修改。一般地，一个应用程序只能在一个配置文件下运行。有关音频和视频数据的配置文件可在相关的RFC TBDk找到。
• 多份净荷格式说明文档，这些文档定义了RTP如何运载各种特殊净荷（如音频和视频编码）。

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

1.1 术语（Terminology）

 
　　本文档中的关键字 “MUST” “MUST NOT” “REQUIRED” “SHALL” “SHALL NOT”, “SHOULD” “SHOULD NOT” “RECOMMENED” “MAY” AND “OPTICAL”将在BCF14，RFC2119的描述中给出解释，它们指示了相应RTP实现的需求层次。