RTP-实时协议

RTP，实时协议被用来为应用程序如音频，视频等的实时数据的传输提供端到端（end to end）的网络传输功能。传输的模型可以是单点传送或是多点传送。数据传输被一个姐妹协议——实时控制协议（RTCP）来监控，后者允许在一个大的多点传送网络上监视数据传送，并且提供最小限度的控制和识别功能。

RTP是被IETF在RFC1889中提出来的。顺带提及，RTP已经被接受为实时多媒体传送的通用标准。ITU-T跟IETF都在各自的系统中将这一协议标准化。

1.1 为何需要RTP?

TCP不能支持像交互视频，会议等的实时服务，这一原因是由于TCP只是一个“慢”协议，需要三次握手。就此在IP层上UDP是一个比TCP更好的选择。但是UDP是本质上是一个不可靠协议，不支持在包丢情况下的重传机制。诚然，UDP有一些特性，比如多路复用跟校验和服务，这些都是对实时服务很有利的。为了消除UDP的缺点，RTP是作为应用层而被提出来的。

RTP提供的各种服务包括有效负载识别，序列编号，时间戳和投递监听。RTP能够序列化包，当这些包在收端不是按顺序到达的时。序列号也能被用来识别包丢失。时间戳被用于媒体有效的播放。到达的数据一直被RTCP监听，以通知RTP层来校正其编码和传输的参数。例如，如果RTCP层检测到包丢失，它会通知RTP层减缓发送速率。

尽管RTP有助于实时媒体的有效的播放 ，但是要注意的是RTP自身并不提供任何机制来确保及时传递或提供其他服务质量（QoS）的保证，而是依靠低层服务来完成这些。同样，RTP也不保证投递或防止无序投递。RTP被设计出来主要是为了满足有多个参加者的多媒体会议的需要。RTP也同样适合于象持续数据的储存，分布式交互仿真，主动标记以及应用程序的控制和测量。

1.2 RTP特性一览

RTP提供有效负荷类型识别，乱序重排和利用时间戳的媒体有效播放。

RTCP监控服务质量，也提供在一个当前进行的会话中传送关于参加者的信息作用。

RTP对于下层协议是独立的，它能够工作在像TCP/IP，ATM，帧时延等类型的网络上。

如果被下层网络支持，RTP支持利用多路技术的对于多点的数据传输。

RTP序列号也能被用来确定包的合适位置。例如在视频解码，包无需按序解码。 

2.0 技术概览

2.1 RTP

RTP头具有如下的格式。开始的12个八位字节在每一个RTP包中都会出现；而CSRC标识符列表只在通过混合器的包中出现。这些域含有以下意义：

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 |

| .... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version (V) （版本号）: 这个域长度为2比特，标出了RTP的最近版本。当前的版本为2.0

Padding (P) （填充）: 这个域长度为1比特，如果P被置位，包在结尾处包含有一个或多个附加的填充字节，这些填充字节不是有效负荷的一部分。填充是一些需要固定块大小的加密算法所要求的，或是为了在低层PDU搬运RTP包。

Extension (X): 这个域长度为1比特，如果被置位，固定的头后面紧跟了一个头的扩展。

CSRC count (CC): 这个域长度为4比特。这个域表示了跟在固定头后面的CSRC标识符的数目。 如前所述，这个域只有在通过一个混合器才有非零值。

Marker bit (M): 这个域长度为1比特，如果M被置位，表示一些重要的项目如帧边界在包中被标记。例如，如果包中有几个比特的当前帧，连同前一帧，那么RTP的这一位就被置位。

Payload type (PT) （有效负荷类型）: 这个域长度为7比特，PT指示的是有RTP包中的有效负荷的类型。RTP音频视频简介(AVP)包含了一个默认的有效负荷类型码到有效负荷格式的映射。附加的有效负荷类型可以向IANA注册。

Sequence number（序列号）： 这个域长度为16个比特，每送一个RTP包数目就增加一，初始值被设为一个随机数。接收方不仅可以用这个序列号检测包丢失，也可以重组包序列。

