流媒體傳輸協(xié)議系列之----RTP/RTCP協(xié)議解析

RTP協(xié)議

        實時傳輸協(xié)議RTP（Real-time Transport Protocol）是一個網(wǎng)絡(luò)傳輸協(xié)議，它是由IETF的多媒體傳輸工作小組1996年在RFC 1889中公布的，后在RFC3550中進行更新。

         國際電信聯(lián)盟ITU-T也發(fā)布了自己的RTP文檔，作為H.225.0，但是后來當IETF發(fā)布了關(guān)于它的穩(wěn)定的標準RFC后就被取消了。它作為因特網(wǎng)標準在 [ RFC 3550 ] 有詳細說明.

        RTP協(xié)議詳細說明了在互聯(lián)網(wǎng)上傳遞音頻和視頻的標準數(shù)據(jù)包格式。它一開始被設(shè)計為一個多播協(xié)議，但后來被用在很多單播應(yīng)用中。RTP協(xié)議常用于流媒體系統(tǒng)（配合RTSP協(xié)議），視頻會議和一鍵通（Push toTalk）系統(tǒng)（配合H.323或SIP），使它成為IP電話產(chǎn)業(yè)的技術(shù)基礎(chǔ)。RTP協(xié)議和RTP控制協(xié)議RTCP一起使用，而且它是建立在用戶數(shù)據(jù)報協(xié)議上的（UDP）。

        RTP廣泛應(yīng)用于流媒體相關(guān)的通訊和娛樂，包括電話、視頻會議、電視和基于網(wǎng)絡(luò)的一鍵通業(yè)務(wù)（類似對講機的通話）

RTP標準定義了兩個子協(xié)議 ，RTP和RTCP

數(shù)據(jù)傳輸協(xié)議RTP，用于實時傳輸數(shù)據(jù)。該協(xié)議提供的信息包括：時間戳（用于同步）、序列號（用于丟包和重排序檢測）、以及負載格式（用于說明數(shù)據(jù)的編碼格式）。

控制協(xié)議RTCP，用于QoS反饋和同步媒體流。相對于RTP來說，RTCP所占的帶寬非常小，通常只有5%。

為什么要使用RTP

        一提到流媒體傳輸、一談到什么視頻監(jiān)控、視頻會議、語音電話（VOIP），都離不開RTP協(xié)議的應(yīng)用，但當大家都根據(jù)經(jīng)驗或者別人的應(yīng)用而選擇RTP協(xié)議的時候，你可曾想過，為什么我們要使用RTP來進行流媒體的傳輸呢？為什么我們一定要用RTP？難道TCP、UDP或者其他的網(wǎng)絡(luò)協(xié)議不能達到我們的要求么？

        像TCP這樣的可靠傳輸協(xié)議，通過超時和重傳機制來保證傳輸數(shù)據(jù)流中的每一個bit的正確性，但這樣會使得無論從協(xié)議的實現(xiàn)還是傳輸?shù)倪^程都變得非常的復(fù)雜。而且，當傳輸過程中有數(shù)據(jù)丟失的時候，由于對數(shù)據(jù)丟失的檢測（超時檢測）和重傳，會數(shù)據(jù)流的傳輸被迫暫停和延時。

        或許你會說，我們可以利用客戶端構(gòu)造一個足夠大的緩沖區(qū)來保證顯示的正常，這種方法對于從網(wǎng)絡(luò)播放音視頻來說是可以接受的，但是對于一些需要實時交互的場合（如視頻聊天、視頻會議等），如果這種緩沖超過了200ms，將會產(chǎn)生難以接受的實時性體驗。

為什么RTP可以解決上述時延問題

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

RTP的協(xié)議層次

傳輸層的子層

圖 1給出了流媒體應(yīng)用中的一個典型的協(xié)議體系結(jié)構(gòu)。

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

