音视频传输(RTP/RTCP)丢包重传(NACK)，以及I帧申请(PLI，FIR)

学过TCP通信原理的同学都知道，TCP没法送一个TCP报文，TCP协议栈都要等对端的ACK确认，才能确定是否进行报文重传或者发送下一包数据；然而RTCP的NACK重传机制与TCP的确认机制整好相反，当RTP接收端发现某一包数据或者N包数据确实没有收到，即在经过中间网络设备时丢掉了，接收端才会向发送端发送RTCP的NACK报文，向发送端要求重传相应的RTP包，NACK报文如下：

特别注意，使用NACK重传机制的收发双发，RTP都有一个发送缓冲区和接收缓冲区，缓冲区有缓冲区大小，发送太迟的NACK申请报文无效，另外，发送缓冲区主要用来处理申请重传请求，接收缓冲区一般用于对乱序或重传的RTP进行重新排序，然后再将排序好的报文送到解码器进行解码。

在网络环境不是太好的情况下，比如网络拥塞比较严重，丢包率可能比较高，简单实用NACK申请重传的机制，这样就会有大量的RTCP NACK报文，发送端收到相应的报文，又会发送大量指定的RTP报文，反而会增加网络的拥塞程度，可能导致更高的丢包率，导致接收端解码失败，导致花屏等马赛克现象。这时采用申请I帧的方式可能会解决马赛克等现象，申请的I帧方式主要PLI（Picture Loss Indication）和FIR（Full Intra Request）两种方式，FIR又包括RFC2032和RFC5104规定的两种方式，其中RFC5104规定的FIR报文比较常用。一般发送端在收到接收端发送过来的RTCP PLI报文，按申请I帧处理，当然收到FIR报文，就是申请I帧，PLI报文和FIR（RFC5104）的报文如下图：

注意事项：有些厂家可能不支持PLI，只支持FIR，需要根据双方实际的SDP报文就行协商；另外，由于I帧是关键帧，是图像内编码，图像比较大，占用较多的带宽，接收端在申请I帧时，不要刷I帧刷的太频繁（一般不小于5s），为了避免这种现象，有些厂家对接收端刷I帧刷的比较频繁，忽略掉部分FIR报文，即不响应部分I帧申请。