[计算机设计论文]RTP数据传输协议译文

1、5. rtp数据传输协议5.1 rtp固定报头字段rtp报头具有以下格式：012301234567890123456789012345678901+|v=2|p|x| cc |m| pt|sequence number|+-+-+-+-+itimestamp|+synchronization source (ssrc) identifier+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ contributing source (csrc) identifiersi.i+每个rtp分组都包含前i 二个八位字节，而

2、csrc标识符列表只冇在被某个混和器插入后 才会被rtp分组包含。报头屮各个字段的含义如下：版本(v)： 2位该字段为rtp的版本标识。根据不同的值可以尬义2个不同的版本(rtp的首个草拟版本 置该值为“1”，而在“vat”音频工具最初履行的协议使用值“0”)。填充(p)： 1位如果设置了填充位，则分组的尾部包含一个或多个附加的填充字节，但是它不是有效载荷的 一部分。填充的最后一个字节是包含它白c在内的应被忽略的填充字节的数目。在某些固立 块大小的算法或在一较低层协议数据单元中传送rtp分组时会使用到填充。扩展(x):1位如果设置了扩展位，则固定报头的后而必须跟有一个具体的头扩展，其格式定义在

3、5.3.1节。赠送源标识符(csrc)数目(cc)：4位该字段记录固定头中csrc标识符的数目。标记(m) : 1位在概述屮对标记进行了解释，它允许垂人事件(如帧边界)在分组流屮被标记。在概述中还 可以尬义附加的标记位或更改有效载荷类型字段中的位数來标明无标记位(见5.3节)有效载荷类型(pt)：7位该字段用来标识rtp有效载荷的类型，而且根据应用确定其解释。一个概述可以具体化一 个从有效载荷码到模式的缺省静态映射。附加的有效载荷类型码可由非rtp方法动态地定 义(见第三节)。rfc35511包含了具体的音频、视频缺省映射集合。在对话期内rtp源可 以更改其有效载荷类型，但这个字段不能用于多路

4、转换分离媒体流(见5.2节)。接收端必须忽略那些有效载荷类型不可被识别的分组。序列号：16位対每个rtp数据发送其序列号的增量为1。接收端可利用序列号对分组缺失进行检测和重建 分组序列。序列号的初值应该是随机的（不可预见的），这样会使得对所知的简易文本的加 密处理更加困难，即使源根据9节中的方法也不能对其自身加密，因为分组会因翻译器使 然而流动。选择随机号的技术在17页屮讨论。时间标记：32位时间标记反映了 rtp数据分组首字节的即时抽样。及时抽样必须来源于一允许同步计算的 单调线性增氏的时钟（见641节）。时钟决议对于期望的同步精度和衡量分组到达来说必须 是充分的（每个视频帧一嘀哒是典型不充

5、分的）。时钟频率由以有效载荷方式传输的数据的 格式来决定，而h-时钟频率或者在概述、冇效载荷格式具体说明中被静态说明，或者为了由 非rtp方法定义的有效载荷格式而被动态地说明。如果rtp分组是周期性产生的，则使用 的是由抽样时钟得到的失真即时抽样，而不是读系统时钟。举一个例了，对固定比率音频来 说，每个抽样周期的时间标记时钟是逐一增氏的。如果音频从输入设备读入一覆盖了 160 个抽样周期的块，则不论是在分组中传输或者丢失，每个块的时间标记都会增长160。时间标记的初值和序列号一样都应该是随机的。如果一些连续的rtp分组在逻辑上（例如: 同属于一个视频帧）是同时产生的，则它们冇相等的时间标记。如

6、果数据不是按照取样的顺 序进行传输的，就像mpeg被插入到视频帧中去，则连续的rtp分组就可能会包含那些非 单调的时间标记（传输时分组的序列号仍然是单调的）。不同媒体流的rtp时间标记对能会以不同比率增长，而且通常会有独立的、随机的补偿。 因此，直接与那些为达到同步而非有效的时间标记相比，这些rtp时间标记对重建某一单 一流的时间来说是充分的。替代地，对于任一媒体rtp时间标记与即时取样相关，ii它与 一-参照时钟的时间标记配对。此参照吋钟表示的是应答rtp时问标记的数据被采样的时问。 参照时钟被所有媒体共亨以达到同步。时间标记对不是在每个数据分组中都会被传输，而是 在rtcp sr分组中以较