Time stamp（时间戳）: 这个域长度为32个比特，时间戳反映了RTP数据包的头一个字节的采样时刻。 采样时刻必须是由一个单调线性增加的时钟产生，这样做是为了接收方的同步和抖动计算。初始值必须为随机数，这是为了避免对原码的攻击。例如，如果RTP源使用了一个编码器， 缓冲20ms的音频数据，那么RTP时间戳必须每个包增加160，无论包是被传递了还是被丢失了。

SSRC: 这个域长度为32比特，这个域表示了正在为会话产生RTP包的源。这个标识符是随机选中的，目的是为了避免同一个RTP会话中两个源有相同的标识符。

CSRC list: 这个列表标识了在这个包中对有效负荷起作用的所有源。标识符的最大数目限定为15，这是由CC域所限定的（全零在CC域中是被禁止的）。如果有超过15个的分配源，只有前15个被标识。

仔细观察RTP可以注意到它不像更低层的协议比如PDU一样，包含一个“定边界”的域。 这一原因是RTP的有效负荷是跟IP的有效负荷相同，因此也就不需要了。

如果相同的用户在一个会话中使用多个媒体，比如说视频跟音频，每个媒体都会打开单独的RTP会话。因此在RTP层面上不存在多路复用。多路复用由更低层来决定。但是RTCP保留了一个叫CNAME的标识符，这个标识符对于由同一用户初始化的媒体是相同的。因此CNAME是在RTP层面上能识别从一个用户产生的不同媒体的唯一的标识符。

从上可以看出，RTP头的开销是相当大的，为了减少这一开销，RTP头压缩被提了出来。

2.2 RTCP

RTP接收者利用RTCP报告包，提供接收质量的反馈。这个报告包可以是发送者类型也可以是接收者类型。如果接收者主动参加到一个会话中，那么它就送SR（sender report），否则它将送RR（receiver report）。除SR跟RR包以外，RTCP还有其他的包类型：SDES （Source Description）, BYE 和APP（Application defined）,RTCP和SDES包的有效负荷类型值在表1和表2中相应给出。

PACKET TYPE                                               Payload Type

SR (发送者报告)                                                    200

RR (接收者报告)                                                    201

SDES (源描述)                                                       202

BYE                                                                203

APP (应用程序定义)                                               204

RTCP SDES ITEM                                            Value

END (SDES列表结尾)                                           0

CNAME (规范名)                                                   1

NAME (用户名)                                                     2

EMAIL                                                                   3

PHONE                                                                  4

LOC                                                                      5

TOOL                                                                   6

NOTE                                                                   7

PRIV                                                                     8

 

2.2.1 RTCP SR 包

RTCP发送者报告包在图2中显示，各域含有下列意义。

Version (V): 与RTP中同

Padding (P): 与RTP中同

Reception report count (RC): 该域长度为5比特，RC表示接收报告块的大小。

Packet type (PT): 该域长度8比特，SR报告包的包类型是200。

SSRC: 与RTP中同

NTP Time stamp: 该域长度64比特，NTP表示了该包发送时的最大执行时间 (wall clock time)，这个信息是被用来测量链路网络（round-trip）传播延时。

RTP Time stamp: 与RTP中同，这些时间戳被用于媒体内／外的同步。

Sender’s packet count: 该域长度为32比特，该域指示了从会话开始直到本SR被发送过程中发送者发出的RTP数据包的数目。

Sender’s octet count: 该域长度为32比特，表示从会话开始发送的有效负荷字节的总数目。

SSRC_n (源标识符): 该域长度为32比特，用于标识在此次阻塞报告中信息源

Fraction lost: 自前一个SR或RR包发送后丢失的RTP包的份额。

Cumulative number of packet lost: 该域长度为24比特，表示从会话开始，丢失的RTP数据包的总数目。

Extended highest sequence number received: 该域长度32比特，低16位包含从SSRC_n收到的RTP包中的最高序列号，最高16位用于扩展相应的序列号的循环周期的计数值。

值得注意的是在同一会话的不同接收这来说，如果他们的起始时间差别比较大的话，接收者将产生不同的扩展位。

Inter-arrival jitter: 该域长度32比特，表示了以时间戳为单位估计的RTP数据包到达时间的统计方差，用无符号的整数表示。

Last SR timestamp: 该域长度32比特，它把收到的NTP时间戳64位中间的32位作为最近的RTCP SR的一部分。

