【文章內(nèi)容簡(jiǎn)介】 rt）的服務(wù)，不進(jìn)行檢錯(cuò)和糾錯(cuò)，因此經(jīng)常發(fā)生數(shù)據(jù)丟失現(xiàn)象。為保證數(shù)據(jù)的可靠傳輸，在傳輸層使用 TCP 協(xié)議，當(dāng)接收端檢測(cè)到數(shù)據(jù)包丟失或錯(cuò)誤時(shí)，要求發(fā)送端重新發(fā)送，但這 樣不可避免地引起傳輸延時(shí)和占用網(wǎng)絡(luò)帶寬。因此傳統(tǒng)的 TCP/IP 協(xié)議傳輸實(shí)時(shí)音頻、視頻數(shù)據(jù)的能力比較差。當(dāng)然在傳輸用于回放的視頻和音頻數(shù)據(jù)時(shí)， TCP 也是一種選擇。如果有足夠大的緩沖區(qū)和充足的網(wǎng)絡(luò)帶寬，比如在局域網(wǎng)內(nèi)，在 TCP 協(xié)議上，接近實(shí)時(shí)的傳輸也是可能的。但是在大多數(shù)情況下，我們需要再?gòu)V域網(wǎng)內(nèi)傳輸數(shù)據(jù)，在這種丟包率較高、網(wǎng)絡(luò)狀況不好的情況下，利用 TCP 協(xié)議進(jìn)行視頻或音頻通信顯然不是很好的一個(gè)選擇。 TCP 協(xié)議是面向連接的協(xié)議，它的重傳機(jī)制和擁塞控制機(jī)制都是不適合用于實(shí)時(shí)多媒體傳輸?shù)?。下面具體分析網(wǎng)絡(luò)運(yùn)行一下 TCP和其他可靠傳輸層協(xié)議如 XTP 不適合實(shí)時(shí)傳輸?shù)膸讉€(gè)主要原因。 （ 1） .啟動(dòng)速度慢 即便在網(wǎng)絡(luò)運(yùn)行狀況良好，沒(méi)有丟失包的情況下，由于 TCP的建立連接需“三次握手”，嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計(jì) ) 4 因而在初始化的過(guò)程中，需要較長(zhǎng)的時(shí)間。而在一個(gè)實(shí)時(shí)多媒體的應(yīng)用中，我們期望盡量少的延遲。 （ 2） .TCP 的重傳機(jī)制 在 TCP/IP 協(xié)議中，當(dāng)發(fā)送方收不到接收方發(fā)來(lái)的確認(rèn)，并超過(guò)一定的時(shí)間，就認(rèn)定該數(shù)據(jù)已丟失，這時(shí)它將重傳丟失的數(shù)據(jù)包。這一過(guò)程將需要一個(gè)甚至更多的周期，這種重傳機(jī)制對(duì)于實(shí)時(shí)性要求較高的多媒體數(shù)據(jù)傳輸來(lái)說(shuō)是災(zāi)難性的，因?yàn)榻邮詹坏貌坏却?重傳數(shù)據(jù)的到來(lái)，從而造成了延時(shí)和斷點(diǎn)。 （ 3） .TCP 的擁塞控制機(jī)制 TCP 擁塞控制機(jī)制在探測(cè)到有數(shù)據(jù)包丟失時(shí)，它就會(huì)減少它的擁塞窗口。另一方面，音頻、視頻在特定的編碼方式下，產(chǎn)生的編碼數(shù)量是不可能突然改變的，例如，標(biāo)準(zhǔn)的 PCM音頻需要 64Kb/s，加上一些額外控制信息，它不能再低于這個(gè)帶寬要求的網(wǎng)絡(luò)上傳輸。正確的擁塞控制應(yīng)該是變換音頻、視頻信息的編碼方式，調(diào)節(jié)視頻信息的幀頻或者圖像的大小。 （ 4） .報(bào)文頭的大小 TCP 和 XTP 報(bào)文頭都比 UDP 的報(bào)文頭大， TCP 和 的報(bào)文頭為 40 字節(jié)， 為 32字節(jié)，而 RTP 的固定報(bào)文頭為 12字節(jié)，因而它們所能攜帶的信息占整個(gè)報(bào)文的比例相對(duì)來(lái)說(shuō)比較小。并且這些可靠的傳輸協(xié)議不能提供時(shí)間戳和編解碼信息，而這些信息是接收方應(yīng)用程序所需要的，因此它們是不適合進(jìn)行多媒體信息傳輸?shù)摹? RTP 的引入 基于上一節(jié)的分析，我們可以清楚的認(rèn)識(shí)到 TCP 協(xié)議是不適合用來(lái)進(jìn)行傳輸實(shí)時(shí)多媒體數(shù)據(jù)的，因此考慮選擇 UDP作為 RTP 的傳輸層協(xié)議。 UDP 是一種面向無(wú)連接的數(shù)據(jù)報(bào)方式，當(dāng)通信一旦開(kāi)始，發(fā)送方就不斷地發(fā)送數(shù)據(jù)而不需要接收端做出確認(rèn)信息。它取消了重發(fā)校驗(yàn)機(jī)制，因此能夠達(dá)到 較高的通信速率，但不能保證報(bào)文的先后順序，也不能保證數(shù)據(jù)傳輸?shù)目煽啃?。因?yàn)橐纛l、視頻碼流比傳統(tǒng)數(shù)據(jù)對(duì)實(shí)時(shí)性要求更高，即使少量的時(shí)延，對(duì)音頻、視頻播放來(lái)說(shuō)也是無(wú)法忍受的，但它們對(duì)于少量的包丟失卻不太敏感。所以本文在 IP網(wǎng)絡(luò)上建立的實(shí)時(shí)音頻傳輸系統(tǒng)采用面向無(wú)連接的 UDP 協(xié)議進(jìn)行傳輸。但是 UDP 傳輸?shù)牟豢煽繋?lái)丟包、亂序等問(wèn)題，所以如果在應(yīng)用層采用合適的封裝方式并增加一些有利于媒體播放的信息進(jìn)行傳輸，可以使得接收端在一定程度上彌補(bǔ)傳輸帶來(lái)的損失，這就是引入 RTP的原因。同時(shí)如果收發(fā)端能夠?qū)崟r(shí)了解網(wǎng)絡(luò)和傳輸狀況，就 可以適當(dāng)調(diào)節(jié)自己嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計(jì) ) 5 的任務(wù)，最終使得在接收端能夠達(dá)到最好的效果，由此引入 RTCP 傳輸控制協(xié)議對(duì)傳輸狀況進(jìn)行實(shí)時(shí)監(jiān)測(cè)和報(bào)告。 RTP（ Realtime Transport Protocol）實(shí)時(shí)傳輸協(xié)議，是由 Inter 工程任務(wù)組（ IETF）的音頻 /視頻傳輸工作組制定，主要用于 VoIP、視頻等實(shí)時(shí)多媒體信息的傳輸。音頻和視頻編碼信數(shù)據(jù)均封裝在 RTP 協(xié)議數(shù)據(jù)包中， RTP 提供定時(shí)信息和數(shù)據(jù)報(bào)序號(hào)，供接收方重組數(shù)據(jù)包，但是 RTP本省并不能為按順序傳送數(shù)據(jù)包提供可靠的傳輸機(jī)制，也不提供流量控制或擁塞控制，它依靠 RTCP 提供這些服務(wù)。通常 RTP 算法并不作為一個(gè)獨(dú)立的網(wǎng)絡(luò)層來(lái)實(shí)現(xiàn)，而是作為應(yīng)用程序代碼的一部分。 RTCP（ Realtime Transport Control Protocol）實(shí)時(shí)傳輸控制協(xié)議，它提供服務(wù)質(zhì)量的統(tǒng)計(jì)信息及提供傳輸可靠性的保證和流量的擁塞控制機(jī)制。 第二章 RTP/RTCP 協(xié)議介紹 實(shí)時(shí)傳輸協(xié)議的簡(jiǎn)單介紹 RTP 全名是 Realtime Transport Protocol（實(shí)時(shí)傳輸協(xié)議）。它是 IETF 提出的一個(gè)標(biāo)準(zhǔn)，對(duì)應(yīng)的 RFC 文檔為 RFC3550（ RFC1889 為其過(guò)期版 本）。 RFC3550 不僅定義了 RTP，而且定義了配套的相關(guān)協(xié)議 RTCP（ Realtime Transport Control Protocol，即實(shí)時(shí)傳輸控制協(xié)議）。 RTP 協(xié)議包括 RTP（ Realtime Transport Protocol）實(shí)時(shí)傳輸協(xié)議和 RTCP（ Realtime Transport Control Protocol）實(shí)時(shí)傳輸控制協(xié)議這兩個(gè)協(xié)議。其中 RTP 被定義為一對(duì)一或一對(duì)多的傳輸情況下工作，實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)的傳輸，但是它并不提供任何傳輸可靠性的保證和流量的擁塞控制機(jī)制，這些工作將 由 RTCP 來(lái)完成。 RTP 和 RTCP 配合使用，能以有效的反饋和最小的開(kāi)銷(xiāo)使傳輸效率最佳化，所以特別適合傳輸實(shí)時(shí)數(shù)據(jù)。 RTP 為交互式 音頻、視頻等具有實(shí)時(shí)特性的數(shù)據(jù)提供端到端的傳輸。它不是典型意義上的傳輸層協(xié)議，因?yàn)樗⒉痪邆湟粋€(gè)典型傳輸協(xié)議的所有特點(diǎn)。例如： RTP 沒(méi)有連接的概念，它必須建立在底層的面向連接的或無(wú)連接的傳輸協(xié)議之上；本身不依賴于特別的地址格式，而需要底層傳輸協(xié)議支持成幀和分段。一般來(lái)說(shuō)， RTP 是在傳輸層協(xié)議之上作為應(yīng)用程序的一部分加以實(shí)現(xiàn)的。 在 IP網(wǎng)絡(luò)上， RTP 協(xié)議一般是運(yùn)行在 UDP 之上。首 先 RTP 可以利用 UDP 的多路復(fù)用功能來(lái)分別傳輸 RTP 數(shù)據(jù)包和 RTCP 控制包。其次， RTCP 能實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)傳輸和服務(wù)質(zhì)量，嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計(jì) ) 6 不需要下層協(xié)議來(lái)保證實(shí)時(shí)業(yè)務(wù)的服務(wù)質(zhì)量。再次，由于 UDP 的傳輸時(shí)延低于 TCP，能與音頻和視頻流很好匹配，保證了實(shí)時(shí)性的要求。因此，在實(shí)際應(yīng)用中， RTP/RTCP/UDP 用于音頻、視頻媒體，而 TCP用于數(shù)據(jù)和控制信令的傳輸。當(dāng)然， RTP 還可以和其他合適的底層網(wǎng)絡(luò)和傳輸協(xié)議一起工作。例如它也可以在 TCP 或 ATM 等其它協(xié)議之上工作。如果底層網(wǎng)絡(luò)支持多點(diǎn)傳播的話， RTP 還支持使用多點(diǎn)傳播向多個(gè)目的 端點(diǎn)發(fā)送數(shù)據(jù)。下圖表示了RTP 與各種網(wǎng)絡(luò)協(xié)議的關(guān)系。 RTP 與各種網(wǎng)絡(luò)協(xié)議的關(guān)系 RTP 協(xié)議的三類(lèi)主要應(yīng)用 （ 1）簡(jiǎn)單的多播音頻會(huì)議 這里的多播主要指 IP 網(wǎng)絡(luò)的多播業(yè)務(wù)用于語(yǔ)音通信。它通過(guò)一個(gè)多播地址和一對(duì)端口來(lái)實(shí)現(xiàn)。一個(gè)端口用于 RTP傳輸音頻數(shù)據(jù)，另一個(gè)端口用于傳輸 RTCP 控制包。這個(gè)地址和端口的信息要發(fā)布給各個(gè)與會(huì)者。當(dāng)一個(gè)與會(huì)者將要發(fā)言時(shí)，其話音將以每 20 毫秒為一幀的間隔分成許多音頻數(shù)據(jù)包，并在數(shù)據(jù)包前加上 RTP 頭，然后按照 RTP 包頭 在前，數(shù)據(jù)在后的順序?qū)⑺鼈兎庋b在 UDP 包中。 RTP 包頭可以指明語(yǔ)音編程類(lèi)型（如 PCM， ADPCM或 LPC），以便發(fā)送方在會(huì)議過(guò)程中改變編碼的類(lèi)型了。 Ier 和其他報(bào)文網(wǎng)絡(luò)一樣，會(huì)有丟包，報(bào)文失序以及報(bào)文的不同時(shí)延問(wèn)題。為嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計(jì) ) 7 了克服這些不利因素， RTP 包頭攜帶時(shí)間戳和序列號(hào)，這樣接收方就可以重建源產(chǎn)生的計(jì)時(shí)信息，語(yǔ)音報(bào)文可以按照 20 毫秒的間隔連續(xù)回放了。其計(jì)時(shí)信息是接收方按照會(huì)議中不同的 RTP源分別重建的。同時(shí)，接收方也可以利用序列號(hào)來(lái)估算包丟失數(shù)。 與會(huì)者在會(huì)議進(jìn)行期間可能加入或退出，因此了解在某一 時(shí)刻有哪些人參加了會(huì)議，以及它們的語(yǔ)音數(shù)據(jù)接收情況是很有必要的。因此每個(gè)與會(huì)者的應(yīng)用程序都周期性地廣播含有自己名字的 RTCP 接收?qǐng)?bào)告。 RTCP 接收?qǐng)?bào)告表明了這一與會(huì)者接收語(yǔ)音數(shù)據(jù)的效果，同時(shí)它可以用來(lái)控制自適應(yīng)編碼器。另外，用戶也可以使用名字以外的其它表示信息，這要視控制帶寬的情況而定。一個(gè)與會(huì)者離開(kāi)會(huì)議時(shí)要發(fā)送 RTCP BYE 報(bào)文，以通知其它的參與者自己離開(kāi)了。 （ 2）音頻和視頻會(huì)議 如果在一個(gè)會(huì)議里同時(shí)有音頻和視頻，它們將采用獨(dú)立的 RTP 會(huì)話來(lái)傳送，兩個(gè)媒體流的 RTCP 報(bào)文采用不同的 UDP 端口對(duì)或多播地 址。在 RTP 層音頻和視頻并沒(méi)有直接的聯(lián)系，除非某個(gè)特定的用戶需要在 RTCP 報(bào)文中使用相同的標(biāo)識(shí)將這兩個(gè) RTP 會(huì)話聯(lián)系起來(lái)。音頻和視頻采用獨(dú)立的 RTP 會(huì)話的原因之一是可以允許部分與會(huì)者根據(jù)需要只接收者音頻或視頻流。盡管采用獨(dú)立的 RTP 會(huì)話，同源的音頻和視頻可以根據(jù) RTCP 的時(shí)間信息進(jìn)行同步回放。 （ 3）混合器和轉(zhuǎn)換器 當(dāng)某一與會(huì)者采用低速鏈路接入會(huì)議，而大部分與會(huì)者采用高速鏈路接入，如果讓每個(gè)與會(huì)者使用窄帶，低質(zhì)量的語(yǔ)音編碼器，這顯然不是一個(gè)很好的解決辦法，這時(shí)就需要使用“混合器”?；旌掀鳎?Mixer）是一個(gè) RTP 層的中繼設(shè)備，將它置于低速鏈路端，它對(duì)到來(lái)的音頻報(bào)文按 20 毫秒的間隔重新進(jìn)行同步，然后將重構(gòu)的音頻數(shù)據(jù)流混合成一路窄帶的數(shù)據(jù)流轉(zhuǎn)發(fā)給窄帶用戶。這些新的報(bào)文可以按照單播或多播的形式發(fā)送給接收者。 RTP包頭提供了一個(gè)字段 CSRC，使混合器可以辨別混合報(bào)文的各個(gè)信源，這樣在接收端就可以正確獲知誰(shuí)是發(fā)送者。 “轉(zhuǎn)換器”（ Translators）也是一種 RTP 層的中繼設(shè)備，當(dāng)某些與會(huì)者不能通過(guò)多播（ multicast）方式直接連接到會(huì)與，比如它們處在不讓任何 IP 包通過(guò)的應(yīng)用級(jí)防火墻之后，這時(shí)就需要用到“轉(zhuǎn)換器” 。在防火墻內(nèi)外各安裝一個(gè)轉(zhuǎn)換器，當(dāng)外面的轉(zhuǎn)換器接收到安全的數(shù)據(jù)包后，將它們以隧道方式直接發(fā)送給防火墻內(nèi)的轉(zhuǎn)換器，由它轉(zhuǎn)發(fā)給防火墻內(nèi)的用戶。 混合器和轉(zhuǎn)換器可以針對(duì)很多不同的目的而設(shè)計(jì)。比如視頻混合器，它可以將多路不同的視頻流的單個(gè)圖像混合成一路視頻流，模擬一個(gè)群體場(chǎng)景。轉(zhuǎn)換器的一個(gè)應(yīng)用例子是嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計(jì) ) 8 連接一些只能使用 IP/UDP 的主機(jī)和只能使用 STII 主機(jī)，或者對(duì)單個(gè)信源的視頻流進(jìn)行逐包的編碼翻譯，而不作重新同步或混合。 RTP 數(shù)據(jù)包格式 2． 3． 1 RTP 數(shù)據(jù)包格式 RTP 報(bào)文頭格式（見(jiàn) RFC3550 Page12）： 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +++++++++++++++++++++++++++++++++ |V=2|P|X| CC |M| PT | sequence number | +++++++++++++++++++++++++++++++++ | timestamp | +++++++++++++++++++++++++++++++++ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +++++++++++++++++++++++++++++++++ 以上域具體意義如下： （ 1）版本 (V):2 比特 此域定義了 RTP 的版本 .此協(xié)議定義的版本是 2.(值 1被 RTP 草案版本使用 ,值 0 用在最初 vat語(yǔ)音工具使用的協(xié)議中 .) （ 2）填料 (P):1 比特 若填料比特被設(shè)置 ,此包包含一到多個(gè)附加在末端的填充比特 ,不是負(fù)載的一部分 .填料的最后一個(gè)字節(jié)包含可以忽略多少個(gè)填充比特 .填料可能用于某些具有固定長(zhǎng)度的加密算法 ,或者在底層數(shù)據(jù)單元中傳輸多個(gè) RTP 包 . （ 3）擴(kuò)展 (X):1 比特 若設(shè)置擴(kuò)展比特 ,固定頭 (僅 )后面跟隨一個(gè)頭擴(kuò)展 . （ 4） CSRC 計(jì)數(shù) (CC):4 比 特 CSRC 計(jì)數(shù)包含了跟在固定頭后面 CSRC 識(shí)別符的數(shù)目 . （ 5）標(biāo)志 (M):1比特 標(biāo)志的解釋由具體協(xié)議規(guī)定 .它用來(lái)允許在比特流中標(biāo)記重要的事件 ,