Internet多媒體協(xié)議課件

Internet多媒體協(xié)議2024/4/17Internet多媒體協(xié)議有關(guān)概念RTP會話：利用RTP進(jìn)行通信的各方之間的映射關(guān)系。對于參與通信的每臺主機(jī)，會話由一對特定的目標(biāo)傳輸?shù)刂?網(wǎng)絡(luò)地址加上RTP端口和RTCP端口)定義。在多媒體會話中，每種媒體都由一個單獨(dú)的RTP會話傳輸；使用單獨(dú)的RTCP分組。這些RTP會話通過不同的端口對和／或不同的組播地址加以區(qū)別。同步源(SynchronizationSource，SSRC)：RTP分組流的源點(diǎn)，SSRC標(biāo)識符包含在RTP首部中。從特定同步源發(fā)出的所有分組組成同一定時和序號空間的一部分，所以接收端可以根據(jù)同步源將收到的分組進(jìn)行分類，從而在本地重放。

2024/4/172Internet多媒體協(xié)議參與源(ContributingSource,CSRC)：特定RTP分組流的源點(diǎn)。該流將作為RTP混合器的輸入之一。混合器將在形成的分組的RTP首部中插入與該分組源點(diǎn)相應(yīng)的一組SSRC標(biāo)識。混合器(Mixer)：從若干數(shù)據(jù)源接收RTP分組的中間系統(tǒng)，該系統(tǒng)可能修改數(shù)據(jù)格式，按特定方式組合分組，然后創(chuàng)建新的RTP分組。由于各輸入源點(diǎn)的定時可能不同步，混和器將會調(diào)整各輸人流的定時，然后為組合流創(chuàng)建自己的定時。所有由混合器創(chuàng)建的數(shù)據(jù)分組的同步源就是該混合器。翻譯器(Translator)：在轉(zhuǎn)發(fā)RTP分組時保持分組的同步源標(biāo)識不變的中間系統(tǒng)。翻譯器的實(shí)例包括：在不進(jìn)行混合操作的同時轉(zhuǎn)換編碼的設(shè)備，將組播轉(zhuǎn)換為單播的中繼器以及防火墻中的應(yīng)用級過濾器。監(jiān)視器(Monitor)：接收RTP會話參與者發(fā)送的RTP分組的應(yīng)用程序，它以分布監(jiān)視、故障偵測和長期統(tǒng)計(jì)為目標(biāo)對當(dāng)前服務(wù)質(zhì)量進(jìn)行估算。2024/4/173Internet多媒體協(xié)議IP組播

IP組播系統(tǒng)：一對多，數(shù)據(jù)分組只創(chuàng)建一次，然后被組播服務(wù)器（ROUTER）復(fù)制多份，發(fā)往服務(wù)器的輸出端口并分發(fā)給相連的所有接收端。

主要應(yīng)用：音頻會議和視頻會議。遠(yuǎn)程教育、會議和白板交談等。地址格式：1110+組播地址（28）從224.0.0.0到239.255.255.255組播方式：組播遂道。組播數(shù)據(jù)封裝在IP數(shù)據(jù)報字段中傳輸，在INTERNET中的轉(zhuǎn)發(fā)過程依傳統(tǒng)的IP首部。路由器上運(yùn)行組播軟件。2024/4/174Internet多媒體協(xié)議IGMP操作IGMP支持組播操作。它允許一主機(jī)加入組。路由器知道組的信息，先向主機(jī)發(fā)送IGMP查詢；IGMP報告操作允許主機(jī)通知ROUTER它是否希望加入特定的組播組。當(dāng)一臺主機(jī)欲加入某個多播組時，會發(fā)出“主機(jī)成員報告”的IGMP消息通知多播路由器。當(dāng)多播路由器接收到發(fā)給那個多播組的數(shù)據(jù)時，便會將其轉(zhuǎn)發(fā)給所有的多播主機(jī)。多播路由器還會周期性地發(fā)出“主機(jī)成員查詢”的IGMP消息，向子網(wǎng)查詢多播主機(jī)，若發(fā)現(xiàn)某個多播組已沒有任何成員，則停止轉(zhuǎn)發(fā)該多播組的數(shù)據(jù)。此外，當(dāng)支持IGMPv2的主機(jī)（如Windows98/2000計(jì)算機(jī)）退出某個多播組時，還會向路由器發(fā)送一條“離開組”的IGMP消息，以通知路由器停止轉(zhuǎn)發(fā)該多播組的數(shù)據(jù)。但只有當(dāng)子網(wǎng)上所有主機(jī)都退出某個多播組時，路由器才會停止向該子網(wǎng)轉(zhuǎn)發(fā)該多播組的數(shù)據(jù)。2024/4/175Internet多媒體協(xié)議MBONEMulticastBackbone的縮寫，一種高速虛擬網(wǎng)絡(luò)，它可以將信息包同時發(fā)送到多個Internet站點(diǎn)，適用于音頻、視頻的傳輸。1992年，MBONE在IETF（Internet工程工作組）的Audiocast試驗(yàn)中，把IETF的會議內(nèi)容通過聲音、圖像進(jìn)行實(shí)時傳播。MBONE已成為Internet的一部分，是支持廣播式傳輸?shù)年P(guān)鍵部件。最初連入了4個國家的40個子網(wǎng)。截至1996年4月，MBONE的規(guī)模已經(jīng)遍及25個國家的2800多個子網(wǎng)。在MBONE上的著名Multicast服務(wù)有NASAspaceshuttlemissions、U.S.HouseandSenatesessions、livesatelliteweatherphotos等等。新的應(yīng)用與服務(wù)的出現(xiàn)，使得InternetMulticasting技術(shù)得到了迅速的發(fā)展。

2024/4/176Internet多媒體協(xié)議實(shí)時協(xié)議(RTP)用于支持實(shí)時數(shù)據(jù)流。典型的實(shí)時應(yīng)用是語音和視頻系統(tǒng)。RTP為具有實(shí)時特征的數(shù)據(jù)，提供了端到端的傳輸服務(wù)。服務(wù)包括負(fù)載類型標(biāo)識、定序、時間戳和傳輸監(jiān)視。應(yīng)用通常在UDP協(xié)議之上運(yùn)行RTP，如果底層網(wǎng)絡(luò)支持組播，那么RTP還支持到組播地址的數(shù)據(jù)傳輸。它依靠底層服務(wù)提供保證及時傳輸或保證其他服務(wù)質(zhì)量。RTP不能防止傳輸過程出現(xiàn)的丟包和亂序現(xiàn)象，而且它也不要求底層網(wǎng)絡(luò)是可靠的或按順序傳輸分組。RTP代表了一種新型的協(xié)議，RTP將提供特定應(yīng)用所需的信息，而且通常與應(yīng)用處理集成在一起，而不是作為單獨(dú)的協(xié)議層實(shí)現(xiàn)。RTP是通過修改和／或增加首部來實(shí)現(xiàn)新功能的。實(shí)時協(xié)議RTP2024/4/177Internet多媒體協(xié)議翻譯器和混合器

RTP翻譯器將負(fù)載從一種語法轉(zhuǎn)換(編碼)為另一種語法。翻譯器的任務(wù)是接收工作站的數(shù)據(jù)流，將其轉(zhuǎn)換(編碼)為以下格式:(1)符合傳輸網(wǎng)絡(luò)的帶寬限制，和/或(2)符合另一邊的用戶工作站的帶寬限制。RTP混合器將多個源組合為一個流。通常，混合器主要執(zhí)行音頻操作，不會降低接收方收到的信號質(zhì)量。它只是將各信號組合為一種統(tǒng)一的格式。RTP混合器特別適用于音頻會議。一般來說它不太適合做視頻會議，因?yàn)閷⒍鄠€視頻源組合成一種格式比較困難。RTP混合器并不是將每種源負(fù)載轉(zhuǎn)換為一種不同的格式。它在保留原來格式的基礎(chǔ)上將不同源負(fù)載組合為一個流。而另一方面，如果視頻流是簡單的脈沖代碼調(diào)制(PCM)的流，則可以將各源負(fù)載的值加起來，從而將它們組合為單一的流。2024/4/178Internet多媒體協(xié)議

