基于RTP的WebRTC音視頻傳輸優(yōu)化方法

李 波, 李雪夢, 王彥本

(西安郵電大學(xué) 通信與信息工程學(xué)院, 陜西 西安 710121)

網(wǎng)頁實時通信(Web real-time communication,WebRTC)集成了音視頻的采集和顯示、網(wǎng)絡(luò)傳輸?shù)群诵募夹g(shù)，可在不同平臺下，實現(xiàn)瀏覽器之間的音視頻通信[1]。與C/S和B/S架構(gòu)相比， WebRTC無需下載相關(guān)插件，方便快捷[2]。但是，無線信道帶寬資源屬于稀有資源，在數(shù)據(jù)傳輸過程中，WebRTC受到無線信道自身時變及帶限等特點的影響，容易造成音視頻數(shù)據(jù)傳輸不流暢和質(zhì)量低等問題。

目前，WebRTC主要采用實時傳輸協(xié)議(real-time transport protocol，RTP)進行音視頻實時傳輸，對RTP報文結(jié)構(gòu)進行壓縮，或者調(diào)整RTP的分包方式，可減小傳輸數(shù)據(jù)的大小，減緩網(wǎng)絡(luò)壓力，但不能從實質(zhì)上避免無線網(wǎng)絡(luò)環(huán)境下WebRTC音視頻傳輸中出現(xiàn)的網(wǎng)絡(luò)延時和丟包問題[3]。本文擬在RTP協(xié)議進行音視頻數(shù)據(jù)實時傳輸時，根據(jù)網(wǎng)絡(luò)狀況及時開啟丟包重傳機制，同時動態(tài)調(diào)整抖動緩沖區(qū)大小，以期降低丟包率，保證音視頻傳輸質(zhì)量。

1 RTP/RTCP協(xié)議

RTP協(xié)議[4]作為實時傳輸協(xié)議，可以在單個發(fā)送者與單個接收者或單個發(fā)送者與多個接收者的情況下工作，其目的是提供時間信息以及實現(xiàn)流同步，但僅有RTP協(xié)議并不能保證傳輸?shù)目煽啃浴Ｔ趥鬏斶^程中，還需依靠實時傳輸控制協(xié)議(real-time transport control protocol,RTCP)提供流量控制和擁塞控制[5]。RTP協(xié)議之所以能實現(xiàn)數(shù)據(jù)傳輸?shù)膶崟r性，主要依靠報文中序列號和時間戳等關(guān)鍵信息。RTP頭字段格式如圖1所示。

RTP協(xié)議與RTCP協(xié)議在工作中相互協(xié)作，一般承載在用戶數(shù)據(jù)報協(xié)議(user datagram protocol,UDP)之上。RTP協(xié)議使用一個偶數(shù)UDP端口號，RTCP協(xié)議則使用一個相鄰的奇數(shù)UDP端口號；RTP保證數(shù)據(jù)傳輸?shù)膶崟r性，RTCP協(xié)議則負責(zé)數(shù)據(jù)的可靠傳輸，以保證服務(wù)質(zhì)量[6]。

2 RTP傳輸優(yōu)化方法

WebRTC是基于Web瀏覽器的實時音視頻的通信技術(shù)[7]，主要包括音頻模塊、視頻模塊和傳輸模塊3個部分，其結(jié)構(gòu)如圖2所示。其中傳輸模塊由RTP/RTCP協(xié)議負責(zé)，RTP報文頭部提供了負載類型、時間戳、序列號和同步源等信息保證基本的音視頻傳輸需求[8]。

在WebRTC中，發(fā)送端采集好數(shù)據(jù)，由傳輸模塊對其進行封包并交給網(wǎng)絡(luò)模塊進行發(fā)送；同理，在接收端將收到的數(shù)據(jù)進行解包，再交由其他模塊進行處理[9]。開啟一個RTP會話之后，參與此會話的通信雙方將周期性的發(fā)送RTCP報文，報文中包含通信雙方發(fā)送及接收數(shù)據(jù)的具體統(tǒng)計信息，對服務(wù)質(zhì)量做出反饋[10]。根據(jù)RTCP協(xié)議的反饋，可在網(wǎng)絡(luò)傳輸層通過丟包重傳和動態(tài)調(diào)整抖動緩沖區(qū)大小等方法降低丟包率，以此提高音視頻傳輸質(zhì)量。

2.1 丟包重傳

實時音視頻傳輸過程中，丟包現(xiàn)象會導(dǎo)致音視頻不流暢。丟包重傳機制(negative-acknowledge character,NACK)[11]就是否定應(yīng)答，在實時音視頻傳輸中，對于丟失的包，可以給對端發(fā)送NACK包，請求對端重新發(fā)送[12]。依據(jù)RTCP報文的反饋，選擇性發(fā)起NACK請求，若丟失的包對整體數(shù)據(jù)沒有太大影響，則不需要進行重傳，可通過其他容錯機制保障可靠性，減少因重傳而帶來的延時問題。NACK報文是RTCP擴展反饋報文，具體格式如圖3所示。

圖3 NACK報文格式

圖3中， NACK報文統(tǒng)計RTP包丟失的序列號，以及繼該包之后的16個RTP數(shù)據(jù)包的丟失情況。在每個NACK報文中，都可以攜帶一個或多個RTP序列號，接收端會依次進行處理[13]。接收端收到NACK請求后，分析報文，根據(jù)報文中包含的RTP序列號，到相應(yīng)的RTP緩存中查找需要的RTP包，如果找到，則把數(shù)據(jù)包發(fā)送到網(wǎng)絡(luò)，丟失的數(shù)據(jù)包就會重新發(fā)送到接收端，完成丟包重傳。

2.2 緩沖區(qū)大小的動態(tài)調(diào)整

網(wǎng)絡(luò)中存在路由變化和網(wǎng)絡(luò)擁塞等問題，在傳輸數(shù)據(jù)包時，它并不總是按時間和順序均勻到達，此時需要設(shè)置緩沖區(qū)存放這些數(shù)據(jù)包并對這些數(shù)據(jù)包重新進行排序，消除網(wǎng)絡(luò)中存在的網(wǎng)絡(luò)抖動等狀況[14]。

若緩沖區(qū)設(shè)置過小，緩存的數(shù)據(jù)包較少，系統(tǒng)會發(fā)起重傳，導(dǎo)致重傳較多；若緩沖區(qū)設(shè)置過大，又會增加在緩沖區(qū)中等待的延時。因此，根據(jù)網(wǎng)絡(luò)狀況動態(tài)調(diào)整緩沖區(qū)大小，在網(wǎng)絡(luò)條件好的時候，將緩沖區(qū)大小設(shè)置為較小緩沖區(qū)，此時發(fā)起丟包重傳，可在較短時間內(nèi)完成，從而降低延時；網(wǎng)絡(luò)條件較差的時候，將緩沖區(qū)大小設(shè)置為較大緩沖區(qū)，但此時網(wǎng)絡(luò)條件較差，較多的重傳會加重惡化網(wǎng)絡(luò)環(huán)境。緩沖區(qū)運行機制如圖4所示。

緩沖區(qū)首次接收到RTP數(shù)據(jù)包時，會將其放置在從空幀隊列彈出的空幀塊當(dāng)中。之后每次接收到一個RTP包，就會根據(jù)時間戳在已存在的幀中尋找，確定是否已經(jīng)接收過相同時間戳的包，再找到具有相同時間戳的RTP數(shù)據(jù)包，彈出此幀塊，否則將會從空幀再次彈出一個空幀。根據(jù)RTP包的序列號，找到應(yīng)該插入幀的位置，并更新幀狀態(tài)。其中幀狀態(tài)有空、殘缺、可解碼和完整4個狀態(tài)，空表示沒有數(shù)據(jù)的狀態(tài)；殘缺表示至少有一個包的狀態(tài)；可解碼表示當(dāng)前的幀處于可解碼狀態(tài)；完整表示這一幀所有數(shù)據(jù)都已經(jīng)到齊，可以進行其他操作。

圖4 buffer運行機制

3 測試系統(tǒng)搭建

在Linux環(huán)境下搭建WebRTC的房間服務(wù)器(room server)、信令服務(wù)器(signaling room)和穿越服務(wù)器(ICE Server)，構(gòu)建音視頻會話測試系統(tǒng)。

3.1 房間服務(wù)器

房間服務(wù)器用于創(chuàng)建和管理會話。在AppRTC房間服務(wù)器[15]的基礎(chǔ)上，通過獲取其源碼并配置constants.py文件，將IP地址改為本機IP地址，創(chuàng)建房間服務(wù)器。訪問房間服務(wù)器如圖5 所示。

圖5 房間服務(wù)器

3.2 信令服務(wù)器

信令服務(wù)器用于管理和協(xié)助通話終端建立點對點通話，主要有控制通信發(fā)起或者結(jié)束，及通信雙方建立安全連接等作用。通過信令服務(wù)器，通信雙方可以獲知對方的IP地址等相關(guān)信息，還可以就會話媒體類型、編解碼方式、傳輸協(xié)議和媒體格式等相關(guān)信息進行協(xié)商。信令服務(wù)器的搭建沿用了Collider服務(wù)器[15]。

3.3 穿越服務(wù)器

穿越服務(wù)器用于穿越防火墻或者帶有網(wǎng)絡(luò)地址轉(zhuǎn)換(network address translation，NAT)功能的路由器,讓兩個同處于私有網(wǎng)絡(luò)里的計算機能夠通信[15]。

穿越服務(wù)器的結(jié)構(gòu)如圖6所示。

圖6 穿越服務(wù)器示意圖

4 測試結(jié)果及分析

在音視頻會話測試系統(tǒng)里，將PC端與手機端分別接入網(wǎng)絡(luò)，并保證沒有其他設(shè)備連接同一網(wǎng)絡(luò)，開啟音視頻通話，與此同時打開WireShark抓包工具，獲取在網(wǎng)絡(luò)狀況較好時，音視頻通話過程中傳輸?shù)腞TP/RTCP包；再將手機端移至WiFi信號差的位置，重復(fù)上述過程，獲取網(wǎng)絡(luò)狀況較差時的RTP/RTCP包，對比兩種情況下丟包率的測試結(jié)果如圖7所示。

圖7 兩種情況下丟包率的對比結(jié)果

由圖7可以看出，在網(wǎng)絡(luò)狀況較差的情況下，丟包率仍能控制在7%以下，能夠保證音視頻的流暢傳輸。通過丟包重傳機制和動態(tài)調(diào)整抖動緩沖區(qū)大小能夠保證在無線環(huán)境下的音視頻傳輸質(zhì)量。

5 結(jié)語

采用RTP協(xié)議進行音視頻實時傳輸時，WebRTC音視頻傳輸?shù)膬?yōu)化方法通過開啟丟包重傳機制，動態(tài)調(diào)整抖動緩沖區(qū)大小，能夠保證音視頻的流暢傳輸。構(gòu)建音視頻會話測試系統(tǒng)，利用WireShark抓包，分析實時音視頻的丟包率。測試結(jié)果表明，該方法有效改善了無線環(huán)境下音視頻的傳輸質(zhì)量，在網(wǎng)絡(luò)狀況較差時，系統(tǒng)仍能保證音視頻通信的流暢性。