李鵬樹,范 輝

(北京交通大學 計算機與信息技術(shù)學院,北京 100044)

WebRTC (Web Real-Time Communication)是一項網(wǎng)頁實時通信技術(shù)并將逐漸成為下一代音視頻通信的標準,它提供了實時音視頻處理的解決方案,并在當前Android系統(tǒng)內(nèi)置瀏覽器和PC端主流瀏覽器對該項技術(shù)提供支持[1].現(xiàn)如今我國的移動醫(yī)療領(lǐng)域發(fā)展迅速,移動問診的興起和發(fā)展拓寬了患者的就醫(yī)渠道,但現(xiàn)階段的移動問診在實時通信方面的用戶體驗度不好.本文對WebRTC技術(shù)進行分析后,研究診后醫(yī)療系統(tǒng)中實時問診業(yè)務下的實時通信模塊,主要對實時通信中所涉及信令協(xié)商、網(wǎng)絡穿越和音視頻處理等處理流程進行研究實現(xiàn),將WebRTC的音視頻處理技術(shù)應用于移動醫(yī)療領(lǐng)域中,結(jié)合出院患者住院信息提出診后醫(yī)療系統(tǒng)以應對慢性病患者出院后期再次就醫(yī)問題,建立患者與其主治醫(yī)師間的在線綁定,開發(fā)出具有高質(zhì)量實時音視頻通信的在線問診醫(yī)療服務系統(tǒng).

實時通信平臺的設(shè)計包括信令控制、網(wǎng)絡穿越、音視頻媒體數(shù)據(jù)處理與傳輸控制,考慮到跨平臺的應用本系統(tǒng)應用會話初始化協(xié)議 (Session Initiation Protocol,SIP)[2]和會話描述協(xié)議(Session Description Protocol,SDP)[3]實現(xiàn)會話協(xié)商,設(shè)計背靠背用戶代理服務器(Back-to-Back User Agent,B2BUA)和會話邊界服務器(Session Border Controller,SBC)[4]實現(xiàn)信令與媒體代理進而實現(xiàn)網(wǎng)絡穿越功能,依托WebRTC協(xié)議體系并應用WebRTC音視頻處理技術(shù)實現(xiàn)實時通信.

1 WebRTC技術(shù)的引入

1.1 WebRTC技術(shù)簡介

WebRTC是一項支持跨平臺的實時音視頻處理的解決方案,它提供了音視頻處理的核心技術(shù),功能結(jié)構(gòu)框架主要分為兩部分：Web API和核心庫[5],如圖1所示.Web API主要供Web開發(fā)者使用以方便進行瀏覽器端開發(fā),核心庫是內(nèi)嵌到瀏覽器中的,這是其核心內(nèi)容.WebRTC的核心類庫主要包括Native API、會話控制、音/視頻處理引擎和網(wǎng)絡傳輸控制等.

圖1 WebRTC框架圖

在WebRTC核心庫中音頻引擎、視頻引擎和傳輸控制是3個重要的模塊.音頻引擎是WebRTC最突出的技術(shù),主要是對語音數(shù)據(jù)進行處理,包括回聲消除、噪聲抑制、增益控制和靜音檢測等功能,用以提升語音質(zhì)量.實現(xiàn)了整個音頻媒體鏈的技術(shù)框架,包括對音頻的聲學處理和音頻編解碼的實現(xiàn).NetEQ模塊[6]功能的加入減小了由于網(wǎng)絡抖動和語音數(shù)據(jù)包分組丟失對語音質(zhì)量的影響,從而在盡可能低的時延下提供高品質(zhì)的語音通話.視頻引擎實現(xiàn)了從采集、傳輸?shù)秸故镜恼麄€視頻控制的框架,包括視頻圖像的增強處理和VP8[7]編解碼的實現(xiàn).在傳輸控制中,WebRTC應用STUN、TURN和ICE[8]機制相結(jié)合來解決不同類型的NAT穿越問題,以實現(xiàn)實時音視頻傳輸.

1.2 實時通信系統(tǒng)架構(gòu)模式比較

