RTSP RTP RTCP

参考
Wireshark 抓包分析 RTSP/RTP/RTCP 基本工作过程
RTSP协议实例分析
RTSP协议之TCP/UDP问题
VLC RTSP网络串流播放失败
Wireshark 抓包分析 RTSP/RTP/RTCP 基本工作过程
webrtc音频系列——4、RTP与RTCP协议

一、RTSP抓包分析

RTSP（Real-Time Streaming Protocol）实时流式协议是IETF的MMUSIC工作组开发的协议，现在已成为因特网建议标准[RFC 2326]。RTSP是为了给流式过程增加更多的功能（暂停、继续、播放、快进、快退）而设计的协议。需要注意的是，RTSP本身不传输数据，音视频流数据是通过RTP传输的。

打开wireshark并输入相应的过滤规则ip.addr==192.168.99.26开始抓包。然后在VLC输入如rtsp://admin:[email protected]来向服务器请求流，其中192.168.99.152是我的本机IP。

image.png

上图为从TCP握手，到开始播放视频的整个流程。左侧第一列为包的序号，下面开始分步解析：

1.OPTIONS

OPTIONS 请求用于返回服务端支持的 RTSP方法列表。也可以定时发送这个请求来保活相关的 RTSP 会话。

客户端经过TCP三次握手后，客户端发送 OPTION的方法询问服务器等提供的服务，此时Cseq为2，它只是记录回话的次数序号而已。

//313包
Real Time Streaming Protocol
    Request: OPTIONS rtsp://192.168.99.26:554 RTSP/1.0\r\n
        Method: OPTIONS
        URL: rtsp://192.168.99.26:554
    CSeq: 2\r\n
    User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)\r\n
    \r\n

//316包
Real Time Streaming Protocol
    Response: RTSP/1.0 200 OK\r\n
        Status: 200
    CSeq: 2\r\n
    Public: OPTIONS,DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,ANNOUNCE,SET_PARAMETER,GET_PARAMETER\r\n
    \r\n

2.DESCRIBE

DESCRIBE 命令用于请求指定的媒体流的 SDP 描述信息（详细包括音视频流的帧率、编码类型等等媒体信息）

//317包
Real Time Streaming Protocol
    Request: DESCRIBE rtsp://192.168.99.26:554 RTSP/1.0\r\n
        Method: DESCRIBE
        URL: rtsp://192.168.99.26:554
    CSeq: 3\r\n
    User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)\r\n
    Accept: application/sdp\r\n
    \r\n

//319包
Real Time Streaming Protocol
    Response: RTSP/1.0 401 ClientUnAuthorized\r\n
        Status: 401
    CSeq: 3\r\n
    WWW-Authenticate: Digest realm="48ea63892640",nonce="75550026517114e169078e528195df14", stale="FALSE"\r\n
    \r\n

Cseq为3时，则是客户端用DESCRIBE 方法主动告诉服务器自己的信息，服务器回的是未认证Unauthorized，即未登录。紧接着，要发送账号密码：

//320包
Real Time Streaming Protocol
    Request: DESCRIBE rtsp://192.168.99.26:554 RTSP/1.0\r\n
        Method: DESCRIBE
        URL: rtsp://192.168.99.26:554
    CSeq: 4\r\n
    Authorization: Digest username="admin", realm="48ea63892640", 
    nonce="75550026517114e169078e528195df14", uri="rtsp://192.168.99.26:554", 
    response="f5bc7cdd9532764e3142f09ad8afd410"\r\n
    User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)\r\n
    Accept: application/sdp\r\n
    \r\n

//324包
Real Time Streaming Protocol
    Response: RTSP/1.0 200 OK\r\n
        Status: 200
    CSeq: 4\r\n
    Content-Base: rtsp://192.168.99.26:554\r\n
    Content-length: 521
    Content-type: application/sdp
    \r\n
    Session Description Protocol
    Session Description Protocol Version (v): 0
    Owner/Creator, Session Id (o): - 1001 1 IN IP4 192.168.99.26
    Session Name (s): VCP IPC Realtime stream
    Media Description, name and address (m): video 0 RTP/AVP 105
    Connection Information (c): IN IP4 192.168.99.26
    Media Attribute (a): control:rtsp://192.168.99.26/media/video1/video
    Media Attribute (a): rtpmap:105 H264/90000
    Media Attribute (a): fmtp:105 profile-level-id=64002a; packetization-mode=1; 
    sprop-parameter-sets=Z2QAKqwsaoHgCJ+WbgICAoAAAfQAAGGoQg==,aO4xshs=
    Media Attribute (a): recvonly
    Media Description, name and address (m): application 0 RTP/AVP 107
    Connection Information (c): IN IP4 192.168.99.26
    Media Attribute (a): control:rtsp://192.168.99.26/media/video1/metadata
    Media Attribute (a): rtpmap:107 vnd.onvif.metadata/90000
    Media Attribute (a): fmtp:107 DecoderTag=h3c-v3 RTCP=0
    Media Attribute (a): recvonly