Delay since last SR (DLSR): 该域长度为32比特，延迟的单位是65536分之1秒，表示最近的SR包和本RR包之间的时间。  

2.2.2 RTCP RR 包

RR包的结构与SR包相同，只是它没有包含发送者相关项（NTP, RTP 时间戳， 包数目跟字节数目）。 只有被动参加者才发RR包。

2.2.3 RTCP SDES 包

SDES包在图3中给出，不同类型的源描述包如下列出:

CNAME： 这是规范终端标识符。CNAME在SDES包中是必须出现的项目，其余的都是可选的。CNAME可以被接收者用来识别同一个特定用户产生的不同的媒体流。

其他被支持的SDES项是NAME, EMAIL,PHONE, LOC, TOOL, NOTE 和 PRIV

涉及到大量的参加者时，在一个会话过程中有可能RTCP的流量超过RTP的流量，这是由于，在时间的任何一个点上，只有一个人在说而其他的人都在听。为了减少RTCP的流量，RTCP的包传输率，作为参加者数目，RTCP包大小，RTCP带宽等的一个函数做动态变化。根据标准，会话带宽的20％分配给RTCP并且RTCP带宽的5％分配给CNAME。换句话说，每发送五个RTP包才发送一个RTCP的RR跟SR包。对于小型会话（参加者数目比较小），每5秒中会有一个RTCP的传输，每隔15秒钟，一个附加项会被包括在SDES包中。

2.2.4 RTCP BYE 包

RTCP BYE包在RTP会话的结尾被送出，包的结构如图4所示：

2.2.5 RTCP APP 包

APP包是为了新的应用程序和新的特性的实验用途，其结构如图5所示

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| subtype | PT=APP=204 | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC/CSRC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name (ASCII) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| application-dependent data ...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.0 SIP中的RTP

IETF已经提议会话初始协议（SIP）作为因特网上多媒体调用的建立，修改和终结。RTP/RTCP被媒体用来作为在他们系统中传输的协议。SIP的流图结构如图6所示

4.0 H.323中的RTP

ITU-T已经提出了H.323，这是另一个著名的多媒体通信系统。RTP/RTCP再次被用作媒体传输。H.323的流图结构在图7中给出。

5.0 结论

RTP是应用层级别的协议，它提供了在单点传送或多点传送基础上，适合媒体传输如视频，音频，仿真数据等实时数据的，端到端的网络传输功能。RTP以序列化，有效负载识别和媒体实时播放为目标。数据传输增加了一个控制协议RTCP，这个协议监听了数据传送并且提供了最小限度的控制和识别功能。RTP和RTCP被设计成独立于下层网络传输网络，并且不提供源保留，也不保证实时服务的服务质量（QoS）。

RTP 术语表

RTP 有效负载： 在一个RTP包中被传输的数据。例如，音频样本或压缩视频数据。

RTP 媒体类型： RTP 媒体类型是有效负载类型的一个集合，这个集合在单一的RTP会话中被运载。有效负载类型是在音频视频协议（AVP）中被定义的【RFC 1890】。

RTP 会话：在一个使用RTP进行通讯的参加者集合中的联络。

Synchronizing source（SSRC）：RTP包的源，由在RTP头中的一个32位数值SSRC标识符来表示。为了跟网络地址区别开来。

Contributing source (CSRC)：RTP包的一个流的源，这个源是通过一个RTP混合器来产生一个混合的新流。

Mixer： 一个媒体间系统，它从一个或多个源发出的RTP包中提取内容，并把它们通过某种方式混合，然后从一个新的RTP包中送出。在此过程中数据格式可能被改变。

Translator： 一个媒体间系统，它把RTP包向前传送，并不改变它们的synchronizing source。Translator的例子包括编码转换而不混合的设备，从多点传送到单一传送的复制器，还有防火墙中应用级别的过滤器。

Monitor： 一个应用程序，它接收在一个RTP会话中参加者送出的RTCP包，并为分配监听，故障诊断，和长期统计估计当前的服务质量。

Non-RTP means：除了RTP以外，为了提供一个可用的服务的协议和机制。例如，在媒体传输之前需要发信号，这在SIP或H.323中被提出来。