實時通信平臺的架構(gòu)模式主要分為：混合處理結(jié)構(gòu)(Mixer)、路由轉(zhuǎn)接結(jié)構(gòu)(Router)和網(wǎng)絡拓撲結(jié)構(gòu)(Mesh),前兩種架構(gòu)模式需要中間服務器轉(zhuǎn)接以實現(xiàn)流媒體信息實時交互,兩者的主要區(qū)別是服務端是否承接音視頻處理功能.Mesh結(jié)構(gòu)主要特點是實現(xiàn)實時通信系統(tǒng)的P2P (Peer-to-Peer)在線傳輸方案,去掉了中間轉(zhuǎn)接媒體信息的服務器,系統(tǒng)只需要部署信令協(xié)商[9]和NAT穿越服務器,以完成終端用戶的會話協(xié)商和獲取相應網(wǎng)絡地址,架構(gòu)方案的比較如下：

(1) 混合處理結(jié)構(gòu)(Mixer)：服務端負責音視頻處理,包括轉(zhuǎn)碼、混音、合屏等,當前多人視頻會議基本上是種結(jié)構(gòu).

方案特點：

① 終端負載最小,理論上支持多人同時音視頻互通.② 可與現(xiàn)有產(chǎn)品無縫對接,最大程度利用硬件能力.③ 服務端負載很大,系統(tǒng)部署成本很高.

④ 多延遲問題,服務端負責工作,如解碼、合屏、混音、編碼,因此會帶來延遲.

(2) 路由轉(zhuǎn)接結(jié)構(gòu)(Router)：服務端負責媒體包轉(zhuǎn)發(fā)但不負責轉(zhuǎn)碼處理.

方案特點：

① 系統(tǒng)容易擴展,相比Mixer結(jié)構(gòu)服務端壓力減小.

② 低延遲,與SVC結(jié)合提升用戶體驗度.

③ 服務端要處理不同終端的接收能力問題,整體部署難度并未大幅下降.

④ 在一定程度上限制了通信系統(tǒng)的規(guī)模.

(3) 網(wǎng)絡拓撲結(jié)構(gòu)(Mesh)：媒體數(shù)據(jù)包不需要經(jīng)過服務端,終端直接P2P交互傳輸[10],是最簡單的實時通信系統(tǒng)的架構(gòu)模式,WebRTC主要應用于此架構(gòu)模式.

方案特點：

① 服務端壓力小,理論上不需要媒體轉(zhuǎn)接服務器.

② 低延遲,終端直接P2P傳輸,減小數(shù)據(jù)轉(zhuǎn)接延遲.

③ 終端負載較大,音視頻的處理工作主要交于終端來處理,對終端要求相對較高.

2 WebRTC技術(shù)要點分析

2.1 音頻處理分析

WebRTC技術(shù)的音頻引擎提供了音頻控制的整套解決方案,它不僅包括音頻中非常重要的編解碼模塊(Audio coding)和音頻處理模塊(Audio processing),還包括混音模塊(Audio conference mixer)和采樣頻率控制模塊(Bitrate controller)等.音頻引擎的整體結(jié)構(gòu)如圖2所示.音頻處理模塊主要是對采集到語音數(shù)據(jù)進行處理,以降低語音數(shù)據(jù)中由于回聲、噪聲、聲音不平穩(wěn)等而造成通信效果不理想問題.因此對捕獲到的音頻數(shù)據(jù)都會進入音頻處理模塊對音頻數(shù)據(jù)進行相應的處理如回聲消除(AEC),噪聲抑制(ANS),增益控制(AGC)和靜音檢測(VAD)等.

圖2 音頻引擎結(jié)構(gòu)圖

WebRTC中比較突出的是其對音頻信息的處理,包括音頻數(shù)據(jù)的采集、組包、處理、編碼和發(fā)送等.下面音頻處理流程進行說明.

(1) 調(diào)用音頻設(shè)置進行音頻數(shù)據(jù)采集,將采集到的數(shù)據(jù)交給音頻引擎進行處理.

(2) 媒體數(shù)據(jù)經(jīng)過音頻引擎處理后形成音頻數(shù)據(jù)單元AudioFrame[11].

(3) 將AudioFrame送入音頻處理模塊進行處理,進行回聲和噪聲等處理.

(4) 處理完成后將語音數(shù)據(jù)送入靜音檢測模塊,確定該音頻數(shù)據(jù)是否為有效語音數(shù)據(jù),決定是否進行傳輸.

(5) 若通過靜音檢測,音頻數(shù)據(jù)會經(jīng)過混音處理,將音頻數(shù)據(jù)分發(fā)到各聲道,最終將音頻數(shù)據(jù)送入RTP傳輸模塊.反之則重回步驟(1)進行音頻采集.

其中,接收端接收到音頻數(shù)據(jù)后,由于媒體數(shù)據(jù)可能是多聲道傳送,接收端需要將音頻數(shù)據(jù)再次通過混音模塊[11]進行合音處理.

2.2 視頻處理分析

WebRTC對視頻的處理主要提供了5個功能模塊,主要包括視頻數(shù)據(jù)采集(Video capture)、數(shù)據(jù)處理(Video processing)、視頻編解碼(Video coding)、視頻數(shù)據(jù)渲染(Video render)和實時傳輸模塊(RTP/RTCP),各模塊間協(xié)作關(guān)系如圖3.各模塊的主要功能是,視頻采集：負責捕獲視頻數(shù)據(jù);視頻處理：對視頻數(shù)據(jù)進行處理,包括降噪、抽取、采樣等;視頻編解碼：對視頻數(shù)據(jù)進行編解碼處理;視頻渲染：用于接收端對接收到的視頻數(shù)據(jù)渲染處理并實現(xiàn)緩存,并投遞給顯示設(shè)備;實時傳輸模塊：接收數(shù)據(jù)包和進行包解析以提供實時傳輸.

圖3 視頻模塊協(xié)作關(guān)系圖

相應的視頻發(fā)送流程是：當發(fā)送源端產(chǎn)生視頻數(shù)據(jù),會調(diào)用視頻采集設(shè)備,將視頻數(shù)據(jù)封裝成視頻幀,按照設(shè)定好的速率傳到視頻幀采集模塊;視頻采集模塊收到數(shù)據(jù)后,對畫面進行處理,如視頻畫面亮度調(diào)整等操作,處理完成后將視頻幀數(shù)據(jù)送入處理模塊進行噪聲、抽取和采樣等處理,處理完成后將數(shù)據(jù)送入編碼模塊進行編碼;最后送入實時傳輸模塊.在視頻接收處理過程中,由于視頻解碼相對于編碼處理時間要長,為了保證視頻顯示質(zhì)量,一般在終端開辟單獨的視頻解碼線程來處理[12].

3 實時通信系統(tǒng)架構(gòu)

將WebRTC技術(shù)應用到醫(yī)療領(lǐng)域,用來實現(xiàn)醫(yī)生和出院患者之間的實時音視頻通信,并結(jié)合患者住院信息建立診后醫(yī)療問診系統(tǒng),本文主要對實時通信模塊進行研究與實現(xiàn).

3.1 實時通信架構(gòu)設(shè)計

診后醫(yī)療系統(tǒng)的實時通信平臺的主要功能是實現(xiàn)患者與醫(yī)生在線實時問診,實時通信平臺的主要架構(gòu)如圖4所示,在通信架構(gòu)中主要應用會話控制服務器、B2BUA信令服務器、SBC服務器來實現(xiàn)終端實時音視頻通信.

圖4 實時通信架構(gòu)圖

會話控制服務器：負責接收SIP信令消息,對其進行處理并最終將SIP信令[13]轉(zhuǎn)發(fā)給B2BUA服務器.

B2BUA信令服務器：負責對收到的SIP消息解析,SIP改寫、會話保持等.主要是對系統(tǒng)中與INVITE相關(guān)的SIP消息進行處理,B2BUA結(jié)構(gòu)的信令服務器在主叫端與被叫端之間分別建立并維持會話[13],在本實時通信平臺中用其實現(xiàn)信令代理功能.