7、低的速率传输，具休描述于6.4节。即时抽样被当作rtp的时间标记参照点是因为它能被传输终端识别，而h对于所有的媒体 它冇一个独立于编码延迟或其他处理过程的通用定义。其i丨的是可以同时采样所冇媒体的同 步样本。存储了实时数据的传输应用一般使用的是来源于参照时钟时间的虚拟显示行从而决定显示 下一帧或者其它媒体单元的时问。在这种情况下，rtp时间标记反映的是每个单元的显示时 间。也就是说，每个单元的rtp时间标记将与该单元在虚拟显示行中变为当前状态的参照 时钟时间相关，而实际显示发主在由接收端决定的稍后时间。个用现场音频描述预先录制好的视频的例子揭示了即时抽样作为参照点的重要性。在这个 例子屮，所描

8、述的视频使用rtp进行传输的同时将局部地呈现给描述者。当视频帧呈现给 描述者时，它的在rtp中传输的即时抽样将根据参照时钟而建立。当对音频取样时，包含 了叙述者讲述内容的音频rtp分组的即时抽样将以相同的参照时钟时间为参照完成。当音 频和视频的参照时钟按照类似于ntp的方法同步时，他们甚至会以不同的方式传输，接收 端可以使音频和视频分组的显示同步，所采用的方法是用rtcpsr分组中的时间标记对音 频、视频的rtp时间标记联系起来。同步源标识符：32位同步源标识符字段用于同步源的识别。这个标识符应被随机地选择，原则是同一 rtp对话 期内的同步源不能有相同的ssrc标识符。产生一个随机标识符的示

9、例算法在附录a.6中给 出。尽管多个源选择同一标识符的可能性不人，所有的rtp工具需具备检测和解决冲突的 能力。第八节描述了冲突发生的可能性，同时还描述了解决冲突和在唯一的ssrc标识符基 础上检测rtp级新循环的方法。如果源更改了其传输地址，则它必须选择一个新的ssrc 标识符从而避免被解释成一个循环源（见8.2节）。赠送源标识符列表：015项，每项32位这个csrc列表用于标识包含在分组中的冇效载荷的赠送源。标识符序号由cc字段给出。 如果有15个以上的赠送源，则最多只能标识15个。csrc标识符市混和器使用赠送源的 ssrc标识符进行插入。（见7.1节）。例如，对于音频分组来说，由所冇源

10、混和而成的分组 的ssrc标识符被罗列出来，并在接收端允许正确的交谈者声明。52多路转换rtp对话对冇效的协议处理来说，多路转换点的数量应该是戢小的，具体描述见集成层处理设计原则 10。在rtp中，每个rtp对话的传输目的地址（网络地址和端口号）都是不同的，正是 这些传输目的地址形成了多路转换。例如，在编码分离的音频、视频电视会议中，任一个媒 体都应以各白的传输日的地址在rtp会话中传送。分离的音频流、视频流不应该在一单一 rtp会话中传送并且在有效载荷类型或ssrc字段 的基础上减少多路转换。添加不同的rtp媒体类型的空白分组而使用相同的ssrc会导致 出现以下问题：1. 如果两个音频流共享

11、同一个rtp会话和ssrc值，而且其中一个山于更改了编码而获得 了不同的rtp有效载荷类型，则没有一个通用的方法来识别是哪个流更改了编码。2. ssrc可以识别单一时标和序列号空间。如果媒体时钟比率不同则添加空白多路转换有 效载荷类型需要不同的计时空间，也需要不同的序列号空间来说明是哪种冇效载荷类型丢失 了分组。3rtcp接收端和发送端报文只能描述每个ssrc的一个时标和序列号空间，而且不存在 有效载荷类型字段。4. rtp混和器不能把不兼容的媒体流合并为一个流。5. 在一个rtp会话中传送多媒体会阻碍：对不同网络路径或合适的网络资源分配的使用； 接收媒体的子集，例如，当视频超过可用帯宽吋接收

12、其音频；対不同媒体使用分离处理步骤, 但使用分离rtp会话的接收端可使用单步或多步处理装直。使用不同的ssrc但是发送于同一个rtp会话将可以避免出现前三个问题，后两个问题却 无法避免。另一方面，rtp会话中同一媒体的多个多路转换相关源使用不同的ssrc值是多点传送会话 的规范。上述的问题不能应用在：举个例子，rtp混和器可将多个音频源合成，这一方法是 通用的。在后两个问题没有出现时，同一媒体多路转换流使用不同的ssrc值适用于其它情 况。5.3 rtp头的具体修改现存的rtp数据分组头对rtp支持的应用类的功能集合来说是完整的。但是，要与alf设 计原则相匹配，头需要做一些修改或增添。同时，

