基于WebRTC的視頻會議系統(tǒng)開發(fā)

石芮 成洪豪 孫立民

摘要：現(xiàn)行視頻會議系統(tǒng)在實現(xiàn)視頻會議功能時，大都需要特定的客戶端軟件支持，造成不同客戶端之間無法進行音視頻通信。針對該問題，本文設(shè)計并實現(xiàn)了一套基于WebRTC（Web Real-Time Communication，WebRTC）的多人視頻會議系統(tǒng)。該系統(tǒng)采用基于集中混合型視頻模型實現(xiàn)，該模型對終端用戶減少了帶寬要求，并且，各終端音視頻流在混流前可以進行靜音壓縮，增強系統(tǒng)靈活性。結(jié)合依托于Kurento的WebRTC作為中間流媒體服務(wù)器的支持，實現(xiàn)媒體路由/調(diào)度的組通信，用于多人視頻通信技術(shù)。通過將系統(tǒng)投放到實際單位使用檢測表明，該系統(tǒng)在多人會議方面系統(tǒng)運行穩(wěn)定，視頻畫面清晰。

關(guān)鍵詞：WebRTC;即時通信;多人視頻會議;Kurento;會議模型

0引言

現(xiàn)行用于視頻會議系統(tǒng)的軟件，大多是安裝在設(shè)備上的基于C/S構(gòu)架的獨立應(yīng)用程序。傳統(tǒng)視頻會議功能類的軟件都需要有特定的客戶端軟件支持，如微信、QQ、SLype。這就會造成不同客戶端之間無法進行音視頻通信，無疑加大了硬件端的負載。復(fù)雜的視頻編解碼問題、通信協(xié)議、回聲消除、去噪等復(fù)雜性很高的專業(yè)性問題，是傳統(tǒng)視頻通信類軟件所面臨的難題。而自GooCle推出web實時通信技術(shù)（web Real -Time Communication，webRTC）以來，這種能夠跨平臺通信的開源技術(shù)，能夠直接為web瀏覽器提供支持語音和視頻會議及數(shù)據(jù)共享的能力，無需下載專用應(yīng)用軟件或插件?，F(xiàn)階段各大瀏覽器都實現(xiàn)了對webRTC的支持，Google Chrome、Mozilla Firefox、Microson Edge、AppleSafari等等，不同瀏覽器視頻通信可以相互兼容，視頻會議向著跨瀏覽器視頻通信的方向發(fā)展，使得視頻會議系統(tǒng)更加方便、更加易于獲得，以滿足用戶需求。憑借以上技術(shù)優(yōu)勢，WebRTC即將成為新一代實時音視頻通信的技術(shù)標(biāo)準(zhǔn)。

本文介紹了webRTC的總體架構(gòu)與關(guān)鍵技術(shù)，闡明了web應(yīng)用中信令層與媒體層邏輯關(guān)系，并完善WebRTC應(yīng)用中媒體層面實現(xiàn)的不足。采用kurento新型媒體服務(wù)器將WebRTC與現(xiàn)有的服務(wù)器模型相結(jié)合并實現(xiàn)其在實際系統(tǒng)中的應(yīng)用。開發(fā)基于webRTC的視頻會議系統(tǒng)，對研究和開發(fā)基于IP網(wǎng)絡(luò)的跨瀏覽器視頻通信具有重要的價值和意義。

1 關(guān)鍵技術(shù)介紹

1.1 WebRTC

作為網(wǎng)絡(luò)視頻的一項新技術(shù)。WebRTC不是服務(wù)。也不是應(yīng)用程序，是一個支持網(wǎng)頁瀏覽器進行實時語音對話或視頻對話的API，WebRTC的總體結(jié)構(gòu)分為三大部分：開發(fā)者基于實際開發(fā)多媒體應(yīng)用的Webapp層、封裝有通信協(xié)議及媒體處理引擎模塊的Web API層、由瀏覽器商自主實現(xiàn)的輸入輸出層。

在WebApp層，開發(fā)者根據(jù)自己的意愿選擇開發(fā)實時音視頻通信的多媒體應(yīng)用，開發(fā)使用的多媒體應(yīng)用大多基于集成了Web API的瀏覽器。

