什么是FEC/NACK/RTX

FEC (Forward Error Correction） 中文叫前向纠错

　前向纠错技术(Forward Error Correction)在确保信号的长距可靠传输方面也起着非常重要的作用，逐渐成为必不可少的主流技术。

这里借用光通讯的图来描述FEC的基本原理。

图1 FEC在光通信中的位置

　　FEC技术是一种广泛应用于通信系统中的编码技术。以典型的分组码为例，其基本原理是：在发送端，通过将k bit信息作为一个分组进行编码，加入（n-k）bit的冗余校验信息，组成长度为n bit的码字。码字经过信道到达接收端之后，如果错误在可纠范围之内，通过译码即可检查并纠正错误bit，从而抵抗信道带来的干扰，提高通信系统的可靠性。在光通信系统中，通过FEC的处理，可以以很小的冗余开销代价，有效降低系统的误码率，延长传输距离，实现降低系统成本的目的。

　　编码开销是校验位长度（n-k）与信息位长度k的比值，称为编码开销。开销越大，FEC方案的理论极限性能越高，但增加并不是线性的，开销越大，开销增加带来的性能提高越小。开销的选择，需要根据具体系统设计的需求来确定。

NACK（Non-Acknowledge）

说NACK前，我们先说说ACK。ACK实际上就是到达通知技术。大家都知道TCP是可靠的连接，他之所以可靠，那是因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。

NACK也是一种通知技术，只是触发通知的条件刚好的ACK相反，在未收到消息时，通知发送方“我未收到消息”，即通知未达。那么问题来了，接受者怎么知道自己未收到消息？

音视频数据包都是按时间顺序发送的，一般都带序号（升序排列的时间戳）。例如发送方按顺序发送了时间戳为60,120,180,240，320共五个包，接收者已经收到了60包，本来预期下一个接收的包的序号应该是序号120的包，但序号是120的包一直没收到，后面的包却收到了。那么接收者就可以判断，120这个包丢了，这时候接收方需要向发送方发出NACK消息（消息中带有丢包的序号，这里是120），让发送方重新发送丢失的包。

实时音视频传输都基于udp，包到达的顺序是不定的，具体是收不到包就马上出发NACK，还是说需要等待一小段时间看没到达的包是否会到达再决定是否发送NACK，这个具体要带webrtc的代码实现了。

webrtc RTX 处理

webrtc中默认开启rtx用于丢包重传，rtx的介绍可以参考rfc4588，https://tools.ietf.org/html/rfc4588#section-4

rtx使用额外的ssrc传输，ssrc在sdp中会标识出来。

↵a=rtpmap:97 rtx/90000
↵a=ssrc-group:FID 2736695910 239189782

类似这样。

一个RTX包，在turnserver中是这样的，原始udp数据->turn/stun协议头->RTP header1 ->RTP header2

在RTP header1中根据payload type进行区别RTP、RTX数据，如果是RTX的话，需要srtp解出后面的数据，再解析。

 

在客户端中，RTX封包的关键函数是：

https://code.google.com/p/webrtc/source/detail?r=4692
Channel::IsPacketRetransmitted
Channel::HandleRtxPacket
rtp_payload_registry_->IsRtx
RTPPayloadRegistry::RestoreOriginalPacket    移除RTX头, 还原原始的RTP

链接是，webrtc加入rtx的issue

 

目前webrtc的服务器，例如licode，janus是禁止rtx的。以避免复杂的处理。