我们在开发FreeSWITCH视频会议系统的过程中,经常遇到智慧党建相关的视频会议需求。考虑到会议规模比较大,FreeSWITCH的转码性能又不好,就一直没敢接。后来有老朋友找到我们,不好拒绝,就做了一套解决方案,两年多过去了,运行良好,也走了一些弯路,在此跟大家分享一下。
会议的使用场景大致是从上到下开大会,区县级组织部为主会场,开到乡镇及行政村。主会场的视频发送到下级,同时主会场可以随时查看各分会场视频,了解大家参会及学习情况。除了集体讲课外,还有互动讨论等,可以选择不同的会场发言。
我们全部使用SIP解决方案。在硬件选择上,主会场我们使用了GrandStream GXV3202设备,支持SIP视频会议及双流。村镇级会场酌情使用GXV3202或质优价廉的机顶盒。
我们使用FreeSWITCH做为视频会议的平台。但是,FreeSWITCH单机无法支撑大规模的转码会议,项目又比较紧急。所以,我们最初采用了最简单的视频会议方式,即不转码,不融屏,仅做视频转发的方式。这种方式有很多限制,比如所有参会方只能看到相同的内容,我们也没法打字幕。我们实现了一个Web界面,可以自动轮循切换所有会场,算是在一定程度上解决了第一个问题,字幕的解决方案就是在会场现场后面挂横幅或者放桌牌。
毕竟是能开会了,我们也在单机上做到了大约400路并发的规模,开了三次会,都比较成功。
在开会的过程中,我们抓紧开发能转码融屏的会议。首先要解决的问题就是多机会议串联。我们采用了一主多从的结构。即主会场全部拨入主服务器,而下级分会场拨入从服务器。主服务器和从服务器的会议室串联。为了避免出现「看对眼」(即一路视频信号上行又下行看到的画面会无限循环)的情况,也是为了解决不同会场看不同画面,我们采用两个画布实现——上行视频永远在画布2上,下行视频永远在画布1上。
实验成功,最后我们用了5台服务器搭建了一个集群,可以转码融屏,也可以打字幕了。但,这只是我们恶梦的开始。
首先我们发现机顶盒顶不住了,经常会出现花屏、卡顿,甚至死机。机顶盒版本比较老,上面有一个SIP终端软件,是第三方开发的,对于我们来讲就相当于一个黑盒子,除了不断地测试修改各种视频参数,我们确实也没有更好的办法进行调试。不过,在经过无数次的实验后,我们还是找到了一些可行的参数,做到了720p高清视频,质量不是最优,但是也算是足够好了。
主会场实拍
大规模系统的另一个难点就是测试,虽然我们也部署了自动化的测试,但测起来跟真实的场景数据有诸多出入,后来还是部署了人肉方式,放了一大批机顶盒实际入会测试。
机顶盒测试
项目是跟山东有线合作的,他们有很好的网络基础设施,人员配合也很到位。但无论如何并发就是上不去。又经过无数有猜测与调试,请教了业界高人的情况下把问题基本定位到Linux内核的瓶颈。这……好像有点超纲了。一次偶然的机会换了台机器测试,发现网络瓶颈竟然不存在了,原因只是那台机器的网卡不一样。后来,我们把所有服务器都换成了那个型号的网卡。
在实现过程中,我们也给FreeSWITCH打了一些补丁,主要是完成级联的控制,以及修复一些Bug,做了一些优化。比如与会者比较多,在大部分会场不上镜(没有人看该会场的画面)的情况下,我们就停止对该会场的视频进行解码,以节省CPU。
当然,在打补丁的过程中我们也成功地植入了自己的Bug。在第一次上线的时候,测试了一整天,到了晚上临近开会的时候,发现内存在默默地增长,如此下去,根本撑不过晚上的会议,一身汗。好在我们提前部署了sofia recover,直接强制所有FreeSWITCH崩溃,重启后仅有少数会场掉线,避免了最大的灾难,顺利撑过了两个多小时的会议。
会后我们连夜把内存泄漏给修复了,至此,视频会议系统算是可以交差了。又经过几轮优化,现在,我们的平台已经有了正式的名称,叫XSWITCH。
后来我们也实现了很多热修复的手段,比如将所有在线的用户都转到echo Application,修复后reload mod_conference,再转回来。因为毕竟协调几百个机顶盒重新呼叫一遍也是很难的。
下图是多级级连示意图。主会场采集的视频图像放到主服务器的画布1上,下发到从服务器进而下发到终端。各终端图像首先汇聚到从服务器画布2上,上行到主服务器画布2,主会场随时可以选择观看画布1或画布2。
多级级连示意图
使用这种方案,在终端数量增多时我们可以线性横向扩展。
会议系统运行以来,状态良好。最近,我们完成了为期三天的视频会议保障,涉及到600多个终端(乡镇及行政村),万名党员,顺便采集到一些技术数据。
下图是某服务器200多个终端的带宽情况。
某服务器200+终端
下图是综合视图。
会控界面显示该会议中共有434个终端入会。
会控界面
会控界面显示各服务器的统计情况。显示该会议中共有504个终端入会。
CPU内存的监控情况。