協定簡介
RTP（real-time transport protocol），實時傳輸協定。RTP在多點傳送（多播）或單點傳送（單播）的網路服務上，提供端對端的網路傳輸功能，適合應用程式傳輸實時數據，如：音頻，視頻或者仿真數據。RTP沒有為實時服務提供資源預留的功能，也不能保證QoS（服務質量）。數據傳輸功能由一個控制協定（RTCP）來擴展，通過擴展，可以用一種方式對數據傳輸進行監測控制，該協定（RTCP）可以升級到大型的多點傳送（多播）網路，並提供最小限度的控制和鑑別功能。RTP和RTCP被設計成和下面的傳輸層和網路層無關。協定支持RTP標準的轉換器和混合器的使用。
舊版的RFC1889線上路里傳輸的數據包格式沒有改變，唯一的改變是使用協定的規則和控制算法。為了最小化傳輸，傳送RTCP數據包時超過了設定的速率，而在這時，很多的參與者同時加入了一個會話，在這樣的情況下，一個新加入到（用於計算的可升級的）計時器算法中的元素是最大的改變 。
協定格式
RTP協定格式RTP協定的報文格式如圖 ：
前12個位元組出現在每個RTP包中，僅僅在被混合器插入時，才出現CSRC識別符列表。這些域有以下意義 ：
•版本(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) RTP協定從上層接收流媒體信息碼流（如H.263），封裝成RTP數據包；RTCP從上層接收控制信息，封裝成RTCP控制包。
2)RTP將RTP數據包發往UDP連線埠對中偶數連線埠；RTCP將RTCP控制包發往UDP連線埠對中的接收連線埠。
協定特點
RTP以一個控制協定（RTCP）結合它的數據傳送,使監測大型的多點網路數據遞送成為可能。 監測允許接收器發現是否有任何的信息包丟失和為任何的延遲跳動補償。兩個協定獨立地在底部傳送層和網路層協定工作。RTP 報頭的信息告訴接收器該如何重建數據而且描述 codec比特流是如何被打包的。通常，RTP在用戶數據包協定（UDP）的頂端運行,雖然它能使用其他的傳送協定。會議開始協定（SIP）和 H.323 都使用 RTP 。
協定包括如下幾個特點 ：
協定簡單靈活
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包 。
音頻和視頻會議
一個會議如果同時使用音頻和視頻媒體，則二者傳輸時使用不同的RTP會話。也就是說，兩種媒體中RTP包和RTCP包的傳輸，是使用兩個不同的UDP連線埠對和（或）多播地址。在RTP層次，音頻和視頻會話沒有直接的耦合，下面這種情況除外：一個同時參加兩個會話的參與者，在兩個會話的RTCP包中，使用了相同的規範名，這樣兩個會話就發生關聯（耦合）了。這樣區隔開來的目的之一，是允許一些會議參與者只接受自己選擇的單一媒體（或者音頻，或者視頻）。儘管兩種媒體區分開來了，但通過兩個會話RTCP包內載有的計時信息，同源的音頻與視頻還是能夠同步回放 。
混頻器和轉換器
到目前為止，我們皆假設所有站點都收到相同格式的媒體數據。然而這並不總是行得通。考慮一下這種情況，一個地方的參與者只能低速接入會議，而其他大部分參與者都能享受高速連線。與其讓強迫大家都忍受低頻寬，不如在只能低速接入的地方，放置一個減質量音頻編碼的RTP層次的中繼（稱作混頻器）。混頻器將重新同步輸入的音頻包，重建傳送方產生的20ms固定間隔，混頻已重建過的音頻流為單一的流，轉換音頻編碼為低頻寬格式，最後通過低頻寬連線轉發數據包流（package stream)。這些包可能被單播到一個接收方，也可能多播到另一個的地址而發給多個接收方。RTP報頭為混頻器提供了一種方法，使其能辨識出對混頻後的包有用的源，從而保證提供給接收方正確的說話者指示。
在音頻會議中，一些預定參與者儘管有高頻寬連線，但不能通過IP多播直接接入會議。例如，他們可能位於一個不允許任何IP包通過的套用層防火牆後面。對這些站點，可能就不需要混頻，而需要另一種稱為轉換器的RTP層次中繼。可以在防火牆兩側分別安裝一個轉換器，外側轉換器將所有多播包通過安全連線轉入內側轉換器，內側轉換器再轉發給內部網的一個多播組（multicast group)。
混頻器和轉換器可以設計成用於各種目的。比如，一個視頻混頻器在測量多個不同視頻流中各人的單獨影像後，將它們組合成一個單一視頻流來模擬群組場景。又如，在只用IP/UDP和只用ST_II的兩個主機群之間通過轉換建立連線。再如，在沒有重新同步或混頻時，用packet-by-packet編碼轉換來自各個獨立源的視頻流 。
分層編碼
為了匹配接收方的能力（容量）以及適應網路擁塞，多媒體應用程式應當能夠調整其傳輸速率。許多套用實現把調適傳輸速率的責任放在源端。這種做法在多播傳輸中並不好，因為不同接收方對頻寬存在著衝突性需求。這經常導致最小公分母的場景，格線中最小的管道支配了全部實況多媒體“廣播”的質量和保真度。
相反地，可以把分層編碼和分層傳輸系統組合起來，從而把調適速率的責任放在接收端。在IP多播之上的RTP上下文中，對一個橫跨多個RTP會話（每個會話在獨自多播組上開展）的分級表示信號(hierarchically represented signal)，源能夠把它的分層（layers)分割成條。 接收方僅需合併適當的多播組子集，就能適應異種網路和控制接收頻寬 。
