Internet多媒體協(xié)議

1、第十章 Internet多媒體協(xié)議概述 本章主要介紹下列支持多媒體傳輸?shù)膮f(xié)議： IGMP MBONE RTP RTCP RSVP12/4/20211有關(guān)概念 RTP會(huì)話：利用RTP進(jìn)行通信的各方之間的映射關(guān)系。對(duì)于參與通信的每臺(tái)主機(jī)，會(huì)話由一對(duì)特定的目標(biāo)傳輸?shù)刂?網(wǎng)絡(luò)地址加上RTP端口和RTCP端口)定義。在多媒體會(huì)話中，每種媒體都由一個(gè)單獨(dú)的RTP會(huì)話傳輸；使用單獨(dú)的RTCP分組。這些RTP會(huì)話通過(guò)不同的端口對(duì)和或不同的組播地址加以區(qū)別。同步源(Synchronization Source，SSRC)：RTP分組流的源點(diǎn)，SSRC標(biāo)識(shí)符包含在RTP首部中。從特定同步源發(fā)出的所有分組組成同一定

2、時(shí)和序號(hào)空間的一部分，所以接收端可以根據(jù)同步源將收到的分組進(jìn)行分類，從而在本地重放。 12/4/20212參與源(Contributing Source,CSRC)：特定RTP分組流的源點(diǎn)。該流將作為RTP混合器的輸入之一。混合器將在形成的分組的RTP首部中插入與該分組源點(diǎn)相應(yīng)的一組SSRC標(biāo)識(shí)?；旌掀?Mixer)：從若干數(shù)據(jù)源接收RTP分組的中間系統(tǒng)，該系統(tǒng)可能修改數(shù)據(jù)格式，按特定方式組合分組，然后創(chuàng)建新的RTP分組。由于各輸入源點(diǎn)的定時(shí)可能不同步，混和器將會(huì)調(diào)整各輸人流的定時(shí)，然后為組合流創(chuàng)建自己的定時(shí)。所有由混合器創(chuàng)建的數(shù)據(jù)分組的同步源就是該混合器。翻譯器(Translator)：在轉(zhuǎn)

3、發(fā)RTP分組時(shí)保持分組的同步源標(biāo)識(shí)不變的中間系統(tǒng)。翻譯器的實(shí)例包括：在不進(jìn)行混合操作的同時(shí)轉(zhuǎn)換編碼的設(shè)備，將組播轉(zhuǎn)換為單播的中繼器以及防火墻中的應(yīng)用級(jí)過(guò)濾器。監(jiān)視器(Monitor)：接收RTP會(huì)話參與者發(fā)送的RTP分組的應(yīng)用程序，它以分布監(jiān)視、故障偵測(cè)和長(zhǎng)期統(tǒng)計(jì)為目標(biāo)對(duì)當(dāng)前服務(wù)質(zhì)量進(jìn)行估算。12/4/20213IP組播 IP組播系統(tǒng)：一對(duì)多，數(shù)據(jù)分組只創(chuàng)建一次，然后被組播服務(wù)器（ROUTER）復(fù)制多份，發(fā)往服務(wù)器的輸出端口并分發(fā)給相連的所有接收端。 主要應(yīng)用：音頻會(huì)議和視頻會(huì)議。遠(yuǎn)程教育、會(huì)議和白板交談等。 地址格式：1110+組播地址（28） 從 224.0.0.0 到 239.255.2

4、55.255 組播方式：組播遂道。 組播數(shù)據(jù)封裝在IP數(shù)據(jù)報(bào)字段中傳輸，在INTERNET中的轉(zhuǎn)發(fā)過(guò)程依傳統(tǒng)的IP首部。 路由器上運(yùn)行組播軟件。12/4/20214IGMP操作 IGMP支持組播操作。它允許一主機(jī)加入組。路由器知道組的信息，先向主機(jī)發(fā)送IGMP查詢；IGMP報(bào)告操作允許主機(jī)通知ROUTER它是否希望加入特定的組播組。當(dāng)一臺(tái)主機(jī)欲加入某個(gè)多播組時(shí)，會(huì)發(fā)出“主機(jī)成員報(bào)告”的IGMP消息通知多播路由器。當(dāng)多播路由器接收到發(fā)給那個(gè)多播組的數(shù)據(jù)時(shí)，便會(huì)將其轉(zhuǎn)發(fā)給所有的多播主機(jī)。多播路由器還會(huì)周期性地發(fā)出“主機(jī)成員查詢”的IGMP消息，向子網(wǎng)查詢多播主機(jī)，若發(fā)現(xiàn)某個(gè)多播組已沒有任何成員，則