RTP的工作機制為：

        當應(yīng)用程序建立一個RTP會話時，應(yīng)用程序?qū)⒋_定一對目的傳輸?shù)刂贰Ｄ康膫鬏數(shù)刂酚梢粋€網(wǎng)絡(luò)地址和一對端口組成，有兩個端口：一個給RTP包，一個給RTCP包，使得RTP/RTCP數(shù)據(jù)能夠正確發(fā)送。RTP數(shù)據(jù)發(fā)向偶數(shù)的UDP端口，而對應(yīng)的控制信號RTCP數(shù)據(jù)發(fā)向相鄰的奇數(shù)UDP端口（偶數(shù)的UDP端口＋1），這樣就構(gòu)成一個UDP端口對。 RTP的發(fā)送過程如下，接收過程則相反。

   1) RTP協(xié)議從上層接收流媒體信息碼流（如H.263），封裝成RTP數(shù)據(jù)包；RTCP從上層接收控制信息，封裝成RTCP控制包。

   2) RTP將RTP 數(shù)據(jù)包發(fā)往UDP端口對中偶數(shù)端口；RTCP將RTCP控制包發(fā)往UDP端口對中的奇數(shù)端口。

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

應(yīng)用層的一部分

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

RTP包頭中的流媒體特性

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

版本號（V）：2比特，用來標志使用的RTP版本。

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

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

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

標記位（M）： 1比特,該位的解釋由配置文檔（Profile）來承擔. 
載荷類型（PayloadType）： 7比特，標識了RTP載荷的類型。

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

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

同步源標識符(×××C)：32比特，同步源就是指RTP包流的來源。在同一個RTP會話中不能有兩個相同的×××C值。該標識符是隨機選取的 RFC1889推薦了MD5隨機算法。

貢獻源列表（CSRC List）：0～15項，每項32比特，用來標志對一個RTP混合器產(chǎn)生的新包有貢獻的所有RTP包的源。由混合器將這些有貢獻的×××C標識符插入表中?！痢痢罜標識符都被列出來，以便接收端能正確指出交談雙方的身份。

RTP擴展頭結(jié)構(gòu)

 
                         圖 Rtp擴展頭

        若 RTP 固定頭中的擴展比特位置 1（注意：如果有CSRC列表，則在CSRC列表之后），則一個長度可變的頭擴展部分被加到 RTP 固定頭之后。頭擴展包含 16 比特的長度域，指示擴展項中 32 比特字的個數(shù)，不包括 4 個字節(jié)擴展頭(因此零是有效值)。

        RTP 固定頭之后只允許有一個頭擴展。為允許多個互操作實現(xiàn)獨立生成不同的頭擴展，或某種特定實現(xiàn)有多種不同的頭擴展,擴展項的前 16 比特用以識別標識符或參數(shù)。這 16 比特的格式由具體實現(xiàn)的上層協(xié)議定義。基本的 RTP 說明并不定義任何頭擴展本身。

RTP的會話過程

        當應(yīng)用程序建立一個RTP會話時，應(yīng)用程序?qū)⒋_定一對目的傳輸?shù)刂贰Ｄ康膫鬏數(shù)刂酚梢粋€網(wǎng)絡(luò)地址和一對端口組成，有兩個端口：一個給RTP包，一個給RTCP包，使得RTP/RTCP數(shù)據(jù)能夠正確發(fā)送。RTP數(shù)據(jù)發(fā)向偶數(shù)的UDP端口，而對應(yīng)的控制信號RTCP數(shù)據(jù)發(fā)向相鄰的奇數(shù)UDP端口（偶數(shù)的UDP端口＋1），這樣就構(gòu)成一個UDP端口對。

RTP的發(fā)送過程如下，接收過程則相反。

1. RTP協(xié)議從上層接收流媒體信息碼流（如H.263），封裝成RTP數(shù)據(jù)包；RTCP從上層接收控制信息，封裝成RTCP控制包。

