摘 要： 視頻傳輸技術(shù)在現(xiàn)代社會(huì)廣泛應(yīng)用，人們對(duì)其的要求也越來越高，其發(fā)展的趨勢是方便、快捷、隨時(shí)隨地。傳統(tǒng)的視頻傳輸過于依賴線路，線路的走向限制了傳輸?shù)暮芏嗫赡?，所以無線傳輸才是發(fā)展的方向。本文提出了一種基于WebRTC的Android移動(dòng)端視頻傳輸技術(shù)，介紹了信令與WebRTC連接實(shí)現(xiàn)機(jī)制，以及穿透的具體過程。
關(guān)鍵詞： 信令；安卓；WebRTC
0 引言
本文提出了一種在移動(dòng)端上（Android）的視頻傳輸技術(shù)，選取了兩臺(tái)Android設(shè)備作為測試設(shè)備，方便快捷，而且可攜帶性強(qiáng)。移動(dòng)智能終端作為監(jiān)控端也是一個(gè)最佳的應(yīng)用平臺(tái)。隨著谷歌Android的飛速發(fā)展[1]，越來越多的人選擇Android平臺(tái)來觀察視頻數(shù)據(jù)。
1 技術(shù)簡介
?。?）Android系統(tǒng)
Android是基于Linux開放性內(nèi)核的操作系統(tǒng)，也是一個(gè)開放的移動(dòng)終端操作系統(tǒng)平臺(tái)，為移動(dòng)設(shè)備提供了一個(gè)包含了操作系統(tǒng)及應(yīng)用程序的軟件疊層架構(gòu)。Android作為Google最具創(chuàng)新的產(chǎn)品之一[2]，越來越多地被移動(dòng)終端廠商使用和二次開發(fā)。Android具有很多特性，最大的特性是開放性，還有就是在其平臺(tái)上開發(fā)的應(yīng)用程序權(quán)限由開發(fā)人員決定。
?。?）WebRTC
WebRTC是Google于2011年6月3日開源的即時(shí)通訊項(xiàng)目[3]。它是一個(gè)支持網(wǎng)頁瀏覽器進(jìn)行實(shí)時(shí)語音對(duì)話或視頻對(duì)話的技術(shù)，其出現(xiàn)可以幫助Web瀏覽器、個(gè)人電腦或手機(jī)實(shí)現(xiàn)實(shí)時(shí)多媒體通信功能。WebRTC提供了各種實(shí)現(xiàn)視頻會(huì)議的核心技術(shù)，包括音視頻的采集、編解碼、信號(hào)優(yōu)化和處理以及網(wǎng)絡(luò)傳輸?shù)取?/p>
2 系統(tǒng)設(shè)計(jì)及實(shí)現(xiàn)
系統(tǒng)設(shè)計(jì)主要包含三個(gè)部分：音視頻模塊、信令服務(wù)和打洞服務(wù)。
2.1 音視頻模塊
VoiceEngine（WebRTC音頻引擎）是包含一系列音頻多媒體處理的框架，包括從視頻采集卡到網(wǎng)絡(luò)傳輸端等整個(gè)解決方案。ISAC（Internet Speech Audio Codec）是針對(duì)VoIP和音頻流的寬帶和超寬帶音頻編解碼器，是WebRTC音頻引擎的默認(rèn)編解碼器。NetEQ for Voice是針對(duì)音頻的語音信號(hào)處理算法、自適應(yīng)抖動(dòng)控制算法以及語音包丟失隱藏算法。能夠快速且高解析度地適應(yīng)不斷變化的網(wǎng)絡(luò)環(huán)境，確保音質(zhì)優(yōu)美且緩沖延遲最小，能夠有效地處理由于網(wǎng)絡(luò)抖動(dòng)和語音包丟失對(duì)語音質(zhì)量產(chǎn)生的影響。VideoEngine（WebRTC視頻處理引擎），是包含一系列視頻處理的整體框架，是從攝像頭采集視頻到視頻信息網(wǎng)絡(luò)傳輸再到視頻顯示整個(gè)完整過程的解決方案。VP8視頻圖像編解碼器是WebRTC視頻引擎的默認(rèn)編解碼器，VP8適合實(shí)時(shí)通信應(yīng)用場景，因?yàn)樗饕轻槍?duì)低延時(shí)而設(shè)計(jì)的編解碼器。Video Jitter Buffer（視頻抖動(dòng)緩沖器），可以降低由于視頻抖動(dòng)和視頻信息包丟失帶來的不良影響。對(duì)音視頻模塊VoiceEngine和VideoEngine進(jìn)行編譯使用，首先要到Google上下載安卓NDK，然后還要安裝其他一些工具。以下對(duì)兩個(gè)庫文件簡單解釋，voe_audio_processingadds消噪（NS）：自動(dòng)增益控制和回聲控制；voe_rtp_rtcp：增加了RTCP發(fā)送器報(bào)告、RTP／RTCP統(tǒng)計(jì)、前向糾錯(cuò)（FEC）和RTP實(shí)時(shí)捕捉。
2.2 信令服務(wù)
信令服務(wù)的作用是在通信雙方都不知道對(duì)方的IP以及端口的情況下建立連接。由服務(wù)器建立連接來實(shí)現(xiàn)。WebRTC實(shí)現(xiàn)了兩個(gè)API，分別是：MediaStream：通過MediaStream的API能夠通過設(shè)備的攝像頭及話筒獲得視頻、音頻的同步流；RTCPeerConnection：RTCPeerConnection是WebRTC用于構(gòu)建點(diǎn)對(duì)點(diǎn)之間穩(wěn)定、高效的流傳輸?shù)慕M件。WebRTC使用RTCPeerConnection傳遞數(shù)據(jù)，但傳遞數(shù)據(jù)之前，需要一種機(jī)制來協(xié)調(diào)通信并發(fā)送控制信息，而這種機(jī)制就是信令機(jī)制。WebRTC并沒有制定任何信令的機(jī)制和協(xié)議，所以可以靈活選擇任何信令協(xié)議[4]。Openfire是一種開源的實(shí)時(shí)協(xié)作（RTC）服務(wù)器，本文設(shè)計(jì)用它作為信令服務(wù)器。
信令交換的信息有：（1）用來控制通信開啟或者關(guān)閉的連接控制消息；（2）媒體流元數(shù)據(jù)，比如解碼器、解碼器的配置、帶寬、媒體類型等；（3）發(fā)生錯(cuò)誤時(shí)彼此告知的消息；（4）外界所看到的網(wǎng)絡(luò)上的數(shù)據(jù)，如IP地址、端口等；（5）用來建立安全連接的關(guān)鍵數(shù)據(jù)。
具體的連接建立方式由一種叫JSEP（JavaScript Session Establishment Protocol）的協(xié)議來規(guī)定，使用JSEP的原因在于在JSEP中需要交換的關(guān)鍵信息是多媒體會(huì)話描述（Multimedia Session Description）。JSEP將客戶端之間傳遞的信令分為兩種：offer信令和answer信令。它們主要內(nèi)容的格式都遵循會(huì)話描述協(xié)議（Session Description Protocal，SDP）。通過offer和answer交換SDP描述符，流程如下：
?。?）A和B雙方建立一個(gè)RTCPeerConnection實(shí)例。
?。?）A通過createOffer（）方法建立一個(gè)包含A的SDP描述符的offer信令。
?。?）A通過setLocalDescription（）方法，將A的SDP描述符交給A的RTCPeerConnection實(shí)例。
?。?）A將offer信令通過服務(wù)器發(fā)送給B。
（5）B將A的offer信令中所包含的SDP描述符提取出來，并通過setRemoteDescription（）方法交給B的RTCPeerConnection實(shí)例。
?。?）B通過createAnswer（）方法建立一個(gè)包含B的SDP描述符的answer信令。
（7）B通過setLocalDescription（）方法將B的SDP描述符交給B的RTCPeerConnection實(shí)例。
?。?）B將answer信令通過服務(wù)器發(fā)送給A。
（9）A接收到B的answer信令后，將其中B的SDP描述符提取出來，調(diào)用setRemoteDescripttion（）方法交給B的RTCPeerConnection實(shí)例。通過這一系列的信令交換之后，A和B所創(chuàng)建的RTCPeerConnection實(shí)例都包含了A和B的SDP描述符了。
2.3 打洞服務(wù)
打洞服務(wù)就是為了獲取連接兩端設(shè)備的網(wǎng)絡(luò)地址[5]。要實(shí)現(xiàn)P2P視頻傳輸，實(shí)際應(yīng)用中不可能讓用戶自己去設(shè)置對(duì)方的IP和音視頻端口，而且即使設(shè)置了對(duì)方的IP和端口也不一定能運(yùn)行，因?yàn)镻2P視頻傳輸過程中，如果雙方不在同一個(gè)網(wǎng)段則還需穿透NAT。
打洞原理：主要思路就是通過STUN服務(wù)器獲取自己的IP、Port及NAT信息，然后通過信令服務(wù)器交換這些信息，最后兩客戶端根據(jù)各自得到的IP、Port、NAT信息進(jìn)行相應(yīng)的穿透。STUN是一種網(wǎng)絡(luò)協(xié)議，可以讓處于NAT后的客戶端找出自己所處的公網(wǎng)IP地址，而且可以獲取自己的NAT類型，以及一些相關(guān)的端口信息，這些信息用來在兩個(gè)處于NAT之后的主機(jī)建立UDP通信。STUN由RFC 5389定義，是一個(gè)客戶機(jī)－服務(wù)器協(xié)議，由于每個(gè)peer可能處于不同的網(wǎng)絡(luò)中，所以每個(gè)peer都需要NAT穿越，確保雙方都可訪問對(duì)方的IP地址和端口以及STUN服務(wù)器。在RTCPeerConnection中，使用ICE框架來保證RTCPeerConnection能實(shí)現(xiàn)NAT穿越。ICE（Interactive Connectivity Establishment），交互式連接建立，是一種綜合性的NAT穿越技術(shù)，可以整合各種NAT穿越技術(shù)，如STUN、TURN（Traversal Using Relay NAT，中繼NAT實(shí)現(xiàn)的穿透）。ICE會(huì)先使用STUN，如果失敗，ICE就會(huì)使用一個(gè)中繼的TURN服務(wù)器。圖1為iceServers配置信息。
在iceServers配置對(duì)象（RTCPeerConnection constructor）中設(shè)置STUN and/or TURN服務(wù)器地址信息，包括IP地址、端口號(hào)等。有了這些信息ICE會(huì)自動(dòng)啟動(dòng)。STUN服務(wù)架設(shè)在外網(wǎng)，它有一個(gè)簡單的任務(wù)：獲取一個(gè)發(fā)送請(qǐng)求的設(shè)備（運(yùn)行在NAT后邊的應(yīng)用）的IP和端口，然后返回這個(gè)地址。換句話說，應(yīng)用使用STUN服務(wù)器發(fā)現(xiàn)它的外網(wǎng)IP和端口，這個(gè)過程確保了一個(gè)WebRTC端獲得它自己的公共地址，然后通過signaling機(jī)制發(fā)送這個(gè)信息給另一端，這樣就可以建立起一個(gè)直接連接。在實(shí)際應(yīng)用中，不同的NATs有不同的工作方式，可能有多個(gè)NAT層，但是原理是一樣的，原理如下：
?。?）A通過公共IP與服務(wù)器建立連接。
（2）A發(fā)送一個(gè)加入某房間的信令，并設(shè)置房間號(hào)，信令中需要包含該房間的編號(hào)。
（3）若有新用戶B加入，B會(huì)向服務(wù)器發(fā)送一個(gè)請(qǐng)求信令（new_peer），信令中包含新加入的用戶B的信息以及房間號(hào)。
?。?）若房間號(hào)相同，則建立A和B的通信連接。
系統(tǒng)框架如圖2所示。
圖2中兩個(gè)peer分別指兩個(gè)終端用戶，NAT的用途是作為穿透使用，turnserver是由一個(gè)STUN服務(wù)器加上中繼功能構(gòu)成，當(dāng)建立一個(gè)基于UDP的連接失敗了，ICE就會(huì)使用一個(gè)中繼的TURN服務(wù)器也就是Relay server。
3 測試及結(jié)果
在本次測試中，采用的兩臺(tái)Android手機(jī)分別是三星平板和魅族手機(jī)。如圖3所示兩臺(tái)Android平臺(tái)（一臺(tái)是安卓手機(jī)，一臺(tái)是安卓平板）正在進(jìn)行視頻傳輸，從屏幕中既可以觀察遠(yuǎn)端傳過來的情況又可以觀察自己要傳出去的視頻情況。
4 結(jié)論
本文采用WebRTC音視頻技術(shù)，利用NAT穿透和信令服務(wù)的搭建，實(shí)現(xiàn)了移動(dòng)終端的無線視頻傳輸。NAT穿透在實(shí)現(xiàn)跨網(wǎng)功能上起到了巨大的作用，對(duì)于安卓移動(dòng)端具有良好的應(yīng)用價(jià)值。
參考文獻(xiàn)
[1] 李寧.Android開發(fā)權(quán)威指南[M].北京：人民郵電出版社，2011.
[2] 丁鶴洋，李太君，徐瑛.3G無線視頻監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].通信技術(shù)，2012，45（2）：68-70.
[3] 鄒勇.基于XMPP和Webrtc的web實(shí)時(shí)通訊[D].南京：南京大學(xué)，2012.
[4] 王璐.Web模式下基于XMPP的即時(shí)通信系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].北京：北京郵電大學(xué)，2010.
[5] 楊佳勝.基于Android終端的視頻通話系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[D].大連：大連理工大學(xué)，2011.