實時傳輸協(xié)議RTP與RTCP

1、-作者：vcfans-發(fā)布時間：2007-3-2 15:52:59-流媒體專題傳輸協(xié)議實時傳輸協(xié)議RTP與RTCP RTP（Real-timeTransportProtocol）是用于Internet上針對多媒體數(shù)據(jù)流的一種傳輸協(xié)議。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現(xiàn)流同步。RTP通常使用UDP來傳送數(shù)據(jù)，但RTP也可以在TCP或ATM等其他協(xié)議之上工作。當應用程序開始一個RTP會話時將使用兩個端口：一個給RTP，一個給RTCP。RTP本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。通常RTP算法并

2、不作為一個獨立的網(wǎng)絡層來實現(xiàn)，而是作為應用程序代碼的一部分。實時傳輸控制協(xié)議RTCP。RTCP(Real-timeTransportControlProtocol)和RTP一起提供流量控制和擁塞控制服務。在RTP會話期間，各參與者周期性地傳送RTCP包。RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料，因此，服務器可以利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實時數(shù)據(jù)。6.2.1 RTP數(shù)據(jù)傳輸協(xié)議 RTP提供端對端網(wǎng)絡傳輸功能，適合通過組播和點播傳送實時數(shù)據(jù)，如視頻、

3、音頻和仿真數(shù)據(jù)。RTP沒有涉及資源預訂和質(zhì)量保證等實時服務，RTCP擴充數(shù)據(jù)傳輸以允許監(jiān)控數(shù)據(jù)傳送，提供最小的控制和識別功能。RTP與RTCP設計成獨立傳輸和網(wǎng)絡層。 2.1.1 RTP固定頭 RTP 頭格式如下： - |V=2|P|X| CC |M| PT | 系列號 | - | 時標 | - | 同步源標識(SSRC) | - | 作用標識 (CSRC) | | . | - 開始12個八進制出現(xiàn)在每個RTP包中，而CSRC標識列表僅出現(xiàn)在混合器插入時。 2.1.2 復用 RTP 連接 為使協(xié)議有效運行，復用點數(shù)目應減至最小。RTP中，復用由定義RTP連接的目的傳輸?shù)刂罚ňW(wǎng)絡地址與端口號）提

4、供。例如，對音頻和視頻單獨編碼的遠程會議，每個媒介被攜帶在單獨RTP連接中，具有各自的目的傳輸?shù)刂?。目標不在將音頻和視頻放在單一RTP連接中，而根據(jù)SSRC段載荷類型進行多路分解。使用同一SSRC ，而具有不同載荷類型的交叉包將帶來幾個問題： 如一種載荷類型在連接期間切換，沒有辦法識別新值將替換那一個舊值。 SSRC定義成用于標識單個計時和系列號空間。如媒體時鐘速率不同，而要求不同系列號空間以說明那種載荷類型有丟包，交叉復用載荷類型將需要不同計時空間。 RTCP發(fā)送和接收報告可能僅描述每個SSRC的計時和系列號空間，而不攜帶載荷類型段。 RTP混合器不能將不兼容媒體流合并成一個流。 在一個RT

5、P連接中攜帶多個媒介阻止幾件事：使用不同網(wǎng)絡路徑或網(wǎng)絡資源分配；接受媒介子集。 對每種媒介使用不同SSRC，但以相同RTP連接發(fā)送可避免前三個問題，但不能避免后兩個問題。 2.1.3 對RTP頭特定設置的修改 可以認為，現(xiàn)用RTP數(shù)據(jù)包頭對RTP支持的所有應用類共同需要的功能集是完整的。然而，為維持ALF設計原則，頭可通過改變或增加設置來裁剪，并仍允許設置無關監(jiān)控和記錄工具起作用。標記位與載荷類型段攜帶特定設置信息，但由于很多應用需要它們，否則要容納它們，就要增加另外32位字，故允許分配在固定頭中。包含這些段的八進制可通過設置重新定義以適應不同要求，如采用更多或更少標記位。如有標記位，既然設置

