摘要 為探究WebRTC視頻通信系統(tǒng)在公路日常運(yùn)行期間突發(fā)事件處理過程中應(yīng)用的主要思路，文章以某省山林地區(qū)公路運(yùn)行段為例，對(duì)依托WebRTC技術(shù)的緊急事務(wù)處理交流視頻通信系統(tǒng)應(yīng)用模型展開設(shè)想，進(jìn)而對(duì)包括數(shù)據(jù)庫設(shè)計(jì)、信令協(xié)議、視頻會(huì)議系統(tǒng)等在內(nèi)的視頻通信系統(tǒng)設(shè)計(jì)思路進(jìn)行了研究，并從系統(tǒng)功能和系統(tǒng)性能兩個(gè)視角展開WebRTC視頻通信系統(tǒng)測(cè)試。結(jié)果表明，依托WebRTC技術(shù)所構(gòu)建的省級(jí)公路日常運(yùn)行突發(fā)事件緊急處理交流視頻通信系統(tǒng)，其視頻音頻通信功能在移動(dòng)終端得到較好實(shí)現(xiàn)，能為公路交通安全運(yùn)行提供實(shí)時(shí)監(jiān)測(cè)及流暢的視頻通信服務(wù)，提升公路應(yīng)急事件處理的時(shí)效性及公路服役能力水平。

關(guān)鍵詞 公路運(yùn)行；突發(fā)事件；處理；WebRTC；視頻通信

中圖分類號(hào) U495 文獻(xiàn)標(biāo)識(shí)碼 B 文章編號(hào) 2096-8949（2024）20-0007-03

0 引言

公路車輛運(yùn)行始終處于動(dòng)態(tài)過程，影響因素眾多，所以在公路日常運(yùn)行中發(fā)生各類突發(fā)事件的可能性非常大。對(duì)于固定監(jiān)控探頭安裝不到位、接入移動(dòng)運(yùn)營(yíng)網(wǎng)絡(luò)明顯滯后的路段而言，公路管理部門在發(fā)生突發(fā)事件后很難第一時(shí)間獲取相關(guān)信息，更談不上及時(shí)采取處置措施，因此常常處于明顯的信息劣勢(shì)和被動(dòng)局面。WebRTC技術(shù)融音頻、視頻處理及信號(hào)處理，流媒體數(shù)據(jù)傳輸?shù)裙δ苡谝惑w，借助瀏覽器實(shí)現(xiàn)實(shí)時(shí)的視頻通信和交互。該技術(shù)隨著移動(dòng)互聯(lián)網(wǎng)的不斷縱深發(fā)展，在政企辦公領(lǐng)域得到一定程度的應(yīng)用，取得了較為理想的信息交互效果。為此，該文創(chuàng)新性地將WebRTC技術(shù)引入公路交通突發(fā)事件處理領(lǐng)域，以期為公路管理部門能在各種形式的突發(fā)事件發(fā)生后，實(shí)時(shí)掌握現(xiàn)場(chǎng)情況、指揮處理、高效解決提供可能。

1 WebRTC視頻通信系統(tǒng)設(shè)計(jì)思路

某省部分地區(qū)山林較多，建設(shè)在此類區(qū)域的公路網(wǎng)在運(yùn)行過程中主要面臨固定攝像頭安裝難度大、與移動(dòng)運(yùn)營(yíng)網(wǎng)絡(luò)連接成本高等問題，無法在公路運(yùn)行日常及突發(fā)事件處理時(shí)開展有效的視頻監(jiān)控與管理。為此，決定構(gòu)建涵蓋各地市級(jí)公路管理部門，并具備路網(wǎng)監(jiān)控、實(shí)時(shí)視頻通信功能的通信系統(tǒng)。該系統(tǒng)主要依托WebRTC技術(shù)而建立并展開信令處理，其所使用的處理協(xié)議可以是較為常規(guī)的Jingle和SIP協(xié)議，也可以是結(jié)合程序運(yùn)行機(jī)制而專門開發(fā)的信令協(xié)議[1]。為保證所構(gòu)建的公路緊急處理視頻通信系統(tǒng)具備較好的接入接出功能和人機(jī)交互功能，還應(yīng)充分借助WebSocket信令服務(wù)器的硬件設(shè)施，為應(yīng)用程序提供較好的信令控制，使之能較好地完成文字及語音交流、用戶呼叫等操作。