5、停止轉(zhuǎn)發(fā)該多播組的數(shù)據(jù)。此外，當(dāng)支持IGMP v2的主機(jī)（如Windows 98/2000計(jì)算機(jī)）退出某個(gè)多播組時(shí)，還會(huì)向路由器發(fā)送一條“離開組”的IGMP消息，以通知路由器停止轉(zhuǎn)發(fā)該多播組的數(shù)據(jù)。但只有當(dāng)子網(wǎng)上所有主機(jī)都退出某個(gè)多播組時(shí)，路由器才會(huì)停止向該子網(wǎng)轉(zhuǎn)發(fā)該多播組的數(shù)據(jù)。12/4/20215MBONEMulticast Backbone的 縮 寫， 一 種 高 速 虛 擬 網(wǎng) 絡(luò)， 它 可 以 將 信 息 包 同 時(shí) 發(fā) 送 到 多 個(gè)Internet站 點(diǎn)， 適 用 于 音 頻、 視 頻 的 傳 輸。1992年，MBONE在IETF（Internet工 程 工 作 組） 的Audi

6、ocast試 驗(yàn) 中， 把IETF的 會(huì) 議 內(nèi) 容 通 過(guò) 聲 音、 圖 像 進(jìn) 行 實(shí) 時(shí) 傳 播。MBONE已 成 為Internet的 一 部 分， 是 支 持 廣 播 式 傳 輸 的 關(guān) 鍵 部 件。最初連入了 4 個(gè)國(guó)家的 40 個(gè)子網(wǎng)。截至 1996 年 4 月，MBONE 的規(guī)模已經(jīng)遍及 25 個(gè)國(guó)家的 2800 多個(gè)子網(wǎng)。在 MBONE 上的著名 Multicast 服務(wù)有 NASA space shuttle missions、U.S. House and Senate sessions、live satellite weather photos 等等。新的應(yīng)用與服務(wù)的出現(xiàn)

7、，使得Internet Multicasting 技術(shù)得到了迅速的發(fā)展。 12/4/20216 實(shí)時(shí)協(xié)議(RTP)用于支持實(shí)時(shí)數(shù)據(jù)流。典型的實(shí)時(shí)應(yīng)用是語(yǔ)音和視頻系統(tǒng)。RTP為具有實(shí)時(shí)特征的數(shù)據(jù)，提供了端到端的傳輸服務(wù)。服務(wù)包括負(fù)載類型標(biāo)識(shí)、定序、時(shí)間戳和傳輸監(jiān)視。應(yīng)用通常在UDP協(xié)議之上運(yùn)行RTP，如果底層網(wǎng)絡(luò)支持組播，那么RTP還支持到組播地址的數(shù)據(jù)傳輸。它依靠底層服務(wù)提供保證及時(shí)傳輸或保證其他服務(wù)質(zhì)量。RTP不能防止傳輸過(guò)程出現(xiàn)的丟包和亂序現(xiàn)象，而且它也不要求底層網(wǎng)絡(luò)是可靠的或按順序傳輸分組。RTP代表了一種新型的協(xié)議，RTP將提供特定應(yīng)用所需的信息，而且通常與應(yīng)用處理集成在一起，而不是作

8、為單獨(dú)的協(xié)議層實(shí)現(xiàn)。RTP是通過(guò)修改和或增加首部來(lái)實(shí)現(xiàn)新功能的。實(shí)時(shí)協(xié)議RTP12/4/20217翻譯器和混合器RTP翻譯器將負(fù)載從一種語(yǔ)法轉(zhuǎn)換(編碼)為另一種語(yǔ)法。翻譯器的任務(wù)是接收工作站的數(shù)據(jù)流，將其轉(zhuǎn)換(編碼)為以下格式:(1)符合傳輸網(wǎng)絡(luò)的帶寬限制，和/或(2)符合另一邊的用戶工作站的帶寬限制。 RTP混合器將多個(gè)源組合為一個(gè)流。通常，混合器主要執(zhí)行音頻操作，不會(huì)降低接收方收到的信號(hào)質(zhì)量。它只是將各信號(hào)組合為一種統(tǒng)一的格式。RTP混合器特別適用于音頻會(huì)議。一般來(lái)說(shuō)它不太適合做視頻會(huì)議，因?yàn)閷⒍鄠€(gè)視頻源組合成一種格式比較困難。RTP混合器并不是將每種源負(fù)載轉(zhuǎn)換為一種不同的格式。它在保留原