Cseq为4时，客户端用DESCRIB方法主动发送用户名及密码给服务端，用户名为字段username，密码则由nonce和 response加密组成，服务器成功认证的话会发送服务器的媒体信息。

3.SETUP

SETUP 命令用于配置数据交互的方法。（比如制定音视频的传输方式TCP UDP）

//327包
Real Time Streaming Protocol
    Request: SETUP rtsp://192.168.99.26/media/video1/video RTSP/1.0\r\n
        Method: SETUP
        URL: rtsp://192.168.99.26/media/video1/video
    CSeq: 5\r\n
    Authorization: Digest username="admin", realm="48ea63892640", 
    nonce="75550026517114e169078e528195df14", uri="rtsp://192.168.99.26:554", 
    response="41f1c5f27b4ea56d04ed250a3b6c817f"\r\n
    User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)\r\n
    Transport: RTP/AVP;unicast;client_port=52454-52455
    \r\n

//330包
Real Time Streaming Protocol
    Response: RTSP/1.0 200 OK\r\n
        Status: 200
    CSeq: 5\r\n
    Transport: RTP/AVP/UDP;unicast;destination=192.168.99.152;
    client_port=52454-52455;server_port=10008-10009;ssrc=1e3dd08;mode="PLAY"
    Session: d712472fec12472f7312472f8312472;timeout=60
    \r\n

Cseq为5时，客户端用SETUP方法主动向服务端请求视频流。这里没有请求音频流，可以参考另一个示例：

image.png

4.PLAY

用于启动 (当暂停时重启) 交付数据给客户端

//335包
Real Time Streaming Protocol
    Request: PLAY rtsp://192.168.99.26:554 RTSP/1.0\r\n
        Method: PLAY
        URL: rtsp://192.168.99.26:554
    CSeq: 6\r\n
    Authorization: Digest username="admin", realm="48ea63892640", 
    nonce="75550026517114e169078e528195df14", uri="rtsp://192.168.99.26:554", 
    response="27afd2aedf2686533cc9def6b5711632"\r\n
    User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)\r\n
    Session: d712472fec12472f7312472f8312472
    Range: npt=0.000-\r\n
    \r\n

//338包
Real Time Streaming Protocol
    Response: RTSP/1.0 200 OK\r\n
        Status: 200
    CSeq: 6\r\n
    Session: d712472fec12472f7312472f8312472
    \r\n

//339包后面就全是RTP数据了

5.PAUSE 和 TEARDOWN

PAUSE 请求用于临时停止服务端的数据的交互。使用 PLAY 来重新启动数据交互。
TEARDOWN 请求用于终止来自服务端的数据的传输。

//关掉VLC后，可以看到1595包
Real Time Streaming Protocol
    Request: TEARDOWN rtsp://192.168.99.26:554 RTSP/1.0\r\n
        Method: TEARDOWN
        URL: rtsp://192.168.99.26:554
    CSeq: 7\r\n
    Authorization: Digest username="admin", realm="48ea63892640", 
    nonce="75550026517114e169078e528195df14", uri="rtsp://192.168.99.26:554", 
    response="3fe7f14201dec5bcd7e2781d31df260a"\r\n
    User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)\r\n
    Session: d712472fec12472f7312472f8312472
    \r\n

6.服务端回应的状态码结构体，跟http请求返回值类型码很类似

