RFC3550_RTP：实时应用程序传输协议.doc

RFC3550

RTP：实时应用程序传输协议

摘要
本文描述RTP（real-time transport protocol），实时传输协议。RTP在多点传送（多播）或单点传送（单播）的网络服务上，提供端对端的网络传输功能，适合应用程序传输实时数据，如：音频，视频或者仿真数据。RTP没有为实时服务提供资源预留的功能，也不能保证QoS（服务质量）。数据传输功能由一个控制协议（RTCP）来扩展，通过扩展，可以用一种方式对数据传输进行监测控制，该协议（RTCP）可以升级到大型的多点传送（多播）网络，并提供最小限度的控制和鉴别功能。RTP和RTCP被设计成和下面的传输层和网络层无关。协议支持RTP标准的转换器和混合器的使用。
本文的大多数内容和旧版的RFC1889相同。在线路里传输的数据包格式没有改变，唯一的改变是使用协议的规则和控制算法。为了最小化传输，发送RTCP数据包时超过了设定的速率，而在这时，很多的参与者同时加入了一个会话，在这样的情况下，一个新加入到（用于计算的可升级的）计时器算法中的元素是最大的改变。

目录（Table of Contents）
1. 引言 （Introduction）
1 1 术语（Terminology）
2 RTP使用场景（RTP Use Scenarios）
2 1 简单多播音频会议（ Simple Multicast Audio Conference）
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 RTP 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包的发送与接收规则（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 关于传输计时器的到期（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: Receiver 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：用户名的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 SDES 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 Description ）
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 with 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 Types）
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数据头有效性检查（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 the RTCP Transmission Interval）
附录 A 8 估测两次到达间隔的抖动（Estimating the Interarrival Jitter）
附录 B 与RFC1889不同之外（Changes from RFC 1889）
参考书目（References）
标准化引用（Normative References ）
资料性引用（Informative References）
作者地址
完整的版权声明

1.绪论
本文详细的介绍实时传输协议RTP，RTP提供带有实时特性的端对端数据传输服务，传输的数据如：交互式的音频和视频。那些服务包括有效载荷类型定义，序列号，时间戳和传输监测控制。应用程序在UDP上运行RTP来使用它的多路技术和checksum服务。2种协议都提供传输协议的部分功能。不过，RTP可能被其他适当的下层网络和传输协议使用（见11节）。如果下层网络支持，RTP支持数据使用多播分发机制转发到多个目的地。
注意RTP本身没有提供任何的机制来确保实时的传输或其他的服务质量保证，而是由低层的服务来完成。它不保证传输或防止乱序传输，它不假定下层网络是否可靠，是否按顺序传送数据包。RTP包含的序列号允许接受方重构发送方的数据包顺序，但序列号也用来确定一个数据包的正确位置，例如，在视频解码的时候不用按顺序的对数据包进行解码。
但是RTP原先的设计是用来满足多参与者的多媒体会议的需要，它没有限定于专门的应用。连续数据的储存，交互分布式仿真，动态标记，以及控制和测量应用程序也可能会适合使用RTP。
该文档定义RTP，由2个密切联系的部分组成：
○实时传输协议RTP，用于实时传输数据。
○RTP控制协议RTCP，用于监控服务质量和传达关于在一个正在进行的会议中的参与者的信息。后者对“宽松控制”的会议可能已经足够，但是并没有必要去支持一个应用程序所有的通讯控制条件。这个功能可能充分的或者部分的被一个单独的会议控制协议所包含，这超过了本文档的范围。
RTP表现了协议的一种新的类型，该类型由Clark和Tennenhouse提出[10]，遵循应用级（framing）框架和（integrated layer processing）统一层处理的原则。就是说，RTP被规定为可扩展的，用来提供一个专门的应用程序需要的信息，并将会经常性的被归并到应用程序的处理中，而不是作为一个单独的层被实现。RTP只是一个故意不完成的协议框架。本文档详细说明那些功能，希望这些功能能够普遍贯穿于所有适合使用RTP的应用程序。和常规的协议不同，额外的功能可能通过完善协议本身或者增加一个可能需要分析的选项机制来增加，RTP被规定为可以根据需要通过修改和/或增加操作，“剪裁”到报头。具体的例子见5.3和6.4.3节。
因此，除了本文档，用于专门应用程序的RTP完整的说明将还需要一个或者更多的同类文档（见13节）：
○ 一个框架（大致轮廓）的说明文档，该文档定义了一系列的有效载荷类型编码和它们与有效载荷格式之间的映射（例如，媒体编码）。一个框架可能也定义了应用程序对RTP的一些扩展和修改，详细到一个专门的类。典型的情况，一个应用程序将在一个框架下运行。一个用于音频和视频数据的框架可以在同类RFC3551[1]文档里找到。
○有效载荷格式说明文档，该文档定义了一个像一个音频或者视频编码的特殊载荷，在RTP里是如何被传输的。
一个关于实时服务和算法如何实现的讨论和关于一些RTP设计结果的后台讨论能够在[11]中找到。
1.1术语
在这个文档里的关键词“一定要”，“一定不能”，“必需的”，“会”，“不会”，“应该”，“不应该”，“推荐”，“可能”和“可选” 将会像在BCP 14（Basic Control Program，基本控制程序），RFC2119[2]里描述一样的解释。并指出适合RTP实现的需要的级别。

2. RTP使用场景（RTP Use Scenarios）
2.1 简单多播音频会议（ Simple Multicast Audio Conference）
2.2 音频和视频会议（Audio and Video Conference）
2.3 混频器和转换器（Mixers and Translators）
2.4 分层编码（Layered Encodings）
　　以下章节描述了用到RTP的一些方面。所举例子用来说明RTP应用的基本操作，但RTP的用途不限于此。在这些例子中，RTP运行于IP和UDP之上，并且遵循RFC3551所描述的音频和视频的配置文件中的约定。
2.1 简单多播音频会议（Simple Multicast Audio Conference）
　　IETF的一个工作组开会讨论最新协议草案时，使用Internet的IP多播服务来进行语音通讯。工作组中心分配到一个多播的组地址和一对端口。一个端口用于音频数据，另一个端口用于控制（RTCP）数据包。该地址和端口信息发布给预定的参与者。如果有私密性要求，则可用章节9.1中说明的方法，对数据和控制包进行加密，这时就需要生成和发布加密密钥。分配和发布机制的精确细节不在RTP的讨论范围之内。
　　每个与会者所使用的音频会议应用程序，都以小块形式（比方说持续２０秒时间）来发送音频数据。每个音频数据块都前导RTP报头；RTP报头和数据依次包含在UDP包里。RTP报头指明了各个包里音频编码的类型（如PCM,ADPCM,LPC），这样发送方可以在会议过程中改变编码方式，以适应状况的变化，例如，要加进一个低带宽接入的参与者，或是要应付网络拥塞。
　　Internet，像其他的报文分组网络一样，偶而会丢失和重排包，造成时长不等的延迟。为弥补这个不足，RTP报头里包含计时信息和一个序列号，允许接收方重建来自源的计时信息，比如前文例子中音频块以20s的间隔在扬声器中连续播放。会议中，对每个RTP包的源,单独地实施计时重建。序列号还被接收方用来评估丢失包数目。
　　由于会议期间不断有工作组成员加入或离开，因此有必要知道任一时刻的实际参与者及他们接收音频数据的状况好坏。出于这个目的，会议中每个音频应用程序的实例，都在RTCP（控制）端口上周期性地多播一个附加用户名的接收报告。接收报告指明了当前说话者被收听到的状况，可用于控制自适应性编码。除了用户名外，通过控制带宽限度，可以包含其他标识信息。一个站点在离开会议时发送RTCP BYE包（章节6.5）。
2.2　音频和视频会议（Audio and Video Conference）
　　一个会议如果同时使用音频和视频媒体，则二者传输时使用不同的RTP会话。也就是说，两种媒体中RTP包和RTCP包的传输，是使用两个不同的UDP端口对和（或）多播地址。在RTP层次，音频和视频会话没有直接的耦合，下面这种情况除外：一个同时参加两个会话的参与者，在两个会话的RTCP包中，使用了相同的规范名，这样两个会话就发生关联（耦合）了。
　　这样区隔开来的目的之一，是允许一些会议参与者只接受自己选择的单一媒体（或者音频，或者视频）。更进一步的说明在章节5.2给出。尽管两种媒体区分开来了，但通过两个会话RTCP包内载有的计时信息，同源的音频与视频还是能够同步回放。
2.3　混频器和转换器（Mixers and Translators）
　　到目前为止，我们皆假设所有站点都收到相同格式的媒体数据。然而这并不总是行得通。考虑一下这种情况，一个地方的参与者只能低速接入会议，而其他大部分参与者都能享受高速连接。与其让强迫大家都忍受低带宽，不如在只能低速接入的地方，放置一个减质量音频编码的RTP层次的中继（称作混频器）。混频器将重新同步输入的音频包，重建发送方产生的20ms固定间隔，混频已重建过的音频流为单一的流，转换音频编码为低带宽格式，最后通过低带宽连接转发数据包流（package stream)。这些包可能被单播到一个接收方，也可能多播到另一个的地址而发给多个接收方。RTP报头为混频器提供了一种方法，使其能辨识出对混频后的包有用的源，从而保证提供给接收方正确的说话者指示。
　　在音频会议中，一些预定参与者尽管有高带宽连接，但不能通过IP多播直接接入会议。例如，他们可能位于一个不允许任何IP包通过的应用层防火墙后面。对这些站点，可能就不需要混频，而需要另一种称为转换器的RTP层次中继。可以在防火墙两侧分别安装一个转换器，外侧转换器将所有多播包通过安全连接转入内侧转换器，内侧转换器再转发给内部网的一个多播组（multicast group)。
　　混频器和转换器可以设计成用于各种目的。比如，一个视频混频器在测量多个不同视频流中各人的单独影像后，将它们组合成一个单一视频流来模拟群组场景。又如，在只用IP/UDP和只用ST_II的两个主机群之间通过转换建立连接。再如，在没有重新同步或混频时，用packet-by-packet编码转换来自各个独立源的视频流。混频器和转换器的操作细节见章节7。
2.4 分层编码（Layered Encodings）
　　为了匹配接收方的能力（容量）以及适应网络拥塞，多媒体应用程序应当能够调整其传输速率。许多应用实现把调适传输速率的责任放在源端。这种做法在多播传输中并不好，因为不同接收方对带宽存在着冲突性需求。这经常导致最小公分母的场景，网格中最小的管道支配了全部实况多媒体“广播”的质量和保真度。
　　相反地，可以把分层编码和分层传输系统组合起来，从而把调适速率的责任放在接收端。在IP多播之上的RTP上下文中，对一个横跨多个RTP会话（每个会话在独自多播组上开展）的分级表示信号(a hierarchically represented signal)，源能够把它的分层（layers)分割成条。 接收方仅需合并适当的多播组子集，就能适应异种网络和控制接收带宽。
RTP分层编码的细节在章节6.3.9，8.3和11中给出。

