internet
文檔
視訊會議
report
網絡
microsoft
目錄(?)[+]
整理記錄
| 版本 | 時間 | 内容 | 整理人 |
| V1.0 | 2008-03-31 | RTP協定分析初稿 | 彭令鵬 |
RTP協定分析
第1章. RTP概述
1.1. RTP是什麼
RTP全名是Real-time Transport Protocol（實時傳輸協定）。它是IETF提出的一個标準，對應的RFC文檔為RFC3550（RFC1889為其過期版本）。RFC3550不僅定義了RTP，而且定義了配套的相關協定RTCP（Real-time Transport Control Protocol，即實時傳輸控制協定）。RTP用來為IP網上的語音、圖像、傳真等多種需要實時傳輸的多媒體資料提供端到端的實時傳輸服務。RTP為Internet上端到端的實時傳輸提供時間資訊和流同步，但并不保證服務品質，服務品質由RTCP來提供。
1.2. RTP的應用環境
RTP用于在單點傳播或多點傳播網絡中傳送實時資料。它們典型的應用場合有如下幾個。
簡單的多點傳播音頻會議。語音通信通過一個多點傳播位址和一對端口來實作。一個用于音頻資料（RTP），另一個用于控制包（RTCP）。
音頻和視訊會議。如果在一次會議中同時使用了音頻和視訊會議，這兩種媒體将分别在不同的RTP會話中傳送，每一個會話使用不同的傳輸位址（IP位址＋端口）。如果一個使用者同時使用了兩個會話，則每個會話對應的RTCP包都使用規範化名字CNAME（Canonical Name）。與會者可以根據RTCP包中的CNAME來擷取相關聯的音頻和視訊，然後根據RTCP包中的計時資訊(Network time protocol)來實作音頻和視訊的同步。
翻譯器和混合器。翻譯器和混合器都是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随機算法。
貢獻源清單（CSRC List）：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有如下五種分組類型。
| 類型 | 縮寫表示 | 用途 |
| 200 | SR（Sender Report） | 發送端報告 |
| 201 | RR（Receiver Report） | 接收端報告 |
| 202 | SDES（Source Description Items） | 源點描述 |
| 203 | BYE | 結束傳輸 |
| 204 | APP | 特定應用 |
表 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辨別符：該報告塊中包含的是從該源接收到的包的統計資訊。
丢失率（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包到發送本報告的延時。
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(Resource Reservation 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章. 實作方案
| ID | Protocol | Captured contents | ||||
| Account | password | Local telephone number | Opponents Telephone Number | audio | login | logout |
| 36 | Rtp | √ |
表2 協定分析要求
表 2給出了協定分析要求。容易看出要擷取RTP音頻包中的音頻資訊很容易，直接将RTP包的標頭去掉即可。當然，要成功地播放解碼擷取到的音頻流，需要知道其編碼，這可從RTP包標頭的有效載荷類型字段（PT）獲得。
第6章. 參考資料
[1] RFC文檔：RFC3550對應RTP/RTCP，RFC2362對應RTSP，RFC2208對應RSVP