Web API層集成了實時音視頻通信所需要的通信協(xié)議與媒體處理引擎。通信協(xié)議由承載協(xié)議和信令協(xié)議兩部分組成：承載協(xié)議使用Websocket全雙工通信協(xié)議，一次握手建立連接后便始終保持連接，在建立的全雙工連接上傳輸數(shù)據(jù)：信令協(xié)議使用SDP協(xié)議與JSEP協(xié)議對音視頻通話進行會話控制與媒體協(xié)商。SDP消息中包含了媒體協(xié)商必需的相關(guān)參數(shù)，JSEP（Java Session Establishment Protocol）協(xié)議對音視頻通話開啟會話控制。

輸入輸出層實現(xiàn)音視頻捕獲與媒體信息流的讀取，此部分由瀏覽器廠商根據(jù)自己的需求進行自定義。

1.2 kurento

Kurento是一個WebRTC媒體服務(wù)器和一組客戶端API。其完善了webRTC媒體處理引擎，提出一個多媒體框架。簡化Web和智能手機平臺的高級視頻應(yīng)用程序的開發(fā)。

提供多種方法改進升級原有WebRTC多媒體應(yīng)用程序：在原有的媒體處理技術(shù)基礎(chǔ)上，音頻編碼器中使用Opus編碼器代替?zhèn)鹘y(tǒng)的iSAC與iLBC編碼器，其可以覆蓋人類聽覺系統(tǒng)整個范圍，采樣支持從8-（4kHz帶寬）48kHz（20kHz全頻）的采樣率，支持固定比特率和6-510kbps可變比特率，幀大小從2.5-60毫秒：視頻編碼器中使用H。264視頻編解碼器，視頻傳輸時被組織成網(wǎng)絡(luò)抽象層單元（“NAL單元”），使用面向字節(jié)流格式或面向分組格式傳輸：視頻編解碼延時小于200ms，滿足實時視頻通信的低延遲特性要求。采用MKV格式（Matroska容器格式）用于錄制。在傳輸方面，kurento可以管理標(biāo)準(zhǔn)RTP/RTCP流，實現(xiàn)網(wǎng)絡(luò)的傳輸與流控等功能，SRTP/SRTCP流為傳輸?shù)臄?shù)據(jù)提供加密、消息認證、完整性保證和重放保護。此外使用Gstreamer支持任何編解碼器之間的自動媒體轉(zhuǎn)碼。

2視頻會議系統(tǒng)分析

2.1 視頻會議系統(tǒng)的需求分析

為了實現(xiàn)在盡可能減少帶寬使用率的前提下，對一場群組視頻會議的管理，系統(tǒng)遵循著完備性、正確性和邏輯性的原則。并根據(jù)視頻會議的具體功能和業(yè)務(wù)流程分析核心業(yè)務(wù)需求。

2.2 視頻會議系統(tǒng)業(yè)務(wù)流程

根據(jù)上述具體功能分析。得出群組視頻會議業(yè)務(wù)流程如圖1所示。可以通過接受kurento媒體服務(wù)器發(fā)起的視頻呼叫進入規(guī)定的會議：也可以通過訪問kurento媒體服務(wù)器的URL進入當(dāng)前會議。

3 視頻會議系統(tǒng)模型實現(xiàn)

3.1 視頻會議系統(tǒng)模型設(shè)計

視頻會議模型根據(jù)信令服務(wù)器與媒體服務(wù)器對節(jié)點的控制關(guān)系可以概括為兩大類：緊耦合模式與松耦合模式。緊耦合是指由一個中心節(jié)點實現(xiàn)信令集中控制的會議：松耦合是指無需中央SIP信令的控制，終端直接進行交互的會議。其中緊耦合會議又可分為端系統(tǒng)混合模式、集中混合模式和信令集中、媒體流分布模式。

