一種適用于自組網(wǎng)的流媒體協(xié)議設(shè)計(jì)

畢海霞

(西安電子工程研究所 西安 710100)

0 引言

當(dāng)前戰(zhàn)爭中，多軍兵種協(xié)同的需求越來越迫切，協(xié)同作戰(zhàn)所需的傳輸信息量急劇上升，傳輸業(yè)務(wù)種類也越來越多。自組網(wǎng)因其無中心、自組織、多跳路由和動(dòng)態(tài)拓?fù)涞奶卣?，網(wǎng)絡(luò)快速部署、抗毀性強(qiáng)和組網(wǎng)靈活等優(yōu)點(diǎn)，成為了近年來軍事信息化應(yīng)用中的研究熱點(diǎn)。自組網(wǎng)的網(wǎng)絡(luò)協(xié)議分為物理層，數(shù)據(jù)鏈路層，網(wǎng)絡(luò)層，傳輸層和應(yīng)用層四部分。應(yīng)用層的設(shè)計(jì)高效與否會(huì)影響整個(gè)自組網(wǎng)系統(tǒng)的性能，本文就此開展研究，提出了一種適用于自組網(wǎng)的流媒體應(yīng)用層設(shè)計(jì)。

自組網(wǎng)應(yīng)用層是一套基于PC 或嵌入式平臺(tái)的軟件系統(tǒng)，主要實(shí)現(xiàn)通信業(yè)務(wù)、運(yùn)維管理類兩部分功能。通信業(yè)務(wù)實(shí)現(xiàn)網(wǎng)絡(luò)通信功能，主要包括語音、視頻、撥號(hào)通話、短消息、01 數(shù)據(jù)、02 指令通信功能;此外，運(yùn)維管理類用戶信息管理可以從點(diǎn)名業(yè)務(wù)中獲取應(yīng)用層用戶信息，包括用戶狀態(tài)、漫游狀態(tài)等信息等。

網(wǎng)絡(luò)管理包括拓?fù)滹@示、用戶信息管理、網(wǎng)絡(luò)參數(shù)配置和自組網(wǎng)設(shè)備狀態(tài)管理四部分功能，其中拓?fù)滹@示實(shí)現(xiàn)點(diǎn)到點(diǎn)鏈路查詢、業(yè)務(wù)拓?fù)洳樵兒蛯?shí)時(shí)拓?fù)洳樵?，分別反映網(wǎng)絡(luò)本地節(jié)點(diǎn)和任意另外一個(gè)節(jié)點(diǎn)間的鏈路連接信息，網(wǎng)絡(luò)傳輸業(yè)務(wù)的連接信息和即時(shí)的網(wǎng)絡(luò)拓?fù)溥B接信息;用戶信息管理通過點(diǎn)名及自組網(wǎng)設(shè)備狀態(tài)管理功能獲取自組網(wǎng)用戶信息，生成用戶信息數(shù)據(jù)庫，一方面為通信業(yè)務(wù)類功能提供通信時(shí)所需的通信錄，另一方面為運(yùn)維管理類功能提供網(wǎng)絡(luò)維護(hù)時(shí)所需的用戶信息;網(wǎng)絡(luò)參數(shù)配置主要對自組網(wǎng)設(shè)備的IP 地址、網(wǎng)關(guān)地址、頻段及頻點(diǎn)等信息進(jìn)行配置。

ANI(Application Network Interface)接口及隊(duì)列調(diào)度，對通信業(yè)務(wù)、網(wǎng)絡(luò)管理及運(yùn)維支撐三部分功能產(chǎn)生及收到的數(shù)據(jù)包進(jìn)行封包或解包，并根據(jù)業(yè)務(wù)的優(yōu)先級(jí)進(jìn)行發(fā)送和接收隊(duì)列的調(diào)度。

1 系統(tǒng)總體架構(gòu)

