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