數字化視頻會議系統的設計和實現

浙江省臺州市機關服務中心 段汝立

隨著5G網絡的不斷普及，數字化技術需要不斷優化視頻和音頻，以更高的音頻質量呈現給人們使用。人們對視頻的信息獲取需求越來越高，機關、企事業單位和高校對于線上視頻會議有很大的需求。除了機關單位常用的幾個視頻會議系統之外，在一些特定場景下，需要通過其他數字化視頻會議形式來提高工作效率。本文以WebRTC（Web實時交流）技術為框架，進行視頻會議的系統設計，實現一種可以進行資源動態伸縮的視頻會議系統。

4G移動網絡的普及以及5G移動網絡的開始普及，讓人們獲取信息的方式變得更加多樣化，用戶之間的交互方式也越來越多樣化，短視頻、直播等新的信息交互方式成為當前社會主流。在5G網絡開始普及后，視頻會議也需要相應地提高自身的音視頻質量，以便為用戶提供更加流暢的視頻會議體驗。當前市場中視頻會議軟件眾多，但是基本沒有基于WebRTC技術進行設計的視頻會議系統。WebRTC技術擁有更加多樣化的音視頻處理工具與網絡框架，可以更加方便地進行音視頻媒體服務，該系統可以為用戶提供多方視頻會議，降低了額外加載匹配的使用率，大大提高了使用便捷性。

1 數字化視頻會議系統功能性需求分析

1.1 會議管理系統功能性需求

在會議管理系統的功能模型中，主要分為4大功能，用戶管理、通訊錄、會議管理以及通知，如圖1所示。通過對整個管理模塊進行功能分析后，可以更好地利用會議管理系統的功能。通過圖1，直觀地展示出了系統模塊與各個用戶之間的交互關系[1]。

會議管理系統的用例表如表1[2]所示。

表1 會議管理系統用例表Tab.1 Use case table of conference management system

1.2 媒體服務器架構功能性需求

媒體服務器主要為視頻會議提供音視頻服務，需要與WebRTC框架兼容，為用戶提供音視頻服務，保證視頻會議的音視頻效果。媒體服務與WebRTC框架相連接，可以提供多人音視頻功能，并與音視頻流建立聯系。前端控制著音視頻流，給出房間號，讓媒體服務后臺使用。在音視頻流交互過程中，前端可以自行關閉音視頻流，并為用戶提供完整的音視頻方案。

2 數字化視頻會議系統總體設計

2.1 整體架構設計

視頻會議系統有兩大子系統，會議管理系統與媒體服務后臺系統，都是通過WebRTC框架進行互聯，兩者之間沒有交互功能，但是都具備一定的容錯性，為用戶提供不同的服務。會議管理系統主要對用戶進行管理，將唯一會議號反饋到前端，前端通過唯一會議號，將其返回到媒體服務集群中，完成媒體流的通訊功能[3]。

用戶首先進入到會議管理后臺進行訪問，后臺會對用戶的信息進行檢查和鑒別，檢查完畢后建立音視頻信息，通過會議號進行媒體服務后臺訪問，媒體服務后臺需要對會議號進行檢驗，查看其真實性，然后建立音視頻流，進行視頻會議。會議結束后，WebRTC會與媒體服務后臺斷開，媒體服務后臺會將會議進行存儲。WebRTC通過發送會議結束的消息通知會議結束。

2.2 會議管理系統模塊設計

（1）會議管理系統微服務模塊：在整個模塊中，均采用容器部署的形式，各個模塊之間通過Redis與RabbitMQ進行交互。存儲對象采用騰訊云的線上存儲服務，可以方便用戶隨時查看，大大的保證了文件的安全性。

（2）用戶管理模塊：為用戶提供服務，方便用戶進行注冊注銷、查詢、更新，還可以出現多端登錄情況的發生。用戶管理模塊主要對系統的用戶信息進行管理，當其他模塊需要進行用戶信息檢索時，需要提供相關驗證權限。

（3）通訊錄模塊：通過添加刪除、新建、修改、移動等操作，完成對用戶的管理。通過好友管理功能，為會議的管理提供便捷。主持人的功能就是方便對人員進行管理，通過添加和刪除好友操作，更好地進行人員管理[4]。

（4）會議管理模塊：會議管理模塊是在通訊錄模塊的基礎上，對通訊錄模塊中的好友進行人員篩選，讓參會人員可以在最短的時間加入到會議中。新建會議通過記錄會議信息，進行時間、會議人員的記錄。同時，通過會議識別碼的形式生成人數，方便后續的匿名用戶使用。

（5）通知模塊：為通訊錄模塊和會議管理模塊提供通知信息推送服務，保證用戶可以及時接收到會議消息并進行及時的操作。通知模塊主要通過Redis和RabbitMQ進行交互。

2.3 數據庫設計

通過對會議管理后臺的各個模塊進行分析后，需要有合理的數據庫設計，數據庫設計可以起到降低開發成本的效果，還可以保證上層數據可以得到更加準確的讀寫數據，從而提高存儲效果。數據庫設計需要對數據進行寫入、讀取、查詢以及修改，以保證數據的合理性，避免數據出現冗余。

會議管理系統需要的數據庫表很多，所有的數據表中都需要包含下列兩個字段，如表2[5]所示。

表2中的這兩個字段，是對表中的創建時間進行記錄，方便隨時對數據庫中的數據進行修改，保證效率。數據庫中大多數都是采用主鍵的方式進行字段添加，表與表之間主要通過業務代碼層進行聯系，以便更好地維護數據庫表并及時更新。