RtspMethod_t gRtspStatu[] = {
    {"Continue", 100},
    {"OK", 200},
    {"Created", 201},
    {"Accepted", 202},
    {"Non-Authoritative Information", 203},
    {"No Content", 204},
    {"Reset Content", 205},
    {"Partial Content", 206},
    {"Multiple Choices", 300},
    {"Moved Permanently", 301},
    {"Moved Temporarily", 302},
    {"Bad Request", 400},
    {"Unauthorized", 401},
    {"Payment Required", 402},
    {"Forbidden", 403},
    {"Not Found", 404},
    {"Method Not Allowed", 405},
    {"Not Acceptable", 406},
    {"Proxy Authentication Required", 407},
    {"Request Time-out", 408},
    {"Conflict", 409},
    {"Gone", 410},
    {"Length Required", 411},
    {"Precondition Failed", 412},
    {"Request Entity Too Large", 413},
    {"Request-URI Too Large", 414},
    {"Unsupported Media Type", 415},
    {"Bad Extension", 420},
    {"Invalid Parameter", 450},
    {"Parameter Not Understood", 451},
    {"Conference Not Found", 452},
    {"Not Enough Bandwidth", 453},
    {"Session Not Found", 454},
    {"Method Not Valid In This State", 455},
    {"Header Field Not Valid for Resource", 456},
    {"Invalid Range", 457},
    {"Parameter Is Read-Only", 458},
    {"Internal Server Error", 500},
    {"Not Implemented", 501},
    {"Bad Gateway", 502},
    {"Service Unavailable", 503},
    {"Gateway Time-out", 504},
    {"RTSP Version Not Supported", 505},
    {"Extended Error:", 911},
    {0, RTSP_PARSE_INVALID_OPCODE}
};

二、TCP UDP

1.区别

如果让你从0开发一套实时互动直播系统，你首先要选择网络传输协议。UDP 还是 TCP？答案是：UDP。

为什么实时传输不能用 TCP ？TCP 的目的就是实现数据的可靠传输，因此他有一套握手，发送 -> 确认，超时 -> 重发的机制。

举个例子，A 与 B 通讯，A 首先向 B 发送数据，并启动一个定时器。当 B 收到 A 的数据后，B 需要给 A 回一个ACK（确认）消息，反复这样操作，数据就源源不断地从 A 流向了 B。如果因为某些原因，A 一直收不到 B 的确认消息会怎么办呢？当 A 的定时器超时后，A 将重发之前没有被确认的消息，并重新设置定时器。

在 TCP 协议中，为了避免重传次数过多，定时器的超时时间会按 2 的指数增长。也就是说，假设第一次设置的超时时间是 1 秒，那么第二次就是 2 秒，第三次是 4 秒……第七次是 64 秒。如果第七次之后仍然超时，则断开 TCP 连接。你可以计算一下，从第一次超时，到最后断开连接，这之间一共经历了 2 分 07 秒，是不是很恐怖？

如果遇到前面的情况，A 与 B 之间的连接断了，那还算是个不错的情况，因为还可以再重新建立连接。但如果在第七次重传后，A 收到了 B 的 ACK 消息，那么 A 与 B 之间的数据传输的延迟就达到 1 分钟以上。对于这样的延迟，实时互动的直播系统是根本无法接受的。

基于以上的原因，在实现实时互动直播系统的时候你必须使用 UDP 协议。

2.RTSP传输TCP包的两种方式

RTSP流(传输RTP包)的传输方式有两种:

RTP/AVP/UDP
RTP/AVP/TCP.

默认传输方式为: RTP/AVP. 即RTP/AVP/UDP.

在RTSP中，TCP与UDP方式的区别在客户端项服务端SETUP请求中的Transport项体现。使用udp传输需要为每一个连接设定本机的rtp和rtcp对应的两个端口用于rtp和rtcp的通讯，而tcp方式不需要。RTSP客户端会根据自己的环境发出请求，以决定使用TCP还是UDP的方式，在比较完善的RTSP服务中这两种方式都支持，然而在我遇到的产品（某品牌NVR）中只支持TCP方式，在实测过程中，VLC连接时默认使用UDP方式连接时会失败，然后VLC会自动切成TCP的连接方式，而FFPALY则不会自动切换，这里为VLC点个赞。

//RTP/AVP
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589

S->C: RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Transport: RTP/AVP;unicast; client_port=4588-4589;server_port=6256-6257

//TCP
C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0
CSeq: 2
Transport: RTP/AVP/TCP;interleaved=0-1

S->C: RTSP/1.0 200 OK
CSeq: 2
Date: 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;interleaved=0-1

3.RTP/AVP

在RTP/AVP情况下, RTSP Client向RTSP Server提出SETUP申请时，指定client端用于接收RTP和RTCP交互的端口:client_port=4588-4589