SBC媒體控制服務器：負責分配通信地址與端口,作為終端會話媒體的中繼節(jié)點并實現(xiàn)通信媒體備份存檔,B2BUA服務器對其進行控制,以實現(xiàn)網(wǎng)絡穿越.

業(yè)務接口服務器：為系統(tǒng)提供服務接口控制、實現(xiàn)與醫(yī)院現(xiàn)有系統(tǒng)的數(shù)據(jù)對接.

3.2 實時通信服務器設(shè)計

通信平臺主要設(shè)計了會話控制服務器、B2BUA信令服務器和SBC服務器,相互協(xié)作完成終端實時通信.

會話控制服務器負責接收終端發(fā)送的請求,將請求發(fā)送到SIP、B2BUA服務器,會話控制服務器接收到SIP消息后會將消息解析,其中主要包括REGISTER注冊消息、INVITE呼叫消息和OPTION會話保持消息和通知消息,其中主要的是對INVITE呼叫消息進行處理,用以完成終端實時通信的會話協(xié)商.SIP服務器主要實現(xiàn)終端用戶的SIP注冊功能.B2BUA信令服務器主要是對SIP消息進行解析,負責信令代理功能并與終端分別建立并維持會話,與SBC服務器協(xié)作實現(xiàn)網(wǎng)絡穿越.SBC服務器主要實現(xiàn)媒體代理,完成媒體轉(zhuǎn)接,在終端協(xié)商成功后,終端發(fā)送實時媒體流到SBC服務器進行處理,平臺服務器的架構(gòu)如圖5.

圖5 服務器架構(gòu)圖

3.3 實時音視頻通信架構(gòu)

問診平臺主要是依托實時通信而實現(xiàn)的,用戶應用智能終端作為服務入口,通信終端通過業(yè)務接口進行前期的業(yè)務綁定,建立醫(yī)生和患者的對應關(guān)系,然后進行終端會話信令協(xié)商,最后應用WebRTC的音視頻控制模塊進行媒體數(shù)據(jù)處理、編碼和傳輸控制等.平臺通過代理服務器完成網(wǎng)絡穿越,最終實現(xiàn)終端會話,通信架構(gòu)分為業(yè)務對接、信令處理、音視頻控制模塊和服務代理模塊,各個模塊的關(guān)系如圖6所示.

圖6 實時通信架構(gòu)圖

3.4 會話流程設(shè)計

醫(yī)生或患者通過智能設(shè)備登錄終端,調(diào)用業(yè)務控制接口,查詢相關(guān)醫(yī)生、患者及醫(yī)院信息并進一步進行相應操作.下面是問診平臺會話流程的處理過程.

(1) 出院患者通過智能終端進行登錄,首次登錄用戶需進行醫(yī)院選擇、錄入患者住院號和身份證號等,并調(diào)用業(yè)務接口查詢主治醫(yī)師,建立關(guān)系綁定.

(2) 醫(yī)生登錄終端并調(diào)用業(yè)務接口,查詢建立醫(yī)患綁定的患者基本情況和病歷信息.

(3) 患者通過終端與綁定的醫(yī)生發(fā)起問診邀請消息.

(4) 醫(yī)生登錄終端,選擇問診患者,建立會話呼叫.

(5) 醫(yī)生終端組裝INVITE信令,發(fā)往會話控制服務器,經(jīng)分析處理后轉(zhuǎn)接給信令代理服務器處理.

(6) B2BUA信令服務器接收INVITE信令后,向SBC服務器發(fā)送地址申請并對信令重寫,向患者終端發(fā)送INVITE信令.

(7) 患者終端接收信令后,組裝應答信令,發(fā)往B2BUA信令服務器,經(jīng)處理后發(fā)往醫(yī)生終端.

(8) 醫(yī)生終端接收到響應信令,進行信令解析設(shè)置,協(xié)商完成后,進行媒體通話.

(9) 終端調(diào)用WebRTC中的音/視頻采集組件進行數(shù)據(jù)采集.

(10) 音頻模塊設(shè)置音頻狀態(tài)、速率、帶寬、通道,調(diào)用采集設(shè)備進行數(shù)據(jù)采集、數(shù)據(jù)控制處理,如降噪、回聲、靜音檢測等處理等、數(shù)據(jù)編碼等.