9、來(lái)格式的基礎(chǔ)上將不同源負(fù)載組合為一個(gè)流。而另一方面，如果視頻流是簡(jiǎn)單的脈沖代碼調(diào)制(PCM)的流，則可以將各源負(fù)載的值加起來(lái)，從而將它們組合為單一的流。12/4/20218 RTP報(bào)文都使用同一種格式。RTP支持應(yīng)用層成幀。如G.722，JPEG視頻標(biāo)準(zhǔn)。RTP協(xié)議數(shù)據(jù)單元（PDU）封裝在用戶UDP和IP（PDU）中傳輸。 RTP無(wú)默認(rèn)的UDP端口。由于主機(jī)在各種不同的應(yīng)用中都要利用RTP，給一默認(rèn)口不夠。但是當(dāng)應(yīng)用沒有其他可用的端口時(shí)，RTP將5004端口作為指定端口。RTP規(guī)范要求不管選取哪個(gè)端口其值必須是偶數(shù)。這是由于比RTP端口值只大1的端口(對(duì)于指定端口為5005)被用于傳送實(shí)時(shí)控制

10、協(xié)議RTCP的業(yè)務(wù)量的緣故。 格式見圖P179。RTP報(bào)文12/4/20219RTP報(bào)文報(bào)文同步源ID是RTP報(bào)文的最初發(fā)送者的標(biāo)識(shí)。該發(fā)送者負(fù)責(zé)計(jì)算報(bào)文的序列號(hào)和時(shí)間戳。RTP翻譯器保留該標(biāo)識(shí)，但RTP混合器將成為新的同步源，而其他(最初的)源將成為參與源，這些參與源記錄在報(bào)文的參與源ID字段中。 通信雙方利用序列號(hào)和時(shí)間戳達(dá)到下列目的：(1)確定數(shù)據(jù)按正確j頃序到達(dá)；(2)檢查丟包現(xiàn)象；(3)同步數(shù)據(jù)流。 值得注意的是，RTP并沒有定義應(yīng)用數(shù)據(jù)字段的格式，而是交給應(yīng)用完成。因此，RTP可以攜帶各種類型的應(yīng)用數(shù)據(jù)。P180頁(yè)列出了RTPPDU數(shù)據(jù)字段可以攜帶的各種載荷類型。該表公布以后，業(yè)界

11、又定義了可由RTP承載的其他標(biāo)準(zhǔn)。例如，H324、H263和C723分別是壓縮音頻流和視頻流的最新標(biāo)準(zhǔn)。12/4/202110RTP復(fù)用復(fù)用操作操作 RTP復(fù)用功能由目標(biāo)傳輸?shù)刂罚⊿OCKET）提供。復(fù)用分組格式 除了時(shí)間戳、標(biāo)記位和SSRC之外，RTP首部的其他字段都保持原有定義。復(fù)用分組的格式如圖所示。 載荷類型：負(fù)載類型字段標(biāo)識(shí)此RTP分組為復(fù)用分組。 時(shí)間戳：該協(xié)議要求分組中所有復(fù)用流必須具有相同的時(shí)鐘頻率(例如，音頻的采樣頻率)，而且按照一定時(shí)間間隔產(chǎn)生媒體幀，該時(shí)間間隔是一個(gè)公共的幀持續(xù)時(shí)間的整數(shù)倍。 標(biāo)記位：復(fù)用操作沒有使用此字段，它的值設(shè)置為0。復(fù)用首部中為每個(gè)用戶都包含一個(gè)標(biāo)