本文中視頻會議模型選擇使用緊耦合會議模式下的集中混合型視頻會議模型。此模型中終端各成員間的通信通過一個核心的混合器來實現(xiàn)，每個終端成員均需與混合器建立媒體和信令的連接，每個終端只收到一個混合流，對終端用戶減少了帶寬要求，用戶可以自由選擇編碼格式：音視頻在混流前可以進行靜音壓縮，增強系統(tǒng)靈活性。與本文提出的服務(wù)器模式相一致，本系統(tǒng)中的核心混合器使用信令服務(wù)器與kurento服務(wù)器：信令服務(wù)器建立與各終端聯(lián)系并負責(zé)對所有成員進行呼叫控制。kurento服務(wù)器進行媒體流的混合分發(fā)。系統(tǒng)模型如圖2所示。

模型中雙向虛線代表各節(jié)點與混合器中信令服務(wù)器交互產(chǎn)生的信令流，雙向?qū)嵕€代表各節(jié)點與混合器中kurento媒體服務(wù)器交互產(chǎn)生的媒體流。

3.2 模型流量控制算法設(shè)計

3.2.1 系統(tǒng)模型角色定義

一場會議當(dāng)中的角色分為主持者（Initiator）和與會者（Participant）。每個角色在模型中都被定義為一個節(jié)點，視作模型中一個視頻會議對等體。每個會議節(jié)點都能進行節(jié)點初始化、媒體流發(fā)送與媒體流接收。除此之外，主持者節(jié)點還需要發(fā)起整場會議（包括設(shè)置發(fā)起會議的名稱與選擇與會人員等）和負責(zé)選擇切換當(dāng)前窗口。

3.2.2 算法流程

會議系統(tǒng)整體流程可以抽象為以下兩種算法表示：使用算法1初始化會議中所有節(jié)點，執(zhí)行會議選擇算法從初始化后的節(jié)點中選擇主窗口節(jié)點。

算法1初始化算法

Procedure：lnit

Input：t為會議主持者節(jié)點，R_k為與會者節(jié)點集合，本次會議集合為C

Output：

（1）BEGIN

（2）令與會者節(jié)點集合R_k為空

（3）Start_listen（t）//初始化

（4）R_n=req_sel_par（t，R_k）//主持者選擇與會人員

（5）END

其中。Start_listen是主持者節(jié)點初始化整場會議，包括設(shè)置會議名稱、發(fā)起會議規(guī)模等;req_sel_par表示與會人員通過‘接受來自視頻會議呼叫信息，t選擇與會人員集合。

算法2會議系統(tǒng)選擇算法

Algorithm：select

Input：E_k（k=1，2，…，n）請求與會人員列表，T主持者節(jié)點，N_j當(dāng)前窗口狀態(tài)，S會議狀態(tài)

Output：當(dāng)前輸出音頻節(jié)點