偶数(4588)
用于接收RTP数据.
奇数(4589)
用于进行RTCP交互.
RTSP Server响应时, 会指定服务器端用于交互的端口：server_port=6256-6257. 其中偶数(6256)用于发送RTP数据, 奇数(6257)用于RTCP交互.

视频和音频分别执行SETUP指令, 故它们有自己独自的RTP和RTCP端口.

image.png

基本流程: RTP打包->UDP传输->RTP解包.
RTCP用于质量控制, 通过QoS反馈到RTP打包和RTP解包.

4.RTP/AVP/TCP

Certain firewall designs and other circumstances may force a server to interleave RTSP methods and stream data.
This interleaving should generally be avoided unless necessary since it complicates client and server operation and imposes additional overhead.
Interleaved binary data SHOULD only be used if RTSP is carried over TCP.

有时候处于安全设计, 防火墙可能要求RTSP控制方法和流数据公用一个通信通道，进行交错传输.
仅在RTSP控制方法通过TCP方式传输时，才可以交错传输二进制数据.

既然是在同一个通道传输，怎么区分RTP通道(channel)和RTCP通道呢?
答案是在RTP层之上增加一层, 叫做:RTSP Interleaved Frame层.

image.png

用wireshark抓包，示意如下:
!RTP层上又封装了一层:RTSP Interleaved Frame层
以上数据中看到Payload type等于97, 一般为音频(视频的Payload type一般为96).

image.png

SETUP请求和响应的示意如下:

C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0
CSeq: 2
Transport: RTP/AVP/TCP;interleaved=0-1

S->C: RTSP/1.0 200 OK
CSeq: 2
Date: 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;interleaved=0-1

可看出Transport: RTP/AVP/TCP;interleaved=0-1中interleaved=一般指定为一个范围: 0-1或2-3
一般偶数用于标示RTP数据
奇数用于标示RTCP数据.

5.VLC RTSP网络串流播放失败

TCP传输方式使用的是原有的套接字，不用另开套接字，起到节省资源的作用，还能利用TCP的可靠性。另一方面它更具有穿墙的特性，在很多网络的路由中有设置不给于外网访问内网，此时用UDP方式，需要服务端主动连接客户端提供的UDP接口，这请求有可能被防火墙拦截，在抓包分析中表现出来是port unreachable的错误提示，可见这种方式是比较受限制的。综上，在可靠连接和资源方面考虑，在嵌入式安防产品中采用TCP方式较多。

image.png

另外参考RTSP视频平台EasyNVR如何设置防火墙允许程序运行端口的访问？

防火墙是现代帮助计算机网络于其内、外网之间构建一道相对隔绝的保护屏障，以保护用户资料与信息安全性的一种技术。视频流媒体平台在使用过程中，由于防火墙的机制，会被防火墙阻拦运行，这时候我就要允许平台端口通过防火墙。
我们在拿EasyNVR来举例。用户在windows服务器内首次安装使用EasyNVR时，怎么配置允许EasyNVR所需端口通过windows防火墙。
EasyNVR默认使用的端口为10800和10935端口。在windows服务器中，如果开启了防火墙功能，则需要进行以下设置，允许EasyNVR所需使用的端口通过防火墙。

三、RTP 协议

我们现在已经决定好用UDP做实时语音。

我们以视频为例，在视频中，一个 I 帧的数据量是非常大的（假设要几十 K）。而以太网的最大传输单元是多少呢？ 1.5K，所以要传输一个 I 帧需要几十个UDP包。这几十个包传到对端后，还要重新组装成 I 帧，这样才能进行解码还原出一幅幅的图像。那么我必须要在包中，添加额外的标记才能够完成组装。这至少包括：

序号：用于标识传输包的序号，这样就可以知道这个包是第几个分片了。
起始标记：记录分帧的第一个 UDP 包。
结束标记：记录分帧的最后一个 UDP 包。

有了上面这几个标识字段，我们就可以在发送端进行拆包，在接收端将视频帧重新再组装起来了。

其实，这样的需求在很早之前就已经有了。因此就有了RTP协议。下面让我们来详细看一下 RTP 协议吧。一般情况下，在实时互动直播系统传输音视频数据流时，我们并不直接将音视频数据流交给 UDP 传输，而是先给音视频数据加个 RTP 头，然后再交给 UDP 进行传输。

image.png

比较值得关注的是payload type 和marker bit ，payload type定义了RTP帧是视频还是音频，marker bit定义了RTP帧是否结束（RTP报文段必须小于MTU，所以一般的视频都有好几个报文段组成）。

image.png