13、允许独立概述的监控器和记录工具发挥其 作用。标记位和有效载荷类型字段携带有特处概述信息，山于有多种应用需要用到它们，所有 在固定头种分配时可能会增加33位字长的空间。包含这些字段的字节也会根据需要被重新 定义，例如需要更多或更少的标记位。基于独立概述的监视器町以观察到分组丢失模式和标 记位z间的关联，所以标记位被置于字节最重要的位上。类似于视频编码这样的特殊有效载荷形式，需要有-些附加信息，而附加信息在分组的 有效载荷区域种传送，它应包含在有效载荷起始处的头内，或者在数据模式中以一保留值來 表示。如果一特殊的应用类需要独立于有效载荷模式的附加功能，协调应用操作的概述应定义 一-附加的固立字段，

14、这个字段是紧随在固立头的ssrc字段z后的。那些应用就可以快速而 直接地对附加字段进行存取。同时，独立概述监控器或记录器仍然可以以翻译前十二个字节 来对rtp分组进行处理。如果附加功能贯穿于所有的概述，则应定义一新的rtp版本以永久改变固定头。5.3.1 rtp头扩展扩展程序可以将个性化工具与新型的独立模式的有效载荷功能一起实验,该功能需要在rtp 数据分组头中传输附加信息。这个程序可使没有进行扩展的相互协作工作的工具忽略头扩 展。应当注意到这种头扩展只冇冇限的用途。更多潜在的用途将更好地以其它方式实现，这些方 式描述于前而的章节。例如，固定头的特定扩展是不值得去做的，因为它既是无条件的也不

15、处于可变地位。特殊的有效载荷模式所需的附加信息也不应使用这种头扩展，但它应在分组 的冇效载荷会话中传送。012301234567890123456789012345678901+-+-+-+-+-+-+idefined by profile|length|+header extension当rtp头内的x位为1时，rtp头必须附加一nj变长度的头扩展，在显示时这个头扩展应 在csrc列表之后。头扩展包含一长度为16位的字段来记录扩展中32位字的数量，并将 头扩展的前四个字节排除在外（因此0是一无效长度）。rtp数据头仅可附加单一扩展。要 允许多个协作的工具分别与不同的头扩展一起实验，或允许一特

16、殊工具与多于一种头扩展类 型实验，头扩展的前16位必须是公开的，以便区分标识符或者参数，这16位由控制工具操 作的规格说明来定义。这个rtp规格说明本身并不定义任何头扩展。11.rtp网络传输协议这节具体地描述了 rtp分组在特定网络中的传送和传输协议。下面的诸规则将一直适用， 直到它被其它的特定协议定义所取代。实时传输协议（rtp）依据基础的协议提供rtp数据的非多路转换以及实时（rtcp）控制 流。对udp和类似的协议來说，rtp应使川偶数作为目的端口号，而且rtcp应答流应使 用紧邻的较人的奇数作为口的端口号。对那些把单一端口号作为参数并且从端口号得到rtp 和rtcp端口值对的应用来说

17、，如杲端口号是一奇数，则被紧邻的较小的偶数值代替并将其 作为端口值对的基数。如果rtp和rtcp 0的端口号是显式给出的，且参数是分离的（使用 签名协议或其它方法），则端ii号的奇偶性和连续性等限制将被忽略，尽管对偶数（奇数） 端口值的使用仍被提倡。由于rtp是根据端口号对rtp数据和rtcp控制流进行多路转换 的，因此，rtp和rtcp的端口号必须是相同的。在单点传送的会话屮，接发双方都得能识別出端口值对以便接收rtp和rtcp分组。接发 双方可以使用相同的端口值对。接发双方z绝不能假定rtp和rtcp分组的输入源端口 可用于输出目的端口。当rtp数据分组是双向传送的，接发双方都得互和发送其

18、rtcp sr 分组到对方指定接收rtcp的端 o rtcpsr分组将输出数据的发送信息和输入数据的接收 报文信息捆绑在一起，当一方没有主动地发送数据（见6.4节）时，贝i发送rtcp sr分纟ft 代替之。分层编码应用应使用相邻的端口号集合。现有操作系统中存在的普遍缺陷限制了多个多点传 送地址使用同一个端口号的使用，所以端口号必须是明确的，且单一传送只允许有一个地址。 因此，对第11层来说，数据端口为p + 2n,控制端口为p+2n+lo当使用多点传送ip时， 地址也必须是明确的，因为多点传送路径和组成员在地址颗粒屮被管理。然而，多点传送的 ip地址的分配是不能预先设定的，因为一些组需要不同的范围，并且会可能因此从不同的 地址排列进行分配。前面的段落与sdp规格说明一rfc 232715有冲突。rfc 2327认为在同一会话描述中指定 具体的多个地址和多个端口是不合理的，其理由是地址和端口的关联是模糊的。在rfc 2327 的修订版本中将放宽这一约束，它允许使用1一1的值对指定相等的地址和端口。rtp数据分组包含有无长度字段或其它描述，