胡 勛，周淵平

（四川大學(xué) 電子信息學(xué)院，四川 成都 610065）

0 引言

本文提出了一種在移動(dòng)端上（Android）的視頻傳輸技術(shù)，選取了兩臺(tái)Android設(shè)備作為測(cè)試設(shè)備，方便快捷，而且可攜帶性強(qiáng)。移動(dòng)智能終端作為監(jiān)控端也是一個(gè)最佳的應(yīng)用平臺(tái)。隨著谷歌Android的飛速發(fā)展[1]，越來越多的人選擇Android平臺(tái)來觀察視頻數(shù)據(jù)。

1 技術(shù)簡(jiǎn)介

（1）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ā)人員決定。

（2）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)用場(chǎng)景，因?yàn)樗饕轻槍?duì)低延時(shí)而設(shè)計(jì)的編解碼器。Video Jitter Buffer（視頻抖動(dòng)緩沖器），可以降低由于視頻抖動(dòng)和視頻信息包丟失帶來的不良影響。對(duì)音視頻模塊VoiceEngine和VideoEngine進(jìn)行編譯使用，首先要到Google上下載安卓NDK，然后還要安裝其他一些工具。以下對(duì)兩個(gè)庫(kù)文件簡(jiǎn)單解釋，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描述符，流程如下：

（1）A和B雙方建立一個(gè)RTCPeerConnection實(shí)例。

（2）A通過 createOffer（）方法建立一個(gè)包含 A的SDP描述符的offer信令。

（3）A 通過 setLocalDescription（）方法，將 A 的 SDP描述符交給A的RTCPeerConnection實(shí)例。

（4）A將offer信令通過服務(wù)器發(fā)送給 B。

（5）B將 A的 offer信令中所包含的 SDP描述符提取出來，并通過setRemoteDescription（）方法交給B的RTCPeerConnection實(shí)例。

（6）B通過createAnswer（）方法建立一個(gè)包含 B的SDP描述符的answer信令。

（7）B 通 過 setLocalDescription（）方 法 將 B 的 SDP 描述符交給B的RTCPeerConnection實(shí)例。

（8）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è)簡(jiǎn)單的任務(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層，但是原理是一樣的，原理如下：

圖1 iceServers配置信息

（1）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)。

（4）若房間號(hào)相同，則建立A和B的通信連接。

系統(tǒng)框架如圖2所示。

圖2 系統(tǒng)框圖

圖2 中兩個(gè)peer分別指兩個(gè)終端用戶，NAT的用途是作為穿透使用，turnserver是由一個(gè)STUN服務(wù)器加上中繼功能構(gòu)成，當(dāng)建立一個(gè)基于UDP的連接失敗了，ICE就會(huì)使用一個(gè)中繼的TURN服務(wù)器也就是Relay server。

3 測(cè)試及結(jié)果

在本次測(cè)試中，采用的兩臺(tái)Android手機(jī)分別是三星平板和魅族手機(jī)。如圖3所示兩臺(tái)Android平臺(tái)（一臺(tái)是安卓手機(jī)，一臺(tái)是安卓平板）正在進(jìn)行視頻傳輸，從屏幕中既可以觀察遠(yuǎn)端傳過來的情況又可以觀察自己要傳出去的視頻情況。

圖3 實(shí)驗(yàn)結(jié)果

4 結(jié)論

本文采用WebRTC音視頻技術(shù)，利用NAT穿透和信令服務(wù)的搭建，實(shí)現(xiàn)了移動(dòng)終端的無線視頻傳輸。NAT穿透在實(shí)現(xiàn)跨網(wǎng)功能上起到了巨大的作用，對(duì)于安卓移動(dòng)端具有良好的應(yīng)用價(jià)值。

[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.