RTP協議RTP（Real-timeTransportProtocol）是由IETF開發的實時傳輸協議，可以在面向連接或無連接的下層協議上工作，通常和UDP協議一起使用。RTP的工作機理與RSVP不同，主要實現一種端到端的多媒體流同步控制機制，既不需要事先建立連接，也不需要中間節點的參與，爲其保留資源。在網絡帶寬充足的情況下，RTP具有一定的帶寬調控能力，保證端到端的多媒體流同步。在網絡帶寬不足時，RTP的帶寬調控能力將受到一定的限制。ITU(國際電信聯合會)的視頻會議標準H.323採用了RTP協議。 RTP定義了兩種報文：RTP報文和RTCP報文，RTP報文用於傳送媒體數據（如音頻和視頻），它由RTP報頭和數據兩部分組成，RTP數據部分稱爲有效載荷(payload)；RTCP報文用於傳送控制信息，以實現協議控制功能。RTP報文和RTCP報文將作爲下層協議的數據單元進行傳輸。如果使用UDP，則RTP報文和RTCP報文分別使用兩個相鄰的UDP端口，RTP報文使用低端口，RTCP報文使用高端口。如果使用其它的下層協議，RTP報文和RTCP報文可以合併，放在一個數據單元中一起傳送，控制信息在前，媒體數據在後。通常，RTP是由應用程序實現的。 1 RTP報文格式RTP報文由兩部分組成：報頭和有效載荷。RTP報頭格式如下圖所示，其中：
·V：RTP協議的版本號，佔2位，當前協議版本號爲2。 ·P：填充標誌，佔1位，如果P=1，則在該報文的尾部將填充一個或多個額外的八位組，它們不是有效載荷的一部分。 ·X：擴展標誌，佔1位，如果X=1，則在RTP報頭後跟有一個擴展報頭。 ·CC：CSRC計數器，佔4位，指示CSRC 標識符的個數。 ·M:標記，佔1位，不同的有效載荷有不同的含義，對於視頻，標記一幀的結束；對於音頻，標記會話的開始。 ·PT:有效載荷類型，佔7位，用於說明RTP報文中有效載荷的類型，如GSM音頻、JPEM圖像等。 ·序列號：佔16位，用於標識發送者所發送的RTP報文的序列號，每發送一個報文，序列號增1。接收者通過序列號來檢測報文丟失情況，重新排序報文，恢復數據。 ·時戳(Timestamp)：佔32位，時戳反映了該RTP報文的第一個八位組的採樣時刻。接收者使用時戳來計算延遲和延遲抖動，並進行同步控制。 ·同步信源(SSRC)標識符：佔32位，用於標識同步信源。該標識符是隨機選擇的，參加同一視頻會議的兩個同步信源不能有相同的SSRC。 ·特約信源(CSRC)標識符：每個CSRC標識符佔32位，可以有0～15個。每個CSRC標識了包含在該RTP報文有效載荷中的所有特約信源。 這裏的同步信源是指產生媒體流的信源，它通過RTP報頭中的一個32位數字SSRC標識符來標識，而不依賴於網絡地址，接收者將根據SSRC標識符來區分不同的信源，進行RTP報文的分組。特約信源是指當混合器接收到一個或多個同步信源的RTP報文後，經過混合處理產生一個新的組合RTP報文，並把混合器作爲組合RTP報文的SSRC，而將原來所有的SSRC都作爲CSRC傳送給接收者，使接收者知道組成組合報文的各個SSRC。 在發送端，上層應用程序以分組形式將編碼後的媒體數據傳給RTP通信模塊，作爲RTP報文的有效載荷，RTP通信模塊將根據上層應用提供的參數在有效載荷前添加RTP報頭，形成RTP報文，通過Socket接口選擇UDP協議發送出去。 在接收端，RTP通信模塊通過Socket接口接收到RTP報文後，將RTP報頭分離出來作相應處理，再將RTP報文的有效載荷作爲數據分組傳遞給上層應用。 考慮到在Internet這種複雜的環境中舉行視頻會議，RTP定義了兩種中間系統：混合器(Mixer)和轉換器(Translator)。 在Internet上舉行視頻會議時，可能有少數參加者通過低速鏈路與使用高速網絡的多數參加者相連接。爲了不強制所有會議參加者都使用低帶寬和低質量的數據編碼，RTP允許在低帶寬區域附近使用混合器作爲RTP級中繼器。混合器從一個或多個信源接收RTP報文，對到達的數據報文進行重新同步和重新組合，這些重組的數據流被混合成一個數據流，將數據編碼轉化爲在低帶寬上可用的類型，並通過低速鏈路向低帶寬區域轉發。爲了對多個輸入信源進行統一的同步，混合器在多個媒體流之間進行定時調整，產生它自己的定時同步，因此所有從混合器輸出的報文都把混合器作爲同步信源。爲了保證接收者能夠正確識別混合器處理前的原始報文發送者，混合器在RTP報頭中設置了CSRC標識符隊列，以標識那些產生混和報文的原始同步信源。 在Internet環境中，一些會議的參加者可能被隔離在應用級防火牆的外面，這些參加者被禁止直接使用IP組播地址進行訪問，雖然他們可能是通過高速鏈路連接的。在這些情況下，RTP允許使用轉換器作爲RTP級中繼器。在防火牆兩端分別安裝一個轉換器，防火牆之外的轉換器過濾所有接收到的組播報文，並通過一條安全的連接傳送給防火牆之內的轉換器，內部轉換器將這些組播報文再轉發送給內部網絡中的組播組成員。 2 基於RTP的帶寬控制方法爲了實時傳輸數據，RTP利用了簡單而快捷的UDP協議實現網絡傳輸。由於UDP協議是一種無連接傳輸協議，不保證報文傳輸的正確性和有序性，也不提供流量控制功能。另一方面，在多媒體通信中，由於多媒體數據的特殊性，不宜採用通常的重傳糾錯法來提供正確性，而是採用控制傳送帶寬方式來減少報文丟失，以滿足多媒體應用所需的QoS。 在RTP協議中，通過RTCP報文提供了基於無連接傳輸協議的端到端控制機制，這是一種基於接收者反饋的網絡傳輸QoS監測機制，在RTCP的接收報告中包含了當前網絡傳輸QoS有關信息，如報文丟失率、報文丟失累計、接收到的最高序列號、平均延遲抖動以及用於計算髮布接收報告往返所需時間的時間標籤等。發送者可通過這些信息監測和評價網絡傳輸QoS狀況，並可採取適當的策略實施同步控制。RTP協議規定，每個RTP系統必須實現RTCP的控制功能，由內部功能模塊定期自動執行。RTCP報文是輕載信息，其信息量與最低的數據通信量相平衡，它所產生的通信量只是數據通信量的5%左右。 要實施端到端的強制同步控制，其前提條件是發送端要能夠獲取網絡失調狀態信息。一種可行的同步控制策略是：各個接收端將一種輕載的網絡失調狀態信息（如QoS參數狀態）反饋給發送端，發送端據此進行強制性同步控制，以滿足接收端演示質量的要求。基於RTP的帶寬控制算法正是利用這種控制策略來實施強制性同步控制的，其基本思想是在RTP協議機制支持下，發送端通過接收端週期反饋的接收報告來評價當前網絡傳輸的QoS，並以此對數據發送速率進行適當調整。端點之間利用RTP報文和RTCP報文來實現帶寬控制：
(1)RTP報文的序號字段可用於排序RTP報文分組，以消除重複分組，保持視頻或音頻流內同步和連續地播放。 (2)RTP報文的時戳字段可作爲流間同步標識，以保持視頻和音頻流間同步和連續地播放。(3)發送者可利用接收者反饋的RTCP報文來制實施端到端的強制性同步控制，以改善當前網絡傳輸的QoS。 2.1.接收端的控制策略接收端通過RTP協議實施如下的控制策略：
①SSRC字段用於標識不同的信源，以支持多對一或多對多的多媒體通信。 ②時戳字段作爲流間同步標識，用於媒體流間的流間控制，以保持視頻和音頻流間同步和連續地播放，並作爲時間量用於計算報文分組的傳輸延時、延時抖動以及數據更新週期等，濾除嚴重延時的RTP報文分組。③序號字段作爲流內同步標識，用於排序RTP報文分組，消除重複報文分組，保持視頻或音頻流內同步和連續地播放。 ④將接收端檢測到的當前網絡QoS狀況通過RTCP的接收報告週期地反饋給發送端。2.2.發送端的控制策略發送端將採用如下的控制算法來調整傳送帶寬。
①設bs爲發送端當前的帶寬，bmin和bmax分別爲應用所設置的最小帶寬和最大帶寬，且bs?[bmin，bmax]。 ②在每個發送帶寬級上保持一個時間片，超時後將根據網絡QoS狀況提高或降低一個帶寬級，以避免帶寬頻繁波動。這裏使用報文丟失率作爲QoS指示器，並設置一個閾值。如果QoS指示器超閾，說明網絡發生阻塞，通過改變發送速率來調整傳送帶寬，疏導網絡交通。 ③初始時按最大帶寬發送報文分組，即bs?bmax，以提高網絡通道的利用率。 ④如果在規定的時間片內QoS指示器超閾，說明網絡發生阻塞，則在超時後需要降低一個帶寬級，即bs? max { bs-μ, bmin}，其中μ爲比例因子。 ⑤如果在規定的時間片內QoS指示器未超閾，說明網絡交通狀況良好，則在超時後應當提高一個帶寬級，即bs? min { bs+μ, bmax}。⑥在點到多點通信場合中，發送者將面對多個不同網段上的接收者，而每個網段的交通狀況又不盡相同。因此，在改變帶寬時可採用多數表決法，即當報文丟失率超閾的接收者超過一定比例時再改變帶寬。 這種方法的特點是：利用RTP協議機制來傳送網絡狀態信息，不需要另外構造網絡檢測機構，易於實現；RTCP報文是一種輕載報文，佔用較少的通信帶寬。 RTP與RTCP協議介紹 1．流媒體( StreamingMedia)
1.1流媒體概念
流媒體技術是網絡技術和多媒體技術發展到一定階段的產物。術語流媒體既可以指在網上傳輸連續時基媒體的流式技術,也可以指使用流式技術的連續時基媒體本身。在網上傳輸音頻、視頻等多媒體信息目前主要有兩種方式:下載和流式傳輸。採用下載方式,用戶需要先下載整個媒體文件,然後才能進行播放。由於網絡帶寬的限制,下載常常要花很長時間,所以這種處理方式延遲很大。而流媒體實現的關鍵技術是流式傳輸。傳輸之前首先對多媒體進行預處理(降低質量和高效壓縮),然後使用緩存系統來保證數據連續正確地進行傳輸。使用流式傳輸方式,用戶不必像採用下載方式那樣要等到整個文件全部下載完畢,而是隻需經過幾秒到幾十秒的啓動延時即可在客戶端進行播放和觀看。此時媒體文件的剩餘部分將在後臺繼續下載。與單純的下載方式相比,這種對多媒體文件邊下載邊播放的流式傳輸方式不僅使啓動延時大幅度地縮短,而且對系統緩存容量的需求也大大降低。使用流式傳輸的另一個好處是使傳輸那些事先不知道或無法知道大小的媒體數據(如網上直播、視頻會議等) 成爲可能。
到目前爲止,Internet 上使用較多的流式視頻格式主要有以下三種:RealNetworks 公司的RealMedia,Apple 公司的QuickTime 以及Microsoft 公司的AdvancedStreaming Format (ASF) 。
1.2支持流媒體的協議
多媒體應用的一個顯著特點是數據量大,並且許多應用對實時性要求比較高。傳統的TCP 協議是一個面向連接的協議,它的重傳機制和擁塞控制機制都是不適用於實時多媒體傳輸的。RTP是一個應用型的傳輸層協議,它並不提供任何傳輸可靠性的保證和流量的擁塞控制機制。RTP 位於UDP(UserDatagramProtocol) 之上。UDP 雖然沒有TCP 那麼可靠,並且無法保證實時業務的服務質量,需要RTCP 實時監控數據傳輸和服務質量。但是,由於UDP 的傳輸時延低於TCP,能與音頻和視頻很好地配合。因此,在實際應用中,RTP/
RTCP/UDP 用於音頻/ 視頻媒體,而TCP 用於數據和控制信令的傳輸。目前,支持流媒體傳輸的協議主要有實時傳輸協議RTP(Real-Time TransportProtocol) 、實時傳輸控制協議RTCP(Real-Time TransportControl Protocol) 和實時流協議RTSP(Real-Time StreamingProtocol) 等。下面分別對這三種協議作簡要介紹。流媒體協議棧如圖1 所示。
圖1 流媒體協議棧
2．實時傳輸協議RTP（Real-TimeTransport Protocol）：
RTP是針對Internet上多媒體數據流的一個傳輸協議, 由IETF(Internet工程任務組)作爲RFC1889發佈。RTP被定義爲在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現流同步。RTP的典型應用建立在UDP上，但也可以在TCP或ATM等其他協議之上工作。RTP本身只保證實時數據的傳輸，並不能爲按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。
2.1 RTP工作機制
威脅多媒體數據傳輸的一個尖銳的問題就是不可預料數據到達時間。但是流媒體的傳輸是需要數據的適時的到達用以播放和回放。rtp協議就是提供了時間標籤,序列號以及其它的結構用於控制適時數據的流放。在流的概念中”時間標籤”是最重要的信息。發送端依照即時的採樣在數據包裏隱蔽的設置了時間標籤。在接受端收到數據包後,就依照時間標籤按照正確的速率恢復成原始的適時的數據。不同的媒體格式調時屬性是不一樣的。但是rtp本身並不負責同步，rtp只是傳輸層協議，爲了簡化運輸層處理，提高該層的效率。將部分運輸層協議功能（比如流量控制）上移到應用層完成。同步就是屬於應用層協議完成的。它沒有運輸層協議的完整功能，不提供任何機制來保證實時地傳輸數據，不支持資源預留，也不保證服務質量。rtp報文甚至不包括長度和報文邊界的描述。同時rtp協議的數據報文和控制報文的使用相鄰的不同端口，這樣大大提高了協議的靈活性和處理的簡單性。
rtp協議和udp二者共同完成運輸層協議功能。udp協議只是傳輸數據包，不管數據包傳輸的時間順序。 rtp的協議數據單元是用udp分組來承載的。在承載rtp數據包的時候，有時候一幀數據被分割成幾個包具有相同的時間標籤，則可以知道時間標籤並不是必須的。而udp的多路複用讓rtp協議利用支持顯式的多點投遞，可以滿足多媒體會話的需求。
rtp協議雖然是傳輸層協議但是它沒有作爲osi體系結構中單獨的一層來實現。rtp協議通常根據一個具體的應用來提供服務，rtp只提供協議框架，開發者可以根據應用的具體要求對協議進行充分的擴展。
2.2 RTP協議的報文結構
RTP頭格式如圖2所示：
 開始12個八進制出現在每個RTP包中，而CSRC標識列表僅出現在混合器插入時。各段含義如下：