RTP報文都使用同一種格式。RTP支持應(yīng)用層成幀。如G.722，JPEG視頻標(biāo)準(zhǔn)。RTP協(xié)議數(shù)據(jù)單元（PDU）封裝在用戶UDP和IP（PDU）中傳輸。RTP無默認(rèn)的UDP端口。由于主機(jī)在各種不同的應(yīng)用中都要利用RTP，給一默認(rèn)口不夠。但是當(dāng)應(yīng)用沒有其他可用的端口時，RTP將5004端口作為指定端口。RTP規(guī)范要求不管選取哪個端口其值必須是偶數(shù)。這是由于比RTP端口值只大1的端口(對于指定端口為5005)被用于傳送實(shí)時控制協(xié)議RTCP的業(yè)務(wù)量的緣故。格式見圖P179。RTP報文2024/4/179Internet多媒體協(xié)議RTP報文

同步源ID是RTP報文的最初發(fā)送者的標(biāo)識。該發(fā)送者負(fù)責(zé)計(jì)算報文的序列號和時間戳。RTP翻譯器保留該標(biāo)識，但RTP混合器將成為新的同步源，而其他(最初的)源將成為參與源，這些參與源記錄在報文的參與源ID字段中。通信雙方利用序列號和時間戳達(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頁列出了RTPPDU數(shù)據(jù)字段可以攜帶的各種載荷類型。該表公布以后，業(yè)界又定義了可由RTP承載的其他標(biāo)準(zhǔn)。例如，H·324、H．263和C．723分別是壓縮音頻流和視頻流的最新標(biāo)準(zhǔn)。2024/4/1710Internet多媒體協(xié)議RTP復(fù)用操作

RTP復(fù)用功能由目標(biāo)傳輸?shù)刂罚⊿OCKET）提供。復(fù)用分組格式除了時間戳、標(biāo)記位和SSRC之外，RTP首部的其他字段都保持原有定義。復(fù)用分組的格式如圖所示?！褫d荷類型：負(fù)載類型字段標(biāo)識此RTP分組為復(fù)用分組。●時間戳：該協(xié)議要求分組中所有復(fù)用流必須具有相同的時鐘頻率(例如，音頻的采樣頻率)，而且按照一定時間間隔產(chǎn)生媒體幀，該時間間隔是一個公共的幀持續(xù)時間的整數(shù)倍?！駱?biāo)記位：復(fù)用操作沒有使用此字段，它的值設(shè)置為0。復(fù)用首部中為每個用戶都包含一個標(biāo)記位?！馭SRC：此字段用于標(biāo)識特定的用戶組(而不是單個用戶)，這些用戶的幀是同步的。復(fù)用(MUX)首部包含參與復(fù)用操作的所有用戶的信息。它還包含載荷類型的信息以及用于每個用戶載荷的標(biāo)識值。2024/4/1711Internet多媒體協(xié)議負(fù)責(zé)管理發(fā)送應(yīng)用和接收應(yīng)用的實(shí)時會話。該協(xié)議支持發(fā)送者向接收者通報后者應(yīng)該接收到的RTP數(shù)據(jù)，它還支持接收者直接向發(fā)送者報告。這種思想在IP組播中非常有效，因?yàn)樗梢詸z查分組分發(fā)中的故障。發(fā)送者和接收者報告可能占用大量的帶寬，RTCP提供了一種定義這些報告發(fā)送頻率的機(jī)制。其思想是無論多少用戶參與會話，會話的總體數(shù)據(jù)流保持恒定。所有RTCP分組的源端都發(fā)送源說明，描述發(fā)送數(shù)據(jù)的那些應(yīng)用的特征。這些報文包含一些定義屬性的源說明項(xiàng)，例如電子郵件地址、地理位置、電話號碼和郵箱地址。會議(視頻或音頻)的參與者可以在任何時間通過發(fā)送一個稱為“bye”的注銷報文而退出會議。RTCP報文可以針對特定應(yīng)用進(jìn)行編碼。RTCP并不關(guān)心報文的內(nèi)容，RTCP操作在應(yīng)用間透明地傳輸報文。RTCP2024/4/1712Internet多媒體協(xié)議RTCP分組有五種分組類型：200~204會話的發(fā)送者每隔一段時間向接收者發(fā)送者報告。各字段內(nèi)容見P184RTCP報文格式。抖動方程：到達(dá)時間間隔抖動是兩個分組的相對傳輸時間的差異。它是分組的RTP時間戳和分組到達(dá)時接收者時鐘之間的差。如下面的方程所示，它等于兩個分組的“相對傳輸時間”之差：相對傳輸時間是分組的RTP時間戳和分組到達(dá)時接收者的時鐘之差，以相同單位計(jì)算。如果Si是分組i的RTP時間戳，Bi是按照RTP時間戳單位計(jì)算的分組i的到達(dá)時間，則對于分組i和i，D的表示如下：D(i，j)=(Rj—Rj)—(Sj—Si）=(Rj—Sj)—(Rj—Si）每次從源SSRC—n接收到數(shù)據(jù)分組i，就計(jì)算一次到達(dá)時間間隔抖動J，其中利用了該分組和按到達(dá)順序計(jì)算的前一分組i—1(不一定按序號順序)之差D，計(jì)算公式如下：J=J+(|D(i—1，i)|-J)／162024/4/1713Internet多媒體協(xié)議源描述分組(SDES)RTCP支持?jǐn)?shù)據(jù)源提供更多的關(guān)于自己的信息。此操作通過發(fā)送RTP源描述分組(SDES)(如圖P185)實(shí)現(xiàn)。該P(yáng)DU包括源同步標(biāo)識或參與源標(biāo)識(SSRC或CCRC)以及SDES項(xiàng)。圖P186列出了目前定義的源描述項(xiàng)。如表所示，這些項(xiàng)只是提供了更多關(guān)于源的信息。它們的使用方法由具體實(shí)現(xiàn)確定，RFCl889和RFCl996對這個課題有更多的討論。2024/4/1714Internet多媒體協(xié)議RSVP協(xié)議簡介：資源預(yù)約協(xié)議(RSVP)為實(shí)時多媒體會議定義了一種預(yù)約操作。RSVP與目前使用諸如ATM、幀中繼以及X．25等技術(shù)的系統(tǒng)不同，它是由數(shù)據(jù)的接收方進(jìn)行預(yù)約。與此形成對照的是，其他技術(shù)支持?jǐn)?shù)據(jù)發(fā)送方創(chuàng)建需求。原理：數(shù)據(jù)接收方最了解自己的能力和限制。例如，視頻服務(wù)器正以很高的比特率向接收方發(fā)送數(shù)據(jù)，比如高質(zhì)量視頻的速率是100Mb／s。但是，各接收者(客戶)接收高質(zhì)量傳輸?shù)哪芰Σ煌?。因此，它們可以向服?wù)器發(fā)送自己的資源預(yù)約請求，從而定義不同的吞吐量要求。例如，一個通過OC-3線路卡與ATM網(wǎng)絡(luò)相連的設(shè)備，連接在以太網(wǎng)上的個人電腦可能無法支持全部100MB的傳輸帶寬。因此，這2個設(shè)備可以向服務(wù)器發(fā)送預(yù)約請求，注明自己的能力(可用帶寬)。2024/4/1715Internet多媒體協(xié)議RSVP使用流的概念表示預(yù)約的數(shù)據(jù)流量。流與幀中繼及ATM中的面向連接的虛擬電路有些相似。它們標(biāo)識了從發(fā)送端應(yīng)用到達(dá)接收端應(yīng)用的數(shù)據(jù)流。此概念與IPv6的流標(biāo)識字段配合得非常好。該字段(連同源地址)將惟一地確定每一個流。流和流標(biāo)識的概念主要用于區(qū)分網(wǎng)絡(luò)中不同類型的數(shù)據(jù)，然后根據(jù)各自的定時和同步要求區(qū)別對待。實(shí)際上，流標(biāo)識最可能用于將數(shù)據(jù)放在中間交換機(jī)(位于服務(wù)器和客戶之間)的不同隊(duì)列上。RSVP2024/4/1716Internet多媒體協(xié)議RSVP路徑操作：RSVP不提供路由功能，而是利用IPv4或IPv6的轉(zhuǎn)發(fā)功能，這正如網(wǎng)際控制報文協(xié)議(ICMP)和Intemet組管理協(xié)議(IGMP)一樣。RSVP支持單播和組播，而且可以支持當(dāng)前和以后可能出現(xiàn)的組播協(xié)議。與IP類似，它根據(jù)路由表計(jì)算報文的路徑。它利用IGMP加入組播組，然后為該組播組預(yù)約資源。RSVP要求數(shù)據(jù)接收方提出流的Oos要求。接收方應(yīng)用必須計(jì)算QOS需求，然后傳遞給RSVP。在分析請求之后，RSVP向數(shù)據(jù)流經(jīng)過的所有節(jié)點(diǎn)發(fā)送請求報文。如圖P187所示，服務(wù)器(流發(fā)送者)利用路徑報文為會話建立路徑。2024/4/1717Internet多媒體協(xié)議預(yù)約操作：由流的接收方發(fā)出的預(yù)約報文，支持發(fā)送方和中間路由器獲得接收方的請求。見P187預(yù)約報文：見P188所有RSVP報文由相同的首部和報文體組成。RSVP對象（報文中信息按對象編碼）RSVP報文功能：

