RTSP网络串流

本文主要是介绍RTSP网络串流，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一.文档简介

1.1.文档目的

本文档主要介绍拉取RTSP网络串流时需要解析的协议。

二.RTSP协议

2.1.简介

百度百科：

RTSP（Real Time Streaming Protocol），RFC2326，实时流传输协议，是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。

HTTP与RTSP相比：

1.RTSP引入了几种新的方法，比如DESCRIBE、PLAY、SETUP 等，并且有不同的协议标识符，RTSP为rtsp 1.0,HTTP为http 1.1；
2.HTTP是无状态的协议，而RTSP为每个会话保持状态；
3.RTSP协议的客户端和服务器端都可以发送Request请求，而在HTTP协议中，只有客户端能发送Request请求。
4.在RTSP协议中，载荷数据一般是通过带外方式来传送的(除了交织的情况)，及通过RTP协议在不同的通道中来传送载荷数据。而HTTP协议的载荷数据都是通过带内方式传送的，比如请求的网页数据是在回应的消息体中携带的。
5.使用ISO10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化；
6.RTSP使用URI请求时包含绝对URI。而由于历史原因造成的向后兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的标题域中；

RTSP是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，更进而支持多方视讯会议（Video
Conference）。因为与HTTP1.1的运作方式相似，所以代理服务器〈Proxy〉的快取功能〈Cache〉也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。

2.2.RTSP协议主要指令

一次基本的RTSP操作过程：

1. 首先，客户端连接到流服务器并发送一个RTSP描述命令（DESCRIBE）。流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。
2. 客户端再分析该SDP描述，并为会话中的每一个流发送一个RTSP建立命令(SETUP)，RTSP建立命令告诉服务器客户端用于接收媒体数据的端口。流媒体连接建立完成后，
3. 客户端发送一个播放命令(PLAY)，服务器就开始在UDP上传送媒体流（RTP包）到客户端。在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。
4. 最后，客户端可发送一个终止命令(TERADOWN)来结束流媒体会话

2.2.1.OPTIONS

用于得到服务器提供的可用方法。

2.2.2.DESCRIBE

客户端向服务器端发送DESCRIBE，用于得到URI所指定的媒体描述信息，一般是SDP信息。客户端通过Accept头指定客户端可以接受的媒体述信息类型。

媒体初始化是任何基于RTSP系统的必要条件，但RTSP规范并没有规定它必须通过DESCRIBE方法完成。RTSP客户端可以通过以下方法来接收媒体描述信息：

1.通过DESCRIBE方法；
2.其它一些协议（HTTP，email附件，等）；
3.通过命令行或标准输入设备

2.2.3.SETUP

用于确定转输机制，建立RTSP会话。客户端能够发出一个SETUP请求为正在播放的媒体流改变传输参数，服务器可能同意这些参数的改变。若是不同意，它必须响应错误"455 Method Not Valid In This State"。
Request中的Transport头字段指定了客户端可接受的数据传输参数；Response中的Transport头字段包含了由服务器选出的传输参数。

2.2.4.PLAY

PLAY方法告知服务器通过SETUP中指定的机制开始发送数据 。在尚未收到SETUP请求的成功应答之前，客户端不可以发出PLAY请求。
PLAY请求将正常播放时间（normal play time）定位到指定范围的起始处，并且传输数据流直到播放范围结束。PLAY请求可能被管道化（pipelined），即放入队列中（queued）；服务器必须将PLAY请求放到队列中有序执行。也就是说，后一个PLAY请求需要等待前一个PLAY请求完成才能得到执行。
比如，不管到达的两个PLAY请求之间有多紧凑，服务器首先play第10到15秒，然后立即第20到25秒，最后是第30秒直到结束。

2.2.5.TEARDOWN

TEARDOWN方法告知服务器结束流传输。

2.2.6.PAUSE