上图抓取了其中一个报文段来分析RTP协议数据，可以看出这是一帧视频流，而且尚未结束还有其他报文（marker bit为false）。下面再来看一个抓包截图：

image.png

前面提及，服务端从420就已经用RTP推送音视频流数据，直到484才收到第一帧视频，其中相隔64个报文段，而接来的视频一般只用5到6个报文段就能传输完成。其实这里涉及一点关于视频编码相关知识，I帧、P帧、B帧等。I帧能完全还原一幅图像，P帧、B帧则是参考其他帧来完成显示，其大小比I帧小很多。这就可以解释上面为什么第一帧视频这么大，而后面几帧就很小的缘故了。

四、RTCP

实时传输控制协议(Real-time ControlProtocol，RTCP)是和 RTP一起工作的控制协议。在RTP会话期间，每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包。

image.png

在使用 RTP 包传输数据时，难免会发生丢包、乱序、抖动等问题，下面我们来看一下使用的网络一般都会在什么情况下出现问题：

网络线路质量问题引起丢包率高；
传输的数据超过了带宽的负载引起的丢包问题；
信号干扰（信号弱）引起的丢包问题；
跨运营商引入的丢包问题 ;

WebRTC 对这些问题在底层都有相应的处理策略，但在处理这些问题之前，它首先要让各端都知道它们自己的网络质量到底是怎样的，这就是 RTCP 的作用。

RTCP也是用UDP来传送的，但RTCP封装的仅仅是一些控制信息，因而分组很短，所以可以将多个RTCP分组封装在一个UDP包中。
根据所携带的控制信息不同，RTCP信息包可分为RR（接收者报告包）、SR（源报告包）、SEDS（源描述包）、BYE（离开申明）和APP（特殊应用包）五类5类：

RTCP 有两个最重要的报文：RR 和 SR 。通过这两个报文的交换，各端就知道自己的网络质量到底如何了。

image.png

从上图中我们可以了解到，SR 报文分成三部分：Header、Sender info和Report block。

Header 部分用于标识该报文的类型，比如是 SR 还是 RR。
Sender info 部分用于指明作为发送方，到底发了多少包。
Report block 部分指明发送方作为接收方时，它从各个 SSRC 接收包的情况。

通过以上的分析，你可以发现SR 报文并不仅是指发送方发了多少数据，它还报告了作为接收方，它接收到的数据的情况。当发送端收到对端的接收报告时，它就可以根据接收报告来评估它与对端之间的网络质量了，随后再根据网络质量做传输策略的调整。

五、RTP/RTCP是如何解决问题的

How RTP/RTCP solve problems together

1.Negative Acknowledgment

也称为NACK。这是使用RTP处理数据包丢失的一种方法。

NACK是回给发送方以请求重发的RTCP消息。接收方使用SSRC和序列号制作RTCP消息。如果发送方没有可用于重新发送的RTP数据包，则忽略该消息。

2.Forward Error Correction

简称为FEC。处理丢包的另一种方法。FEC指的是发送方多次重复发送相同的数据，甚至是在接收方没有要求的情况下发送。这是在RTP协议层级完成的，甚至也可以在编解码器以下的层级完成。

在呼叫的数据丢包率比较稳定的情况下，作为延迟处理方案，FEC比NACK好的多。对于NACK，必须先请求，然后重新传输数据包，数据往返的时间对性能的影响可能是很明显的。

3.Adaptive Bitrate and Bandwidth Estimation

现代IP网络（包括无线和有线网络）的一个普遍问题是不可预测和不可靠的带宽。在整个会话过程中，网络条件可能会多次动态变化。在一秒钟之内看到可用的带宽急剧变化（差别达到数量级），这样的情况并不少见。

有线网络的不可预测性可能是由于网络带宽需求的变化，路由更改，传输介质（光纤通道，以太网，dsl）的限制等引起的。

除了在有线网络中存在的问题之外，无线电信号传输本身的特性，来自多个源的干扰，到手机信号塔或Wi-Fi接入点的距离以及物理障碍（阅读墙）也是导致无线网络特征无法预测的一些原因。

WebRTC具有多种机制，即使网络条件发生变化，也可以帮助将视频/音频信号顺利发送给接收方。其主要思路是根据预测的，当前的和将来的可用网络带宽来调整编码比特率。这样可以确保传输质量最佳的视频/音频信号，并且不会因为网络拥塞而断开连接。对网络行为建模并尝试对其进行预测的启发式方法称为带宽估计。

