rtp協議詳解/rtcp協議詳解

一、簡介

目前，在IP網絡中實現實時語音、視頻通訊和應用已經成爲網絡應用的一個主流技術和發展方向，本文詳細介紹IP協議族中用於實時語音、視頻數據傳輸的標準協議RTP（ Real-time Transport Protocol）和RTCP（RTP Control Ptotocol）的主要功能。

二、RTP/RTCP協議簡介

RTP 由 IETF（http://www.ietf.org/）定義在 RFC 3550和3551中。

RTP被定義爲傳輸音頻、視頻、模擬數據等實時數據的傳輸協議，與傳統的注重的高可靠的數據傳輸的運輸層協議相比，它更加側重的數據傳輸的實時性，此協議提供的服務包括數據順序號、時間標記、傳輸控制等。

RTP一般與輔助控制協議RTCP一塊兒工做，RTP只負責實時數據的傳輸，RTCP負責對RTP的通訊和會話進行帶外管理（如流量控制、擁塞控制、會話源管理等）。

三、RTP/RTCP協議層次和封裝

RTP位於傳輸層（一般是UDP）之上，應用程序之下，實時語音、視頻數據通過模數轉換和壓縮編碼處理後，先送給RTP封裝成爲RTP數據單元，RTP數據單元被封裝爲UDP數據報，而後再向下遞交給IP封裝爲IP數據包。

RTP分組只包含RTP數據，而控制是由另外一個配套協議RTCP提供。RTP在端口號1025到65535之間選擇一個未使用的偶數UDP端口號，而在同一次會話中的RTCP則使用下一個奇數UDP端口號。

RTP一般和RTCP一塊兒工做，在RTP會話期間，各參與者週期的發送RTCP消息。RTCP消息含有已發送數據的丟包統計和網絡擁塞等信息，服務器能夠利用這些信息動態的改變傳輸速率，甚至改變淨荷的類型。RTCP消息也被封裝爲UDP數據報進行傳輸。

四、RTP/RTCP協議頭信息

version (V): 2 bits

標明RTP版本號。協議初始版本爲0，RFC3550中規定的版本號爲2。

padding (P): 1 bit

若是該位被設置，則在該packet末尾包含了額外的附加信息，附加信息的最後一個字節表示額外附加信息的長度（包含該字節自己）。該字段之因此存在是由於一些加密機制須要固定長度的數據塊，或者爲了在一個底層協議數據單元中傳輸多個RTP packets。

extension (X): 1 bit

若是該位被設置，則在固定的頭部後存在一個擴展頭部，格式定義在RFC3550 5.3.1節。

CSRC count (CC): 4 bits

在固定頭部後存在多少個CSRC標記。

marker (M): 1 bit

該位的功能依賴於profile的定義。profile能夠改變該位的長度，可是要保持marker和payload type總長度不變（一共是8 bit）。

payload type (PT): 7 bits

標記着RTP packet所攜帶信息的類型，標準類型列出在RFC3551中。若是接收方不能識別該類型，必須忽略該packet。

sequence number: 16 bits

序列號，每一個RTP packet發送後該序列號加1，接收方能夠根據該序列號從新排列數據包順序。

timestamp: 32 bits

時間戳。反映RTP packet所攜帶信息包中第一個字節的採樣時間。

SSRC: 32 bits

數據源標識。在一個RTP Session其間每一個數據流都應該有一個不一樣的SSRC。

CSRC list: 0 to 15 items, 每一個源標識32 bits

貢獻數據源標識。只有存在Mixer的時候纔有效。如一個將多聲道的語音流合併成一個單聲道的語音流，在這裏就列出原來每一個聲道的SSRC。

 

五、RTCP協議

RTCP協議處理機根據定義了五種類型的報文：

RR: receiver report

SR: sender report

SDES: source description items.

BYE: indicates end of participation.

APP: application specific functions

它們完成接收、分析、產生和發送控制報文的功能。

RTCP能夠說是控制交通的協議，它提供了：

1）SR發送者報告分組：用來使發送端週期的向全部接收端用多播方式進行報告。內容包括：

該RTP流的SSRC；該RTP流中最新產生的RTP分組的時間戳和絕對時鐘時間（或稱牆上時間：wall clock time);該RTP流包含的分組數；該RTP流包含的字節數。

絕對時鐘時間是必要的。由於RTP要求每一種媒體使用一個流。有了絕對時鐘時間就能夠進行圖形和聲音的同步。

2）RR接收者報告分組：用來使接收端週期性的向全部的點用多播方式進行報告。內容包括

所接收到的RTP流的SSRC；該RTP流的分組丟失率；在該RTP流中的最後一個RTP分組的序號；分組到達時間間隔的抖動等。

發送RR分組有兩個目的。第一，可使全部的接收端和發送端了解當前網絡的狀態。

第二，可使全部發送RTCP分組的站點自適應的調整本身發送RTCP分組的速率，RTCP分組的通訊量不超過網絡中的數據分組的通訊量的5%，而接收端分組報告分組的通訊量又應小於全部RTCP分組的通訊量的75%。