PAUSE请求引起媒体流传输的暂时中断。如果请求URL中指定了具体的媒体流，那么只有该媒体流的播放和记录被暂停（halt）。比如，指定暂停音频，播放将会无声。如果请求URL指定了一组流，那么在该组中的所有流的传输将被暂停。
PAUSE请求中可能包含一个Range头用来指定何时媒体流暂停，我们称这个时刻为暂停点（pause point）。该头必须包含一个精确的值，而不是一个时间范围。媒体流的正常播放时间设置成暂停点。当服务器遇到在任何当前挂起（pending）的PLAY请求中指定的时间点后，暂停请求生效。如果Range头指定了一个时间超出了任何一个当前挂起的PLAY请求，将返回错误"457 Invalid Range" 。如果一个媒体单元（比如一个音频或视频禎）正好在一个暂停点开始，那么表示将不会被播放或记录。如果Range头缺失，那么在收到暂停消息后媒体流传输立即中断，并且暂停点设置成当前正常播放时间。

2.3.认证

参考：https://www.jianshu.com/p/b323d8f88b38

2.3.1.基本认证

http1.0提出的认证方案，其消息传输不经过加密转换，存在严重的安全隐患；
认证流程：

1.客户端发送DESCRIBE请求到服务端
2.服务端认为认证没有通过，发送包含WWW-Authenticate字段的认证请求
3.客户端弹出用户名密码认证窗口，要求输入认证信息
4.客户端携带Authorization字段再次发出DESCRIBE请求（Authorization字段包含了对username:password进行base64编码的信息）

response计算：

当password为MD5编码，则 response = md5(password:nonce:md5(public_method:url)) 当password为ANSI字符串，则response = md5(md5(username:realm:password):nonce:md5(public_method:url))
客户端在每次发起不同的请求方法时都需要计算response，同样在服务端验证时也默认采取同样的计算方法 RTSP用的是MD5小写计算

2.3.2.摘要认证

http1.1提出的基本认证的替代方案，其消息经过MD5加密转换，具有更高的安全性
认证流程：

1.客户端发送DESCRIBE请求到服务端
2.服务端端返回401错误，提示未认证并返回realm和nonce
3.客户端根据用户名、realm、密码、nonce、RTSP方法，请求的URL生成response返回
4.服务端验证客户端返回的response，验证成功返回OK，响应DESCRIBE
5.客户端发起SETUP请求到服务端（用同样的方法生成response）
6.服务端验证客户端返回的response，验证成功返回OK，响应SETUP
7.客户端发起PLAY请求到服务端（用同样的方法生成response）
8.服务端验证客户端返回的response，验证成功返回OK，响应PLAY

2.3.3.摘要认证对比基本认证

1.密码使用MD5加密，基本不可逆
2.防止重放攻击，服务端向客户端发送随机数nonce，客户端生成摘要时要把nonce和密码放在一起，服务端知道用户的原始密码及nonce，接收到请求后再临时生成摘要与之对比
3.通过客户端产生随机数nonce的方式，支持客户端对服务器的认证（双向认证，防止伪装服务器攻击）

2.4.RTSP数据

使用udp接收数据时不需要对数据做rtp包解包处理，使用tcp接收数据时，由于rtp，rtcp，rtsp都在同一端口上，用户需要做tcp解包处理。

2.4.1.数据包格式

Rtsp数据格式：

typedef struct RtspCntHeader {uint8_t		magic;			// 0x24uint8_t		channel;uint16_t	length;uint8_t		payload[0];		// RtpHeader
} RtspCntHeader_st;

magic：美元符号$（0x24）表示Interleave Frame层的开始
channel：channel identifier，表明协议的类型，一般如下：0x00：Video RTP0x01：Video RTCP0x02：Audio RTP0x03：Audio RTCP
length：data length，RTP包（封装的二进制数据）的大小
payload：RTP数据

抓包分析：

