公路突發事件處理中WebRTC視頻通信系統的設計與應用

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

關鍵詞 公路運行；突發事件；處理；WebRTC；視頻通信

中圖分類號 U495 文獻標識碼 B 文章編號 2096-8949（2024）20-0007-03

0 引言

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

1 WebRTC視頻通信系統設計思路

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

按照以上概述及視頻需求設計，依托WebRTC技術構建的緊急處理交流視頻通信系統應用模型[2]見圖1所示：

2 WebRTC視頻通信系統設計要點

2.1 數據庫設計

提供設備運行數據存儲、用戶信息存儲、權限策略優化等服務是數據庫的主要功能。Web服務器所采用的是Microsoft SQL Server 2008 R2數據庫操作系統，該數據庫基本無外鍵設置，其表關聯過程的控制主要ZAv017INQlM3Kevl+cnB0aKohZu8G93Jo+OvA8/pc2Q=通過通知程序實現。通過查取表間關聯字段關系即可得到對應的設計規則。

該公路緊急處理交流中的Web服務器核心數據庫表，應包括用戶信息表、組織機構表、設備表、信令服務器信息表、位置信息表等類型。其中，用戶信息表主要統計和體現公路運行應急事件、道路巡查專員等情況；組織機構表則統計和羅列公路工程所在省份的應急平臺部署、視頻會議參與的機構信息等；設備表則記錄和展示應急平臺所涵蓋的移動端設備、應急情報板、監控攝像頭等各類設備的管理情況。

2.2 信令協議

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

嚴格來講，信令服務器本質上具有中介屬性，所起到的功能和作用與代理服務器、轉發服務器類似。具體請求由客戶端提出，此后得到相應應答后便重新返回，這一過程中要求必須保持會話連接狀態，同時也對信令服務器所具備的相關管理功能提出更高要求。WebRTC視頻通信功能實現前，必須構建相應的主體端會話，每一輪次的會話均通過唯一性的標識符進行標識與確定。

在開展以上過程及信令服務器初始化處理時，必須綁定相關服務器，同時實施相關認證事件的監管和連接。這一過程中要求對相關自定義事件和視頻通信的連接—斷開事件進行注冊認證；各種形式的信息處置事件轉發處理，主要通過emitChatEvent調用技術實現，所涉及的用戶和服務器之間的各種形式的會話信息，主要通過連接斷開事件予以清除。

按照以上設計思路，用戶和服務器之間切實可行的會話交互[4]應當按照圖2所示的流程展開。根據這一程序，用戶和服務器之間的連接必須經過認證才能實現，此后便能與服務器始終保持會話狀態，所形成的會話信息會自動進行打包存儲。

2.3 視頻通信

為方便開展信令服務器地址類信息及客戶端設備信息接入管理，應在該視頻通信系統內的設備管理模塊設置單兵設備管理模塊。此系統在運行期間，在左方功能菜單處顯示相應的監測模塊，主要存儲模塊和平臺所收集的移動端設備位置等信息，通過點擊圖標便可開啟瀏覽。

相關操作人員按照設計流程登錄后，可借助P2P.connect方法實現與相應信令服務器硬件的直接連接；此后按照事先設置好的主動/被動呼叫方式，進行視頻通信過程的點對點觸發。在主動呼叫的模式下，移動客戶端將接收自動邀請信息；chat-invitation信息則完全借助WebSocket平臺直接發送至相應的服務器硬件端，并進一步轉發至移動客戶端。在被動呼叫模式下，chat-invitation信息主要由呼叫方發送，待被呼叫方選擇接收后系統便會自動構建Peerconnection連接，進而自動生成本地SDP與遠程SDP，取得相應答復后仍由WebSocket平臺向服務器硬件端發送。

2.4 視頻會議系統

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

3 WebRTC視頻通信系統測試

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

3.1 系統功能測試

在開展視頻通信功能檢測時，結合該研究中WebRTC通信系統信令服務器的運行條件，此處以Windows為主要的功能測試環境，將相關控制臺開啟并相應切換至服務器所在的根目錄，隨后在根目錄下進行nodesignalserver.js命令及服務器的同時運行，還應設置與這一過程相匹配的監聽端口。待以上處理全部完成后，系統也相應實現與服務器的自動連接。在選擇單兵視頻通信功能后，頁面將自動向監測主頁跳轉，此時操作人員可在客戶端自主選取相應圖標開啟視頻通信。

在進行視頻會議功能檢測時，必須借助控制平臺并轉換至MCU根目錄，在此基礎上展開./bin/start-all.sh命令及相應服務器硬件設施的啟動和執行，進而選取視頻會議相關界面，便可十分便捷地開啟視頻會議的功能檢測。

3.2 系統性能測_{74ab865402ae65532baa454572a35e54f32beeb30ee24c57aa6e23c5efa4150f}試

考慮P2P視頻通信對WebRTC視頻通信系統性能的要求較低，故此處只分析存在一定應用難度的視頻會議性能測試問題。

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

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

通過對WebRTC視頻通信系統視頻數據和音頻數據發送和接收速率的監測可以看出，兩種類型的數據發送量分別為290 K位和39 K位，所對應的發送速率為41.0 kB/s。與此同時，兩種類型的數據接收量分別為700 K位和68 K位，所對應的接收速率為96.0 kB/s。通過對以上兩個過程和相應數據的比較可以看出，WebRTC視頻通信系統網頁端視頻和音頻數據的接收速率較小，且基本不受與會人數和規模的影響，相應地對網絡帶寬也無較高要求。

綜上，網絡流量數據可以通過監控頁面信息圖直觀體現，所發送的音頻涉及的用戶較少；網頁端視頻通信數據收發速率基本不受視頻會議參與人數影響，因接收速率下降，對網絡帶寬的要求也相應降低，較好地保證了WebRTC視頻通信系統性能。

4 結論

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

參考文獻

[1]高朝龍，張景波，蔡星娟.WebRTC視頻會議的高維多目標多碼率優化研究[J].小型微型計算機系統，2023（8）：1735-1742.

[2]張遠，劉偉，董顯平，等.基于Janus網關的WebRTC音視頻客戶端設計與實現[J].中國新通信，2021（10）：45-47.

[3]周勇，楊洋，李偉，等.基于網頁實時通信的跨平臺高速公路應急視頻應用研究[J].現代信息科技，2023（9）：82-85+89.

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

[5]朱彥姣.高速公路特長隧道中高清視頻監控系統的設計[J].機電信息，2021（8）：39-40.

收稿日期：2024-05-13

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