①版本（V）
2位，標識RTP版本。
②填充標識（P）
1位，如設置填充位，在包尾將包含附加填充字，它不屬於有效載荷。填充的最後一個八進制包含應該忽略的八進制計數。某些加密算法需要固定大小的填充字，或爲在底層協議數據單元中攜帶幾個RTP包。
③擴展（X）
1位，如設置擴展位，固定頭後跟一個頭擴展。
④CSRC計數（CC）
4位，CSRC計數包括緊接在固定頭後CSRC標識符個數。
⑤標記（M）
1位，標記解釋由設置定義，目的在於允許重要事件在包流中標記出來。設置可定義其他標示位，或通過改變位數量來指定沒有標記位。
⑥載荷類型（PT）
7位，記錄後面資料使用哪種 Codec ， receiver 端找出相應的 decoder 解碼出來。
常用 types：
⑦系列號
16位，系列號隨每個RTP數據包而增加1，由接收者用來探測包損失。系列號初值是隨機的，使對加密的文本攻擊更加困難。
⑧時標
32位，時標反映RTP數據包中第一個八進制數的採樣時刻，採樣時刻必須從單調、線性增加的時鐘導出，以允許同步與抖動計算。時標可以讓receiver端知道在正確的時間將資料播放出來。
由上圖可知，如果只有系列號，並不能完整按照順序的將data播放出來，因爲如果data中間有一段是沒有資料的，只有系列號的話會造成錯誤，需搭配上讓它知道在哪個時間將data正確播放出來，如此我們才能播放出正確無誤的信息。
⑨SSRC
32位，SSRC段標識同步源。此標識不是隨機選擇的，目的在於使同一RTP包連接中沒有兩個同步源有相同的SSRC標識。儘管多個源選擇同一個標識的概率很低，所有RTP實現都必須探測並解決衝突。如源改變源傳輸地址，也必須選擇一個新SSRC標識以避免插入成環行源。
⑩CSRC列表
0到15項，每項32位。CSRC列表表示包內的對載荷起作用的源。標識數量由CC段給出。如超出15個作用源，也僅標識15個。CSRC標識由混合器插入，採用作用源的SSRC標識。
3．實時傳輸控制協議RTCP(Real-Time TransportControl Protocol)
RTCP負責管理傳輸質量在當前應用進程之間交換控制信息。在RTP會話期間，各參與者週期性地傳送RTCP包，包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料。因此，服務器可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，故特別適合傳送網上的實時數據。
3.1 RTCP工作機制
當應用程序開始一個rtp會話時將使用兩個端口：一個給rtp，一個給rtcp。rtp本身並不能爲按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠rtcp提供這些服務。在rtp的會話之間週期的發放一些rtcp包以用來傳監聽服務質量和交換會話用戶信息等功能。rtcp包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料。因此，服務器可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。rtp和rtcp配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的實時數據。根據用戶間的數據傳輸反饋信息，可以制定流量控制的策略，而會話用戶信息的交互，可以制定會話控制的策略。
3.2 RTCP數據報
在RTCP通信控制中，RTCP協議的功能是通過不同的RTCP數據報來實現的，主要有如下幾種類型：
①SR:發送端報告，所謂發送端是指發出RTP數據報的應用程序或者終端，發送端同時也可以是接收端。
②RR:接收端報告，所謂接收端是指僅接收但不發送RTP數據報的應用程序或者終端。
③SDES:源描述，主要功能是作爲會話成員有關標識信息的載體，如用戶名、郵件地址、電話號碼等，此外還具有向會話成員傳達會話控制信息的功能。
④BYE:通知離開，主要功能是指示某一個或者幾個源不再有效，即通知會話中的其他成員自己將退出會話。
⑤APP:由應用程序自己定義，解決了RTCP的擴展性問題，並且爲協議的實現者提供了很大的靈活性。
4．資源預訂協議RSVP(Resorce Reservation Protocol)
由於音頻和視頻數據流比傳統數據對網絡的延時更敏感，要在網絡中傳輸高質量的音頻、視頻信息，除帶寬要求之外，還需其他更多的條件。RSVP是Internet上的資源預訂協議，使用RSVP預留部分網絡資源(即帶寬)，能在一定程度上爲流媒體的傳輸提供QoS。RTP協議分析 第1章. RTP概述1.1. RTP是什麼RTP全名是Real-time TransportProtocol（實時傳輸協議）。它是IETF提出的一個標準，對應的RFC文檔爲RFC3550（RFC1889爲其過期版本）。RFC3550不僅定義了RTP，而且定義了配套的相關協議RTCP（Real-time Transport ControlProtocol，即實時傳輸控制協議）。RTP用來爲IP網上的語音、圖像、傳真等多種需要實時傳輸的多媒體數據提供端到端的實時傳輸服務。RTP爲Internet上端到端的實時傳輸提供時間信息和流同步，但並不保證服務質量，服務質量由RTCP來提供。 1.2. RTP的應用環境RTP用於在單播或多播網絡中傳送實時數據。它們典型的應用場合有如下幾個。 簡單的多播音頻會議。語音通信通過一個多播地址和一對端口來實現。一個用於音頻數據（RTP），另一個用於控制包（RTCP）。 音頻和視頻會議。如果在一次會議中同時使用了音頻和視頻會議，這兩種媒體將分別在不同的RTP會話中傳送，每一個會話使用不同的傳輸地址（IP地址＋端口）。如果一個用戶同時使用了兩個會話，則每個會話對應的RTCP包都使用規範化名字CNAME（CanonicalName）。與會者可以根據RTCP包中的CNAME來獲取相關聯的音頻和視頻，然後根據RTCP包中的計時信息(Network timeprotocol)來實現音頻和視頻的同步。 翻譯器和混合器。翻譯器和混合器都是RTP級的中繼系統。翻譯器用在通過IP多播不能直接到達的用戶區，例如發送者和接收者之間存在防火牆。當與會者能接收的音頻編碼格式不一樣，比如有一個與會者通過一條低速鏈路接入到高速會議，這時就要使用混合器。在進入音頻數據格式需要變化的網絡前，混合器將來自一個源或多個源的音頻包進行重構，並把重構後的多個音頻合併，採用另一種音頻編碼進行編碼後，再轉發這個新的RTP包。從一個混合器出來的所有數據包要用混合器作爲它們的同步源（SSRC，見RTP的封裝）來識別，可以通過貢獻源列表（CSRC表，見RTP的封裝）可以確認談話者。 1.3. 相關概念1.3.1. 流媒體流媒體是指Internet上使用流式傳輸技術的連續時基媒體。當前在Internet上傳輸音頻和視頻等信息主要有兩種方式：下載和流式傳輸兩種方式。 下載情況下，用戶需要先下載整個媒體文件到本地，然後才能播放媒體文件。在視頻直播等應用場合，由於生成整個媒體文件要等直播結束，也就是用戶至少要在直播結束後才能看到直播節目，所以用下載方式不能實現直播。 流式傳輸是實現流媒體的關鍵技術。使用流式傳輸可以邊下載邊觀看流媒體節目。由於Internet是基於分組傳輸的，所以接收端收到的數據包往往有延遲和亂序（流式傳輸構建在UDP上）。要實現流式傳輸，就是要從降低延遲和恢復數據包時序入手。在發送端，爲降低延遲，往往對傳輸數據進行預處理（降低質量和高效壓縮）。在接收端爲了恢復時序，採用了接收緩衝；而爲了實現媒體的流暢播放，則採用了播放緩衝。 使用接收緩衝，可以將接收到的數據包緩存起來，然後根據數據包的封裝信息（如包序號和時戳等），將亂序的包重新排序，最後將重新排序了的數據包放入播放緩衝播放。 爲什麼需要播放緩衝呢？容易想到，由於網絡不可能很理想，並且對數據包排序需要處理時耗，我們得到排序好的數據包的時間間隔是不等的。如果不用播放緩衝，那麼播放節目會很卡，這叫時延抖動。相反，使用播放緩衝，在開始播放時，花費幾十秒鐘先將播放緩衝填滿（例如PPLIVE），可以有效地消除時延抖動，從而在不太損失實時性的前提下實現流媒體的順暢播放。 到目前爲止,Internet 上使用較多的流式視頻格式主要有以下三種:RealNetworks 公司的RealMedia,Apple 公司的QuickTime 以及Microsoft 公司的Advanced Streaming Format(ASF) 。 上面在談接收緩衝時，說到了流媒體數據包的封裝信息（包序號和時戳等），這在後面的RTP封裝中會有體現。另外，RealMedia這些流式媒體格式只是編解碼有不同，但對於RTP來說，它們都是待封裝傳輸的流媒體數據而沒有什麼不同。 第2章. RTP詳解2.1. RTP的協議層次2.1.1. 傳輸層的子層RTP（實時傳輸協議），顧名思義它是用來提供實時傳輸的，因而可以看成是傳輸層的一個子層。圖 1給出了流媒體應用中的一個典型的協議體系結構。
圖 1 流媒體體系結構 從圖中可以看出，RTP被劃分在傳輸層，它建立在UDP上。同UDP協議一樣，爲了實現其實時傳輸功能，RTP也有固定的封裝形式。RTP用來爲端到端的實時傳輸提供時間信息和流同步，但並不保證服務質量。服務質量由RTCP來提供。這些特點，在第4章可以看到。 2.1.2. 應用層的一部分不少人也把RTP歸爲應用層的一部分，這是從應用開發者的角度來說的。操作系統中的TCP/IP等協議棧所提供的是我們最常用的服務，而RTP的實現還是要靠開發者自己。因此從開發的角度來說，RTP的實現和應用層協議的實現沒不同，所以可將RTP看成應用層協議。 RTP實現者在發送RTP數據時，需先將數據封裝成RTP包，而在接收到RTP數據包，需要將數據從RTP包中提取出來。 2.2. RTP的封裝一個協議的封裝是爲了滿足協議的功能需求的。從前面提出的功能需求，可以推測出RTP封裝中應該有同步源和時戳等字段，但更爲完整的封裝是什麼樣子呢？請看圖2。
圖 2 RTP的頭部格式 版本號（V）：2比特，用來標誌使用的RTP版本。 填充位（P）：1比特，如果該位置位，則該RTP包的尾部就包含附加的填充字節。 擴展位（X）：1比特，如果該位置位的話，RTP固定頭部後面就跟有一個擴展頭部。 CSRC計數器（CC）：4比特，含有固定頭部後面跟着的CSRC的數目。 標記位（M）：1比特,該位的解釋由配置文檔（Profile）來承擔. 載荷類型（PT）：7比特，標識了RTP載荷的類型。 序列號（SN）：16比特，發送方在每發送完一個RTP包後就將該域的值增加1，接收方可以由該域檢測包的丟失及恢復包序列。序列號的初始值是隨機的。 時間戳：32比特，記錄了該包中數據的第一個字節的採樣時刻。在一次會話開始時，時間戳初始化成一個初始值。即使在沒有信號發送時，時間戳的數值也要隨時間而不斷地增加（時間在流逝嘛）。時間戳是去除抖動和實現同步不可缺少的。 同步源標識符(SSRC)：32比特，同步源就是指RTP包流的來源。在同一個RTP會話中不能有兩個相同的SSRC值。該標識符是隨機選取的 RFC1889推薦了MD5隨機算法。 貢獻源列表（CSRCList）：0～15項，每項32比特，用來標誌對一個RTP混合器產生的新包有貢獻的所有RTP包的源。由混合器將這些有貢獻的SSRC標識符插入表中。SSRC標識符都被列出來，以便接收端能正確指出交談雙方的身份。 2.3. RTCP的封裝RTP需要RTCP爲其服務質量提供保證，因此下面介紹一下RTCP的相關知識。 RTCP的主要功能是：服務質量的監視與反饋、媒體間的同步，以及多播組中成員的標識。在RTP會話期 間，各參與者週期性地傳送RTCP包。RTCP包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料，因此，各參與者可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的實時數據。 從圖 1可以看到，RTCP也是用UDP來傳送的，但RTCP封裝的僅僅是一些控制信息，因而分組很短，所以可以將多個RTCP分組封裝在一個UDP包中。RTCP有如下五種分組類型。
表 1 RTCP的5種分組類型 上述五種分組的封裝大同小異，下面只講述SR類型，而其它類型請參考RFC3550。 發送端報告分組SR（SenderReport）用來使發送端以多播方式向所有接收端報告發送情況。SR分組的主要內容有：相應的RTP流的SSRC，RTP流中最新產生的RTP分組的時間戳和NTP，RTP流包含的分組數，RTP流包含的字節數。SR包的封裝如圖3所示。
圖 3 RTCP頭部的格式 版本（V）：同RTP包頭域。 填充（P）：同RTP包頭域。 接收報告計數器（RC）：5比特，該SR包中的接收報告塊的數目，可以爲零。 包類型（PT）：8比特，SR包是200。 長度域（Length）：16比特，其中存放的是該SR包以32比特爲單位的總長度減一。 同步源（SSRC）：SR包發送者的同步源標識符。與對應RTP包中的SSRC一樣。 NTPTimestamp（Network timeprotocol）SR包發送時的絕對時間值。NTP的作用是同步不同的RTP媒體流。 RTPTimestamp：與NTP時間戳對應，與RTP數據包中的RTP時間戳具有相同的單位和隨機初始值。 Sender’spacket count：從開始發送包到產生這個SR包這段時間裏，發送者發送的RTP數據包的總數.SSRC改變時，這個域清零。 Sender`s octetcount：從開始發送包到產生這個SR包這段時間裏，發送者發送的淨荷數據的總字節數（不包括頭部和填充）。發送者改變其SSRC時，這個域要清零。 同步源n的SSRC標識符：該報告塊中包含的是從該源接收到的包的統計信息。 丟失率（FractionLost）：表明從上一個SR或RR包發出以來從同步源n(SSRC_n)來的RTP數據包的丟失率。 累計的包丟失數目：從開始接收到SSRC_n的包到發送SR,從SSRC_n傳過來的RTP數據包的丟失總數。 收到的擴展最大序列號：從SSRC_n收到的RTP數據包中最大的序列號， 接收抖動（Interarrivaljitter）：RTP數據包接受時間的統計方差估計 上次SR時間戳（LastSR,LSR）：取最近從SSRC_n收到的SR包中的NTP時間戳的中間32比特。如果目前還沒收到SR包，則該域清零。 上次SR以來的延時（Delaysince last SR,DLSR）：上次從SSRC_n收到SR包到發送本報告的延時。 2.4. 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端口對中的接收端口。 第3章. 相關的協議3.1. 實時流協議RTSP實時流協議RTSP（Real-Time Streaming Protocol）是IETF提出的協議，對應的RFC文檔爲RFC2362。 從圖 1可以看出，RTSP是一個應用層協議（TCP/IP網絡體系中）。它以C/S模式工作，它是一個多媒體播放控制協議，主要用來使用戶在播放流媒體時可以像操作本地的影碟機一樣進行控制，即可以對流媒體進行暫停/繼續、後退和前進等控制。 3.2. 資源預定協議RSVP資源預定協議RSVP(ResourceReservation Protocol)是IETF提出的協議，對應的RFC文檔爲RFC2208。 從圖 1可以看出，RSVP工作在IP層之上傳輸層之下，是一個網絡控制協議。RSVP通過在路由器上預留一定的帶寬，能在一定程度上爲流媒體的傳輸提供服務質量。在某些試驗性的系統如網絡視頻會議工具vic中就集成了RSVP。 第4章. 常見的疑問4.1. 怎樣重組亂序的數據包可以根據RTP包的序列號來排序。 4.2. 怎樣獲得數據包的時序可以根據RTP包的時間戳來獲得數據包的時序。 4.3. 聲音和圖像怎麼同步根據聲音流和圖像流的相對時間（即RTP包的時間戳），以及它們的絕對時間（即對應的RTCP包中的RTCP），可以實現聲音和圖像的同步。 4.4. 接收緩衝和播放緩衝的作用如1.3.1所述，接收緩衝用來排序亂序了的數據包；播放緩衝用來消除播放的抖動，實現等時播放。 第5章. 實現方案
表 2 協議分析要求 表 2給出了協議分析要求。容易看出要獲取RTP音頻包中的音頻信息很容易，直接將RTP包的包頭去掉即可。當然，要成功地播放解碼獲取到的音頻流，需要知道其編碼，這可從RTP包包頭的有效載荷類型字段（PT）獲得。 第6章. 參考資料[1] RFC文檔：RFC3550對應RTP/RTCP，RFC2362對應RTSP，RFC2208對應RSVP [2] http://www.faqs.org/rfcs/，上面有全面的英文RFC文檔 [3] http://www.cnpaf.net/，有不少協議分析文檔，也有中文RFC文檔，但質量不是特別高。 RTP傳輸中的時間戳 首先，瞭解幾個基本概念： 時間戳增量：相鄰兩個RTP包之間的時間差（以時間戳單位爲基準）。 採樣頻率： 每秒鐘抽取樣本的次數，例如音頻的採樣率一般爲8000Hz 幀率： 每秒傳輸或者顯示幀數，例如25f/s 再看看RTP時間戳課本中的定義：
官方的解釋看懂沒？沒看懂？沒關係，我剛開始也沒看懂，那就聽我的解釋吧。 首先，時間戳就是一個值，用來反映某個數據塊的產生（採集）時間點的，後採集的數據塊的時間戳肯定是大於先採集的數據塊的。有了這樣一個時間戳，就可以標記數據塊的先後順序。
第二，在實時流傳輸中，數據採集後立刻傳遞到RTP模塊進行發送，那麼，其實，數據塊的採集時間戳就直接作爲RTP包的時間戳。 第三，如果用RTP來傳輸固定的文件，則這個時間戳就是讀文件的時間點，依次遞增。這個不再我們當前的討論範圍內，暫時不考慮。 第四，時間戳的單位採用的是採樣頻率的倒數，例如採樣頻率爲8000Hz時，時間戳的單位爲1/ 8000，在Jrtplib庫中，有設置時間戳單位的函數接口，而ORTP庫中根據負載類型直接給定了時間戳的單位（音頻負載1/8000，視頻負載1/90000） 第五，時間戳增量是指兩個RTP包之間的時間間隔，詳細點說，就是發送第二個RTP包相距發送第一個RTP包時的時間間隔（單位是時間戳單位）。 如果採樣頻率爲90000Hz，則由上面討論可知，時間戳單位爲1/90000，我們就假設1s鐘被劃分了90000個時間塊，那麼，如果每秒發送25幀，那麼，每一個幀的發送佔多少個時間塊呢？當然是 90000/25 =3600。因此，我們根據定義“時間戳增量是發送第二個RTP包相距發送第一個RTP包時的時間間隔”，故時間戳增量應該爲3600。 在Jrtplib中好像不需要自己管理時間戳的遞增，由庫內部管理。但在ORTP中每次數據的發送都需要自己傳入時間戳的值，即自己需要每次發完一個RTP包後，累加時間戳增量，不是很方便，這就需要自己對RTP的時間戳有比較深刻地理解，我剛開始就是因爲沒搞清楚，隨時設置時間戳增量導致傳輸一直有問題，困擾我好久。 爲什麼要使用RTP 一提到流媒體傳輸、一談到什麼視頻監控、視頻會議、語音電話（VOIP），都離不開RTP協議的應用，但當大家都根據經驗或者別人的應用而選擇RTP協議的時候，你可曾想過，爲什麼我們要使用RTP來進行流媒體的傳輸呢？爲什麼我們一定要用RTP？難道TCP、UDP或者其他的網絡協議不能達到我們的要求麼？ 本文就是根據我在RTP協議的學習和應用過程中整理出來的思考，希望對大家有所啓發，同時，也歡迎大家留言探討，提出自己的想法和思考。 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 andretries, which makes them more complex to implement. It also meansthat when there is data loss on the network, the media streamstalls while the protocol handlers detect the loss and retransmitthe missing data. Clients can minimize this effect by bufferingdata for display. While delay due to buffering is acceptable invideo on demand scenarios, users of interactive applications suchas video conferencing will experience a loss of fidelity if thedelay that buffering contributes to exceeds 200 ms. 像TCP這樣的可靠傳輸協議，通過超時和重傳機制來保證傳輸數據流中的每一個bit的正確性，但這樣會使得無論從協議的實現還是傳輸的過程都變得非常的複雜。而且，當傳輸過程中有數據丟失的時候，由於對數據丟失的檢測（超時檢測）和重傳，會數據流的傳輸被迫暫停和延時。 或許你會說，我們可以利用客戶端構造一個足夠大的緩衝區來保證顯示的正常，這種方法對於從網絡播放音視頻來說是可以接受的，但是對於一些需要實時交互的場合（如視頻聊天、視頻會議等），如果這種緩衝超過了200ms，將會產生難以接受的實時性體驗。 2. 爲什麼RTP可以解決上述時延問題 RTP協議是一種基於UDP的傳輸協議，RTP本身並不能爲按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。這樣，對於那些丟失的數據包，不存在由於超時檢測而帶來的延時，同時，對於那些丟棄的包，也可以由上層根據其重要性來選擇性的重傳。比如，對於I幀、P幀、B幀數據，由於其重要性依次降低，故在網絡狀況不好的情況下，可以考慮在B幀丟失甚至P幀丟失的情況下不進行重傳，這樣，在客戶端方面，雖然可能會有短暫的不清晰畫面，但卻保證了實時性的體驗和要求。 3. 多播功能 多播在網絡視頻會議方面有着很廣泛的應用，它主要應用於這樣一種環境，即：
假設紅色的圓爲存放有視頻數據的流媒體服務器，其他的圓爲連接到該服務器的各個客戶端，當所有的綠色的客戶端要求同時觀看紅色服務器上的某一個視頻時，如果服務器爲每一路客戶端單獨建立連接進行數據的傳輸，這樣明顯不太合理浪費帶寬，因此，多播技術可以很好地解決這種問題，即同一份數據，由服務器發送到公共的多播地址，各個客戶端均監聽同一個多播地址來獲取數據，這樣，既節省了帶寬，同時也保證了各個客戶端所觀看的視頻的同步。 這樣的多播應用TCP協議是不支持的，而RTP協議在最初就是爲了實現類似的視頻會議的應用而誕生的，對其有非常好的支持。 4. RTP包頭中的流媒體特性 首先，我們看看RTP的包頭。
V ― 版本。識別 RTP 版本。 P ― 填充。設置1時，數據包包含一個或多個附加填充比特，填充比特不屬於有效載荷。 PayloadType ― 負載類型。由具體的應用決定其解釋。某些profile 文件規定了從Payload 編碼到 Payload 格式的缺省靜態映射。另外的 PayloadType 編碼也可以通過非 RTP方法實現動態定義。 SequenceNumber ― 序列號。每發送一個 RTP 數據包，序列號增加1。接收端可以據此檢測丟包和重建包序列。 Timestamp ―時間戳。反映了RTP 數據包中第一個字節的採樣時間。時鐘頻率依賴於負載數據格式，並在描述文件（profile）中進行描述。 SSRC ― 同步源。該標識符隨機生成，旨在確保在同一個 RTP 會話中不存在兩個同步源具有相同的 SSRC 標識符。 CSRC ― 貢獻源標識符。識別該數據包中的有效載荷的貢獻源。 從RTP包頭的規定中，我們可以非常清晰地看出，在RTP協議中，添加了非常多專爲流媒體傳輸所使用的特性，更加有助於應用於流媒體的傳輸。 比如用於幀邊界標記的M標誌位，方便接收端快速定位幀邊界；比如負載類型字段，用來告訴接收端（或者播放器）傳輸的是哪種類型的媒體（例如G.729，H.264，MPEG-4等），這樣接收端（或者播放器）就知道數據流是什麼格式，然後使用對應的解碼器去解碼或者播放；比如時間戳字段，標識了數據流的時間戳，接收端可以利用這個時間戳來去除由網絡引起的信息包的抖動，並且在接收端爲播放提供同步功能，等等。 因此，相比於直接使用TCP或者UDP來進行流媒體傳輸，這樣一個專門爲傳輸音視頻而誕生的網絡協議更加合適。 5. RTP的profile機制 RTP爲具體的應用提供了非常大的靈活性，它將傳輸協議與具體的應用環境、具體的控制策略分開，傳輸協議本身只提供完成實時傳輸的機制，開發者可以根據不同的應用環境，自主選擇合適的配置環境、以及合適的控制策略。 這裏所說的控制策略指的是你可以根據自己特定的應用需求，來實現特定的一些RTCP控制算法，比如前面提到的丟包的檢測算法、丟包的重傳策略、一些視頻會議應用中的控制方案等等（這些策略我可能將在後續的文章中進行描述）。 對於上面說的合適的配置環境，主要是指RTP的相關配置和負載格式的定義。RTP協議爲了廣泛地支持各種多媒體格式（如 H.264,MPEG-4, MJPEG,MPEG），沒有在協議中體現出具體的應用配置，而是通過profile配置文件以及負載類型格式說明文件的形式來提供。對於任何一種特定的應用，RTP定義了一個profile文件以及相關的負載格式說明，相關的文件如下所示： 《RTP Profile for Audio and Video Conferences with MinimalControl》（RFC3551） 《RTP Payload Format for H.264 Video》（RFC3984） 《RTP Payload Format for MPEG-4 Audio/VisualStreams》（RFC3016） 等等，想了解更多可以點擊這裏：http://en.wikipedia.org/wiki/RTP_audio_video_profile 說明，如果應用程序不使用專有的方案來提供有效載荷類型(payloadtype)、順序號或者時間戳，而是使用標準的RTP協議，應用程序就更容易與其他的網絡應用程序配合運行，這是大家都希望的事情。例如，如果有兩個不同的公司都在開發因特網電話軟件，他們都把RTP合併到他們的產品中，這樣就有希望：使用不同公司電話軟件的用戶之間能夠進行通信。 6. RTP其他的一些良好特性 （1）RTP協議在設計上考慮到安全功能，支持加密數據和身份驗證功能。 （2）有較少的首部開銷 TCP和XTP相對RTP來說具有過多的首部開銷(TCP和XTP3.6是40字節，XTP4.0是32字節，而RTP只有12字節) （3）……（等待補充） 7. 相關資源列表 這裏有些相關的RTP資源，希望對大家有所幫助。 （1）維基百科對RTP的介紹： http://en.wikipedia.org/wiki/Real-time_Transport_Protocol （2）維基百科對流媒體的介紹： http://en.wikipedia.org/wiki/Streaming_media （3）stackoverflows論壇關於RTP vs TCP的討論 http://stackoverflow.com/questions/361943/why-does-rtp-use-udp-instead-of-tcp （4）關於RTP的負載類型和時間戳的講解 http://ticktick.blog.51cto.com/823160/350142 （5） RTPFAQ IP/TCP/UDP/RTP/RTCP包結構圖 IP 包頭結構:
TCP 包頭結構: UDP 包頭結構:
RTCP 包頭結構: 另附RTP/UDP/TCP協議總結：http://wenku.baidu.com/view/3580ad6648d7c1c708a145e1.html |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
