xxxFEC方案瞬间丢包补偿达95%

http://www.ucpaas.com/news/201611/83.html


xxxFEC方案瞬间丢包补偿达95%

公网丢包的特点与传统解决办法


随着移动互联网的发展,各种基于互联网通讯的APP广泛应用,比如微信,有信等APP,而这些APP都不可避免面对公网上传输实时媒体流的丢包问题,而丢包是影响语音质量的主要因素。
如何解决公网媒体传输丢包的问题?在服务器的机房间拉专线,避开公网传输是有效直接的方案,但拉专线成本高,维护难,一般企业无法承受如此高昂的成本。云之讯的解决方案是通过技术手段解决公网传输丢包问题:在点对点的媒体转发服务器间动态启用FEC解决丢包问题。
 

公网丢包的特点:
 

1 瞬时丢包:丢包不严重,偶尔丢1到3个包,如图一, 此种情况对语音质量影响较小,完全可以通过FEC技术恢复丢包。
 

 
 
2 连续随机丢包:丢包较严重,影响到语音质量,如图2,此种丢包也完全可以通过FEC技术恢复丢包。
 
 
3 持续大量丢包:长时间地丢包,此情况,FEC技术不是很好地解决,可以通过智能路由技术,动态调整传输路径来解决这个问题。此技术不在本文讨论范围。
 

云之讯FEC公网动态丢包补偿解决方案

先来看下技术的架构设计
 
 
RTPP1、RTPP2分布为用户侧与落地侧的媒体转发服务器,受VBOSS系统控制。每个RTPP对接收的媒体流实时计算一个丢包率,比如每收到4个包计算一个丢包率,如发现有丢包,则立刻通过RTCP信令告诉发送端一个平滑丢包率,发送端根据平滑丢包率的大小发送一定倍数的FEC 冗余包,接收端解码FEC 冗余包获得丢失数据包的一个拷贝;当接收端监测到无丢包,则平滑丢包率逐步降为0,发送端收到平滑丢包率为0,则停止发送FEC冗余包。
 
发送端发送FEC包的冗余度根据平滑丢包率的大小动态调整FEC的倍数,丢包率越高,冗余的倍数越高;另外,在接收端监测到从无丢包到丢包时,默认发送一个较高的平滑丢包率给发送端,促使发送端到尽量发送倍数较大的FEC冗余包。
 
通过这种动态的机制,当在网络从无丢包到有丢包时能够立刻开启FEC功能,并且是发送较大的倍数冗余包,尽量补偿丢失的媒体包;当网络从有丢包到无丢包时,能够平滑过渡,逐渐减少FEC的冗余倍数,直到停止发送FEC冗余包,从而减少没必要的带宽成本。
 
在测试环境中,模拟瞬时丢包与连续随机丢包两种丢包的场景,验证该动态丢包补偿的效果,具体测试数据如下。
 

瞬时丢包测试数据: 

 

连续随机丢包测试数据:
 


 
 
通过以上两个的丢包场景的测试数据,动态的丢包补偿效果非常有效,瞬间丢包补偿率平均值95%以上,最高可达100%,固定随机丢包场景的补偿效率 随着模拟的丢包率逐渐增大而减少,在模拟60%丢包率以下,补偿效率可以达到90%以上。
 
另外,从线上系统运行的统计数据对比来看,也确定验证了动态丢包补偿的效果。比如,在线上系统,我们对接收的媒体流分别计算两个实时丢包率,一个为原始丢包率,一个为丢包补偿恢复之后的丢包率,然后统计每分钟的系统的丢包次数,具体对比数据如下。
 
下图为9月20号19点15分一次模拟丢包事件中丢包数据的对比,原始丢包数据为每分钟丢包次数达200次,而经过丢包补偿之后每分钟丢包次数降为0;
 



 
 
下图为9月21日15时另一次模拟丢包事件中丢包数据的对比,原始的丢包数据分钟丢包次数达600次,而经过丢包补偿之后每分钟丢包次数不超过20,丢包次数降低高达96.67%,为企业客户满意度提供了技术保障
 



 
综上所述,云之讯动态丢包补偿方案,对公网上传输的瞬时丢包与连续瞬即丢包两者场景达到很好的丢包补偿效果,实现了低成本与高语音质量两全其美。


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值