自組網(wǎng)應(yīng)用層通信示意圖如下所示。對音視頻業(yè)務(wù)，應(yīng)用層采集攝像頭和話筒數(shù)據(jù)后，進(jìn)行音視頻編碼，然后在網(wǎng)絡(luò)協(xié)議控制下，進(jìn)入通信網(wǎng)絡(luò)進(jìn)行傳輸，對端收到音視頻數(shù)據(jù)，進(jìn)行解碼及恢復(fù)工作;對數(shù)據(jù)類通信業(yè)務(wù)，應(yīng)用層接收到數(shù)據(jù)后，在網(wǎng)絡(luò)協(xié)議處理后，進(jìn)入通信網(wǎng)絡(luò)傳輸至對端;對網(wǎng)絡(luò)管理類及運(yùn)維支撐類數(shù)據(jù)，應(yīng)用層進(jìn)行解析后，與底層協(xié)議進(jìn)行交互，或進(jìn)入通信網(wǎng)路。

通過對應(yīng)用層軟件功能進(jìn)行分析，可將其分解為以下子功能:

(1)實(shí)現(xiàn)VOIP 語音及視頻，包括語音及視頻的采集、編碼及封包和解包。

(2)實(shí)現(xiàn)對通信業(yè)務(wù)的差異化處理(封裝ANI頭，不同的優(yōu)先級(jí)及QoS 處理策略)，并實(shí)現(xiàn)網(wǎng)絡(luò)管理及運(yùn)維支撐類業(yè)務(wù)的功能。

(3)實(shí)現(xiàn)一個(gè)可移植、穩(wěn)健的平臺(tái)，功能包括操作系統(tǒng)適配，socket 抽象，消息包管理，進(jìn)程監(jiān)控，定時(shí)器管理及日志等。

(4)實(shí)現(xiàn)UI用戶界面，便于用戶操作。

綜上分析，應(yīng)用層邏輯架構(gòu)如下圖所示。

圖1 應(yīng)用層邏輯架構(gòu)

2 信令面協(xié)議設(shè)計(jì)

2.1 VoIP 協(xié)議分析

VoIP(Voice Over Internet Protocol)是建立在Internet 基礎(chǔ)上的新型數(shù)字化傳輸技術(shù)，是在IP(Internet Protocol)網(wǎng)上進(jìn)行實(shí)時(shí)音視頻，數(shù)據(jù)和文件等業(yè)務(wù)傳輸?shù)募夹g(shù)［1］。

H.323［2］和SIP［3］是VoIP 協(xié)議中最主要的兩種信令面協(xié)議，分別由ITU-T 和IETF 制定。兩者均利用RTP/RTCP(Real-Time Protocol/Real-Time Control Protocol)作為多媒體通信的應(yīng)用層控制協(xié)議，因此，兩者所提供的信令功能類似;但由于制定機(jī)構(gòu)不同，兩者在設(shè)計(jì)風(fēng)格上差別巨大。

下表從幾個(gè)方面對兩種協(xié)議進(jìn)行比較與分析:

表1 H.323 和SIP 協(xié)議比較

續(xù)表

綜上分析，H.323 基于傳統(tǒng)的電話信令架構(gòu)而設(shè)計(jì)，協(xié)議發(fā)展較成熟，但由于架構(gòu)龐雜，難以理解和實(shí)現(xiàn)。并且，H.323 的版本更新必須遵循向前兼容的原則，這意味著，隨著應(yīng)用的不斷更新，即使某些舊特性不再具有應(yīng)用價(jià)值也不會(huì)被淘汰掉，而同時(shí)新特性不斷累加，這無疑將導(dǎo)致協(xié)議越來越來龐雜。而SIP 協(xié)議在設(shè)計(jì)時(shí)遵循了簡單、開放、兼容和可擴(kuò)展等原則。隨著應(yīng)用的發(fā)展，被淘汰的舊的首部和取值將逐漸消失，保證了協(xié)議的簡潔。同時(shí)，SIP 協(xié)議在消息格式上編碼更方便，使得SIP 協(xié)議在擴(kuò)展方面能夠產(chǎn)生更有效率的應(yīng)用。因此，本設(shè)計(jì)中選用SIP 協(xié)議作為VoIP 信令面協(xié)議。

2.2 傳統(tǒng)的SIP 系統(tǒng)及呼叫流程

