WebRTC NACK 和 PLI
TCP 协议栈都要等对端的 ACK 确认，才能确定是否进行报文重传或者发送下一包数据
RTCP 当确认没有收到包是会像发起者发送 NACK 报文，让对方重发
// 所以 webrtc-rs 需要读取数据包，才能经过默认拦截器，才能自动发送 NACK
在网络环境不是太好的情况下，比如网络拥塞比较严重，丢包率可能比较高，简单实用 NACK 申请重传的机制，这样就会有大量的 RTCP NACK 报文，发送端收到相应的报文，又会发送大量指定的 RTP 报文，反而会增加网络的拥塞程度，可能导致更高的丢包率，导致接收端解码失败，导致花屏等马赛克现象。这时采用申请I帧的方式可能会解决马赛克等现象，申请的I帧方式主要PLI（Picture Loss Indication）和FIR（Full Intra Request）两种方式。由于I帧是关键帧，是图像内编码，图像比较大，占用较多的带宽，接收端在申请I帧时，不要刷I帧刷的太频繁（一般不小于5s），为了避免这种现象，有些厂家对接收端刷I帧刷的比较频繁，忽略掉部分FIR报文，即不响应部分I帧申请