RTP是一種提供端對(duì)端傳輸服務(wù)的實(shí)時(shí)傳輸協(xié)議，用來支持在單目標(biāo)廣播和多目標(biāo)廣播網(wǎng)絡(luò)服務(wù)中傳輸實(shí)時(shí)數(shù)據(jù)，而實(shí)時(shí)數(shù)據(jù)的傳輸則由RTCP協(xié)議來監(jiān)視和控制。
RTP定義在RFC
使用RTP協(xié)議的應(yīng)用程序運(yùn)行在RTP之上，而執(zhí)行RTP的程序運(yùn)行在UDP的上層，目的是為了使用UDP的端口號(hào)和檢查和。如圖16-12所示，RTP可以看成是傳輸層的子層。由多媒體應(yīng)用程序生成的聲音和電視數(shù)據(jù)塊被封裝在RTP信息包中，每個(gè)RTP信息包被封裝在UDP消息段中，然后再封裝在IP數(shù)據(jù)包中。
1889中。信息包的結(jié)構(gòu)包含廣泛用于多媒體的若干個(gè)域，包括聲音點(diǎn)播(audio-on-demand)、影視點(diǎn)播(video on demand)、因特網(wǎng)電話(Internet telephony)和電視會(huì)議(videoconferencing)。RTP的規(guī)格沒有對(duì)聲音和電視的壓縮格式制定標(biāo)準(zhǔn)，它可以被用來傳輸普通格式的文件。例如，WAV或者GSM(Global System for Mobile communications)格式的聲音、MPEG-1和MPEG-2的電視，也可以用來傳輸專有格式存儲(chǔ)的聲音和電視文件。
TCP/IP模型
應(yīng)用層(application)
傳輸層
RTP
UDP
IP
數(shù)據(jù)鏈路層(data link)
物理層(physical)
圖16-12 RTP是傳輸層上的協(xié)議
從應(yīng)用開發(fā)人員的角度來看，可把RTP執(zhí)行程序看成是應(yīng)用程序的一部分，因?yàn)殚_發(fā)人員必需把RTP集成到應(yīng)用程序中。在發(fā)送端，開發(fā)人員必需把執(zhí)行RTP協(xié)議的程序?qū)懭氲絼?chuàng)建RTP信息包的應(yīng)用程序中，然后應(yīng)用程序把RTP信息包發(fā)送到UDP的套接接口(socket interface)，如圖16-13所示；同樣，在接收端，RTP信息包通過UDP套接接口輸入到應(yīng)用程序，因此開發(fā)人員必需把執(zhí)行RTP協(xié)議的程序?qū)懭氲綇腞TP信息包中抽出媒體數(shù)據(jù)的應(yīng)用程序。
TCP/IP模型
應(yīng)用層(application)
RTP
套接接口
UDP
IP
數(shù)據(jù)鏈路層(data link)
物理層(physical)
圖16-13 RTP和UDP之間的接口
現(xiàn)以用RTP傳輸聲音為例來說明它的工作過程。假設(shè)音源的聲音是64 kb/s的PCM編碼聲音，并假設(shè)應(yīng)用程序取20毫秒的編碼數(shù)據(jù)為一個(gè)數(shù)據(jù)塊(chunk)，即在一個(gè)數(shù)據(jù)塊中有160個(gè)字節(jié)的聲音數(shù)據(jù)。應(yīng)用程序需要為這塊聲音數(shù)據(jù)添加RTP標(biāo)題生成RTP信息包，這個(gè)標(biāo)題包括聲音數(shù)據(jù)的類型、順序號(hào)和時(shí)間戳。然后RTP信息包被送到UDP套接接口，在那里再被封裝在UDP信息包中。在接收端，應(yīng)用程序從套接接口處接收RTP信息包，并從RTP信息包中抽出聲音數(shù)據(jù)塊，然后使用RTP信息包的標(biāo)題域中的信息正確地譯碼和播放聲音。
如果應(yīng)用程序不使用專有的方案來提供有效載荷類型(payload type)、順序號(hào)或者時(shí)間戳，而是使用標(biāo)準(zhǔn)的RTP協(xié)議，應(yīng)用程序就更容易與其他的網(wǎng)絡(luò)應(yīng)用程序配合運(yùn)行，這是大家都希望的事情。例如，如果有兩個(gè)不同的公司都在開發(fā)因特網(wǎng)電話軟件，他們都把RTP合并到他們的產(chǎn)品中，這樣就有希望：使用不同公司電話軟件的用戶之間能夠進(jìn)行通信。
這里需要強(qiáng)調(diào)的是，RTP本身不提供任何機(jī)制來確保把數(shù)據(jù)及時(shí)遞送到接收端或者確保其他的服務(wù)質(zhì)量，它也不擔(dān)保在遞送過程中不丟失信息包或者防止信息包的次序不被打亂。的確，RTP的封裝只是在系統(tǒng)端才能看到，中間的路由器并不區(qū)分那個(gè)IP數(shù)據(jù)報(bào)是運(yùn)載RTP信息包的。
RTP允許給每個(gè)媒體源分配一個(gè)單獨(dú)的RTP信息包流，例如，攝像機(jī)或者麥克風(fēng)。例如，有兩個(gè)團(tuán)體參與的電視會(huì)議，這就可能打開4個(gè)信息包流：兩臺(tái)攝像機(jī)傳送電視流和兩個(gè)麥克風(fēng)傳送聲音流。然而，許多流行的編碼技術(shù)，包括MPEG-1和MPEG-2在編碼過程中都把聲音和電視圖像捆綁在一起以形成單一的數(shù)據(jù)流，一個(gè)方向就生成一個(gè)RTP信息包流。
RTP信息包沒有被限制只可應(yīng)用于單目標(biāo)廣播，它們也可以在一對(duì)多(one-to-many)的多目標(biāo)廣播樹或者在多對(duì)多(many-to-many)的多目標(biāo)廣播樹上傳送。例如，多對(duì)多的多目標(biāo)廣播，在這種應(yīng)用場(chǎng)合下，所有發(fā)送端通常都把他們的RTP信息包流發(fā)送到具有相同多目標(biāo)廣播地址的多目標(biāo)廣播樹上。
16.6.2 RTP信息包標(biāo)題域
RTP標(biāo)題由4個(gè)信息包標(biāo)題域和其他域組成：有效載荷類型(payload type)域，順序號(hào)(sequence number)域，時(shí)間戳(timestamp)域和同步源標(biāo)識(shí)符(Synchronization Source Identifier)域等。RTP信息包的標(biāo)題域的結(jié)構(gòu)如下圖所示：
Payload
Type
(有效載荷類型)
Sequence Number
(順序號(hào))
Timestamp
(時(shí)間戳)
Synchronization Source Identifier
(同步源標(biāo)識(shí)符)
Miscellaneous Fields
(其他)
1. 有效載荷類型
RTP信息包中的有效載荷域(Payload Type Field)的長度為7位，因此RTP可支持128種不同的有效載荷類型。對(duì)于聲音流，這個(gè)域用來指示聲音使用的編碼類型，例如PCM、自適應(yīng)增量調(diào)制或線性預(yù)測(cè)編碼等等。如果發(fā)送端在會(huì)話或者廣播的中途決定改變編碼方法，發(fā)送端可通過這個(gè)域來通知接收端。表16-01列出了目前RTP所能支持的聲音有效載荷類型。
表16-01 目前RTP所能支持的聲音有效載荷類型
有效載荷號(hào)
聲音類型
采樣率(kHz)
數(shù)據(jù)率(kb/s)
0
PCM mu-law
8
64
1
1016
8
4.8
2
G.721
8
32
3
GSM
8
32
6
DVI
16
64
7
LPC
8
2.4
9
G.722
8
48～64
14
MPEG Audio
90
-
15
G.728
8
16
對(duì)電視流，有效載荷類型可以用來指示電視編碼的類型，例如motion JPEG, MPEG-1，MPEG-2或者H.231等等。發(fā)送端也可以在會(huì)話或者期間隨時(shí)改變電視的編碼方法。表16-02列出了目前RTP所能支持的某些電視有效載荷類型。
表16-02 目前RTP所能支持的聲音有效載荷類型
有效載荷號(hào)
電視格式
26
Motion JPEG
28
-
31
H.261
32
MPEG-1 video
33
MPEG-2 video
2. 順序號(hào)
順序號(hào)(Sequence Number Field)域的長度為16位。每發(fā)送一個(gè)RTP信息包順序號(hào)就加1，接收端可以用它來檢查信息包是否有丟失以及按順序號(hào)處理信息包。例如，接收端的應(yīng)用程序接收到一個(gè)RTP信息包流，這個(gè)RTP信息包在順序號(hào)86和89之間有一個(gè)間隔，接收端就知道信息包87和88已經(jīng)丟失，并且采取措施來處理丟失的數(shù)據(jù)。
3. 時(shí)間戳
時(shí)間戳(Timestamp)域的長度為32字節(jié)。它反映RTP數(shù)據(jù)信息包中第一個(gè)字節(jié)的采樣時(shí)刻(時(shí)間)。接收端可以利用這個(gè)時(shí)間戳來去除由網(wǎng)絡(luò)引起的信息包的抖動(dòng)，并且在接收端為播放提供同步功能。
4. 同步源標(biāo)識(shí)符
同步源標(biāo)識(shí)符(Synchronization Source Identifier，SSRC)域的長度為32位。它用來標(biāo)識(shí)RTP信息包流的起源，在RTP會(huì)話或者期間的每個(gè)信息包流都有一個(gè)清楚的SSRC。SSRC不是發(fā)送端的IP地址，而是在新的信息包流開始時(shí)源端隨機(jī)分配的一個(gè)號(hào)碼。
16.6.3 實(shí)時(shí)傳輸控制協(xié)議
實(shí)時(shí)傳輸控制協(xié)議(Real-time Control Protocol，RTCP)也定義在1996年提出的RFC 1889中。多媒體網(wǎng)絡(luò)應(yīng)用把RTCP和RTP一起使用，尤其是在多目標(biāo)廣播中更具吸引力。當(dāng)從一個(gè)或者多個(gè)發(fā)送端向多個(gè)接收端廣播聲音或者電視時(shí)，也就是在RTP會(huì)話期間，每個(gè)參與者周期性地向所有其他參與者發(fā)送RTCP控制信息包，如圖16-14所示。RTCP用來監(jiān)視服務(wù)質(zhì)量和傳送有關(guān)與會(huì)者的信息。對(duì)于RTP會(huì)話或者廣播，通常使用單個(gè)多目標(biāo)廣播地址，屬于這個(gè)會(huì)話的所有RTP和RTCP信息包都使用這個(gè)多目標(biāo)廣播地址，通過使用不同的端口號(hào)可把RTP信息包和RTCP信息包區(qū)分開來。
圖16-14 每個(gè)參與者周期性地發(fā)送RTCP控制信息包
RTCP的主要功能是為應(yīng)用程序提供會(huì)話質(zhì)量或者廣播性能質(zhì)量的信息。每個(gè)RTCP信息包不封裝聲音數(shù)據(jù)或者電視數(shù)據(jù)，而是封裝發(fā)送端和/或者接收端的統(tǒng)計(jì)報(bào)表。這些信息包括發(fā)送的信息包數(shù)目、丟失的信息包數(shù)目和信息包的抖動(dòng)等情況，這些反饋信息對(duì)發(fā)送端、接收端或者網(wǎng)絡(luò)管理員都是很有用的。RTCP規(guī)格沒有指定應(yīng)用程序應(yīng)該使用這個(gè)反饋信息做什么，這完全取決于應(yīng)用程序開發(fā)人員。例如，發(fā)送端可以根據(jù)反饋信息來修改傳輸速率，接收端可以根據(jù)反饋信息判斷問題是本地的、區(qū)域性的還是全球性的，網(wǎng)絡(luò)管理員也可以使用RTCP信息包中的信息來評(píng)估網(wǎng)絡(luò)用于多目標(biāo)廣播的性能。
16.6.4 實(shí)時(shí)流放協(xié)議
實(shí)時(shí)流放協(xié)議(Real-Time Streaming Protocol，RTSP)是一個(gè)剛開始開發(fā)的協(xié)議，它的設(shè)想描述在RFC
播放的數(shù)據(jù)流被分成許多信息包，信息包的大小很適用于客戶機(jī)和服務(wù)器之間的帶寬。當(dāng)客戶機(jī)已經(jīng)接收到足夠多的信息包之后，用戶軟件就可開始播放一個(gè)信息包，同時(shí)對(duì)另一個(gè)信息包解壓縮和接收第三個(gè)信息包。這樣用戶就不需要把整個(gè)媒體文件從服務(wù)器上下載之后就可立即播放。廣播源可以是現(xiàn)場(chǎng)的數(shù)據(jù)流也可以是存儲(chǔ)的數(shù)據(jù)流。
RTSP協(xié)議想要提供控制多種應(yīng)用數(shù)據(jù)傳送的功能，提供一種選擇傳送通道的方法，例如UDP, TCP, IP多目標(biāo)廣播通道，以及提供一種基于RTP協(xié)議的遞送方法。正在設(shè)計(jì)的RTSP將工作在RTP的上層，用來控制和傳送實(shí)時(shí)的內(nèi)容。
RTSP能夠與資源保留協(xié)議一起使用，用來設(shè)置和管理保留帶寬的流式會(huì)話或者廣播。
2326文件中。RTSP是應(yīng)用級(jí)的實(shí)時(shí)流放協(xié)議，它主要目標(biāo)是為單目標(biāo)廣播和多目標(biāo)廣播上的流式多媒體應(yīng)用提供牢靠的播放性能，以及支持不同廠家提供的客戶機(jī)和服務(wù)機(jī)之間的協(xié)同工作能力。
http://publishblog.blogchina.com/blog/tb.b?diaryID=5335330
