本文主要介紹RTP與RTCP協(xié)議。
author: ZJ 06-11-17
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)上傳輸音頻、視頻等多媒體信息目前主要有兩種方式:下載和流式傳輸。采用下載方式,用戶需要先下載整個(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)行傳輸。使用流式傳輸方式,用戶不必像采用下載方式那樣要等到整個(gè)文件全部下載完畢,而是只需經(jīng)過(guò)幾秒到幾十秒的啟動(dòng)延時(shí)即可在客戶端進(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ù)摹?span style="padding-bottom: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px" lang="EN-US">RTP 是一個(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)投遞，可以滿足多媒體會(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報(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)記位。
⑥載荷類型（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)槿绻?/span>data中間有一段是沒(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ù)刂罚脖仨氝x擇一個(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)地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，能以有效的反饋和最小的開(kāi)銷使傳輸效率最佳化，故特別適合傳送網(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ì)話用戶信息等功能。rtcp包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料。因此，服務(wù)器可以利用這些信息動(dòng)態(tài)地改變傳輸速率，甚至改變有效載荷類型。rtp和rtcp配合使用，它們能以有效的反饋和最小的開(kāi)銷使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實(shí)時(shí)數(shù)據(jù)。根據(jù)用戶間的數(shù)據(jù)傳輸反饋信息，可以制定流量控制的策略，而會(huì)話用戶信息的交互，可以制定會(huì)話控制的策略。
3.2 RTCP數(shù)據(jù)報(bào)
在RTCP通信控制中，RTCP協(xié)議的功能是通過(guò)不同的RTCP數(shù)據(jù)報(bào)來(lái)實(shí)現(xiàn)的，主要有如下幾種類型：
①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à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。
5．參考資料
[1]蔣愛(ài)權(quán)，流媒體技術(shù)的Java實(shí)現(xiàn)，計(jì)算機(jī)應(yīng)用研究2002，10。
[2]吳國(guó)勇，網(wǎng)絡(luò)視頻流媒體技術(shù)與應(yīng)用，北京郵電大學(xué)出版社，2001。
[3]臺(tái)灣國(guó)立中央大學(xué)電機(jī)工程系通訊專題報(bào)告VOIP
本文出自 “子 孑” 博客，請(qǐng)務(wù)必保留此出處http://zhangjunhd.blog.51cto.com/113473/25481