石芮 成洪豪 孫立民

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

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

0引言

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

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

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

1.1 WebRTC

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

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

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

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

1.2 kurento

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2.2 算法流程

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

算法1初始化算法

Procedure：lnit

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

Output：

（1）BEGIN

（2）令與會(huì)者節(jié)點(diǎn)集合R_k為空

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

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

（5）END

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

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

Algorithm：select

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

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

（1）if（s==1）{//當(dāng)會(huì)議正在進(jìn)行時(shí)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 結(jié)果展示

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

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

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

本模型的應(yīng)用實(shí)例是稅務(wù)總局對(duì)下屬十六個(gè)縣市區(qū)稅務(wù)局召開(kāi)視頻直播會(huì)議，要求各下屬稅務(wù)局逐個(gè)進(jìn)行工作情況匯報(bào)。

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

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

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

5 結(jié)束語(yǔ)

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