本節(jié)簡要介紹RSVP報文的功能，算是對前面關(guān)于RSVP的討論的總結(jié)。關(guān)于更詳細(xì)的信息可以參考RFC2205。路徑報文針對自己創(chuàng)建的每個數(shù)據(jù)流，發(fā)送方都定期地發(fā)送路徑報文。該報文中包括一個定義數(shù)據(jù)分組格式的SENDER—TEMPLATE對象和描述流特征的SENDER—TSPEC對象。另外，它還可能包括一個存儲該流的廣播信息的ADSPEC對象。2024/4/1718Internet多媒體協(xié)議預(yù)約報文(Resv)預(yù)約報文攜帶預(yù)約請求，它沿著與此會話的數(shù)據(jù)流相反的方向從接收方逐跳傳輸?shù)桨l(fā)送方。預(yù)約報文的IP目的地址是從路徑狀態(tài)中獲得的前一跳的單播地址，而源地址是發(fā)送此報文的節(jié)點(diǎn)的地址。此報文中的RESV_CONFIRM對象表示需要預(yù)約確認(rèn)，而且其中攜帶了接收預(yù)約確認(rèn)報文的IP地址。該報文還可以包含若干POLICY_DATA對象。

路徑拆除報文收到路徑拆除報文后將會刪除匹配的路徑狀態(tài)。所謂匹配必須與SES-SION、SENDER_TEMPLATE和PHOP對象匹配。另外，針對組播會話的路徑拆除報文只能與該報文到達(dá)的接收接口上路徑信息匹配。如果不存在匹配的路徑狀態(tài)，則應(yīng)該將路徑拆除報文丟棄并不再轉(zhuǎn)發(fā)。

路