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）中進行描述。
同步源標識符(***C)：32比特，同步源就是指RTP包流的來源。在同一個RTP會話中不能有兩個相同的***C值。該標識符是隨機選取的 RFC1889推薦了MD5隨機算法。
貢獻源列表（CSRC List）：0～15項，每項32比特，用來標誌對一個RTP混合器產生的新包有貢獻的所有RTP包的源。由混合器將這些有貢獻的***C標識符插入表中。***C標識符都被列出來，以便接收端能正確指出交談雙方的身份。
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的發送過程如下，接收過程則相反。
RTP協議從上層接收流媒體信息碼流（如H.263），封裝成RTP數據包；RTCP從上層接收控制信息，封裝成RTCP控制包。
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）
等等，想了解更多可以點擊這裏：http://en.wikipedia.org/wiki/RTP_audio_video_profile
說明：如果應用程序不使用專有的方案來提供有效載荷類型(payload type)、順序號或者時間戳，而是使用標準的RTP協議，應用程序就更容易與其他的網絡應用程序配合運行，這是大家都希望的事情。例如，如果有兩個不同的公司都在開發因特網電話軟件，他們都把RTP合併到他們的產品中，這樣就有希望：使用不同公司電話軟件的用戶之間能夠進行通信。
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 | 特定應用 |
上述五種分組的封裝大同小異，下面只講述SR類型，而其它類型請參考RFC3550。
發送端報告分組SR（Sender Report）用來使發送端以多播方式向所有接收端報告發送情況。SR分組的主要內容有：相應的RTP流的***C，RTP流中最新產生的RTP分組的時間戳和NTP，RTP流包含的分組數，RTP流包含的字節數。SR包的封裝如圖3所示。
版本（V）：同RTP包頭域。
填充（P）：同RTP包頭域。
接收報告計數器（RC）：5比特，該SR包中的接收報告塊的數目，可以爲零。
包類型（PT）：8比特，SR包是200。
長度域（Length）：16比特，其中存放的是該SR包以32比特爲單位的總長度減一。
同步源（***C）：SR包發送者的同步源標識符。與對應RTP包中的***C一樣。
NTP Timestamp（Network time protocol）SR包發送時的絕對時間值。NTP的作用是同步不同的RTP媒體流。
RTP Timestamp：與NTP時間戳對應，與RTP數據包中的RTP時間戳具有相同的單位和隨機初始值。
Sender’s packet count：從開始發送包到產生這個SR包這段時間裏，發送者發送的RTP數據包的總數. ***C改變時，這個域清零。
Sender`s octet count：從開始發送包到產生這個SR包這段時間裏，發送者發送的淨荷數據的總字節數（不包括頭部和填充）。發送者改變其***C時，這個域要清零。
同步源n的***C標識符：該報告塊中包含的是從該源接收到的包的統計信息。
丟失率（Fraction Lost）：表明從上一個SR或RR包發出以來從同步源n(***C_n)來的RTP數據包的丟失率。
累計的包丟失數目：從開始接收到***C_n的包到發送SR,從***C_n傳過來的RTP數據包的丟失總數。
收到的擴展最大序列號：從***C_n收到的RTP數據包中最大的序列號，
接收抖動（Interarrival jitter）：RTP數據包接受時間的統計方差估計
上次SR時間戳（Last SR,LSR）：取最近從***C_n收到的SR包中的NTP時間戳的中間32比特。如果目前還沒收到SR包，則該域清零。
上次SR以來的延時（Delay since last SR,DLSR）：上次從***C_n收到SR包到發送本報告的延時。
附： 代碼描述
RTP header :
/*
* RTP header
*/typedef struct {#if 0 //BIG_ENDIA
unsigned int version:2; /* protocol version */
unsigned int p:1; /* padding flag */
unsigned int x:1; /* header extension flag */
unsigned int cc:4; /* CSRC count */
unsigned int m:1; /* marker bit */
unsigned int pt:7; /* payload type */
unsigned int seq:16; /* sequence number */#else
unsigned int cc:4; /* CSRC count */
unsigned int x:1; /* header extension flag */
unsigned int p:1; /* padding flag */
unsigned int version:2; /* protocol version */
unsigned int pt:7; /* payload type */
unsigned int m:1; /* marker bit */
unsigned int seq:16; /* sequence number */#endif
u_int32 ts; /* timestamp */
u_int32 ***c; /* synchronization source */
u_int32 csrc[1]; /* optional CSRC list */} rtp_hdr_t;1234567891011121314151617181920212223242526272829RTCP Common header :
/*
* RTCP common header word
*/typedef struct {#if 0 //BIG_ENDIA
unsigned int version:2; /* protocol version */
unsigned int p:1; /* padding flag */
unsigned int count:5; /* varies by packet type */#else
unsigned int count:5; /* varies by packet type */
unsigned int p:1; /* padding flag */
unsigned int version:2; /* protocol version */#endif
unsigned int pt:8; /* RTCP packet type */
unsigned short length; /* pkt len in words, w/o this word */} rtcp_common_t;掃描下方二維碼 關注