24：起始符，美元符号$
00：协议的类型，Video RTP
05A8：RTP包大小

2.4.2.tcp和udp接收数据区别

2.4.2.1.工作方式的差异

通常来说，RTSP提供UDP方式发送RTP流。当然，发送流媒体时，UDP往往是更好的选择。但是，在互联网上使用UDP方式发送流会有一些问题：

1.UDP协议上的RTSP/RTP需要打开多个UDP端口（每一路流媒体都需要2个UDP端口，一个用于接收数据，一个用于接收控制信息）；
2.当因特网上的路由器没有打开这些端口的时候，上述第一点将会存在问题；
3.中间网络路由器很容易就过滤或者忽略掉UDP数据包；
4.UDP是不可靠传输协议，媒体包在因特网上传输时会面临着丢包。

如果在TCP传输协议上承载RTSP/RTP将解决这些问题：

1.RTSP/RTP的控制命令和数据都通过一个端口，即RTSP的端口（默认为554），进行交互。
2.TCP协议提供可靠的流传输。
3.TCP包更容易穿透中间网络路由器。

使用TCP传输协议承载RTSP/RTP需要花更多的功夫：

1.由于二元交织，会使得RTP包封包和解包的过程变得更加复杂。
2.TCP是可靠的传输协议，但正是因为如此，会导致在实时流媒体中的延时。

2.4.2.2.rtsp指令交互差异

与UDP RTSP指令集相比，TCP指令集在SETUP指令上存在差异：

TCP： Transport: RTP/AVP/TCP;unicast;interleaved=0-1
UDP： Transport: RTP/AVP;unicast;client_port=63082-63083

使用偶数信道作为数据传输（RTP）信道，使用奇数信通道（RTCP）作为控制信道（数据信道 + 1）。所以，如果你设定数据信道为0，那控制信道应该是0 + 1 = 1。

三.SDP协议

3.1.概述

SDP(Session Description Protocol)会话描述协议，用于描述多媒体会话，它为会话通知、会话初始和其它形式的多媒体会话初始等操作提供服务。
SDP的设计宗旨是通用性协议，所有它可以应用于很大范围的网络环境和应用程序，但SDP不支持会话内容或媒体编码的协商操作。
SDP信息包括：

1.会话名称和目标；
2.会话活动时间；
3.构成会话的媒体；
4.有关接收媒体的信息、地址等。

3.2.SDP格式

SDP信息是文本信息，UTF-8编码采用ISO 10646字符设置。SDP会话描述如下（标注*符号的表示可选字段）：

v=*（SDP的版本号，不包括次版本号）
o=*（所有者/创建者和会话标识符）o=<username> <sessionid> <version> <network type> <address type> <address><username>是用户的登录名。如果主机不支持<username>，则为“－”。注意：<username>不能含空格。<session id>：是一个数字串。在整个会话中，必须是唯一的<version>：该会话公告的版本<networktype>：网络类型，一般为“IN”,表示“internet”<address type>：地址类型，一般为IP4<address>：地址
s=*（会话名称）会话名，在整个会话中有且只有一个“s=”
i=*（会话信息）
u=*（URI 描述）
e=*（Email 地址）
p=*（电话号码）
c=*（连接信息 ― 如果包含在所有媒体中，则不需要该字段）c=<networktype> <address type> <connection address>b=*（带宽信息）b=<modifier>:<bandwidth-value>描述了建议的带宽，单位kilobits per second
<modifier>：包括两种CT和AS。CT：Conference Total，总带宽。AS：Application-Specific Maximum，单个媒体带宽的最大值。扩展机制：<modifier>以“X－”开始。建议modifier越短越好。例b=X-YZ:128

一个或更多时间描述（如下所示）：

z=*（时间区域调整）
k=*（加密密钥）
a=*（0个或多个会话属性线路）
0个或多个媒体描述（如下所示）

时间描述

