RTP和RTCP详解

1 RTP和RTCP详解

1.1 概述

在流媒体相关的领域，我们进场会看到RTP/RTCP，其用于流式传输的最常见的码流传输协议，位于传输层之上，控制流媒体码流传输。RTP（Real-time Transport Protocol）实时传输协议，用来为IP网上的语音、图像、元数据等多种需要实时传输的多媒体数据提供端到端的实时传输服务，它是由IETF的多媒体传输工作小组提出的一个标准，对应的RFC文档为RFC3550，其中根据RTP负载的不同，衍生出其他RTP相关规范，比如：

• RTP+FU-A(IETF RFC3984)
• RTP+PS(ISO/IEC 13818-1:2000)
• RTP+TS(ISO/IEC－13818)

RTP经常与RTCP成对使用，广泛应用于流媒体相关的通讯和娱乐，包括电话、视频会议、电视和基于网络的一键通业务。
RTCP（Realtime Transport Control Protocol）实时传输控制协议，实现服务质量的监视与反馈、媒体间的同步，以及多播组中成员的标识，其协议规范在IETF RFC3550中定义。

RTP/RTCP协议体系结构图如下：

RTP/RTCP被划分在传输层，它建立在UDP/TCP上，同UDP协议一样，为了实现其实时传输功能，RTP也有固定的封装形式，RTP用来为端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP来提供。

1.2 RTP协议详解

RTP协议格式如下图所示：

• Version (V): RTP版本,长度为2比特，默认版本为2
• Padding §: 填充位,长度为1比特，如果P被置位，在结尾处包含有一个或多个附加的填充字节，这些填充字节不是有效负荷的一部分,填充是一些需要固定块大小的加密算法所要求的，或是为了在低层PDU搬运RTP包。如果P=1，payload最后一位表示填充字节长度，负载数据需要去掉其尾部的填充字节。
• Extension (X): 扩展头标志位，长度为1比特，如果被置位，固定的头后面紧跟了一个头的扩展
• CSRC count (CC): 这个域长度为4比特。这个域表示了跟在固定头后面的CSRC标识符的数目，这个域只有在通过一个混合器才有非零值。
• Marker bit (M): 这个域长度为1比特，如果M被置位，表示一些重要的项目如帧边界在包中被标记。例如，如果包中有几个比特的当前帧，连同前一帧，那么RTP的这一位就被置位。一般非分片的RTP打包模式都置位为1，如果时分片的打包模式，数据包最后一个分片置为1，其他分片为0
• Payload type (PT) （有效负荷类型）: 这个域长度为7比特，PT指示的是有RTP包中的有效负荷的类型，RTP音频视频简介(AVP)包含了一个默认的有效负荷类型码到有效负荷格式的映射，参考https://blog.csdn.net/sudaning/article/details/64127282
  一般未定义的pt，由厂家自定义。
• Sequence number（序列号）：长度为16个比特，每送一个RTP包数目就增加一，初始值被设为一个随机数，接收方不仅可以用这个序列号检测包丢失，也可以重组包序列。
• Time stamp（时间戳）: 这个域长度为32个比特，时间戳反映了RTP数据包的头一个字节的采样时刻， 采样时刻必须是由一个单调线性增加的时钟产生，这样做是为了接收方的同步和 抖动计算，初始值可以从0开始，例如，如果RTP源使用了一个编码器， 缓冲20ms的音频数据，那么RTP时间戳必须每个包增加160，无论包是被传递了还是被丢失了。
• SSRC: 同步信源标识符，这个域长度为32比特，这个域表示了正在为会话产生RTP包的源。这个标识符是随机选中的，目的是为了避免同一个RTP会话中两个源有相同的标识符。
• CSRC list:特约信源标识符，这个列表标识了在这个包中对有效负荷起作用的所有源，标识符的最大数目限定为15，这是由CC域所限定的（全零在CC域中是被禁止的），如果有超过15个的分配源，只有前15个被标识。

如果扩展标志X被置位则说明紧跟在报头后面是一个头扩展，其格式如下：

[2字节defined by profile ][2字节长度][头扩展]
RTP 提供扩展机制以允许实现个性化:某些新的与负载格式独立的功能要求的附加信息在RTP 数据包头中传输，设计此方法可以使其它没有扩展的交互忽略此头扩展。在解封装时，如果不需要关注RTP扩展头，只需要根据长度跳过即可，这里要注意扩展头长度是扩展项中 32 比特字的个数，不包括 4 个字节扩展头，因此计算时需要跳过4+length*4

抓包实例如下：

80 60 95 1c c6 5a ec fa 3c c5 fa f7 62 01 13 d1
...

