一、 簡介

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

RTP標準定義了兩個子協議，RTP和RTCP

數據傳輸協議RTP，用于實時傳輸數據。該協議提供的信息包括：時間戳（用于同步）、序列號（用于丟包和重排序檢測）、以及負載格式（用于說明數據的編碼格式）。
控制協議RTCP，用于QoS反饋和同步媒體流。相對于RTP來說，RTCP所占的帶寬非常小，通常只有5%。

為什么要使用RTP？
一提到流媒體傳輸、一談到什么視頻監控、視頻會議、語音電話（VOIP），都離不開RTP協議的應用，但當大家都根據經驗或者別人的應用而選擇RTP協議的時候，你可曾想過，為什么我們要使用RTP來進行流媒體的傳輸呢？為什么我們一定要用RTP？難道TCP、UDP或者其他的網絡協議不能達到我們的要求么？
像TCP這樣的可靠傳輸協議，通過超時和重傳機制來保證傳輸數據流中的每一個bit的正確性，但這樣會使得無論從協議的實現還是傳輸的過程都變得非常的復雜。而且，當傳輸過程中有數據丟失的時候，由于對數據丟失的檢測（超時檢測）和重傳，會數據流的傳輸被迫暫停和延時。
或許你會說，我們可以利用客戶端構造一個足夠大的緩沖區來保證顯示的正常，這種方法對于從網絡播放音視頻來說是可以接受的，但是對于一些需要實時交互的場合（如視頻聊天、視頻會議等），如果這種緩沖超過了200ms，將會產生難以接受的實時性體驗。

那為什么RTP可以解決上述問題呢？
RTP協議是一種基于UDP的傳輸協議，RTP本身并不能為按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。這樣，對于那些丟失的數據包，不存在由于超時檢測而帶來的延時，同時，對于那些丟棄的包，也可以由上層根據其重要性來選擇性的重傳。比如，對于I幀、P幀、B幀數據，由于其重要性依次降低，故在網絡狀況不好的情況下，可以考慮在B幀丟失甚至P幀丟失的情況下不進行重傳，這樣，在客戶端方面，雖然可能會有短暫的不清晰畫面，但卻保證了實時性的體驗和要求。

二、RTP解析

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分組只包含RTP數據，而控制是由RTCP協議提供。RTP在1025到65535之間選擇一個未使用的偶數UDP端口號，而在同一次會話中的RTCP則使用下一個奇數UDP端口號。端口號5004和5005分別用作RTP和RTCP的默認端口號。RTP分組的首部格式如圖2所示，其中前12個字節是必須的。

應用層的一部分

從應用開發者的角度看，RTP 應當是應用層的一部分。在應用的發送端，開發者必須編寫用 RTP 封裝分組的程序代碼，然后把 RTP 分組交給 UDP 插口接口。在接收端，RTP 分組通過 UDP 插口接口進入應用層后，還要利用開發者編寫的程序代碼從 RTP 分組中把應用數據塊提取出來。

RTP報文頭的內容

填充位（P）：1比特，如果該位置位，則該RTP包的尾部就包含附加的填充字節。

擴展位（X）： 1比特，如果該位置位的話，RTP固定頭部后面就跟有一個擴展頭部。

CSRC計數器（CC）：4比特，含有固定頭部后面跟著的CSRC的數目。

標記位（M）： 1比特,該位的解釋由配置文檔（Profile）來承擔.

載荷類型（PayloadType）： 7比特，標識了RTP載荷的類型。

序列號（SN）：16比特，每發送一個 RTP 數據包，序列號增加1。接收端可以據此檢測丟包和重建包序列。

時間戳(Timestamp): 2比特，記錄了該包中數據的第一個字節的采樣時刻。在一次會話開始時，時間戳初始化成一個初始值。即使在沒有信號發送時，時間戳的數值也要隨時間而不斷地增加（時間在流逝嘛）。時鐘頻率依賴于負載數據格式，并在描述文件（profile）中進行描述。

同步源標識符(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端口對中的接收端口。

RTP的profile機制

RTP為具體的應用提供了非常大的靈活性，它將傳輸協議與具體的應用環境、具體的控制策略分開，傳輸協議本身只提供完成實時傳輸的機制，開發者可以根據不同的應用環境，自主選擇合適的配置環境、以及合適的控制策略。

這里所說的控制策略指的是你可以根據自己特定的應用需求，來實現特定的一些RTCP控制算法，比如前面提到的丟包的檢測算法、丟包的重傳策略、一些視頻會議應用中的控制方案等等（這些策略我可能將在后續的文章中進行描述）。

對于上面說的合適的配置環境，主要是指RTP的相關配置和負載格式的定義。RTP協議為了廣泛地支持各種多媒體格式（如 H.264, MPEG-4, MJPEG, MPEG），沒有在協議中體現出具體的應用配置，而是通過profile配置文件以及負載類型格式說明文件的形式來提供。

說明：如果應用程序不使用專有的方案來提供有效載荷類型(payload type)、順序號或者時間戳，而是使用標準的RTP協議，應用程序就更容易與其他的網絡應用程序配合運行，這是大家都希望的事情。例如，如果有兩個不同的公司都在開發因特網電話軟件，他們都把RTP合并到他們的產品中，這樣就有希望：使用不同公司電話軟件的用戶之間能夠進行通信。

RTCP的封裝

RTCP的主要功能：服務質量的監視與反饋、媒體間的同步，以及多播組中成員的標識。在RTP會話期 間，各參與者周期性地傳送RTCP包。RTCP包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料，因此，各參與者可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的實時數據。

RTCP也是用UDP來傳送的，但RTCP封裝的僅僅是一些控制信息，因而分組很短，所以可以將多個RTCP分組封裝在一個UDP包中。

根據所攜帶的控制信息不同RTCP信息包可分為RR（接收者報告包）、SR（源報告包）、SEDS（源描述包）、BYE（離開申明）和APP（特殊應用包）五類5類：

RTCP傳輸間隔

由于RTP設計成允許應用自動擴展，可從幾個人的小規模系統擴展成上千人的大規模系統。由于每個對話成員定期發送RTCP信息包，隨著參加者不斷增加，RTCP信息包頻繁發送將占用過多的網絡資源，為了防止擁塞，必須限制RTCP信息包的流量，控制信息所占帶寬一般不超過可用帶寬的 5%，因此就需要調整 RTCP包的發送速率。由于任意兩個RTP終端之間都互發 RTCP包，因此終端的總數很容易估計出來，應用程序根據參加者總數就可以調整RTCP包的發送速率

RTP/RTCP的不足之處

RTP與RTCP相結合雖然保證了實時數據的傳輸，但也有自己的缺點。最顯著的是當有許多用戶一起加入會話進程的時候，由于每個參與者都周期發送RTCP信息包，導致RTCP包泛濫(flooding)。

參考自 RTP與RTCP協議詳解 開源中國