本文主要介紹RTP與RTCP協議。
author: ZJ 06-11-17
1流媒體( Streaming Media)rtp協議rtp協議rtp協議rtp協議
1.1流媒體技術是網絡技術和多媒體技術發展到一定階段的產物。術語流媒體既可以指在網上傳輸連續時基媒體的流式技術,也可以指使用流式技術的連續時基媒體本身。在網上傳輸音頻、視頻等多媒體信息目前主要有兩種方式:下載和流式傳輸。採用下載方式,用戶需要先下載整個媒體文件,然後才能進行播放。由於網絡帶寬的限制,下載常常要花很長時間,所以這種處理方式延遲很大。而流媒體實現的關鍵技術是流式傳輸。傳輸之前首先對多媒體進行預處理(降低質量和高效壓縮) ,然後使用緩存系統來保證數據連續正確地進行傳輸。使用流式傳輸方式,用戶不必像採用下載方式那樣要等到整個文件全部下載完畢,而是隻需經過幾秒到幾十秒的啓動延時即可在客戶端進行播放和觀看。此時媒體文件的剩餘部分將在後臺繼續下載。與單純的下載方式相比,這種對多媒體文件邊下載邊播放的流式傳輸方式不僅使啓動延時大幅度地縮短,而且對系統緩存容量的需求也大大降低。使用流式傳輸的另一個好處是使傳輸那些事先不知道或無法知道大小的媒體數據(如網上直播、視頻會議等) 成爲可能。rtp協議
到目前爲止,Internet 上使用較多的流式視頻格式主要有以下三種:RealNetworks 公司的RealMedia ,Apple 公司的QuickTime 以及Microsoft 公司的Advanced Streaming Format (ASF) 。
1.2支持流媒體的協議
多媒體應用的一個顯著特點是數據量大,並且許多應用對實時性要求比較高。傳統的TCP 協議是一個面向連接的協議,它的重傳機制和擁塞控制機制都是不適用於實時多媒體傳輸的。RTP 是一個應用型的傳輸層協議,它並不提供任何傳輸可靠性的保證和流量的擁塞控制機制。RTP 位於UDP(User Datagram Protocol) 之上。UDP 雖然沒有TCP 那麼可靠,並且無法保證實時業務的服務質量,需要RTCP 實時監控數據傳輸和服務質量。但是,由於UDP 的傳輸時延低於TCP ,能與音頻和視頻很好地配合。因此,在實際應用中,RTP/ RTCP/ UDP 用於音頻/ 視頻媒體,而TCP 用於數據和控制信令的傳輸。目前,支持流媒體傳輸的協議主要有實時傳輸協議RTP( Real-Time Transport Protocol) 、實時傳輸控制協議RTCP(Real-Time Transport Control Protocol) 和實時流協議RTSP(Real-Time Streaming Protocol) 等。下面分別對這三種協議作簡要介紹。流媒體協議棧如圖1 所示。
圖1 流媒體協議棧
2．實時傳輸協議RTP（Real-Time Transport Protocol）：
RTP是針對Internet上多媒體數據流的一個傳輸協議, 由IETF(Internet工程任務組)作爲RFC1889發佈。RTP被定義爲在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現流同步。RTP的典型應用建立在UDP上，但也可以在TCP或ATM等其他協議之上工作。RTP本身只保證實時數據的傳輸，並不能爲按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。
2.1 RTP工作機制
rtp協議
2.2 RTP協議RTP頭格式如圖2所示：
開始12個八進制出現在每個RTP包中，而CSRC標識列表僅出現在混合器插入時。各段含義如下：
①版本（V）
2位，標識RTP版本。
②填充標識（P）
1位，如設置填充位，在包尾將包含附加填充字，它不屬於有效載荷。填充的最後一個八進制包含應該忽略的八進制計數。某些加密算法需要固定大小的填充字，或爲在底層協議數據單元中攜帶幾個RTP包。
③擴展（X）
1位，如設置擴展位，固定頭後跟一個頭擴展。
④CSRC計數（CC）
4位，CSRC計數包括緊接在固定頭後CSRC標識符個數。
⑤標記（M）
1位，標記解釋由設置定義，目的在於允許重要事件在包流中標記出來。設置可定義其他標示位，或通過改變位數量來指定沒有標記位。
⑥載荷類型（PT）
7位，記錄後面資料使用哪種 Codec ， receiver 端找出相應的 decoder 解碼出來。
常用 types：
|
Payload Type
|
Codec
|
|
0
|
PCM μ -Law
|
|
8
|
PCM-A Law
|
|
9
|
G..722 audio codec
|
|
4
|
G..723 audio codec
|
|
15
|
G..728 audio codec
|
|
18
|
G..729 audio codec
|
|
34
|
G..763 audio codec
|
|
31
|
G..761 audio codec
|
⑦系列號
16位，系列號隨每個RTP數據包而增加1，由接收者用來探測包損失。系列號初值是隨機的，使對加密的文本***更加困難。
⑧時標
32
⑨***C
32位，***C段標識同步源。此標識不是隨機選擇的，目的在於使同一RTP包連接中沒有兩個同步源有相同的***C標識。儘管多個源選擇同一個標識的概率很低，所有RTP實現都必須探測並解決衝突。如源改變源傳輸地址，也必須選擇一個新***C標識以避免插入成環行源。
⑩CSRC列表
0到15項，每項32位。CSRC列表表示包內的對載荷起作用的源。標識數量由CC段給出。如超出15個作用源，也僅標識15個。CSRC標識由混合器插入，採用作用源的***C標識。
3．實時傳輸控制協議RTCP(Real-Time Transport Control Protocol)
RTCP負責管理傳輸質量在當前應用進程之間交換控制信息。在RTP會話期間，各參與者週期性地傳送RTCP包，包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料。因此，服務器可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，故特別適合傳送網上的實時數據。
3.1 RTCP工作機制
3.2 RTCP數據報
在RTCP通信控制中，RTCP協議的功能是通過不同的RTCP數據報來實現的，主要有如下幾種類型：
①SR:發送端報告，所謂發送端是指發出RTP數據報的應用程序或者終端，發送端同時也可以是接收端。
②RR:接收端報告，所謂接收端是指僅接收但不發送RTP數據報的應用程序或者終端。
③SDES:源描述，主要功能是作爲會話成員有關標識信息的載體，如用戶名、郵件地址、電話號碼等，此外還具有向會話成員傳達會話控制信息的功能。
④BYE:通知離開，主要功能是指示某一個或者幾個源不再有效，即通知會話中的其他成員自己將退出會話。
⑤APP:由應用程序自己定義，解決了RTCP的擴展性問題，並且爲協議的實現者提供了很大的靈活性。
4．
5．參考資料
[1]流媒體技術的Java實現，計算機應用研究2002，10。
[2][3]