RTP協議

        實時傳輸協議RTP（Real-time Transport Protocol）是一個網路傳輸協議，它是由IETF的多媒體傳輸工作小組1996年在RFC 1889中公佈的，後在RFC3550中進行更新。

         國際電信聯盟ITU-T也釋出了自己的RTP文件，作為H.225.0，但是後來當IETF釋出了關於它的穩定的標準RFC後就被取消了。它作為因特網標準在 [ RFC 3550 ] 有詳細說明.

        RTP協議詳細說明了在網際網路上傳遞音訊和視訊的標準資料包格式。它一開始被設計為一個多播協議，但後來被用在很多單播應用中。RTP協議常用於流媒體系統（配合RTSP協議），視訊會議和一鍵通（Push toTalk）系統（配合H.323或SIP），使它成為IP電話產業的技術基礎。RTP協議和RTP控制協議RTCP一起使用，而且它是建立在使用者資料報協議上的（UDP）。

        RTP廣泛應用於流媒體相關的通訊和娛樂，包括電話、視訊會議、電視和基於網路的一鍵通業務（類似對講機的通話）

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的協議層次

傳輸層的子層

圖 1給出了流媒體應用中的一個典型的協議體系結構。

        從圖中可以看出，RTP被劃分在傳輸層，它建立在UDP上。同UDP協議一樣，為了實現其實時傳輸功能，RTP也有固定的封裝形式。RTP用來為端到端的實時傳輸提供時間資訊和流同步，但並不保證服務質量。服務質量由RTCP來提供。

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包頭中的流媒體特性

首先，我們看看RTP的包頭。 
RTP報文頭格式（見RFC3550 Page12）： 

版本號（V）：2位元，用來標誌使用的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 固定頭中的擴充套件位元位置 1（注意：如果有CSRC列表，則在CSRC列表之後），則一個長度可變的頭擴充套件部分被加到 RTP 固定頭之後。頭擴充套件包含 16 位元的長度域，指示擴充套件項中 32 位元字的個數，不包括 4 個位元組擴充套件頭(因此零是有效值)。

        RTP 固定頭之後只允許有一個頭擴充套件。為允許多個互操作實現獨立生成不同的頭擴充套件，或某種特定實現有多種不同的頭擴充套件,擴充套件項的前 16 位元用以識別識別符號或引數。這 16 位元的格式由具體實現的上層協議定義。基本的 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的profile機制

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

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

        對於上面說的合適的配置環境，主要是指RTP的相關配置和負載格式的定義。RTP協議為了廣泛地支援各種多媒體格式（如 H.264, MPEG-4, MJPEG, MPEG），沒有在協議中體現出具體的應用配置，而是通過profile配置檔案以及負載型別格式說明檔案的形式來提供。對於任何一種特定的應用，RTP定義了一個profile檔案以及相關的負載格式說明，相關的檔案如下所示：

《RTP Profile for Audio and Video Conferences with Minimal Control》（RFC3551）

《RTP Payload Format for H.264 Video》（RFC3984）

《RTP Payload Format for MPEG-4 Audio/Visual Streams》（RFC3016）

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

RTCP的封裝

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

        RTCP也是用UDP來傳送的，但RTCP封裝的僅僅是一些控制資訊，因而分組很短，所以可以將多個RTCP分組封裝在一個UDP包中。RTCP有如下五種分組型別。

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

        傳送端報告分組SR（Sender Report）用來使傳送端以多播方式向所有接收端報告發送情況。SR分組的主要內容有：相應的RTP流的SSRC，RTP流中最新產生的RTP分組的時間戳和NTP，RTP流包含的分組數，RTP流包含的位元組數。SR包的封裝如圖3所示。

版本（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包到傳送本報告的延時