按照以上概述及視頻需求設(shè)計(jì)，依托WebRTC技術(shù)構(gòu)建的緊急處理交流視頻通信系統(tǒng)應(yīng)用模型[2]見圖1所示：

2 WebRTC視頻通信系統(tǒng)設(shè)計(jì)要點(diǎn)

2.1 數(shù)據(jù)庫設(shè)計(jì)

提供設(shè)備運(yùn)行數(shù)據(jù)存儲(chǔ)、用戶信息存儲(chǔ)、權(quán)限策略優(yōu)化等服務(wù)是數(shù)據(jù)庫的主要功能。Web服務(wù)器所采用的是Microsoft SQL Server 2008 R2數(shù)據(jù)庫操作系統(tǒng)，該數(shù)據(jù)庫基本無外鍵設(shè)置，其表關(guān)聯(lián)過程的控制主要ZAv017INQlM3Kevl+cnB0aKohZu8G93Jo+OvA8/pc2Q=通過通知程序?qū)崿F(xiàn)。通過查取表間關(guān)聯(lián)字段關(guān)系即可得到對(duì)應(yīng)的設(shè)計(jì)規(guī)則。

該公路緊急處理交流中的Web服務(wù)器核心數(shù)據(jù)庫表，應(yīng)包括用戶信息表、組織機(jī)構(gòu)表、設(shè)備表、信令服務(wù)器信息表、位置信息表等類型。其中，用戶信息表主要統(tǒng)計(jì)和體現(xiàn)公路運(yùn)行應(yīng)急事件、道路巡查專員等情況；組織機(jī)構(gòu)表則統(tǒng)計(jì)和羅列公路工程所在省份的應(yīng)急平臺(tái)部署、視頻會(huì)議參與的機(jī)構(gòu)信息等；設(shè)備表則記錄和展示應(yīng)急平臺(tái)所涵蓋的移動(dòng)端設(shè)備、應(yīng)急情報(bào)板、監(jiān)控?cái)z像頭等各類設(shè)備的管理情況。

2.2 信令協(xié)議

WebRTC規(guī)則中的信令協(xié)議不具備指定性和具體性，所需要的信令協(xié)議完全由開發(fā)人員選擇或指定。出于相關(guān)方面考慮，該研究主要選定的是WebRTC自定義信令協(xié)議。具體而言，根據(jù)其中的Node.js功能鎖定硬件方面的信令服務(wù)器類型，同時(shí)借助Socket.IO技術(shù)為信令協(xié)議的良好實(shí)施提供保證。作為WebSocket庫的Socket.IO技術(shù)，可以結(jié)合移動(dòng)設(shè)備或?yàn)g覽器的實(shí)際情況在AJAX、Forever Iframe等方式中選取最佳的應(yīng)用方式[3]。

嚴(yán)格來講，信令服務(wù)器本質(zhì)上具有中介屬性，所起到的功能和作用與代理服務(wù)器、轉(zhuǎn)發(fā)服務(wù)器類似。具體請(qǐng)求由客戶端提出，此后得到相應(yīng)應(yīng)答后便重新返回，這一過程中要求必須保持會(huì)話連接狀態(tài)，同時(shí)也對(duì)信令服務(wù)器所具備的相關(guān)管理功能提出更高要求。WebRTC視頻通信功能實(shí)現(xiàn)前，必須構(gòu)建相應(yīng)的主體端會(huì)話，每一輪次的會(huì)話均通過唯一性的標(biāo)識(shí)符進(jìn)行標(biāo)識(shí)與確定。

在開展以上過程及信令服務(wù)器初始化處理時(shí)，必須綁定相關(guān)服務(wù)器，同時(shí)實(shí)施相關(guān)認(rèn)證事件的監(jiān)管和連接。這一過程中要求對(duì)相關(guān)自定義事件和視頻通信的連接—斷開事件進(jìn)行注冊(cè)認(rèn)證；各種形式的信息處置事件轉(zhuǎn)發(fā)處理，主要通過emitChatEvent調(diào)用技術(shù)實(shí)現(xiàn)，所涉及的用戶和服務(wù)器之間的各種形式的會(huì)話信息，主要通過連接斷開事件予以清除。

