孫建偉,陳 立,2,王 衛(wèi)

1(中國科學(xué)院 沈陽計算技術(shù)研究所,沈陽 110168)

2(中國科學(xué)院大學(xué),北京 100049)

Web實時通信(WebRTC)[1]是一種構(gòu)建在Web瀏覽器上的實時音視頻通信技術(shù).WebRTC由Google收購 Global IP Solution 公司而獲得的一項技術(shù),并在2011年將其開源.WebRTC提供了音視頻采集、網(wǎng)絡(luò)傳輸、音視頻編解碼、信號優(yōu)化和處理等[2]一整套的音視頻通信解決方案.由于WebRTC強大的多媒體處理引擎,WebRTC 已經(jīng)在 Chrome、Firefox、Opera、Android、iOS等瀏覽器和平臺上得到了支持.

會話初始協(xié)議(Session Initiation Protocol,SIP)是一個應(yīng)用層的信令控制協(xié)議,是IMS的核心的、成熟的、已經(jīng)得到廣泛應(yīng)用的技術(shù),用于創(chuàng)建、修改和釋放一個或多個參與者的會話.WebRTC提供的JSEP是一種僅維護信令狀態(tài)機的弱信令控制協(xié)議,在企業(yè)級融合通信應(yīng)用中必須將WebRTC和實際的信令協(xié)議相結(jié)合.

本文介紹了WebRTC和SIP融合已有的兩種方案,分析了WebRTC和SIP互通需要解決的問題,提出了一種WebRTC的PeerConnection層和SIP協(xié)議在客戶端融合的方案,最后在多種客戶端實現(xiàn)了WebRTC和SIP融合的應(yīng)用,并和其他方案對比得出了此方案的優(yōu)缺點.

1 相關(guān)技術(shù)簡介

1.1 SIP協(xié)議簡介

SIP是基于文本的、獨立于傳輸層的應(yīng)用層IMS核心協(xié)議.其用于建立,結(jié)束以及中斷多媒體會話[3].

1.2 WebRTC簡介

WebRTC語音引擎支持iSAC、iLBC、Opus 等多種編解碼器.音頻NetEQ算法包括抖動緩沖和丟包補償模塊以延遲減至最小并提高音頻質(zhì)量[4].WebRTC視頻引擎包含采集、編解碼(VP9、VP8、可添加H264等編解碼器)、加解密、媒體文件、圖像處理與顯示、網(wǎng)絡(luò)傳輸與媒體流控制等技術(shù)[5].WebRTC提供JSEP這樣的弱信令目的就是為了讓W(xué)ebRTC強大的多媒體處理能力可以和不同的實際的信令協(xié)議相結(jié)合,如 SIP、ROAP、XMPP、Jingle 等[6].

2 WebRTC 的 PeerConnection 層和 SIP 協(xié)議在客戶端融合方案的研究

從信令的角度來看,當(dāng)下主要有兩種SIP和WebRTC互通方案[7]:一種是基于服務(wù)器開發(fā) SIP/WebRTC 轉(zhuǎn)換網(wǎng)關(guān).另一種是用 JavaScript 實現(xiàn) SIP 協(xié)議,在此協(xié)議棧的基礎(chǔ)上構(gòu)建WebRTC 應(yīng)用.

2.1 基于服務(wù)器端的信令轉(zhuǎn)化網(wǎng)關(guān)實現(xiàn)WebRTC和IMS網(wǎng)絡(luò)互通

這種方案通過開發(fā)SIP/WebRTC轉(zhuǎn)化網(wǎng)關(guān)實現(xiàn)SIP信令和WebRTC信令的轉(zhuǎn)化,如webrtc2sip[8]就是這種方案的典型代表.基于服務(wù)器端的信令轉(zhuǎn)化網(wǎng)關(guān)實現(xiàn)WebRTC和IMS網(wǎng)絡(luò)互通架構(gòu)圖如圖1所示.

2.2 基于JavaScript實現(xiàn)的SIP協(xié)議開發(fā)IMS客戶端

這種方案用JavaScript實現(xiàn)SIP協(xié)議并向Web應(yīng)用開發(fā)者提供JavaScript API.開發(fā)者調(diào)用WebRTC JavaScript API開發(fā)出的 WebRTC 應(yīng)用可以采用WebSocket傳輸SIP信令.開發(fā)者通過此類WebRTC應(yīng)用直接注冊并登錄支持WebSocket[9]的SIP Server,與傳統(tǒng) SIP終端進(jìn)行通信.使用這種解決方案的開源SIP項目有Jssip和SipML5.

