RTP协议学习笔记

1、定义

RTP payload - RTP 负载 ：

   通过 RTP 传输的包中的数据，例如，音频样本或压缩好的视频数据。

 

RTP packet - RTP 包 ：

   一种数据包，其组成部分有：一个固定 RTP 报头，一个可能为空的作用源（contributing sources）列表，以及负载数据。一些下层协议可能要求对 RTP 包的封装进行定义。一般地，下层协议的一个包包含一个 RTP 包，但若封装方法允许，也可包含数个 RTP 包

 

RTCP packet：

   一种控制包，其组成部分有：一个类似 RTP 包的固定报头，后跟一个结构化的部分，该部分具体元素依不同 RTCP 包的类型而定。一般地，多个 RTCP 包将在一个下层协议的包中以合成 RTCP 包的形式传输；这依靠 RTCP 包的固定报头中的长度字段来实现。

 

RTP media type ：

   一个 RTP 媒体类型是一个单独 RTP 会话所载有的负载类型的集合。RTP 配置文件把 RTP 媒体类型指派给 RTP 负载类型。

Multimedia session - 多媒体会话 ：

   在一个参与者公共组中，并发的 RTP 会话的集合。例如，一个视频会议（为多媒体会话）可能包含一个音频 RTP 会话和一个视频 RTP 会话。

 

SSRC-Synchronization source-同步源

   RTP 包流的源，用 RTP 报头中 32 位数值的 SSRC 标识符进行标识，使其不依赖于网络地址。一个同步源的所有包构成了相同计时和序列号空间的一部分，这样接收方就可以把一个同步源的包放在一起，来进行重放。举些同步源的例子，像来自同一信号源的包流的发送方，如麦克风、摄影机、RTP 混频器就是同步源。一个同步源可能随着时间变化而改变其数据格式，如音频编码。SSRC 标识符是一个随机选取的值，它在特定的 RTP 会话中是全局唯一（globally unique ）的参与者并不需要在一个多媒体会议的所有 RTP 会话中，使用相同的 SSRC 标识符；SSRC 标识符的绑定通过 RTCP。如果参与者在一个 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数据包（因为它们在不同的端口上）。这些被称作第三方监视器。还有一种情况也是可以接受的，第三方监视器只接收但不发送数据包，或者另外地算入到会话中。

 

Non-RTP means - 非 RTP 途径 ：

   为提供一个可用的服务，可能还需要其他的协议和机制。特别地，对多媒体会议来说，一个控制协议可以发布多播地址，发布加密密钥，协商所用的加密算法，以及为没有预定义负载类型值的格式，建立负载类型值和其所代表的负载格式之间的动态映射。其他协议的例子如下：会话初始化协议（SIRFC3261[13] ）， ITU 推荐的 H.323[14]，还有使用 SDP(RFC2327[15])的应用程序，如 RTSP(RFC 2326[16]). 对于简单的应用程序，电子邮件或者会议数据库也可能用到。

 

2、RTP数据传输协议

2.1、RTP HEADER

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

V-Version-版本 

   2 bit 此域定义了 RTP 的版本。此协议定义的版本是 2。(值 1 被 RTP 草案版本使用，值 0用在最初"vat"语音工具使用的协议中。)

 

P-Padding-填充

   1bit 若填料比特被设置，则此包包含一到多个附加在末端的填充比特，填充比特不算作负载的一部分。填充的最后一个字节指明可以忽略多少个填充比特。填充可能用于某些具有固定长度的加密算法，或者用于在底层数据单元中传输多个 RTP 包。若置1，在packet末尾被填充，填充优势是方便一些针对固定长度的封装。

 

X - extension - 扩展

   1 bit 如果置一，在RTP HEADER会跟着一个header extension

 

CC - CSRC count 

   4 bit CSRC计数包含了跟在固定头后面 CSRC 识别符的数目

 

M - marker

   1 bit 标志的解释由具体协议规定。它用来允许在比特流中标记重要的事件，如帧边界。会在一个profile里面

 

PT - playload type 

   7 bit 此域定义了负载的格式，由具体应用决定其解释。协议可以规定负载类型码和负载格式之间一个默认的匹配。其他的负载类型码可以通过非 RTP 方法动态定义。RTP 发送端在任意给定时间发出一个单独的 RTP 负载类型；此域不用来复用不同的媒体流。

 

sequence number - 序列号：

   16bit 每发送一个 RTP 数据包，序列号加 1，接收端可以据此检测丢包和重建包序列。序列号的初始值是随机的(不可预测)，以使即便在源本身不加密时(有时包要通过翻译器 ，它会这样做)，对加密算法泛知的普通文本攻击也会更加困难。

 

timestamp - 时间戳

   32bit 时间戳反映了 RTP 数据包中第一个字节的采样时间。时钟频率依赖于负载数据格式，并在描述文件（profile）中进行描述。也可以通过 RTP 方法对负载格式动态描述。

 

SSRC ：

   32 bit 同步源的ID,用以识别同步源。标识符被随机生成，以使在同一个 RTP 会话期中没有任何两个同步源有相同的SSRC识别符。尽管多个源选择同一个SSRC识别符的概率很低，所有 RTP 实现工具都必须准备检测和解决冲突。若一个源改变本身的源传输地址，必须选择新的SSRC识别符，以避免被当作一个环路源。

CSRC ：

   0~15项，每项32bit  CSRC列表识别在此包中负载的所有贡献源。识别符的数目在CC域中给定。若有贡献源多于 15 个，仅识别 15 个。CSRC识别符由混合器插入，并列出所有贡献源的SSRC识别符。例如语音包，混合产生新包的所有源的SSRC标识符都被列出，以在接收端处正确指示参与者。

 

 

 

 

 

 

 

 

 

 

 

附录：

时间戳

如果 RTP 包是周期性产生的，那么将使用由采样时钟决定的名义上的采样时刻，而不是读取系统时间。例如，对一个固定速率的音频，采样时钟将在每个周期内增加 1。如果一个音频从输入设备中读取含有 160个采样周期的块，那么对每个块，时间戳的值增加 160。时间戳的初始值应当是随机的，就像序号一样。几个连续的 RTP 包如果是同时产生的。如：属于同一个视频帧的 RTP 包，将有相同的序列号。不同媒体流的 RTP 时间戳可能以不同的速率增长。而且会有独立的随机偏移量。因此，虽然这些时间戳足以重构一个单独的流的时间，但直接比较不同的媒体流的时间戳不能进行同步。对于每一个媒体，我们把与采样时刻相关联的 RTP 时间戳与来自于参考时钟上的时间戳（ NTP）相关联。因此参考时钟的时间戳就了数据的采样时间。 （即：RTP 时间戳可用来实现不同媒体流的同步，NTP 时间戳解决了 RTP 时间戳有随机偏移量的问题。 ）参考时钟用于同步所有媒体的共同时间。这一时间戳对（RTP 时间戳和 NTP 时间戳） ，用于判断RTP 时间戳和 NTP 时间戳的对应关系，以进行媒体流的同步。它们不是在每一个数据包中都被发送，而在发送速率更低的 RTCP 的 SR（发送者报告）中。如果传输的数据是存贮好的，而不是实时采样等到的，那么会使用从参考时钟得到的虚的表示时间线（virtual presentation timeline） 。以确定存贮数据中的每个媒体下一帧或下一个单元应该呈现的时间。此种情况下 RTP 时间戳反映了每一个单元应当回放的时间。真正的回放将由接收者决定。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

复制去Google翻译 翻译结果