服务质量分析模型有什么 服务质量的五个标准( 七 )



总结一下,对于服务质量保障,首先提高网络质量,NACK和FEC解决丢包问题,JitterBuffer解决视频的乱序与抖动,NetEQ解决音频的乱序与抖动;带宽评估通过Goog-REMB和Goog-TCC,还有丢包的带宽评估;为了保障实时性,需要选择更优质的线路,比如客户端与服务端通信的时候选择更好的路线节点,保证云端网络带宽等等;从业务上,减少数据量可以用AV1、SVC、Simulcast、动态码率,减少业务;在防拥塞上,通过Pacer进行流控,只要能控制在500ms之内,适当增加时延也是可以接收的 。
以上就是本次分享的全部内容,谢谢!
Q&A (部分)
1. 路径的选择是WebRTC内部自动选择的吗?
是自动选择的 。WebRTC会自动判断通信的双方是否在同一个局域网内,如果是就直接在局域网内建立连接;如果不是,会通过STUN协议获取各自的外网地址,然后进行NAT穿越;如果还不成功的话,才会选择TURN服务进行数据中转 。
2. WebRTC网络传输质量衡量指标有什么?
衡量任何一个实时传输系统时,首要看它的时延是否达到500ms以内 。其实500ms对于实时通信而言,也是比较苛刻的标准了,因为网络的变化是非常大的,所以要实现这个指标其实难度也是蛮大的 。其次是丢包率,这是非常关键的指标,刚才说到2%的丢包率代表网络比较好;小于10%,对于WebRTC来说,代表目前的带宽是准确的;超过10%则代表发生了拥塞 。有些厂商说它的产品可以抗xx%的丢包,这样的前提是不认为丢包是一个指标,但在真网络中,当路由的缓冲被撑爆后,必然会出现大量丢包,如果不把丢包当作指标的话,就缺少了一种判断网络拥塞发生的条件,这显然是不合理的 。
3. 视频JitterBuffer怎么具体控制平滑的?
其实JitterBuffer平滑处理的难度并不像我们想像的那样复杂,之所以大家认为它复杂,可能是因为一些额外的因素,如还要处理音视频同步等问题 。对于平滑处理,我们完全可以自己通过一个Buffer来实现 。Buffer可以是动态大小或固定大小 。为了简化,我们假设它是固定大小,比如定义一个可以存放 100 个元素的数组,在数组的一头每隔 10 毫秒取一个包,这就是一个最简单的平滑处理 。当然更好的方式是可以根据网络的变化让这个平滑数组的大小也动态变化,这样就更高级一些 。当然,如果Buffer是动态变化的,那在计算平滑数组的动态大小时,会稍难一些 。
4. WebRTC要和SIP客户端通讯有什么好的方案?
一般与SIP通信最好借助流媒体服务器比如Janus,它既支持SIP协议也能支持WebRTC客户端 。这样SIP终端就可以将数据传输流媒体服务器,然后再转发给WebRTC终端了,同理WebRTC终端也可以通过流媒体服务器与SIP终端通信了 。
5. FEC和NACK默认是不是都要开启?
是的 。对于WebRTC来说,FEC和NACK都是开启的,也可以控制它们的开关 。
6. 能说下为什么TCC比REMB准确吗?
TCC和REMB主要有两个区别 。第一是计算的端不同,REMB是在接收端计算的,接收端计算后再将结果返回给发送端进行控制,而在回传结果时,可能网络又发生了新的变化,这就造成了REMB的及时性不够;TCC是将所有数据都交给发送端做计算和控制,因此及时性和准确度会更高 。第二是滤波器不同,REMB是卡尔曼滤波器(Kalman),TCC是最小二乘法滤波器(Trend line) 。最小二乘法滤波器在网络延时评估这方面比卡尔曼滤波器效果更好一些 。
7. 在内网环境下p2p想让延时尽可能小,可以做哪些工作?实验室环境最小延时可以达到100ms以下吗?
如果在同一个局域网内,实际只有几十毫秒的延迟 。有同学可能会疑惑,有的产品在同一局域网内延迟非常小,为什么用WebRTC反而延迟增大了?这就是因为WebRTC为保障网络质量,在内部通过多种机制,各种缓冲,来做到的 。所以它必然会产生一定的延迟,也就是拿延迟换质量 。而在局域网内,网络基本没有延时,不丢包、不抖动、不乱序 。这时什么策略都不采用,网络的传输才是最快的,因此在内网通信时,WebRTC的实时性一定不如什么策略都不加的产品好 。

推荐阅读