12、記位。 SSRC：此字段用于標(biāo)識(shí)特定的用戶組(而不是單個(gè)用戶)，這些用戶的幀是同步的。 復(fù)用(MUX)首部包含參與復(fù)用操作的所有用戶的信息。它還包含載荷類型的信息以及用于每個(gè)用戶載荷的標(biāo)識(shí)值。12/4/202111負(fù) 責(zé) 管理發(fā)送應(yīng)用和接收應(yīng)用的實(shí)時(shí)會(huì)話。該協(xié)議支持發(fā)送者向接收者通報(bào)后者應(yīng)該接收到的RTP數(shù)據(jù)，它還支持接收者直接向發(fā)送者報(bào)告。這種思想在IP組播中非常有效，因?yàn)樗梢詸z查分組分發(fā)中的故障。發(fā)送者和接收者報(bào)告可能占用大量的帶寬，RTCP提供了一種定義這些報(bào)告發(fā)送頻率的機(jī)制。其思想是無(wú)論多少用戶參與會(huì)話，會(huì)話的總體數(shù)據(jù)流保持恒定。 所有RTCP分組的源端都發(fā)送源說(shuō)明，描述發(fā)送數(shù)據(jù)的那

13、些應(yīng)用的特征。這些報(bào)文包含一些定義屬性的源說(shuō)明項(xiàng)，例如電子郵件地址、地理位置、電話號(hào)碼和郵箱地址。會(huì)議(視頻或音頻)的參與者可以在任何時(shí)間通過(guò)發(fā)送一個(gè)稱為“bye”的注銷報(bào)文而退出會(huì)議。RTCP報(bào)文可以針對(duì)特定應(yīng)用進(jìn)行編碼。RTCP并不關(guān)心報(bào)文的內(nèi)容，RTCP操作在應(yīng)用間透明地傳輸報(bào)文。RTCP12/4/202112RTCP分組分組有五種分組類型：200204會(huì)話的發(fā)送者每隔一段時(shí)間向接收者發(fā)送者報(bào)告。各字段內(nèi)容見P184RTCP報(bào)文格式。抖動(dòng)方程：到達(dá)時(shí)間間隔抖動(dòng)是兩個(gè)分組的相對(duì)傳輸時(shí)間的差異。它是分組的RTP時(shí)間戳和分組到達(dá)時(shí)接收者時(shí)鐘之間的差。 如下面的方程所示，它等于兩個(gè)分組的“相對(duì)傳

14、輸時(shí)間”之差：相對(duì)傳輸時(shí)間是分組的RTP時(shí)間戳和分組到達(dá)時(shí)接收者的時(shí)鐘之差，以相同單位計(jì)算。 如果Si是分組i的RTP時(shí)間戳，Bi是按照RTP時(shí)間戳單位計(jì)算的分組i的到達(dá)時(shí)間，則對(duì)于分組i和i，D的表示如下： D(i，j)=(RjRj)(SjSi）=(RjSj)(RjSi） 每次從源SSRCn接收到數(shù)據(jù)分組i，就計(jì)算一次到達(dá)時(shí)間間隔抖動(dòng)J，其中利用了該分組和按到達(dá)順序計(jì)算的前一分組i1(不一定按序號(hào)順序)之差D，計(jì)算公式如下： J=J+(|D(i1，i)|-J)1612/4/202113源描述分組(SDES) RTCP支持?jǐn)?shù)據(jù)源提供更多的關(guān)于自己的信息。此操作通過(guò)發(fā)送RTP源描述分組(SDES

15、)(如圖P185)實(shí)現(xiàn)。該P(yáng)DU包括源同步標(biāo)識(shí)或參與源標(biāo)識(shí)(SSRC或CCRC)以及SDES項(xiàng)。圖P186列出了目前定義的源描述項(xiàng)。如表所示，這些項(xiàng)只是提供了更多關(guān)于源的信息。它們的使用方法由具體實(shí)現(xiàn)確定，RFCl889和RFCl996對(duì)這個(gè)課題有更多的討論。12/4/202114RSVP協(xié)議簡(jiǎn)介：協(xié)議簡(jiǎn)介： 資源預(yù)約協(xié)議資源預(yù)約協(xié)議(RSVP)為實(shí)時(shí)多媒體會(huì)議定為實(shí)時(shí)多媒體會(huì)議定義了一種預(yù)約操作。義了一種預(yù)約操作。RSVP與目前使用諸如與目前使用諸如ATM、幀幀中繼以及中繼以及X25等技術(shù)的系統(tǒng)不同，它是由數(shù)據(jù)的接等技術(shù)的系統(tǒng)不同，它是由數(shù)據(jù)的接收方進(jìn)行預(yù)約。與此形成對(duì)照的是，其他技術(shù)支持?jǐn)?shù)

