what's the RTP協議

what's the RTP

　　RTP全名是Real-time Transport Protocol（實時傳輸協議）。它是IETF提出的一個標準，對應的RFC文檔爲RFC3550（RFC1889爲其過時版本）。RFC3550不只定義了RTP，並且定義了配套的相關協議RTCP（Real-time Transport Control Protocol，即實時傳輸控制協議）。

　　RTP用來爲IP網上的語音、圖像、傳真等多種須要實時傳輸的多媒體數據提供端到端的實時傳輸服務。RTP爲Internet上端到端的實時傳輸提供時間信息和流同步，但並不保證服務質量，服務質量由RTCP來提供。

 

RTP的應用環境

　　RTP用於在單播或多播網絡中傳送實時數據。它們典型的應用場合有以下幾個。

1. 簡單的多播音頻會議。語音通訊經過一個多播地址和一對端口來實現。一個用於音頻數據（RTP），另外一個用於控制包（RTCP）。
2. 音頻和視頻會議。若是在一次會議中同時使用了音頻和視頻會議，這兩種媒體將分別在不一樣的RTP會話中傳送，每個會話使用不一樣的傳輸地址（IP地址＋端口）。若是一個用戶同時使用了兩個會話，則每一個會話對應的RTCP包都使用規範化名字CNAME（Canonical Name）。與會者能夠根據RTCP包中的CNAME來獲取相關聯的音頻和視頻，而後根據RTCP包中的計時信息(Network time protocol)來實現音頻和視頻的同步。
3. 翻譯器和混合器。翻譯器和混合器都是RTP級的中繼系統。翻譯器用在經過IP多 播不能直接到達的用戶區，例如發送者和接收者之間存在防火牆。當與會者能接收的音頻編碼格式不同，好比有一個與會者經過一條低速鏈路接入到高速會議，這時就要使用混合器。在進入音頻數據格式須要變化的網絡前，混合器未來自一個源或多個源的音頻包進行重構，並把重構後的多個音頻合併，採用另外一種音頻編碼進 行編碼後，再轉發這個新的RTP包。從一個混合器出來的全部數據包要用混合器做爲它們的同步源（SSRC，見RTP的封裝）來識別，能夠經過貢獻源列表（CSRC表，見RTP的封裝）能夠確認談話者。

流媒體

　　流媒體是指Internet上使用流式傳輸技術的連續時基媒體。

　　當前在Internet上傳輸音頻和視頻等信息主要有兩種方式：下載和流式傳輸

　　下載狀況下，用戶須要先下載整個媒體文件到本地，而後才能播放媒體文件。在視頻直播等應用場合，因爲生成整個媒體文件要等直播結束，也就是用戶至少要在直播結束後才能看到直播節目，因此用下載方式不能實現直播。

　　流式傳輸是實現流媒體的關鍵技術。使用流式傳輸能夠邊下載邊觀看流媒體節目。因爲Internet是基於分組傳輸的，因此接收端收到的數據包每每有延遲和亂序（流式傳輸構建在UDP上）。要實現流式傳輸，就是要從下降延遲和恢復數據包時序入手。在發送端，爲下降延遲，每每對傳輸數據進行預處理（下降質量和高效壓縮）。在接收端爲了恢復時序，採用了接收緩衝；而爲了實現媒體的流暢播放，則採用了播放緩衝。

　　使用接收緩衝，能夠將接收到的數據包緩存起來，而後根據數據包的封裝信息（如包序號和時戳等），將亂序的包從新排序，最後將從新排序了的數據包放入播放緩衝播放。

　　爲何須要播放緩衝呢？容易想到，因爲網絡不可能很理想，而且對數據包排序須要處理時耗，咱們獲得排序好的數據包的時間間隔是不等的。若是不用播放緩衝，那麼播放節目會很卡，這叫時延抖動。相反，使用播放緩衝，在開始播放時，花費幾十秒鐘先將播放緩衝填滿（例如PPLIVE），能夠有效地消除時延抖動，從而在不太損失實時性的前提下實現流媒體的順暢播放。

　　到目前爲止,Internet 上使用較多的流式視頻格式主要有如下三種:RealNetworks 公司的RealMedia ,Apple 公司的QuickTime 以及Microsoft 公司的Advanced Streaming Format (ASF) 。