2. RTP將RTP 數(shù)據(jù)包發(fā)往UDP端口對中偶數(shù)端口；RTCP將RTCP控制包發(fā)往UDP端口對中的接收端口。

RTP的profile機制

        RTP為具體的應(yīng)用提供了非常大的靈活性，它將傳輸協(xié)議與具體的應(yīng)用環(huán)境、具體的控制策略分開，傳輸協(xié)議本身只提供完成實時傳輸?shù)臋C制，開發(fā)者可以根據(jù)不同的應(yīng)用環(huán)境，自主選擇合適的配置環(huán)境、以及合適的控制策略。

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

        對于上面說的合適的配置環(huán)境，主要是指RTP的相關(guān)配置和負載格式的定義。RTP協(xié)議為了廣泛地支持各種多媒體格式（如 H.264, MPEG-4, MJPEG, MPEG），沒有在協(xié)議中體現(xiàn)出具體的應(yīng)用配置，而是通過profile配置文件以及負載類型格式說明文件的形式來提供。對于任何一種特定的應(yīng)用，RTP定義了一個profile文件以及相關(guān)的負載格式說明，相關(guān)的文件如下所示：

《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

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

RTCP的封裝

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

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

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

        發(fā)送端報告分組SR（Sender Report）用來使發(fā)送端以多播方式向所有接收端報告發(fā)送情況。SR分組的主要內(nèi)容有：相應(yīng)的RTP流的×××C，RTP流中最新產(chǎn)生的RTP分組的時間戳和NTP，RTP流包含的分組數(shù)，RTP流包含的字節(jié)數(shù)。SR包的封裝如圖3所示。

版本（V）：同RTP包頭域。

填充（P）：同RTP包頭域。

接收報告計數(shù)器（RC）：5比特，該SR包中的接收報告塊的數(shù)目，可以為零。 
包類型（PT）：8比特，SR包是200。

長度域（Length）：16比特，其中存放的是該SR包以32比特為單位的總長度減一。

同步源（×××C）：SR包發(fā)送者的同步源標識符。與對應(yīng)RTP包中的×××C一樣。 
NTP Timestamp（Network time protocol）SR包發(fā)送時的絕對時間值。NTP的作用是同步不同的RTP媒體流。

RTP Timestamp：與NTP時間戳對應(yīng)，與RTP數(shù)據(jù)包中的RTP時間戳具有相同的單位和隨機初始值。

Sender’s packet count：從開始發(fā)送包到產(chǎn)生這個SR包這段時間里，發(fā)送者發(fā)送的RTP數(shù)據(jù)包的總數(shù). ×××C改變時，這個域清零。

Sender`s octet count：從開始發(fā)送包到產(chǎn)生這個SR包這段時間里，發(fā)送者發(fā)送的凈荷數(shù)據(jù)的總字節(jié)數(shù)（不包括頭部和填充）。發(fā)送者改變其×××C時，這個域要清零。

同步源n的×××C標識符：該報告塊中包含的是從該源接收到的包的統(tǒng)計信息。

丟失率（Fraction Lost）：表明從上一個SR或RR包發(fā)出以來從同步源n(×××C_n)來的RTP數(shù)據(jù)包的丟失率。

累計的包丟失數(shù)目：從開始接收到×××C_n的包到發(fā)送SR,從×××C_n傳過來的RTP數(shù)據(jù)包的丟失總數(shù)。

收到的擴展最大序列號：從×××C_n收到的RTP數(shù)據(jù)包中最大的序列號，

接收抖動（Interarrival jitter）：RTP數(shù)據(jù)包接受時間的統(tǒng)計方差估計 
上次SR時間戳（Last SR,LSR）：取最近從×××C_n收到的SR包中的NTP時間戳的中間32比特。如果目前還沒收到SR包，則該域清零。

上次SR以來的延時（Delay since last SR,DLSR）：上次從×××C_n收到SR包到發(fā)送本報告的延時。

附： 代碼描述

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

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;

掃描下方二維碼 關(guān)注