會議的使用場景大致是從上到下開大會，區(qū)縣級組織部為主會場，開到鄉(xiāng)鎮(zhèn)及行政村。主會場的視頻發(fā)送到下級，同時主會場可以隨時查看各分會場視頻，了解大家參會及學(xué)習(xí)情況。除了集體講課外，還有互動討論等，可以選擇不同的會場發(fā)言。
我們?nèi)渴褂肧IP解決方案。在硬件選擇上，主會場我們使用了GrandStream GXV3202設(shè)備，支持SIP視頻會議及雙流。村鎮(zhèn)級會場酌情使用GXV3202或質(zhì)優(yōu)價廉的機(jī)頂盒。
我們使用FreeSWITCH做為視頻會議的平臺。但是，F(xiàn)reeSWITCH單機(jī)無法支撐大規(guī)模的轉(zhuǎn)碼會議，項目又比較緊急。所以，我們最初采用了最簡單的視頻會議方式，即不轉(zhuǎn)碼，不融屏，僅做視頻轉(zhuǎn)發(fā)的方式。這種方式有很多限制，比如所有參會方只能看到相同的內(nèi)容，我們也沒法打字幕。我們實現(xiàn)了一個Web界面，可以自動輪循切換所有會場，算是在一定程度上解決了第一個問題，字幕的解決方案就是在會場現(xiàn)場后面掛橫幅或者放桌牌。
畢竟是能開會了，我們也在單機(jī)上做到了大約400路并發(fā)的規(guī)模，開了三次會，都比較成功。
在開會的過程中，我們抓緊開發(fā)能轉(zhuǎn)碼融屏的會議。首先要解決的問題就是多機(jī)會議串聯(lián)。我們采用了一主多從的結(jié)構(gòu)。即主會場全部撥入主服務(wù)器，而下級分會場撥入從服務(wù)器。主服務(wù)器和從服務(wù)器的會議室串聯(lián)。為了避免出現(xiàn)「看對眼」（即一路視頻信號上行又下行看到的畫面會無限循環(huán)）的情況，也是為了解決不同會場看不同畫面，我們采用兩個畫布實現(xiàn)——上行視頻永遠(yuǎn)在畫布2上，下行視頻永遠(yuǎn)在畫布1上。
實驗成功，最后我們用了5臺服務(wù)器搭建了一個集群，可以轉(zhuǎn)碼融屏，也可以打字幕了。但，這只是我們惡夢的開始。
首先我們發(fā)現(xiàn)機(jī)頂盒頂不住了，經(jīng)常會出現(xiàn)花屏、卡頓，甚至死機(jī)。機(jī)頂盒版本比較老，上面有一個SIP終端軟件，是第三方開發(fā)的，對于我們來講就相當(dāng)于一個黑盒子，除了不斷地測試修改各種視頻參數(shù)，我們確實也沒有更好的辦法進(jìn)行調(diào)試。不過，在經(jīng)過無數(shù)次的實驗后，我們還是找到了一些可行的參數(shù)，做到了720p高清視頻，質(zhì)量不是最優(yōu)，但是也算是足夠好了。
主會場實拍
多畫面
多畫面
大規(guī)模系統(tǒng)的另一個難點就是測試，雖然我們也部署了自動化的測試，但測起來跟真實的場景數(shù)據(jù)有諸多出入，后來還是部署了人肉方式，放了一大批機(jī)頂盒實際入會測試。
機(jī)頂盒測試
項目是跟山東有線合作的，他們有很好的網(wǎng)絡(luò)基礎(chǔ)設(shè)施，人員配合也很到位。但無論如何并發(fā)就是上不去。又經(jīng)過無數(shù)有猜測與調(diào)試，請教了業(yè)界高人的情況下把問題基本定位到Linux內(nèi)核的瓶頸。這……好像有點超綱了。一次偶然的機(jī)會換了臺機(jī)器測試，發(fā)現(xiàn)網(wǎng)絡(luò)瓶頸竟然不存在了，原因只是那臺機(jī)器的網(wǎng)卡不一樣。后來，我們把所有服務(wù)器都換成了那個型號的網(wǎng)卡。
在實現(xiàn)過程中，我們也給FreeSWITCH打了一些補(bǔ)丁，主要是完成級聯(lián)的控制，以及修復(fù)一些Bug，做了一些優(yōu)化。比如與會者比較多，在大部分會場不上鏡（沒有人看該會場的畫面）的情況下，我們就停止對該會場的視頻進(jìn)行解碼，以節(jié)省CPU。
當(dāng)然，在打補(bǔ)丁的過程中我們也成功地植入了自己的Bug。在第一次上線的時候，測試了一整天，到了晚上臨近開會的時候，發(fā)現(xiàn)內(nèi)存在默默地增長，如此下去，根本撐不過晚上的會議，一身汗。好在我們提前部署了sofia recover，直接強(qiáng)制所有FreeSWITCH崩潰，重啟后僅有少數(shù)會場掉線，避免了最大的災(zāi)難，順利撐過了兩個多小時的會議。
會后我們連夜把內(nèi)存泄漏給修復(fù)了，至此，視頻會議系統(tǒng)算是可以交差了。又經(jīng)過幾輪優(yōu)化，現(xiàn)在，我們的平臺已經(jīng)有了正式的名稱，叫XSWITCH。
后來我們也實現(xiàn)了很多熱修復(fù)的手段，比如將所有在線的用戶都轉(zhuǎn)到echo Application，修復(fù)后reload mod_conference，再轉(zhuǎn)回來。因為畢竟協(xié)調(diào)幾百個機(jī)頂盒重新呼叫一遍也是很難的。
下圖是多級級連示意圖。主會場采集的視頻圖像放到主服務(wù)器的畫布1上，下發(fā)到從服務(wù)器進(jìn)而下發(fā)到終端。各終端圖像首先匯聚到從服務(wù)器畫布2上，上行到主服務(wù)器畫布2，主會場隨時可以選擇觀看畫布1或畫布2。
多級級連示意圖
使用這種方案，在終端數(shù)量增多時我們可以線性橫向擴(kuò)展。
會議系統(tǒng)運(yùn)行以來，狀態(tài)良好。最近，我們完成了為期三天的視頻會議保障，涉及到600多個終端（鄉(xiāng)鎮(zhèn)及行政村），萬名黨員，順便采集到一些技術(shù)數(shù)據(jù)。
下圖是某服務(wù)器200多個終端的帶寬情況。
某服務(wù)器200+終端
下圖是綜合視圖。
會控界面顯示該會議中共有434個終端入會。
會控界面
會控界面顯示各服務(wù)器的統(tǒng)計情況。顯示該會議中共有504個終端入會。
CPU內(nèi)存的監(jiān)控情況。
以上只是部分統(tǒng)計數(shù)據(jù)。當(dāng)時服務(wù)器上還有其它并行的會議在開。總得來看，由于我們做了轉(zhuǎn)碼優(yōu)化，CPU反而沒有什么瓶頸了，而瓶頸在于網(wǎng)卡。我們暫時使用上行2M下行1M的碼率，理論上千兆的網(wǎng)卡可以支撐500路，或打8折400路的并發(fā)。我們暫時最大只跑了200多路，潛力有待進(jìn)一步驗證。
下一步的優(yōu)化方案也很清晰：
增加一塊網(wǎng)卡可以提高一倍并發(fā)
使用動態(tài)碼率控制，在參會方不上鏡的時候降低碼率或停發(fā)視頻，但需要客戶端配合
感謝各位領(lǐng)導(dǎo)的信任與支持，也感謝所有黨員同志們的大力支持。我們一定不會放過持續(xù)優(yōu)化的機(jī)會，爭取發(fā)揮出硬件最大的性能，這是我們程序員的追求，也是我們的責(zé)任。
cpuinfo，懂的看 ;）
processor: 63
vendor_id: GenuineIntel
cpu family: 6
model: 79
model name: Intel（R） Xeon（R） CPU E5-2683 v4 @ 2.10GHz
stepping: 1
microcode: 0xb000021
cpu MHz: 1200.219
cache size: 40960 KB
physical id: 1
siblings: 32
core id: 15
cpu cores: 16
apicid: 63
initial apicid: 63
fpu: yes
fpu_exception: yes
cpuid level: 20
wp: yes
flags: fpu vme de …
bugs:
bogomips: 4201.09
clflush size: 64
cache_alignment: 64
address sizes: 46 bits physical, 48 bits virtual
power management:
關(guān)于FreeSWITCH視頻會議相關(guān)的技術(shù)，很久以前在易靈微課上講過一次課：《是的，我們在做視頻會議》，歡迎閱讀。
煙臺小櫻桃科技是FreeSWITCH開源項目的核心貢獻(xiàn)者，文中提到了很多補(bǔ)丁都已提交到FreeSWITCH的源代碼倉庫。
煙臺小櫻桃科技招聘FreeSWITCH相關(guān)開發(fā)及運(yùn)維實施人員，如果有興趣加入我們，歡迎發(fā)郵件到 jobs@x-y-t.cn。
煙臺小櫻桃科技提供專業(yè)的FreeSWITCH技術(shù)支持及呼叫中心解決方案。歡迎參觀，郵件info@x-y-t.cn。
另外，我們將于11月22日在北京搞事情，歡迎參加：第八屆FreeSWITCH-CN開發(fā)者沙龍
如果您對具體的技術(shù)感興趣，也歡迎參加我們的FreeSWITCH培訓(xùn)：FreeSWITCH高級培訓(xùn)冬季班-北京站
