基于RTP的多媒體通信的監(jiān)控/發(fā)布的設(shè)計(jì)與實(shí)現(xiàn)
楊 鵬 姚顯利 2007/02/14
為實(shí)現(xiàn)對(duì)多媒體通信的監(jiān)聽(tīng)，首先要能夠捕獲到媒體流的數(shù)據(jù)包，并剔除掉無(wú)效的信息，保留有用的信息，然后根據(jù)通信協(xié)議對(duì)有效信息做進(jìn)一步的解析。
1協(xié)議原理分析
1.1傳輸層協(xié)議分析
很多多媒體通信的數(shù)據(jù)傳輸都是利用實(shí)時(shí)傳輸協(xié)議RTP實(shí)現(xiàn)的，因此要對(duì)多媒體通信進(jìn)行監(jiān)聽(tīng)要先分析RTP協(xié)議。RTP是實(shí)現(xiàn)數(shù)據(jù)實(shí)時(shí)傳輸非常有效的協(xié)議，能夠提供端對(duì)端的網(wǎng)絡(luò)傳輸功能，適合單播或多播網(wǎng)絡(luò)的多媒體數(shù)據(jù)的實(shí)時(shí)傳輸應(yīng)用。
RTP傳輸協(xié)議有如下一些特點(diǎn)。
(1)靈活性和簡(jiǎn)單性。RTP不具備傳輸層協(xié)議的完整功能，不支持資源預(yù)留，也不保證實(shí)時(shí)傳輸?shù)姆⻊?wù)質(zhì)量。另外，RTP將部分傳輸層協(xié)議功能(比如流量控制)上移到應(yīng)用層完成，簡(jiǎn)化了傳輸層處理，提高了該層效率。同時(shí)RTP的數(shù)據(jù)報(bào)文和控制報(bào)文使用相鄰的不同端口，保證了數(shù)據(jù)流和控制流的分離；
(2)可擴(kuò)展性和適用性。RTP通常為一個(gè)具體的應(yīng)用來(lái)提供服務(wù)，通過(guò)一個(gè)具體的應(yīng)用進(jìn)程實(shí)現(xiàn)，而不作為OSI體系結(jié)構(gòu)中單獨(dú)的一層來(lái)實(shí)現(xiàn)，RTP只提供協(xié)議框架，開(kāi)發(fā)者可以根據(jù)應(yīng)用的具體要求進(jìn)行充分的擴(kuò)展。
RTP在UDP協(xié)議之上，由包頭和負(fù)載構(gòu)成。其包頭的前12byte是固定存在的，負(fù)載數(shù)據(jù)可以是音視頻信息。其包頭中含有負(fù)載類型，以及保證數(shù)據(jù)實(shí)時(shí)連續(xù)性的信息(如Sequence Number、Timestamp等)，能夠保證音視頻的同步。
RTP協(xié)議本身不提供流量控制和擁塞控制功能，它靠一個(gè)專門(mén)的實(shí)時(shí)傳輸控制協(xié)議(RTCP)來(lái)實(shí)現(xiàn)。RTCP根據(jù)攜帶控制信息的不同，分為5種分組類型：發(fā)送方報(bào)告RR、接收方報(bào)告SR、資源描述條目SDES、結(jié)束參與顯示包BYE，以及特別應(yīng)用功能APP。RTCP的分發(fā)機(jī)制與RTP相同，它周期性地與所有會(huì)話參與者傳輸控制包，統(tǒng)計(jì)數(shù)據(jù)包傳輸時(shí)的丟失情況等信息，服務(wù)器根據(jù)這些反饋信息來(lái)制定流量控制的策略，改變傳輸碼率甚至負(fù)載類型，能夠大大提高實(shí)時(shí)數(shù)據(jù)的傳輸性能。
1.2H.323協(xié)議棧分析
H.323呼叫建立過(guò)程涉及3種信令：RAS信令，H.225呼叫信令和H.245控制信令。RAS信令用來(lái)完成終端與GK之間的登記注冊(cè)、授權(quán)許可、帶寬改變、狀態(tài)和脫離解除等過(guò)程；H.225呼叫信令用來(lái)建立兩個(gè)終端之間的連接，這個(gè)信令使用Q.931消息來(lái)控制呼叫的建立和拆除；H.245控制信令用來(lái)傳送終端到終端的控制消息，包括主從判別、能力交換、打開(kāi)和關(guān)閉邏輯信道、模式參數(shù)請(qǐng)求、流控消息和通用命令與指令等。圖1描述了兩個(gè)H.323終端通過(guò)GK進(jìn)行呼叫建立的過(guò)程。
1.3SIP協(xié)議分析
SIP是應(yīng)用層的控制協(xié)議，用來(lái)建立、修改、和終止多媒體會(huì)話或者呼叫。SIP 的終端系統(tǒng)叫做UA(用戶代理)，中間的結(jié)點(diǎn)叫做proxy服務(wù)器。SIP是基于消息機(jī)制的文本協(xié)議，使用UTF-8字符集。一個(gè)SIP消息既可以是一個(gè)從客戶端到服務(wù)器端的請(qǐng)求，也可以是一個(gè)從服務(wù)器端到客戶端的一個(gè)應(yīng)答。圖2是SIP會(huì)話建立的一個(gè)例子。
SIP協(xié)議憑借其簡(jiǎn)單、易于擴(kuò)展、便于實(shí)現(xiàn)等諸多優(yōu)點(diǎn)越來(lái)越得到業(yè)界的青睞，它正逐步成為NGN(下一代網(wǎng)絡(luò))和3G多媒體子系統(tǒng)域中的重要協(xié)議，并且市場(chǎng)上出現(xiàn)越來(lái)越多的支持SIP的客戶端軟件和智能多媒體終端，以及用SIP協(xié)議實(shí)現(xiàn)的服務(wù)器和軟交換設(shè)備。
2對(duì)媒體流監(jiān)聽(tīng)的設(shè)計(jì)和實(shí)現(xiàn)
通過(guò)分析H.323和SIP這兩種多媒體通信中應(yīng)用最廣泛的協(xié)議，可以捕獲數(shù)據(jù)包并進(jìn)行解析來(lái)達(dá)到監(jiān)聽(tīng)的目的。
在H.323協(xié)議下，所要捕獲的數(shù)據(jù)包為終端與終端(包括MCU)間通信傳輸?shù)腞TP包。在呼叫建立之初就在H.323協(xié)議框架下對(duì)每個(gè)IP包進(jìn)行解析判斷。首先經(jīng)過(guò)比對(duì)獲得H.225 RAS ARQ，解析得到多媒體會(huì)話ID用來(lái)確定所要發(fā)布的媒體流；然后判斷解析H.245 OpenLogicalChannelAck包，獲得RTP通信的IP地址，確定此地址是指定終端的IP地址，同時(shí)記錄負(fù)載分別為音頻和視頻的端口號(hào)，作為過(guò)濾后繼RTP數(shù)據(jù)流的依據(jù)。
由于SIP是文本協(xié)議，判斷起來(lái)與H.323協(xié)議相比較為便捷。經(jīng)過(guò)比對(duì)首先獲得被監(jiān)聽(tīng)端與UA呼叫建立后回發(fā)的200 OK消息，在其消息體中獲得RTP通信的端口號(hào)，包括音頻和視頻。進(jìn)而對(duì)RTP包進(jìn)行過(guò)濾，將IP地址和端口號(hào)符合條件的RTP包保留，就是我們所要捕獲的媒體流。
3媒體流發(fā)布的設(shè)計(jì)與實(shí)現(xiàn)
媒體流的傳輸和播放都可以基于微軟的DirectShow技術(shù)實(shí)現(xiàn)。DirectShow系統(tǒng)位于應(yīng)用層中，它使用一種叫Filter Graph的模型來(lái)管理整個(gè)數(shù)據(jù)流的處理過(guò)程；參與數(shù)據(jù)處理的各個(gè)功能模塊叫做Filter；各個(gè)Filter在Filter Graph中按一定的順序連接成一條“流水線”協(xié)同工作。
3.1方案設(shè)計(jì)
由發(fā)送端和接收端組成。以視頻為例，圖4、5兩幅Filter Graph詳細(xì)說(shuō)明了各個(gè)filter之間的關(guān)系和流程。
同時(shí)考慮視頻和音頻，并將Filter Graph簡(jiǎn)化，可以得到圖6。
3.2發(fā)送速度的控制
RTP協(xié)議沒(méi)有規(guī)定RTP包的長(zhǎng)度和發(fā)送數(shù)據(jù)的速度，因此需要根據(jù)具體情況調(diào)整服務(wù)器端發(fā)送媒體流的速度。對(duì)于來(lái)自設(shè)備的實(shí)時(shí)數(shù)據(jù)可以采取等時(shí)間間隔訪問(wèn)設(shè)備緩沖區(qū)，在有新數(shù)據(jù)輸入時(shí)發(fā)送數(shù)據(jù)的方式，時(shí)間戳的設(shè)置相對(duì)容易；對(duì)于媒體文件來(lái)說(shuō)，如H.263格式的視頻文件，由于其本身不包含幀率信息，需要事先知道其原有的幀率或者設(shè)置一個(gè)初始值，在發(fā)送數(shù)據(jù)的時(shí)候找出發(fā)送數(shù)據(jù)中的幀數(shù)目，然后根據(jù)幀率和預(yù)設(shè)初始值來(lái)計(jì)算時(shí)延。
時(shí)間戳字段是RTP包頭中說(shuō)明數(shù)據(jù)包時(shí)間的同步信息，是數(shù)據(jù)能以正確的時(shí)間順序恢復(fù)的關(guān)鍵。時(shí)間戳的值給出了分組中數(shù)據(jù)的第一個(gè)字節(jié)的采樣時(shí)間(Sampling Instant)，要求發(fā)送方時(shí)間戳的時(shí)鐘是連續(xù)、單調(diào)增長(zhǎng)的，即使在沒(méi)有數(shù)據(jù)輸入或發(fā)送數(shù)據(jù)時(shí)也是如此。在靜默時(shí)，發(fā)送端不必發(fā)送數(shù)據(jù)，保持時(shí)間戳的增長(zhǎng)，在接收端，由于接收到的數(shù)據(jù)分組的序號(hào)沒(méi)有丟失，就知道沒(méi)有發(fā)生數(shù)據(jù)丟失。RTP規(guī)定一次會(huì)話的初始時(shí)間戳必須隨機(jī)選擇，但協(xié)議沒(méi)有規(guī)定時(shí)間戳的單位，也沒(méi)有規(guī)定該值的精確解釋，而是由負(fù)載類型來(lái)確定時(shí)鐘的顆粒，這樣各種應(yīng)用類型可以根據(jù)需要選擇合適的輸出計(jì)時(shí)精度。
對(duì)于本應(yīng)用來(lái)說(shuō)，捕獲的RTP數(shù)據(jù)包頭包含時(shí)間戳，發(fā)送數(shù)據(jù)時(shí)，只需比較前后兩包時(shí)間戳的差異，就能夠確定輸出的時(shí)間間隔，從而以適當(dāng)?shù)乃俣劝l(fā)送數(shù)據(jù)。
3.3音視頻的同步
音頻與視頻一起傳輸?shù)臅r(shí)候，由于編碼的不同，RTP使用兩個(gè)流分別進(jìn)行傳輸，這樣兩個(gè)流的時(shí)間戳以不同的速率變化，接收端必須同步兩個(gè)流，以保證聲音與圖像的一致。
音視頻數(shù)據(jù)流能夠同步的前提是接收端能夠知道哪個(gè)音頻流與哪個(gè)視頻流是關(guān)聯(lián)的，為此RCTP要求發(fā)送端給每個(gè)傳輸分配一個(gè)能夠唯一標(biāo)識(shí)數(shù)據(jù)源的規(guī)范名 (Canonical Name)。盡管由一個(gè)數(shù)據(jù)源發(fā)出的不同的流具有不同的同步源標(biāo)識(shí)(SSRC)，但由于有相同的規(guī)范名，這樣接收端就知道哪些流是有關(guān)聯(lián)的。然后利用SR報(bào)文所包含的信息，接收方協(xié)調(diào)兩個(gè)流中的時(shí)間戳值。SR中含有一個(gè)以網(wǎng)絡(luò)時(shí)間協(xié)議NTP(Network Time Protocol)格式表示的絕對(duì)時(shí)間值，結(jié)合RTP包中的時(shí)間戳值就能夠確定同步的音視頻數(shù)據(jù)。由于發(fā)送端發(fā)出的音視頻數(shù)據(jù)流和SR都使用同一個(gè)絕對(duì)時(shí)鐘，接收方就可以比較來(lái)自同一數(shù)據(jù)源的兩個(gè)流的絕對(duì)時(shí)間，從而確定如何將一個(gè)流中的時(shí)間戳值映射為另一個(gè)流中的時(shí)間戳值。
4結(jié)論
由于RTP協(xié)議支持多播技術(shù)，因此發(fā)送端可以作為多媒體服務(wù)器實(shí)現(xiàn)對(duì)流媒體的分發(fā)，從而達(dá)到直播或轉(zhuǎn)播的效果。
通過(guò)對(duì)于多媒體通信的監(jiān)控，可以在實(shí)際生活中得到許多應(yīng)用，比如對(duì)點(diǎn)對(duì)點(diǎn)視頻通信以及視頻會(huì)議的監(jiān)控。不僅如此，在DirectShow框架下可以將接收端接收到的數(shù)據(jù)流存儲(chǔ)在硬盤(pán)上，就能夠?qū)γ襟w流進(jìn)行錄制，并進(jìn)一步提供下載等服務(wù)。
《衛(wèi)星與網(wǎng)絡(luò)》雜志
相關(guān)鏈接: