RTP: A Transport Protocol for Real-Time Applications——2

.  Byte Order, Alignment, and Time Format 

所有的整数字段都按网络字节序传输，即，最高字节(8位组)优先。这个字节序通常称为大端。传输顺序详情在

[]中说明。除了另外告知，否则数字常量都按十进制表示。

所有头部数据都与其自然长度对齐，即 16 位字段在偶数偏移量上对齐，32 位字段在偏移量可被 4 整除时对齐，

依此类推。指定为填充的八位字节的值为零。
挂钟时间(绝对时间)使用网络时间协议（NTP）的时间戳格式表示，以秒为单位，相对于 1900 年 1 月 1 日的

0h UTC [5]。完整格式的 NTP 时间戳是一个 64 位无符号定点数，整数部分在前 32 位，小数部分在最后 32 

位。在某些字段，更紧凑的表示形式更加适当，仅使用中间的32位;即整数部分的低 16 位和小数部分的高 16 位

。整数部分的高 16 位必须独立确定。

.  RTP Data Transfer Protocol

 RTP Fixed Header Fields 

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             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

前面12个字节固定出现在RTP包中，而CSRC标识符仅当混音器插入之后才会出现。   

version (V): 2 bits

这个字段表示RTP版本。本规范定义的版本是2。(1已经被RTP的第一个草稿版本所使用而0被vat音频工具的协议

初始实现所使用。)        

padding (P): 1 bit
如果padding位被设置，那么数据包尾部会包含一个或多个额外的字节，这部分不算入负载。负载的最后字节包含

多少个字节应该被忽略的计数。一些使用固定块数的加密算法或在低层次协议数据单元中传输几个RTP包可能需要

附加字节。

extension (X): 1 bit
如果被置位，则固定头部后面跟随一个头部扩展，5.3.1节定义了相关格式。        

CSRC count (CC): 4 bits
包含了固定头部后面的CSRC标识符个数。

marker (M): 1 bit
marker位的解析由一个profile定义。旨在允许有意义的事件，譬如在数据包流中标记帧边界。一个profile可以

定义额外的标记位，或通过改变负载类型字段的位数指定没有标记位(看5.3节)。意思应该是负载类型字段可以

占用标记位。

payload type (PT): 7 bits
这个字段标识了RTP有效负载的格式并决定了应用程序对它的解释。一个profile指定了有效负载类型代码到有效

负载格式的一个默认静态映射。其他有效负载类型可以通过非RTP的方案动态定义(看第3节)。音视频的默认映射

的一个初始集合在一个伴随profile Internet-Draft 中定义，可以在Assigned Numbers RFC

[]的未来版本中定义。一个RTP发送者在任何给定时间发送一个单一的RTP有效载荷类型；此字段不用于多路复用

单独的媒体流(看5.2节)。

我的理解是一个独立的RTP有效载荷可以有自己的有效载荷类型，譬如一个多媒体流中三个RTP包，三个包的有效

载荷类型都可以不同，视具体情况而定。

sequence number: 16 bits
序列号按照发送的每个RTP数据包逐个递增，可以被接收者用于探测丢包和恢复数据包顺序。初始序列号是随机

的(不可预测)，即使源本身不加密，也使得针对加密的明文的已知攻击更加困难，因为数据包可能会流经加密

的转换器。选择不可预测数字的技术在[7]中讨论。

timestamp: 32 bits
时间戳反映了RTP数据包中第一个字节的采样时刻。采样时刻必须从一个时钟推导出，且这个时钟的时间是单调

和线性增长的，以便允许同步和抖动计算 (see  )。时钟的分辨率必须满足同步所需的精度和数据包到

达的测量(一个视频帧一个tick一般是不满足的)。时钟频率取决于作为有效载荷携带的数据的格式，并在定义格式的

profile中或者有效载荷格式规范中静态指定，或者通过非RTP方法定义的有效载荷格式动态指定。如果RTP包是周期

性产生的，就使用采样时钟决定的最小采样时刻，不是读取系统时钟。作为一个例子，对于固定速率的音频，时间

戳时钟偏向于在每一个采样周期的基础上加1。如果一个音频应用从输入设备读取了覆盖160个采样周期的数据块，每

个此类块的时间戳将增加160，无论该块是在数据包中传输还是作为静默丢弃。

时间戳的初始值是随机的，因为序列号的初始值是随机的。如果若干个连续的RTP数据包逻辑上是同时产生的，那么他们

可能有相同的时间戳，例如，他们属于同个视频帧。如果若干个连续的数据包不是按采样顺序发送的，那么他们的

时间戳可以是非单调的，譬如MPEG插值视频帧。(传输时这些包的序列号还是单调的)。

SSRC: 32 bits

SSRC字段标识了同步源。这个标识符是随机选择的，目的在于同一个RTP会话中两个同步源不会使用同一个SSRC

标识符。 包含了一个用于产生随机标识符的示例算法。尽管多个源选择同一个标识符的可能性是

非常低的，但所有的RTP实现还是必须进行探测和解决冲突。  描述了冲突的可能性以及一种基于SSRC标识

符的唯一性用于解决冲突和探测RTP级别前转的机制。如果一个源改变了它的源传输地址，它必须也选择一个新的

SSRC标识符以避免被解析为循环的源。

CSRC list: 0 to 15 items, 32 bits each

CSRC列表描述了一个包的有效载荷包含的所有源。标识符的个数由CC字段给出。如果贡献源超出15个，那么仅能

标识15个。CSRC标识符由混音器插入，使用贡献源的SSRC标识符。例如，把多个音频包混合到一起形成一个包，所

有源的SSRC标识符将会被列出，以方便接收者纠正说话者的提示符。

 Multiplexing RTP Sessions 

为了实现高效的协议处理，应该尽量减少多路复用点的数量，如集成层处理设计原则[]中所描述的。在RTP中，

目标传输地址(网络地址和端口号)定义了一个RTP会话，提供了多路复用。例如，一个电话会议由音频和视频构成，

每种多媒体独立编码且在各自的RTP会话中传输，每个会话有自己的目标传输地址。不应在单个RTP会话中传输音频

和视频，并基于有效载荷类型或SSRC字段进行复用。交叉的数据包使用不同的有效载荷类型但使用同一个SSRC将会

引入如下问题：

1. 如果在一个会话中切换有效载荷类型，则没有常规的方法识别新的有效载荷类型是替换哪些旧的值。

2.定义SSRC是为了标识单个时序和序列号空间。如果媒体时钟速率不同，那么交替的多个负载类型将要求不同

的时序空间，以及要求不同的序列号空间以识别哪种有效载荷类型发生丢包。

3.RTCP发送者和接收者报告(see )仅能描述一个SSRC的一个时序和序列号空间且不传输有效载荷类

型。

这样的话肯定无法识别报告的是哪个有效载荷类型的。除非RTCP协议也要改。
4. RTP混音器无法把不兼容的交替的媒体流合并到一个流中。
5. 一个RTP会话中传输多种媒体会妨碍到如下功能的实现：使用不同网络路径或者需要时分配网络资源；如果希

望接收多媒体的一个子集合，例如如果视频超过可用带宽则仅接收音频；以及接收者实现是针对不同的多媒体使

用独立的处理过程，而使用独立的RTP会话允许单个的或者多个的处理实现。

每种媒体使用不同的SSRC但在同一个RTP会话中发送，能够避免前面3个问题但无法避免后面两个。

 Profile-Specific Modifications to the RTP Header 

目前已有的RTP数据包首部被认为是完整的，能够满足RTP可能支持的所有应用程序所要求的功能集。

然而，为了与ALF设计原则保持一致，可以通过修改或添加配置文件规范（a profile specification）中定义的首

部进行定制，同时仍然允许与配置文件无关的监视和记录工具运行。

	
	

		marker位和payload type字段携带特定profile信息，但他们是在固定首部分配的，因为大部分应用程序都需
	


要他们，否则可能需要另外分配32位字才能保存他们。存放这些字段的字节可能通过一个profile来重新定义以适应

不同的需求，例如更多或更少的标记位。如果有任何标记位，则其中一个应该位于八位字节的最高符号位，因为与

profile无关的监视器可能能够观察到包丢失模式和标记位之间的相关性。

	
	

		一个特定的负载类型格式，诸如视频编码，需要在数据包的载荷部分携带额外的信息。这可能在载荷部分开始
	


处 的一个首部中，或者通过数据模式中的保留值来提示。

	
	

		如果一个特定类别的应用需要与载荷格式无关的额外功能，那么这些应用所使用的profile应当定义额外的固定
	