6、無關監(jiān)控器能觀察包丟失模式和標記位間關系，我們就可以定位八進制中最重要的位。 其它特殊載荷格式（視頻編碼）所要求的信息應該攜帶在包的載荷部分。可出現(xiàn)在頭，總是在載荷部分開始處，或在數(shù)據(jù)模式的保留值中指出。如特殊應用類需要獨立載荷格式的附加功能，應用運行的設置應該定義附加固定段跟隨在現(xiàn)存固定頭SSRC之后。這些應用將能迅速而直接訪問附加段，同時，與監(jiān)控器和記錄器無關設置仍能通過僅解釋開始12個八進制處理RTP包。如證實附加功能是所有設置共同需要的，新版本RTP應該對固定頭作出明確改變。RTP控制協(xié)議- RTCP RTCP協(xié)議將控制包周期發(fā)送給所有連接者，應用與數(shù)據(jù)包相同的分布機制。低層協(xié)議提供數(shù)

7、據(jù)與控制包的復用，如使用單獨的UDP端口號。RTCP執(zhí)行下列四大功能： 主要是提供數(shù)據(jù)發(fā)布的質(zhì)量反饋。是作為RTP傳輸協(xié)議的一部分，與其他傳輸協(xié)議的流和阻塞控制有關。反饋對自適應編碼控制直接起作用，但IP組播經(jīng)驗表明，從發(fā)送者收到反饋對診斷發(fā)送錯誤是致關重要的。給所有參加者發(fā)送接收反饋報告允許問題觀察者估計那些問題是局部的，還是全局的。諸如IP組播等發(fā)布機制使網(wǎng)絡服務提供商類團體可能接收反饋信息，充當?shù)谌奖O(jiān)控者來診斷網(wǎng)絡問題。反饋功能由RTCP發(fā)送者和接收者報告執(zhí)行。 RTCP帶有稱作規(guī)范名字（CNAME）的RTP源持久傳輸層標識。如發(fā)現(xiàn)沖突，或程序重新啟動，既然SSRC標識可改變，接收者需

8、要CNAME跟蹤參加者。接收者也需要CNAME 與相關RTP連接中給定的幾個數(shù)據(jù)流聯(lián)系 前兩種功能要求所有參加者發(fā)送RTCP包，因此，為了RTP擴展到大規(guī)模數(shù)量，速率必須受到控制。讓每個參加者給其它參加者發(fā)送控制包，就大獨立觀察參加者數(shù)量。該數(shù)量用語計算包發(fā)送的速率。 第四個可選功能是傳送最小連接控制信息，如參加者辨識。最可能用在松散控制連接，那里參加者自由進入或離開，沒有成員控制或參數(shù)協(xié)調(diào)，RTCP充當通往所有參加者的方便通道，但不必支持應用的所有控制通訊要求。高級連接控制協(xié)議超出本書范圍。 在IP組播場合應用RTP時，前3個功能是必須的，推薦用于所有情形。RTP應用設計人員必須避免使用僅在

9、單播模式下工作的機制，那將導致無法擴展規(guī)模。 RTCP 包格式 下面定義幾個攜帶不同控制信息的RTCP包類型： SR： 發(fā)送報告，當前活動發(fā)送者發(fā)送、接收統(tǒng)計。 RR： 接收報告，非活動發(fā)送者接收統(tǒng)計。 SDES： 源描述項，包括CNAME。 BYE： 表示結(jié)束。 APP： 應用特定函數(shù)。 類似于RTP數(shù)據(jù)包，每個RTCP包以固定部分開始，緊接著的是可變長結(jié)構(gòu)元素，但以一個32位邊界結(jié)束。包含安排要求和固定部分中長度段，使RTCP包可堆疊。不需要插入任何分隔符將多哥RTCP包連接起來形成一個RTCP組合包，以低層協(xié)議用單一包發(fā)送出去。由于需要低層協(xié)議提供提供整體長度來決定組合包

10、的結(jié)尾，在組合包中沒有單個RTCP包顯式計數(shù)。 組合包中每個RTCP包可獨立處理，不需要根據(jù)包組合順序。但未了執(zhí)行協(xié)議功能，強加如下約束： 接收統(tǒng)計（在SR或RR中）應該經(jīng)常發(fā)送，只要帶寬允許，因此每個周期發(fā)送的組合RTCP 包應包含報告包。 新接收者需要接收CNAME，并盡快識別源，開始聯(lián)系媒介進行同步，因此每個包應該包含SDES CNAME。 出現(xiàn)在組合包前面的是包類型數(shù)量，其增長應該受到限制，以提高常數(shù)位數(shù)量，提高成功確認RTCP包對錯誤地址RTP數(shù)據(jù)包或其他無關包的概率。 因此，所有RTCP包至少必須以兩個包組合形式發(fā)送，推薦格式如下： 加密前綴（Encryption prefix）：

11、 僅當組合包被加密，才加上一個32位隨機數(shù)用于每個組合包發(fā)送。 SR或RR： 組合包中第一個RTCP包必須總為一個報告包，方便頭的確認。即使沒有數(shù)據(jù)發(fā)送，也沒有接收到數(shù)據(jù)，也要發(fā)送一個空RR，那怕組合包中RTCP包為BYE。 附加RR： 如報告統(tǒng)計源數(shù)目超過31，在初始報告包后應該有附加RR 包。 SDES： 包含CNAME 項的SDES包必須包含在每個組合RTCP包中。如應用要求，其他源描述項可選，但受到帶寬限制。 BYE或APP： 其它RTCP包類型可以任意順序排列，除了BYE應作為最后一個包發(fā)送，包類型出現(xiàn)可不止一次。 建議轉(zhuǎn)換器或混合器從多個源組合單個RTCP包。如組合包整體長度超過網(wǎng)

12、絡路徑最大傳輸單元，可分成多個較短組合包用低層協(xié)議以單個包形式發(fā)送。注意，每個組合包必須以SR或RR包開始。附加RTCP包類型可在Internet Assigned Numbers Authority (IANA)處注冊。 RTCP傳輸間隔 RTP設計成允許應用自動擴展，連接數(shù)可從幾個到上千個。例如，音頻會議中，數(shù)據(jù)流量是內(nèi)在限制的，因為同一時刻只有一兩個人說話；對組播，給定連接數(shù)據(jù)率仍是常數(shù)，獨立于連接數(shù)，但控制流量不是內(nèi)在限制的。如每個參加者以固定速率發(fā)送接收報告，控制流量將隨參加者數(shù)量線性增長，因此，速率必須按比例下降。 一旦確認地址有效，如后來標記成未活動，地址的狀態(tài)應

13、仍保留，地址應繼續(xù)計入共享RTCP帶寬地址的總數(shù)中，時間要保證能掃描典型網(wǎng)絡分區(qū)，建議為30分鐘。注意，這仍大于RTCP報告間隔最大值的五倍。 這個規(guī)范定義了除必需的CNAME外的幾個源描述項，如NAME（人名）和EMAIL（電子郵件地址）。它也為定義新特定應用RTCP包類型的途徑。給附加信息分配控制帶寬應引起注意，因為它將降低接收報告和CNAME發(fā)送的速率而損害協(xié)議的性能。建議分配給單個參加者用于攜帶附加信息的RTCP帶寬不要超過20%。而且并沒有有意讓所有SDES項包含在每個應用中。 發(fā)送者與接收者報告 RTP接收者使用RTCP報告包提供接收質(zhì)量反饋，報告包根據(jù)接收者是否是

14、發(fā)送者而采用兩種格式中的一種。除包類型代碼外，發(fā)送者報告與接收者報告間唯一的差別是發(fā)送者報告包含一個20個字節(jié)發(fā)送者信息段。如某地址在發(fā)出最后或前一個報告間隔期間發(fā)送數(shù)據(jù)包，就發(fā)布SR；否則，就發(fā)出RR；SR和RR都可沒有或包括多個接收報告塊。發(fā)布報告不是為列在CSRC列表上的起作用的源，每個接收報告塊提供從特殊源接收數(shù)據(jù)的統(tǒng)計。既然最大可有31個接收報告塊嵌入在SR 或 RR包中， 丟失包累計數(shù)差別給出間隔期間丟掉的數(shù)量，而所收到擴展的最后一個系列號的差別給出間隔期間希望發(fā)送的包數(shù)量，兩者之比等于經(jīng)過間隔期間包丟失百分比。如兩報告連續(xù)，比值應該等于丟失段部分；否則，就不等。每秒包丟失綠可通過

15、NTP時標差除以丟失部分得到。 從發(fā)送者信息，第三方監(jiān)控器可計算載荷平均數(shù)據(jù)速率與沒收到數(shù)據(jù)間隔的平均包速率，兩者比值給出平均載荷大小。如假設包丟失與包大小無關，那么特殊接收者收到的包數(shù)量給出此接收者收到的表觀流量。 SDES: 源描述RTCP包 SDES 包為三層結(jié)構(gòu)，由頭與數(shù)據(jù)塊組成，數(shù)據(jù)塊可以沒有，也可有多個，組成項描述塊所表明的源。項描述如下： 版本（V）、填充（P）、長度： 如SR包中所描述。 包類型（PT）： 8位，包含常數(shù)202，識別RTCP SDES包。 源計數(shù)（SC）： 5位，包含在SDES包中的SSRC/CSRC塊數(shù)量，零值有效，但沒有意義。 源描魷钅諶萑縵

16、攏? CNAME: 規(guī)范終端標識SDES項 CNAME標識屬性如下： 如發(fā)生沖突或重啟程序，由于隨機分配的SSRC標識可能發(fā)生變化，需要CNAME項提供從SSRC標識到仍為常量的源標識的綁定。 象SSRC標識，CNAME標識在RTP連接的所有參加者中應是唯一的。 為了提供一套相關RTP連接中某個參加者所采用的跨多媒體工具間的綁定，CNAME應固定為那個參加者。 為方便第三方監(jiān)控，CNAME應適合程序或人員定位源。 NAME：用戶名稱SDES項 這是用于描述源的真正的名稱，如John Doe, Bit Recycler, Megacorp，可是用戶想要的任意形式。對諸如會議應用，這種名稱也許是參

17、加者列表顯示最適宜的形式，它將是除CNAME外發(fā)送最頻繁的項目。設置可建立這樣的優(yōu)先級別。NAME值至少在連接期間仍希望保持為常數(shù)。它不該成為連接的所有參加者中唯一依賴。 EMAIL：電子郵件地址SDES項 郵件地址格式由RFC822規(guī)定，如 。連接期間，電子郵件仍希望保持為常數(shù)。 PHONE：電話號碼SDES項 電話號碼應帶有加號，代替國際接入代碼，如+1 908 555 1212即為美國電話號碼。 LOC：用戶地理位置SDES項 根據(jù)應用，此項具有不同程度的細節(jié)。對會議應用，字符串如Murray Hill, New Jersey就足夠了。然而，對活動標記系統(tǒng)，字符串如Room 2A244,

18、 AT&T BL MH也許就適用。細節(jié)留給實施或用戶，但格式和內(nèi)容可用設置指示。在連接期間，除移動主機外，LOC值期望仍保留為常數(shù)。 TOOL：應用或工具名稱SDES項 是一個字符串，表示產(chǎn)生流的應用的名稱與版本，如videotool 1.2。這部分信息對調(diào)試很有用，類似于郵件或郵件系統(tǒng)版本SMTP頭。TOOL值在連接期間仍保持常數(shù)。 NOTE: 通知/狀態(tài)SDES項 該項的推薦語法如下所述，但這些或其它語法可在設置中顯式定義。NOTE 項旨在描述源當前狀態(tài)的過渡信息，如on the phone, cant talk，或在講座期間用于傳送談話的題目。它應該只用于攜帶例外信息，而不應包含在全部參

19、加者中，因為這將降低接收報告和CNAME發(fā)送的速度，因此損害協(xié)議的性能。特殊情況下，它不應作為用戶設置文件的項目，也不是自動產(chǎn)生。 當其為活動時，由于NOTE項對顯示很重要，其它非CNAME項（如NAME）傳輸速率將會降低，結(jié)果使NOTE項占用RTCP部分帶寬。若過渡信息不活躍，NOTE項繼續(xù)以同樣的速度重復發(fā)送幾次，但以一個串長為零的字符串通知接收者。然而，如對小倍數(shù)的重復或約20-30 RTCP間隔也沒有接收到，接收者也應該考慮NOTE項是不活躍的。 PRIV: 專用擴展SDES項 該項用于定義實驗或應用特定的SDES擴展，它包括由長字符串對組成的前綴，后跟填充該項其他部分和攜帶所需信息的

20、字符串值。前綴長度段為8位。前綴字符串是定義PRIV項人員選擇的名稱，唯一對應應用接收到的其它PRIV項。應用實現(xiàn)者可選擇使用應用名稱，如有必要，外加附加子類型標識。另外，推薦其它人根據(jù)其代表的實體選擇名稱，然后，在實體內(nèi)部協(xié)調(diào)名稱的使用。 注意，前綴消耗了總長為255個八進制項的一些空間，因此，前綴應盡可能的短。這個設備和受到約束的RTCP帶寬不應過載，其目的不在于滿足所有應用的全部控制通訊要求。SDES PRIV前綴沒在IANA處注冊。如證實某些形式的PRIV項具有通用性， IANA應給它分配一個正式的SDES項類型，這樣就不再需要前綴。這簡化了應用，并提高了傳輸?shù)男省?

21、BYE：斷開RTCP包 如混合器接收到一個BYE包，混合器轉(zhuǎn)發(fā)BYE包，而不改變SSRC/CSRC 標識。如混合器關閉，它也應該發(fā)出一個BYE包，列出它所處理的所有源，而不只是自己的SSRC標識。作為可選項，BYE包可包括一個8位八進制計數(shù)，后跟很多八進制文本，表示離開原因，如：camera malfunction或RTP loop detected。字符串具有同樣的編碼，如在SDES 中所描述的。如字符串填充包至下32位邊界，字符串就不以空結(jié)尾；否則，BYE包以空八進制填充。 APP：定義應用的RTCP包 APP包用于開發(fā)新應用和新特征的實驗，不要求注冊包類型值。帶有不可識別

22、名稱的APP包應被忽略掉。測試后，如確定應用廣泛，推薦重新定義每個APP包，而不用向IANA注冊子類型和名稱段。實時流協(xié)議RTSP 實時流協(xié)議RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，該協(xié)議定義了一對多應用程序如何有效地通過IP網(wǎng)絡傳送多媒體數(shù)據(jù)。RTSP在體系結(jié)構(gòu)上位于RTP和RTCP之上，它使用TCP或RTP完成數(shù)據(jù)傳輸。HTTP與RTSP相比，HTTP傳送HTML，而RTP傳送的是多媒體數(shù)據(jù)。HTTP請求由客戶機發(fā)出，服務器作出響應；使用RTSP時，客戶機和服務器都可以發(fā)出請求，即RTSP可以是雙向的。6.3

23、RTSP協(xié)議 實時流協(xié)議（RTSP）是應用級協(xié)議，控制實時數(shù)據(jù)的發(fā)送。RTSP提供了一個可擴展框架，使實時數(shù)據(jù)，如音頻與視頻，的受控、點播成為可能。數(shù)據(jù)源包括現(xiàn)場數(shù)據(jù)與存儲在剪輯中數(shù)據(jù)。該協(xié)議目的在于控制多個數(shù)據(jù)發(fā)送連接，為選擇發(fā)送通道，如UDP、組播UDP與TCP，提供途徑，并為選擇基于RTP上發(fā)送機制提供方法。 6.3.1 簡介 目的 實時流協(xié)議（RTSP）建立并控制一個或幾個時間同步的連續(xù)流媒體。盡管連續(xù)媒體流與控制流交叉是可能的，通常它本身并不發(fā)送連續(xù)流。換言之，RTSP充當多媒體服務器的網(wǎng)絡遠程控制。RTSP連接沒有綁定到傳輸層連接，如TCP。在RTSP連接期間，RT

24、SP用戶可打開或關閉多個對服務器的可靠傳輸連接以發(fā)出RTSP 請求。此外，可使用無連接傳輸協(xié)議，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依賴用于攜帶連續(xù)媒體的傳輸機制。實時流協(xié)議在語法和操作上與HTTP/1.1類似，因此HTTP的擴展機制大都可加入RTSP。協(xié)議支持的操作如下： 從媒體服務器上檢索媒體： 用戶可通過HTTP或其它方法提交一個演示描述。如演示是組播，演示式就包含用于連續(xù)媒體的的組播地址和端口。如演示僅通過單播發(fā)送給用戶，用戶為了安全應提供目的地址。 媒體服務器邀請進入會議： 媒體服務器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在

25、分布式教育應用上很有用，會議中幾方可輪流按遠程控制按鈕。 將媒體加到現(xiàn)成講座中： 如服務器告訴用戶可獲得附加媒體內(nèi)容，對現(xiàn)場講座顯得尤其有用。如HTTP/1.1中類似，RTSP請求可由代理、通道與緩存處理。 協(xié)議特點 RTSP 特性如下： 可擴展性： 新方法和參數(shù)很容易加入RTSP。 易解析： RTSP可由標準 HTTP或MIME解吸器解析。 安全： RTSP使用網(wǎng)頁安全機制。 獨立于傳輸： RTSP可使用不可靠數(shù)據(jù)報協(xié)議（UDP）、可靠數(shù)據(jù)報協(xié)議（RDP），如要實現(xiàn)應用級可靠，可使用可靠流協(xié)議。 多服務器支持： 每個流可放在不同服務器上，用戶端自動同不同服務器建立幾個并發(fā)控制

26、連接，媒體同步在傳輸層執(zhí)行。 記錄設備控制： 協(xié)議可控制記錄和回放設備。 流控與會議開始分離： 僅要求會議初始化協(xié)議提供，或可用來創(chuàng)建唯一會議標識號。特殊情況下， SIP或H.323 可用來邀請服務器入會。 適合專業(yè)應用： 通過SMPTE 時標，RTSP支持幀級精度，允許遠程數(shù)字編輯 演示描述中立： 協(xié)議沒強加特殊演示或元文件，可傳送所用格式類型；然而，演示描述至少必須包含一個RTSP URI。 代理與防火墻友好： 協(xié)議可由應用和傳輸層防火墻處理。防火墻需要理解SETUP方法，為UDP媒體流打開一個缺口。 HTTP友好： 此處，RTSP明智的采用HTTP觀念，使現(xiàn)在結(jié)構(gòu)都可重用。結(jié)構(gòu)包括Int

27、ernet 內(nèi)容選擇平臺（PICS）。由于在大多數(shù)情況下控制連續(xù)媒體需要服務器狀態(tài)， RTSP不僅僅向HTTP 添加方法。 適當?shù)姆掌骺刂疲?如用戶啟動一個流，他必須也可以停止一個流。 傳輸協(xié)調(diào)； 實際處理連續(xù)媒體流前，用戶 可協(xié)調(diào)傳輸方法。 性能協(xié)調(diào)： 如基本特征無效，必須有一些清理機制讓用戶決定那種方法沒生效。這允許用戶提出適合的用戶界面。 擴展RTSP 由于不是所有媒體服務器有著相同的功能，媒體服務器有必要支持不同請求集。RTSP 可以如下三種方式擴展，這里以改變大小排序： 以新參數(shù)擴展。如用戶需要拒絕通知，而方法擴展不支持，相應標記就加入要求的段中。 加入新方法。如信息

28、接收者不理解請求，返回501錯誤代碼（還未實現(xiàn)），發(fā)送者不應再次嘗試這種方法。用戶可使用OPTIONS方法查詢服務器支持的方法。服務器使用公共響應頭列出支持的方法。 定義新版本協(xié)議，允許改變所有部分。（除了協(xié)議版本號位置） 操作模式 每個演示和媒體流可用RTSP URL識別。演示組成的整個演示與媒體屬性由演示描述文件定義。使用HTTP或其它途徑用戶可獲得這個文件，它沒有必要保存在媒體服務器上。 為了說明，假設演示描述描述了多個演示，其中每個演示維持了一個公共時間軸。為簡化說明，且不失一般性，假定演示描述的確包含這樣一個演示。演示可包含多個媒體流。除媒體參數(shù)外，網(wǎng)絡目標地址和端口也

29、需要決定。下面區(qū)分幾種操作模式： 單播： 以用戶選擇的端口號將媒體發(fā)送到RTSP請求源。 組播，服務器選擇地址： 媒體服務器選擇組播地址和端口，這是現(xiàn)場直播或準點播常用的方式。 組播，用戶選擇地址： 如服務器加入正在進行的組播會議，組播地址、端口和密匙由會議描述給出。 RTSP狀態(tài) RTSP控制通過單獨協(xié)議發(fā)送的流，與控制通道無關。例如，RTSP控制可通過TCP連接，而數(shù)據(jù)流通過UDP。因此，即使媒體服務器沒有收到請求，數(shù)據(jù)也會繼續(xù)發(fā)送。在連接生命期，單個媒體流可通過不同TCP連接順序發(fā)出請求來控制。所以，服務器需要維持能聯(lián)系流與RTSP請求的連接狀態(tài)。RTSP中很多方法與狀態(tài)

30、無關，但下列方法在定義服務器流資源的分配與應用上起著重要的作用： SETUP： 讓服務器給流分配資源，啟動RTSP連接。 PLAY與RECORD： 啟動SETUP 分配流的數(shù)據(jù)傳輸。 PAUSE： 臨時停止流，而不釋放服務器資源。 TEARDOWN： 釋放流的資源，RTSP連接停止。 標識狀態(tài)的RTSP方法使用連接頭段識別RTSP連接，為響應SETUP請求，服務器連 接產(chǎn)生連接標識。 與其他協(xié)議關系 RTSP在功能上與HTTP有重疊，與HTTP相互作用體現(xiàn)在與流內(nèi)容的初始接觸是通過網(wǎng)頁的。目前的協(xié)議規(guī)范目的在于允許在網(wǎng)頁服務器與實現(xiàn)RTSP媒體服務器之間存在不同傳遞點。例如，演

31、示描述可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨立RTSP 服務器與用戶不全依靠HTTP。 但是，RTSP與HTTP 的本質(zhì)差別在于數(shù)據(jù)發(fā)送以不同協(xié)議進行。HTTP是不對稱協(xié)議，用戶發(fā)出請求，服務器作出響應。RTSP中，媒體用戶和服務器都可發(fā)出請求，且其請求都是無狀態(tài)的；在請求確認后很長時間內(nèi)，仍可設置參數(shù)，控制媒體流。重用HTTP功能至少在兩個方面有好處，即安全和代理。要求非常接近，在緩存、代理和授權上采用HTTP功能是有價值的。 當大多數(shù)實時媒體使用RTP作為傳輸協(xié)議時，RTSP沒有綁定到RTP。RTSP假設存在演示描述格式可表示包含幾個媒體流的演示的靜態(tài)與臨時屬性。

32、 6.3.2 協(xié)議參數(shù) 6.3.3 RTSP 信息 RTSP是基于文本的協(xié)議，采用ISO 10646 字符集，使用UTF-8編碼方案。行以CRLF中斷，但接收者本身可將CR和LF解釋成行終止符。基于文本的協(xié)議使以自描述方式增加可選參數(shù)更容易。由于參數(shù)的數(shù)量和命令的頻率出現(xiàn)較低，處理效率沒引起注意。如仔細研究，文本協(xié)議很容易以腳本語言（如：Tcl、Visual Basic與Perl）實現(xiàn)研究原型。 10646字符集避免敏感字符集切換，但對應用來說不可見。RTCP也采用這種編碼方案。帶有重要意義位的ISO 8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通過任何低層傳輸協(xié)議

33、攜帶。 請求包括方法、方法作用于其上的對象和進一步描述方法的參數(shù)。方法也可設計為在服務器端只需要少量或不需要狀態(tài)維護。當信息體包含在信息中，信息體長度有如下因素決定： 不管實體頭段是否出現(xiàn)在信息中，不包括信息體的的響應信息總以頭段后第一和空行結(jié)束。 如出現(xiàn)內(nèi)容長度頭段，其值以字節(jié)計，表示信息體長度。如未出現(xiàn)頭段，其值為零。 服務器關閉連接。 注意：RTSP目前并不支持HTTP/1.1塊傳輸編碼，需要有內(nèi)容長度頭。假如返回適度演示描述長度，即使動態(tài)產(chǎn)生，使塊傳輸編碼沒有必要，服務器也應該能決定其長度。如有實體，即使必須有內(nèi)容長度，且長度沒顯式給出，規(guī)則可確保行為合理。 從用戶到服務器端的請求信息

34、在第一行內(nèi)包括源采用的方法、源標識和所用協(xié)議版本。RTSP定義了附加狀態(tài)代碼，而沒有定義任何HTTP代碼。 6.3.4 實體 如不受請求方法或響應狀態(tài)編碼限制，請求和響應信息可傳輸實體，實體由實體頭文件和試題體組成，有些響應僅包括實體頭。在此，根據(jù)誰發(fā)送實體、誰接收實體，發(fā)送者和接收者可分別指用戶和服務器。 實體頭定義實體體可選元信息，如沒有實體體，指請求標識的資源。擴展頭機制允許定義附加實體頭段，而不用改變協(xié)議，但這些段不能假定接收者能識別。不可識別頭段應被接收者忽略，而讓代理轉(zhuǎn)發(fā)。 6.3.5 連接 RTSP請求可以幾種不同方式傳送： 1、持久傳輸連接，用于多個請求/響應傳輸。 2、每個請求/響應傳輸一個連接。 3、無連接模式。 傳輸連接類型由RTSP URI來定義。對 rtsp