　　上面在談接收緩衝時，說到了流媒體數據包的封裝信息（包序號和時戳等），這在後面的RTP封裝中會有體現。另外，RealMedia這些流式媒體格式只是編解碼有不一樣，但對於RTP來講，它們都是待封裝傳輸的流媒體數據而沒有什麼不一樣。

 

怎樣重組亂序的數據包

　　能夠根據RTP包的序列號來排序。

怎樣得到數據包的時序

　　能夠根據RTP包的時間戳來得到數據包的時序。

聲音和圖像怎麼同步

　　根據聲音流和圖像流的相對時間（即RTP包的時間戳），以及它們的絕對時間（即對應的RTCP包中的RTCP），能夠實現聲音和圖像的同步。

接收緩衝和播放緩衝的做用

　　接收緩衝用來排序亂序了的數據包；播放緩衝用來消除播放的抖動，實現等時播放。

 

RTP的協議層次

　　RTP（實時傳輸協議），顧名思義它是用來提供實時傳輸的，於是能夠當作是傳輸層的一個子層。給出了流媒體應用中的一個典型的協議體系結構。下圖給出了RTP協議與其餘協議之間的關係。RTP、TCP、UDP都屬於傳輸層協議; RTP也能夠認爲是介於應用層與傳輸層之間

　　RTP被劃分在傳輸層，它創建在UDP上。同UDP協議同樣，爲了實現其實時傳輸功能，RTP也有固定的封裝形式。RTP用來爲端到端的實時傳輸提供時間信息和流同步，但並不保證服務質量。服務質量由RTCP來提供。

　　很多人也把RTP歸爲應用層的一部分，這是從應用開發者的角度來講的。操做系統中的TCP/IP等協議棧所提供的是咱們最經常使用的服務，而RTP的實現仍是要靠開發者本身。所以從開發的角度來講，RTP的實現和應用層協議的實現沒不一樣，因此可將RTP當作應用層協議。

　　RTP實現者在發送RTP數據時，需先將數據封裝成RTP包，而在接收到RTP數據包，須要將數據從RTP包中提取出來。

 

RTP的封裝

　　一個協議的封裝是爲了知足協議的功能需求的。RTP封裝中應該有同步源和時戳等字段，具體封裝形式以下

 

另外還包括如下字段

• 版本號（V）：2比特，用來標誌使用的RTP版本。
• 填充位（P）：1比特，若是該位置位，則該RTP包的尾部就包含附加的填充字節。
• 擴展位（X）：1比特，若是該位置位的話，RTP固定頭部後面就跟有一個擴展頭部。
• CSRC計數器（CC）：4比特，含有固定頭部後面跟着的CSRC的數目。
• 標記位（M）：1比特,該位的解釋由配置文檔（Profile）來承擔.
• 載荷類型（PT）：7比特，標識了RTP載荷的類型。
• 序列號（SN）：16比特，發送方在每發送完一個RTP包後就將該域的值增長1，接收方能夠由該域檢測包的丟失及恢復包序列。序列號的初始值是隨機的。
• 時間戳：32比特，記錄了該包中數據的第一個字節的採樣時刻。在一次會話開始時，時間戳初始化成一個初始值。即便在沒有信號發送時，時間戳的數值也要隨時間而不斷地增長（時間在流逝嘛）。時間戳是去除抖動和實現同步不可缺乏的。
• 同步源標識符(SSRC)：32比特，同步源就是指RTP包流的來源。在同一個RTP會話中不能有兩個相同的SSRC值。該標識符是隨機選取的 RFC1889推薦了MD5隨機算法。
• 貢獻源列表（CSRC List）：0～15項，每項32比特，用來標誌對一個RTP混合器產生的新包有貢獻的全部RTP包的源。由混合器將這些有貢獻的SSRC標識符插入表中。SSRC標識符都被列出來，以便接收端能正確指出交談雙方的身份。

RTP的會話過程

　　當應用程序創建一個RTP會話時，應用程序將肯定一對目的傳輸地址。目的傳輸地址由一個網絡地址和一對端口組成，有兩個端口：一個給RTP包，一個給RTCP包，使得RTP/RTCP數據可以正確發送。RTP數據發向偶數的UDP端口，而對應的控制信號RTCP數據發向相鄰的奇數UDP端口（偶數的UDP端口＋1），這樣就構成一個UDP端口對。 RTP的發送過程以下，接收過程則相反。

1. RTP協議從上層接收流媒體信息碼流（如H.263），封裝成RTP數據包；RTCP從上層接收控制信息，封裝成RTCP控制包。
2. RTP將RTP 數據包發往UDP端口對中偶數端口；RTCP將RTCP控制包發往UDP端口對中的接收端口。

 

