WebRTC的丢包计算方法

背景

目前WebRTC的版本主要还是基于GCC的拥塞控制，发送端需要根据丢包率控制发送码率，而丢包率是在接收端计算并通过RR(Receiver Report RTCP)包通知发送端。

版本

问题

重传包可能会影响丢包率，如果发送端重传的包都被接收端收到，并且接收端没有区分重传包，那么丢包率会是0，与实际的网络状态不符，发送端也无从控制发送码率。

丢包与NACK、RTX的关系

在使能RTX的情况下，发送端的重传包会使用新的SSRC通过RTX发送，这些包并不会被计入正常的接收包，这样接收端丢包率的计算是天然正确的。
在没有使能RTX的情况下，发送端的重传包就在原来的SSRC上简单重传，接收端没有办法通过什么特殊标识区分是否是重传包，而是以接收到包的时间戳以及估算的RTT来判断是否是重传包。

判断当前包是否重传包的算法

t1=上一个未乱序的包到当前包时间戳的时间间隔
t2=上一个未乱序的包到当前时间的时间间隔
如果t2 > t1 + f(rtt)则认为当前包是重传包，f(rtt)是rtt的线性函数，目前f(rtt)=rtt/3+1。
直观解释就是，当前包的时间戳已经是过去的时间，其加上f(rtt)后仍然是过去的时间，说明可能是接收端通过NACK通知发送端发送的重传包(可能经过了一个rtt)，可以认为是重传包。

丢包的计算

1. 接收端维护两个计数器，每收到一个RTP包都更新：

transmitted，接收到的RTP包的总数；
retransmitted，接收到重传RTP包的数量；

2.某时刻收到的有序包的数量Count = transmitted-retransmitte ，当前时刻为Count2，上一时刻为Count1;

3.接收端以一定的频率发送RTCP包（RR、REMB、NACK等）时，会统计两次发送间隔之间(fraction)的接收包信息：
//两次发送间隔之间理论上应该收到的包数量=当前接收到的最大包序号-上个时刻最大有序包序号
  uint16_t exp_since_last = (received_seq_max_ - last_report_seq_max_);

  //两次发送间隔之间实际接收到有序包的数量=当前时刻收到的有序包的数量-上一个时刻收到的有序包的数量
  uint32_t rec_since_last = Count2 - Count1

  //丢包数=理论上应收的包数-实际收到的包数
  int32_t missing = exp_since_last - rec_since_last

missing即为两次发送间隔之间的丢包数量，会累加并通过RR包通知发送端。

RR中的丢包

接收端发送的RR包中包含两个丢包，一个是fraction_lost，是两次统计间隔间的丢包数，一个是cumulative_lost，是总的累积丢包。发送端收到后在状态统计Stats中看到的是累积丢包，而在计算发送码率的时候更多的是使用分段丢包fraction_lost，因为其属于比较实时的参数。