圖1 基于服務(wù)器端的信令轉(zhuǎn)化網(wǎng)關(guān)實現(xiàn)WebRTC和IMS網(wǎng)絡(luò)互通架構(gòu)

2.3 WebRTC的PeerConnection層和SIP協(xié)議在客戶端融合方案

WebRTC C++ API(PeerConnection 層)是面向瀏覽器廠商的,使的瀏覽器廠商容易在此基礎(chǔ)上實現(xiàn)WebRTC標(biāo)準(zhǔn)的Web API.本文提出了一種WebRTC的PeerConnection層和SIP協(xié)議在客戶端實現(xiàn)融合互通的方案,可以適當(dāng)避免上述兩種方案的缺陷.該方案主要通過內(nèi)嵌于客戶端SIPRTC本地網(wǎng)關(guān)做WebRTC SDP和 SIP SDP的轉(zhuǎn)化及 SIP信令和 WebRTC PeerConnection API的映射.該方案基于 WebRTC PeerConnection API,但不局限于 C++ API,也包括編譯等手段產(chǎn)生的其他語言的PeerConnection 層API,相應(yīng)的不同終端結(jié)合的SIP模塊會有所不同.WebRTC的PeerConnection層和SIP協(xié)議在客戶端的融合方案架構(gòu)如圖2所示.

方案一需要在SIP服務(wù)器上開發(fā)為了兼容WebRTC信令的轉(zhuǎn)換網(wǎng)關(guān),開發(fā)成本較高,服務(wù)器也會因信令的轉(zhuǎn)換產(chǎn)生一定的延遲.但是該方案會減輕客戶端的開發(fā)負(fù)擔(dān).方案二需要瀏覽器支持WebRTC,雖然目前主流的瀏覽器都已支持WebRTC,但限于瀏覽器的 WebRTC JavaScript API尚處于草案階段,在此基礎(chǔ)上開發(fā)應(yīng)用會有所不便.但這種開發(fā)方式的開發(fā)流程較為簡單,代碼可以實現(xiàn)跨平臺.這兩種案都需要服務(wù)器端傳輸通道支持WebSocket;且這兩種方案開發(fā)的都是Web應(yīng)用,Web應(yīng)用在性能上會低于原生應(yīng)用.

本文提出的方案首先可以不必在服務(wù)器端做兼容WebRTC的開發(fā),從而減小服務(wù)器的壓力和信令轉(zhuǎn)換造成延遲;其次不需要服務(wù)器傳輸通道支持WebSocket,從而減小服務(wù)器傳輸通道的限制;最后由于此時客戶端由本來的 Web App 一躍變成 Native App,也一定程度上提高了客戶端的性能.該方案一定程度上加大了客戶端的工作量,但對比方案一的工作量,該方案的工作量完全可以接受.

圖2 WebRTC 的 PeerConnection 層和 SIP 協(xié)議在客戶端的融合方案架構(gòu)

3 WebRTC 的 PeerConnection 層和 SIP 協(xié)議在客戶端融合系統(tǒng)設(shè)計與實現(xiàn)

本方案中最重要的一個環(huán)節(jié)就是SIPRTC本地網(wǎng)關(guān)的設(shè)計,其功能包括 WebRTC SDP 和 SIP SDP 轉(zhuǎn)化和 SIP 信令和 WebRTC PeerConnection API映射.

3.1 WebRTC的PeerConnection層和SIP協(xié)議在客戶端融合方案的本地網(wǎng)關(guān)設(shè)計

WebRTC 使用 JSEP(JavaScript Session Establish Protocol)提供的弱信令完成媒體協(xié)商.JSEP提供的信令分為主叫方的Offer信令和被叫方的Answer信令,信令中的主要信息均符合SDP(Session Description Protocol)標(biāo)準(zhǔn).WebRTC和SIP在媒體和信令的異同點對比如表1所示.

表1 WebRTC 和 SIP 媒體和信令的異同點對比表

本方案中客戶端通過SIPRTC本地網(wǎng)關(guān)做信令轉(zhuǎn)化和接口映射,WebRTC PeerConnection 和 SIP 協(xié)議的映射流程如圖3所示,其中Alice是主叫,Bob是被叫.WebRTC PeerConnection和SIP映射步驟如下:

(1)Alice 調(diào)用 PeerConnection 層 createoffer API,并通過SIPRTC本地網(wǎng)關(guān)轉(zhuǎn)化成SIP(INVITE)消息發(fā)送給Bob;

(2)Bob 接收 SIP 消息后,調(diào)用 PeerConnection 層setRemoteDescription、createAnswer API,并通過SIPRTC 本地網(wǎng)關(guān)轉(zhuǎn)化成 SIP(180 Ring、200 OK)消息發(fā)送給Alice;

(3)Alice 接收 SIP 消息,調(diào)用 PeerConnection 層setRemoteDescription API,并發(fā)送 SIP(ACK)消息給Bob,此時建立了p2p或者通過多媒體中轉(zhuǎn)服務(wù)器的多媒體會話;

(4)Alice調(diào)用 PeerConnection層removeRemoteStream API,并通過 SIPRTC 本地網(wǎng)關(guān)轉(zhuǎn)化成SIP(BYE)消息發(fā)送給Bob;

(5)Bob 接收 SIP 消息,調(diào)用 PeerConnection 層removeRemoteStream API,并發(fā)送 SIP(200 OK)消息給Alice,至此完成一次音視頻會話.

3.2 WebRTC的PeerConnection層和SIP協(xié)議在客戶端融合方案的應(yīng)用實現(xiàn)

圖4為客戶端應(yīng)用設(shè)計的架構(gòu),在完成SIPRTC本地網(wǎng)關(guān)后,業(yè)務(wù)邏輯只需調(diào)用SIP接口,從而便于業(yè)務(wù)邏輯的實現(xiàn);MQTT用于文本聊天等功能的實現(xiàn).

視各客戶端不同,WebRTC 的 PeerConnection 在不同平臺結(jié)合的SIP模塊稍有不同,具體來說Windows平臺選擇 pjsip[10],Android 平臺選擇 sipdroid,iOS 平臺選擇sofiasip;相應(yīng)的WebRTC的PeerConnection API不局限于某種語言的API,包括編譯手段產(chǎn)生的C++ API、Java API、OC API.

4 WebRTC 的 PeerConnection 層和 SIP 協(xié)議在客戶端融合方案的測試及對比

本實驗在服務(wù)器端使用OpenSIPS部署SIP服務(wù)器,使用 Google 的 Stun Server作為 ICE 代理,使用Asterisk服務(wù)器部署多媒體中轉(zhuǎn)服務(wù)器.

在Android、iOS、Windows客戶端完成了WebRTC PeerConnection 和 SIP 協(xié)議的融合,并測試了各平臺之間的音視頻通信.SIPRTC本地網(wǎng)關(guān)轉(zhuǎn)化的呼叫和響應(yīng)信令如圖5和圖6所示.Android端發(fā)出呼叫 并和iOS端視頻通話如圖7和圖8所示.

圖3 WebRTC PeerConnetion 和 SIP 映射流程

圖4 客戶端應(yīng)用設(shè)計架構(gòu)

圖5 SIPRTC 本地網(wǎng)關(guān)轉(zhuǎn)化的呼叫信令

圖6 SIPRTC 本地網(wǎng)關(guān)轉(zhuǎn)化的響應(yīng)信令

經(jīng)過多次測試和抓包分析,驗證了WebRTC的PeerConnection層在客戶端融合SIP協(xié)議方案的可行性,對比前兩種方案,發(fā)現(xiàn)本方案的客戶端流暢度要高于前兩種方案的客戶端;且本方案服務(wù)器造成的延遲要低于方案一的服務(wù)器,特別是服務(wù)器負(fù)載較大時,本方案服務(wù)器造成的延遲會明顯低于方案一的服務(wù)器.

5 結(jié)論

本文介紹了已有的WebRTC和SIP協(xié)議融合的方案,研究了WebRTC和SIP協(xié)議互通需要解決的問題,提出了一種WebRTC的PeerConnection層和SIP協(xié)議在客戶端融合的方案,通過查閱大量資料、搭建試驗環(huán)境、編碼、測試和對比,驗證了該方案的可行性和優(yōu)越性.但是由于使用Google提供的Stun Server做ICE代理,有時會有明顯的延遲,后期的工作將集中研究、開發(fā)及搭建自己的ICE代理;另外后期我們也將在不同應(yīng)用場景下對各客戶端的穩(wěn)定性做測試,盡早將該方案產(chǎn)品從實驗室推向市場.

圖7 Android 端發(fā)出呼叫

圖8 iOS 端視頻會話