實(shí)時(shí)傳輸協(xié)議RTP與RTCP
RTP（Real-timeTransportProtocol）是用于Internet上針對(duì)多媒體數(shù)據(jù)流的一種傳輸協(xié)議。RTP被定義為在一對(duì)一或一對(duì)多的傳輸情況下工作，其目的是提供時(shí)間信息和實(shí)現(xiàn)流同步。RTP通常使用UDP來傳送數(shù)據(jù)，但RTP也可以在TCP或ATM等其他協(xié)議之上工作。當(dāng)應(yīng)用程序開始一個(gè)RTP會(huì)話時(shí)將使用兩個(gè)端口：一個(gè)給RTP，一個(gè)給RTCP。RTP本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)。通常RTP算法并不作為一個(gè)獨(dú)立的網(wǎng)絡(luò)層來實(shí)現(xiàn)，而是作為應(yīng)用程序代碼的一部分。實(shí)時(shí)傳輸控制協(xié)議RTCP。RTCP(Real-timeTransportControlProtocol)和RTP一起提供流量控制和擁塞控制服務(wù)。在RTP會(huì)話期間，各參與者周期性地傳送RTCP包。RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料，因此，服務(wù)器可以利用這些信息動(dòng)態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實(shí)時(shí)數(shù)據(jù)。
6.2.1 RTP數(shù)據(jù)傳輸協(xié)議
RTP提供端對(duì)端網(wǎng)絡(luò)傳輸功能，適合通過組播和點(diǎn)播傳送實(shí)時(shí)數(shù)據(jù)，如視頻、音頻和仿真數(shù)據(jù)。RTP沒有涉及資源預(yù)訂和質(zhì)量保證等實(shí)時(shí)服務(wù)，RTCP擴(kuò)充數(shù)據(jù)傳輸以允許監(jiān)控?cái)?shù)據(jù)傳送，提供最小的控制和識(shí)別功能。RTP與RTCP設(shè)計(jì)成獨(dú)立傳輸和網(wǎng)絡(luò)層。
2.1.1 RTP固定頭
RTP 頭格式如下：
-----------------------------------------------------------------------------------------------
|V=2|P|X| CC |M| PT | 系列號(hào) |
-----------------------------------------------------------------------------------------------
| 時(shí)標(biāo) |
-----------------------------------------------------------------------------------------------
| 同步源標(biāo)識(shí)(SSRC) |
-----------------------------------------------------------------------------------------------
| 作用標(biāo)識(shí) (CSRC) |
| .... |
-----------------------------------------------------------------------------------------------
開始12個(gè)八進(jìn)制出現(xiàn)在每個(gè)RTP包中，而CSRC標(biāo)識(shí)列表僅出現(xiàn)在混合器插入時(shí)。
2.1.2 復(fù)用 RTP 連接
為使協(xié)議有效運(yùn)行，復(fù)用點(diǎn)數(shù)目應(yīng)減至最小。RTP中，復(fù)用由定義RTP連接的目的傳輸?shù)刂罚ňW(wǎng)絡(luò)地址與端口號(hào)）提供。例如，對(duì)音頻和視頻單獨(dú)編碼的遠(yuǎn)程會(huì)議，每個(gè)媒介被攜帶在單獨(dú)RTP連接中，具有各自的目的傳輸?shù)刂贰Ｄ繕?biāo)不在將音頻和視頻放在單一RTP連接中，而根據(jù)SSRC段載荷類型進(jìn)行多路分解。使用同一SSRC ，而具有不同載荷類型的交叉包將帶來幾個(gè)問題：
如一種載荷類型在連接期間切換，沒有辦法識(shí)別新值將替換那一個(gè)舊值。
SSRC定義成用于標(biāo)識(shí)單個(gè)計(jì)時(shí)和系列號(hào)空間。如媒體時(shí)鐘速率不同，而要求不同系列號(hào)空間以說明那種載荷類型有丟包，交叉復(fù)用載荷類型將需要不同計(jì)時(shí)空間。
RTCP發(fā)送和接收?qǐng)?bào)告可能僅描述每個(gè)SSRC的計(jì)時(shí)和系列號(hào)空間，而不攜帶載荷類型段。
RTP混合器不能將不兼容媒體流合并成一個(gè)流。
在一個(gè)RTP連接中攜帶多個(gè)媒介阻止幾件事：使用不同網(wǎng)絡(luò)路徑或網(wǎng)絡(luò)資源分配；接受媒介子集。
對(duì)每種媒介使用不同SSRC，但以相同RTP連接發(fā)送可避免前三個(gè)問題，但不能避免后兩個(gè)問題。
2.1.3 對(duì)RTP頭特定設(shè)置的修改
可以認(rèn)為，現(xiàn)用RTP數(shù)據(jù)包頭對(duì)RTP支持的所有應(yīng)用類共同需要的功能集是完整的。然而，為維持ALF設(shè)計(jì)原則，頭可通過改變或增加設(shè)置來裁剪，并仍允許設(shè)置無關(guān)監(jiān)控和記錄工具起作用。標(biāo)記位與載荷類型段攜帶特定設(shè)置信息，但由于很多應(yīng)用需要它們，否則要容納它們，就要增加另外32位字，故允許分配在固定頭中。包含這些段的八進(jìn)制可通過設(shè)置重新定義以適應(yīng)不同要求，如采用更多或更少標(biāo)記位。如有標(biāo)記位，既然設(shè)置無關(guān)監(jiān)控器能觀察包丟失模式和標(biāo)記位間關(guān)系，我們就可以定位八進(jìn)制中最重要的位。
其它特殊載荷格式（視頻編碼）所要求的信息應(yīng)該攜帶在包的載荷部分。可出現(xiàn)在頭，總是在載荷部分開始處，或在數(shù)據(jù)模式的保留值中指出。如特殊應(yīng)用類需要獨(dú)立載荷格式的附加功能，應(yīng)用運(yùn)行的設(shè)置應(yīng)該定義附加固定段跟隨在現(xiàn)存固定頭SSRC之后。這些應(yīng)用將能迅速而直接訪問附加段，同時(shí)，與監(jiān)控器和記錄器無關(guān)設(shè)置仍能通過僅解釋開始12個(gè)八進(jìn)制處理RTP包。如證實(shí)附加功能是所有設(shè)置共同需要的，新版本RTP應(yīng)該對(duì)固定頭作出明確改變。
|-page-|
實(shí)時(shí)傳輸協(xié)議RTP與RTCP
RTP（Real-timeTransportProtocol）是用于Internet上針對(duì)多媒體數(shù)據(jù)流的一種傳輸協(xié)議。RTP被定義為在一對(duì)一或一對(duì)多的傳輸情況下工作，其目的是提供時(shí)間信息和實(shí)現(xiàn)流同步。RTP通常使用UDP來傳送數(shù)據(jù)，但RTP也可以在TCP或ATM等其他協(xié)議之上工作。當(dāng)應(yīng)用程序開始一個(gè)RTP會(huì)話時(shí)將使用兩個(gè)端口：一個(gè)給RTP，一個(gè)給RTCP。RTP本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)。通常RTP算法并不作為一個(gè)獨(dú)立的網(wǎng)絡(luò)層來實(shí)現(xiàn)，而是作為應(yīng)用程序代碼的一部分。實(shí)時(shí)傳輸控制協(xié)議RTCP。RTCP(Real-timeTransportControlProtocol)和RTP一起提供流量控制和擁塞控制服務(wù)。在RTP會(huì)話期間，各參與者周期性地傳送RTCP包。RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料，因此，服務(wù)器可以利用這些信息動(dòng)態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實(shí)時(shí)數(shù)據(jù)。
6.2.2 RTP控制協(xié)議-- RTCP
RTCP協(xié)議將控制包周期發(fā)送給所有連接者，應(yīng)用與數(shù)據(jù)包相同的分布機(jī)制。低層協(xié)議提供數(shù)據(jù)與控制包的復(fù)用，如使用單獨(dú)的UDP端口號(hào)。RTCP執(zhí)行下列四大功能：
主要是提供數(shù)據(jù)發(fā)布的質(zhì)量反饋。是作為RTP傳輸協(xié)議的一部分，與其他傳輸協(xié)議的流和阻塞控制有關(guān)。反饋對(duì)自適應(yīng)編碼控制直接起作用，但IP組播經(jīng)驗(yàn)表明，從發(fā)送者收到反饋對(duì)診斷發(fā)送錯(cuò)誤是致關(guān)重要的。給所有參加者發(fā)送接收反饋報(bào)告允許問題觀察者估計(jì)那些問題是局部的，還是全局的。諸如IP組播等發(fā)布機(jī)制使網(wǎng)絡(luò)服務(wù)提供商類團(tuán)體可能接收反饋信息，充當(dāng)?shù)谌奖O(jiān)控者來診斷網(wǎng)絡(luò)問題。反饋功能由RTCP發(fā)送者和接收者報(bào)告執(zhí)行。
RTCP帶有稱作規(guī)范名字（CNAME）的RTP源持久傳輸層標(biāo)識(shí)。如發(fā)現(xiàn)沖突，或程序重新啟動(dòng)，既然SSRC標(biāo)識(shí)可改變，接收者需要CNAME跟蹤參加者。接收者也需要CNAME 與相關(guān)RTP連接中給定的幾個(gè)數(shù)據(jù)流聯(lián)系
前兩種功能要求所有參加者發(fā)送RTCP包，因此，為了RTP擴(kuò)展到大規(guī)模數(shù)量，速率必須受到控制。讓每個(gè)參加者給其它參加者發(fā)送控制包，就大獨(dú)立觀察參加者數(shù)量。該數(shù)量用語計(jì)算包發(fā)送的速率。
第四個(gè)可選功能是傳送最小連接控制信息，如參加者辨識(shí)。最可能用在"松散控制"連接，那里參加者自由進(jìn)入或離開，沒有成員控制或參數(shù)協(xié)調(diào)，RTCP充當(dāng)通往所有參加者的方便通道，但不必支持應(yīng)用的所有控制通訊要求。高級(jí)連接控制協(xié)議超出本書范圍。
在IP組播場(chǎng)合應(yīng)用RTP時(shí)，前3個(gè)功能是必須的，推薦用于所有情形。RTP應(yīng)用設(shè)計(jì)人員必須避免使用僅在單播模式下工作的機(jī)制，那將導(dǎo)致無法擴(kuò)展規(guī)模。
6.2.2.1 RTCP 包格式
下面定義幾個(gè)攜帶不同控制信息的RTCP包類型：
SR：
發(fā)送報(bào)告，當(dāng)前活動(dòng)發(fā)送者發(fā)送、接收統(tǒng)計(jì)。
RR：
接收?qǐng)?bào)告，非活動(dòng)發(fā)送者接收統(tǒng)計(jì)。
SDES：
源描述項(xiàng)，包括CNAME。
BYE：
表示結(jié)束。
APP：
應(yīng)用特定函數(shù)。
類似于RTP數(shù)據(jù)包，每個(gè)RTCP包以固定部分開始，緊接著的是可變長(zhǎng)結(jié)構(gòu)元素，但以一個(gè)32位邊界結(jié)束。包含安排要求和固定部分中長(zhǎng)度段，使RTCP包可堆疊。不需要插入任何分隔符將多哥RTCP包連接起來形成一個(gè)RTCP組合包，以低層協(xié)議用單一包發(fā)送出去。由于需要低層協(xié)議提供提供整體長(zhǎng)度來決定組合包的結(jié)尾，在組合包中沒有單個(gè)RTCP包顯式計(jì)數(shù)。
組合包中每個(gè)RTCP包可獨(dú)立處理，不需要根據(jù)包組合順序。但未了執(zhí)行協(xié)議功能，強(qiáng)加如下約束：
接收統(tǒng)計(jì)（在SR或RR中）應(yīng)該經(jīng)常發(fā)送，只要帶寬允許，因此每個(gè)周期發(fā)送的組合RTCP 包應(yīng)包含報(bào)告包。
新接收者需要接收CNAME，并盡快識(shí)別源，開始聯(lián)系媒介進(jìn)行同步，因此每個(gè)包應(yīng)該包含SDES CNAME。
出現(xiàn)在組合包前面的是包類型數(shù)量，其增長(zhǎng)應(yīng)該受到限制，以提高常數(shù)位數(shù)量，提高成功確認(rèn)RTCP包對(duì)錯(cuò)誤地址RTP數(shù)據(jù)包或其他無關(guān)包的概率。
因此，所有RTCP包至少必須以兩個(gè)包組合形式發(fā)送，推薦格式如下：
加密前綴（Encryption prefix）：
僅當(dāng)組合包被加密，才加上一個(gè)32位隨機(jī)數(shù)用于每個(gè)組合包發(fā)送。
SR或RR：
組合包中第一個(gè)RTCP包必須總為一個(gè)報(bào)告包，方便頭的確認(rèn)。即使沒有數(shù)據(jù)發(fā)送，也沒有接收到數(shù)據(jù)，也要發(fā)送一個(gè)空RR，那怕組合包中RTCP包為BYE。
附加RR：
如報(bào)告統(tǒng)計(jì)源數(shù)目超過31，在初始報(bào)告包后應(yīng)該有附加RR 包。
SDES：
包含CNAME 項(xiàng)的SDES包必須包含在每個(gè)組合RTCP包中。如應(yīng)用要求，其他源描述項(xiàng)可選，但受到帶寬限制。
BYE或APP：
其它RTCP包類型可以任意順序排列，除了BYE應(yīng)作為最后一個(gè)包發(fā)送，包類型出現(xiàn)可不止一次。
建議轉(zhuǎn)換器或混合器從多個(gè)源組合單個(gè)RTCP包。如組合包整體長(zhǎng)度超過網(wǎng)絡(luò)路徑最大傳輸單元，可分成多個(gè)較短組合包用低層協(xié)議以單個(gè)包形式發(fā)送。注意，每個(gè)組合包必須以SR或RR包開始。附加RTCP包類型可在Internet Assigned Numbers Authority (IANA)處注冊(cè)。
6.2.2.2 RTCP傳輸間隔
RTP設(shè)計(jì)成允許應(yīng)用自動(dòng)擴(kuò)展，連接數(shù)可從幾個(gè)到上千個(gè)。例如，音頻會(huì)議中，數(shù)據(jù)流量是內(nèi)在限制的，因?yàn)橥粫r(shí)刻只有一兩個(gè)人說話；對(duì)組播，給定連接數(shù)據(jù)率仍是常數(shù)，獨(dú)立于連接數(shù)，但控制流量不是內(nèi)在限制的。如每個(gè)參加者以固定速率發(fā)送接收?qǐng)?bào)告，控制流量將隨參加者數(shù)量線性增長(zhǎng)，因此，速率必須按比例下降。
一旦確認(rèn)地址有效，如后來標(biāo)記成未活動(dòng)，地址的狀態(tài)應(yīng)仍保留，地址應(yīng)繼續(xù)計(jì)入共享RTCP帶寬地址的總數(shù)中，時(shí)間要保證能掃描典型網(wǎng)絡(luò)分區(qū)，建議為30分鐘。注意，這仍大于RTCP報(bào)告間隔最大值的五倍。
這個(gè)規(guī)范定義了除必需的CNAME外的幾個(gè)源描述項(xiàng)，如NAME（人名）和EMAIL（電子郵件地址）。它也為定義新特定應(yīng)用RTCP包類型的途徑。給附加信息分配控制帶寬應(yīng)引起注意，因?yàn)樗鼘⒔档徒邮請(qǐng)?bào)告和CNAME發(fā)送的速率而損害協(xié)議的性能。建議分配給單個(gè)參加者用于攜帶附加信息的RTCP帶寬不要超過20%。而且并沒有有意讓所有SDES項(xiàng)包含在每個(gè)應(yīng)用中。
6.2.2.3 發(fā)送者與接收者報(bào)告
RTP接收者使用RTCP報(bào)告包提供接收質(zhì)量反饋，報(bào)告包根據(jù)接收者是否是發(fā)送者而采用兩種格式中的一種。除包類型代碼外，發(fā)送者報(bào)告與接收者報(bào)告間唯一的差別是發(fā)送者報(bào)告包含一個(gè)20個(gè)字節(jié)發(fā)送者信息段。如某地址在發(fā)出最后或前一個(gè)報(bào)告間隔期間發(fā)送數(shù)據(jù)包，就發(fā)布SR；否則，就發(fā)出RR；SR和RR都可沒有或包括多個(gè)接收?qǐng)?bào)告塊。發(fā)布報(bào)告不是為列在CSRC列表上的起作用的源，每個(gè)接收?qǐng)?bào)告塊提供從特殊源接收數(shù)據(jù)的統(tǒng)計(jì)。既然最大可有31個(gè)接收?qǐng)?bào)告塊嵌入在SR 或 RR包中，
丟失包累計(jì)數(shù)差別給出間隔期間丟掉的數(shù)量，而所收到擴(kuò)展的最后一個(gè)系列號(hào)的差別給出間隔期間希望發(fā)送的包數(shù)量，兩者之比等于經(jīng)過間隔期間包丟失百分比。如兩報(bào)告連續(xù)，比值應(yīng)該等于丟失段部分；否則，就不等。每秒包丟失綠可通過NTP時(shí)標(biāo)差除以丟失部分得到。
從發(fā)送者信息，第三方監(jiān)控器可計(jì)算載荷平均數(shù)據(jù)速率與沒收到數(shù)據(jù)間隔的平均包速率，兩者比值給出平均載荷大小。如假設(shè)包丟失與包大小無關(guān)，那么特殊接收者收到的包數(shù)量給出此接收者收到的表觀流量。
6.2.2.4 SDES: 源描述RTCP包
SDES 包為三層結(jié)構(gòu)，由頭與數(shù)據(jù)塊組成，數(shù)據(jù)塊可以沒有，也可有多個(gè)，組成項(xiàng)描述塊所表明的源。項(xiàng)描述如下：
版本（V）、填充（P）、長(zhǎng)度：
如SR包中所描述。
包類型（PT）：
8位，包含常數(shù)202，識(shí)別RTCP SDES包。
源計(jì)數(shù)（SC）：
5位，包含在SDES包中的SSRC/CSRC塊數(shù)量，零值有效，但沒有意義。
源描述項(xiàng)內(nèi)容如下：
CNAME: 規(guī)范終端標(biāo)識(shí)SDES項(xiàng)
CNAME標(biāo)識(shí)屬性如下：
如發(fā)生沖突或重啟程序，由于隨機(jī)分配的SSRC標(biāo)識(shí)可能發(fā)生變化，需要CNAME項(xiàng)提供從SSRC標(biāo)識(shí)到仍為常量的源標(biāo)識(shí)的綁定。
象SSRC標(biāo)識(shí)，CNAME標(biāo)識(shí)在RTP連接的所有參加者中應(yīng)是唯一的。
為了提供一套相關(guān)RTP連接中某個(gè)參加者所采用的跨多媒體工具間的綁定，CNAME應(yīng)固定為那個(gè)參加者。
為方便第三方監(jiān)控，CNAME應(yīng)適合程序或人員定位源。
NAME：用戶名稱SDES項(xiàng)
這是用于描述源的真正的名稱，如"John Doe, Bit Recycler, Megacorp"，可是用戶想要的任意形式。對(duì)諸如會(huì)議應(yīng)用，這種名稱也許是參加者列表顯示最適宜的形式，它將是除CNAME外發(fā)送最頻繁的項(xiàng)目。設(shè)置可建立這樣的優(yōu)先級(jí)別。NAME值至少在連接期間仍希望保持為常數(shù)。它不該成為連接的所有參加者中唯一依賴。
EMAIL：電子郵件地址SDES項(xiàng)
郵件地址格式由RFC822規(guī)定，如"John.Doe@megacorp.com"。連接期間，電子郵件仍希望保持為常數(shù)。
PHONE：電話號(hào)碼SDES項(xiàng)
電話號(hào)碼應(yīng)帶有加號(hào)，代替國際接入代碼，如"+1 908 555 1212"即為美國電話號(hào)碼。
LOC：用戶地理位置SDES項(xiàng)
根據(jù)應(yīng)用，此項(xiàng)具有不同程度的細(xì)節(jié)。對(duì)會(huì)議應(yīng)用，字符串如"Murray Hill, New Jersey"就足夠了。然而，對(duì)活動(dòng)標(biāo)記系統(tǒng)，字符串如"Room 2A244, AT&T BL MH"也許就適用。細(xì)節(jié)留給實(shí)施或用戶，但格式和內(nèi)容可用設(shè)置指示。在連接期間，除移動(dòng)主機(jī)外，LOC值期望仍保留為常數(shù)。
TOOL：應(yīng)用或工具名稱SDES項(xiàng)
是一個(gè)字符串，表示產(chǎn)生流的應(yīng)用的名稱與版本，如"videotool 1.2"。這部分信息對(duì)調(diào)試很有用，類似于郵件或郵件系統(tǒng)版本SMTP頭。TOOL值在連接期間仍保持常數(shù)。
NOTE: 通知/狀態(tài)SDES項(xiàng)
該項(xiàng)的推薦語法如下所述，但這些或其它語法可在設(shè)置中顯式定義。NOTE 項(xiàng)旨在描述源當(dāng)前狀態(tài)的過渡信息，如"on the phone, can´t talk"，或在講座期間用于傳送談話的題目。它應(yīng)該只用于攜帶例外信息，而不應(yīng)包含在全部參加者中，因?yàn)檫@將降低接收?qǐng)?bào)告和CNAME發(fā)送的速度，因此損害協(xié)議的性能。特殊情況下，它不應(yīng)作為用戶設(shè)置文件的項(xiàng)目，也不是自動(dòng)產(chǎn)生。
當(dāng)其為活動(dòng)時(shí)，由于NOTE項(xiàng)對(duì)顯示很重要，其它非CNAME項(xiàng)（如NAME）傳輸速率將會(huì)降低，結(jié)果使NOTE項(xiàng)占用RTCP部分帶寬。若過渡信息不活躍，NOTE項(xiàng)繼續(xù)以同樣的速度重復(fù)發(fā)送幾次，但以一個(gè)串長(zhǎng)為零的字符串通知接收者。然而，如對(duì)小倍數(shù)的重復(fù)或約20-30 RTCP間隔也沒有接收到，接收者也應(yīng)該考慮NOTE項(xiàng)是不活躍的。
PRIV: 專用擴(kuò)展SDES項(xiàng)
該項(xiàng)用于定義實(shí)驗(yàn)或應(yīng)用特定的SDES擴(kuò)展，它包括由長(zhǎng)字符串對(duì)組成的前綴，后跟填充該項(xiàng)其他部分和攜帶所需信息的字符串值。前綴長(zhǎng)度段為8位。前綴字符串是定義PRIV項(xiàng)人員選擇的名稱，唯一對(duì)應(yīng)應(yīng)用接收到的其它PRIV項(xiàng)。應(yīng)用實(shí)現(xiàn)者可選擇使用應(yīng)用名稱，如有必要，外加附加子類型標(biāo)識(shí)。另外，推薦其它人根據(jù)其代表的實(shí)體選擇名稱，然后，在實(shí)體內(nèi)部協(xié)調(diào)名稱的使用。
注意，前綴消耗了總長(zhǎng)為255個(gè)八進(jìn)制項(xiàng)的一些空間，因此，前綴應(yīng)盡可能的短。這個(gè)設(shè)備和受到約束的RTCP帶寬不應(yīng)過載，其目的不在于滿足所有應(yīng)用的全部控制通訊要求。SDES PRIV前綴沒在IANA處注冊(cè)。如證實(shí)某些形式的PRIV項(xiàng)具有通用性， IANA應(yīng)給它分配一個(gè)正式的SDES項(xiàng)類型，這樣就不再需要前綴。這簡(jiǎn)化了應(yīng)用，并提高了傳輸?shù)男省?/span>
6.2.2.5 BYE：斷開RTCP包
如混合器接收到一個(gè)BYE包，混合器轉(zhuǎn)發(fā)BYE包，而不改變SSRC/CSRC 標(biāo)識(shí)。如混合器關(guān)閉，它也應(yīng)該發(fā)出一個(gè)BYE包，列出它所處理的所有源，而不只是自己的SSRC標(biāo)識(shí)。作為可選項(xiàng)，BYE包可包括一個(gè)8位八進(jìn)制計(jì)數(shù)，后跟很多八進(jìn)制文本，表示離開原因，如："camera malfunction"或"RTP loop detected"。字符串具有同樣的編碼，如在SDES 中所描述的。如字符串填充包至下32位邊界，字符串就不以空結(jié)尾；否則，BYE包以空八進(jìn)制填充。
6.2.2.6 APP：定義應(yīng)用的RTCP包
APP包用于開發(fā)新應(yīng)用和新特征的實(shí)驗(yàn)，不要求注冊(cè)包類型值。帶有不可識(shí)別名稱的APP包應(yīng)被忽略掉。測(cè)試后，如確定應(yīng)用廣泛，推薦重新定義每個(gè)APP包，而不用向IANA注冊(cè)子類型和名稱段。
|-page-|
實(shí)時(shí)流協(xié)議RTSP
實(shí)時(shí)流協(xié)議RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，該協(xié)議定義了一對(duì)多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。RTSP在體系結(jié)構(gòu)上位于RTP和RTCP之上，它使用TCP或RTP完成數(shù)據(jù)傳輸。HTTP與RTSP相比，HTTP傳送HTML，而RTP傳送的是多媒體數(shù)據(jù)。HTTP請(qǐng)求由客戶機(jī)發(fā)出，服務(wù)器作出響應(yīng)；使用RTSP時(shí)，客戶機(jī)和服務(wù)器都可以發(fā)出請(qǐng)求，即RTSP可以是雙向的。
6.3 RTSP協(xié)議
實(shí)時(shí)流協(xié)議（RTSP）是應(yīng)用級(jí)協(xié)議，控制實(shí)時(shí)數(shù)據(jù)的發(fā)送。RTSP提供了一個(gè)可擴(kuò)展框架，使實(shí)時(shí)數(shù)據(jù)，如音頻與視頻，的受控、點(diǎn)播成為可能。數(shù)據(jù)源包括現(xiàn)場(chǎng)數(shù)據(jù)與存儲(chǔ)在剪輯中數(shù)據(jù)。該協(xié)議目的在于控制多個(gè)數(shù)據(jù)發(fā)送連接，為選擇發(fā)送通道，如UDP、組播UDP與TCP，提供途徑，并為選擇基于RTP上發(fā)送機(jī)制提供方法。
6.3.1 簡(jiǎn)介
6.3.1.1 目的
實(shí)時(shí)流協(xié)議（RTSP）建立并控制一個(gè)或幾個(gè)時(shí)間同步的連續(xù)流媒體。盡管連續(xù)媒體流與控制流交叉是可能的，通常它本身并不發(fā)送連續(xù)流。換言之，RTSP充當(dāng)多媒體服務(wù)器的網(wǎng)絡(luò)遠(yuǎn)程控制。RTSP連接沒有綁定到傳輸層連接，如TCP。在RTSP連接期間，RTSP用戶可打開或關(guān)閉多個(gè)對(duì)服務(wù)器的可靠傳輸連接以發(fā)出RTSP 請(qǐng)求。此外，可使用無連接傳輸協(xié)議，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依賴用于攜帶連續(xù)媒體的傳輸機(jī)制。實(shí)時(shí)流協(xié)議在語法和操作上與HTTP/1.1類似，因此HTTP的擴(kuò)展機(jī)制大都可加入RTSP。協(xié)議支持的操作如下：
從媒體服務(wù)器上檢索媒體：
用戶可通過HTTP或其它方法提交一個(gè)演示描述。如演示是組播，演示式就包含用于連續(xù)媒體的的組播地址和端口。如演示僅通過單播發(fā)送給用戶，用戶為了安全應(yīng)提供目的地址。
媒體服務(wù)器邀請(qǐng)進(jìn)入會(huì)議：
媒體服務(wù)器可被邀請(qǐng)參加正進(jìn)行的會(huì)議，或回放媒體，或記錄其中一部分，或全部。這種模式在分布式教育應(yīng)用上很有用，會(huì)議中幾方可輪流按遠(yuǎn)程控制按鈕。
將媒體加到現(xiàn)成講座中：
如服務(wù)器告訴用戶可獲得附加媒體內(nèi)容，對(duì)現(xiàn)場(chǎng)講座顯得尤其有用。如HTTP/1.1中類似，RTSP請(qǐng)求可由代理、通道與緩存處理。
6.3.1.2 協(xié)議特點(diǎn)
RTSP 特性如下：
可擴(kuò)展性：
新方法和參數(shù)很容易加入RTSP。
易解析：
RTSP可由標(biāo)準(zhǔn) HTTP或MIME解吸器解析。
安全：
RTSP使用網(wǎng)頁安全機(jī)制。
獨(dú)立于傳輸：
RTSP可使用不可靠數(shù)據(jù)報(bào)協(xié)議（UDP）、可靠數(shù)據(jù)報(bào)協(xié)議（RDP），如要實(shí)現(xiàn)應(yīng)用級(jí)可靠，可使用可靠流協(xié)議。
多服務(wù)器支持：
每個(gè)流可放在不同服務(wù)器上，用戶端自動(dòng)同不同服務(wù)器建立幾個(gè)并發(fā)控制連接，媒體同步在傳輸層執(zhí)行。
記錄設(shè)備控制：
協(xié)議可控制記錄和回放設(shè)備。
流控與會(huì)議開始分離：
僅要求會(huì)議初始化協(xié)議提供，或可用來創(chuàng)建唯一會(huì)議標(biāo)識(shí)號(hào)。特殊情況下， SIP或H.323
可用來邀請(qǐng)服務(wù)器入會(huì)。
適合專業(yè)應(yīng)用：
通過SMPTE 時(shí)標(biāo)，RTSP支持幀級(jí)精度，允許遠(yuǎn)程數(shù)字編輯
演示描述中立：
協(xié)議沒強(qiáng)加特殊演示或元文件，可傳送所用格式類型；然而，演示描述至少必須包含一個(gè)RTSP URI。
代理與防火墻友好：
協(xié)議可由應(yīng)用和傳輸層防火墻處理。防火墻需要理解SETUP方法，為UDP媒體流打開一個(gè)"缺口"。
HTTP友好：
此處，RTSP明智的采用HTTP觀念，使現(xiàn)在結(jié)構(gòu)都可重用。結(jié)構(gòu)包括Internet 內(nèi)容選擇平臺(tái)（PICS）。由于在大多數(shù)情況下控制連續(xù)媒體需要服務(wù)器狀態(tài)， RTSP不僅僅向HTTP 添加方法。
適當(dāng)?shù)姆?wù)器控制：
如用戶啟動(dòng)一個(gè)流，他必須也可以停止一個(gè)流。
傳輸協(xié)調(diào)；
實(shí)際處理連續(xù)媒體流前，用戶可協(xié)調(diào)傳輸方法。
性能協(xié)調(diào)：
如基本特征無效，必須有一些清理機(jī)制讓用戶決定那種方法沒生效。這允許用戶提出適合的用戶界面。
6.3.1.3擴(kuò)展RTSP
由于不是所有媒體服務(wù)器有著相同的功能，媒體服務(wù)器有必要支持不同請(qǐng)求集。RTSP 可以如下三種方式擴(kuò)展，這里以改變大小排序：
以新參數(shù)擴(kuò)展。如用戶需要拒絕通知，而方法擴(kuò)展不支持，相應(yīng)標(biāo)記就加入要求的段中。
加入新方法。如信息接收者不理解請(qǐng)求，返回501錯(cuò)誤代碼（還未實(shí)現(xiàn)），發(fā)送者不應(yīng)再次嘗試這種方法。用戶可使用OPTIONS方法查詢服務(wù)器支持的方法。服務(wù)器使用公共響應(yīng)頭列出支持的方法。
定義新版本協(xié)議，允許改變所有部分。（除了協(xié)議版本號(hào)位置）
6.3.1.4操作模式
每個(gè)演示和媒體流可用RTSP URL識(shí)別。演示組成的整個(gè)演示與媒體屬性由演示描述文件定義。使用HTTP或其它途徑用戶可獲得這個(gè)文件，它沒有必要保存在媒體服務(wù)器上。
為了說明，假設(shè)演示描述描述了多個(gè)演示，其中每個(gè)演示維持了一個(gè)公共時(shí)間軸。為簡(jiǎn)化說明，且不失一般性，假定演示描述的確包含這樣一個(gè)演示。演示可包含多個(gè)媒體流。除媒體參數(shù)外，網(wǎng)絡(luò)目標(biāo)地址和端口也需要決定。下面區(qū)分幾種操作模式：
單播：
以用戶選擇的端口號(hào)將媒體發(fā)送到RTSP請(qǐng)求源。
組播，服務(wù)器選擇地址：
媒體服務(wù)器選擇組播地址和端口，這是現(xiàn)場(chǎng)直播或準(zhǔn)點(diǎn)播常用的方式。
組播，用戶選擇地址：
如服務(wù)器加入正在進(jìn)行的組播會(huì)議，組播地址、端口和密匙由會(huì)議描述給出。
6.3.1.5 RTSP狀態(tài)
RTSP控制通過單獨(dú)協(xié)議發(fā)送的流，與控制通道無關(guān)。例如，RTSP控制可通過TCP連接，而數(shù)據(jù)流通過UDP。因此，即使媒體服務(wù)器沒有收到請(qǐng)求，數(shù)據(jù)也會(huì)繼續(xù)發(fā)送。在連接生命期，單個(gè)媒體流可通過不同TCP連接順序發(fā)出請(qǐng)求來控制。所以，服務(wù)器需要維持能聯(lián)系流與RTSP請(qǐng)求的連接狀態(tài)。RTSP中很多方法與狀態(tài)無關(guān)，但下列方法在定義服務(wù)器流資源的分配與應(yīng)用上起著重要的作用：
SETUP：
讓服務(wù)器給流分配資源，啟動(dòng)RTSP連接。
PLAY與RECORD：
啟動(dòng)SETUP 分配流的數(shù)據(jù)傳輸。
PAUSE：
臨時(shí)停止流，而不釋放服務(wù)器資源。
TEARDOWN：
釋放流的資源，RTSP連接停止。
標(biāo)識(shí)狀態(tài)的RTSP方法使用連接頭段識(shí)別RTSP連接，為響應(yīng)SETUP請(qǐng)求，服務(wù)器連
接產(chǎn)生連接標(biāo)識(shí)。
6.3.1.6 與其他協(xié)議關(guān)系
RTSP在功能上與HTTP有重疊，與HTTP相互作用體現(xiàn)在與流內(nèi)容的初始接觸是通過網(wǎng)頁的。目前的協(xié)議規(guī)范目的在于允許在網(wǎng)頁服務(wù)器與實(shí)現(xiàn)RTSP媒體服務(wù)器之間存在不同傳遞點(diǎn)。例如，演示描述可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨(dú)立RTSP 服務(wù)器與用戶不全依靠HTTP。
但是，RTSP與HTTP 的本質(zhì)差別在于數(shù)據(jù)發(fā)送以不同協(xié)議進(jìn)行。HTTP是不對(duì)稱協(xié)議，用戶發(fā)出請(qǐng)求，服務(wù)器作出響應(yīng)。RTSP中，媒體用戶和服務(wù)器都可發(fā)出請(qǐng)求，且其請(qǐng)求都是無狀態(tài)的；在請(qǐng)求確認(rèn)后很長(zhǎng)時(shí)間內(nèi)，仍可設(shè)置參數(shù)，控制媒體流。重用HTTP功能至少在兩個(gè)方面有好處，即安全和代理。要求非常接近，在緩存、代理和授權(quán)上采用HTTP功能是有價(jià)值的。
當(dāng)大多數(shù)實(shí)時(shí)媒體使用RTP作為傳輸協(xié)議時(shí)，RTSP沒有綁定到RTP。RTSP假設(shè)存在演示描述格式可表示包含幾個(gè)媒體流的演示的靜態(tài)與臨時(shí)屬性。
6.3.2 協(xié)議參數(shù)
6.3.3 RTSP 信息
RTSP是基于文本的協(xié)議，采用ISO 10646 字符集，使用UTF-8編碼方案。行以CRLF中斷，但接收者本身可將CR和LF解釋成行終止符。基于文本的協(xié)議使以自描述方式增加可選參數(shù)更容易。由于參數(shù)的數(shù)量和命令的頻率出現(xiàn)較低，處理效率沒引起注意。如仔細(xì)研究，文本協(xié)議很容易以腳本語言（如：Tcl、Visual Basic與Perl）實(shí)現(xiàn)研究原型。
10646字符集避免敏感字符集切換，但對(duì)應(yīng)用來說不可見。RTCP也采用這種編碼方案。帶有重要意義位的ISO 8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通過任何低層傳輸協(xié)議攜帶。
請(qǐng)求包括方法、方法作用于其上的對(duì)象和進(jìn)一步描述方法的參數(shù)。方法也可設(shè)計(jì)為在服務(wù)器端只需要少量或不需要狀態(tài)維護(hù)。當(dāng)信息體包含在信息中，信息體長(zhǎng)度有如下因素決定：
不管實(shí)體頭段是否出現(xiàn)在信息中，不包括信息體的的響應(yīng)信息總以頭段后第一和空行結(jié)束。
如出現(xiàn)內(nèi)容長(zhǎng)度頭段，其值以字節(jié)計(jì)，表示信息體長(zhǎng)度。如未出現(xiàn)頭段，其值為零。
服務(wù)器關(guān)閉連接。
注意：RTSP目前并不支持HTTP/1.1"塊"傳輸編碼，需要有內(nèi)容長(zhǎng)度頭。假如返回適度演示描述長(zhǎng)度，即使動(dòng)態(tài)產(chǎn)生，使塊傳輸編碼沒有必要，服務(wù)器也應(yīng)該能決定其長(zhǎng)度。如有實(shí)體，即使必須有內(nèi)容長(zhǎng)度，且長(zhǎng)度沒顯式給出，規(guī)則可確保行為合理。
從用戶到服務(wù)器端的請(qǐng)求信息在第一行內(nèi)包括源采用的方法、源標(biāo)識(shí)和所用協(xié)議版本。RTSP定義了附加狀態(tài)代碼，而沒有定義任何HTTP代碼。
6.3.4 實(shí)體
如不受請(qǐng)求方法或響應(yīng)狀態(tài)編碼限制，請(qǐng)求和響應(yīng)信息可傳輸實(shí)體，實(shí)體由實(shí)體頭文件和試題體組成，有些響應(yīng)僅包括實(shí)體頭。在此，根據(jù)誰發(fā)送實(shí)體、誰接收實(shí)體，發(fā)送者和接收者可分別指用戶和服務(wù)器。
實(shí)體頭定義實(shí)體體可選元信息，如沒有實(shí)體體，指請(qǐng)求標(biāo)識(shí)的資源。擴(kuò)展頭機(jī)制允許定義附加實(shí)體頭段，而不用改變協(xié)議，但這些段不能假定接收者能識(shí)別。不可識(shí)別頭段應(yīng)被接收者忽略，而讓代理轉(zhuǎn)發(fā)。
6.3.5 連接
RTSP請(qǐng)求可以幾種不同方式傳送：
1、持久傳輸連接，用于多個(gè)請(qǐng)求/響應(yīng)傳輸。
2、每個(gè)請(qǐng)求/響應(yīng)傳輸一個(gè)連接。
3、無連接模式。
傳輸連接類型由RTSP URI來定義。對(duì) "rtsp" 方案，需要持續(xù)連接；而"rtspu"方案，調(diào)用RTSP 請(qǐng)求發(fā)送，而不用建立連接。
不象HTTP，RTSP允許媒體服務(wù)器給媒體用戶發(fā)送請(qǐng)求。然而，這僅在持久連接時(shí)才支持，否則媒體服務(wù)器沒有可靠途徑到達(dá)用戶，這也是請(qǐng)求通過防火墻從媒體服務(wù)器傳到用戶的唯一途徑。
6.3.6 方法定義
方法記號(hào)表示資源上執(zhí)行的方法，它區(qū)分大小寫。新方法可在將來定義，但不能以$開頭。
某些防火墻設(shè)計(jì)與其他環(huán)境可能要求服務(wù)器插入RTSP方法和流數(shù)據(jù)。由于插入將使客戶端和服務(wù)器操作復(fù)雜，并強(qiáng)加附加開銷，除非有必要，應(yīng)避免這樣做。插入二進(jìn)制數(shù)據(jù)僅在RTSP通過TCP傳輸時(shí)才可使用。流數(shù)據(jù)（如RTP包）用一個(gè)ASCII美圓符號(hào)封裝，后跟一個(gè)一字節(jié)通道標(biāo)識(shí)，其后是封裝二進(jìn)制數(shù)據(jù)的長(zhǎng)度，兩字節(jié)整數(shù)。流數(shù)據(jù)緊跟其后，沒有CRLF，但包括高層協(xié)議頭。每個(gè)$塊包含一個(gè)高層協(xié)議數(shù)據(jù)單元。
當(dāng)傳輸選擇為RTP，RTCP信息也被服務(wù)器通過TCP連接插入。缺省情況下，RTCP包在比RTP通道高的第一個(gè)可用通道上發(fā)送。客戶端可能在另一通道顯式請(qǐng)求RTCP包，這可通過指定傳輸頭插入?yún)?shù)中的兩個(gè)通道來做到。當(dāng)兩個(gè)或更多流交叉時(shí)，為取得同步，需要RTCP。而且，這為當(dāng)網(wǎng)絡(luò)設(shè)置需要通過TCP控制連接透過RTP/RTCP提供了一條方便的途徑，可能時(shí)，在UDP上進(jìn)行傳輸。
6.3.7 流水線操作
支持持久連接或無連接的客戶端可能給其請(qǐng)求排隊(duì)。服務(wù)器必須以收到請(qǐng)求的同樣順序發(fā)出響應(yīng)。如果請(qǐng)求不是發(fā)送給組播組，接收者就確認(rèn)請(qǐng)求，如沒有確認(rèn)信息，發(fā)送者可在超過一個(gè)來回時(shí)間（RTT）后重發(fā)同一信息。
RTT在TCP中估計(jì)，初始值為500 ms。應(yīng)用緩存最后所測(cè)量的RTT，作為將來連接的初始值。如使用一個(gè)可靠傳輸協(xié)議傳輸RTSP，請(qǐng)求不允許重發(fā)，RTSP應(yīng)用反過來依賴低層傳輸提供可靠性。如兩個(gè)低層可靠傳輸（如TCP 和RTSP）應(yīng)用重發(fā)請(qǐng)求，有可能每個(gè)包損失導(dǎo)致兩次重傳。由于傳輸棧在第一次嘗試到達(dá)接收著者前不會(huì)發(fā)送應(yīng)用層重傳，接收者也不能充分利用應(yīng)用層重傳。如包損失由阻塞引起，不同層的重發(fā)將使阻塞進(jìn)一步惡化。時(shí)標(biāo)頭用來避免重發(fā)模糊性問題，避免對(duì)圓錐算法的依賴。每個(gè)請(qǐng)求在CSeq頭中攜帶一個(gè)系列號(hào)，每發(fā)送一個(gè)不同請(qǐng)求，它就加一。如由于沒有確認(rèn)而重發(fā)請(qǐng)求，請(qǐng)求必須攜帶初始系列號(hào)。
實(shí)現(xiàn)RTSP的系統(tǒng)必須支持通過TCP傳輸RTSP ，并支持UDP。對(duì)UDP和TCP，RTSP服務(wù)器的缺省端口都是554。許多目的一致的RTSP包被打包成單個(gè)低層PDU或TCP流。RTSP數(shù)據(jù)可與RTP和RTCP包交叉。不象HTTP，RTSP信息必須包含一個(gè)內(nèi)容長(zhǎng)度頭，無論信息何時(shí)包含負(fù)載。否則，RTSP包以空行結(jié)束，后跟最后一個(gè)信息頭。
|-page-|
資源預(yù)訂協(xié)議RSVP協(xié)議
由于音頻和視頻數(shù)據(jù)流比傳統(tǒng)數(shù)據(jù)對(duì)網(wǎng)絡(luò)的延時(shí)更敏感，要在網(wǎng)絡(luò)中傳輸高質(zhì)量的音頻、視頻信息，除帶寬要求之外，還需其他更多的條件。RSVP(ResourceReserveProtocol)是正在開發(fā)的Internet上的資源預(yù)訂協(xié)議，使用RSVP預(yù)留一部分網(wǎng)絡(luò)資源（即帶寬），能在一定程度上為流媒體的傳輸提供QoS。在某些試驗(yàn)性的系統(tǒng)如網(wǎng)絡(luò)視頻會(huì)議工具vic中就集成了RSVP。
6.4 RSVP協(xié)議
6.4.1 背景
資源預(yù)訂協(xié)議（RSVP）是網(wǎng)絡(luò)控制協(xié)議，它使Internet應(yīng)用傳輸數(shù)據(jù)流時(shí)能夠獲得特殊服務(wù)質(zhì)量（QoSs），RSVP是非路由協(xié)議；它同路由協(xié)議協(xié)同工作，建立與路由協(xié)議計(jì)算出路由等價(jià)的動(dòng)態(tài)訪問列表， RSVP屬OSI 七層協(xié)議棧中傳輸層，開始是研究人員構(gòu)造的，IETF正朝標(biāo)準(zhǔn)化方向努力，圖3.4 說明了RSVP運(yùn)行環(huán)境。
圖3.4 RSVP中主機(jī)信息通過數(shù)據(jù)流發(fā)送給接收者示意圖
6.4.2 RSVP數(shù)據(jù)流
在RSVP中，數(shù)據(jù)流是一系列信息，有著相同的源、目的（可有多個(gè)）和服務(wù)質(zhì)量，QoS要求通過網(wǎng)絡(luò)以流說明形式通訊。流說明是互連網(wǎng)主機(jī)用來請(qǐng)求特殊服務(wù)的數(shù)據(jù)結(jié)構(gòu)，保證互連網(wǎng)處理主機(jī)傳輸。RSVP支持三種傳輸類型：最好性能（best-effort），速率敏感（rate-sensitive）與延遲敏感（delay-sensitive）。用來支持這些傳輸類型的數(shù)據(jù)流服務(wù)依賴QoS實(shí)施，以下部分陳述傳輸類型與相關(guān)服務(wù)。
最好性能傳輸為傳統(tǒng)IP傳輸。應(yīng)用包括文件傳輸（如郵件傳輸）、磁盤映像、交互登錄和事務(wù)傳輸。支持最好性能傳輸?shù)姆?wù)稱為最好性能服務(wù)。速率敏感傳輸放棄及時(shí)性，而確保速率。例如：速率敏感傳輸請(qǐng)求100 kbps帶寬，如在擴(kuò)展期實(shí)際發(fā)送200 kbps，路由器可能延遲傳輸。速率敏感傳輸目的不在通過電路交換網(wǎng)絡(luò)傳輸，但它通常與電路交換網(wǎng)絡(luò)（ISDN）應(yīng)用有聯(lián)系，現(xiàn)在正運(yùn)行在數(shù)據(jù)報(bào)網(wǎng)絡(luò)（IP）上。這類應(yīng)用如H.323視頻會(huì)議，設(shè)計(jì)運(yùn)行在ISDN （H.320）或ATM（H.310）上，但發(fā)現(xiàn)在Internet上也有應(yīng)用。H.323編碼是常數(shù)速率或準(zhǔn)常數(shù)速率，它需要常數(shù)傳輸速率。RSVP服務(wù)支持速率敏感傳輸，稱為位速率保證服務(wù)。延遲敏感傳輸要求傳輸及時(shí)，并因而改變其速率。例如：MPEG-II視頻根據(jù)圖象改變量大小平均流量為3 到7 Mbps，3 Mbps可能對(duì)應(yīng)一堵上色的墻，而7 Mbps 可能是海洋的波浪。MPEG-II視頻源發(fā)送關(guān)鍵和增量幀。典型的，每秒一個(gè)或兩個(gè)關(guān)鍵幀，描述整個(gè)圖象，而每秒13或28幀描述關(guān)鍵幀之間的變化，增量幀通常比關(guān)鍵幀小。因此，幀與幀之間速率變化較大。但由于單個(gè)幀要求在一幀時(shí)間內(nèi)發(fā)送出去，或解碼器速度跟不上，必須對(duì)增量幀傳輸進(jìn)行特定優(yōu)先級(jí)別協(xié)調(diào)。RSVP服務(wù)支持延遲敏感傳輸，被看作控制延遲服務(wù)（非實(shí)時(shí)服務(wù)）與預(yù)報(bào)服務(wù)（實(shí)時(shí)服務(wù)）。
6.4.3 RSVP 數(shù)據(jù)流處理
RSVP數(shù)據(jù)流基本特征是連接，數(shù)據(jù)包在其上流通。連接是具有相同單播或組播目的數(shù)據(jù)流，RSVP分別處理每個(gè)連接。RSVP支持單播和組播連接（這里連接是一些發(fā)送者與另一些接收者的會(huì)話），而流總是從發(fā)送者開始的。特定連接的數(shù)據(jù)包被導(dǎo)向同一個(gè)IP目的地址或公開的目的端口。IP目的地址可能是組播發(fā)送的組地址，也可能是單個(gè)接收者的單播地址。公開目的端口可用UDP/TCP目的端口段、另外傳輸協(xié)議等價(jià)段或某些應(yīng)用特定信息定義。
RSVP數(shù)據(jù)發(fā)布是通過組播或單播實(shí)現(xiàn)的。組播傳輸將某個(gè)發(fā)送者的每個(gè)數(shù)據(jù)包拷貝轉(zhuǎn)發(fā)給多個(gè)目的。單播傳輸特征是只有一個(gè)接收者。即使目的地址是單播，也可能有多個(gè)接收者，以公開端口區(qū)分。多個(gè)發(fā)送者也可能存在單播地址，在這種情況下，RSVP可建立多對(duì)一傳輸?shù)馁Y源預(yù)訂。每個(gè)RSVP發(fā)送者和接收者對(duì)應(yīng)唯一的Internet主機(jī)。然而，單個(gè)主機(jī)可包括多個(gè)發(fā)送者和接收者，以公開端口區(qū)分。
RSVP服務(wù)質(zhì)量(QoS)
在RSVP中，服務(wù)質(zhì)量（QoS）是流規(guī)范指定的屬性，流規(guī)范用于決定參加實(shí)體（路由器、接收者和發(fā)送者）進(jìn)行數(shù)據(jù)交換的方式。主機(jī)和路由器使用RSVP指定QoS；其中主機(jī)代表應(yīng)用數(shù)據(jù)流使用RSVP從網(wǎng)絡(luò)申請(qǐng)QoS級(jí)別，而路由器使用RSVP發(fā)送QoS請(qǐng)求給數(shù)據(jù)流路經(jīng)的其它路由器。這樣做，RSVP就可維持路由器和主機(jī)狀態(tài)來提供所請(qǐng)求的服務(wù)。
RSVP連接啟動(dòng)
為了初始化RSVP組播連接，接收者首先使用Internet組成員協(xié)議（IGMP）加入IP目的地址指定的組播組。對(duì)單播連接，單播路由就象IGMP結(jié)合協(xié)議無關(guān)組播（PIM）在組播時(shí)的作用。接收者加入組后，潛在的發(fā)送者就開始發(fā)送RSVP路徑信息給IP目的地址。接收者應(yīng)用收到路徑信息，開始發(fā)送相應(yīng)資源預(yù)訂請(qǐng)求信息，使用RSVP指定欲點(diǎn)播的流描述。發(fā)送者應(yīng)用接收到資源預(yù)訂請(qǐng)求信息后，發(fā)送者開始發(fā)送數(shù)據(jù)包。
6.4.4 RSVP資源預(yù)訂類型
資源預(yù)訂類型指一套指定所支持參數(shù)的控制選項(xiàng)。RSVP支持兩種主要資源預(yù)訂：獨(dú)占資源預(yù)訂和共享資源預(yù)訂。獨(dú)占資源預(yù)訂為每個(gè)連接中每個(gè)相關(guān)發(fā)送者安裝一個(gè)流；而共享資源預(yù)訂由互不相關(guān)的發(fā)送者使用。表3.10說明這兩種資源預(yù)訂協(xié)議的應(yīng)用范圍及所支持的范圍與類型的組合情況。
6.4.5 RSVP軟狀態(tài)實(shí)現(xiàn)
對(duì)RSVP，軟狀態(tài)指可被某些RSVP信息更新的路由器和終端結(jié)點(diǎn)的狀態(tài)。軟狀態(tài)特征允許RSVP網(wǎng)絡(luò)支持動(dòng)態(tài)組成員變化，并適應(yīng)路由變化。一般說來，軟狀態(tài)由基于RSVP網(wǎng)絡(luò)維護(hù)，使網(wǎng)絡(luò)可在沒有查詢終端結(jié)點(diǎn)的情況下改變狀態(tài)。對(duì)比電路交換結(jié)構(gòu)，終端結(jié)點(diǎn)進(jìn)行依次呼叫，如失敗，進(jìn)行依次新呼叫。
RSVP協(xié)議為創(chuàng)建和維護(hù)組播和單播混合發(fā)送路徑的分布式資源預(yù)訂狀態(tài)提供了一個(gè)通用功能。為維護(hù)資源預(yù)訂狀態(tài)，RSVP跟蹤路由器和主機(jī)結(jié)點(diǎn)的軟狀態(tài)。路徑與資源預(yù)訂請(qǐng)求信息創(chuàng)建并周期更新RSVP軟狀態(tài)。如在清除時(shí)間間隔到期前沒有收到相應(yīng)更新信息，就刪除該狀態(tài)，顯式teardown 信息也可刪除軟狀態(tài)。RSVP周期掃描欲建立的軟狀態(tài)，并轉(zhuǎn)發(fā)路徑與預(yù)訂請(qǐng)求更新信息給下一跳。
當(dāng)路由改變，下一個(gè)路徑信息初始化新路由的路徑狀態(tài)，將來資源預(yù)訂請(qǐng)求信息建立資源預(yù)訂狀態(tài)。現(xiàn)在未使用的網(wǎng)段狀態(tài)標(biāo)記為超時(shí)。（RSVP規(guī)范要求在拓?fù)涓淖兒髢擅胪ㄟ^網(wǎng)絡(luò)初始化新資源預(yù)訂）。當(dāng)發(fā)生狀態(tài)變化，RSVP無延遲的將變化從RSVP網(wǎng)絡(luò)的一個(gè)終端傳到另一個(gè)終端。如接收到的狀態(tài)與存儲(chǔ)狀態(tài)不同，就更新存儲(chǔ)狀態(tài)。如結(jié)果改變了欲產(chǎn)生的更新信息，更新信息立即生成并轉(zhuǎn)發(fā)出去。
6.4.6 RSVP 操作模型
在RSVP下，資源為簡(jiǎn)單數(shù)據(jù)流（單向數(shù)據(jù)流）預(yù)訂起來。每個(gè)發(fā)送者邏輯上與接收者不同，但任何應(yīng)用都可充當(dāng)發(fā)送者和接收者，接收者負(fù)責(zé)請(qǐng)求資源預(yù)訂。圖3.5說明了其基本操作環(huán)境，緊接部分將提供特定事件序列的框架。
圖3.5 RSVP 操作環(huán)境：為單向數(shù)據(jù)流預(yù)訂資源
6.4.6.1基本RSVP協(xié)議操作
RSVP資源預(yù)訂處理初始化開始于RSVP 后臺(tái)服務(wù)查詢本地路由協(xié)議以獲得路由。主機(jī)發(fā)送IGMP消息加入組播組，而發(fā)送RSVP消息預(yù)訂沿組路徑的資源。每個(gè)能加入資源預(yù)訂的路由器將收到的數(shù)據(jù)包傳遞給包分類器，然后將它們?cè)诎{(diào)度器中排隊(duì)。RSVP包分類器決定每個(gè)包的路由和QoS類；RSVP調(diào)度器給每個(gè)接口所使用的特殊數(shù)據(jù)鏈路層媒介上傳輸分配資源。如數(shù)據(jù)鏈路層媒介有自身的QoS管理能力，包調(diào)度器負(fù)責(zé)協(xié)調(diào)數(shù)據(jù)鏈路層，獲得RSVP所請(qǐng)求的QoS。調(diào)度器本身分配無源QoS媒介上包傳輸能力，如雙鉸線；也可分配其它系統(tǒng)資源，如CPU時(shí)間與緩存。QoS請(qǐng)求一般發(fā)源于接收者主機(jī)應(yīng)用，而被傳遞到本地RSVP應(yīng)用，如RSVP 后臺(tái)服務(wù)。RSVP協(xié)議接著將對(duì)所有結(jié)點(diǎn)（路又器與主機(jī)）的請(qǐng)求沿逆向數(shù)據(jù)路徑傳到到數(shù)據(jù)源。在每個(gè)結(jié)點(diǎn)處，RSVP程序應(yīng)用一個(gè)稱為進(jìn)入允許控制的本地決定程序決定是否能提供所請(qǐng)求的QoS。如進(jìn)入允許控制成功，RSVP程序設(shè)置包分類和調(diào)度器的參數(shù)，以獲得所申請(qǐng)的QoS。如進(jìn)入允許控制在某結(jié)點(diǎn)處失敗，RSVP程序給產(chǎn)生此請(qǐng)求的應(yīng)用返回一個(gè)錯(cuò)誤指示。
6.4.6.2 RSVP 隧道
在整個(gè)Internet上同時(shí)配置RSVP或任意其他協(xié)議都是不可能的。實(shí)際上，RSVP決不可能在每個(gè)地方都被配置。因此，RSVP必須提供正確協(xié)議操作，即使只有兩個(gè)支持RSVP的路由器與一群不支持RSVP的路由器相連。一個(gè)中等規(guī)模不支持RSVP的網(wǎng)絡(luò)不能執(zhí)行資源預(yù)訂，因而服務(wù)保證也就不能實(shí)現(xiàn)。然而，如該網(wǎng)絡(luò)有充足額外容量，也可以提供可接受的實(shí)時(shí)服務(wù)。
為了支持RSVP網(wǎng)絡(luò)連接通過不支持RSVP的網(wǎng)絡(luò)，RSVP支持隧道技術(shù)。隧道技術(shù)要求RSVP和非RSVP路由器用本地路由表轉(zhuǎn)發(fā)到目的地址的路徑信息。當(dāng)路徑信息通過非RSVP 網(wǎng)絡(luò)時(shí)，路徑信息拷貝攜帶最后一個(gè)支持RSVP的路由器的IP地址。預(yù)訂請(qǐng)求信息轉(zhuǎn)發(fā)給下一個(gè)上游支持RSVP的路由器
6.4.7 加權(quán)平均排隊(duì)方案
用技術(shù)來加強(qiáng)出現(xiàn)瓶頸處的有效資源預(yù)訂（如Cisco的加權(quán)平均排隊(duì)方案）有著正面影響。隧道技術(shù)僅在瓶頸出在非RSVP 域且不可避免時(shí)才有風(fēng)險(xiǎn)。圖3.6表示基于RSVP網(wǎng)絡(luò)間采用隧道技術(shù)的RSVP環(huán)境
圖3.6 ：應(yīng)用隧道技術(shù)的RSVP環(huán)境
6.4.8 RSVP 消息
RSVP支持四種基本消息類型：資源預(yù)訂請(qǐng)求消息、路徑消息、錯(cuò)誤與確認(rèn)消息和斷開消息。
6.4.9 RSVP 包格式
表3.11說明了RSVP包格式，如下內(nèi)容列出格式的頭和對(duì)象段。
表3.11 RSVP包格式 RSVP消息頭段（長(zhǎng)度單位：位） 4 4 8 16 16 8 8 32 15 1 16 版本標(biāo)志類型校驗(yàn)和長(zhǎng)度預(yù)訂發(fā)送TTL 消息ID 預(yù)訂 MF 偏移量 RSVP對(duì)象段（長(zhǎng)度單位：位） 16 8 8 可變長(zhǎng)度分類號(hào) C類型對(duì)象內(nèi)容
RSVP 消息頭段
RSVP 消息頭段組成：
版本號(hào)---4位，表示協(xié)議版本號(hào)（當(dāng)前版本為1）。
標(biāo)志---4位，當(dāng)前沒有定義標(biāo)志段。
類型---8位，有幾種可能值，如表3.12所示。
表3.12：RSVP消息類型段取值值消息類型 1 路徑 2 資源預(yù)訂請(qǐng)求 3 路徑錯(cuò)誤 4 資源預(yù)訂請(qǐng)求錯(cuò)誤 5 路徑斷開 6 資源預(yù)訂斷開 7 資源預(yù)訂請(qǐng)求確認(rèn)校驗(yàn)和---16位，表示基于RSVP消息的內(nèi)容上標(biāo)準(zhǔn)TCP/UDP校驗(yàn)和。
長(zhǎng)度---16-位，表示RSVP包的字節(jié)長(zhǎng)度，包括公共頭和隨后的可變長(zhǎng)度對(duì)象。如設(shè)置了MF標(biāo)志，或片段偏移為非零值，這就是較大消息當(dāng)前片段長(zhǎng)度。
發(fā)送TTL---8位，表示消息發(fā)送的IP生存期。
消息ID---32位，提供下一RSVP跳/前一RSVP跳消息中所有片段共享標(biāo)簽。
更多片段 (MF) 標(biāo)志---一個(gè)字節(jié)的最低位，其它7位預(yù)訂，除消息的最后一個(gè)片段外，都將設(shè)置MF。
片段偏移---24位，表示消息中片段的字節(jié)偏移量。
RSVP 對(duì)象段
RSVP 對(duì)象段組成如下：
長(zhǎng)度---16-位，包含總對(duì)象長(zhǎng)度，以字節(jié)計(jì)（必須是4的倍數(shù)，至少是4）。
分類號(hào)---表示對(duì)象類型，每個(gè)對(duì)象類型都有一個(gè)名稱。RSVP程序必須可識(shí)別分類，類型在表3.13列出。如沒有識(shí)別出對(duì)象分類號(hào)，分類號(hào)高位決定結(jié)點(diǎn)采用什么行動(dòng)。
C-類型---C類型，在分類號(hào)中唯一。最大內(nèi)容長(zhǎng)度是65528個(gè)字節(jié)。分類號(hào)和C-類型段(與標(biāo)志位一起) 可用作定義每個(gè)對(duì)象唯一位的16位數(shù)。
對(duì)象內(nèi)容---長(zhǎng)度、類型號(hào)和C類型段指定對(duì)象內(nèi)容的形式。
6.4.10 RSVP小結(jié)
RSVP運(yùn)行在傳輸層，在IP上層。與ICMP和IGMP相比，它是一個(gè)控制協(xié)議。RSVP的組成元素有發(fā)送者、接收者和主機(jī)或路由器。發(fā)送者負(fù)責(zé)讓接收者知道數(shù)據(jù)將要發(fā)送，以及需要什么樣的QoS；接收者負(fù)責(zé)發(fā)送一個(gè)通知到主機(jī)或路由器，這樣他們就可以準(zhǔn)備接收即將到來的數(shù)據(jù)；主機(jī)或路由器負(fù)責(zé)留出所有合適的資源。
RSVP協(xié)議的兩個(gè)重要概念是流與預(yù)定。流是從發(fā)送者到一個(gè)或多個(gè)接收者的連接特征，通過IP包中"流標(biāo)記"來認(rèn)證。發(fā)送一個(gè)流前，發(fā)送者傳輸一個(gè)路徑信息到目的接收方，這個(gè)信息包括源IP地址、目的IP地址和一個(gè)流規(guī)格。這個(gè)流規(guī)格是由流的速率和延遲組成的，這是流的QoS需要的。接收者實(shí)現(xiàn)預(yù)定后，基于接收者的模式能夠?qū)崿F(xiàn)一種分布式解決方案。
RSVP領(lǐng)域的發(fā)展是非常迅速的，但目前并沒有在任何一種網(wǎng)絡(luò)上得到證實(shí)，它的應(yīng)用只是局限在測(cè)試的小Intranet網(wǎng)絡(luò)上。因?yàn)?/span>RSVP的預(yù)定必須建立在完全流方式的基礎(chǔ)上，其可擴(kuò)展性問題倍受關(guān)注。RSVP還存在諸如當(dāng)一個(gè)服務(wù)請(qǐng)求被申請(qǐng)控制否決時(shí)網(wǎng)絡(luò)應(yīng)該怎樣通知用戶以及用戶怎樣應(yīng)答這樣的通知等問題。