首部，这些额外的首部紧跟着已有的固定首部的SSRC字段之后。这样这些应用能够快速直接访问额外的字段而与profile

无关的监视器或记录器仍然能够通过解释前面12个字节内容来处理RTP包。
如果开启的额外功能对于所有的profile都是需要的，那么应该定义一个新版本的RTP，使得对首部的改变是永久的。
如果事实证明所有配置文件都需要共同的其他功能，则应定义新版本的RTP以对固定首部进行永久更改。   

 RTP Header Extension 

提供了一种扩展机型以允许独立实现与有效负载格式无关的但需要通过RTP数据包首部传输额外信息的新功能。设计这种

机制是为了使得其他还没有被扩展的交互实现可以忽略这些扩展。

请注意，此标头扩展仅用于有限使用。此机制的大部分潜在应用最好使用其他方式实现，使用上一节描述的方法。例如，

对于固定首部的特定profile的扩展的处理成本是较低的，因为它不是有条件的其位置也不是可变的。需要额外信息的特定

有效载荷格式不应该使用这种首部扩展，而是要放在数据包的载荷部分中进行传输。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      defined by profile       |           length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        header extension                       |
   |                             ....                              |

如果RTP首部的X位被置为1，RTP首部后面将会附加可变长度的首部扩展，如果有CSRC列表的话则在CSRC列表之后。首部扩展

包含16位长度的字段，用于记录扩展中32位字的个数，除了4字节的扩展首部之外(因此0是合法的长度)。仅有一个扩展可以被

附加到RTP数据首部。为了允许多个互操作实现使用不同的标头扩展独立地进行每个实验，或者允许特定实现试验多种类型的

标头扩展，标头扩展的前 16 位将保持打开状态以区分标识符或参数。这16位的格式由实现所使用的profile定义。RTP规范不

定义自身的首部扩展。
 

 .  RTP Control Protocol -- RTCP

RTP 控制协议 （RTCP） 基于将控制数据包定期传输到会话中的所有参与者，使用与数据包相同的分发机制。底层协议必须提供

数据包和控制包的多路复用。譬如使用独立端口号的UDP。

RTCP执行4个功能：

	
	

		主要功能是提供数据分发质量的反馈。这是RTP作为传输协议角色的一个组成部分，并且与其他传输协议的流量和拥塞控制
	


功能有关。反馈对于自适应编码[,]可能有直接用处，但使用IP多播的实验已经表明在分发中获取接收者的反馈也是很关键的。发送

接收者反馈报告给所有参与者，允许正在观察问题的一方能够评估问题是本地的还是全局的。

使用诸如IP多播的分发机制，对于不属于一个会话的实体，譬如网络服务提供商，也是可以接收到反馈信息的，可以作为第三方监视器

诊断网络问题。这个反馈功能由发送者和接收者报告实现，在6.3节中描述。

	
	

		RTCP为一个RTP源传输一个持久的传输级别的标识符，称为canonical name or CNAME，请看6.4.1节。如果一个冲突发生或
	


一个程序重启，则SSRC标识符可能会改变，那接收者可以借助CNAME保持跟踪每个参与者。接收者也可以通过CNAME把来自一个给定

参与者的一个相关RTP会话集合里的多个数据流关联到一起，譬如同步音频和视频。

	
	

		前面两个功能要求所有的参与者发送RTCP包，前两个功能要求所有参与者发送 RTCP 数据包，因此必须控制速率，以便 RTP
	


扩展到大量参与者。通过让每个参与者将其控制数据包发送给所有其他参与者，每个人都可以独立观察参与者的数量。此数字用于

计算数据包的发送速率，如第 6.2 节所述。

	
	

		第四个可选功能是传达最小的会话控制信息，例如要在用户界面中显示的参与者标识。这在“松散控制”会话中最可能有用，
	


在这些会话中，参与者在没有成员资格控制或参数协商的情况下进入和离开。RTCP是一个方便的通道，可以到达所有参与者，但它

并不一定支持应用程序的所有控制通信要求。如果不能满足那么可能需要更高级别的绘画控制协议，这超出了本文档的范围。 当RTP应用在IP多播环境中功能1-3是必须的，在其他环境中是推荐的。建议RTP应用程序设计者避免使用仅能在单播模式下应用的机制，

不利于大规模扩展。