表2 所有數據表包含字段信息Tab.2 All data tables contain field information

2.4 媒體服務系統模塊設計

2.4.1 SFU（選擇性轉發單元）架構

SFU架構通過媒體服務器的形式進行對流，適用于小型視頻會議。主要讓所有的上行音頻流和視頻流都可以集中到媒體服務器中，完成對音視頻流的轉發，從而實現媒體流互通效果。SFU架構也可以作為一個WebRTC的Peer的客戶端，讓每一個客戶端的上行音視頻流都可以準確的發送到另一個客戶端或者媒體服務器中。

2.4.2 MCU（多點控制單元）架構

MCU架構適用于大型會議，起到混流、音視頻流隨意切換效果，與SFU不同，在MCU架構中，可以有多個用戶參與，上行音視頻流和下行音視頻流各有一條。擁有神的信令服務器和資源分配服務器，用于適配分布式架構操作。相較于SFU架構，增設了資源分配器可以更加便捷的對媒體服務器進行資源分配，減少服務器的壓力[6]。

2.4.3 動態負載均衡

動態負載均衡設計的目的是適配分布式架構的動態變化，當請求量增加時，分布式集群的節點數量也在增加，傳統的負載均衡器無法滿足需求，需要使用動態負載均衡器。動態負載均衡器分為SFU和MCU兩大部分，以MCU架構為例。在MCU架構中，同一會議中的所有用戶都需要在同一個媒體服務器下工作，這樣才可以讓資源分配器與動態負載均衡器更好的聯系在一起，當運行動態負載均衡時可以更好地分配用戶所需功能。

3 數字化視頻會議系統實現

3.1 會議管理系統實現

（1）用戶管理模塊主要對用戶的一系列操作進行管理，用戶可以通過用戶名或者手機進行登錄，禁止多賬戶同時登錄，極大地提高了用戶信息的安全性。刷新token，會自動記錄用戶瀏覽的內容，用于后續模塊驗證用戶的真實身份，以保證用戶在所登錄的時間內所有的行為合法。Controller層中，AuthController用于記錄用戶的登錄方式；UserController用于記錄用戶的登錄密碼；FileController用于用戶的頭像上傳。Service層根據業務完成對數據的記錄，并通過Controller進行使用。其中，authService用于驗證用戶密碼；UserService方便用戶查找所需功能；tokenService主要對token進行處理。

（2）通訊錄模塊主要對用戶進行管理、分組和群組管理，可以對用戶進行增加、刪除操作，通過通知模塊，還可以添加、拒絕好友。通過分組管理，對所有的分組信息進行整理，根據分組ID獲取好友。群組管理的功能不僅可以創建群組，還可以對群組中的信息進行修改，還可以獲取群組中全部成員的信息。

（3）會議管理模塊中，有兩大接口，ConferenceAction Controller和Conference UserController。其中，Conference ActionController對會議的狀態進行管理，通過Start、Cancel、Finish等函數進行管理。當管理會議狀態時，需要先獲取實體類，再進行會議狀態的修改。

ConferenceUserController對會議成員進行管理，當會議狀態未開始時，需要通過添加參會成員通知會議，通過invitedJoin函數，邀請成員加入會議，并記錄會議人數，該函數會對用戶的ID進行查找，并查詢會議狀態，根據會議狀態進行會議記錄并反饋信息；joinMeeting函數通過會議ID進入會議中，通過調用ConferenceAction Controller中的Get函數完成會議內容的獲取[7]。

（4）通知模塊主要為其他三個模塊進行服務，通過通知模塊，將所有的信息集合在一個模塊中改進型管理，并通過openAPI的方式將其提供給其他三個模塊。通知模塊的核心功能就是通知站內信息，通過WebSocket實現，通過Redis和RabbitMQ對信息進行緩存，通過MySQL數據庫對信息進行存儲。以WebSocket服務器作為主要服務器，對各類的信息進行處理，并更加快捷的增加通知事件。

3.2 媒體服務系統實現

SFU架構采用Coturn服務器進行音視頻流的轉發操作，MCU架構采用FreeSwitch進行音視頻服務，兩種架構本身就具備不同的性能測試，后臺架構在進行指標采集時，通過Prometheus監控該平臺獲取CPU、內存和帶寬的使用情況，通過Chrome瀏覽器中的WebRTC測試工具完成幀速率的指標采集。對于SUF而言，采用分布式架構，在進行CPU的使用時，每一個容器的CPU的使用情況都需要根據數量得到平均數。集群模式與單機模式相比，CPU的使用率并沒有受到很大影響。由于Coturn服務器需要通過網絡對UDP包進行轉發，當人數有所增加時，內存占用比降低，內存是隨著人數的變化而發生變化的。

MCU架構采用混流方式，因此CPU的使用率較高，相同并發人數使用的網絡帶寬降低。不管是哪一種架構模式，對于客戶端而言，都是為其提供相同的媒體服務，當人數較多的情況下，都可以有更好的速率為其使用，能夠處理更多的突發情況。

4 結語

總而言之，通過會議管理系統和媒體服務系統兩大部分，對視頻會議系統進行設計與實現，對會議管理系統的四大管理模塊進行詳細分析，并對其功能進行了闡述。隨后簡單介紹了媒體服務架構所用到的兩種實現方式，在保證功能完整的情況下，提高系統的使用率，實現媒體資源的動態伸縮功能。