傅曉茜，何加銘

（寧波大學(xué)信息科學(xué)與工程學(xué)院，浙江 寧波 315211）

1 引言

近年來，隨著移動通信和多媒體技術(shù)的迅速發(fā)展，計算機(jī)、網(wǎng)絡(luò)以及圖像處理、傳輸技術(shù)也得到了飛速發(fā)展，視頻監(jiān)控技術(shù)受到越來越廣泛的應(yīng)用。視頻監(jiān)控系統(tǒng)對安全性的要求比較高，服務(wù)器平臺構(gòu)架要簡單方便，無論是在PC（Personal Computer，個人電腦）機(jī)上還是移動設(shè)備上都可以對監(jiān)控內(nèi)容進(jìn)行實(shí)時查看。流媒體技術(shù)[1-2]是視頻監(jiān)控系統(tǒng)的關(guān)鍵，目前主流的流媒體傳輸協(xié)議主要是實(shí)時傳輸協(xié)議RTP/RTCP以及實(shí)時流協(xié)議RTSP[3]。如果流媒體服務(wù)器和終端之間用普通的實(shí)現(xiàn)RTSP方法進(jìn)行連接，那么在網(wǎng)絡(luò)暢通的終端上都能實(shí)現(xiàn)對該服務(wù)器的訪問，就能查看視頻監(jiān)控的具體內(nèi)容。傳統(tǒng)的方法無法對訪問者進(jìn)行權(quán)限的控制，特別是用在安全性較高的系統(tǒng)中，安全性較低。

為了提高視頻監(jiān)控系統(tǒng)的安全性，本文提出一種心跳機(jī)制的實(shí)現(xiàn)方法，使得現(xiàn)有普通的實(shí)現(xiàn)RTSP的終端不能正確訪問到實(shí)現(xiàn)了本方法的流媒體服務(wù)器，從而增加了系統(tǒng)的安全性和可靠性。除此之外，實(shí)現(xiàn)本方法還具有流保活功能，若終端的網(wǎng)絡(luò)環(huán)境異常甚至出現(xiàn)斷網(wǎng)的情況，則流媒體服務(wù)器會及時發(fā)現(xiàn)并停止對其服務(wù)，避免浪費(fèi)服務(wù)器資源。

2 流媒體傳輸協(xié)議簡介

2.1 實(shí)時流媒體協(xié)議RTSP

RTSP協(xié)議能夠配合低層協(xié)議共同給用戶提供一套較為完整的基于Internet的流式傳輸服務(wù)，為流媒體服務(wù)器和終端間實(shí)現(xiàn)音視頻流數(shù)據(jù)的控制搭建了橋梁。RTSP協(xié)議規(guī)定了一套可以根據(jù)需求而進(jìn)行擴(kuò)展的框架，終端播放時可以控制音頻和視頻，如控制在線視頻的暫停、定位、快進(jìn)等，支持單播和組播服務(wù)，提供了選擇發(fā)送通道的方法以及基于RTP的發(fā)送機(jī)制。

2.2 實(shí)時傳輸協(xié)議RTP/RTCP

視頻流是視頻通信的核心，是一系列連續(xù)的并且?guī)в袝r間戳的視頻包數(shù)據(jù)。由于視頻流有實(shí)時傳輸?shù)奶匦?，對帶寬和延遲較敏感，因此需要合適的傳輸協(xié)議。

一般情況下，實(shí)時視頻傳輸系統(tǒng)利用U D P（User Datagram Protocol，用戶數(shù)據(jù)報協(xié)議）來實(shí)現(xiàn)數(shù)據(jù)的傳送，但是UDP是“貪婪”的，不像TCP（Transmission Control Protocol，傳輸控制協(xié)議）有沖突檢測和擁塞控制機(jī)制，一旦網(wǎng)絡(luò)發(fā)生擁塞，UDP不會減少數(shù)據(jù)包的發(fā)送量，從而導(dǎo)致傳輸?shù)耐Ｖ购妥枞?。TCP雖然有AIMD（Additive Increase Multiplicative Decrease，擁塞控制算法），即每發(fā)現(xiàn)一個報文丟失就減半窗口，但這種做法極大地破壞了數(shù)據(jù)流的平滑性，從而影響接收質(zhì)量。

RTP傳輸協(xié)議[4]包含兩部分內(nèi)容：RTP數(shù)據(jù)傳輸協(xié)議和RTCP傳輸控制協(xié)議。RTP可以靈活改變傳輸速率，以防亂序；而RTCP報文可以把網(wǎng)絡(luò)狀況和服務(wù)質(zhì)量反饋給RTP數(shù)據(jù)，即RTP/RTCP能夠?qū)崿F(xiàn)視頻自適應(yīng)傳輸。

3 心跳機(jī)制的設(shè)計與實(shí)現(xiàn)

3.1 流媒體服務(wù)器與終端間的連接過程

本文中提到的方法擴(kuò)展了原有的RTSP協(xié)議的連接建立過程，在流媒體服務(wù)器響應(yīng)了終端的PLAY請求后，定時器開始計時。終端接收到服務(wù)器的PLAY響應(yīng)后就以設(shè)定的時間間隔向服務(wù)器發(fā)送心跳包，服務(wù)器收到此心跳包后重設(shè)定時器，并分析出心跳包中終端對應(yīng)的公網(wǎng)IP地址信息和端口號。服務(wù)器根據(jù)獲取的IP地址和端口號向終端發(fā)送視頻流數(shù)據(jù)，終端播放器在會話過程中仍以一定的時間間隔發(fā)送心跳包。若服務(wù)器在定時器超過一定數(shù)值后還沒有接收到心跳包，則關(guān)閉會話。具體流程如圖1所示：

圖1 流媒體服務(wù)器與終端通信流程圖

（1）終端與流媒體服務(wù)器經(jīng)過OPTIONS、DESCRIBE、SETUP、PLAY等交互后建立連接。

（2）終端視頻端口（client_port），端口號分別是59532、59533，其中59532端口用于接收視頻流數(shù)據(jù)，59533端口用于終端和服務(wù)器間RTCP消息交互。

（3）流媒體服務(wù)器用于接收接收心跳包的端口（server_port）分別為6970、6971，其中6970用于接收終端發(fā)送的RTP心跳包，6971用于接收終端RTCP心跳包。

（4）流媒體服務(wù)器響應(yīng)完終端PLAY請求之后，并沒有馬上向終端發(fā)送視頻流數(shù)據(jù)，而是先設(shè)定一個定時器，等待終端向其發(fā)送心跳包。若在定時器規(guī)定的時間內(nèi)收到心跳包，服務(wù)器才向終端發(fā)送視頻數(shù)據(jù)；若等待時間超出了定時器設(shè)定時間，服務(wù)器則關(guān)閉與終端的連接。

（5）流媒體服務(wù)器收到終端發(fā)送的心跳包后，重新設(shè)定定時器并分析心跳包，從中獲取終端對應(yīng)的公網(wǎng)IP地址和端口號，或者終端的NAT（Network Address Translation，網(wǎng)絡(luò)地址轉(zhuǎn)換）設(shè)備的公網(wǎng)IP（Internet Protocol，網(wǎng)協(xié)）地址以及NAT設(shè)備端口號。服務(wù)器就能根據(jù)得到的IP地址和端口號向終端播放器發(fā)送視頻流數(shù)據(jù)，同時進(jìn)行RTCP消息交互。

（6）流媒體服務(wù)器向終端發(fā)送視頻流數(shù)據(jù)后，終端仍然以設(shè)定的時間間隔向服務(wù)器發(fā)送心跳包，如果服務(wù)器在設(shè)定的時間間隔內(nèi)未收到心跳包，則判定終端處于離線狀態(tài)，隨即關(guān)閉連接。

3.2 心跳包的設(shè)計

本文中心跳包結(jié)構(gòu)擴(kuò)展了RTP協(xié)議數(shù)據(jù)包字段[5-6]，在RTP數(shù)據(jù)包的報文頭擴(kuò)展字段中填入流媒體服務(wù)器所需的驗(yàn)證信息，再由UDP發(fā)送。心跳包的構(gòu)成如圖2所示：

圖2 心跳包結(jié)構(gòu)圖

各個字段描述如下：

V：標(biāo)識RTP版本，占2位；

P：填充標(biāo)識，占1位；

X：擴(kuò)展標(biāo)識，占1位；

CC：CSRC計數(shù)器，占4位；

M：標(biāo)記，占1位；

PT：載荷類型，占7位；

sequence number：系列號，占16位，用于標(biāo)識發(fā)送端發(fā)送RTP報文的序列號，每發(fā)送1個，序列號就加1，接收端則通過序列號對數(shù)據(jù)包進(jìn)行排序，檢測數(shù)據(jù)包丟失情況；

timestamp：時標(biāo)，占32位，反映RTP數(shù)據(jù)包中第1個八進(jìn)制采樣時刻，用于接收端延遲和延遲抖動，并且進(jìn)行同步控制；

SSRC：同步源標(biāo)識符，占32位，用于同一RTP包連接中沒有兩個同步源有相同的SSRC標(biāo)識；

CSRC列表：貢獻(xiàn)源標(biāo)識符，占32位，表示包內(nèi)的對載荷起作用的源；

identifier：標(biāo)識，占32位；

IPCID：網(wǎng)絡(luò)攝像頭ID號，占16位；

length：心跳包的有效字段字節(jié)數(shù)；

packettype：值為0表示初始化包，值為1表示維持包；

reserved：保留字段，占16位。

流媒體服務(wù)器向終端響應(yīng)PLAY請求后，并非立刻向終端播放器發(fā)送視頻流數(shù)據(jù)，而是先處于等待狀態(tài)，當(dāng)含有初始化標(biāo)志的心跳包到達(dá)時，經(jīng)過分析、驗(yàn)證正確后，服務(wù)器才向終端發(fā)送視頻流數(shù)據(jù)。終端收到流媒體服務(wù)器發(fā)送的視頻流數(shù)據(jù)后，設(shè)置心跳包的packettype字段為“維持”，直到連接結(jié)束，此時心跳包的作用為在線?；睢?/p>

流媒體服務(wù)器分析心跳包的過程如圖3所示。

流媒體服務(wù)器收到終端發(fā)送的心跳包后，先判斷其identifier字段是否正確，如果正確則說明收到正確的心跳包，再檢測packettype字段，若packettype為“初始化包”，則服務(wù)器從承載心跳包的UDP數(shù)據(jù)包頭獲得源IP地址及其端口號，根據(jù)獲取的IP地址及端口號發(fā)送視頻流數(shù)據(jù)，若規(guī)定時間內(nèi)未收到“初始化包”，則關(guān)閉連接。如果packettype字段標(biāo)識為“維持包”，那么服務(wù)器更新定時器，在規(guī)定時間內(nèi)未收到“維持包”服務(wù)器則判定終端播放器已處于離線狀態(tài)，關(guān)閉連接。

圖3 心跳包分析過程圖

4 結(jié)束語

本文描述了流媒體服務(wù)器和終端之間通信連接建立的過程，提出了一種心跳機(jī)制的實(shí)現(xiàn)方法，該方法對傳統(tǒng)的RTP數(shù)據(jù)包頭部進(jìn)行擴(kuò)展，利用增加的字段識別來自終端的信息，使得普通的實(shí)現(xiàn)RTSP的終端不能訪問流媒體服務(wù)器，從而更好地保障了視頻監(jiān)控系統(tǒng)的安全性。無論終端的網(wǎng)絡(luò)環(huán)境是處于公網(wǎng)，還是含有NAT設(shè)備的內(nèi)網(wǎng)環(huán)境，實(shí)現(xiàn)了本方法后就可以查看監(jiān)控內(nèi)容，為解決一些網(wǎng)絡(luò)問題提供參考。

[1]孫冬柏. 流媒體技術(shù)及其應(yīng)用[J]. 信息技術(shù), 2005(11):131-134.

[2]宋剛,楊顯富. 實(shí)時流媒體傳輸及其協(xié)議[J]. 成都大學(xué)學(xué)報: 自然科學(xué)版, 2005,24(1): 28-31.

[3]章民融,徐亞鋒. 基于RTSP的流媒體視頻服務(wù)器的設(shè)計與實(shí)現(xiàn)[J]. 計算機(jī)應(yīng)用與軟件, 2006,23(7): 93-95.

[4]潘鵬,杜旭,葉婷,等. RTP/RTCP實(shí)時傳輸協(xié)議的研究與Linux實(shí)現(xiàn)[J]. 計算機(jī)工程與應(yīng)用, 2005(24): 105-107.

[5]RTP包頭分析[EB/OL]. (2010-11-18). http://wenku.baidu.com/view/df7856d126fff705cc170a5f.html.

[6]黃金雪. Socket高效網(wǎng)絡(luò)服務(wù)端研究[J]. 現(xiàn)代計算機(jī),2011(10): 22-25.

[7]Stephan Wenger. H.264/AVC over IP[J]. IEEE Transactions on Circu its and System for Video Techno-logy,2003,7(13): 64-65.

[8]劉焱,鐘國輝,劉玉. 基于RTSP協(xié)議的流媒體雙向認(rèn)證模型的研究[J]. 計算機(jī)應(yīng)用與軟件, 2009,26(8): 83-85.

[9]Li Huaming, Tan Jindong. Heartbeat-Driven Medium-Access Control for Body Sensor Networks[J]. IEEE Transactions on Information Technology in Biomedicine,2010,14(1): 44-51.

[10]鐘玉琢,向哲,沈洪. 流媒體和視頻服務(wù)器[M]. 北京: 清華大學(xué)出版社, 2003.

[11]王小燕. 一種高效點(diǎn)播流媒體服務(wù)器的設(shè)計與實(shí)現(xiàn)[J].計算機(jī)工程與科學(xué), 2010(2): 118-120.