1.前言
在WebRTC中，我们需要对当前的音视频情况进行监控，便于对音视频质量有一个了解，同时可以用来分析定位音视频卡顿模糊等问题。WebRTC提供了一个标准的解决方案：标准详情,基于此标准Kurento也提供了一套实现方案，接下来就来具体介绍一下。
2. 序列图
依照上述时序图openvidu这块步骤分为2步：
第一步创建媒体通道时开启WEBRTC统计信息：
pipeline.setLatencyStats(true);
第二步端点调用getStats方法并处理返回Map类型的数据，重点在第二步上面。
其中getStats方法可分别获取video流，audio流，data数据的质量统计,其中返回的Map数据里面以键值对的形式包含有所需要的数据。
列表如下：
l ssrc：同步源（SSRC）。
l firCount：计算发送方收到的完整内部请求（FIR）数据包的总数。此指标仅对视频有效，并由接收方发送。
l pliCount：计算发送方接收并由接收方发送的数据包丢失指示（PLI）数据包的总数。
l nackCount：计算发送方接收到并由接收方发送的否定确认（NACK）数据包的总数。
l sliCount：计算发送方接收的切片丢失指示（SLI）数据包的总数。此指标仅对视频有效，并由接收方发送。
l remb：接收器估计的最大比特率（REMB）。此指标仅对视频有效。
l packetLost：此SSRC丢失的RTP数据包总数。
l packetReceived：为此SSRC接收的RTP数据包总数。
l bytesReceived：为此SSRC接收的字节总数。
l jitter：此SSRC的数据包抖动（以秒为单位）。
l packetSent：为此SSRC发送的RTP数据包总数。
l bytesSent：为此SSRC发送的字节总数。
l targetBitrate：此SSRC当前配置的比特率目标，以每秒比特数为单位。
l roundTripTime：基于RTCP时间戳，此SSRC的估计往返时间（秒）。
l audioE2ELatency：端到端音频延迟（以纳秒为单位）。
l videoE2ELatency：端到端视频延迟（以纳秒为单位）。
l inboundrtp：KMS中收到的流的统计信息。
l outboundrtp：KMS发送的流的统计信息。
3. 注意事项
网络质量衡量的是网络链路的强度，而不是用户对视频或音频的实际感知。这一区别很重要：即使面对非常糟糕的网络链接，WebRTC仍包含非常先进的机制来尝试调整传输，但是并不能保证这些机制足以提供无缝的体验。在最佳情况下，没人会注意到，视频或音频流将以高质量进行，好像什么也没发生。否则，视频和音频可能会断断续续，并且整体质量会下降。
4.结束语
关于openvidu实现网络质量检测统计的分享就到这里咯。还请各位观众老爷多多交流指正哦。