1、RFC3550RTP：实时应用程序传输协议摘要本文描述 RTP（real-time transport protocol） ，实时传输协议。RTP 在多点传送（多播）或单点传送（单播）的网络服务上，提供端对端的网络传输功能，适合应用程序传输实时数据，如：音频，视频或者仿真数据。RTP 没有为实时服务提供资源预留的功能，也不能保证 QoS（服务质量） 。数据传输功能由一个控制协议（RTCP）来扩展，通过扩展，可以用一种方式对数据传输进行监测控制，该协议（RTCP）可以升级到大型的多点传送（多播）网络，并提供最小限度的控制和鉴别功能。RTP 和 RTCP 被设计成和下面的传输层和网络层无关。协议支
2、持 RTP 标准的转换器和混合器的使用。本文的大多数内容和旧版的 RFC1889 相同。在线路里传输的数据包格式没有改变，唯一的改变是使用协议的规则和控制算法。为了最小化传输，发送 RTCP 数据包时超过了设定的速率，而在这时，很多的参与者同时加入了一个会话，在这样的情况下，一个新加入到（用于计算的可升级的）计时器算法中的元素是最大的改变。目录（Table of Contents）1. 引言 （Introduction）1 1 术语（Terminology） 2 RTP 使用场景（RTP Use Scenarios） 2 1 简单多播音频会议（ Simple Multicast Audio C
3、onference） 2 2 音频和视频会议（Audio and Video Conference ） 2 3 混频器和转换器（Mixers and Translators） 2 4 分层编码（Layered Encodings） 3 定义（Definitions ） 4 字节序，校正和时间格式（Byte Order, Alignment, and Time Format） 5 RTP 数据传输协议（RTP Data Transfer Protocol） 5 1 RTP 固定头域（RTP Fixed Header Fields ） 5 2 多路复用 RTP 会话（Multiplexing RT
4、P Sessions） 5 3 RTP 头的配置文件详细变更（Profile-Specific Modifications to the RTP Header） 5 3 1 RTP 报头扩展（RTP Header Extension） 6 RTP 控制协议（RTP Control Protocol） - RTCP 6 1 RTCP 包格式（RTCP Packet Format） 6 2 RTCP 传输间隔（RTCP Transmission Interval） 6 2 1 维护会话成员数目（Maintaining the number of session members） 6 3 RTCP
5、包的发送与接收规则（ RTCP Packet Send and Receive Rules） 6 3 1 计算 RTCP 传输间隔（ Computing the RTCP Transmission Interval） 6 3 2 初始化（Initialization） 6 3 3 接收 RTP 或 RTCP（非 BYE)包（Receiving an RTP or Non-BYE RTCP Packet） 6 3 4 接收 RTCP（BYE ）包（Receiving an RTCP BYE Packet） 6 3 5 SSRC 计时失效（Timing Out an SSRC）6 3 6 关于传输
6、计时器的到期（Expiration of Transmission Timer） 6 3 7 传输一个 BYE 包（Transmitting a BYE Packet）6 3 8 更新 we_sent（Updating we_sent）6 3 9 分配源描述带宽（Allocation of Source Description Bandwidth）6 4 发送方和接收方报告（Sender and Receiver Reports） 6 4 1 SR：发送方报告的 RTCP 包（SR: Sender report RTCP packet） 6 4 2 RR：接收方报告的 RTCP 包（RR: R
7、eceiver Report RTCP Packet ） 6 4 3 扩展发送方和接收方报告（Extending the Sender and Receiver Reports ） 6 4 4 分析发送方和接收方报告（Analyzing Sender and Receiver Reports ） 6 5 SDES：源描述 RTCP 包（SDES: Source description RTCP packet ） 6 5 1 CNAME：规范终端标识符的 SDES 数据项 (CNAME: Canonical End-Point Identifier SDES Item） 6 5 2 NAME：用
8、户名的 SDES 数据项（NAME: User name SDES item) 6 5 3 EMAIL:电子邮件地址的 SDES 数据项（EMAIL: Electronic Mail Address SDES Item） 6 5 4 PHONE：电话号码的 SDES 数据项（PHONE: Phone Number SDES Item）6 5 5 LOC:地理用户地址的 SDES 数据项（LOC: Geographic User Location SDES Item）6 5 6 TOOL：应用程序或工具名字的 SDES 数据项（TOOL: Application or Tool Name SDE
9、S Item） 6 5 7 NOTE：通知/ 状态的 SDES 数据项（NOTE: Notice/Status SDES Item ） 6 5 8 PRIV:私有扩展的 SDES 数据项（PRIV: Private Extensions SDES Item） 6 6 BYE：Goodbye RTCP 包（BYE: Goodbye RTCP packet） 6 7 APP:定义应用程序的 RTCP 包（APP: Application-Defined RTCP Packet）7 RTP 转换器和混频器（RTP Translators and Mixers） 7 1 概述（General Desc
10、ription ） 7 2 在转换器中的 RTCP 数据处理（RTCP Processing in Translators） 7 3 在混频器中的 RTCP 数据处理（RTCP Processing in Mixers ） 7 4 级联混频器（Cascaded Mixers） 8 SSRC 标识符的分配和使用（SSRC Identifier Allocation and Use） 8 1 冲突概率（Probability of Collision ） 8 2 冲突解决和循环检测（Collision Resolution and Loop Detection）8 3 在分层编码中使用（Use w
11、ith Layered Encodings） 9 安全（Security ） 9 1 机密性（Confidentiality） 9 2 身份验证和消息完整性（Authentication and Message Integrity） 10 拥塞控制（Congestion Control） 11 网络和传输协议之上的 RTP（RTP over Network and Transport Protocols） 12 协议常量摘要（Summary of Protocol Constants） 12 1 RTCP 包类型（RTCP Packet Types） 12 2 SDES 类型（SDES Typ
12、es） 13 RTP 概况和负载格式详细说明（RTP Profiles and Payload Format Specifications） 14 安全考虑（Security Considerations） 15 IANA 考虑（ IANA Considerations） 16 知识产权声明（Intellectual Property Rights Statement） 17 鸣谢（Acknowledgments） 附录 A 算法（Algorithms ） 附录 A 1 RTP 数据头有效性检查（RTP Data Header Validity Checks ） 附录 A 2 RTCP 数据头
13、有效性检查（RTCP Header Validity Checks） 附录 A 3 确定 RTP 包预期数目和丢失数目（Determining Number of Packets Expected and Lost） 附录 A 4 生成 SDES RTCP 包（Generating RTCP SDES Packets） 附录 A 5 解析 RTCP SDES 包（Parsing RTCP SDES Packets） 附录 A 6 生成 32 位随机标识符（ Generating a Random 32-bit Identifier 附录 A 7 计算 RTCP 传输间隔（Computing t
14、he RTCP Transmission Interval） 附录 A 8 估测两次到达间隔的抖动（ Estimating the Interarrival Jitter） 附录 B 与 RFC1889 不同之外（Changes from RFC 1889） 参考书目（References ） 标准化引用（Normative References ） 资料性引用（Informative References ） 作者地址 完整的版权声明 1.绪论本文详细的介绍实时传输协议 RTP，RTP 提供带有实时特性的端对端数据传输服务，传输的数据如：交互式的音频和视频。那些服务包括有效载荷类型定义，序列
15、号，时间戳和传输监测控制。应用程序在 UDP 上运行 RTP 来使用它的多路技术和 checksum 服务。2 种协议都提供传输协议的部分功能。不过，RTP 可能被其他适当的下层网络和传输协议使用（见 11 节） 。如果下层网络支持，RTP 支持数据使用多播分发机制转发到多个目的地。注意 RTP 本身没有提供任何的机制来确保实时的传输或其他的服务质量保证，而是由低层的服务来完成。它不保证传输或防止乱序传输，它不假定下层网络是否可靠，是否按顺序传送数据包。RTP 包含的序列号允许接受方重构发送方的数据包顺序，但序列号也用来确定一个数据包的正确位置，例如，在视频解码的时候不用按顺序的对数据包进行解
16、码。但是 RTP 原先的设计是用来满足多参与者的多媒体会议的需要，它没有限定于专门的应用。连续数据的储存，交互分布式仿真，动态标记，以及控制和测量应用程序也可能会适合使用 RTP。该文档定义 RTP，由 2 个密切联系的部分组成：实时传输协议 RTP，用于实时传输数据。RTP 控制协议 RTCP，用于监控服务质量和传达关于在一个正在进行的会议中的参与者的信息。后者对“宽松控制” 的会议可能已经足够，但是并没有必要去支持一个应用程序所有的通讯控制条件。这个功能可能充分的或者部分的被一个单独的会议控制协议所包含，这超过了本文档的范围。RTP 表现了协议的一种新的类型，该类型由 Clark 和 Te
17、nnenhouse 提出10 ，遵循应用级（framing）框架和（integrated layer processing）统一层处理的原则。就是说，RTP 被规定为可扩展的，用来提供一个专门的应用程序需要的信息，并将会经常性的被归并到应用程序的处理中，而不是作为一个单独的层被实现。RTP 只是一个故意不完成的协议框架。本文档详细说明那些功能，希望这些功能能够普遍贯穿于所有适合使用 RTP 的应用程序。和常规的协议不同，额外的功能可能通过完善协议本身或者增加一个可能需要分析的选项机制来增加，RTP 被规定为可以根据需要通过修改和/ 或增加操作， “剪裁” 到报头。具体的例子见 5.3 和 6.
18、4.3 节。因此，除了本文档，用于专门应用程序的 RTP 完整的说明将还需要一个或者更多的同类文档（见 13 节）： 一个框架（大致轮廓）的说明文档，该文档定义了一系列的有效载荷类型编码和它们与有效载荷格式之间的映射（例如，媒体编码） 。一个框架可能也定义了应用程序对 RTP 的一些扩展和修改，详细到一个专门的类。典型的情况，一个应用程序将在一个框架下运行。一个用于音频和视频数据的框架可以在同类 RFC35511文档里找到。有效载荷格式说明文档，该文档定义了一个像一个音频或者视频编码的特殊载荷，在RTP 里是如何被传输的。一个关于实时服务和算法如何实现的讨论和关于一些 RTP 设计结果的后台讨
19、论能够在11中找到。1.1 术语在这个文档里的关键词“一定要”， “一定不能”， “必需的”， “会”， “不会”， “应该”， “不应该”， “推荐”， “可能”和“可选” 将会像在 BCP 14（Basic Control Program，基本控制程序） ，RFC21192里描述一样的解释。并指出适合 RTP 实现的需要的级别。2. RTP 使用场景（RTP Use Scenarios）2.1 简单多播音频会议（ Simple Multicast Audio Conference）2.2 音频和视频会议（Audio and Video Conference ）2.3 混频器和转换器（Mix
20、ers and Translators）2.4 分层编码（Layered Encodings）以下章节描述了用到 RTP 的一些方面。所举例子用来说明 RTP 应用的基本操作，但RTP 的用途不限于此。在这些例子中，RTP 运行于 IP 和 UDP 之上，并且遵循 RFC3551 所描述的音频和视频的配置文件中的约定。2.1 简单多播音频会议（Simple Multicast Audio Conference）IETF 的一个工作组开会讨论最新协议草案时，使用 Internet 的 IP 多播服务来进行语音通讯。工作组中心分配到一个多播的组地址和一对端口。一个端口用于音频数据，另一个端口用于控
21、制（RTCP）数据包。该地址和端口信息发布给预定的参与者。如果有私密性要求，则可用章节 9.1 中说明的方法，对数据和控制包进行加密，这时就需要生成和发布加密密钥。分配和发布机制的精确细节不在 RTP 的讨论范围之内。每个与会者所使用的音频会议应用程序，都以小块形式（比方说持续秒时间）来发送音频数据。每个音频数据块都前导 RTP 报头；RTP 报头和数据依次包含在 UDP 包里。RTP 报头指明了各个包里音频编码的类型（如 PCM,ADPCM,LPC） ，这样发送方可以在会议过程中改变编码方式，以适应状况的变化，例如，要加进一个低带宽接入的参与者，或是要应付网络拥塞。Internet，像其他的
22、报文分组网络一样，偶而会丢失和重排包，造成时长不等的延迟。为弥补这个不足，RTP 报头里包含计时信息和一个序列号，允许接收方重建来自源的计时信息，比如前文例子中音频块以 20s 的间隔在扬声器中连续播放。会议中，对每个 RTP 包的源,单独地实施计时重建。序列号还被接收方用来评估丢失包数目。由于会议期间不断有工作组成员加入或离开，因此有必要知道任一时刻的实际参与者及他们接收音频数据的状况好坏。出于这个目的，会议中每个音频应用程序的实例，都在RTCP（控制）端口上周期性地多播一个附加用户名的接收报告。接收报告指明了当前说话者被收听到的状况，可用于控制自适应性编码。除了用户名外，通过控制带宽限度，
23、可以包含其他标识信息。一个站点在离开会议时发送 RTCP BYE 包（章节 6.5） 。2.2 音频和视频会议（Audio and Video Conference ）一个会议如果同时使用音频和视频媒体，则二者传输时使用不同的 RTP 会话。也就是说，两种媒体中 RTP 包和 RTCP 包的传输，是使用两个不同的 UDP 端口对和（或）多播地址。在 RTP 层次，音频和视频会话没有直接的耦合，下面这种情况除外：一个同时参加两个会话的参与者，在两个会话的 RTCP 包中，使用了相同的规范名，这样两个会话就发生关联（耦合）了。这样区隔开来的目的之一，是允许一些会议参与者只接受自己选择的单一媒体（或
24、者音频，或者视频） 。更进一步的说明在章节 5.2 给出。尽管两种媒体区分开来了，但通过两个会话 RTCP 包内载有的计时信息，同源的音频与视频还是能够同步回放。2.3 混频器和转换器（Mixers and Translators）到目前为止，我们皆假设所有站点都收到相同格式的媒体数据。然而这并不总是行得通。考虑一下这种情况，一个地方的参与者只能低速接入会议，而其他大部分参与者都能享受高速连接。与其让强迫大家都忍受低带宽，不如在只能低速接入的地方，放置一个减质量音频编码的 RTP 层次的中继（称作混频器） 。混频器将重新同步输入的音频包，重建发送方产生的 20ms 固定间隔，混频已重建过的音频
25、流为单一的流，转换音频编码为低带宽格式，最后通过低带宽连接转发数据包流（package stream)。这些包可能被单播到一个接收方，也可能多播到另一个的地址而发给多个接收方。RTP 报头为混频器提供了一种方法，使其能辨识出对混频后的包有用的源，从而保证提供给接收方正确的说话者指示。在音频会议中，一些预定参与者尽管有高带宽连接，但不能通过 IP 多播直接接入会议。例如，他们可能位于一个不允许任何 IP 包通过的应用层防火墙后面。对这些站点，可能就不需要混频，而需要另一种称为转换器的 RTP 层次中继。可以在防火墙两侧分别安装一个转换器，外侧转换器将所有多播包通过安全连接转入内侧转换器，内侧转换
26、器再转发给内部网的一个多播组（multicast group)。混频器和转换器可以设计成用于各种目的。比如，一个视频混频器在测量多个不同视频流中各人的单独影像后，将它们组合成一个单一视频流来模拟群组场景。又如，在只用IP/UDP 和只用 ST_II 的两个主机群之间通过转换建立连接。再如，在没有重新同步或混频时，用 packet-by-packet 编码转换来自各个独立源的视频流。混频器和转换器的操作细节见章节 7。2.4 分层编码（Layered Encodings）为了匹配接收方的能力（容量）以及适应网络拥塞，多媒体应用程序应当能够调整其传输速率。许多应用实现把调适传输速率的责任放在源端。
27、这种做法在多播传输中并不好，因为不同接收方对带宽存在着冲突性需求。这经常导致最小公分母的场景，网格中最小的管道支配了全部实况多媒体“广播”的质量和保真度。相反地，可以把分层编码和分层传输系统组合起来，从而把调适速率的责任放在接收端。在 IP 多播之上的 RTP 上下文中，对一个横跨多个 RTP 会话（每个会话在独自多播组上开展）的分级表示信号(a hierarchically represented signal)，源能够把它的分层（layers) 分割成条。 接收方仅需合并适当的多播组子集，就能适应异种网络和控制接收带宽。RTP 分层编码的细节在章节 6.3.9，8.3 和 11 中给出。3
28、. 定义（definitions)RTP 负载（RTP payload）：通过 RTP 传输的包中的数据，例如，音频样本或压缩好的视频数据。负载格式与解释不在本文讨论范围。RTP 包（RTP packet）：一种数据包，其组成部分有：一个固定 RTP 报头，一个可能为空的作用源（contributing sources）列表（见下文） ，以及负载数据。一些下层协议可能要求对 RTP 包的封装进行定义。一般地，下层协议的一个包包含一个 RTP 包，但若封装方法允许，也可包含数个 RTP 包（见章节 11） 。RTCP 包（ RTCP packet）：一种控制包，其组成部分有：一个类似 RTP 包
29、的固定报头，后跟一个结构化的部分，该部分具体元素依不同 RTCP 包的类型而定。格式的定义见章节。一般地，多个 RTCP 包将在一个下层协议的包中以合成 RTCP 包的形式传输；这依靠 RTCP 包的固定报头中的长度字段来实现。端口（Port）：“ 传输协议用来在同一主机中区分不同目的地的一种抽象。TCP/IP 协议使用正整数来标识不同端口。 ”12 OSI 传输层使用的传输选择器（TSEL,the transport selectors）等同于这里的端口。RTP 需依靠低层协议提供的多种机制，如“端口”用以多路复用会话中的 RTP 和 RTCP 包。传输地址(Transport addres
30、s)：是网络地址与端口的结合，用来标识一个传输层次的终端，例如一个 IP 地址与一个 UDP 端口。包是从源传输地址发送到目的传输地址。RTP 媒体类型（RTP media type）：一个 RTP 媒体类型是一个单独 RTP 会话所载有的负载类型的集合。RTP 配置文件把 RTP 媒体类型指派给 RTP 负载类型。多媒体会话（Multimedia session）：在一个参与者公共组中，并发的 RTP 会话的集合。例如，一个视频会议（为多媒体会话）可能包含一个音频 RTP 会话和一个视频 RTP 会话。RTP 会话（RTP session）：一群参与者通过 RTP 进行通信时所产生的关联。一
31、个参与者可能同时参与多个 RTP 会话。在一个多媒体会话中，除非编码方式把多种媒体多路复用到一个单一数据流中，否则每种媒体都将使用各自的 RTCP 包，通过单独的 RTP 会话来传送。通过使用不同的目的传输地址对（一个网络地址加上一对分别用于 RTP 和 RTCP 的端口，构成了一个传输地址对）来接收不同的会话，参与者能把多个 RTP 会话区隔开来。单个 RTP 会话中的所有参与者，可能共享一个公用目的传输地址对，比如 IP 多播的情况；也可能各自使用不同的目的传输地址对，比如个体单播网络地址加上一个端口对。对于单播的情况，参与者可能使用相同端口对来收听其他所有参与者，也可能对来其他每个参与者
32、使用不同的端口对来收听。RTP 会话间相互区别的特征，在于每个 RTP 会话都维护一个用于 SSRC 标识符的独立完整的空间。RTP 会话所包含的参与者组，由能接收 SSRC 标识符的参与者组成，这些SSRC 标识符由 RTP（同步源或作用源）或 RTCP 中的任意参与者传递。例如，考虑下述情况，用单播 UDP 实现的三方会议，每方都用不同的端口对来收听其他两方。如果收到一方的数据，就只把 RTCP 反馈发送给那一方，则会议就相当于由三个单独的点到点 RTP 会话构成；如果收到一方的数据，却把 RTCP 反馈发送另两方，则会议就是由一个多方（multi-party)RTP 会话构成。后者模拟了
33、三方间进行 IP 多播通信时的行为。RTP 框架允许上述规定发生变化，但一个特定的控制协议或者应用程序在设计时常常对变化作出约束。同步源(SSRC，Synchronization source)：RTP 包流的源，用 RTP 报头中 32 位数值的SSRC 标识符进行标识，使其不依赖于网络地址。一个同步源的所有包构成了相同计时和序列号空间的一部分，这样接收方就可以把一个同步源的包放在一起，来进行重放。举些同步源的例子，像来自同一信号源的包流的发送方，如麦克风、摄影机、RTP 混频器（见下文）就是同步源。一个同步源可能随着时间变化而改变其数据格式，如音频编码。SSRC标识符是一个随机选取的值，它
34、在特定的 RTP 会话中是全局唯一（ globally unique）的（见章节 8） 。参与者并不需要在一个多媒体会议的所有 RTP 会话中，使用相同的 SSRC 标识符；SSRC 标识符的绑定通过 RTCP（见章节 6.5.1） 。如果参与者在一个 RTP 会话中生成了多个流，例如来自多个摄影机，则每个摄影机都必须标识成单独的同步源。作用源（CSRC，Contributing source )：若一个 RTP 包流的源，对由 RTP 混频器生成的组合流起了作用，则它就是一个作用源。对特定包的生成起作用的源，其 SSRC 标识符组成的列表，被混频器插入到包的 RTP 报头中。这个列表叫做 C
35、SRC 表。相关应用的例子如，在音频会议中，混频器向所有的说话人（talker)指出，谁的话语（speech)将被组合到即将发出的包中，即便所有的包都包含在同一个（混频器的）SSRC 标识符中，也可让听者（接收者）可以清楚谁是当前说话人。 终端系统（End system)：一种应用程序，它产生发送出的 RTP 包中内容，或者使用接收到的 RTP 包中内容。在一个特定的 RTP 会话中，一个终端系统可以扮演一个或多个同步源角色，但通常是一个。混频器（Mixer)：一种中间系统，它从一个或多个源中接收 RTP 包，可能改变其数据格式，再按某种方式把这些包组合成一个新的包，然后转发出去。由于多个输入
36、源的计时一般不会同步，所以混频器会对各个流的计时作出调整，并为组合流生成一个新的计时。因此，混频器将被标识成它所产生所有数据包的同步源。转换器（Translator) ：一种中间系统，它转发 RTP 包而不改变各包的同步源标识符。转换器的例子如下：不作混频地转变编码的设备，把多播复制到单播的重复装置，以及防火墙里应用层次的过滤器。监视器(Monitor)：一种应用程序，它接收 RTP 会话参与者所发送的 RTCP 包，特别是接收报告（reception report)，而且对当前服务质量进行评估，评估结果用于分配监视任务，故障诊断和长期统计。监视器常常被内建到参与会话的应用程序中，但也可以是一
37、个的独立的应用程序不参加会话、也不发送或接收 RTP 数据包（因为它们在不同的端口上） 。这些被称作第三方监视器。还有一种情况也是可以接受的，第三方监视器只接收但不发送数据包，或者另外地算入到会话中。非 RTP 途径（Non-RTP means)：为提供一个可用的服务，可能还需要其他的协议和机制。特别地，对多媒体会议来说，一个控制协议可以发布多播地址，发布加密密钥，协商所用的加密算法，以及为没有预定义负载类型值的格式，建立负载类型值和其所代表的负载格式之间的动态映射。其他协议的例子如下：会话初始化协议（SIRFC326113） ，ITU推荐的 H.32314，还有使用 SDP(RFC23271
38、5)的应用程序，如 RTSP(RFC 232616). 对于简单的应用程序，电子邮件或者会议数据库也可能用到。对这些协议和机制的详细说明已经超出了本文档的讨论范围。5 RTP 数据传输协议5.1 RTP 固定头中的各字段 RTP 头有以下格式: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number |
39、 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers |
40、 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+RTP 包头格式 前 12 个字节出现在每个 RTP 包中，仅仅在被混合器插入时，才出现 CSRC 识别符列表。这些域有以下意义： 版本(V)：2 比特 此域定义了 RTP 的版本。此协议定义的版本是 2。(值 1 被 RTP 草案版本使用，值 0 用在最初“vat“语音工具使用的协议中。) 填充(P)：1 比特 若填料比特被设置，则此包包含一到多个附加在末端的填充比特，填充比特不算作负载的一部分。填充的最后一个字节指明可以忽略多少个填充比特。填充可能用于
41、某些具有固定长度的加密算法，或者用于在底层数据单元中传输多个 RTP 包。 扩展(X)：1 比特 若设置扩展比特，固定头 (仅) 后面跟随一个头扩展。 CSRC 计数(CC)：4 比特 CSRC 计数包含了跟在固定头后面 CSRC 识别符的数目。 标志(M) ：1 比特 标志的解释由具体协议规定。它用来允许在比特流中标记重要的事件，如帧边界。负载类型(PT)：7 比特 此域定义了负载的格式，由具体应用决定其解释。协议可以规定负载类型码和负载格式之间一个默认的匹配。其他的负载类型码可以通过非 RTP 方法动态定义。RTP 发送端在任意给定时间发出一个单独的 RTP 负载类型；此域不用来复用不同的
42、媒体流。 序列号（sequence number）：16 比特 每发送一个 RTP 数据包，序列号加 1，接收端可以据此检测丢包和重建包序列。序列号的初始值是随机的(不可预测) ，以使即便在源本身不加密时(有时包要通过翻译器，它会这样做 )，对加密算法泛知的普通文本攻击也会更加困难。 时间戳（timestamp） 32 比特时间戳反映了 RTP 数据包中第一个字节的采样时间。时钟频率依赖于负载数据格式，并在描述文件（profile）中进行描述。也可以通过 RTP 方法对负载格式动态描述。如果 RTP 包是周期性产生的，那么将使用由采样时钟决定的名义上的采样时刻，而不是读取系统时间。例如，对一个
43、固定速率的音频，采样时钟将在每个周期内增加 1。如果一个音频从输入设备中读取含有 160 个采样周期的块，那么对每个块，时间戳的值增加 160。时间戳的初始值应当是随机的，就像序号一样。几个连续的 RTP 包如果是同时产生的。如：属于同一个视频帧的 RTP 包，将有相同的序列号。不同媒体流的 RTP 时间戳可能以不同的速率增长。而且会有独立的随机偏移量。因此，虽然这些时间戳足以重构一个单独的流的时间，但直接比较不同的媒体流的时间戳不能进行同步。对于每一个媒体，我们把与采样时刻相关联的 RTP 时间戳与来自于参考时钟上的时间戳（NTP）相关联。因此参考时钟的时间戳就了数据的采样时间。 （即：RT
44、P 时间戳可用来实现不同媒体流的同步，NTP 时间戳解决了 RTP 时间戳有随机偏移量的问题。 ）参考时钟用于同步所有媒体的共同时间。这一时间戳对（RTP 时间戳和 NTP 时间戳） ，用于判断RTP 时间戳和 NTP 时间戳的对应关系，以进行媒体流的同步。它们不是在每一个数据包中都被发送，而在发送速率更低的 RTCP 的 SR（发送者报告）中。如果传输的数据是存贮好的，而不是实时采样等到的，那么会使用从参考时钟得到的虚的表示时间线（virtual presentation timeline） 。以确定存贮数据中的每个媒体下一帧或下一个单元应该呈现的时间。此种情况下 RTP 时间戳反映了每一个
45、单元应当回放的时间。真正的回放将由接收者决定。SSRC：32 比特 用以识别同步源。标识符被随机生成，以使在同一个 RTP 会话期中没有任何两个同步源有相同的 SSRC 识别符。尽管多个源选择同一个 SSRC 识别符的概率很低，所有 RTP 实现工具都必须准备检测和解决冲突。若一个源改变本身的源传输地址，必须选择新的 SSRC 识别符，以避免被当作一个环路源。CSRC 列表：0 到 15 项，每项 32 比特 CSRC 列表识别在此包中负载的所有贡献源。识别符的数目在 CC 域中给定。若有贡献源多于 15 个，仅识别 15 个。CSRC 识别符由混合器插入，并列出所有贡献源的 SSRC 识别符
46、。例如语音包，混合产生新包的所有源的SSRC 标识符都被列出，以在接收端处正确指示参与者。 5.3.1 RTP 头扩展 RTP 提供扩展机制以允许实现个性化：某些新的与负载格式独立的功能要求的附加信息在 RTP 数据包头中传输。设计此方法可以使其它没有扩展的交互忽略此头扩展。RTP 头扩展的格式如下图所示。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | defin
47、ed by profile | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | header extension | | |若 RTP 头中的扩展比特位置 1，则一个长度可变的头扩展部分被加到 RTP 固定头之后。头扩展包含 16 比特的长度域，指示扩展项中 32 比特字的个数，不包括 4 个字节扩展头(因此零是有效值)。RTP 固定头之后只允许有一个头扩展。为允许多个互操作实现独立生成不同的头扩展，或某种特定实现有多种不同的头扩展，扩展项的前 16 比特用以识别标识符或参数。这 16 比
48、特的格式由具体实现的上层协议定义。基本的 RTP 说明并不定义任何头扩展本身。 6 RTP 控制协议 RTCP RTP 控制协议(RTCP)向会议中所有成员周期性发送控制包。它使用与数据包相同的传输机制。底层协议必须提供数据包和控制包的复用，例如用不同的 UDP 端口。RTCP 提供以下四个功能： 基本功能是提供数据传输质量的反馈。这是 RTP 作为一种传输协议的主要作用，它与其他协议的流量和拥塞控制相关。反馈可能对自适应编码有直接作用，并且 IP 组播的实验表明它对于从接收端得到反馈信息以诊断传输故障也有决定性作用。向所有成员发送接收反馈可以使“观察员 “评估这些问题是局部的还是全局的。利用类似多点广播的传输机制，可以使某些实体，诸如没有加入会议的网络业务观察员，接收到反馈信息并作为第三方监视员来诊断网络故障。反馈功能通过 RTCP 发送者和接收者报告实现。 RTCP 为每个 RTP 源传输一个固定的识别符，称为规范名（CNAME） 。由于当发生冲突或程序重启时 SSRC 可能改变，接收者要用 CNAME 来跟踪每个成员。接收者还要用CNAME 来关联一系列相关 RTP 会话中来自同一个成员的多个数据流，例如同步语音和图像。前两个功能要求所有成员都发送 RTCP 包，因此必须控制速率以使 RTP 成员数可以逐级增长。通过让每个成员向所有成员发送控制包，各个成员都可以独立地