3）SDES源描述分組：給出會話中參加者的描述，包括參加者的規範名（CNAME）

4）BYE分組：關閉一個數據流。

5）APP分組：應用程序可以定義新的分組類型。

六、實時流協議RTSP協議

1） RTSP協議

RTSP（Real Time Streaming Protocol）協議定義瞭如何有效地經過IP網絡傳送多媒體數據，是一種客戶端到服務器端的多媒體描述協議，詳見RFC2326。

RTSP是一個很是相似於HTTP的應用層協議。每一個發佈和媒體文件也被定義爲RTSP UPL。而媒體文件的發佈信息被書寫進一個被稱爲媒體發佈文件裏，這個文件在後面會說明。在這個文件說明的包括編碼器，語言，RTSP ULS，地址，端口號以幾其它參數。這個發佈文件能夠在客戶端經過EMAIL形式或者HTTP形式得到。

2） RTSP協議的特色：

RTSP是應用層協議,與RTP、RSVP一塊兒設計來徹底流式服務。

RTSP有很大的靈活性，可被用在多種操做系統上,它容許客戶端和不一樣廠商的服務平臺交互。

RTSP在體系結構上位於RTP和RTCP之上，它使用RTP完成數據傳輸。它將流式媒體數據可控制的經過網絡傳輸到客戶端。

RTSP能夠保持用戶計算機與傳輸流業務服務器之間的固定鏈接，用於觀看者與單播（Unicast）服務器通訊而且還容許雙向通訊，觀看者能夠同流媒體服務器通訊.

提供相似「VCR」形式的例如暫停、快進、倒轉、跳轉等操做。操做的資源對象能夠是直播流也能夠是存儲片斷。

RTSP是設還提供了選擇傳輸通道，如使用UDP仍是多點UDP或是TCP。

七、資源預留協議RSVP

1） RSVP協議：

RSVP (Resorce reSerVation Protocol) 資源預留協議並非一個路由協議，而是一種IP網絡中的信令協議，它與路由協議相結合來實現對網絡傳輸服務質量（QoS）的控制。RSVP是爲支持因特網綜合業務而提出的。這是解決IP通訊中QoS（服務質量）問題的一種技術，用來保證點端到端的傳輸帶寬。

2） RSVP協議是如何工做：

RSVP使用控制數據報，這些數據報在向特定地址傳輸時包括了須要由路由器檢查（有些時候須要更新）的信息,若是路由器須要決定是否是要檢查數據報的內容的時候對上層數據內容進行語法分析。這種分析的代價可不小。如今的狀況是，網絡終端利用它向網絡申請資源，在這種代表「申請」 的信號中，包含着以下的信息：業務的種類？ 使用者類型？ 什麼時間？ 須要多大帶寬？ 其餘參考信息？ 網絡在接收到上類信息後，會根據實際狀況爲這次鏈接分配一個優先代碼，用戶利用優先代碼進行信息傳遞時，網絡不需從新對業務進行分析與判別，從另一個角度來講，利用RSVP 能從必定程度上減小網絡對信息處理的時延，提升網絡節點的工做效率，改善信息傳輸的服務質量（QoS）。實時應用用RSVP是爲了在傳輸路徑中保持必要的資源以保證請求能確保到達。

RSVP是IP路由器爲提供更好的服務質量向前邁進的具備深入意義的一步。傳統上IP路由器只負責分組轉發，經過路由協議知道鄰近路由器的地址。而RSVP則相似於電路交換系統的信令協議同樣，爲一個數據流通知其所通過的每一個節點（IP路由器），與端點協商爲此數據流提供質量保證。

八、結束語

在前面咱們討論了一些與實時數據傳輸相關的四個協議：

1）RTP是實時數據傳輸協議。它提供時間標誌，序列號以及其它可以保證在實時數據傳輸時處理時間的方法；它是依靠RVSP保證服務質量標準的。

2）RTCP是RTP的控制部分,是用來保證服務質量和成員管理的。

3）RTSP是開始和指引流媒體數據從流媒體服務器。它又可叫作"網上錄像機控制協議".它是提供遠程的控制，具體的數據傳輸是交給RTP的。

4）RSVP是Internet上的資源預訂協議，使用RSVP預留一部分網絡資源（即帶寬），能在必定程度上爲流媒體的傳輸提供QoS。就像TCP的重發和滑動窗口等都是

 

做者: Hundre 發表於 2010-11-20 21:56 原文連接

評論: 0 查看評論 發表評論

最新新聞：
· Debian 6.0「Squeeze」發佈(2011-02-06 11:17)
· 傳諾基亞將進行管理層重組 多名高管將離職(2011-02-06 11:15)
· 即將舉辦超級碗的Cowboys體育場在Google Earth裏3D化(2011-02-06 11:07)
· Android 3.0 Honeycomb 炫麗蜂巢開機動畫(2011-02-06 10:57)
· Google 發佈 Contracts for Java 開源項目(2011-02-06 10:47)

編輯推薦：無意插柳：Gmail之父，FriendFeed創始人談人生偶然性

網站導航：博客園首頁  個人園子  新聞  閃存  小組  博問  知識庫