一個(gè)SIP 系統(tǒng)主要由網(wǎng)絡(luò)服務(wù)器和用戶代理(User Agent)組成。UA(User Agent)也稱作SIP 終端，而網(wǎng)絡(luò)服務(wù)器包括代理服務(wù)器、注冊服務(wù)器和重定向服務(wù)器等。SIP 會(huì)話主要由這四個(gè)應(yīng)用實(shí)體來完成［6］。

●用戶代理

UA 為終端用戶的通信提供多功能的界面。目前的SIP UA 通?？芍С终Z音，即時(shí)消息和視頻等多種業(yè)務(wù)。其主要功能包括會(huì)話發(fā)起，會(huì)話保持，會(huì)話轉(zhuǎn)接等6］。

●代理服務(wù)器

代理服務(wù)器的主要功能是路由并轉(zhuǎn)發(fā)用戶的呼叫請求。當(dāng)某用戶發(fā)起會(huì)話時(shí)，其UA 會(huì)生成一個(gè)SIP 請求消息并發(fā)送至對應(yīng)的代理服務(wù)器，然后，代理服務(wù)器將請求消息轉(zhuǎn)發(fā)至對端的UA，從而搭建起用戶間交互的橋梁［6］。

●重定向服務(wù)器

重定向服務(wù)器的功能不同于代理服務(wù)器。當(dāng)收到用戶請求時(shí)，重定向服務(wù)器并不轉(zhuǎn)發(fā)，而是執(zhí)行查找操作，獲得被請求用戶的地址信息，并將其回復(fù)給請求用戶。請求用戶接收到地址信息后，將直接向被請求用戶發(fā)送會(huì)話請求［6］。

●注冊服務(wù)器

注冊服務(wù)器的主要功能是處理用戶的注冊請求，從而完成用戶地址的更新。當(dāng)用戶登錄時(shí)，UA會(huì)向注冊服務(wù)器發(fā)送注冊消息，并將自己的IP 地址告訴注冊服務(wù)器，注冊服務(wù)器將用戶的IP 地址與用戶綁定，以方便其他用戶對其進(jìn)行查找［6］。

傳統(tǒng)的SIP 呼叫流程如下圖所示。

圖2 SIP 會(huì)話的建立過程

2.3 適用于自組網(wǎng)系統(tǒng)的SIP 協(xié)議

傳統(tǒng)的SIP 協(xié)議采用了C/S 架構(gòu)。由于SIP 協(xié)議用戶數(shù)目過于龐大，必須由專門的服務(wù)器完成用戶注冊(用戶自身信息，包括ID 與地址之間的映射關(guān)系等注冊于服務(wù)器上)，以及用戶的鑒權(quán)，重定向等工作。再通過邀請(INVITE)流程發(fā)起會(huì)話建立，協(xié)商雙方的用戶面(語音)編碼方式、傳輸?shù)刂?端口等信息，為后續(xù)傳輸用戶面語音幀的RTP/RTCP協(xié)議協(xié)商和分配資源，除此之外，INVITE 流程還包括一系列后續(xù)雙方的行為交互，包括振鈴、轉(zhuǎn)接、接聽/拒絕等等。

而自組網(wǎng)應(yīng)用層的需求具有以下幾個(gè)特點(diǎn):，

●節(jié)點(diǎn)數(shù)目少

自組網(wǎng)節(jié)點(diǎn)數(shù)目一般為幾十個(gè)。

●SIP 終端IP 地址固定

由于應(yīng)用場景的特殊性，每個(gè)SIP 終端在使用前必須配置好IP 地址。即使IP 地址發(fā)生變更，也會(huì)通過網(wǎng)絡(luò)傳輸告知其他相關(guān)SIP 終端。且，每個(gè)SIP 終端上均保存了其他SIP 終端的IP 地址。

●自組網(wǎng)中節(jié)點(diǎn)地位平等

出于抗毀性的考慮，自組網(wǎng)各節(jié)點(diǎn)地位平等，任何一個(gè)節(jié)點(diǎn)損毀都不會(huì)影響其他節(jié)點(diǎn)的通信。如果設(shè)置其中某些節(jié)點(diǎn)作為SIP 網(wǎng)絡(luò)中的服務(wù)器，那如果該節(jié)點(diǎn)被毀，則網(wǎng)絡(luò)將癱瘓。