按照以上設(shè)計(jì)思路，用戶和服務(wù)器之間切實(shí)可行的會(huì)話交互[4]應(yīng)當(dāng)按照?qǐng)D2所示的流程展開。根據(jù)這一程序，用戶和服務(wù)器之間的連接必須經(jīng)過認(rèn)證才能實(shí)現(xiàn)，此后便能與服務(wù)器始終保持會(huì)話狀態(tài)，所形成的會(huì)話信息會(huì)自動(dòng)進(jìn)行打包存儲(chǔ)。

2.3 視頻通信

為方便開展信令服務(wù)器地址類信息及客戶端設(shè)備信息接入管理，應(yīng)在該視頻通信系統(tǒng)內(nèi)的設(shè)備管理模塊設(shè)置單兵設(shè)備管理模塊。此系統(tǒng)在運(yùn)行期間，在左方功能菜單處顯示相應(yīng)的監(jiān)測(cè)模塊，主要存儲(chǔ)模塊和平臺(tái)所收集的移動(dòng)端設(shè)備位置等信息，通過點(diǎn)擊圖標(biāo)便可開啟瀏覽。

相關(guān)操作人員按照設(shè)計(jì)流程登錄后，可借助P2P.connect方法實(shí)現(xiàn)與相應(yīng)信令服務(wù)器硬件的直接連接；此后按照事先設(shè)置好的主動(dòng)/被動(dòng)呼叫方式，進(jìn)行視頻通信過程的點(diǎn)對(duì)點(diǎn)觸發(fā)。在主動(dòng)呼叫的模式下，移動(dòng)客戶端將接收自動(dòng)邀請(qǐng)信息；chat-invitation信息則完全借助WebSocket平臺(tái)直接發(fā)送至相應(yīng)的服務(wù)器硬件端，并進(jìn)一步轉(zhuǎn)發(fā)至移動(dòng)客戶端。在被動(dòng)呼叫模式下，chat-invitation信息主要由呼叫方發(fā)送，待被呼叫方選擇接收后系統(tǒng)便會(huì)自動(dòng)構(gòu)建Peerconnection連接，進(jìn)而自動(dòng)生成本地SDP與遠(yuǎn)程SDP，取得相應(yīng)答復(fù)后仍由WebSocket平臺(tái)向服務(wù)器硬件端發(fā)送。

2.4 視頻會(huì)議系統(tǒng)

該研究所創(chuàng)建的WebRTC視頻通信系統(tǒng)主要依托MCU服務(wù)器，以保證系統(tǒng)具備的流媒體協(xié)議、視頻和音頻混合編碼和解碼、會(huì)務(wù)管理等全部功能得以順利實(shí)現(xiàn)。具體而言，該系統(tǒng)選用的是技術(shù)架構(gòu)完全等同于Licode開源技術(shù)的WebRTC會(huì)務(wù)服務(wù)器。系統(tǒng)中Erizo模塊主要依托C++語言，進(jìn)而達(dá)到與WebRTC協(xié)議完全兼容的狀態(tài)；Erizo API則主要借助Node.js插件的具體應(yīng)用達(dá)到對(duì)Erizo模塊的全面管理。最后，建立在Erizo API模塊基礎(chǔ)上的Erizo Controller，則主要憑借所具備的安全機(jī)制及事件處理、數(shù)據(jù)管理等多種功能，為用戶提供高質(zhì)量的實(shí)時(shí)視頻會(huì)議交互式管理服務(wù)。

3 WebRTC視頻通信系統(tǒng)測(cè)試

對(duì)于應(yīng)用軟件而言，測(cè)試內(nèi)容主要涉及集成測(cè)試、單元測(cè)試、驗(yàn)收測(cè)試等。各測(cè)試內(nèi)容所對(duì)應(yīng)的測(cè)試級(jí)別不盡一致，但均應(yīng)保證測(cè)試層面的充分性和全面性。測(cè)試期間除應(yīng)展開逐項(xiàng)功能需求檢測(cè)外，還應(yīng)注重接口要求和內(nèi)部的處理邏輯。該文所設(shè)計(jì)的公路突發(fā)事件處理中WebRTC視頻通信系統(tǒng)測(cè)試環(huán)境，應(yīng)至少包括MCU視頻會(huì)議服務(wù)器1臺(tái)、應(yīng)急處置PC平臺(tái)2臺(tái)，前者內(nèi)存5.7 GB，配置Intel（R）Core（TM）i5-2430M 2.40 GHz處理器，同時(shí)按照Ubuntu 14.04 LTS×64-bit操作系統(tǒng)運(yùn)行；后者則以Windows 7（64 bit）為主操作系統(tǒng)，并配備Google Chrome 44.0.2403.157版本瀏覽器。在此基礎(chǔ)上，還應(yīng)配置1部?jī)?nèi)存不小于3.0 GB的安卓系統(tǒng)智能手機(jī)，且前后置攝像頭均為800萬超高清像素。

