-
實時傳送協議
鎖定
- 中文名稱
- 實時傳送協議
- 英文名稱
- real-time transport protocol;RTP
- 定 義
- 在因特網上，可用於一對一或一對多實時傳送多媒體數據流的協議。
- 應用學科
- 通信科技（一級學科），通信協議（二級學科）
以上內容由全國科學技術名詞審定委員會審定公佈
- 中文名
- 實時傳輸協議
- 外文名
- Real-time Transport Protocol
- 類 型
- 概念
- 簡 稱
- RTP
實時傳送協議協議簡介
RTP（real-time transport protocol），實時傳輸協議。RTP在多點傳送（多播）或單點傳送（單播）的網絡服務上，提供端對端的網絡傳輸功能，適合應用程序傳輸實時數據，如：音頻，視頻或者仿真數據。RTP沒有為實時服務提供資源預留的功能，也不能保證QoS（服務質量）。數據傳輸功能由一個控制協議（RTCP）來擴展，通過擴展，可以用一種方式對數據傳輸進行監測控制，該協議（RTCP）可以升級到大型的多點傳送（多播）網絡，並提供最小限度的控制和鑑別功能。RTP和RTCP被設計成和下面的傳輸層和網絡層無關。協議支持RTP標準的轉換器和混合器的使用。
舊版的RFC1889在線路里傳輸的數據包格式沒有改變，唯一的改變是使用協議的規則和控制算法。為了最小化傳輸，發送RTCP數據包時超過了設定的速率，而在這時，很多的參與者同時加入了一個會話，在這樣的情況下，一個新加入到（用於計算的可升級的）計時器算法中的元素是最大的改變
[1]
。
實時傳送協議協議格式
- 版本(V)：2比特此域定義了RTP的版本。此協議定義的版本是2。(值1被RTP草案版本使用，值0用在最初"vat"語音工具使用的協議中。)
- 填充(P)：1比特若填料比特被設置，則此包包含一到多個附加在末端的填充比特，填充比特不算作負載的一部分。填充的最後一個字節指明可以忽略多少個填充比特。填充可能用於某些具有固定長度的加密算法，或者用於在底層數據單元中傳輸多個RTP包。
- 擴展(X)：1比特若設置擴展比特，固定頭(僅)後面跟隨一個頭擴展。
- CSRC計數(CC)：4比特 CSRC計數包含了跟在固定頭後面CSRC識別符的數目。
- 標誌(M)：1比特標誌的解釋由具體協議規定。它用來允許在比特流中標記重要的事件，如幀邊界。
- 負載類型(PT)：7比特此域定義了負載的格式，由具體應用決定其解釋。協議可以規定負載類型碼和負載格式之間一個默認的匹配。其他的負載類型碼可以通過非RTP方法動態定義。RTP發送端在任意給定時間發出一個單獨的RTP負載類型；此域不用來複用不同的媒體流。
- 序列號（sequence number）：16比特每發送一個RTP數據包，序列號加1，接收端可以據此檢測丟包和重建包序列。序列號的初始值是隨機的(不可預測)，以使即便在源本身不加密時(有時包要通過翻譯器，它會這樣做)，對加密算法泛知的普通文本攻擊也會更加困難。
- 時間戳（timestamp） 32比特時間戳反映了RTP數據包中第一個字節的採樣時間。時鐘頻率依賴於負載數據格式，並在描述文件（profile）中進行描述。也可以通過RTP方法對負載格式動態描述。如果RTP包是週期性產生的，那麼將使用由採樣時鐘決定的名義上的採樣時刻，而不是讀取系統時間。例如，對一個固定速率的音頻，採樣時鐘將在每個週期內增加1。如果一個音頻從輸入設備中讀取含有160個採樣週期的塊，那麼對每個塊，時間戳的值增加160。時間戳的初始值應當是隨機的，就像序號一樣。幾個連續的RTP包如果是同時產生的。如：屬於同一個視頻幀的RTP包，將有相同的序列號。不同媒體流的RTP時間戳可能以不同的速率增長。而且會有獨立的隨機偏移量。因此，雖然這些時間戳足以重構一個單獨的流的時間，但直接比較不同的媒體流的時間戳不能進行同步。對於每一個媒體，我們把與採樣時刻相關聯的RTP時間戳與來自於參考時鐘上的時間戳（NTP）相關聯。因此參考時鐘的時間戳就了數據的採樣時間。（即：RTP時間戳可用來實現不同媒體流的同步，NTP時間戳解決了RTP時間戳有隨機偏移量的問題。）參考時鐘用於同步所有媒體的共同時間。這一時間戳對（RTP時間戳和NTP時間戳），用於判斷RTP時間戳和NTP時間戳的對應關係，以進行媒體流的同步。它們不是在每一個數據包中都被髮送，而在發送速率更低的RTCP的SR（發送者報告）中。如果傳輸的數據是存貯好的，而不是實時採樣等到的，那麼會使用從參考時鐘得到的虛的表示時間線（virtual presentation timeline）。以確定存貯數據中的每個媒體下一幀或下一個單元應該呈現的時間。此種情況下RTP時間戳反映了每一個單元應當回放的時間。真正的回放將由接收者決定。
- SSRC：32比特用以識別同步源。標識符被隨機生成，以使在同一個RTP會話期中沒有任何兩個同步源有相同的SSRC識別符。儘管多個源選擇同一個SSRC識別符的概率很低，所有RTP實現工具都必須準備檢測和解決衝突。若一個源改變本身的源傳輸地址，必須選擇新的SSRC識別符，以避免被當作一個環路源。
- CSRC列表：0到15項，每項32比特 CSRC列表識別在此包中負載的所有貢獻源。識別符的數目在CC域中給定。若有貢獻源多於15個，僅識別15個。CSRC識別符由混合器插入，並列出所有貢獻源的SSRC識別符。例如語音包，混合產生新包的所有源的SSRC標識符都被列出，以在接收端處正確指示參與者。
實時傳送協議RTP工作機制
當應用程序建立一個RTP會話時，應用程序將確定一對目的傳輸地址。目的傳輸地址由一個網絡地址和一對端口組成，有兩個端口：一個給RTP包，一個給RTCP包，使得RTP/RTCP數據能夠正確發送。RTP數據發向偶數的UDP端口，而對應的控制信號RTCP數據發向相鄰的奇數UDP端口（偶數的UDP端口+1），這樣就構成一個UDP端口對。 RTP的發送過程如下，接收過程則相反
[1]
。
1) RTP協議從上層接收流媒體信息碼流（如H.263），封裝成RTP數據包；RTCP從上層接收控制信息，封裝成RTCP控制包。
2)RTP將RTP數據包發往UDP端口對中偶數端口；RTCP將RTCP控制包發往UDP端口對中的接收端口。
實時傳送協議協議特點
RTP以一個控制協議（RTCP）結合它的數據傳送,使監測大型的多點網絡數據遞送成為可能。 監測允許接收器發現是否有任何的信息包丟失和為任何的延遲跳動補償。兩個協議獨立地在底部傳送層和網絡層協議工作。RTP 報頭的信息告訴接收器該如何重建數據而且描述 codec比特流是如何被打包的。通常，RTP在用户數據包協議（UDP）的頂端運行,雖然它能使用其他的傳送協議。會議開始協議（SIP）和 H.323 都使用 RTP
[3]
。
實時傳送協議協議簡單靈活
RTP協議相對來説比較簡單，比如説它的報頭固定部分只包含12字節（Byte），所以開銷很小，有利於提高傳輸效率。靈活性體現在把協議機制和控制策略的具體算法分開。協議本身只提供完成實時傳輸的機制，對控制策略的有效算法實現不做具體規定。開發者可以根據不同的應用環境，選擇實現效率較高的算法和合適的控制策略。
實時傳送協議協議獨立性
RTP最初設計的目的是Internet，但它更傾向於發展成為獨立於底層協議的傳輸協議。RTP一般建立在UDP協議之上，充分利用了UDP協議的的多路複用服務，它也可以建立在其他協議之上，像ATM、IPV6,、AAL5等，所以RTP協議具有很好的獨立性。
實時傳送協議同步機制
RTP協議採用時間戳（Timestamp）來控制單一媒體數據流的同步，但它本身並不能控制不同媒體數據流間的同步。如要實現不同數據流之間的同步，必須由應用程序參與完成。
實時傳送協議不可靠性
由於RTP協議設計的目的是傳輸實時數據，而不是可靠的數據，因此它不能提供有關錯誤檢測和報文順序檢測的機制。
實時傳送協議協議組成
RTP組成包括：一個序列數字，用來發現丟失的信息包；負載量確認, 描述特定的媒體編碼以便如果它必須適應帶寬的變化的時候，它能被改變；幀指示，為每個幀的開始和結束作標記；來源確認，識別幀的發送者；還有媒體本身同步，使用時間戳在單個流裏面發現不同的延遲跳動並且為它補償。
RTPC組成包括: 服務質量（QoS）反饋，包括丟失信息包的數量，來回旅程時間和跳動，所以來源能適當地調整他們的數據速率；會議控制，使用 RTCP BYE（再見）信息包允許叁加者顯示他們正在離開會議；確認，為其他參加者提供信息包括參加者的名字，電子郵件賬號和電話號碼；還有媒介物同步，使分離的聲音和視頻流能夠同步。
實時傳送協議協議用途
在RFC 2509中被指定的被壓縮的 RTP（CRTP），被髮展用來減少 IP、UDP 和RTP 報頭的大小。 然而，它被設計成以可靠和快速的點對點鏈接工作。在不是最佳的環境中，可能有長的延遲,信息包丟失和無序信息包，CRTP 在 通過IP網絡傳送話音（VoIP）應用上表現不佳。另外的一個改進，增強 CRPT（ECRPT），被定義在一個後來的英特網草案中以克服這個問題。
實時傳送協議簡單多播音頻會議
IETF的一個工作組開會討論最新協議草案時，使用Internet的IP多播服務來進行語音通訊。工作組中心分配到一個多播的組地址和一對端口。一個端口用於音頻數據，另一個端口用於控制（RTCP）數據包。該地址和端口信息發佈給預定的參與者。如果有私密性要求，對數據和控制包進行加密，這時就需要生成和發佈加密密鑰。分配和發佈機制的精確細節不在RTP的討論範圍之內。
每個與會者所使用的音頻會議應用程序，都以小塊形式（比方説持續20秒時間）來發送音頻數據。每個音頻數據塊都前導RTP報頭；RTP報頭和數據依次包含在UDP包裏。RTP報頭指明瞭各個包裏音頻編碼的類型（如PCM,ADPCM,LPC），這樣發送方可以在會議過程中改變編碼方式，以適應狀況的變化，例如，要加進一個低帶寬接入的參與者，或是要應付網絡擁塞。
Internet，像其他的報文分組網絡一樣，偶而會丟失和重排包，造成時長不等的延遲。為彌補這個不足，RTP報頭裏包含計時信息和一個序列號，允許接收方重建來自源的計時信息，比如前文例子中音頻塊以20s的間隔在揚聲器中連續播放。會議中，對每個RTP包的源,單獨地實施計時重建。序列號還被接收方用來評估丟失包數目。
由於會議期間不斷有工作組成員加入或離開，因此有必要知道任一時刻的實際參與者及他們接收音頻數據的狀況好壞。出於這個目的，會議中每個音頻應用程序的實例，都在RTCP（控制）端口上週期性地多播一個附加用户名的接收報告。接收報告指明瞭當前説話者被收聽到的狀況，可用於控制自適應性編碼。除了用户名外，通過控制帶寬限度，可以包含其他標識信息。一個站點在離開會議時發送RTCP BYE包
[1]
。
實時傳送協議音頻和視頻會議
一個會議如果同時使用音頻和視頻媒體，則二者傳輸時使用不同的RTP會話。也就是説，兩種媒體中RTP包和RTCP包的傳輸，是使用兩個不同的UDP端口對和（或）多播地址。在RTP層次，音頻和視頻會話沒有直接的耦合，下面這種情況除外：一個同時參加兩個會話的參與者，在兩個會話的RTCP包中，使用了相同的規範名，這樣兩個會話就發生關聯（耦合）了。這樣區隔開來的目的之一，是允許一些會議參與者只接受自己選擇的單一媒體（或者音頻，或者視頻）。儘管兩種媒體區分開來了，但通過兩個會話RTCP包內載有的計時信息，同源的音頻與視頻還是能夠同步回放
[1]
。
實時傳送協議混頻器和轉換器
到目前為止，我們皆假設所有站點都收到相同格式的媒體數據。然而這並不總是行得通。考慮一下這種情況，一個地方的參與者只能低速接入會議，而其他大部分參與者都能享受高速連接。與其讓強迫大家都忍受低帶寬，不如在只能低速接入的地方，放置一個減質量音頻編碼的RTP層次的中繼（稱作混頻器）。混頻器將重新同步輸入的音頻包，重建發送方產生的20ms固定間隔，混頻已重建過的音頻流為單一的流，轉換音頻編碼為低帶寬格式，最後通過低帶寬連接轉發數據包流（package stream）。這些包可能被單播到一個接收方，也可能多播到另一個的地址而發給多個接收方。RTP報頭為混頻器提供了一種方法，使其能辨識出對混頻後的包有用的源，從而保證提供給接收方正確的説話者指示。
在音頻會議中，一些預定參與者儘管有高帶寬連接，但不能通過IP多播直接接入會議。例如，他們可能位於一個不允許任何IP包通過的應用層防火牆後面。對這些站點，可能就不需要混頻，而需要另一種稱為轉換器的RTP層次中繼。可以在防火牆兩側分別安裝一個轉換器，外側轉換器將所有多播包通過安全連接轉入內側轉換器，內側轉換器再轉發給內部網的一個多播組（multicast group）。
混頻器和轉換器可以設計成用於各種目的。比如，一個視頻混頻器在測量多個不同視頻流中各人的單獨影像後，將它們組合成一個單一視頻流來模擬羣組場景。又如，在只用IP/UDP和只用ST_II的兩個主機羣之間通過轉換建立連接。再如，在沒有重新同步或混頻時，用packet-by-packet編碼轉換來自各個獨立源的視頻流
[1]
。
實時傳送協議分層編碼
為了匹配接收方的能力（容量）以及適應網絡擁塞，多媒體應用程序應當能夠調整其傳輸速率。許多應用實現把調適傳輸速率的責任放在源端。這種做法在多播傳輸中並不好，因為不同接收方對帶寬存在着衝突性需求。這經常導致最小公分母的場景，網格中最小的管道支配了全部實況多媒體“廣播”的質量和保真度。
相反地，可以把分層編碼和分層傳輸系統組合起來，從而把調適速率的責任放在接收端。在IP多播之上的RTP上下文中，對一個橫跨多個RTP會話（每個會話在獨自多播組上開展）的分級表示信號(hierarchically represented signal)，源能夠把它的分層（layers）分割成條。 接收方僅需合併適當的多播組子集，就能適應異種網絡和控制接收帶寬
[1]
。
- 參考資料
-
- 1. RFC3550 ．IETF[引用日期2016-11-29]
- 2. 基於RTP協議的視頻流媒體實時傳輸 ．中國知網[引用日期2016-11-29]
- 3. RTP協議的研究與實現 ．萬方數據庫[引用日期2016-11-29]