綜上分析，自組網(wǎng)應(yīng)用場景下，SIP 協(xié)議中的服務(wù)器是不可以也無需存在的。針對該需求，剔除服務(wù)器的功能，將SIP 會(huì)話流程修改如下:

圖3 適用于自組網(wǎng)的SIP 會(huì)話流程

(1)用戶A 向用戶B 通過“INVITE”消息發(fā)起會(huì)話請求，會(huì)話請求消息體中帶有用戶A 的媒體屬性描述;

(2)用戶B 振鈴，向用戶A 返回響應(yīng)消息“180 RINGING”，用戶A 播放回鈴音;

(3)用戶B 摘機(jī)，并向用戶A 返回對“INVITE”請求的響應(yīng)消息“200 OK”，響應(yīng)消息的消息體中帶有用戶B 的媒體屬性描述;

(4)用戶A 發(fā)送針對響應(yīng)消息“200 OK”的ACK 確認(rèn)請求消息。此時(shí)，用戶A 與B 會(huì)話建立，開始進(jìn)行多媒體會(huì)話;

(5)用戶B 掛機(jī)，用戶B 向用戶A 發(fā)送Bye 請求消息;

(6)用戶A 返回對Bye 請求消息的“200 OK”響應(yīng)消息，通話結(jié)束。

3 用戶面協(xié)議設(shè)計(jì)

3.1 RTP/RTCP 協(xié)議分析

在流媒體研究中，對音視頻文件的實(shí)時(shí)傳輸要求較低的時(shí)延和較小的丟包率?；谶B接的TCP協(xié)議是一種可靠的傳輸層協(xié)議，但為保證可靠傳輸而設(shè)計(jì)的三次握手機(jī)制，擁塞控制技術(shù)和重發(fā)機(jī)制導(dǎo)致開銷增大，時(shí)延增加，無法很好地支持穩(wěn)定速率的流媒體數(shù)據(jù)的平滑傳輸;而無連接的傳輸層協(xié)議UDP 沒有任何QoS 保證，無法保證數(shù)據(jù)的可靠傳送。為解決上述矛盾，實(shí)現(xiàn)流媒體數(shù)據(jù)在IP 上的實(shí)時(shí)可靠傳輸，需要在傳輸層和應(yīng)用層協(xié)議之間增加一個(gè)通信控制層，即RTP/RTCP［7］協(xié)議。RTP 可提供編碼數(shù)據(jù)的實(shí)時(shí)傳輸，RTCP 則向會(huì)話中的所有成員周期性地發(fā)送控制信息反饋數(shù)據(jù)傳送情況，以便對發(fā)送速率，服務(wù)質(zhì)量和擁塞進(jìn)行控制。其端到端傳輸流程描述如下:

音視頻信息經(jīng)編碼器處理后形成多媒體數(shù)據(jù)流，RTP 協(xié)議對多媒體數(shù)據(jù)進(jìn)行封裝后交由網(wǎng)絡(luò)傳輸。對端網(wǎng)絡(luò)傳輸模塊接收到多媒體數(shù)據(jù)后交由RTP 協(xié)議進(jìn)行解封處理，然后音視頻解碼模塊對數(shù)據(jù)進(jìn)行解碼，恢復(fù)原有音視頻信號(hào)。在對多媒體數(shù)據(jù)進(jìn)行封裝和解封時(shí)，RTP 協(xié)議會(huì)根據(jù)數(shù)據(jù)包中所攜帶的載荷類型、時(shí)間戳、幀邊界等包頭信息對音視頻信號(hào)進(jìn)行同步控制。

在多媒體數(shù)據(jù)傳輸過程中，RTP/RTCP 協(xié)議多運(yùn)行于UDP 協(xié)議之上。這是因?yàn)镽TCP 協(xié)議能實(shí)時(shí)進(jìn)行質(zhì)量和擁塞控制，無需下層的傳輸層協(xié)議進(jìn)行QoS 保證;同時(shí)，UDP 協(xié)議的傳輸時(shí)延低于TCP協(xié)議，能保證多媒體數(shù)據(jù)流的流暢傳輸。當(dāng)然，當(dāng)存在對可靠性要求非常高的數(shù)據(jù)傳輸需求時(shí)，也可將RTP/RTCP 協(xié)議運(yùn)行于TCP 協(xié)議之上，數(shù)據(jù)和控制信令的傳輸即適用于該類情況。

圖4(a)表示了RTP/RTCP 與各種網(wǎng)絡(luò)協(xié)議的關(guān)系。

3.1 適用于自組網(wǎng)系統(tǒng)的用戶面協(xié)議

軍事應(yīng)用中，自組網(wǎng)系統(tǒng)的業(yè)務(wù)主要分為音視頻和數(shù)據(jù)兩部分。按照傳統(tǒng)的RTP 使用方法，音視頻一般采用UDP 傳輸，而數(shù)據(jù)和控制指令采用TCP傳輸?？紤]到系統(tǒng)對時(shí)延要求較高，尤其是火控?cái)?shù)據(jù)，而TCP 連接建立過程中需要三次握手，若采用該協(xié)議，將對時(shí)延指標(biāo)的實(shí)現(xiàn)帶來巨大壓力。因此，本系統(tǒng)所有通信業(yè)務(wù)的傳輸均采用UDP 協(xié)議。

由于音視頻數(shù)據(jù)對時(shí)延和抖動(dòng)要求較高，因此，必須使用RTP/RTCP 監(jiān)控?cái)?shù)據(jù)傳輸，保證傳輸質(zhì)量，因此，音視頻傳輸協(xié)議棧定義如圖4(b)所示

由于軍事應(yīng)用中的某些數(shù)據(jù)(比如火指控?cái)?shù)據(jù))對時(shí)延要求非常高，若使用SIP+RTP/RTCP 的方式進(jìn)行傳輸，則在真正的數(shù)據(jù)傳輸前，必須首先進(jìn)行四次SIP 握手，這將導(dǎo)致時(shí)延大幅增加。因此，建議數(shù)據(jù)傳輸時(shí)，不使用SIP 進(jìn)行信令交互，同時(shí)，數(shù)據(jù)面協(xié)議中不封裝RTP/RTCP 頭以減小數(shù)據(jù)量。數(shù)據(jù)傳輸協(xié)議棧修改如圖4(c)所示。

圖4 自組網(wǎng)用戶面協(xié)議棧圖示

4 結(jié)束語

本文分析了應(yīng)用層流媒體協(xié)議的特性，針對自組網(wǎng)的應(yīng)用需求，進(jìn)行了協(xié)議選型。由于自組網(wǎng)系統(tǒng)具有節(jié)點(diǎn)平等，移動(dòng)性強(qiáng)及無線傳輸質(zhì)量差的網(wǎng)絡(luò)特性，對所選擇的SIP 和RTP/RTCP 協(xié)議架構(gòu)及呼叫流程進(jìn)行了修改，使其適用于自組織網(wǎng)絡(luò)，是一種可行的自組網(wǎng)流媒體協(xié)議。

［1］郝中偉，郝中娜.基于WEB 的呼叫中心［J］.信息技術(shù)，2002，(6):61-64.

［2］H.323 Standards.http://www.h323forum.org/standards/.

［3］J.Rosenberg，H.Schulzrinne，G.Camarillo.SIP:Session Initiation Protocol.RFC 3261，IETF，June，2002.

［4］林韜.基于SIP 的多媒體通信研究與實(shí)現(xiàn)，［D］.北京:北京郵電大學(xué)，2009:2-18.

［5］崔學(xué)敏.視頻通信協(xié)議技術(shù)的分析研究與應(yīng)用［D］.昆明:昆明理工大學(xué)，2007:3-12.

［6］韓磊磊.基于P2P-SIP 的VoIP 關(guān)鍵技術(shù)研究［D］.鄭州:解放軍信息工程大學(xué)，2010:44-20.

［7］RFC3550，RTP:A Transport Protocol for Real-Time Applications.