16、收方進(jìn)行預(yù)約。與此形成對(duì)照的是，其他技術(shù)支持?jǐn)?shù)據(jù)發(fā)送方創(chuàng)建需求。據(jù)發(fā)送方創(chuàng)建需求。原理：數(shù)據(jù)接收方最了解自己的能力和限制。原理：數(shù)據(jù)接收方最了解自己的能力和限制。例如，視頻服務(wù)器正以很高的比特率向接收方發(fā)送數(shù)據(jù)，例如，視頻服務(wù)器正以很高的比特率向接收方發(fā)送數(shù)據(jù)，比如高質(zhì)量視頻的速率是比如高質(zhì)量視頻的速率是100Mbs。但是，但是，各接收者各接收者(客戶客戶)接收高質(zhì)量傳輸?shù)哪芰Σ煌邮崭哔|(zhì)量傳輸?shù)哪芰Σ煌?。因此，它們可以向。因此，它們可以向服?wù)器發(fā)送自己的資源預(yù)約請(qǐng)求，從而定義不同的服務(wù)器發(fā)送自己的資源預(yù)約請(qǐng)求，從而定義不同的吞吞吐量要求吐量要求。例如，一個(gè)通過(guò)例如，一個(gè)通過(guò)OC-3線路卡與線

17、路卡與ATM網(wǎng)絡(luò)相連的設(shè)備，連網(wǎng)絡(luò)相連的設(shè)備，連接在以太網(wǎng)上的個(gè)人電腦可能無(wú)法支持全部接在以太網(wǎng)上的個(gè)人電腦可能無(wú)法支持全部100MB的的傳輸帶寬。因此，這傳輸帶寬。因此，這2個(gè)設(shè)備可以向服務(wù)器發(fā)送預(yù)約請(qǐng)個(gè)設(shè)備可以向服務(wù)器發(fā)送預(yù)約請(qǐng)求，注明自己的能力求，注明自己的能力(可用帶寬可用帶寬)。 12/4/202115RSVP使用流的概念表示預(yù)約的數(shù)據(jù)流量。使用流的概念表示預(yù)約的數(shù)據(jù)流量。流與幀中繼及流與幀中繼及ATM中的面向連接的虛擬電路有些中的面向連接的虛擬電路有些相似。它們標(biāo)識(shí)了從發(fā)送端應(yīng)用到達(dá)接收端相似。它們標(biāo)識(shí)了從發(fā)送端應(yīng)用到達(dá)接收端應(yīng)用的數(shù)據(jù)流。此概念與應(yīng)用的數(shù)據(jù)流。此概念與IPv6的流

18、標(biāo)識(shí)字段配合的流標(biāo)識(shí)字段配合得非常好。該字段得非常好。該字段(連同源地址連同源地址)將惟一地確定每將惟一地確定每一個(gè)流。流和流標(biāo)識(shí)的概念主要用于區(qū)分網(wǎng)絡(luò)一個(gè)流。流和流標(biāo)識(shí)的概念主要用于區(qū)分網(wǎng)絡(luò)中不同類型的數(shù)據(jù)，然后根據(jù)各自的中不同類型的數(shù)據(jù)，然后根據(jù)各自的定時(shí)定時(shí)和和同同步步要求區(qū)別對(duì)待。實(shí)際上，流標(biāo)識(shí)最可能用于要求區(qū)別對(duì)待。實(shí)際上，流標(biāo)識(shí)最可能用于將數(shù)據(jù)放在中間交換機(jī)將數(shù)據(jù)放在中間交換機(jī)(位于服務(wù)器和客戶之位于服務(wù)器和客戶之間間)的不同隊(duì)列上。的不同隊(duì)列上。RSVP12/4/202116RSVP路徑操作：RSVP不提供路由功能，而是利用IPv4或IPv6的轉(zhuǎn)發(fā)功能，這正如網(wǎng)際控制報(bào)文協(xié)議(I

19、CMP)和Intemet組管理協(xié)議(IGMP)一樣。RSVP支持單播和組播，而且可以支持當(dāng)前和以后可能出現(xiàn)的組播協(xié)議。與IP類似，它根據(jù)路由表計(jì)算報(bào)文的路徑。它利用IGMP加入組播組，然后為該組播組預(yù)約資源。RSVP要求數(shù)據(jù)接收方提出流的Oos要求。接收方應(yīng)用必須計(jì)算QOS需求，然后傳遞給RSVP。在分析請(qǐng)求之后，RSVP向數(shù)據(jù)流經(jīng)過(guò)的所有節(jié)點(diǎn)發(fā)送請(qǐng)求報(bào)文。如圖P187所示，服務(wù)器(流發(fā)送者)利用路徑報(bào)文為會(huì)話建立路徑。12/4/202117預(yù)約操作：由流的接收方發(fā)出的預(yù)約報(bào)文，支持發(fā)送方和中間路由器獲得接收方的請(qǐng)求。見P187預(yù)約報(bào)文：見P188 所有RSVP報(bào)文由相同的首部和報(bào)文體組成。

