EasyDarwin開源社區流媒體視頻課程：流媒體傳輸控制通訊協定(RTSP RTP SDP)詳解之RTP

標籤：

視頻課程及相關文檔代碼地址：https://github.com/EasyDarwin/Course#course-3

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和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擴充頭結構

           圖 4 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）

等等，想瞭解更多可以點擊這裡：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流的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包到發送本報告的延時。

附： 代碼描述 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 ssrc;             /* synchronization source */    u_int32 csrc[1];          /* optional CSRC list */} rtp_hdr_t;

RTCP 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;

擷取更多資訊

郵件：[email protected]

WEB：www.EasyDarwin.org

Copyright ? EasyDarwin.org 2012-2016

EasyDarwin開源社區流媒體視頻課程：流媒體傳輸控制通訊協定(RTSP RTP SDP)詳解之RTP