3.　定义（definitions)
　　RTP负载（RTP payload）：通过RTP传输的包中的数据，例如，音频样本或压缩好的视频数据。负载格式与解释不在本文讨论范围。
　　RTP包（RTP packet）：一种数据包，其组成部分有：一个固定RTP报头，一个可能为空的作用源（contributing sources）列表（见下文），以及负载数据。一些下层协议可能要求对RTP包的封装进行定义。一般地，下层协议的一个包包含一个RTP包，但若封装方法允许，也可包含数个RTP包（见章节11）。
　　 RTCP包（RTCP packet）：一种控制包，其组成部分有：一个类似RTP包的固定报头，后跟一个结构化的部分，该部分具体元素依不同RTCP包的类型而定。格式的定义见章节６。一般地，多个RTCP包将在一个下层协议的包中以合成RTCP包的形式传输；这依靠RTCP包的固定报头中的长度字段来实现。
　　端口（Port）：“传输协议用来在同一主机中区分不同目的地的一种抽象。TCP/IP协议使用正整数来标识不同端口。”[12]　OSI传输层使用的传输选择器（TSEL,the transport selectors）等同于这里的端口。RTP需依靠低层协议提供的多种机制，如“端口”用以多路复用会话中的RTP和RTCP包。
　　传输地址(Transport address)：是网络地址与端口的结合，用来标识一个传输层次的终端，例如一个IP地址与一个UDP端口。包是从源传输地址发送到目的传输地址。
　　RTP媒体类型（RTP media type）：一个RTP媒体类型是一个单独RTP会话所载有的负载类型的集合。RTP配置文件把RTP媒体类型指派给RTP负载类型。
　　多媒体会话（Multimedia session）：在一个参与者公共组中，并发的RTP会话的集合。例如，一个视频会议（为多媒体会话）可能包含一个音频RTP会话和一个视频RTP会话。
　　RTP会话（RTP session）：一群参与者通过RTP进行通信时所产生的关联。一个参与者可能同时参与多个RTP会话。在一个多媒体会话中，除非编码方式把多种媒体多路复用到一个单一数据流中，否则每种媒体都将使用各自的RTCP包，通过单独的RTP会话来传送。通过使用不同的目的传输地址对（一个网络地址加上一对分别用于RTP和RTCP的端口，构成了一个传输地址对）来接收不同的会话，参与者能把多个RTP会话区隔开来。单个RTP会话中的所有参与者，可能共享一个公用目的传输地址对，比如IP多播的情况；也可能各自使用不同的目的传输地址对，比如个体单播网络地址加上一个端口对。对于单播的情况，参与者可能使用相同端口对来收听其他所有参与者，也可能对来其他每个参与者使用不同的端口对来收听。
　　RTP会话间相互区别的特征，在于每个RTP会话都维护一个用于SSRC标识符的独立完整的空间。RTP会话所包含的参与者组，由能接收SSRC标识符的参与者组成，这些SSRC标识符由RTP（同步源或作用源）或RTCP中的任意参与者传递。例如，考虑下述情况，用单播UDP实现的三方会议，每方都用不同的端口对来收听其他两方。如果收到一方的数据，就只把RTCP反馈发送给那一方，则会议就相当于由三个单独的点到点RTP会话构成；如果收到一方的数据，却把RTCP反馈发送另两方，则会议就是由一个多方（multi-party)RTP会话构成。后者模拟了三方间进行IP多播通信时的行为。
　　RTP框架允许上述规定发生变化，但一个特定的控制协议或者应用程序在设计时常常对变化作出约束。
　　同步源(SSRC，Synchronization source)：RTP包流的源，用RTP报头中32位数值的SSRC标识符进行标识，使其不依赖于网络地址。一个同步源的所有包构成了相同计时和序列号空间的一部分，这样接收方就可以把一个同步源的包放在一起，来进行重放。举些同步源的例子，像来自同一信号源的包流的发送方，如麦克风、摄影机、RTP混频器（见下文）就是同步源。一个同步源可能随着时间变化而改变其数据格式，如音频编码。SSRC标识符是一个随机选取的值，它在特定的RTP会话中是全局唯一（globally unique）的（见章节8）。参与者并不需要在一个多媒体会议的所有RTP会话中，使用相同的SSRC标识符；SSRC标识符的绑定通过RTCP（见章节6.5.1）。如果参与者在一个RTP会话中生成了多个流，例如来自多个摄影机，则每个摄影机都必须标识成单独的同步源。
作用源（CSRC，Contributing source )：若一个RTP包流的源，对由RTP混频器生成的组合流起了作用，则它就是一个作用源。对特定包的生成起作用的源，其SSRC标识符组成的列表，被混频器插入到包的RTP报头中。这个列表叫做CSRC表。相关应用的例子如，在音频会议中，混频器向所有的说话人（talker)指出，谁的话语（speech)将被组合到即将发出的包中，即便所有的包都包含在同一个（混频器的）SSRC标识符中，也可让听者（接收者）可以清楚谁是当前说话人。 　
　　终端系统（End system)：一种应用程序，它产生发送出的RTP包中内容，或者使用接收到的RTP包中内容。在一个特定的RTP会话中，一个终端系统可以扮演一个或多个同步源角色，但通常是一个。
混频器（Mixer)：一种中间系统，它从一个或多个源中接收RTP包，可能改变其数据格式，再按某种方式把这些包组合成一个新的包，然后转发出去。由于多个输入源的计时一般不会同步，所以混频器会对各个流的计时作出调整，并为组合流生成一个新的计时。因此，混频器将被标识成它所产生所有数据包的同步源。
转换器（Translator)：一种中间系统，它转发RTP包而不改变各包的同步源标识符。转换器的例子如下：不作混频地转变编码的设备，把多播复制到单播的重复装置，以及防火墙里应用层次的过滤器。
监视器(Monitor)：一种应用程序，它接收RTP会话参与者所发送的RTCP包，特别是接收报告（reception report)，而且对当前服务质量进行评估，评估结果用于分配监视任务，故障诊断和长期统计。监视器常常被内建到参与会话的应用程序中，但也可以是一个的独立的应用程序——不参加会话、也不发送或接收RTP数据包（因为它们在不同的端口上）。这些被称作第三方监视器。还有一种情况也是可以接受的，第三方监视器只接收但不发送数据包，或者另外地算入到会话中。
　　非RTP途径（Non-RTP means)：为提供一个可用的服务，可能还需要其他的协议和机制。特别地，对多媒体会议来说，一个控制协议可以发布多播地址，发布加密密钥，协商所用的加密算法，以及为没有预定义负载类型值的格式，建立负载类型值和其所代表的负载格式之间的动态映射。其他协议的例子如下：会话初始化协议（SIRFC3261[13]），ITU推荐的H.323[14]，还有使用SDP(RFC2327[15])的应用程序，如RTSP(RFC 2326[16]). 对于简单的应用程序，电子邮件或者会议数据库也可能用到。对这些协议和机制的详细说明已经超出了本文档的讨论范围。

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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTP包头格式
　前12个字节出现在每个RTP包中，仅仅在被混合器插入时，才出现CSRC识别符列表。这些域有以下意义：
　版本(V)：2比特 此域定义了RTP的版本。此协议定义的版本是2。(值1被RTP草案版本使用，值0用在最初"vat"语音工具使用的协议中。)
　填充(P)：1比特 若填料比特被设置，则此包包含一到多个附加在末端的填充比特，填充比特不算作负载的一部分。填充的最后一个字节指明可以忽略多少个填充比特。填充可能用于某些具有固定长度的加密算法，或者用于在底层数据单元中传输多个RTP包。
　扩展(X)：1比特 若设置扩展比特，固定头(仅)后面跟随一个头扩展。
　CSRC计数(CC)：4比特 CSRC计数包含了跟在固定头后面CSRC识别符的数目。
　标志(M)：1比特 标志的解释由具体协议规定。它用来允许在比特流中标记重要的事件，如帧边界。
　负载类型(PT)：7比特 此域定义了负载的格式，由具体应用决定其解释。协议可以规定负载类型码和负载格式之间一个默认的匹配。其他的负载类型码可以通过非RTP方法动态定义。RTP发送端在任意给定时间发出一个单独的RTP负载类型；此域不用来复用不同的媒体流。
　 序列号（sequence number）：16比特 每发送一个RTP数据包，序列号加1，接收端可以据此检测丢包和重建包序列。序列号的初始值是随机的(不可预测)，以使即便在源本身不加密时(有时包要通过翻译器，它会这样做)，对加密算法泛知的普通文本攻击也会更加困难。
时间戳（timestamp） 32比特 时间戳反映了RTP数据包中第一个字节的采样时间。（采样时钟必须来源于一个及时的单调、线性递增时钟，以便允许同步和去除网络引起的数据包抖动（见章节6.4.1）。该时钟的分辨率必须满足理想的同步精度和测量数据包到来时的抖动的需要（一种典型的时钟分辨率不满足情况是每个视频帧仅一个时钟周期）时钟频率依赖于负载数据的格式，并在描述文件（profile）中或者是在负载格式描述中（payload format speci_cation）进行静态描述。也可以通过非RTP方法（non-RTP means）对负载格式动态描述。
如果RTP包是周期性产生的，那么将使用由采样时钟决定的名义上的采样时刻，而不是读取系统时间。例如，对一个固定速率的音频，采样时钟（时间戳时钟）将在每个周期内增加1。如果一个音频从输入设备中读取含有160个采样周期的块，那么对每个块，时间戳的值增加160，而不考虑该块是否用一个包传递或是被丢弃。
时间戳的初始值应当是随机的，就像序号一样。几个连续的RTP包如果（逻辑上）是同时产生的，如：属于同一个视频帧的RTP包，将有相同的序列号。如果数据并不是以它采样的顺序进行传输，那么连续的RTP包可以包含不是单调递增（或递减）的时间戳（RTP包的序列号仍然是单调变化的）。
不同媒体流的RTP时间戳可能以不同的速率增长。而且会有独立的随机偏移量。因此，虽然这些时间戳足以重构一个单独的流的时序，但直接比较不同的媒体流的时间戳不能有效的进行同步。对于每一个媒体，我们把与采样时刻相关联的RTP时间戳与来自于参考时钟上的时间戳（NTP）相关联（相反，对于每一种媒体，RTP时间戳通过与一个参考时间戳wallclock配对的方法来与采样时刻联系起来。）。参考时钟的时间戳表示了（对应于RTP时间戳的）数据的采样时刻。（即：RTP时间戳可用来实现不同媒体流的同步，NTP时间戳解决了RTP时间戳有随机偏移量的问题。）参考时钟用于同步所有媒体的共同时间（参考时间戳为所有媒体所公用，以此来实现同步）。这一时间戳对（RTP时间戳和NTP时间戳），用于判断RTP时间戳和NTP时间戳的对应关系，以进行媒体流的同步。它们不是在每一个数据包中都被发送，而在发送速率更低的RTCP的SR（发送者报告）中。即RTP时间戳记录当前是第几个采样数据，NTP时间戳记录当前数据包相对于参考时钟（1900年1月1日0点算起，当前时间相对于该时刻所经过的秒数）的绝对时间。
选取采样时间作为RTP时间戳的参考点是因为它可以被传输的终节点获知，而且对所有媒体内容有一个相同的定义，再者是它不受编码延迟或其它数据处理的约束。目的是为了对所有在同一时刻采样的媒体进行同步。
如果传输的数据是存贮好的，而不是实时采样等到的，那么会使用从参考时钟得到的虚的表示时间线（virtual presentation timeline虚拟表示时间表）以确定存贮数据中的每个媒体下一帧或下一个单元应该呈现的时间（还是时刻？？？）。此种情况下RTP时间戳反映了每一个单元应当回放的时间（时刻？？？）。这就是说，每个单元的RTP时间戳将会和参考时钟相关。真正的回放将由接收者决定。
一个描述了关于预先录制好的视频的现场音频旁白的例子说明了采用采样时间作为参考点的重要性。在这种情况下，视频会在本地提交给解说员观看，同时会通过RTP包向外界传输。通过RTP传输的一帧视频的“采样时刻”将会被建立，建立的方法是在该帧视频提交给解说员的时刻，将RTP包的时间戳与参考时钟比较算出而建立（即