（1）if（s==1）{//當(dāng)會議正在進行時

算法中req_tran_media表示當(dāng)選中當(dāng)前窗口時，當(dāng)前窗口作為主窗口媒體流的傳輸，將媒體流信息分別發(fā)送到各個節(jié)點：沒被選中的窗口處于靜音狀態(tài)，只能接受主窗口命令。

3.3 系統(tǒng)架構(gòu)設(shè)計

根據(jù)上述關(guān)鍵功能的需求分析，圍繞核心業(yè)務(wù)設(shè)計系統(tǒng)架構(gòu)，如圖3所示。整個系統(tǒng)架構(gòu)以視頻會議為驅(qū)動，采用軟件架構(gòu)中MVC多層架構(gòu)設(shè)計思想搭建而成。

圖3中信息訪問層即表現(xiàn)層，為用戶提供多種接人渠道訪問本系統(tǒng)，保持與控制層對應(yīng)關(guān)系;服務(wù)應(yīng)用層實現(xiàn)控制層與業(yè)務(wù)層功能，使用WebRTC協(xié)議提供搜索引擎服務(wù)、工作流服務(wù)支持，解釋用戶的請求并將其映射成可執(zhí)行的操作，根據(jù)具體的需求來進行業(yè)務(wù)邏輯處理：應(yīng)用支持平臺實現(xiàn)對數(shù)據(jù)訪問層與數(shù)據(jù)儲存層支持。kurento服務(wù)器包含了系統(tǒng)中視頻有關(guān)流的所有核心數(shù)據(jù)，jeecg框架提供權(quán)限控制服務(wù)支持，用來對數(shù)據(jù)存儲層的數(shù)據(jù)進行直接增、刪、改、查等操作。在系統(tǒng)的數(shù)據(jù)傳輸層搭建信令服務(wù)器，使用UDP提供邏輯連接的建立、傳輸層尋址、數(shù)據(jù)傳輸、傳輸連接釋放等。將通信雙方需要交換的相關(guān)參數(shù)封裝在SDP中傳遞給通信雙方。

3.4 系統(tǒng)模型服務(wù)器端實現(xiàn)

模型中的核心混合器端由系統(tǒng)中信令服務(wù)器與kurento媒體服務(wù)器實現(xiàn)。每個終端均需與系統(tǒng)服務(wù)器端建立媒體和信令的連接。通過信令服務(wù)器與所有通信端點建立連接，負責(zé)獲取初始信息并建立媒體流傳輸通道：kurento媒體服務(wù)器對各個端點發(fā)送來的媒體流混合處理，將其發(fā)送到各個端點。每個終端僅會收到一個混合的流，減少了計算復(fù)雜性：通過使用kurento媒體服務(wù)器中的GStream多媒體庫，對來自各個終端的編碼需求處理，終端可以自由選擇編碼格式：并對除主持人外的與會者的音頻流使用端點靜音算法壓縮處理，減少了帶寬的使用率，系統(tǒng)靈活性增強，并使會議可以接受不同網(wǎng)絡(luò)帶寬性能的多樣終端端點參與。系統(tǒng)服務(wù)器端通信架構(gòu)如圖4所示。

3.4.1 信令服務(wù)器搭建

信令服務(wù)器主要用于會話控制與媒體協(xié)商，具體的信令實現(xiàn)過程是基于WebRTC提供的弱信令A(yù)PI-JSEP（JavaScript Session EstablishmentProtocol，JavaScript會話建立協(xié)議）來實現(xiàn)。媒體協(xié)商在接到目標(biāo)用戶所在瀏覽器或終端傳來的SDP協(xié)議格式消息以后開始，調(diào)用JSEP信令A(yù)PI的createOffer（）/createAnswer（）接口，生成SDP（Session Description Protocol），為通信雙方交換的會話描述內(nèi)容提供會話描述格式，保存通信雙方需要交換的相關(guān)參數(shù)，SDP消息中包含了媒體協(xié)商必需的相關(guān)參數(shù)：由瀏覽器調(diào)用WebRTC內(nèi)置API實例化RTCPeerConnection對象獲得自我會話描述并使用內(nèi)置函數(shù)localDescription將其保存，通過信令通道發(fā)送到另一客戶端，由此完成交換會話請求和應(yīng)答消息，從而完成通信雙方會話的創(chuàng)建。

媒體協(xié)商成功建立鏈接后進行媒體流傳輸，通過信令消息對音視頻通話開啟會話控制（會話開始、結(jié)束、信息修改等）。會話控制也調(diào)用JSEP（Java Session Establishment Protocol）協(xié)議，其沒有定義具體的實現(xiàn)協(xié)議，由開發(fā)者在開發(fā)時自行選擇即可。此系統(tǒng)中使用SIP協(xié)議實現(xiàn)。

3.4.2Kurento服務(wù)器搭建流程

視頻會議模型中核心服務(wù)器使用kurento媒體服務(wù)器進行處理媒體流。通過Websocket全雙工通信建立kurento客戶端與kuremo media serve公開的API之間的連接，使用kurento提供的kurento協(xié)議來對客戶端與kurento media serve之間的通信提供不同類型的請求/響應(yīng)消息，以完成kurento客戶端對kurento media serve執(zhí)行的操作。

（1）首先建立客戶端與kurento media serve之間的websocket鏈接。使用kurento協(xié)議中提供的ping方法，作為客戶端發(fā)送方發(fā)送的鏈接方法，發(fā)送給接收方。

（2）創(chuàng)建用于傳輸?shù)膋urento媒體對象。使用kurento協(xié)議中create消息創(chuàng)建。在create消息中的type參數(shù)中指定創(chuàng)建媒體對象類型。如媒體管道和媒體元素等：接收方接受到發(fā)送方的create消息后，返回sessionID參數(shù)，用于創(chuàng)建下一步的創(chuàng)建請求。

