摘??要： 在研究RTP／RTCP協(xié)議特點與功能的基礎上，討論了基于RTP／RTCP協(xié)議實時視頻傳輸?shù)?a class="innerlink" href="http://ihrv.cn/tags/控制方法" title="控制方法" target="_blank">控制方法。通過此控制方法可以有效地提高RTP流的平穩(wěn)性，減小抖動，增加網(wǎng)絡帶寬的利用率，流暢地傳輸多媒體數(shù)據(jù)。利用GPS、RTP／RTCP等協(xié)議實現(xiàn)了手機報警系統(tǒng)。
關鍵詞： RTP／RTCP； Internet； H．263／H．264； G.729； GPS
?
隨著我國經(jīng)濟的迅速增長和精神生活的不斷豐富，人們越來越熱衷于參加一些具有挑戰(zhàn)性的活動，而遇到危險的幾率也大大增加,因此在困境中個人求助顯得格外重要。此外，因惡性案件嚴重地威脅到人身安全，所以要求相關部門加強整治社會治安力度、快捷有效地偵破案件。目前手機的應用越來越普及，作為一項手機功能的拓展，構建一套簡單快捷的手機報警系統(tǒng)很有必要，也易于推廣。
手機報警系統(tǒng)是利用現(xiàn)有手機加載GPS技術、網(wǎng)絡協(xié)議RTP/RTCP以及H．263/H．264、G.729視音頻編碼方式實現(xiàn)的一鍵快速報警系統(tǒng)。一鍵快速報警后，手機終端不斷地發(fā)送其位置信息和周圍環(huán)境的音頻、視頻信息，從而實現(xiàn)其快捷、隱蔽的報警，為公安及相關部門施救或破案實時地提供有效的現(xiàn)場信息。
1 GPS及GPS信息采集
GPS（Global Positioning System）全球定位系統(tǒng)[1]是中距離圓形軌道衛(wèi)星定位系統(tǒng)，可以為地球表面絕大部分地區(qū)提供準確的定位和高精度的時間基準。GPS信息包括經(jīng)度、緯度和采集時間等，即在定時器的控制下，手機不斷地采集GPS信息并發(fā)送相關數(shù)據(jù)。獲取GPS坐標數(shù)據(jù)模塊的函數(shù)接口如下[2]：
(1)InitDevice（）函數(shù)：用于初始化GPS設備驅(qū)動程序的函數(shù)接口。
(2)LoadThread（）函數(shù)：用于創(chuàng)建獲取GPS坐標數(shù)據(jù)的線程函數(shù)接口。
(3)GPSThreadProc(_opt LPVOID lpParameter) 函數(shù)：用于獲取GPS坐標數(shù)據(jù)的函數(shù)接口。
(4)BackUpGPSData(MYGPSDATESEND GpsDate) 函數(shù)：用于將獲取后的GPS坐標數(shù)據(jù)以二制形式存儲在終端本地的函數(shù)接口。
(5)UnloadThread（）函數(shù) ：用于停止GPS線程運行的函數(shù)接口。
(6)StopTime(int StopTime) 函數(shù)：用于停止GPS獲取的時間設置。
2 RTP／RTCP協(xié)議及其傳輸控制方法
2.1 RTP／RTCP協(xié)議[3]
RTP協(xié)議是用于音頻、視頻等多媒體數(shù)據(jù)實時傳輸?shù)膮f(xié)議，它包括RTP和RTCP兩個子協(xié)議。其中，RTP用于實時數(shù)據(jù)端到端傳輸，RTP包中提供了時間戳即發(fā)送數(shù)據(jù)塊首字節(jié)的創(chuàng)建時間和序列號，以達到數(shù)據(jù)的同步和重組；而RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失數(shù)據(jù)包的情況和數(shù)據(jù)包到達時延抖動等信息，可以監(jiān)視網(wǎng)絡的服務質(zhì)量、通信帶寬以及網(wǎng)上傳送的信息。發(fā)送端可以利用RTCP提供的信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，可共同提供流量控制和擁塞控制服務，能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合網(wǎng)上實時數(shù)據(jù)的傳送。RTP協(xié)議的數(shù)據(jù)包格式如圖 1所示。
?
?
??? 常用的RTCP包有五種：發(fā)送方報告包(SR)、接收者報告包(RR)、源描述包(SDES)、站點離開系統(tǒng)報告包(BYE)和特殊應用包(APP)。包的主要數(shù)據(jù)項格式如圖2所示。
?
??? RTP包通過下層UDP 來實現(xiàn)數(shù)據(jù)的傳輸，數(shù)據(jù)裝載模型如圖3所示。
?
2.2 實時傳輸控制方法
? 遠程網(wǎng)絡傳輸?shù)牟豢煽啃灾饕憩F(xiàn)在[4-5]三方面：(1)數(shù)據(jù)包“亂序到達”，先發(fā)送數(shù)據(jù)包有可能后到；(2)在Internet環(huán)境下，網(wǎng)絡傳輸帶寬變動會引起發(fā)送的數(shù)據(jù)包丟失；(3)數(shù)據(jù)包到達的時延過大而產(chǎn)生抖動會引起數(shù)據(jù)的失真。
? 而RTP/RTCP能很好地解決上述問題。首先，在接收端緩沖區(qū)中用RTP包中的序列號來調(diào)整到達數(shù)據(jù)包的順序，使之與發(fā)送時的數(shù)據(jù)順序一致；其次，為了改進遠程視頻傳輸系統(tǒng)的穩(wěn)定性，建立一個傳輸控制模型，這樣就可通過網(wǎng)絡狀況的反饋及時調(diào)整采樣頻率以及編碼格式以適應當前的網(wǎng)絡傳輸要求。RTCP利用主要的兩種控制包SR和RR反饋的信息如數(shù)據(jù)包丟失比、數(shù)據(jù)包丟失率、吞吐量和吞吐率、數(shù)據(jù)包到達時延抖動J（interarrival jitter）和往返傳播時延等來調(diào)節(jié)實時傳輸，并調(diào)整系統(tǒng)的打包格式、發(fā)包速率來保證流暢地傳輸數(shù)據(jù)和清晰地播放視頻。其數(shù)據(jù)傳輸控制模型如圖4所示。
?
3 手機報警系統(tǒng)的組成
??? 手機報警系統(tǒng)的結構框圖如圖5所示，由三大部分構成：(1)信息采集部分，包括智能報警終端(手機)、移動無線傳輸網(wǎng)絡和接入服務器；(2)中央處理部分(服務器端)，它是系統(tǒng)的核心，包括各個服務器單元、報警系統(tǒng)的接口等；(3)終端即110指揮中心處接入坐席(監(jiān)控端)。各部分功能如下。
?
??? 報警終端：
(1) 使用WinCE鍵盤鉤子模擬一鍵報警(長按綠鍵)。
(2) 按鍵報警后，鍵盤不做任何響應直至服務器發(fā)出結束指令。
(3) 按鍵報警后，手機獲取EEII號、啟動GPRS進行設備認證。
(4) 認證通過，開始傳遞報警數(shù)據(jù)直至服務器發(fā)出結束指令。
(5) 定時傳遞GPS坐標信息。
(6) 手機本地保留報警數(shù)據(jù)直至無存儲空間為止。
服務器：
?、?服務器接到報警請求后，根據(jù)EEII號進行身份驗證；
② 將報警索引信息寫入數(shù)據(jù)庫，實時數(shù)據(jù)寫入文件；
?、?通知監(jiān)控端更新監(jiān)控對象列表；
?、?根據(jù)需要，實時轉(zhuǎn)發(fā)報警數(shù)據(jù)到監(jiān)控端；
?、?支持多個手機終端，維護在線報警手機列表；
?、?支持多個監(jiān)控端，維護在線監(jiān)控端列表。
監(jiān)控端：
(1) 可以定時刷新報警列表。
(2) 選擇報警對象進行跟蹤。
(3) 動態(tài)顯示報警信息。
(4) 發(fā)出“結束報警”指令。
4 手機報警系統(tǒng)的設計
手機報警系統(tǒng)的流程是：首先手機端發(fā)送注冊信號給服務器端進行連接，注冊成功后開始音頻采集、視頻采集和GPS采集，同時進行音視頻的壓縮編碼， RTP分包封裝，并且形成RTCP發(fā)送端報告，發(fā)送給服務器端。服務器根據(jù)報警信息進行相關的處理：存儲數(shù)據(jù)、與監(jiān)控端進行連接和發(fā)送報警信息。報警系統(tǒng)的邏輯框圖如圖6所示。
?
5 手機報警系統(tǒng)的實現(xiàn)
系統(tǒng)的實現(xiàn)是在Visual C++6．0環(huán)境下[6-8]，采用H．263/H．264視頻編碼[9-10]和G726音頻壓縮編碼[11]。傳輸控制子系統(tǒng)是基于RTP/RTCP協(xié)議構建，通過傳輸層的UDP? Socket完成實時傳輸。手機端負責按鍵報警，它包括如下幾個模塊：啟動GPRS網(wǎng)絡模塊、采集音頻數(shù)據(jù)模塊、獲取GPS坐標數(shù)據(jù)模塊、數(shù)據(jù)打包發(fā)送模塊。服務器端主要分為如下模塊：網(wǎng)絡管理模塊、協(xié)議分發(fā)模塊、代理模塊、管理模塊、登錄管理模塊、終端管理模塊、監(jiān)控端管理模塊、文件管理模塊、數(shù)據(jù)庫管理模塊、日志管理模塊及UI等模塊。
監(jiān)控端再現(xiàn)報警人的音視頻和GPS信息，其詳細實現(xiàn)如下：
(1) 監(jiān)控端注冊，即監(jiān)控端軟件啟動后，啟動網(wǎng)絡監(jiān)聽，然后自動向服務器進行注冊（注冊內(nèi)容包括IP地址和端口號）。如果超過15s服務器沒有響應，軟件給出錯誤警告，然后退出系統(tǒng)。
(2) 心跳信號，即監(jiān)控端軟件每15s發(fā)送心跳信號數(shù)據(jù)包給服務器，服務器據(jù)此來維護監(jiān)控端列表。
(3) 刷新報警列表，即軟件維持一個當前報警對象的列表。報警列表的更新方式有兩種：
?、佘浖硬⒆院?，服務器即返回當前報警列表。
②當服務器端報警列表更新的時候，向監(jiān)控端發(fā)送變更消息。
(4) 選擇報警對象進行跟蹤，即發(fā)送“跟蹤”指令給服務器，如果成功回應，接收音視頻數(shù)據(jù)，開始播放音視頻數(shù)據(jù)；如果25s沒有應答，則退出請求跟蹤。處理過程如圖7所示。
?
RTP協(xié)議中用于監(jiān)控端與服務器軟件的接口函數(shù)如下：
(1)RTPProtocolInit（）函數(shù)：用于初始化RTP，判斷連接服務器是否成功的函數(shù)接口。
(2)onCrlDataArrive(const RTPAddress frm,const CrlType crltype, unsigned char *data, const int length, const char *id)函數(shù)：用于實時接收服務器返回的信息數(shù)據(jù)函數(shù)接口。
(3)SendData(CrlType crltype,unsigned char * Data,int Length) 函數(shù)：利用RTP協(xié)議定時發(fā)送心跳信息及向服務器注冊的信息函數(shù)接口。
RTP/RTCP協(xié)議選取數(shù)據(jù)包丟失比、數(shù)據(jù)包丟失率、吞吐量和吞吐率、數(shù)據(jù)包到達時延抖動和往返傳播時延等服務質(zhì)量控制參數(shù)，作為動態(tài)反饋來自動判斷網(wǎng)絡狀況，并根據(jù)網(wǎng)絡狀況自動調(diào)節(jié)編碼方式，因而這種協(xié)議非常適合多媒體數(shù)據(jù)實時傳輸?；赗TP/RTCP設計并成功實現(xiàn)了手機報警系統(tǒng)，經(jīng)過仿真實驗，視頻、音頻等數(shù)據(jù)傳輸都很流暢，該系統(tǒng)正在測試和推廣使用中。手機用戶的大幅增加和手機費用的逐步降低，為該技術的推廣提供了便利條件。
參考文獻
[1] ?LOVSE J W,? TESKEY W F, LACHAPELLE G, et al.Dynamic ?deformation monitoring of tall structures using?GPS technology[J]. Journal of Surveying Engineering.1995,121(1):35-40.
[2] ?周建鄭.GPS測量定位技術[M].北京：化學工業(yè)出版社,2004.
[3] ?SCHULZRINNE H, CASNER S, FREDEIRCK R, et a1．RTP： a transport? protocol for real—time applications[S]．RFC 1889，1996.
[4] ?BUSSE I， DEFFNER B， SCHULZRINNE H． Dynamic?QoS control of multimedia applications based on RTP? [J]．Computer Communication，1996，19(1)：49-58．
[5] ?ZHANG Ke， XIE? Zhong Cheng， JU Jiu Bin． Real-time?repairing lost packets based on real—time transport protocol[J]． Journal of Software，2001，7(12)：1042-1049．
[6] ?黃維通. Visual C++面向?qū)ο笈c可視化程序設計[M]．北京：清華大學出版社，2003：84-147．
[7] ?歐建平，婁強生．網(wǎng)絡與多媒體通信技術[M]．北京：人民郵電出版社，2002．
[8] ?蔣東興. Windows Sockets 網(wǎng)絡程序設計大全[M].北京：清華大學出版社，1999:117-162.
[9] ?IETF? RFC2190. RTP payload format for H．263 video?streams[S]．1997．
[10] WEN Ger. H.264／AV Cover IP? [J]． IEEET Rans Circuits－Syst Video Technology，2003，13: 645-656．
[11] CHOU P A, MORH A E, WANG A, et a1． Error control ?for receiver—driven layered multicast of audio and video?[J]． IEEE Transactions on? Multimedia，2001；3(1)：l08-122.