t=*（会话活动时间）t=<start time><stop time>描述了会话的开始时间和结束时间
r=*（0或多次重复次数）

媒体描述

m=*（媒体名称和传输地址）
m=<media><port> <transport> <fmt list>一个会话描述包括几个媒体描述。一个媒体描述以”m=”开始到下一个”m=”结束<media>：表示媒体类型。有audio、video、application（例白板信息），data不向用户显示的数据）和control（描述额外的控制通道）<port>：媒体流发往传输层的端口<transport>：传输协议，与c=行的地址类型有关，RTP/AVP/TCP<fmt list>：媒体格式
i=*（媒体标题）
c=*（连接信息 — 如果包含在会话层则该字段可选）
b=*（带宽信息）
k=*（加密密钥）
a=*（0个或多个会话属性线路）a=rtpmap:<payload type><encoding name>/<clock rate>[/<encodingparameters>]

四.RTP协议

参考：http://blog.csdn.net/chen495810242/article/details/39207305

4.1.概述

实时传输协议（Real-time Transport Protocol或简写RTP）是一个网络传输协议，它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。
RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议，但后来被用在很多单播应用中。RTP协议常用于流媒体系统（配合RTSP协议），视频会议和一键通（Push to Talk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是创建在UDP协议上的。

4.2.数据包格式

typedef struct RtpCntHeader {uint8_t  exts;uint8_t  type;uint16_t seqNo;			// Sequence numberuint32_t ts;				// Timestampuint32_t SyncSrcId;		// Synchronization source (SSRC) identifier// Contributing source (SSRC_n) identifieruint8_t payload[0];		// Frame data
} RtpCntHeader_st;

exts：V：RTP协议的版本号，占2位，当前协议版本号为2P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头CC：CSRC计数器，占4位，指示CSRC标识符个数
types：M：标志，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。PT（payload type）：有效荷载类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等，在流媒体中大部分是用来区分音频流和视频流，这样便于客户端进行解析。
seqNo：序列号，占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。当出现网络抖动的情况可以用来对数据进行重新排序。序列号的初始值是随机的，同时音频包和视频包的sequence是分别计数的。
ts：时间戳（Timestamp），占32位，必须使用90kHZ时钟频率（程序中的90000）。时戳反映了该RTP报文的第一个八位组的采样时刻。接受者使用时戳来计算延迟和延迟抖动，并进行同步控制。可以根据RTP包的时间戳来获得数据包的时序。
SyncSrcId：同步信源（SSRC）标识符，占32位，用于标识同步信源。同步信源是指产生媒体流的信源，他通过RTP报头中的一个32为数字SSRC标识符来标识，而不依赖网络地址，接收者将根据SSRC标识符来区分不同的信源，进行RTP报文的分组。
提供信源（CSRC）标识符：每个CSRC标识符占32位，可以有0~15个CSRC。每个CSRC标识了包含在RTP报文有效载荷中的所有提供信源。（示例没有）

注：

同步信源是指产生媒体流的信源，例如麦克风、摄像机、RTP混合器等；它通过RTP报头中的一个32位数字SSRC标识符来标识，而不依赖于网络地址，接收者将根据SSRC标识符来区分不同的信源，进行RTP报文的分组。

特约信源是指当混合器接收到一个或多个同步信源的RTP报文后，经过混合处理产生一个新的组合RTP报文，并把混合器作为组合RTP报文的SSRC，而将原来所有的SSRC都作为CSRC传送给接收者，使接收者知道组成组合报文的各个SSRC。

若一个RTP包流的源，对由RTP混频器生成的组合流起了作用，则它就是一个作用源。对特定包的生成起作用的源，其SSRC标识符组成的列表，被混频器插入到包的RTP报头中。这个列表叫做CSRC表。

