XSWITCH大规模视频会议解决方案

　　我们在开发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，再转回来。因为毕竟协调几百个机顶盒重新呼叫一遍也是很难的。