3.1 系統(tǒng)功能測(cè)試

在開展視頻通信功能檢測(cè)時(shí)，結(jié)合該研究中WebRTC通信系統(tǒng)信令服務(wù)器的運(yùn)行條件，此處以Windows為主要的功能測(cè)試環(huán)境，將相關(guān)控制臺(tái)開啟并相應(yīng)切換至服務(wù)器所在的根目錄，隨后在根目錄下進(jìn)行nodesignalserver.js命令及服務(wù)器的同時(shí)運(yùn)行，還應(yīng)設(shè)置與這一過程相匹配的監(jiān)聽端口。待以上處理全部完成后，系統(tǒng)也相應(yīng)實(shí)現(xiàn)與服務(wù)器的自動(dòng)連接。在選擇單兵視頻通信功能后，頁面將自動(dòng)向監(jiān)測(cè)主頁跳轉(zhuǎn)，此時(shí)操作人員可在客戶端自主選取相應(yīng)圖標(biāo)開啟視頻通信。

在進(jìn)行視頻會(huì)議功能檢測(cè)時(shí)，必須借助控制平臺(tái)并轉(zhuǎn)換至MCU根目錄，在此基礎(chǔ)上展開./bin/start-all.sh命令及相應(yīng)服務(wù)器硬件設(shè)施的啟動(dòng)和執(zhí)行，進(jìn)而選取視頻會(huì)議相關(guān)界面，便可十分便捷地開啟視頻會(huì)議的功能檢測(cè)。

3.2 系統(tǒng)性能測(cè)_{74ab865402ae65532baa454572a35e54f32beeb30ee24c57aa6e23c5efa4150f}試

考慮P2P視頻通信對(duì)WebRTC視頻通信系統(tǒng)性能的要求較低，故此處只分析存在一定應(yīng)用難度的視頻會(huì)議性能測(cè)試問題。

首先是CPU占用情況測(cè)試。該研究主要借助Dalvik Debug Monitor Service技術(shù)對(duì)WebRTC視頻通信系統(tǒng)客戶端占用程度展開測(cè)試[5]。該技術(shù)屬于虛擬屬性的調(diào)試型監(jiān)控服務(wù)手段，通過該技術(shù)可以向監(jiān)控人員實(shí)時(shí)展示系統(tǒng)的運(yùn)行進(jìn)程和狀態(tài)，也能提供內(nèi)存信息運(yùn)行進(jìn)程的查看服務(wù)。這里的內(nèi)存信息主要包括CPU分配、logcat、網(wǎng)絡(luò)流量、地理位置信息等。根據(jù)對(duì)該省公路運(yùn)行中WebRTC視頻通信系統(tǒng)CPU占用進(jìn)程的監(jiān)測(cè)分析看出，三人及以上的視頻會(huì)議基本不會(huì)增大移動(dòng)端設(shè)備的運(yùn)行負(fù)荷，能夠?yàn)橐曨l會(huì)議系統(tǒng)的順暢運(yùn)行提供可靠保證，也就是說隨著使用人數(shù)的增多，因MCU服務(wù)器功能的順利發(fā)揮，CPU占用率基本保持在穩(wěn)定狀態(tài)，即使召開多人視頻會(huì)議，也不會(huì)增大移動(dòng)端設(shè)備負(fù)擔(dān)，仍能確保系統(tǒng)的順暢運(yùn)行。

其次是系統(tǒng)網(wǎng)絡(luò)數(shù)據(jù)監(jiān)控。在測(cè)試客戶端占用程度所使用的監(jiān)測(cè)技術(shù)下，客戶端視頻分辨率主要按照640×480的初始值確定。通過比較2人及3人視頻會(huì)議過程中網(wǎng)監(jiān)數(shù)據(jù)流量的變動(dòng)趨勢(shì)可以看出，視頻發(fā)布階段的上行流量始終位于48 kB/s左右，而經(jīng)由MCU服務(wù)器處理后的下行流量基本位于98～100 kB/s；此外，即使視頻會(huì)議參加人數(shù)暴增，上下行流量也基本處于穩(wěn)定狀態(tài)，網(wǎng)絡(luò)運(yùn)行較為穩(wěn)定。