如图，有三个信号源各发出一路RTP流，RTP1携带的SSRC是SSRC1，RTP2携带的SSRC是SSRC2，RTP3携带SSRC3，这三路RTP流到达混合器时，混合器会将这三路流混合成一路流发出去，它会把这三路流的SSRC记录下来，形成一个列表，叫CSRC表，在发送的混合RTP流中，SSRC域填充的字段是混合器本身的SSRC4，而CSRC字段则会根据该包的负载的源来填入。例如当前的RTP包的负载是来自SSRC1的，那么在当前RTP包的CSRC字段填入SSRC1。这样接收者就可以根据CSRC来区分不同的信源；一般的，混合的RTP流中，每隔一段时间，就会有一个RTP报文包含了完整的CSRC表。例如在发送混合流时的第一个RTP包，它的CSRC域把CSRC表都填入，此时该包的负载可能是无意义或者并不是媒体流；此后的RTP报文中则根据负载的来源来填入CSRC域。

抓包分析：

80：1000 0000
10：V，RTP协议的版本号
0：P，填充标志
0：X，扩展标志
0000：CC，CSRC计数器
60：0110 0000
0：M标志
110 0000：PT，有效荷载类型
5D06：序列号
A6B87472：时间戳
C009E78D：SSRC

4.3.RTP会话过程

当应用程序建立一个RTP会话时，应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成，有两个端口：一个给RTP包，一个给RTCP包，使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口，而对应的控制信号RTCP数据发向相邻的奇数UDP端口（偶数的UDP端口＋1），这样就构成一个UDP端口对。RTP的发送过程如下，接收过程则相反。

1.RTP协议从上层接收流媒体信息码流（如H.263），封装成RTP数据包；
2.RTCP从上层接收控制信息，封装成RTCP控制包。
3.RTP将RTP 数据包发往UDP端口对中偶数端口；RTCP将RTCP控制包发往UDP端口对中的接收端口。

4.4.RTP载荷H264码流

F和NRI与NALU头一样，只有Type有些不一样：拓展24–31：

0：未定义
1-23：NAL单元单个NAL单元包.
24：STAP-A单一时间的组合包
25：STAP-B单一时间的组合包
26：MTAP16多个时间的组合包
27：MTAP24多个时间的组合包
28：FU-A分片的单元
29：FU-B分片的单元
30-31：未定义

1.单个NAL单元包：荷载中只包含一个NAL单元。NAL头类型域等于原始 NAL单元（NALU）类型，即Type在范围1到23之间。
2.组合包：本类型用于聚合多个NAL单元到单个RTP荷载中。本包有四种版本，单时间聚合包类型A（STAP-A）单时间聚合包类型B（STAP-B）,多时间聚合包类型（MTAP）16位位移（MTAP16）,多时间聚合包类型（MTAP）24位位移（MTAP24）。赋予STAP-A，STAP-B，MTAP16，MTAP24的NAL单元类型号（Type）分别是24 25 26 27
3.分片包：用于分片单个NAL单元到多个RTP包。现存两个版本FU-A，FU-B，用NAL单元类型（Type）28、29标识

常用的打包时的分包规则：如果小于MTU采用单个NAL单元包，如果大于MTU（最大传输单元，Maximum Transmission Unit）就采用FUs（分片单元，Fragmentation Units）分片方式。

4.4.1.单个NAL单元包

定义在此的NAL单元包必须只包含一个。这意味聚合包和分片单元不可以用在单个NAL单元包中。并且RTP序号必须符合NAL单元的解码顺序。NAL单元的第一字节和RTP荷载头第一个字节重合。打包H264码流时，只需在帧前面加上12字节的RTP头即可。

4.4.2.分片单元（FU-A）

