Qos.NACK
一、前言
RTP/RTCP协议是流媒体通信最基本协议。RTP协议定义流媒体数据在互联网上传输的数据包格式，而RTCP协议则负责可靠传输、流量控制和拥塞控制等服务质量保证。在很多项目中，如WebRTC中，RTP/RTCP模块作为传输模块的一部分，负责对发送端采集到的媒体数据进行进行封包，然后交给上层网络模块发送；在接收端RTP/RTCP模块收到上层模块的数据包后，进行解包操作，最后把负载发送到解码模块。RTP协议是Internet上针对流媒体传输的基础协议，该协议详细说明在互联网上传输音视频的标准数据包格式。
RTP协议本身只保证实时数据的传输，RTCP协议则负责流媒体的传输质量保证，提供流量控制和拥塞控制等服务。在RTP会话期间，各参与者周期性彼此发送RTCP报文。报文中包含各参与者数据发送和接收等统计信息，参与者可以据此动态控制流媒体传输质量。RFC3550 [1]定义RTP/RTCP协议的基本内容，包括报文格式、传输规则等。
二、NACK（Non-Acknowledge）
说NACK前，先说说ACK。ACK实际上就是到达通知技术。大家都知道TCP是可靠的连接，他之所以可靠，那是因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。
NACK也是一种通知技术，只是触发通知的条件刚好的ACK相反，在未收到消息时，通知发送方“我未收到消息”，即通知未达。那么问题来了，接受者怎么知道自己未收到消息？音视频数据包都是按时间顺序发送的，一般都带序号（升序排列的时间戳）。例如发送方按顺序发送了时间戳为60,120,180,240，320共五个包，接收者已经收到了60包，本来预期下一个接收的包的序号应该是序号120的包，但序号是120的包一直没收到，后面的包却收到了。那么接收者就可以判断，120这个包丢了，这时候接收方需要向发送方发出NACK消息（消息中带有丢包的序号，这里是120），让发送方重新发送丢失的包。
在WebRTC中，前向纠错(FEC)和丢包重传(NACK)是抵抗网络错误的重要手段。FEC在发送端将数据包添加冗余纠错码，纠错码连同数据包一起发送到接收端；接收端根据纠错码对数据进行检查和纠正。RFC5109[1]定义FEC数据包的格式。NACK则在接收端检测到数据丢包后，发送NACK报文到发送端；发送端根据NACK报文中的序列号，在发送缓冲区找到对应的数据包，重新发送到接收端。NACK需要发送端发送缓冲区的支持，RFC5104[2]定义NACK数据包的格式。
三、NACK协议
NACK报文是类型为205的RTCP 扩展反馈报文，在RFC4585中定义[4]。
*| 0 1 2 3 |
*| 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
*+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*|V=2|P| RC | PT=205 | length |
*
*+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*| SSRC of packet sender |
*+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+==+=+
*| SSRC of media source |
*+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*| PID | BLP |
*+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*
*/
其中PT = 205，FMT = 1，Packet identifier(PID)即为丢失RTP数据包的序列号，Bitmao of Lost Packets(BLP)指示从PID开始接下来16个RTP数据包的丢失情况。一个NACK报文可以携带多个RTP序列号，NACK接收端对这些序列号逐个处理。NACK报文构造完成以后，发送到网络层。NACK报文是RTCP报文的一种，因此其发送、接收和分析遵循RTCP报文处理的一般流程。
注意version, padding, blockcount, packettype, length , ssrc为公共头部分，即所有消息都具有，此头信息，而ssrcsource, pid, blp为NACK消息特有部分。
class NackStructor {
public:
uint32_tversion :2; //协议版本号（2bit）
uint32_t padding :1;
uint32_t fmt :5; //(5bit)在不同消息中叫法不同，也叫blockcount或RC，此处指格式
//format,在NACK消息中此值为1，之所以同时具有fmt和packettype
//是因为某些消息存在多级类型，比如当前的NACK消息属于Feedback
//类型。因此fmt=1(Feedback).
uint32_t packettype :8; //包类型（8bit）,NACK消息类型值为205,Feedback子类型
uint32_t length :16; //(16bit)消息长度
uint32_t ssrc; //构造发送当前消息包的端的SSRC，若本端是此NACK包的发送者，此
//SSRC值就是本端的SSRC值（源标识符）
uint32_t ssrcsource; //NACK消息部分，也是SSRC值，在此可称为媒体源标识符，用来指明
//此消息要反鐀谁的情况。比如我是接收端，我知道发送端的音频流
//（SSRC：1234）给我发来的数据包有丢包，我要反鐀对方音频流的
//情况，那这个地方就应该填写1234(对方音频流SSRC)。
uint32_t pid:16; //packet id(sequence number)详见下面PID-BLP图
uint32_t blp:16;
};
//在一个消息的一个公用头后面的NACK块部分可以有多个，每个NACK块可以反鐀1个流（SSRC）的情况。当然
1个NACK块中的blp部分也可以有多个。
四、WebRTC中实现NACK
（1）接收端的NACK报文构造和发送工作在ModuleProcessThread线程中周期性完成。
ModuleProcessThread线程周期性调用VideoReceiver::process函数，该函数通过VCMReceiver调用VCMJitterBuffer::GetNackList，从missing_seq_nums集合中得到过去一段时间内丢失RTP数据包的序列号。然后调用RtpStreamReceiver::ResendPackets函数。调用流程最终会到达RTCPSender::SendRTCP，发送类型为NACK的RTCP报文。
（2）接收端在接收和解析NACK报文后，通过回调机制处理各种类型的RTCP报文，对于NACK报文，会调用RTPSender重新发送RTP数据包，如图所示：
RTCPReceiver在解析RTCP之后，得到RTCP报文的描述结构，然后通过回调进行报文语义处理。NACK报文会被发送到RTPSender进行处理。RTPSender根据NACK报文中包含的序列号，到RTPPacketHistory缓存中查找对应的RTP数据包。如果找到，则把数据包发送到网络。至此，一个完整的NACK报文回路完成，丢失的RTP数据包会重新发送到接收端。
参考文献
[1] RFC5109 - RTP Payload Format for Generic Forward Error Correction.
[2] RFC5104 - RFC 5104 - Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
[3] WebRTC中RTP/RTCP协议实现分析 - http://www.jianshu.com/p/c84be6f3ddf3
[4] RFC4585 - Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)