实现拥塞控制的第一个障碍是UDP和RTP不通信网络状态。作为一个发送者，我不知道我的包何时到达，或者它们是否到达！RTP/RTCP有3种不同的解决方案。他们都有自己的优点和缺点。

(a)Receiver Reports
Receiver Reports are RTCP messages, the original way to communicate network status. You can find them in RFC 1889. They are sent on a schedule for each SSRC and contain the following fields:

Fraction Lost – What percentage of packets have been lost since the last Receiver Report.自上一次接收者报告以来丢失数据包的百分比
Cumulative Number of Packets Lost – How many packets have been lost during the entire call.在整个呼叫过程中丢失了多少数据包
Extended Highest Sequence Number Received – What was the last Sequence Number received, and how many times has it rolled over.最后收到的序列号是多少
Interarrival Jitter – The rolling Jitter for the entire call.整个通话的滚动抖动

(b)TMMBR、TMMBN和REMB

The next generation of Network Status messages all involve receivers messaging senders via RTCP with explicit bitrate requests.

Temporary Maximum Media Stream Bit Rate Request - A mantissa/exponent of a requested bitrate for a single SSRC.
Temporary Maximum Media Stream Bit Rate Notification - A message to notify that a TMMBR has been received.
Receiver Estimated Maximum Bitrate - A mantissa/exponent of a requested bitrate for the entire session.

TMMBR and TMMBN came first and are defined in RFC 5104. REMB came later, there was a draft submitted in draft-alvestrand-rmcat-remb, but it was never standardized.

A session that uses REMB would look like the following

image.png

(c)Transport Wide Congestion Control
传输范围内的拥塞控制（TWCC）是在大多数浏览器中实现的高级拥塞控制规范。

TWCC使用一个非常简单的原则：

image.png

与REMB不同，TWCC的接收方不会尝试估计自己的传入比特率。它只是让发送方知道哪些包在何处及何时被接收。基于这些报告，发送方可以了解网络的最新的状况。

发送方创建带有特殊的TWCC标头扩展的RTP数据包，其中包含一个数据包序列号的列表。

接收方以特殊的RTCP反馈消息进行响应，以使发送方知道每个数据包是否以及何时被接收。
发送方跟踪已发送的数据包，包括它们的序列号，大小和时间戳。当发送方从接收方收到RTCP消息时，它将发送数据包间的延迟与接收延迟进行比较。如果接收延迟增加，则意味着网络正在发生拥塞，发送者必须对此采取行动。

在下图中，数据包间延迟的中位数增长了+20毫秒，这清楚地表明网络正在发生拥塞。

image.png

TWCC提供了原始数据和实时网络状况的绝佳视图：

几乎是即时的丢包统计信息，不仅包括丢失的百分比，还包括丢失的确切数据包。

准确的发送比特率。
准确的接收比特率。
抖动估计。
发送和接收数据包延迟之间的差异。

一种简单的，用于估计从发送方到接收方的传输比特率的拥塞控制算法是，将接收到的数据包大小相加，然后将其除以接收方一端经过的时间。

更复杂的拥塞控制算法建立在原始的TWCC数据的基础上，例如：一种用于实时通信的Google拥塞控制算法，简称GCC，由Google提出并在Chrome中实现。它通过使用Kalman过滤器预测当前和将来的网络带宽。

还有几种GCC的替代品，例如：NADA：一种实时媒体的统一拥塞控制方案和 SCReAM- 多媒体的自时钟速率自适应。

问：我如何知道TWCC已被支持并启用？

答：查看SDP offer/answer。如果您看到以下几行，则说明您的连接已经协商并启用了TWCC：

a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions

以及

a=rtcp-fb:96 transport-cc

RTSP RTP RTCP

一、RTSP抓包分析

1.OPTIONS

2.DESCRIBE

3.SETUP

4.PLAY

5.PAUSE 和 TEARDOWN

6.服务端回应的状态码结构体，跟http请求返回值类型码很类似

二、TCP UDP

1.区别

2.RTSP传输TCP包的两种方式

3.RTP/AVP

4.RTP/AVP/TCP

5.VLC RTSP网络串流播放失败

三、RTP 协议

四、RTCP

五、RTP/RTCP是如何解决问题的

1.Negative Acknowledgment

2.Forward Error Correction

3.Adaptive Bitrate and Bandwidth Estimation

你可能感兴趣的:(RTSP RTP RTCP)