RTP協議分析

**：

rtp全名是real-time transport protocol（實時傳輸協議）。它是ietf提出的乙個標準，對應的rfc文件為rfc3550（rfc1889為其過期版本）。rfc3550不僅定義了rtp，而且定義了配套的相關協議rtcp（real-time transport control protocol，即實時傳輸控制協議）。rtp用來為ip網上的語音、影象、傳真等多種需要實時傳輸的多**資料提供端到端的實時傳輸服務。rtp為internet上端到端的實時傳輸提供時間資訊和流同步，但並不保證服務質量，服務質量由rtcp來提供。

rtp用於在單播或多播網路中傳送實時資料。它們典型的應用場合有如下幾個。

簡單的多播音訊會議。語音通訊通過乙個多播位址和一對埠來實現。乙個用於音訊資料（rtp），另乙個用於控制包（rtcp）。

翻譯器和混合器。翻譯器和混合器都是rtp級的中繼系統。翻譯器用在通過ip多播不能直接到達的使用者區，例如傳送者和接收者之間存在防火牆。當與會者能接收的音訊編碼格式不一樣，比如有乙個與會者通過一條低速鏈路接入到高速會議，這時就要使用混合器。在進入音訊資料格式需要變化的網路前，混合器將來自乙個源或多個源的音訊包進行重構，並把重構後的多個音訊合併，採用另一種音訊編碼進行編碼後，再**這個新的rtp包。從乙個混合器出來的所有資料報要用混合器作為它們的同步源（ssrc，見rtp的封裝）來識別，可以通過貢獻源列表（csrc表，見rtp的封裝）可以確認談話者。

上面在談接收緩衝時，說到了流**資料報的封裝資訊（包序號和時戳等），這在後面的rtp封裝中會有體現。另外，realmedia這些流式**格式只是編譯碼有不同，但對於rtp來說，它們都是待封裝傳輸的流**資料而沒有什麼不同。

rtp（實時傳輸協議），顧名思義它是用來提供實時傳輸的，因而可以看成是傳輸層的乙個子層。圖 1給出了流**應用中的乙個典型的協議體系結構。

圖 1 流**體系結構

從圖中可以看出，rtp被劃分在傳輸層，它建立在udp上。同udp協議一樣，為了實現其實時傳輸功能，rtp也有固定的封裝形式。rtp用來為端到端的實時傳輸提供時間資訊和流同步，但並不保證服務質量。服務質量由rtcp來提供。這些特點，在第4章可以看到。

不少人也把rtp歸為應用層的一部分，這是從應用開發者的角度來說的。作業系統中的tcp/ip等協議棧所提供的是我們最常用的服務，而rtp的實現還是要靠開發者自己。因此從開發的角度來說，rtp的實現和應用層協議的實現沒不同，所以可將rtp看成應用層協議。

rtp實現者在傳送rtp資料時，需先將資料封裝成rtp包，而在接收到rtp資料報，需要將資料從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位元，記錄了該包中資料的第乙個位元組的取樣時刻。在一次會話開始時，時間戳初始化成乙個初始值。即使在沒有訊號傳送時，時間戳的數值也要隨時間而不斷地增加（時間在流逝嘛）。時間戳是去除抖動和實現同步不可缺少的。

貢獻源列表（csrc list）：0～15項，每項32位元，用來標誌對乙個rtp混合器產生的新包有貢獻的所有rtp包的源。由混合器將這些有貢獻的ssrc識別符號插入表中。ssrc識別符號都被列出來，以便接收端能正確指出交談雙方的身份。

rtp需要rtcp為其服務質量提供保證，因此下面介紹一下rtcp的相關知識。

rtcp的主要功能是：服務質量的監視與反饋、**間的同步，以及多播組中成員的標識。在rtp會話期間，各參與者周期性地傳送rtcp包。rtcp包中含有已傳送的資料報的數量、丟失的資料報的數量等統計資料，因此，各參與者可以利用這些資訊動態地改變傳輸速率，甚至改變有效載荷型別。rtp和rtcp配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的實時資料。

從圖 1可以看到，rtcp也是用udp來傳送的，但rtcp封裝的僅僅是一些控制資訊，因而分組很短，所以可以將多個rtcp分組封裝在乙個udp包中。rtcp有如下五種分組型別。

型別縮寫表示

用途sr（sender report）

傳送端報告

rr（receiver report）

接收端報告

sdes（source description items）

源點描述

bye結束傳輸

特定應用

表 1 rtcp的5種分組型別

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

傳送端報告分組sr（sender report）用來使傳送端以多播方式向所有接收端報告傳送情況。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一樣。

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識別符號：該報告塊中包含的是從該源接收到的包的統計資訊。

累計的包丟失數目：從開始接收到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會話時，應用程式將確定一對目的傳輸位址。目的傳輸位址由乙個網路位址和一對埠組成，有兩個埠：乙個給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埠對中的接收埠。

實時流協議rtsp（real-time streaming protocol）是ietf提出的協議，對應的rfc文件為rfc2362。

資源預定協議rsvp(resource reservation protocol)是ietf提出的協議，對應的rfc文件為rfc2208。

可以根據rtp包的序列號來排序。

可以根據rtp包的時間戳來獲得資料報的時序。

根據聲音流和影象流的相對時間（即rtp包的時間戳），以及它們的絕對時間（即對應的rtcp包中的rtcp），可以實現聲音和影象的同步。

idprotocol

captured contents

account

password

local telephone

number

opponents

telephone

number

audio

logout

rtp表 2 協議分析要求

RTP協議分析

RTP協議分析

RTP協議分析

RTP協議分析

相關推薦