RTP與RTCP協議介紹

本文主要介紹RTP與RTCP協議。

author: ZJ    06-11-17

Blog: [url]http://zhangjunhd.blog.51cto.com/[/url]

 

1．流媒體( Streaming Media)

1.1流媒體概念

流媒體技術是網絡技術和多媒體技術發展到必定階段的產物。術語流媒體既能夠指在網上傳輸連續時基媒體的流式技術,也能夠指使用流式技術的連續時基媒體自己。在網上傳輸音頻、視頻等多媒體信息目前主要有兩種方式:下載和流式傳輸。採用下載方式,用戶須要先下載整個媒體文件,而後才能進行播放。因爲網絡帶寬的限制,下載經常要花很長時間,因此這種處理方式延遲很大。而流媒體實現的關鍵技術是流式傳輸。傳輸以前首先對多媒體進行預處理(下降質量和高效壓縮) ,而後使用緩存系統來保證數據連續正確地進行傳輸。使用流式傳輸方式,用戶沒必要像採用下載方式那樣要等到整個文件所有下載完畢,而是隻需通過幾秒到幾十秒的啓動延時便可在客戶端進行播放和觀看。此時媒體文件的剩餘部分將在後臺繼續下載。與單純的下載方式相比,這種對多媒體文件邊下載邊播放的流式傳輸方式不只使啓動延時大幅度地縮短,並且對系統緩存容量的需求也大大下降。使用流式傳輸的另外一個好處是使傳輸那些事先不知道或沒法知道大小的媒體數據(如網上直播、視頻會議等) 成爲可能。

到目前爲止,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協議就是提供了時間標籤,序列號以及其它的結構用於控制適時數據的流放。在流的概念中」時間標籤」是最重要的信息。發送端依照即時的採樣在數據包裏隱蔽的設置了時間標籤。在接受端收到數據包後,就依照時間標籤按照正確的速率恢復成原始的適時的數據。不一樣的媒體格式調時屬性是不同的。可是rtp自己並不負責同步，rtp只是傳輸層協議，爲了簡化運輸層處理，提升該層的效率。將部分運輸層協議功能（好比流量控制）上移到應用層完成。同步就是屬於應用層協議完成的。它沒有運輸層協議的完整功能，不提供任何機制來保證明時地傳輸數據，不支持資源預留，也不保證服務質量。rtp報文甚至不包括長度和報文邊界的描述。同時rtp協議的數據報文和控制報文的使用相鄰的不一樣端口，這樣大大提升了協議的靈活性和處理的簡單性。

rtp協議和udp兩者共同完成運輸層協議功能。udp協議只是傳輸數據包，無論數據包傳輸的時間順序。 rtp的協議數據單元是用udp分組來承載的。在承載rtp數據包的時候，有時候一幀數據被分割成幾個包具備相同的時間標籤，則能夠知道時間標籤並非必須的。而udp的多路複用讓rtp協議利用支持顯式的多點投遞，能夠知足多媒體會話的需求。

rtp協議雖然是傳輸層協議可是它沒有做爲osi體系結構中單獨的一層來實現。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位，時標反映RTP數據包中第一個八進制數的採樣時刻，採樣時刻必須從單調、線性增長的時鐘導出，以容許同步與抖動計算。時標可讓receiver端知道在正確的時間將資料播放出來。

由上圖可知，若是隻有系列號，並不能完整按照順序的將data播放出來，由於若是data中間有一段是沒有資料的，只有系列號的話會形成錯誤，需搭配上讓它知道在哪一個時間將data正確播放出來，如此咱們才能播放出正確無誤的信息。

 

⑨×××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工做機制

當應用程序開始一個rtp會話時將使用兩個端口：一個給rtp，一個給rtcp。rtp自己並不能爲按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠rtcp提供這些服務。在rtp的會話之間週期的發放一些rtcp包以用來傳監聽服務質量和交換會話用戶信息等功能。rtcp包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料。所以，服務器能夠利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。rtp和rtcp配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，於是特別適合傳送網上的實時數據。根據用戶間的數據傳輸反饋信息，能夠制定流量控制的策略，而會話用戶信息的交互，能夠制定會話控制的策略。

 

3.2 RTCP數據報

在RTCP通訊控制中，RTCP協議的功能是經過不一樣的RTCP數據報來實現的，主要有以下幾種類型：

①SR:發送端報告，所謂發送端是指發出RTP數據報的應用程序或者終端，發送端同時也能夠是接收端。

②RR:接收端報告，所謂接收端是指僅接收但不發送RTP數據報的應用程序或者終端。

③SDES:源描述，主要功能是做爲會話成員有關標識信息的載體，如用戶名、郵件地址、電話號碼等，此外還具備向會話成員傳達會話控制信息的功能。

④BYE:通知離開，主要功能是指示某一個或者幾個源再也不有效，即通知會話中的其餘成員本身將退出會話。

⑤APP:由應用程序本身定義，解決了RTCP的擴展性問題，而且爲協議的實現者提供了很大的靈活性。

 

4．資源預訂協議RSVP (Resorce Reservation Protocol)

因爲音頻和視頻數據流比傳統數據對網絡的延時更敏感，要在網絡中傳輸高質量的音頻、視頻信息，除帶寬要求以外，還需其餘更多的條件。RSVP是Internet上的資源預訂協議，使用RSVP預留部分網絡資源(即帶寬)，能在必定程度上爲流媒體的傳輸提供QoS。

 

5．參考資料

[1]蔣愛權，流媒體技術的Java實現，計算機應用研究2002，10。

[2]吳國勇，網絡視頻流媒體技術與應用，北京郵電大學出版社，2001。

[3]臺灣國立中央大學電機工程系通信專題報告VOIP