基于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ù)姆⻊召|量。另外，RTP將部分傳輸層協(xié)議功能(比如流量控制)上移到應用層完成，簡化了傳輸層處理，提高了該層效率。同時RTP的數(shù)據(jù)報文和控制報文使用相鄰的不同端口，保證了數(shù)據(jù)流和控制流的分離；
(2)可擴展性和適用性。RTP通常為一個具體的應用來提供服務，通過一個具體的應用進程實現(xiàn)，而不作為OSI體系結構中單獨的一層來實現(xiàn)，RTP只提供協(xié)議框架，開發(fā)者可以根據(jù)應用的具體要求進行充分的擴展。
RTP在UDP協(xié)議之上，由包頭和負載構成。其包頭的前12byte是固定存在的，負載數(shù)據(jù)可以是音視頻信息。其包頭中含有負載類型，以及保證數(shù)據(jù)實時連續(xù)性的信息(如Sequence Number、Timestamp等)，能夠保證音視頻的同步。
RTP協(xié)議本身不提供流量控制和擁塞控制功能，它靠一個專門的實時傳輸控制協(xié)議(RTCP)來實現(xiàn)。RTCP根據(jù)攜帶控制信息的不同，分為5種分組類型：發(fā)送方報告RR、接收方報告SR、資源描述條目SDES、結束參與顯示包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之間的登記注冊、授權許可、帶寬改變、狀態(tài)和脫離解除等過程；H.225呼叫信令用來建立兩個終端之間的連接，這個信令使用Q.931消息來控制呼叫的建立和拆除；H.245控制信令用來傳送終端到終端的控制消息，包括主從判別、能力交換、打開和關閉邏輯信道、模式參數(shù)請求、流控消息和通用命令與指令等。圖1描述了兩個H.323終端通過GK進行呼叫建立的過程。
1.3SIP協(xié)議分析
SIP是應用層的控制協(xié)議，用來建立、修改、和終止多媒體會話或者呼叫。SIP 的終端系統(tǒng)叫做UA(用戶代理)，中間的結點叫做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技術實現(xiàn)。DirectShow系統(tǒng)位于應用層中，它使用一種叫Filter Graph的模型來管理整個數(shù)據(jù)流的處理過程；參與數(shù)據(jù)處理的各個功能模塊叫做Filter；各個Filter在Filter Graph中按一定的順序連接成一條“流水線”協(xié)同工作。
3.1方案設計
由發(fā)送端和接收端組成。以視頻為例，圖4、5兩幅Filter Graph詳細說明了各個filter之間的關系和流程。
同時考慮視頻和音頻，并將Filter Graph簡化，可以得到圖6。
3.2發(fā)送速度的控制
RTP協(xié)議沒有規(guī)定RTP包的長度和發(fā)送數(shù)據(jù)的速度，因此需要根據(jù)具體情況調整服務器端發(fā)送媒體流的速度。對于來自設備的實時數(shù)據(jù)可以采取等時間間隔訪問設備緩沖區(qū)，在有新數(shù)據(jù)輸入時發(fā)送數(shù)據(jù)的方式，時間戳的設置相對容易；對于媒體文件來說，如H.263格式的視頻文件，由于其本身不包含幀率信息，需要事先知道其原有的幀率或者設置一個初始值，在發(fā)送數(shù)據(jù)的時候找出發(fā)送數(shù)據(jù)中的幀數(shù)目，然后根據(jù)幀率和預設初始值來計算時延。
時間戳字段是RTP包頭中說明數(shù)據(jù)包時間的同步信息，是數(shù)據(jù)能以正確的時間順序恢復的關鍵。時間戳的值給出了分組中數(shù)據(jù)的第一個字節(jié)的采樣時間(Sampling Instant)，要求發(fā)送方時間戳的時鐘是連續(xù)、單調增長的，即使在沒有數(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ù)流能夠同步的前提是接收端能夠知道哪個音頻流與哪個視頻流是關聯(lián)的，為此RCTP要求發(fā)送端給每個傳輸分配一個能夠唯一標識數(shù)據(jù)源的規(guī)范名 (Canonical Name)。盡管由一個數(shù)據(jù)源發(fā)出的不同的流具有不同的同步源標識(SSRC)，但由于有相同的規(guī)范名，這樣接收端就知道哪些流是有關聯(lián)的。然后利用SR報文所包含的信息，接收方協(xié)調兩個流中的時間戳值。SR中含有一個以網(wǎng)絡時間協(xié)議NTP(Network Time Protocol)格式表示的絕對時間值，結合RTP包中的時間戳值就能夠確定同步的音視頻數(shù)據(jù)。由于發(fā)送端發(fā)出的音視頻數(shù)據(jù)流和SR都使用同一個絕對時鐘，接收方就可以比較來自同一數(shù)據(jù)源的兩個流的絕對時間，從而確定如何將一個流中的時間戳值映射為另一個流中的時間戳值。
4結論
由于RTP協(xié)議支持多播技術，因此發(fā)送端可以作為多媒體服務器實現(xiàn)對流媒體的分發(fā)，從而達到直播或轉播的效果。
通過對于多媒體通信的監(jiān)控，可以在實際生活中得到許多應用，比如對點對點視頻通信以及視頻會議的監(jiān)控。不僅如此，在DirectShow框架下可以將接收端接收到的數(shù)據(jù)流存儲在硬盤上，就能夠對媒體流進行錄制，并進一步提供下載等服務。
《衛(wèi)星與網(wǎng)絡》雜志
相關鏈接: