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