20、RSVP對(duì)象（報(bào)文中信息按對(duì)象編碼）RSVP報(bào)文功能： 本節(jié)簡(jiǎn)要介紹RSVP報(bào)文的功能，算是對(duì)前面關(guān)于RSVP的討論的總結(jié)。關(guān)于更詳細(xì)的信息可以參考RFC2205。 路徑報(bào)文 針對(duì)自己創(chuàng)建的每個(gè)數(shù)據(jù)流，發(fā)送方都定期地發(fā)送路徑報(bào)文。該報(bào)文中包括一個(gè)定義數(shù)據(jù)分組格式的SENDERTEMPLATE對(duì)象和描述流特征的SENDERTSPEC對(duì)象。另外，它還可能包括一個(gè)存儲(chǔ)該流的廣播信息的ADSPEC對(duì)象。12/4/202118預(yù)約報(bào)文(Resv) 預(yù)約報(bào)文攜帶預(yù)約請(qǐng)求，它沿著與此會(huì)話的數(shù)據(jù)流相反的方向從接收方逐跳傳輸?shù)桨l(fā)送方。預(yù)約報(bào)文的IP目的地址是從路徑狀態(tài)中獲得的前一跳的單播地址，而源地址是發(fā)送此報(bào)

21、文的節(jié)點(diǎn)的地址。 此報(bào)文中的RESV_CONFIRM對(duì)象表示需要預(yù)約確認(rèn)，而且其中攜帶了接收預(yù)約確認(rèn)報(bào)文的IP地址。該報(bào)文還可以包含若干POLICY_DATA對(duì)象。 路徑拆除報(bào)文 收到路徑拆除報(bào)文后將會(huì)刪除匹配的路徑狀態(tài)。所謂匹配必須與SES-SION、 SENDER_TEMPLATE 和PHOP 對(duì)象匹配。另外，針對(duì)組播會(huì)話的路徑拆除報(bào)文只能與該報(bào)文到達(dá)的接收接口上路徑信息匹配。如果不存在匹配的路徑狀態(tài)，則應(yīng)該將路徑拆除報(bào)文丟棄并不再轉(zhuǎn)發(fā)。 路徑拆除報(bào)文由發(fā)送方或檢測(cè)到路徑狀態(tài)超時(shí)的節(jié)點(diǎn)最先發(fā)出，然后沿下游向所有接收跳發(fā)送。路徑拆除報(bào)文必須以與相應(yīng)的路徑報(bào)文相同的方式轉(zhuǎn)發(fā)。因此，它的IP目標(biāo)地址必須是會(huì)話的目標(biāo)地址，而源IP地址必須是將被拆除的路徑狀態(tài)中的發(fā)送方地址。 12/4/202119預(yù)約拆除報(bào)文 收到預(yù)約拆除報(bào)文的節(jié)點(diǎn)將會(huì)刪除匹配的預(yù)約狀態(tài)。所謂匹配的預(yù)約狀態(tài)是指與SESSION、STYLE和FILTER SPEC對(duì)象匹配。如果不存在匹配的預(yù)約狀態(tài)，則該預(yù)約拆除報(bào)文將被丟棄。預(yù)約拆除報(bào)文可以拆除FF類型或SE類型的預(yù)約