(11) 視頻模塊設(shè)置視頻顯示參數(shù)如,大小、幀率、載荷等,調(diào)用采集設(shè)備采集視頻數(shù)據(jù),對數(shù)據(jù)進行畫面處理和數(shù)據(jù)編碼等.

(12) 經(jīng)過采集編碼后的媒體數(shù)據(jù),經(jīng)SBC服務器所建立的地址映射關(guān)系,建立實時傳輸.

(13) 患者終端接收到音視頻數(shù)據(jù)后,經(jīng)WebRTC音視頻處理模塊處理.

(14) 經(jīng)處理后的媒體數(shù)據(jù)流調(diào)用WebRTC解碼模塊進行解碼處理后,調(diào)用顯示設(shè)備呈現(xiàn)給醫(yī)生.

其中,會話的建立是步驟(1)-(8),會話建立后,雙方可同時應用終端向?qū)Ψ桨l(fā)送音視頻媒體流,如步驟(10)-(14).

3.5 系統(tǒng)運行展示

圖7是問診系統(tǒng)醫(yī)生的排班情況,圖8患者與醫(yī)生在線問診的運行截圖.

4 實現(xiàn)要點分析

4.1 信令代理實現(xiàn)

平臺中應用B2BUA結(jié)構(gòu)的信令服務器實現(xiàn)信令代理功能,通過UAS (User Agent Server)、UAC (User Agent Client)完成信令的接收、修改和轉(zhuǎn)發(fā).以信令協(xié)商為例介紹信令代理的實現(xiàn),信令協(xié)商的主要功能是處理呼叫端(醫(yī)生)UAC發(fā)起的INVITE呼叫的相關(guān)消息,通過與代理服務器進行交互,最終將信令呼叫消息發(fā)送到被呼叫端(患者)UAS,以對INVITE信令進行處理,完成會話終端呼叫協(xié)商并建立通話,圖9是呼叫信令的代理模式處理過程.

圖7 醫(yī)生就診時間

圖8 患者在線問診

圖9 呼叫信令處理過程

(1) 醫(yī)生發(fā)起呼叫請求,終端UAC向會話管理服務器發(fā)送INVITE信令,經(jīng)解析處理后,將信令轉(zhuǎn)發(fā)到B2BUA信令服務器.

(2) 代理服務器的UAS收到INVITE信令后,向SBC服務器發(fā)送控制請求,最終對信令進行改寫,并通過UAC發(fā)送到患者終端,B2BUA信令服務器在通信終端分別維持會話.

(3) 患者收到INVITE消息后,構(gòu)造響應消息如180 Ringing、200 OK,發(fā)送給信令代理服務器,控制模塊對其改寫并發(fā)送給醫(yī)生終端,完成媒體協(xié)商.

4.2 媒體代理實現(xiàn)

本實時通信系統(tǒng)中通過B2BUA和SBC結(jié)構(gòu)的服務器實現(xiàn)信令和媒體的代理功能,SBC服務器受信令服務器的控制,用以處理實時通信的媒體流,是通信終端媒體數(shù)據(jù)的中轉(zhuǎn)點,主要是實現(xiàn)地址映射和通信媒體流的控制.

地址映射：在信令協(xié)商時,信令代理服模塊向SBC服務器發(fā)送控制請求,請求為本次會話分配公網(wǎng)地址和端口號,代理模塊分配并存儲該地址和端口.在信令協(xié)商成功后,通信雙方的實時音視頻流會發(fā)往本次分配的地址和端口,終端先進行音頻啞包發(fā)送,以打通媒體網(wǎng)絡通道,服務器對到達的實時數(shù)據(jù)包所處網(wǎng)絡建立地址映射,實現(xiàn)后期通信媒體流的轉(zhuǎn)接.

媒體流控制：考慮到實時問診系統(tǒng)的業(yè)務背景,需要對通信數(shù)據(jù)進行備份轉(zhuǎn)存,媒體服務器對會話終端所通過的媒體流進行存儲備份,并能對媒體流進行控制,統(tǒng)計終端通話時長等.