通過對(duì)WebRTC視頻通信系統(tǒng)視頻數(shù)據(jù)和音頻數(shù)據(jù)發(fā)送和接收速率的監(jiān)測(cè)可以看出，兩種類型的數(shù)據(jù)發(fā)送量分別為290 K位和39 K位，所對(duì)應(yīng)的發(fā)送速率為41.0 kB/s。與此同時(shí)，兩種類型的數(shù)據(jù)接收量分別為700 K位和68 K位，所對(duì)應(yīng)的接收速率為96.0 kB/s。通過對(duì)以上兩個(gè)過程和相應(yīng)數(shù)據(jù)的比較可以看出，WebRTC視頻通信系統(tǒng)網(wǎng)頁端視頻和音頻數(shù)據(jù)的接收速率較小，且基本不受與會(huì)人數(shù)和規(guī)模的影響，相應(yīng)地對(duì)網(wǎng)絡(luò)帶寬也無較高要求。

綜上，網(wǎng)絡(luò)流量數(shù)據(jù)可以通過監(jiān)控頁面信息圖直觀體現(xiàn)，所發(fā)送的音頻涉及的用戶較少；網(wǎng)頁端視頻通信數(shù)據(jù)收發(fā)速率基本不受視頻會(huì)議參與人數(shù)影響，因接收速率下降，對(duì)網(wǎng)絡(luò)帶寬的要求也相應(yīng)降低，較好地保證了WebRTC視頻通信系統(tǒng)性能。

4 結(jié)論

該研究對(duì)某省公路網(wǎng)緊急事件處理中的視頻通信系統(tǒng)展開設(shè)計(jì)，并對(duì)WebRTC技術(shù)優(yōu)勢(shì)及系統(tǒng)架構(gòu)展開探討，主要得出以下結(jié)論：依托WebRTC技術(shù)所設(shè)計(jì)的省級(jí)公路網(wǎng)緊急事件處理系統(tǒng)主要包含單兵設(shè)備模塊及視頻會(huì)議模塊，信令服務(wù)器具備可自我界定功能，并兼具視頻通信功能和視頻會(huì)議功能。該文所開發(fā)的視頻通信系統(tǒng)可較好地應(yīng)用于省級(jí)公路網(wǎng)運(yùn)行期間的緊急事件處理，系統(tǒng)所具備的功能可全部通過人機(jī)交互在移動(dòng)終端進(jìn)行實(shí)現(xiàn)，能較好地為固定監(jiān)控設(shè)備欠缺的地區(qū)提供移動(dòng)型視頻監(jiān)控和實(shí)時(shí)通信服務(wù)，整個(gè)路網(wǎng)和相應(yīng)路段在緊急事件發(fā)生后第一時(shí)間便可得到妥善處理，公路服役效率和水平得到顯著提高。

參考文獻(xiàn)

[1]高朝龍，張景波，蔡星娟.WebRTC視頻會(huì)議的高維多目標(biāo)多碼率優(yōu)化研究[J].小型微型計(jì)算機(jī)系統(tǒng)，2023（8）：1735-1742.

[2]張遠(yuǎn)，劉偉，董顯平，等.基于Janus網(wǎng)關(guān)的WebRTC音視頻客戶端設(shè)計(jì)與實(shí)現(xiàn)[J].中國(guó)新通信，2021（10）：45-47.

[3]周勇，楊洋，李偉，等.基于網(wǎng)頁實(shí)時(shí)通信的跨平臺(tái)高速公路應(yīng)急視頻應(yīng)用研究[J].現(xiàn)代信息科技，2023（9）：82-85+89.

[4]成韻姿.隧道高清視頻監(jiān)控系統(tǒng)升級(jí)改造方案研究[J].山西交通科技，2022（6）：108-111+118.

[5]朱彥姣.高速公路特長(zhǎng)隧道中高清視頻監(jiān)控系統(tǒng)的設(shè)計(jì)[J].機(jī)電信息，2021（8）：39-40.

收稿日期：2024-05-13

作者簡(jiǎn)介：劉瑞旸（1992—），男，本科，工程師，從事交通通信工程工作。