rtp-實時軟件傳輸協(xié)議-資料下載頁
2025-05-14 04:58本頁面
【正文】 可以用在某些與之相適配的底層網(wǎng)絡和傳輸協(xié)議中。RTP可以在網(wǎng)絡的允許下利用多點傳送功能向多個目標發(fā)送數(shù)據(jù)。 但是要注意到，RTP本身不能對傳輸?shù)募皶r性及傳輸?shù)馁|量提供保證，這些是依靠它的下層服務來實現(xiàn)的。它也不能保證在傳輸過程中傳輸順序都是有序的，就像他不能確定基層的網(wǎng)絡是可靠的，其在網(wǎng)絡上傳送的包是按順序的一樣。RTP中對包都進行了編號，那樣就允許接受者重建包的順序，而且這些編碼可以用來測定包所在的位子，比如一個視頻，完全依次進行編碼是沒有必要的。 RTP最初設計是為了滿足多人視頻會議，但現(xiàn)在已經(jīng)不僅僅局限在這個方面了，數(shù)據(jù)的連續(xù)存儲，互動的分布式模擬，以及控制和測量部門都能找RTP的身影。 本文對RTP的定義包括兩個方面：[1].實時傳輸協(xié)議，用來傳輸具有實時特征的數(shù)據(jù)；[2].實施傳輸控制協(xié)議RTCP，用來監(jiān)測服務的質量以及傳達某個正在進行的會議中各個成員的信息。對于RTCP第二個方面的應用，在一些不是非常嚴格的會議我們已經(jīng)得到了應用：一般這些會議沒有復雜的成員控制和建立，那么對所有應用程序控制的交流是沒有必要的。這種情況也許會被部分或者全部的包含在一個獨立的會議控制中，這個已經(jīng)超出了本文的討論范圍。 RTP是繼應用層框架原理以后新的協(xié)議類型，他整合層的處理。也就是說RTP對于一個應用程序所要求得信息處理已經(jīng)不再是作為一個單獨的層去進行，而是隨著整合進該程序的進行過程中，同時處理。RTP有意成為一個不完整的協(xié)議框架。本文闡述這些功能，希望在那些適合RTP的應用程序中RTP能得到充分的發(fā)揮。而不像一些傳統(tǒng)的協(xié)議那樣，需要通過推廣或者是機構的授權來增加附加功能。此外，如果想要知道對于某一個特定程序的RTP的描述，你可以在一些相關的書中尋找（見12章）：[1].一個概括地說明文檔，定義一系列載荷類型編碼和相對應的載荷格式。同時也說明了在某些特定的類型的應用程序中RTP的擴展和修改。以及各一個具有代表性的應用程序的炒作過程。一個為視頻和音頻數(shù)據(jù)做的概要說明可以在RFC TBD里找到。[2].在和類型的描述文檔，定義了一個特定的載荷，比如音頻和視頻編碼是如何通過RTP來傳輸?shù)?。對于實時服務的討論，對于RTP設計及其運行時所遵循的算法和背景的討論我們可以在第二節(jié)找到。 一些RTP程序，不管是試驗性質的還是商業(yè)性質的從設計階段上升到了實踐階段。這些程序包括音頻和視頻工具以及一些診斷工具比如交通監(jiān)視器。這些工具的用戶數(shù)量已有成千上萬。但是現(xiàn)在的英特網(wǎng)還無法支持實時服務全部潛在的需求，利用RTP的高速寬帶服務，比如視頻，將會嚴重的降低網(wǎng)絡其他服務的質量。所以，執(zhí)行者應該采取合適的防范措施來限制那些次要的寬帶利用。應用程序文件會清楚的略述這些限制以及在英特網(wǎng)和其他網(wǎng)絡服務中高速寬帶的實時服務可能會帶來的影響。 2 RTP 使用環(huán)境 這個章節(jié)我們將討論RTP的使用方面。我們將會通過實例來說明使用RTP程序的一些基本操作，但不限制使用的是什么樣的RTP。在這些舉例中，RTP運載于IP和UDP之上，在其之后是一些為了視頻和音頻而已經(jīng)確立的協(xié)議，這些協(xié)議可以在同類書籍中找到。 簡單的多點音頻會議 一個工作組要討論一個最近的工作草案，他們可以通過英特網(wǎng)的多點服務來進行語音交流。通過一些機制分配，工作組組長獲得一個多點傳送的地址以及兩個端口，一個是用來傳輸語音數(shù)據(jù)，一個是用來控制包的傳輸，這個地址同時也被分送到每個成員那里。如果有保密的需要，數(shù)據(jù)及控制包可以被加密（），當然這樣的話解密鑰匙也必須要發(fā)布出去，關于機制的具體分布與安排不在RTP的討論范圍之內(nèi)。 參加音頻會議的人以包的形式傳輸語音數(shù)據(jù)，平均20毫秒一個。每個包有一個RTP報頭。RTP 報頭及其數(shù)據(jù)依次放入UDP包中。RTP報頭用來說音頻編碼的類型（比如PCM ,ADPCM, LPC）,這樣的方式可以讓數(shù)據(jù)發(fā)送者在會議中改變編碼方式，這樣的話，我們可以單獨的為一個低速會議成員安排接入方式，同時我們也可以對網(wǎng)絡的擁堵做出反應。 英特網(wǎng)，和其他的封寶試的網(wǎng)絡一樣，有時候會丟失包或者發(fā)生不可預知的時間延遲，為了處理這種情況，RTP報頭包含了一個時間信息，和一個序列號碼，那樣就允許接受者重新排序，在這個例子中，音頻包每隔20毫秒發(fā)出一個，會議中對于這些RTP包時序的重組一直在獨立的進行著。序列號碼還可以用來估計有多少包在傳輸中丟失了。 鑒于工作組成員會在開會時進入或者離開，那么清楚的知道到底誰在參加會議以及到底他們接受的音頻數(shù)據(jù)質量如何是很有用的。于是每一個遠程應用程序會定時的往RTCP發(fā)送一個接收報告，報告里會附上他們的名字。這個報告會指出現(xiàn)在對于講話者數(shù)據(jù)接收如何從而用來控制合適的編碼。除了用戶的名字之外，我們還會用到其他的鑒別信息來控制款待限制。一個節(jié)點會發(fā)送一個“BYE”包（）當他離開的時候。 如果在一個會議中同時要用到視頻和音頻的話，他們在傳輸?shù)倪^程中，用的是互相獨立的RTP層，兩種媒體的RTCP包也是用不同的UDP端口或者是不同的多點傳送地址。在音頻和視頻兩個層之間沒有直接的連接。除非是一個成員要以同一個規(guī)范化的名字參加兩個會議層，這種情況下連個層會被連在一起。 把兩種媒體分割開來可以使會議成員自由的選擇一種或兩種媒體。盡管是分割的，但是通過RTCP包中的時間信息，我們完全可以是兩種媒體同步起來。 混頻和翻譯 到目前為止，我們一直假定所有的網(wǎng)站都是接受相同類型的媒體數(shù)據(jù)，但事實上，這種假定是不合理的。考慮到有些成員，以低速網(wǎng)絡接入一個大部分成員是高速網(wǎng)絡的會議中，我們可以在低速網(wǎng)絡的區(qū)域放一個混頻器那樣我們就不用要求每一個成員都要以低速，低質的音頻方式接入了。這個混頻器重新同步音頻包，以恒定的20毫秒的間隔重建發(fā)送者的音頻信號。把這些改造過的音頻流混合成一個單獨的流，這樣就把這些音頻編碼轉化成了適用于低速寬帶面下低速連接的數(shù)據(jù)包流。這些包可以被斷點傳送給一個用戶也可以被多點傳送給不同用戶的不同地址。RTP報頭包含了混合器的方法，這樣即使包被混合了，接受者還是可以正確的確認誰在發(fā)言?！ ∫纛l會議中，一些用戶雖然是通過高速寬帶連接，但他們有可能依然不可以直接通過IP被多點傳送。比如，他們運行了一個應用層的防火墻，就會阻止任何IP包通過。對于這些站點，混頻可能會失敗，這種情況下我們可以利用另一個方法,翻譯。防火墻的兩端都裝上翻譯器，這樣防火墻的兩端好像形成了一個相連的漏斗，多點傳送包，就可以安全的從外面?zhèn)鞯嚼锩?，然后防火墻?nèi)部的翻譯器再一次對網(wǎng)絡內(nèi)部進行多點傳送。12 /
規(guī)章制度相關推薦
鄂ICP備17016276號-1