4.3 終端媒體數(shù)據(jù)處理

在本實時通信終端,采用WebRTC技術(shù)來實現(xiàn)終端音視頻處理與控制,在WebRTC中對實時音視頻的處理是分開的,各自調(diào)用設(shè)備采集并通過信道進行傳輸.但是對于音視頻發(fā)送流程不同的是,音頻數(shù)據(jù)需要混音處理操作,多路視頻畫面接收后沒有類似多路音頻混音的操作,而是分別進行渲染.應用終端音視頻處理流程如圖10所示.

5 結(jié)論與展望

基于WebRTC的實時音視頻通信應用具有良好的跨平臺性,它的提出為全平臺的音視頻互通提供了技術(shù)可行性,為研究實時音視頻解決方案提供了技術(shù)基礎(chǔ),將WebRTC技術(shù)與移動醫(yī)療領(lǐng)域相結(jié)合并與現(xiàn)有醫(yī)院信息系統(tǒng)相對接以設(shè)計和實現(xiàn)出針對出院患者再就醫(yī)需求的線上問診的實時通信服務系統(tǒng),不僅有效提升了在線問診的用戶體驗度和服務質(zhì)量,還解決了慢性病患者的長期就醫(yī)難問題.目前WebRTC技術(shù)也存在著一些不足,如對音視頻處理的設(shè)置參數(shù)多數(shù)是取自經(jīng)驗值且沒有提供多人會話方案,并且服務器集群管理方面都需要我們對其進行進一步研究以此更好的實現(xiàn)移動醫(yī)療領(lǐng)域的實時音視頻通信.

圖10 音視頻數(shù)據(jù)處理

1 張向輝,黃佳慶,吳康恒,等.基于WebRTC的實時視音頻通信研究綜述.計算機科學,2015,42(2)：1-6,32.[doi：10.11896/j.issn.1002-137X.2015.02.001]

2 張永強,張捍東,趙金寶.SIP協(xié)議棧研究.計算機技術(shù)與發(fā) 展 ,2007,17(11)：49-51,56.[doi：10.3969/j.issn.1673-629X.2007.11.015]

3 王榮生.SDP協(xié)議在視頻點播系統(tǒng)中的應用.計算機應用與軟件,2005,22(1)：74-76.

4 潘平.會話邊界控制設(shè)備SBC應用的相關(guān)研究.廣東通信技術(shù),2010,30(5)：14-17.

5 林鴻,王松,楊鑫,等.基于WebRTC技術(shù)的應用及平臺技術(shù)開發(fā)與設(shè)計.電信科學,2013,29(9)：20-25,36.

6 吳江銳.WebRTC語音引擎中NetEQ技術(shù)的研究[碩士學位論文].西安：西安電子科技大學,2013.

7 Bankoski J,Wilkins P,Xu YW.Technical overview of VP8,an open source video codec for the web.Proceedings of 2011 IEEE International Conference on Multimedia and Expo.Barcelona,Spain.2011.1-6.

8 朱光,張云華,盧娟.基于ICE的VOIP穿越NAT方案的研究.計算機應用與軟件,2011,28(10)：222-224,234.[doi：10.3969/j.issn.1000-386X.2011.10.064]

9 Amirante A,Castaldi T,Miniero L,et al.On the seamless interaction between WebRTC browsers and SIP-based conferencing systems.IEEE Communications Magazine,2013,51(4)：42-47.[doi：10.1109/MCOM.2013.6495759]

10 劉亞杰,王暉,郭波.P2P流媒體數(shù)據(jù)調(diào)度研究綜述.計算機應用,2008,28(4)：829-831,848.

11 王亞輝.基于WebRTC語音引擎的會議混音技術(shù)研究[碩士學位論文].西安：西安電子科技大學,2013.

12 熊雨新.基于WebRTC引擎的音頻視頻交互系統(tǒng)設(shè)計與實現(xiàn)[碩士學位論文].成都：電子科技大學,2014.

13 雷為民,李偉.基于SIP B2BUA的媒體服務器的集成.小型微型計算機系統(tǒng),2008,29(11)：2060-2064.