rtcp webrtc 接收_WebRTC中的RTT

RTT(Round-Trip Time)往返时延，是网络通信的一个重要指标，本文介绍了WebRTC中是如何计算RTT的。

RTT本身是指一次通信在网络上花费的往返时间。例如，当我们说A和B的RTT为30ms时，意味着A发送了数据包到B，B返回数据包到A，一共花费了30ms。

这个计算过程似乎非常容易，但考虑以下问题：

问题1: B收到A的请求后，未必是立即返回的，B可能处理了一段时间才返回。

问题2: 通信是不可靠的，A发送给B的发送包可能丢失，B发送给A的返回包也可能丢失。需要确保当A收到过一次B的返回包，就可以计算出RTT。

解决问题1:

如图，比较直接的想法是：
A和B分别记录发送时间和接收时间，B在给A回包时带上处理延迟(即B_TS2-BTS1)，则A就可以减去B的处理时间。

那么RTT为：(A_TS2 - A_TS1) - (B_TS2 - B_TS1)

解决问题2:

在B回包时，将A_TS1连同B_TS2-B_TS1一起返回给A。这样不论A/B是否丢包，在发送端A只要收到一次B的返回，就能立刻利用当前时间戳计算出RTT=(A_TS2 - A_TS1) - (B_TS2 - B_TS1)。

理解了上述过程，再来看WebRTC中的做法。WebRTC使用RTP来传输音视频数据，用RTCP来发送控制信息。RTCP有五种标准数据包类型，其中和计算RTT相关的是SR(sender reports)和RR(receiver reports)这两种类型的包。

SR是由发送端A产生发往B，报文中携带了A的发送时间。

RR是接收端B产生，返回给A，报文中携带了A的发送时间和B的处理总时间。

看一下具体报文格式，SR的数据封装如下：

RR的数据封装如下：

与RTT计算相关的是报文中红色部分：

SR的NTP timestamp字段表示SR被发送的时间戳，等同于A_TS1。RR中LSR(Last SR)字段记录了最近一次接收到SR的时间，也就是A_TS1。RR中的DLSR(Delay since last SR)是B的处理延迟，即B_TS2-B_TS1的值。

因此A计算的RTT时间就是：

    RTT = now(A_TS2) - LSR - DLSR

以上就是WebRTC中对于RTT计算的过程。

还有一些细节故意被忽略了，这些过程并不影响理解RTT本身的计算，比如：

1) 在SR中发送的时间戳是64位的，而在RR中是32位的。这是因为对于LSR来说并不需要高精度的时间戳，webrtc将其处理到精度为毫秒的级别，可以节约传输长度。

2)接收端在产生RR时永远使用的是最新的SR信息(LSR)，这样在接收端仅需要维护最新的一个SR的信息。

3)RTT被计算后，并不会将一次的计算结果通知给观察者，会有一个平滑均值的计算过程。

4)A和B的时钟可能是不同步的，由于RTT计算的是差值，因此两边时钟不同步也没关系。