• 0x80=10000000B: 根据上文可知，V=10=2；P=0;X=0;CC=0000=0;
• 0x60=01100000: M=0;标识分片数据不是最后一个分片；PT=1100000=96
• 0x951C: 2个字节标识序列号，值为38172
• 0xc65aecfa: 4个字节表示时间戳，值为：3327847674
• 0x3cc5faf7: 4个字节为SSRC

由于X=0,因此无RTP头扩展，后面跟的是负责数据，由于P=0，所以无填充为，直接去掉12字节头，即是流媒体数据，流媒体数据根据RTP封装方式的不通，可能存在分片，需要根据规则组合形成原始帧数据，可参考：
H264码流RTP封装方式详解
H265码流RTP封装方式详解

1.3 RTCP协议详解

在RTP传输过程中，客户端和服务器都需要周期性地传送RTCP包，RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，早期为了节省传输过程中的耗时，RTP一般通过UDP方式传输，其可能存在丢包、数据不同步等问题，需要通过RTCP包进行相互监控，根据RTCP重发或者修正操作，当前由于网络传输及极其性能的飞跃发展，网传稳定性大大提升，RTCP作用越来越小，因此很多时候RTCP只被用来作为心跳使用，有些视频对接协议规范中，甚至去掉了RTCP,不过标准的RTSP传输中，必须RTP/RTCP一起完成码流传输。
RTCP协议有5种包类型，如下表所示：

此五种封包类型都比较类似，实时流种常用的为SR和RR，下面只讲述SR包类型机型介绍，其它类型请参考RFC3550。
发送端报告分组SR（Sender Report）:用来使发送端向所有接收端报告发送情况,其协议格式如下：

• 版本（V）：同RTP包头域
• 填充（P）：同RTP包头域
• 接收报告计数器（RC）：5bits，该SR包中的接收报告块的数目，可以为0
• 包类型（PT）：8bits，SR包是200
• 长度域（Length）：16bits，其中存放的是该SR包以32比特为单位的总长度减一
• 同步源（SSRC）：SR包发送者的同步源标识符。与对应RTP包中的SSRC一样
• NTP Timestamp（Network time protocol）SR包发送时的绝对时间值,NTP的作用是同步不同的RTP媒体流
• RTP Timestamp：与NTP时间戳对应，与RTP数据包中的RTP时间戳具有相同的单位和随机初始值
• Sender’s packet count：从开始发送包到产生这个SR包这段时间里，发送者发送的RTP数据包的总数. SSRC改变时，这个域清零
• Sender`s octet count：从开始发送包到产生这个SR包这段时间里，发送者发送的净荷数据的总字节数（不包括头部和填充）,发送者改变其SSRC时，这个域要清零
• 同步源n的SSRC标识符：该报告块中包含的是从该源接收到的包的统计信息
• 丢失率（Fraction Lost）：表明从上一个SR或RR包发出以来从同步源n(SSRC_n)来的RTP数据包的丢失率
• 累计的包丢失数目：从开始接收到SSRC_n的包到发送SR,从SSRC_n传过来的RTP数据包的丢失总数
• 收到的扩展最大序列号：从SSRC_n收到的RTP数据包中最大的序列号，
• 接收抖动（Interarrival jitter）：RTP数据包接受时间的统计方差估计
• 上次SR时间戳（Last SR,LSR）：取最近从SSRC_n收到的SR包中的NTP时间戳的中间32比特。如果目前还没收到SR包，则该域清零。
• 上次SR以来的延时（Delay since last SR,DLSR）：上次从SSRC_n收到SR包到发送本报告的延时。

抓包实例：

80 c8 00 06 4a 9b 57 b3 d6 5d 72 c6 a1 0b d8 7b
8c e2 d1 4e 00 5f 3c 30 db 4d 5b 97

• 0x80=10000000：V=10=2；P=0;RC=0
• 0xC8: 1bytes,PT=200表示发送端报告
• 0x0006: 2bytes,长度域为6，表示长度为7*4=28字节
• 0x4a9b57b3: 4bytes表示发送端流的SSRC
• 0xd65d72c6a10bd87b：8bytes表示NTP时间戳
• 0x8ce2d14e: 4bytes，RTP时间戳
• 0x005f3c30: 4bytes,发送端包数量
• 0xdb4d5b97: 4bytes,发送端发送的净荷数据的总字节数

wireshark分析结果：

RR分组类型格式如下，与SR类似，这里就不做详细介绍

抓包实例：

81 c9 00 07 9d 02 06 5e 3c c5 fa f7 00 ff ff ff
00 01 9e 4e 00 00 00 f0 00 00 00 00 00 00 00 00

wireshark分析结果：

一般媒体流提供方发送SR，接收方放松RR，当前大部分厂家已经不在严格校验RTCP，因此很多时候都不发送RTCP，如果在码流对接过程中发现对方无故关闭码流，可以查看下是否发送RTCP。