RTCP的封裝

　　RTP須要RTCP爲其服務質量提供保證，所以須要介紹一下RTCP的相關知識。

　　RTCP的主要功能是：服務質量的監視與反饋、媒體間的同步，以及多播組中成員的標識。

　　在RTP會話期間，各參與者週期性地傳送RTCP包。RTCP包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料，所以，各參與者能夠利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，於是特別適合傳送網上的實時數據。

　　RTCP也是用UDP來傳送的，但RTCP封裝的僅僅是一些控制信息，於是分組很短，因此能夠將多個RTCP分組封裝在一個UDP包中。RTCP有以下五種分組類型。

類型	縮寫表示	用途
200	SR（Sender Report）	發送端報告
201	RR（Receiver Report）	接收端報告
202	SDES（Source Description Items）	源點描述
203	BYE	結束傳輸
204	APP	特定應用

表 1 RTCP的5種分組類型

上述五種分組的封裝大同小異，下面只講述SR類型，而其它類型請參考RFC3550。

　　發送端報告分組SR（Sender Report）用來使發送端以多播方式向全部接收端報告發送狀況。SR分組的主要內容有：相應的RTP流的SSRC，RTP流中最新產生的RTP分組的時間戳和NTP，RTP流包含的分組數，RTP流包含的字節數。

• 版本（V）：同RTP包頭域。
• 填充（P）：同RTP包頭域。
• 接收報告計數器（RC）：5比特，該SR包中的接收報告塊的數目，能夠爲零。
• 包類型（PT）：8比特，SR包是200。
• 長度域（Length）：16比特，其中存放的是該SR包以32比特爲單位的總長度減一。
• 同步源（SSRC）：SR包發送者的同步源標識符。與對應RTP包中的SSRC同樣。
• NTP Timestamp（Network time protocol）SR包發送時的絕對時間值。NTP的做用是同步不一樣的RTP媒體流。
• RTP Timestamp：與NTP時間戳對應，與RTP數據包中的RTP時間戳具備相同的單位和隨機初始值。
• Sender’s packet count：從開始發送包到產生這個SR包這段時間裏，發送者發送的RTP數據包的總數. SSRC改變時，這個域清零。
• Sender`s octet count：從開始發送包到產生這個SR包這段時間裏，發送者發送的淨荷數據的總字節數（不包括頭部和填充）。發送者改變其SSRC時，這個域要清零。
• 同步源n的SSRC標識符：該報告塊中包含的是從該源接收到的包的統計信息。
• 丟失率（Fraction Lost）：代表從上一個SR或RR包發出以來從同步源n(SSRC_n)來的RTP數據包的丟失率。
• 累計的包丟失數目：從開始接收到SSRC_n的包到發送SR,從SSRC_n傳過來的RTP數據包的丟失總數。
• 收到的擴展最大序列號：從SSRC_n收到的RTP數據包中最大的序列號，
• 接收抖動（Interarrival jitter）：RTP數據包接受時間的統計方差估計
• 上次SR時間戳（Last SR,LSR）：取最近從SSRC_n收到的SR包中的NTP時間戳的中間32比特。若是目前還沒收到SR包，則該域清零。
• 上次SR以來的延時（Delay since last SR,DLSR）：上次從SSRC_n收到SR包到發送本報告的延時。

 

其餘相關協議

實時流協議RTSP

　　實時流協議RTSP（Real-Time Streaming Protocol）是IETF提出的協議，對應的RFC文檔爲RFC2362。

　　RTSP是一個應用層協議（TCP/IP網絡體系中）。它以C/S模式工做，它是一個多媒體播放控制協議，主要用來使用戶在播放流媒體時能夠像操做本地的影碟機同樣進行控制，便可以對流媒體進行暫停/繼續、後退和前進等控制。

資源預約協議RSVP

　　資源預約協議RSVP(Resource Reservation Protocol)是IETF提出的協議，對應的RFC文檔爲RFC2208。

　　RSVP工做在IP層之上傳輸層之下，是一個網絡控制協議。RSVP經過在路由器上預留必定的帶寬，能在必定程度上爲流媒體的傳輸提供服務質量。在某些試驗性的系統如網絡視頻會議工具vic中就集成了RSVP。

 

 

 

 

參考：http://www.javashuo.com/article/p-xnpwwmyq-ch.html