SFU级联在VOIP和会议模式下的应用

尽管一对一语言/视频通话的能力可以通过会议模式实现,但一对一模式还是较为特殊的应用场景(比方一对一打电话的时候,P2P网络会有优于服务器转发的情况),所以这里同时分析一对一和会议模式下SFU级联场景下的媒体包多路径转发问题,如下只提供一个思路,并非考虑实现;

 

Jitsi针对跨区域出现的星星拓扑问题,给出的解决方案是SFU级联的方式,详细可以参考文章

呱牛笔记 


菊风有个专利:CN104410509A_一种基于质量评价的多路径数据传输方法的思路可以延伸jitsi的多路径评价方法,实现了一种RTP转发最优路径选择的算法和思路;

呱牛笔记

图来源专利,居然被叫客户端写成了“主叫客户端”,专利还能审过,也真是绝了!


多路径主要包括,四条路径:

1:主叫客户端->主叫媒体服务器 -> 被叫媒体服务器  -> 被叫客户端

2:主叫客户端->主叫媒体服务器 ->被叫客户端

3:主叫客户端-> 被叫媒体服务器  -> 被叫客户端

4:主叫客户端-> 被叫客户端

不同路径选择评分算法不同,是可以规避菊风的专利范围的;

 

基于会议模式下的媒体包转发场景下,如果涉及多SFU级联,其实处理还是挺复杂的,比方:A如果分配的是SFU1, B分配的是SFU2, 并且限制最多只能有两个SFU充当级联转发功能,那么SFU1与SFU2之间其实只有一个选择,就是通过4096端口互相级联,并不涉及复杂的路由选择算法;

 

A  -  SFU1            SFU2  -  B     

 

如果涉及超过2个SFU级联,该如何处理?比方A连接SFU1、B连接SFU2、C连接SFU3,同一会议室的包如何转发?

 

A  -  SFU1 亚洲           欧洲SFU2  -  B          美洲SFU3  - C     

 呱牛笔记

 




后记: 

最近在学习Go语言,重点关注通过Go实现的网络服务框架,找到一个网关的实现项目fastway, 虽然我的第一印象是使用Go能很高效的实现一个支持大容量并发场景的网络服务器,但fastway的实现细节还是挺复杂的,对比看类似shikanon/socks5proxy的代码,就显得有些晦涩难懂了;复杂有复杂的原因,游戏场景下天然的高并发,fastway工程的实现还是很有参考价值的。

呱牛笔记

 

Gateway作为接入层,在网络架构中有蛮重要的地位,可以方便实现类似流控、负载均衡、甚至做到抗DDOS攻击等等能力,加上边缘计算等5G概念的应用,如果在边缘机房部署一个业务服务器,然后再实现转发等等逻辑,对原有业务的冲击和架构调整可想而知,如果只是部署一个Gateway,是不是简单高效,还能兼顾边缘机房靠近用户的特点;

 

将接入网关导进来,结合多SFU级联的思路,构建一个公网的音视频通信平台,或许是一个不错的思路。


本文为呱牛笔记原创文章,转载无需和我联系,但请注明来自呱牛笔记 ,it3q.com

请先登录后发表评论
  • 最新评论
  • 总共0条评论