分片只定义于单个NAL单元不用于任何聚合包。NAL单元的一个分片由整数个连续NAL单元字节组成。每个NAL单元字节必须正好是该NAL单元一个分片的一部分。相同NAL单元的分片必须使用递增的RTP序号连续顺序发送(第一和最后分片之间没有其他的RTP包）。相似，NAL单元必须按照RTP顺序号的顺序装配。
当一个NAL单元被分片运送在分片单元(FUs)中时，被引用为分片NAL单元。STAPs，MTAPs不可以被分片。FUs不可以嵌套。即,一个FU不可以包含另一个FU。运送FU的RTP时戳被设置成分片NAL单元的NALU时刻。
FU-A的RTP荷载格式。FU-A由1字节的分片单元指示，1字节的分片单元头，和分片单元荷载组成。

S：1 bit当设置成1，开始位指示分片NAL单元的开始。当跟随的FU荷载不是分片NAL单元荷载的开始，开始位设为0。
E：1 bit当设置成1，结束位指示分片NAL单元的结束，即荷载的最后字节也是分片NAL单元的最后一个字节。当跟随的FU荷载不是分片NAL单元的最后分片，结束位设置为0。
R：1 bit保留位必须设置为0，接收者必须忽略该位

抓包分析

前12位为RTP Header
7C是FU indicator
81是FU Header
FU indicator（0x7C）和FU Header（0x81）换成二进制如下：
0111 1100 1000 0001，按顺序解析
0：F，forbidden_zero_bit，H264规定此位必须为0
11：NRI，nal_ref_idc，代表优先级（0-3，3最高）
11100：是FU Type，这里是28，即FU-A
1：S，Start，说明是分片的第一包
0：E，End，如果是分片的最后一包，设置为1，这里不是
0：R，是R，Remain，保留位，总是0
00001：nal_unit_type，NALU单元类型

打包时，FUindicator的F、NRI是NAL Header中的F、NRI，Type是28；FU Header的S、E、R分别按照分片起始位置设置，Type是NAL Header中的Type。
解包时，取FU indicator的前三位和FU Header的后五位，即0110 0101（0x65）为NAL类型。

五.RTCP协议

参考：https://winddoing.github.io/post/32277.html

5.1.概述

Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP）是实时传输协议（RTP）的一个姐妹协议。RTCP由RFC 3550定义（取代作废的RFC 1889）。RTP使用一个偶数UDP port ；而RTCP则使用RTP的下一个port，也就是一个奇数port。RTCP与RTP联合工作，RTP实施实际数据的传输，RTCP则负责将控制包送至电话中的每个人。其主要功能是就RTP正在提供的服务质量做出反馈。

作用：

RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。通常使用UDP来传送数据，但RTP也可以在TCP或ATM等其他协议之上工作。当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。在RTP会话期间，各参与者周期性地传送RTCP包，RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，RTP实施实际数据的传输，RTCP则负责将控制包送至电话中的每个人。其主要功能是就RTP正在提供的服务质量做出反馈。它们能以有效的反馈和最小的开销使传输效率最佳化。因而特别适合传送网上的实时数据。

RTCP为RTP媒体流提供信道外（out-of-band）控制。RTCP本身并不传输数据，但和RTP一起协作将多媒体数据打包和发送。RTCP定期在流多媒体会话参加者之间传输控制数据。RTCP的主要功能是为RTP所提供的服务质量（Quality
of Service）提供反馈。

RTCP收集相关媒体连接的统计信息，例如：传输字节数，传输分组数，丢失分组数，jitter，单向和双向网络延迟等等，网络应用程序即可利用RTCP的统计信息来控制传输的品质，比如当网络带宽高负载时限制信息流量或改用压缩比较小的编解码器。

RTCP本身不提供数据加密或身份认证。SRTCP可以用于此类用途。

5.2.数据包格式

RTCP也是用UDP来传送的，但RTCP封装的仅仅是一些控制信息，因而分组很短，所以可以将多个RTCP分组封装在一个UDP包中。
类似于RTP信息包，每个RTCP信息包以固定部分开始，紧接着的是可变长结构单元，最后以一个32位边界结束。
根据所携带的控制信息不同RTCP信息包可分为：

200：SR（Sender Report），发送端报告
201：RR（Receiver Report），接收端报告
202：SDES（Source Description Items），源点描述
203：BYE，结束传输
204：APP，特定应用
195：1j（Extended Jitter Report），扩展Jitter报告，RFC 5450
205：RTPFB（传输层反馈），RFC 4585
206：PSFB（Payload-specific FB），负载相关反馈，RFC 5104
207：XR（Extended Report），扩展报告，RFC 3611

格式：

version (V)，2 bits，标识当前RTP版本2
padding (P)，1 bit，填充位标识
Feedback message type (FMT)，5bits，标识反馈消息的类型
Payload type (PT)，8 bits，RTCP包的类型
Length，16 bits

FMT报文子类型：

Generic NACK：The Generic NACK message is identified by PT=RTPFB and FMT=1
消息语法：

PID：Packet ID，16bits
BLP：bit mask of following lost packets，16bits

从PID开始接下来16个RTP数据包的丢失情况，一个NACK报文可以携带多个RTP序列号，NACK接收端对这些序列号逐个处理。

丢包重传：

其他格式：
SR: Receiver Report RTCP Packet

RR: Receiver Report RTCP Packet

V：version，2 bits，版本，一般为2
P：padding，如果设定了padding位，这个个别的RTCP报文在尾部包含一些附加的padding字段，不是控制信息但却包含在长度域中。padding 的最后一个字段是应该忽略的字段的计数，包括自己。一般为0
RC：reception report count，5 bits，本报文中包含的接收报告块的数量、一般为1
PT：packet type，8bits，包类型
Length：16 bits，本RTCP报文长度（以32-bit形式）减一，包括头和padding（减一是为了零长度有效和避免无限循环来寻找混合的RTCP报文，而32-bit字是避免对四的倍数的有效检查）。这里值为7，简单的说就是记得是头的长度减去1的值
SSRC：32 bits，此值为一个随机数，但是却要保持唯一
SSRC_n：32 bits，源的SSRC identifier，本报告块的信息所属。说白了，就是RTP包的SSRC值
fraction lost：8 bits，上次SR或RR发送之后，从SSRC_n源的RTP报文丢失的部分，以定点数来表达，二进制的点在左边沿（相当于loss部分乘256之后取整）。这部分定义为丢失报文的数量除以期望的报文，像下段所应依的那样。如果因为复制而使损失为负，lost部分设定为零。注意到接收者不能辨认是否有报文丢失，如果在上次报告间隔期间的报文丢失了，不会有没有接收报告来关注这个问题
cumulative number of packets lost：24 bits，从接收开始，SSRC_n源的RTP报文丢失的数量。定义为期望的减去实际接收的，其中接收的包括迟到的和复制的，如果有复制，丢失可能为负。期望的报文定义为由上次接收的序列号延伸出的序列号，如下所定义，减去接收到的初始序列号。
extended highest sequence number received：32 bits，低16位包含从源SSRC_n接收到的RTP数据报文中最高的序列值、高16位表示循环的次数
interarrival jitter：32 bits，关于RTP数据报文 interarrival 时间的统计方差的估值，以timestamp单元来估值，表现为无符号整数。interarrival jitter J定义为D的均方差，D为接收者和发送者的间隔。像下面方程所示，等于两个报文的“相对传输时间”（the relative transit time）的差；相对传输时间是一个报文的RTP timestamp和到达接收者的时钟的差，在相同单元衡量
last SR timestamp (LSR)：32 bits，NTP timestamp的中间32位作为从源 SSRC_n来的最近的RTCPSR。如果尚未接收到SR，域设置为零
delay since last SR (DLSR)：32 bits，延迟定义为从接收到从源SSRC_n来的上一个SR到发送本接收报告块的间隔，表示为1/65536秒一个单元。如果尚未收到SR，DLSR域设置为零

这篇关于RTSP网络串流的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---