（3）創(chuàng)建對象完成，對創(chuàng)建完成的媒體對象執(zhí)行相應(yīng)的操作。kurento協(xié)議中invoke消息是用于定義要執(zhí)行的操作，參數(shù)operation用于定義將要執(zhí)行操作的名稱。例如connect進行連接操作等。

（4）與會者需要訂閱主持者發(fā)布的視頻流。執(zhí)行kurento協(xié)議中subscribe消息。參數(shù)id定義為主持者id，type參數(shù)定義訂閱視頻流類型，主持人端收到訂閱消息后，觸發(fā)onEvent事件，從服務(wù)器端請求視頻流數(shù)據(jù)。使用unsubscribe消息取消對主持者端的訂閱。

（5）會議結(jié)束后釋放不使用的對象。使用release消息用于釋放不需要的對象及其資源。

4 結(jié)果展示

4.1 系統(tǒng)開發(fā)環(huán)境搭建

PC端使用ieecg面向?qū)W習(xí)型的開源Java EE開發(fā)框架。在spring-boot核心框架基礎(chǔ)上搭建的一個Java基礎(chǔ)開發(fā)平臺，使用Vue作為編寫展示層框架實現(xiàn)瀏覽器端HTML/is頁面，使用MyBatis技術(shù)實現(xiàn)數(shù)據(jù)訪問層、控制層及業(yè)務(wù)邏輯層使用spring-boot框架操作，ApacheShiro為權(quán)限授權(quán)層。Ehcahe對常用數(shù)據(jù)進行緩存，thymeleaf做為模板引擎，數(shù)據(jù)存儲層使用Oracle大型數(shù)據(jù)庫等MVC多層架構(gòu)的設(shè)計模式。

4.2 視頻會議系統(tǒng)應(yīng)用場景

本模型的應(yīng)用實例是稅務(wù)總局對下屬十六個縣市區(qū)稅務(wù)局召開視頻直播會議，要求各下屬稅務(wù)局逐個進行工作情況匯報。

在如圖5所示的界面中，由稅務(wù)總局主持人（會議發(fā)起者）選擇需要邀請的用戶列表權(quán)限，后臺對數(shù)據(jù)庫中所選中的邀請用戶進行角色權(quán)限搜索遍歷，用戶角色權(quán)限符合，對其發(fā)起視頻會議呼叫。

用戶接受呼叫邀請進入視頻會議界面，待所有用戶都加入到會議中后，主會議頁面使用響應(yīng)式柵格化方式，自動分配每個用戶窗口和屏幕大小，（各分局頁面為主持人端與本客戶端）如圖6所示。

窗口則需要執(zhí)行靜音算法，即不對當(dāng)前進行的匯報產(chǎn)生干擾，也減少對網(wǎng)絡(luò)帶寬的使用。經(jīng)過實際測試表明。本會議模型可建立基于P2P的16路對等視頻會議。在會議時長持續(xù)24小時中，會議過程視頻流暢，無卡頓現(xiàn)象。

5 結(jié)束語

WebRTC是基于瀏覽器的實時通信，是指運行在瀏覽器上的Web應(yīng)用通過調(diào)用瀏覽器提供的API，實現(xiàn)瀏覽器之間實時通信連接的建立和音視頻等數(shù)據(jù)的傳輸。本文基于這種新型的直播技術(shù)提出一種視頻會議系統(tǒng)模型，改變傳統(tǒng)的視頻會議全連接模式，由主持人端發(fā)起會議，接受其余全部與會人員視頻流信息：與會人員只需接受主持人端視頻，減少服務(wù)器端負荷：對除發(fā)言窗口外其余窗口使用靜音算法來減少帶寬使用。根據(jù)視頻會議模型設(shè)計的視頻會議系統(tǒng)。并應(yīng)用到稅務(wù)部門實際工作中，進行反復(fù)檢測用戶加入數(shù)量對視頻會議帶寬影響。下一步工作中，對現(xiàn)有的靜音算法優(yōu)化，降低多用戶狀態(tài)下切換目標(biāo)時產(chǎn)生的延遲。