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级联的思路，构建一个公网的音视频通信平台，或许是一个不错的思路。