1 RTP報(bào)文格式
2 基于RTP的帶寬控制方法
1. 接收端的控制策略
2. 發(fā)送端的控制策略
RTP（Real-time Transport Protocol）是由IETF開(kāi)發(fā)的實(shí)時(shí)傳輸協(xié)議，可以在面向連接或無(wú)連接的下層協(xié)議上工作，通常和UDP協(xié)議一起使用。RTP的工作機(jī)理與RSVP不同，主要實(shí)現(xiàn)一種端到端的多媒體流同步控制機(jī)制，既不需要事先建立連接，也不需要中間節(jié)點(diǎn)的參與，為其保留資源。在網(wǎng)絡(luò)帶寬充足的情況下，RTP具有一定的帶寬調(diào)控能力，保證端到端的多媒體流同步。在網(wǎng)絡(luò)帶寬不足時(shí)，RTP的帶寬調(diào)控能力將受到一定的限制。ITU(國(guó)際電信聯(lián)合會(huì))的視頻會(huì)議標(biāo)準(zhǔn) H.323采用了RTP協(xié)議。
RTP定義了兩種報(bào)文：RTP報(bào)文和RTCP報(bào)文，RTP報(bào)文用于傳送媒體數(shù)據(jù)（如音頻和視頻），它由 RTP報(bào)頭和數(shù)據(jù)兩部分組成，RTP數(shù)據(jù)部分稱(chēng)為有效載荷(payload)；RTCP報(bào)文用于傳送控制信息，以實(shí)現(xiàn)協(xié)議控制功能。RTP報(bào)文和RTCP 報(bào)文將作為下層協(xié)議的數(shù)據(jù)單元進(jìn)行傳輸。如果使用UDP，則RTP報(bào)文和RTCP報(bào)文分別使用兩個(gè)相鄰的UDP端口，RTP報(bào)文使用低端口，RTCP報(bào)文使用高端口。如果使用其它的下層協(xié)議，RTP報(bào)文和RTCP報(bào)文可以合并，放在一個(gè)數(shù)據(jù)單元中一起傳送，控制信息在前，媒體數(shù)據(jù)在后。通常，RTP是由應(yīng)用程序?qū)崿F(xiàn)的。
1 RTP報(bào)文格式
RTP報(bào)文由兩部分組成：報(bào)頭和有效載荷。RTP報(bào)頭格式如下圖所示，其中：
·V：RTP協(xié)議的版本號(hào)，占2位，當(dāng)前協(xié)議版本號(hào)為2。
·P：填充標(biāo)志，占1位，如果P=1，則在該報(bào)文的尾部將填充一個(gè)或多個(gè)額外的八位組，它們不是有效載荷的一部分。
·X：擴(kuò)展標(biāo)志，占1位，如果X=1，則在RTP報(bào)頭后跟有一個(gè)擴(kuò)展報(bào)頭。
·CC：CSRC計(jì)數(shù)器，占 4位，指示CSRC 標(biāo)識(shí)符的個(gè)數(shù)。
·M: 標(biāo)記，占1位，不同的有效載荷有不同的含義，對(duì)于視頻，標(biāo)記一幀的結(jié)束；對(duì)于音頻，標(biāo)記會(huì)話的開(kāi)始。
·PT: 有效載荷類(lèi)型，占7位，用于說(shuō)明RTP報(bào)文中有效載荷的類(lèi)型，如GSM音頻、JPEM圖像等。
·序列號(hào)：占16位，用于標(biāo)識(shí)發(fā)送者所發(fā)送的RTP報(bào)文的序列號(hào)，每發(fā)送一個(gè)報(bào)文，序列號(hào)增1。接收者通過(guò)序列號(hào)來(lái)檢測(cè)報(bào)文丟失情況，重新排序報(bào)文，恢復(fù)數(shù)據(jù)。
·時(shí)戳 (Timestamp)：占32位，時(shí)戳反映了該RTP報(bào)文的第一個(gè)八位組的采樣時(shí)刻。接收者使用時(shí)戳來(lái)計(jì)算延遲和延遲抖動(dòng)，并進(jìn)行同步控制。
·同步信源(SSRC)標(biāo)識(shí)符：占32位，用于標(biāo)識(shí)同步信源。該標(biāo)識(shí)符是隨機(jī)選擇的，參加同一視頻會(huì)議的兩個(gè)同步信源不能有相同的SSRC。
·特約信源(CSRC)標(biāo)識(shí)符：每個(gè)CSRC標(biāo)識(shí)符占32位，可以有0～15個(gè)。每個(gè)CSRC標(biāo)識(shí)了包含在該RTP報(bào)文有效載荷中的所有特約信源。
這里的同步信源是指產(chǎn)生媒體流的信源，它通過(guò)RTP報(bào)頭中的一個(gè)32位數(shù)字SSRC標(biāo)識(shí)符來(lái)標(biāo)識(shí)，而不依賴(lài)于網(wǎng)絡(luò)地址，接收者將根據(jù)SSRC標(biāo)識(shí)符來(lái)區(qū)分不同的信源，進(jìn)行RTP報(bào)文的分組。特約信源是指當(dāng)混合器接收到一個(gè)或多個(gè)同步信源的RTP報(bào)文后，經(jīng)過(guò)混合處理產(chǎn)生一個(gè)新的組合RTP報(bào)文，并把混合器作為組合RTP報(bào)文的 SSRC，而將原來(lái)所有的SSRC都作為CSRC傳送給接收者，使接收者知道組成組合報(bào)文的各個(gè)SSRC。
在發(fā)送端，上層應(yīng)用程序以分組形式將編碼后的媒體數(shù)據(jù)傳給RTP通信模塊，作為RTP報(bào)文的有效載荷，RTP通信模塊將根據(jù)上層應(yīng)用提供的參數(shù)在有效載荷前添加RTP報(bào)頭，形成 RTP報(bào)文，通過(guò)Socket接口選擇UDP協(xié)議發(fā)送出去。
在接收端，RTP通信模塊通過(guò)Socket接口接收到RTP報(bào)文后，將RTP報(bào)頭分離出來(lái)作相應(yīng)處理，再將RTP報(bào)文的有效載荷作為數(shù)據(jù)分組傳遞給上層應(yīng)用。
考慮到在Internet這種復(fù)雜的環(huán)境中舉行視頻會(huì)議，RTP定義了兩種中間系統(tǒng)：混合器(Mixer)和轉(zhuǎn)換器(Translator)。
在Internet上舉行視頻會(huì)議時(shí)，可能有少數(shù)參加者通過(guò)低速鏈路與使用高速網(wǎng)絡(luò)的多數(shù)參加者相連接。為了不強(qiáng)制所有會(huì)議參加者都使用低帶寬和低質(zhì)量的數(shù)據(jù)編碼，RTP允許在低帶寬區(qū)域附近使用混合器作為RTP級(jí)中繼器?；旌掀鲝囊粋€(gè)或多個(gè)信源接收RTP 報(bào)文，對(duì)到達(dá)的數(shù)據(jù)報(bào)文進(jìn)行重新同步和重新組合，這些重組的數(shù)據(jù)流被混合成一個(gè)數(shù)據(jù)流，將數(shù)據(jù)編碼轉(zhuǎn)化為在低帶寬上可用的類(lèi)型，并通過(guò)低速鏈路向低帶寬區(qū)域轉(zhuǎn)發(fā)。為了對(duì)多個(gè)輸入信源進(jìn)行統(tǒng)一的同步，混合器在多個(gè)媒體流之間進(jìn)行定時(shí)調(diào)整，產(chǎn)生它自己的定時(shí)同步，因此所有從混合器輸出的報(bào)文都把混合器作為同步信源。為了保證接收者能夠正確識(shí)別混合器處理前的原始報(bào)文發(fā)送者，混合器在RTP報(bào)頭中設(shè)置了CSRC標(biāo)識(shí)符隊(duì)列，以標(biāo)識(shí)那些產(chǎn)生混和報(bào)文的原始同步信源。
在Internet環(huán)境中，一些會(huì)議的參加者可能被隔離在應(yīng)用級(jí)防火墻的外面，這些參加者被禁止直接使用 IP組播地址進(jìn)行訪問(wèn)，雖然他們可能是通過(guò)高速鏈路連接的。在這些情況下，RTP允許使用轉(zhuǎn)換器作為RTP級(jí)中繼器。在防火墻兩端分別安裝一個(gè)轉(zhuǎn)換器，防火墻之外的轉(zhuǎn)換器過(guò)濾所有接收到的組播報(bào)文，并通過(guò)一條安全的連接傳送給防火墻之內(nèi)的轉(zhuǎn)換器，內(nèi)部轉(zhuǎn)換器將這些組播報(bào)文再轉(zhuǎn)發(fā)送給內(nèi)部網(wǎng)絡(luò)中的組播組成員。
2 基于RTP的帶寬控制方法 為了實(shí)時(shí)傳輸數(shù)據(jù)，RTP利用了簡(jiǎn)單而快捷的UDP協(xié)議實(shí)現(xiàn)網(wǎng)絡(luò)傳輸。由于UDP協(xié)議是一種無(wú)連接傳輸協(xié)議，不保證報(bào)文傳輸?shù)恼_性和有序性，也不提供流量控制功能。另一方面，在多媒體通信中，由于多媒體數(shù)據(jù)的特殊性，不宜采用通常的重傳糾錯(cuò)法來(lái)提供正確性，而是采用控制傳送帶寬方式來(lái)減少報(bào)文丟失，以滿(mǎn)足多媒體應(yīng)用所需的QoS。 在RTP協(xié)議中，通過(guò) RTCP報(bào)文提供了基于無(wú)連接傳輸協(xié)議的端到端控制機(jī)制，這是一種基于接收者反饋的網(wǎng)絡(luò)傳輸QoS監(jiān)測(cè)機(jī)制，在RTCP的接收?qǐng)?bào)告中包含了當(dāng)前網(wǎng)絡(luò)傳輸 QoS有關(guān)信息，如報(bào)文丟失率、報(bào)文丟失累計(jì)、接收到的最高序列號(hào)、平均延遲抖動(dòng)以及用于計(jì)算發(fā)布接收?qǐng)?bào)告往返所需時(shí)間的時(shí)間標(biāo)簽等。發(fā)送者可通過(guò)這些信息監(jiān)測(cè)和評(píng)價(jià)網(wǎng)絡(luò)傳輸QoS狀況，并可采取適當(dāng)?shù)牟呗詫?shí)施同步控制。
RTP協(xié)議規(guī)定，每個(gè)RTP 系統(tǒng)必須實(shí)現(xiàn)RTCP的控制功能，由內(nèi)部功能模塊定期自動(dòng)執(zhí)行。RTCP報(bào)文是輕載信息，其信息量與最低的數(shù)據(jù)通信量相平衡，它所產(chǎn)生的通信量只是數(shù)據(jù)通信量的5%左右。 要實(shí)施端到端的強(qiáng)制同步控制，其前提條件是發(fā)送端要能夠獲取網(wǎng)絡(luò)失調(diào)狀態(tài)信息。一種可行的同步控制策略是：各個(gè)接收端將一種輕載的網(wǎng)絡(luò)失調(diào)狀態(tài)信息（如 QoS參數(shù)狀態(tài)）反饋給發(fā)送端，發(fā)送端據(jù)此進(jìn)行強(qiáng)制性同步控制，以滿(mǎn)足接收端演示質(zhì)量的要求。
基于RTP的帶寬控制算法正是利用這種控制策略來(lái)實(shí)施強(qiáng)制性同步控制的，其基本思想是在RTP協(xié)議機(jī)制支持下，發(fā)送端通過(guò)接收端周期反饋的接收?qǐng)?bào)告來(lái)評(píng)價(jià)當(dāng)前網(wǎng)絡(luò)傳輸?shù)腝oS，并以此對(duì)數(shù)據(jù)發(fā)送速率進(jìn)行適當(dāng)調(diào)整。端點(diǎn)之間利用RTP報(bào)文和RTCP報(bào)文來(lái)實(shí)現(xiàn)帶寬控制：
(1) RTP報(bào)文的序號(hào)字段可用于排序RTP報(bào)文分組，以消除重復(fù)分組，保持視頻或音頻流內(nèi)同步和連續(xù)地播放。 (2)RTP報(bào)文的時(shí)戳字段可作為流間同步標(biāo)識(shí)，以保持視頻和音頻流間同步和連續(xù)地播放。
(3) 發(fā)送者可利用接收者反饋的RTCP報(bào)文來(lái)制實(shí)施端到端的強(qiáng)制性同步控制，以改善當(dāng)前網(wǎng)絡(luò)傳輸?shù)腝oS。
2.1.接收端的控制策略
接收端通過(guò)RTP協(xié)議實(shí)施如下的控制策略：
①SSRC字段用于標(biāo)識(shí)不同的信源，以支持多對(duì)一或多對(duì)多的多媒體通信。 ②時(shí)戳字段作為流間同步標(biāo)識(shí)，用于媒體流間的流間控制，以保持視頻和音頻流間同步和連續(xù)地播放，并作為時(shí)間量用于計(jì)算報(bào)文分組的傳輸延時(shí)、延時(shí)抖動(dòng)以及數(shù)據(jù)更新周期等，濾除嚴(yán)重延時(shí)的RTP報(bào)文分組。
③序號(hào)字段作為流內(nèi)同步標(biāo)識(shí)，用于排序RTP報(bào)文分組，消除重復(fù)報(bào)文分組，保持視頻或音頻流內(nèi)同步和連續(xù)地播放。 ④將接收端檢測(cè)到的當(dāng)前網(wǎng)絡(luò) QoS狀況通過(guò)RTCP的接收?qǐng)?bào)告周期地反饋給發(fā)送端。
2.2.發(fā)送端的控制策略
發(fā)送端將采用如下的控制算法來(lái)調(diào)整傳送帶寬。
①設(shè)bs為發(fā)送端當(dāng)前的帶寬，bmin和bmax分別為應(yīng)用所設(shè)置的最小帶寬和最大帶寬，且bs?[bmin，bmax]。 ②在每個(gè)發(fā)送帶寬級(jí)上保持一個(gè)時(shí)間片，超時(shí)后將根據(jù)網(wǎng)絡(luò)QoS狀況提高或降低一個(gè)帶寬級(jí)，以避免帶寬頻繁波動(dòng)。這里使用報(bào)文丟失率作為QoS指示器，并設(shè)置一個(gè)閾值。如果QoS指示器超閾，說(shuō)明網(wǎng)絡(luò)發(fā)生阻塞，通過(guò)改變發(fā)送速率來(lái)調(diào)整傳送帶寬，疏導(dǎo)網(wǎng)絡(luò)交通。
③初始時(shí)按最大帶寬發(fā)送報(bào)文分組，即bs?bmax，以提高網(wǎng)絡(luò)通道的利用率。
④如果在規(guī)定的時(shí)間片內(nèi) QoS指示器超閾，說(shuō)明網(wǎng)絡(luò)發(fā)生阻塞，則在超時(shí)后需要降低一個(gè)帶寬級(jí)，即bs? max { bs-μ, bmin }，其中μ為比例因子。 ⑤如果在規(guī)定的時(shí)間片內(nèi) QoS指示器未超閾，說(shuō)明網(wǎng)絡(luò)交通狀況良好，則在超時(shí)后應(yīng)當(dāng)提高一個(gè)帶寬級(jí)，即bs? min { bs+μ, bmax }。
⑥在點(diǎn)到多點(diǎn)通信場(chǎng)合中，發(fā)送者將面對(duì)多個(gè)不同網(wǎng)段上的接收者，而每個(gè)網(wǎng)段的交通狀況又不盡相同。因此，在改變帶寬時(shí)可采用多數(shù)表決法，即當(dāng)報(bào)文丟失率超閾的接收者超過(guò)一定比例時(shí)再改變帶寬。
這種方法的特點(diǎn)是：利用 RTP協(xié)議機(jī)制來(lái)傳送網(wǎng)絡(luò)狀態(tài)信息，不需要另外構(gòu)造網(wǎng)絡(luò)檢測(cè)機(jī)構(gòu)，易于實(shí)現(xiàn)；RTCP報(bào)文是一種輕載報(bào)文，占用較少的通信帶寬。
RTP與RTCP協(xié)議介紹
1．流媒體( Streaming Media)
1.1流媒體概念
流媒體技術(shù)是網(wǎng)絡(luò)技術(shù)和多媒體技術(shù)發(fā)展到一定階段的產(chǎn)物。術(shù)語(yǔ)流媒體既可以指在網(wǎng)上傳輸連續(xù)時(shí)基媒體的流式技術(shù),也可以指使用流式技術(shù)的連續(xù)時(shí)基媒體本身。在網(wǎng)上傳輸音頻、視頻等多媒體信息目前主要有兩種方式:下載和流式傳輸。采用下載方式,用戶(hù)需要先下載整個(gè)媒體文件,然后才能進(jìn)行播放。由于網(wǎng)絡(luò)帶寬的限制,下載常常要花很長(zhǎng)時(shí)間,所以這種處理方式延遲很大。而流媒體實(shí)現(xiàn)的關(guān)鍵技術(shù)是流式傳輸。傳輸之前首先對(duì)多媒體進(jìn)行預(yù)處理(降低質(zhì)量和高效壓縮) ,然后使用緩存系統(tǒng)來(lái)保證數(shù)據(jù)連續(xù)正確地進(jìn)行傳輸。使用流式傳輸方式,用戶(hù)不必像采用下載方式那樣要等到整個(gè)文件全部下載完畢,而是只需經(jīng)過(guò)幾秒到幾十秒的啟動(dòng)延時(shí)即可在客戶(hù)端進(jìn)行播放和觀看。此時(shí)媒體文件的剩余部分將在后臺(tái)繼續(xù)下載。與單純的下載方式相比,這種對(duì)多媒體文件邊下載邊播放的流式傳輸方式不僅使啟動(dòng)延時(shí)大幅度地縮短,而且對(duì)系統(tǒng)緩存容量的需求也大大降低。使用流式傳輸?shù)牧硪粋€(gè)好處是使傳輸那些事先不知道或無(wú)法知道大小的媒體數(shù)據(jù)(如網(wǎng)上直播、視頻會(huì)議等) 成為可能。
到目前為止,Internet 上使用較多的流式視頻格式主要有以下三種:RealNetworks 公司的RealMedia ,Apple 公司的QuickTime 以及Microsoft 公司的Advanced Streaming Format (ASF) 。
1.2支持流媒體的協(xié)議
多媒體應(yīng)用的一個(gè)顯著特點(diǎn)是數(shù)據(jù)量大,并且許多應(yīng)用對(duì)實(shí)時(shí)性要求比較高。傳統(tǒng)的TCP 協(xié)議是一個(gè)面向連接的協(xié)議,它的重傳機(jī)制和擁塞控制機(jī)制都是不適用于實(shí)時(shí)多媒體傳輸?shù)摹TP 是一個(gè)應(yīng)用型的傳輸層協(xié)議,它并不提供任何傳輸可靠性的保證和流量的擁塞控制機(jī)制。RTP 位于UDP(User Datagram Protocol) 之上。UDP 雖然沒(méi)有TCP 那么可靠,并且無(wú)法保證實(shí)時(shí)業(yè)務(wù)的服務(wù)質(zhì)量,需要RTCP 實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)傳輸和服務(wù)質(zhì)量。但是,由于UDP 的傳輸時(shí)延低于TCP ,能與音頻和視頻很好地配合。因此,在實(shí)際應(yīng)用中,RTP/ RTCP/ UDP 用于音頻/ 視頻媒體,而TCP 用于數(shù)據(jù)和控制信令的傳輸。目前,支持流媒體傳輸?shù)膮f(xié)議主要有實(shí)時(shí)傳輸協(xié)議RTP( Real-Time Transport Protocol) 、實(shí)時(shí)傳輸控制協(xié)議RTCP(Real-Time Transport Control Protocol) 和實(shí)時(shí)流協(xié)議RTSP(Real-Time Streaming Protocol) 等。下面分別對(duì)這三種協(xié)議作簡(jiǎn)要介紹。流媒體協(xié)議棧如圖1 所示。
圖1 流媒體協(xié)議棧
2．實(shí)時(shí)傳輸協(xié)議RTP（Real-Time Transport Protocol）：
RTP是針對(duì)Internet上多媒體數(shù)據(jù)流的一個(gè)傳輸協(xié)議, 由IETF(Internet工程任務(wù)組)作為RFC1889發(fā)布。RTP被定義為在一對(duì)一或一對(duì)多的傳輸情況下工作，其目的是提供時(shí)間信息和實(shí)現(xiàn)流同步。RTP的典型應(yīng)用建立在UDP上，但也可以在TCP或ATM等其他協(xié)議之上工作。RTP本身只保證實(shí)時(shí)數(shù)據(jù)的傳輸，并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)。
2.1 RTP工作機(jī)制
威脅多媒體數(shù)據(jù)傳輸?shù)囊粋€(gè)尖銳的問(wèn)題就是不可預(yù)料數(shù)據(jù)到達(dá)時(shí)間。但是流媒體的傳輸是需要數(shù)據(jù)的適時(shí)的到達(dá)用以播放和回放。rtp協(xié)議就是提供了時(shí)間標(biāo)簽,序列號(hào)以及其它的結(jié)構(gòu)用于控制適時(shí)數(shù)據(jù)的流放。在流的概念中”時(shí)間標(biāo)簽”是最重要的信息。發(fā)送端依照即時(shí)的采樣在數(shù)據(jù)包里隱蔽的設(shè)置了時(shí)間標(biāo)簽。在接受端收到數(shù)據(jù)包后,就依照時(shí)間標(biāo)簽按照正確的速率恢復(fù)成原始的適時(shí)的數(shù)據(jù)。不同的媒體格式調(diào)時(shí)屬性是不一樣的。但是rtp本身并不負(fù)責(zé)同步，rtp只是傳輸層協(xié)議，為了簡(jiǎn)化運(yùn)輸層處理，提高該層的效率。將部分運(yùn)輸層協(xié)議功能（比如流量控制）上移到應(yīng)用層完成。同步就是屬于應(yīng)用層協(xié)議完成的。它沒(méi)有運(yùn)輸層協(xié)議的完整功能，不提供任何機(jī)制來(lái)保證實(shí)時(shí)地傳輸數(shù)據(jù)，不支持資源預(yù)留，也不保證服務(wù)質(zhì)量。rtp報(bào)文甚至不包括長(zhǎng)度和報(bào)文邊界的描述。同時(shí)rtp協(xié)議的數(shù)據(jù)報(bào)文和控制報(bào)文的使用相鄰的不同端口，這樣大大提高了協(xié)議的靈活性和處理的簡(jiǎn)單性。
rtp協(xié)議和udp二者共同完成運(yùn)輸層協(xié)議功能。udp協(xié)議只是傳輸數(shù)據(jù)包，不管數(shù)據(jù)包傳輸?shù)臅r(shí)間順序。 rtp的協(xié)議數(shù)據(jù)單元是用udp分組來(lái)承載的。在承載rtp數(shù)據(jù)包的時(shí)候，有時(shí)候一幀數(shù)據(jù)被分割成幾個(gè)包具有相同的時(shí)間標(biāo)簽，則可以知道時(shí)間標(biāo)簽并不是必須的。而udp的多路復(fù)用讓rtp協(xié)議利用支持顯式的多點(diǎn)投遞，可以滿(mǎn)足多媒體會(huì)話的需求。
rtp協(xié)議雖然是傳輸層協(xié)議但是它沒(méi)有作為osi體系結(jié)構(gòu)中單獨(dú)的一層來(lái)實(shí)現(xiàn)。rtp協(xié)議通常根據(jù)一個(gè)具體的應(yīng)用來(lái)提供服務(wù)，rtp只提供協(xié)議框架，開(kāi)發(fā)者可以根據(jù)應(yīng)用的具體要求對(duì)協(xié)議進(jìn)行充分的擴(kuò)展。
2.2 RTP協(xié)議的報(bào)文結(jié)構(gòu)
RTP頭格式如圖2所示：
開(kāi)始12個(gè)八進(jìn)制出現(xiàn)在每個(gè)RTP包中，而CSRC標(biāo)識(shí)列表僅出現(xiàn)在混合器插入時(shí)。各段含義如下：
①版本（V）
2位，標(biāo)識(shí)RTP版本。
②填充標(biāo)識(shí)（P）
1位，如設(shè)置填充位，在包尾將包含附加填充字，它不屬于有效載荷。填充的最后一個(gè)八進(jìn)制包含應(yīng)該忽略的八進(jìn)制計(jì)數(shù)。某些加密算法需要固定大小的填充字，或?yàn)樵诘讓訁f(xié)議數(shù)據(jù)單元中攜帶幾個(gè)RTP包。
③擴(kuò)展（X）
1位，如設(shè)置擴(kuò)展位，固定頭后跟一個(gè)頭擴(kuò)展。
④CSRC計(jì)數(shù)（CC）
4位，CSRC計(jì)數(shù)包括緊接在固定頭后CSRC標(biāo)識(shí)符個(gè)數(shù)。
⑤標(biāo)記（M）
1位，標(biāo)記解釋由設(shè)置定義，目的在于允許重要事件在包流中標(biāo)記出來(lái)。設(shè)置可定義其他標(biāo)示位，或通過(guò)改變位數(shù)量來(lái)指定沒(méi)有標(biāo)記位。
⑥載荷類(lèi)型（PT）
7位，記錄后面資料使用哪種 Codec ， receiver 端找出相應(yīng)的 decoder 解碼出來(lái)。
常用 types：
Payload Type
Codec
0
PCM μ -Law
8
PCM-A Law
9
G..722 audio codec
4
G..723 audio codec
15
G..728 audio codec
18
G..729 audio codec
34
G..763 audio codec
31
G..761 audio codec
⑦系列號(hào)
16位，系列號(hào)隨每個(gè)RTP數(shù)據(jù)包而增加1，由接收者用來(lái)探測(cè)包損失。系列號(hào)初值是隨機(jī)的，使對(duì)加密的文本攻擊更加困難。
⑧時(shí)標(biāo)
32位，時(shí)標(biāo)反映RTP數(shù)據(jù)包中第一個(gè)八進(jìn)制數(shù)的采樣時(shí)刻，采樣時(shí)刻必須從單調(diào)、線性增加的時(shí)鐘導(dǎo)出，以允許同步與抖動(dòng)計(jì)算。時(shí)標(biāo)可以讓receiver端知道在正確的時(shí)間將資料播放出來(lái)。
由上圖可知，如果只有系列號(hào)，并不能完整按照順序的將data播放出來(lái)，因?yàn)槿绻鹍ata中間有一段是沒(méi)有資料的，只有系列號(hào)的話會(huì)造成錯(cuò)誤，需搭配上讓它知道在哪個(gè)時(shí)間將data正確播放出來(lái)，如此我們才能播放出正確無(wú)誤的信息。
⑨SSRC
32位，SSRC段標(biāo)識(shí)同步源。此標(biāo)識(shí)不是隨機(jī)選擇的，目的在于使同一RTP包連接中沒(méi)有兩個(gè)同步源有相同的SSRC標(biāo)識(shí)。盡管多個(gè)源選擇同一個(gè)標(biāo)識(shí)的概率很低，所有RTP實(shí)現(xiàn)都必須探測(cè)并解決沖突。如源改變?cè)磦鬏數(shù)刂?，也必須選擇一個(gè)新SSRC標(biāo)識(shí)以避免插入成環(huán)行源。
⑩CSRC列表
0到15項(xiàng)，每項(xiàng)32位。CSRC列表表示包內(nèi)的對(duì)載荷起作用的源。標(biāo)識(shí)數(shù)量由CC段給出。如超出15個(gè)作用源，也僅標(biāo)識(shí)15個(gè)。CSRC標(biāo)識(shí)由混合器插入，采用作用源的SSRC標(biāo)識(shí)。
3．實(shí)時(shí)傳輸控制協(xié)議RTCP(Real-Time Transport Control Protocol)
RTCP負(fù)責(zé)管理傳輸質(zhì)量在當(dāng)前應(yīng)用進(jìn)程之間交換控制信息。在RTP會(huì)話期間，各參與者周期性地傳送RTCP包，包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料。因此，服務(wù)器可以利用這些信息動(dòng)態(tài)地改變傳輸速率，甚至改變有效載荷類(lèi)型。RTP和RTCP配合使用，能以有效的反饋和最小的開(kāi)銷(xiāo)使傳輸效率最佳化，故特別適合傳送網(wǎng)上的實(shí)時(shí)數(shù)據(jù)。
3.1 RTCP工作機(jī)制
當(dāng)應(yīng)用程序開(kāi)始一個(gè)rtp會(huì)話時(shí)將使用兩個(gè)端口：一個(gè)給rtp，一個(gè)給rtcp。rtp本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠rtcp提供這些服務(wù)。在rtp的會(huì)話之間周期的發(fā)放一些rtcp包以用來(lái)傳監(jiān)聽(tīng)服務(wù)質(zhì)量和交換會(huì)話用戶(hù)信息等功能。rtcp包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料。因此，服務(wù)器可以利用這些信息動(dòng)態(tài)地改變傳輸速率，甚至改變有效載荷類(lèi)型。rtp和rtcp配合使用，它們能以有效的反饋和最小的開(kāi)銷(xiāo)使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實(shí)時(shí)數(shù)據(jù)。根據(jù)用戶(hù)間的數(shù)據(jù)傳輸反饋信息，可以制定流量控制的策略，而會(huì)話用戶(hù)信息的交互，可以制定會(huì)話控制的策略。
3.2 RTCP數(shù)據(jù)報(bào)
在RTCP通信控制中，RTCP協(xié)議的功能是通過(guò)不同的RTCP數(shù)據(jù)報(bào)來(lái)實(shí)現(xiàn)的，主要有如下幾種類(lèi)型：
①SR:發(fā)送端報(bào)告，所謂發(fā)送端是指發(fā)出RTP數(shù)據(jù)報(bào)的應(yīng)用程序或者終端，發(fā)送端同時(shí)也可以是接收端。
②RR:接收端報(bào)告，所謂接收端是指僅接收但不發(fā)送RTP數(shù)據(jù)報(bào)的應(yīng)用程序或者終端。
③SDES:源描述，主要功能是作為會(huì)話成員有關(guān)標(biāo)識(shí)信息的載體，如用戶(hù)名、郵件地址、電話號(hào)碼等，此外還具有向會(huì)話成員傳達(dá)會(huì)話控制信息的功能。
④BYE:通知離開(kāi)，主要功能是指示某一個(gè)或者幾個(gè)源不再有效，即通知會(huì)話中的其他成員自己將退出會(huì)話。
⑤APP:由應(yīng)用程序自己定義，解決了RTCP的擴(kuò)展性問(wèn)題，并且為協(xié)議的實(shí)現(xiàn)者提供了很大的靈活性。
4．資源預(yù)訂協(xié)議RSVP (Resorce Reservation Protocol)由于音頻和視頻數(shù)據(jù)流比傳統(tǒng)數(shù)據(jù)對(duì)網(wǎng)絡(luò)的延時(shí)更敏感，要在網(wǎng)絡(luò)中傳輸高質(zhì)量的音頻、視頻信息，除帶寬要求之外，還需其他更多的條件。RSVP是Internet上的資源預(yù)訂協(xié)議，使用RSVP預(yù)留部分網(wǎng)絡(luò)資源(即帶寬)，能在一定程度上為流媒體的傳輸提供QoS。
RTP協(xié)議分析
第1章. RTP概述
1.1. RTP是什么
RTP全名是Real-time Transport Protocol（實(shí)時(shí)傳輸協(xié)議）。它是IETF提出的一個(gè)標(biāo)準(zhǔn)，對(duì)應(yīng)的RFC文檔為RFC3550（RFC1889為其過(guò)期版本）。RFC3550不僅定義了RTP，而且定義了配套的相關(guān)協(xié)議RTCP（Real-time Transport Control Protocol，即實(shí)時(shí)傳輸控制協(xié)議）。RTP用來(lái)為IP網(wǎng)上的語(yǔ)音、圖像、傳真等多種需要實(shí)時(shí)傳輸?shù)亩嗝襟w數(shù)據(jù)提供端到端的實(shí)時(shí)傳輸服務(wù)。RTP為Internet上端到端的實(shí)時(shí)傳輸提供時(shí)間信息和流同步，但并不保證服務(wù)質(zhì)量，服務(wù)質(zhì)量由RTCP來(lái)提供。
1.2. RTP的應(yīng)用環(huán)境
RTP用于在單播或多播網(wǎng)絡(luò)中傳送實(shí)時(shí)數(shù)據(jù)。它們典型的應(yīng)用場(chǎng)合有如下幾個(gè)。
簡(jiǎn)單的多播音頻會(huì)議。語(yǔ)音通信通過(guò)一個(gè)多播地址和一對(duì)端口來(lái)實(shí)現(xiàn)。一個(gè)用于音頻數(shù)據(jù)（RTP），另一個(gè)用于控制包（RTCP）。
音頻和視頻會(huì)議。如果在一次會(huì)議中同時(shí)使用了音頻和視頻會(huì)議，這兩種媒體將分別在不同的RTP會(huì)話中傳送，每一個(gè)會(huì)話使用不同的傳輸?shù)刂罚↖P地址＋端口）。如果一個(gè)用戶(hù)同時(shí)使用了兩個(gè)會(huì)話，則每個(gè)會(huì)話對(duì)應(yīng)的RTCP包都使用規(guī)范化名字CNAME（Canonical Name）。與會(huì)者可以根據(jù)RTCP包中的CNAME來(lái)獲取相關(guān)聯(lián)的音頻和視頻，然后根據(jù)RTCP包中的計(jì)時(shí)信息(Network time protocol)來(lái)實(shí)現(xiàn)音頻和視頻的同步。
翻譯器和混合器。翻譯器和混合器都是RTP級(jí)的中繼系統(tǒng)。翻譯器用在通過(guò)IP多 播不能直接到達(dá)的用戶(hù)區(qū)，例如發(fā)送者和接收者之間存在防火墻。當(dāng)與會(huì)者能接收的音頻編碼格式不一樣，比如有一個(gè)與會(huì)者通過(guò)一條低速鏈路接入到高速會(huì)議，這 時(shí)就要使用混合器。在進(jìn)入音頻數(shù)據(jù)格式需要變化的網(wǎng)絡(luò)前，混合器將來(lái)自一個(gè)源或多個(gè)源的音頻包進(jìn)行重構(gòu)，并把重構(gòu)后的多個(gè)音頻合并，采用另一種音頻編碼進(jìn) 行編碼后，再轉(zhuǎn)發(fā)這個(gè)新的RTP包。從一個(gè)混合器出來(lái)的所有數(shù)據(jù)包要用混合器作為它們的同步源（SSRC，見(jiàn)RTP的封裝）來(lái)識(shí)別，可以通過(guò)貢獻(xiàn)源列表（CSRC表，見(jiàn)RTP的封裝）可以確認(rèn)談話者。
1.3. 相關(guān)概念
1.3.1. 流媒體
流媒體是指Internet上使用流式傳輸技術(shù)的連續(xù)時(shí)基媒體。當(dāng)前在Internet上傳輸音頻和視頻等信息主要有兩種方式：下載和流式傳輸兩種方式。
下載情況下，用戶(hù)需要先下載整個(gè)媒體文件到本地，然后才能播放媒體文件。在視頻直播等應(yīng)用場(chǎng)合，由于生成整個(gè)媒體文件要等直播結(jié)束，也就是用戶(hù)至少要在直播結(jié)束后才能看到直播節(jié)目，所以用下載方式不能實(shí)現(xiàn)直播。
流式傳輸是實(shí)現(xiàn)流媒體的關(guān)鍵技術(shù)。使用流式傳輸可以邊下載邊觀看流媒體節(jié)目。由于Internet是基于分組傳輸?shù)?，所以接收端收到的?shù)據(jù)包往往有延遲和亂序（流式傳輸構(gòu)建在UDP上）。要實(shí)現(xiàn)流式傳輸，就是要從降低延遲和恢復(fù)數(shù)據(jù)包時(shí)序入手。在發(fā)送端，為降低延遲，往往對(duì)傳輸數(shù)據(jù)進(jìn)行預(yù)處理（降低質(zhì)量和高效壓縮）。在接收端為了恢復(fù)時(shí)序，采用了接收緩沖；而為了實(shí)現(xiàn)媒體的流暢播放，則采用了播放緩沖。
使用接收緩沖，可以將接收到的數(shù)據(jù)包緩存起來(lái)，然后根據(jù)數(shù)據(jù)包的封裝信息（如包序號(hào)和時(shí)戳等），將亂序的包重新排序，最后將重新排序了的數(shù)據(jù)包放入播放緩沖播放。
為什么需要播放緩沖呢？容易想到，由于網(wǎng)絡(luò)不可能很理想，并且對(duì)數(shù)據(jù)包排序需要處理時(shí)耗，我們得到排序好的數(shù)據(jù)包的時(shí)間間隔是不等的。如果不用播放緩沖，那么播放節(jié)目會(huì)很卡，這叫時(shí)延抖動(dòng)。相反，使用播放緩沖，在開(kāi)始播放時(shí)，花費(fèi)幾十秒鐘先將播放緩沖填滿(mǎn)（例如PPLIVE），可以有效地消除時(shí)延抖動(dòng)，從而在不太損失實(shí)時(shí)性的前提下實(shí)現(xiàn)流媒體的順暢播放。
到目前為止,Internet 上使用較多的流式視頻格式主要有以下三種:RealNetworks 公司的RealMedia ,Apple 公司的QuickTime 以及Microsoft 公司的Advanced Streaming Format (ASF) 。
上面在談接收緩沖時(shí)，說(shuō)到了流媒體數(shù)據(jù)包的封裝信息（包序號(hào)和時(shí)戳等），這在后面的RTP封裝中會(huì)有體現(xiàn)。另外，RealMedia這些流式媒體格式只是編解碼有不同，但對(duì)于RTP來(lái)說(shuō)，它們都是待封裝傳輸?shù)牧髅襟w數(shù)據(jù)而沒(méi)有什么不同。
第2章. RTP詳解
2.1. RTP的協(xié)議層次
2.1.1. 傳輸層的子層
RTP（實(shí)時(shí)傳輸協(xié)議），顧名思義它是用來(lái)提供實(shí)時(shí)傳輸?shù)?，因而可以看成是傳輸層的一個(gè)子層。圖 1給出了流媒體應(yīng)用中的一個(gè)典型的協(xié)議體系結(jié)構(gòu)。
圖 1 流媒體體系結(jié)構(gòu)
從圖中可以看出，RTP被劃分在傳輸層，它建立在UDP上。同UDP協(xié)議一樣，為了實(shí)現(xiàn)其實(shí)時(shí)傳輸功能，RTP也有固定的封裝形式。RTP用來(lái)為端到端的實(shí)時(shí)傳輸提供時(shí)間信息和流同步，但并不保證服務(wù)質(zhì)量。服務(wù)質(zhì)量由RTCP來(lái)提供。這些特點(diǎn)，在第4章可以看到。
2.1.2. 應(yīng)用層的一部分
不少人也把RTP歸為應(yīng)用層的一部分，這是從應(yīng)用開(kāi)發(fā)者的角度來(lái)說(shuō)的。操作系統(tǒng)中的TCP/IP等協(xié)議棧所提供的是我們最常用的服務(wù)，而RTP的實(shí)現(xiàn)還是要靠開(kāi)發(fā)者自己。因此從開(kāi)發(fā)的角度來(lái)說(shuō)，RTP的實(shí)現(xiàn)和應(yīng)用層協(xié)議的實(shí)現(xiàn)沒(méi)不同，所以可將RTP看成應(yīng)用層協(xié)議。
RTP實(shí)現(xiàn)者在發(fā)送RTP數(shù)據(jù)時(shí)，需先將數(shù)據(jù)封裝成RTP包，而在接收到RTP數(shù)據(jù)包，需要將數(shù)據(jù)從RTP包中提取出來(lái)。
2.2. RTP的封裝
一個(gè)協(xié)議的封裝是為了滿(mǎn)足協(xié)議的功能需求的。從前面提出的功能需求，可以推測(cè)出RTP封裝中應(yīng)該有同步源和時(shí)戳等字段，但更為完整的封裝是什么樣子呢？請(qǐng)看圖2。
圖 2 RTP的頭部格式
版本號(hào)（V）：2比特，用來(lái)標(biāo)志使用的RTP版本。
填充位（P）：1比特，如果該位置位，則該RTP包的尾部就包含附加的填充字節(jié)。
擴(kuò)展位（X）：1比特，如果該位置位的話，RTP固定頭部后面就跟有一個(gè)擴(kuò)展頭部。
CSRC計(jì)數(shù)器（CC）：4比特，含有固定頭部后面跟著的CSRC的數(shù)目。
標(biāo)記位（M）：1比特,該位的解釋由配置文檔（Profile）來(lái)承擔(dān).
載荷類(lèi)型（PT）：7比特，標(biāo)識(shí)了RTP載荷的類(lèi)型。
序列號(hào)（SN）：16比特，發(fā)送方在每發(fā)送完一個(gè)RTP包后就將該域的值增加1，接收方可以由該域檢測(cè)包的丟失及恢復(fù)包序列。序列號(hào)的初始值是隨機(jī)的。
時(shí)間戳：32比特，記錄了該包中數(shù)據(jù)的第一個(gè)字節(jié)的采樣時(shí)刻。在一次會(huì)話開(kāi)始時(shí)，時(shí)間戳初始化成一個(gè)初始值。即使在沒(méi)有信號(hào)發(fā)送時(shí)，時(shí)間戳的數(shù)值也要隨時(shí)間而不斷地增加（時(shí)間在流逝嘛）。時(shí)間戳是去除抖動(dòng)和實(shí)現(xiàn)同步不可缺少的。
同步源標(biāo)識(shí)符(SSRC)：32比特，同步源就是指RTP包流的來(lái)源。在同一個(gè)RTP會(huì)話中不能有兩個(gè)相同的SSRC值。該標(biāo)識(shí)符是隨機(jī)選取的 RFC1889推薦了MD5隨機(jī)算法。
貢獻(xiàn)源列表（CSRC List）：0～15項(xiàng)，每項(xiàng)32比特，用來(lái)標(biāo)志對(duì)一個(gè)RTP混合器產(chǎn)生的新包有貢獻(xiàn)的所有RTP包的源。由混合器將這些有貢獻(xiàn)的SSRC標(biāo)識(shí)符插入表中。SSRC標(biāo)識(shí)符都被列出來(lái)，以便接收端能正確指出交談雙方的身份。
2.3. RTCP的封裝
RTP需要RTCP為其服務(wù)質(zhì)量提供保證，因此下面介紹一下RTCP的相關(guān)知識(shí)。
RTCP的主要功能是：服務(wù)質(zhì)量的監(jiān)視與反饋、媒體間的同步，以及多播組中成員的標(biāo)識(shí)。在RTP會(huì)話期 間，各參與者周期性地傳送RTCP包。RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料，因此，各參與者可以利用這些信息動(dòng)態(tài)地改變傳輸速率，甚至改變有效載荷類(lèi)型。RTP和RTCP配合使用，它們能以有效的反饋和最小的開(kāi)銷(xiāo)使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實(shí)時(shí)數(shù)據(jù)。
從圖 1可以看到，RTCP也是用UDP來(lái)傳送的，但RTCP封裝的僅僅是一些控制信息，因而分組很短，所以可以將多個(gè)RTCP分組封裝在一個(gè)UDP包中。RTCP有如下五種分組類(lèi)型。
類(lèi)型
縮寫(xiě)表示
用途
200
SR（Sender Report）
發(fā)送端報(bào)告
201
RR（Receiver Report）
接收端報(bào)告
202
SDES（Source Description Items）
源點(diǎn)描述
203
BYE
結(jié)束傳輸
204
APP
特定應(yīng)用
表 1 RTCP的5種分組類(lèi)型
上述五種分組的封裝大同小異，下面只講述SR類(lèi)型，而其它類(lèi)型請(qǐng)參考RFC3550。
發(fā)送端報(bào)告分組SR（Sender Report）用來(lái)使發(fā)送端以多播方式向所有接收端報(bào)告發(fā)送情況。SR分組的主要內(nèi)容有：相應(yīng)的RTP流的SSRC，RTP流中最新產(chǎn)生的RTP分組的時(shí)間戳和NTP，RTP流包含的分組數(shù)，RTP流包含的字節(jié)數(shù)。SR包的封裝如圖3所示。
圖 3 RTCP頭部的格式
版本（V）：同RTP包頭域。
填充（P）：同RTP包頭域。
接收?qǐng)?bào)告計(jì)數(shù)器（RC）：5比特，該SR包中的接收?qǐng)?bào)告塊的數(shù)目，可以為零。
包類(lèi)型（PT）：8比特，SR包是200。
長(zhǎng)度域（Length）：16比特，其中存放的是該SR包以32比特為單位的總長(zhǎng)度減一。
同步源（SSRC）：SR包發(fā)送者的同步源標(biāo)識(shí)符。與對(duì)應(yīng)RTP包中的SSRC一樣。
NTP Timestamp（Network time protocol）SR包發(fā)送時(shí)的絕對(duì)時(shí)間值。NTP的作用是同步不同的RTP媒體流。
RTP Timestamp：與NTP時(shí)間戳對(duì)應(yīng)，與RTP數(shù)據(jù)包中的RTP時(shí)間戳具有相同的單位和隨機(jī)初始值。
Sender’s packet count：從開(kāi)始發(fā)送包到產(chǎn)生這個(gè)SR包這段時(shí)間里，發(fā)送者發(fā)送的RTP數(shù)據(jù)包的總數(shù). SSRC改變時(shí)，這個(gè)域清零。
Sender`s octet count：從開(kāi)始發(fā)送包到產(chǎn)生這個(gè)SR包這段時(shí)間里，發(fā)送者發(fā)送的凈荷數(shù)據(jù)的總字節(jié)數(shù)（不包括頭部和填充）。發(fā)送者改變其SSRC時(shí)，這個(gè)域要清零。
同步源n的SSRC標(biāo)識(shí)符：該報(bào)告塊中包含的是從該源接收到的包的統(tǒng)計(jì)信息。
丟失率（Fraction Lost）：表明從上一個(gè)SR或RR包發(fā)出以來(lái)從同步源n(SSRC_n)來(lái)的RTP數(shù)據(jù)包的丟失率。
累計(jì)的包丟失數(shù)目：從開(kāi)始接收到SSRC_n的包到發(fā)送SR,從SSRC_n傳過(guò)來(lái)的RTP數(shù)據(jù)包的丟失總數(shù)。
收到的擴(kuò)展最大序列號(hào)：從SSRC_n收到的RTP數(shù)據(jù)包中最大的序列號(hào)，
接收抖動(dòng)（Interarrival jitter）：RTP數(shù)據(jù)包接受時(shí)間的統(tǒng)計(jì)方差估計(jì)
上次SR時(shí)間戳（Last SR,LSR）：取最近從SSRC_n收到的SR包中的NTP時(shí)間戳的中間32比特。如果目前還沒(méi)收到SR包，則該域清零。
上次SR以來(lái)的延時(shí)（Delay since last SR,DLSR）：上次從SSRC_n收到SR包到發(fā)送本報(bào)告的延時(shí)。
2.4. RTP的會(huì)話過(guò)程
當(dāng)應(yīng)用程序建立一個(gè)RTP會(huì)話時(shí)，應(yīng)用程序?qū)⒋_定一對(duì)目的傳輸?shù)刂?。目的傳輸?shù)刂酚梢粋€(gè)網(wǎng)絡(luò)地址和一對(duì)端口組成，有兩個(gè)端口：一個(gè)給RTP包，一個(gè)給RTCP包，使得RTP/RTCP數(shù)據(jù)能夠正確發(fā)送。RTP數(shù)據(jù)發(fā)向偶數(shù)的UDP端口，而對(duì)應(yīng)的控制信號(hào)RTCP數(shù)據(jù)發(fā)向相鄰的奇數(shù)UDP端口（偶數(shù)的UDP端口＋1），這樣就構(gòu)成一個(gè)UDP端口對(duì)。 RTP的發(fā)送過(guò)程如下，接收過(guò)程則相反。
1) RTP協(xié)議從上層接收流媒體信息碼流（如H.263），封裝成RTP數(shù)據(jù)包；RTCP從上層接收控制信息，封裝成RTCP控制包。
2) RTP將RTP 數(shù)據(jù)包發(fā)往UDP端口對(duì)中偶數(shù)端口；RTCP將RTCP控制包發(fā)往UDP端口對(duì)中的接收端口。
第3章. 相關(guān)的協(xié)議
3.1. 實(shí)時(shí)流協(xié)議RTSP
實(shí)時(shí)流協(xié)議RTSP（Real-Time Streaming Protocol）是IETF提出的協(xié)議，對(duì)應(yīng)的RFC文檔為RFC2362。
從圖 1可以看出，RTSP是一個(gè)應(yīng)用層協(xié)議（TCP/IP網(wǎng)絡(luò)體系中）。它以C/S模式工作，它是一個(gè)多媒體播放控制協(xié)議，主要用來(lái)使用戶(hù)在播放流媒體時(shí)可以像操作本地的影碟機(jī)一樣進(jìn)行控制，即可以對(duì)流媒體進(jìn)行暫停/繼續(xù)、后退和前進(jìn)等控制。
3.2. 資源預(yù)定協(xié)議RSVP
資源預(yù)定協(xié)議RSVP(Resource Reservation Protocol)是IETF提出的協(xié)議，對(duì)應(yīng)的RFC文檔為RFC2208。
從圖 1可以看出，RSVP工作在IP層之上傳輸層之下，是一個(gè)網(wǎng)絡(luò)控制協(xié)議。RSVP通過(guò)在路由器上預(yù)留一定的帶寬，能在一定程度上為流媒體的傳輸提供服務(wù)質(zhì)量。在某些試驗(yàn)性的系統(tǒng)如網(wǎng)絡(luò)視頻會(huì)議工具vic中就集成了RSVP。
第4章. 常見(jiàn)的疑問(wèn)
4.1. 怎樣重組亂序的數(shù)據(jù)包
可以根據(jù)RTP包的序列號(hào)來(lái)排序。
4.2. 怎樣獲得數(shù)據(jù)包的時(shí)序
可以根據(jù)RTP包的時(shí)間戳來(lái)獲得數(shù)據(jù)包的時(shí)序。
4.3. 聲音和圖像怎么同步
根據(jù)聲音流和圖像流的相對(duì)時(shí)間（即RTP包的時(shí)間戳），以及它們的絕對(duì)時(shí)間（即對(duì)應(yīng)的RTCP包中的RTCP），可以實(shí)現(xiàn)聲音和圖像的同步。
4.4. 接收緩沖和播放緩沖的作用
如1.3.1所述，接收緩沖用來(lái)排序亂序了的數(shù)據(jù)包；播放緩沖用來(lái)消除播放的抖動(dòng)，實(shí)現(xiàn)等時(shí)播放。
第5章. 實(shí)現(xiàn)方案
ID
Protocol
Captured contents
Account
password
Local telephone
number
Opponents
Telephone
Number
audio
login
logout
36
Rtp
√
表 2 協(xié)議分析要求
表 2給出了協(xié)議分析要求。容易看出要獲取RTP音頻包中的音頻信息很容易，直接將RTP包的包頭去掉即可。當(dāng)然，要成功地播放解碼獲取到的音頻流，需要知道其編碼，這可從RTP包包頭的有效載荷類(lèi)型字段（PT）獲得。
第6章. 參考資料
[1] RFC文檔：RFC3550對(duì)應(yīng)RTP/RTCP，RFC2362對(duì)應(yīng)RTSP，RFC2208對(duì)應(yīng)RSVP
[2] http://www.faqs.org/rfcs/，上面有全面的英文RFC文檔
[3] http://www.cnpaf.net/，有不少協(xié)議分析文檔，也有中文RFC文檔，但質(zhì)量不是特別高。
RTP傳輸中的時(shí)間戳
首先，了解幾個(gè)基本概念：
時(shí)間戳單位：時(shí)間戳計(jì)算的單位不是秒之類(lèi)的單位，而是由采樣頻率所代替的單位，這樣做的目的就是為了是時(shí)間戳單位更為精準(zhǔn)。比如說(shuō)一個(gè)音頻的采樣頻率為8000Hz，那么我們可以把時(shí)間戳單位設(shè)為1 / 8000。
時(shí)間戳增量：相鄰兩個(gè)RTP包之間的時(shí)間差（以時(shí)間戳單位為基準(zhǔn)）。
采樣頻率： 每秒鐘抽取樣本的次數(shù)，例如音頻的采樣率一般為8000Hz
幀率： 每秒傳輸或者顯示幀數(shù)，例如25f/s
再看看RTP時(shí)間戳課本中的定義：
RTP包頭的第2個(gè)32Bit即為RTP包的時(shí)間戳，Time Stamp ，占32位。
時(shí)間戳反映了RTP分組中的數(shù)據(jù)的第一個(gè)字節(jié)的采樣時(shí)刻。在一次會(huì)話開(kāi)始時(shí)的時(shí)間戳初值也是隨機(jī)選擇的。即使是沒(méi)有信號(hào)發(fā)送時(shí)，時(shí)間戳的數(shù)值也要隨時(shí)間不 斷的增加。接收端使用時(shí)間戳可準(zhǔn)確知道應(yīng)當(dāng)在什么時(shí)間還原哪一個(gè)數(shù)據(jù)塊，從而消除傳輸中的抖動(dòng)。時(shí)間戳還可用來(lái)使視頻應(yīng)用中聲音和圖像同步。
在RTP協(xié)議中并沒(méi)有規(guī)定時(shí)間戳的粒度，這取決于有效載荷的類(lèi)型。因此RTP的時(shí)間戳又稱(chēng)為媒體時(shí)間戳，以強(qiáng)調(diào)這種時(shí)間戳的粒度取決于信號(hào)的類(lèi)型。例如， 對(duì)于8kHz采樣的話音信號(hào)，若每隔20ms構(gòu)成一個(gè)數(shù)據(jù)塊，則一個(gè)數(shù)據(jù)塊中包含有160個(gè)樣本（0.02×8000=160）。因此每發(fā)送一個(gè)RTP分 組，其時(shí)間戳的值就增加160。
官方的解釋看懂沒(méi)？沒(méi)看懂？沒(méi)關(guān)系，我剛開(kāi)始也沒(méi)看懂，那就聽(tīng)我的解釋吧。
首先，時(shí)間戳就是一個(gè)值，用來(lái)反映某個(gè)數(shù)據(jù)塊的產(chǎn)生（采集）時(shí)間點(diǎn)的，后采集的數(shù)據(jù)塊的時(shí)間戳肯定是大于先采集的數(shù)據(jù)塊的。有了這樣一個(gè)時(shí)間戳，就可以標(biāo)記數(shù)據(jù)塊的先后順序。
第二，在實(shí)時(shí)流傳輸中，數(shù)據(jù)采集后立刻傳遞到RTP模塊進(jìn)行發(fā)送，那么，其實(shí)，數(shù)據(jù)塊的采集時(shí)間戳就直接作為RTP包的時(shí)間戳。
第三，如果用RTP來(lái)傳輸固定的文件，則這個(gè)時(shí)間戳就是讀文件的時(shí)間點(diǎn)，依次遞增。這個(gè)不再我們當(dāng)前的討論范圍內(nèi)，暫時(shí)不考慮。
第四，時(shí)間戳的單位采用的是采樣頻率的倒數(shù)，例如采樣頻率為8000Hz時(shí)，時(shí)間戳的單位為1 / 8000 ，在Jrtplib庫(kù)中，有設(shè)置時(shí)間戳單位的函數(shù)接口，而ORTP庫(kù)中根據(jù)負(fù)載類(lèi)型直接給定了時(shí)間戳的單位（音頻負(fù)載1/8000，視頻負(fù)載1/90000）
第五，時(shí)間戳增量是指兩個(gè)RTP包之間的時(shí)間間隔，詳細(xì)點(diǎn)說(shuō)，就是發(fā)送第二個(gè)RTP包相距發(fā)送第一個(gè)RTP包時(shí)的時(shí)間間隔（單位是時(shí)間戳單位）。
如果采樣頻率為90000Hz，則由上面討論可知，時(shí)間戳單位為1/90000，我們就假設(shè)1s鐘被劃分了90000個(gè)時(shí)間塊，那么，如果每秒發(fā)送25 幀，那么，每一個(gè)幀的發(fā)送占多少個(gè)時(shí)間塊呢？當(dāng)然是 90000/25 = 3600。因此，我們根據(jù)定義“時(shí)間戳增量是發(fā)送第二個(gè)RTP包相距發(fā)送第一個(gè)RTP包時(shí)的時(shí)間間隔”，故時(shí)間戳增量應(yīng)該為3600。
在 Jrtplib中好像不需要自己管理時(shí)間戳的遞增，由庫(kù)內(nèi)部管理。但在ORTP中每次數(shù)據(jù)的發(fā)送都需要自己傳入時(shí)間戳的值，即自己需要每次發(fā)完一個(gè)RTP 包后，累加時(shí)間戳增量，不是很方便，這就需要自己對(duì)RTP的時(shí)間戳有比較深刻地理解，我剛開(kāi)始就是因?yàn)闆](méi)搞清楚，隨時(shí)設(shè)置時(shí)間戳增量導(dǎo)致傳輸一直有問(wèn)題， 困擾我好久。
為什么要使用RTP
一提到流媒體傳輸、一談到什么視頻監(jiān)控、視頻會(huì)議、語(yǔ)音電話（VOIP），都離不開(kāi)RTP協(xié)議的應(yīng)用，但當(dāng)大家都根據(jù)經(jīng)驗(yàn)或者別人的應(yīng)用而選擇RTP協(xié)議的時(shí)候，你可曾想過(guò)，為什么我們要使用RTP來(lái)進(jìn)行流媒體的傳輸呢？為什么我們一定要用RTP？難道TCP、UDP或者其他的網(wǎng)絡(luò)協(xié)議不能達(dá)到我們的要求么？
本文就是根據(jù)我在RTP協(xié)議的學(xué)習(xí)和應(yīng)用過(guò)程中整理出來(lái)的思考，希望對(duì)大家有所啟發(fā)，同時(shí)，也歡迎大家留言探討，提出自己的想法和思考。
1. 維基百科的相關(guān)解釋
Reliable protocols, such as the Transmission Control Protocol (TCP), guarantee correct delivery of each bit in the media stream. However, they accomplish this with a system of timeouts and retries, which makes them more complex to implement. It also means that when there is data loss on the network, the media stream stalls while the protocol handlers detect the loss and retransmit the missing data. Clients can minimize this effect by buffering data for display. While delay due to buffering is acceptable in video on demand scenarios, users of interactive applications such as video conferencing will experience a loss of fidelity if the delay that buffering contributes to exceeds 200 ms.
像TCP這樣的可靠傳輸協(xié)議，通過(guò)超時(shí)和重傳機(jī)制來(lái)保證傳輸數(shù)據(jù)流中的每一個(gè)bit的正確性，但這樣會(huì)使得無(wú)論從協(xié)議的實(shí)現(xiàn)還是傳輸?shù)倪^(guò)程都變得非常的復(fù)雜。而且，當(dāng)傳輸過(guò)程中有數(shù)據(jù)丟失的時(shí)候，由于對(duì)數(shù)據(jù)丟失的檢測(cè)（超時(shí)檢測(cè)）和重傳，會(huì)數(shù)據(jù)流的傳輸被迫暫停和延時(shí)。
或許你會(huì)說(shuō)，我們可以利用客戶(hù)端構(gòu)造一個(gè)足夠大的緩沖區(qū)來(lái)保證顯示的正常，這種方法對(duì)于從網(wǎng)絡(luò)播放音視頻來(lái)說(shuō)是可以接受的，但是對(duì)于一些需要實(shí)時(shí)交互的場(chǎng)合（如視頻聊天、視頻會(huì)議等），如果這種緩沖超過(guò)了200ms，將會(huì)產(chǎn)生難以接受的實(shí)時(shí)性體驗(yàn)。
2. 為什么RTP可以解決上述時(shí)延問(wèn)題
RTP協(xié)議是一種基于UDP的傳輸協(xié)議，RTP本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)。這樣，對(duì)于那些丟失的數(shù)據(jù)包，不存在由于超時(shí)檢測(cè)而帶來(lái)的延時(shí)，同時(shí)，對(duì)于那些丟棄的包，也可以由上層根據(jù)其重要性來(lái)選擇性的重傳。比如，對(duì)于I幀、P幀、B幀數(shù)據(jù)，由于其重要性依次降低，故在網(wǎng)絡(luò)狀況不好的情況下，可以考慮在B幀丟失甚至P幀丟失的情況下不進(jìn)行重傳，這樣，在客戶(hù)端方面，雖然可能會(huì)有短暫的不清晰畫(huà)面，但卻保證了實(shí)時(shí)性的體驗(yàn)和要求。
3. 多播功能
多播在網(wǎng)絡(luò)視頻會(huì)議方面有著很廣泛的應(yīng)用，它主要應(yīng)用于這樣一種環(huán)境，即：
假 設(shè)紅色的圓為存放有視頻數(shù)據(jù)的流媒體服務(wù)器，其他的圓為連接到該服務(wù)器的各個(gè)客戶(hù)端，當(dāng)所有的綠色的客戶(hù)端要求同時(shí)觀看紅色服務(wù)器上的某一個(gè)視頻時(shí)，如果 服務(wù)器為每一路客戶(hù)端單獨(dú)建立連接進(jìn)行數(shù)據(jù)的傳輸，這樣明顯不太合理浪費(fèi)帶寬，因此，多播技術(shù)可以很好地解決這種問(wèn)題，即同一份數(shù)據(jù)，由服務(wù)器發(fā)送到公共 的多播地址，各個(gè)客戶(hù)端均監(jiān)聽(tīng)同一個(gè)多播地址來(lái)獲取數(shù)據(jù)，這樣，既節(jié)省了帶寬，同時(shí)也保證了各個(gè)客戶(hù)端所觀看的視頻的同步。
這樣的多播應(yīng)用TCP協(xié)議是不支持的，而RTP協(xié)議在最初就是為了實(shí)現(xiàn)類(lèi)似的視頻會(huì)議的應(yīng)用而誕生的，對(duì)其有非常好的支持。
4. RTP包頭中的流媒體特性
首先，我們看看RTP的包頭。
V ― 版本。識(shí)別 RTP 版本。
P ― 填充。設(shè)置1時(shí)，數(shù)據(jù)包包含一個(gè)或多個(gè)附加填充比特，填充比特不屬于有效載荷。
X ― 擴(kuò)展位。設(shè)置1時(shí)，在固定頭后面，跟隨一個(gè)頭擴(kuò)展。
CSRC Count ― 包含 CSRC 標(biāo)識(shí)符（在固定頭后）的數(shù)目。
M ― 標(biāo)志。標(biāo)志由描述文件（profile）文件定義。允許在比特流中標(biāo)記重要的事件，如幀邊界。
Payload Type ― 負(fù)載類(lèi)型。由具體的應(yīng)用決定其解釋。某些profile 文件規(guī)定了從 Payload 編碼到 Payload 格式的缺省靜態(tài)映射。另外的 Payload Type 編碼也可以通過(guò)非 RTP 方法實(shí)現(xiàn)動(dòng)態(tài)定義。
Sequence Number ― 序列號(hào)。每發(fā)送一個(gè) RTP 數(shù)據(jù)包，序列號(hào)增加1。接收端可以據(jù)此檢測(cè)丟包和重建包序列。
Timestamp ―時(shí)間戳。反映了RTP 數(shù)據(jù)包中第一個(gè)字節(jié)的采樣時(shí)間。時(shí)鐘頻率依賴(lài)于負(fù)載數(shù)據(jù)格式，并在描述文件（profile）中進(jìn)行描述。
SSRC ― 同步源。該標(biāo)識(shí)符隨機(jī)生成，旨在確保在同一個(gè) RTP 會(huì)話中不存在兩個(gè)同步源具有相同的 SSRC 標(biāo)識(shí)符。
CSRC ― 貢獻(xiàn)源標(biāo)識(shí)符。識(shí)別該數(shù)據(jù)包中的有效載荷的貢獻(xiàn)源。
從RTP包頭的規(guī)定中，我們可以非常清晰地看出，在RTP協(xié)議中，添加了非常多專(zhuān)為流媒體傳輸所使用的特性，更加有助于應(yīng)用于流媒體的傳輸。
比如用于幀邊界標(biāo)記的M標(biāo)志位，方便接收端快速定位幀邊界；比如負(fù)載類(lèi)型字段，用來(lái)告訴接收端（或者播放器）傳輸?shù)氖悄姆N類(lèi)型的媒體（例如G.729，H.264，MPEG-4等），這樣接收端（或者播放器）就知道數(shù)據(jù)流是什么格式，然后使用對(duì)應(yīng)的解碼器去解碼或者播放；比如時(shí)間戳字段，標(biāo)識(shí)了數(shù)據(jù)流的時(shí)間戳，接收端可以利用這個(gè)時(shí)間戳來(lái)去除由網(wǎng)絡(luò)引起的信息包的抖動(dòng)，并且在接收端為播放提供同步功能，等等。
因此，相比于直接使用TCP或者UDP來(lái)進(jìn)行流媒體傳輸，這樣一個(gè)專(zhuān)門(mén)為傳輸音視頻而誕生的網(wǎng)絡(luò)協(xié)議更加合適。
5. RTP的profile機(jī)制
RTP為具體的應(yīng)用提供了非常大的靈活性，它將傳輸協(xié)議與具體的應(yīng)用環(huán)境、具體的控制策略分開(kāi)，傳輸協(xié)議本身只提供完成實(shí)時(shí)傳輸?shù)臋C(jī)制，開(kāi)發(fā)者可以根據(jù)不同的應(yīng)用環(huán)境，自主選擇合適的配置環(huán)境、以及合適的控制策略。
這里所說(shuō)的控制策略指的是你可以根據(jù)自己特定的應(yīng)用需求，來(lái)實(shí)現(xiàn)特定的一些RTCP控制算法，比如前面提到的丟包的檢測(cè)算法、丟包的重傳策略、一些視頻會(huì)議應(yīng)用中的控制方案等等（這些策略我可能將在后續(xù)的文章中進(jìn)行描述）。
對(duì)于上面說(shuō)的合適的配置環(huán)境，主要是指RTP的相關(guān)配置和負(fù)載格式的定義。RTP協(xié)議為了廣泛地支持各種多媒體格式（如 H.264, MPEG-4, MJPEG, MPEG），沒(méi)有在協(xié)議中體現(xiàn)出具體的應(yīng)用配置，而是通過(guò)profile配置文件以及負(fù)載類(lèi)型格式說(shuō)明文件的形式來(lái)提供。對(duì)于任何一種特定的應(yīng)用，RTP定義了一個(gè)profile文件以及相關(guān)的負(fù)載格式說(shuō)明，相關(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）
等等，想了解更多可以點(diǎn)擊這里：http://en.wikipedia.org/wiki/RTP_audio_video_profile
說(shuō)明，如果應(yīng)用程序不使用專(zhuān)有的方案來(lái)提供有效載荷類(lèi)型(payload type)、順序號(hào)或者時(shí)間戳，而是使用標(biāo)準(zhǔn)的RTP協(xié)議，應(yīng)用程序就更容易與其他的網(wǎng)絡(luò)應(yīng)用程序配合運(yùn)行，這是大家都希望的事情。例如，如果有兩個(gè)不同的公司都在開(kāi)發(fā)因特網(wǎng)電話軟件，他們都把RTP合并到他們的產(chǎn)品中，這樣就有希望：使用不同公司電話軟件的用戶(hù)之間能夠進(jìn)行通信。
6. RTP其他的一些良好特性
（1）RTP協(xié)議在設(shè)計(jì)上考慮到安全功能，支持加密數(shù)據(jù)和身份驗(yàn)證功能。
（2）有較少的首部開(kāi)銷(xiāo)
TCP和XTP相對(duì)RTP來(lái)說(shuō)具有過(guò)多的首部開(kāi)銷(xiāo)(TCP和XTP3.6是40字節(jié)，XTP4.0是32字節(jié)，而RTP只有12字節(jié))
（3）……（等待補(bǔ)充）
7. 相關(guān)資源列表
這里有些相關(guān)的RTP資源，希望對(duì)大家有所幫助。
（1）維基百科對(duì)RTP的介紹：
http://en.wikipedia.org/wiki/Real-time_Transport_Protocol
（2）維基百科對(duì)流媒體的介紹：
http://en.wikipedia.org/wiki/Streaming_media
（3）stackoverflows論壇關(guān)于RTP vs TCP的討論
http://stackoverflow.com/questions/361943/why-does-rtp-use-udp-instead-of-tcp
（4）關(guān)于RTP的負(fù)載類(lèi)型和時(shí)間戳的講解
http://ticktick.blog.51cto.com/823160/350142
（5） RTP FAQ
Some Frequently Asked Questions about RTP
IP/TCP/UDP/RTP/RTCP包結(jié)構(gòu)圖
IP 包頭結(jié)構(gòu):
TCP 包頭結(jié)構(gòu):
UDP 包頭結(jié)構(gòu):
RTP 包頭結(jié)構(gòu):
RTCP 包頭結(jié)構(gòu):
另附RTP/UDP/TCP協(xié)議總結(jié)：http://wenku.baidu.com/view/3580ad6648d7c1c708a145e1.html
聯(lián)系客服
