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

1、-作者：vcfans-發(fā)布時(shí)間：2007-3-2 15:52:59-流媒體專題傳輸協(xié)議實(shí)時(shí)傳輸協(xié)議RTP與RTCP RTP（Real-timeTransportProtocol）是用于Internet上針對多媒體數(shù)據(jù)流的一種傳輸協(xié)議。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時(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算法并

2、不作為一個(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提供端對端網(wǎng)絡(luò)傳輸功能，適合通過組播和點(diǎn)播傳送實(shí)時(shí)數(shù)據(jù)，如視頻、

3、音頻和仿真數(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 | 系列號 | - | 時(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ò)地址與端口號）提

4、供。例如，對音頻和視頻單獨(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í)和系列號空間。如媒體時(shí)鐘速率不同，而要求不同系列號空間以說明那種載荷類型有丟包，交叉復(fù)用載荷類型將需要不同計(jì)時(shí)空間。 RTCP發(fā)送和接收報(bào)告可能僅描述每個(gè)SSRC的計(jì)時(shí)和系列號空間，而不攜帶載荷類型段。 RTP混合器不能將不兼容媒體流合并成一個(gè)流。 在一個(gè)RT

5、P連接中攜帶多個(gè)媒介阻止幾件事：使用不同網(wǎng)絡(luò)路徑或網(wǎng)絡(luò)資源分配；接受媒介子集。 對每種媒介使用不同SSRC，但以相同RTP連接發(fā)送可避免前三個(gè)問題，但不能避免后兩個(gè)問題。 2.1.3 對RTP頭特定設(shè)置的修改 可以認(rèn)為，現(xiàn)用RTP數(shù)據(jù)包頭對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è)置

6、無關(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)該對固定頭作出明確改變。RTP控制協(xié)議- RTCP RTCP協(xié)議將控制包周期發(fā)送給所有連接者，應(yīng)用與數(shù)據(jù)包相同的分布機(jī)制。低層協(xié)議提供數(shù)

7、據(jù)與控制包的復(fù)用，如使用單獨(dú)的UDP端口號。RTCP執(zhí)行下列四大功能： 主要是提供數(shù)據(jù)發(fā)布的質(zhì)量反饋。是作為RTP傳輸協(xié)議的一部分，與其他傳輸協(xié)議的流和阻塞控制有關(guān)。反饋對自適應(yīng)編碼控制直接起作用，但I(xiàn)P組播經(jīng)驗(yàn)表明，從發(fā)送者收到反饋對診斷發(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í)可改變，接收者需

8、要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)用的所有控制通訊要求。高級連接控制協(xié)議超出本書范圍。 在IP組播場合應(yīng)用RTP時(shí)，前3個(gè)功能是必須的，推薦用于所有情形。RTP應(yīng)用設(shè)計(jì)人員必須避免使用僅在

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

10、的結(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ù)量，其增長應(yīng)該受到限制，以提高常數(shù)位數(shù)量，提高成功確認(rèn)RTCP包對錯(cuò)誤地址RTP數(shù)據(jù)包或其他無關(guān)包的概率。 因此，所有RTCP包至少必須以兩個(gè)包組合形式發(fā)送，推薦格式如下： 加密前綴（Encryption prefix）：

11、 僅當(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包。如組合包整體長度超過網(wǎng)

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

13、仍保留，地址應(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)樗鼘⒔档徒邮請?bào)告和CNAME發(fā)送的速率而損害協(xié)議的性能。建議分配給單個(gè)參加者用于攜帶附加信息的RTCP帶寬不要超過20%。而且并沒有有意讓所有SDES項(xiàng)包含在每個(gè)應(yīng)用中。 發(fā)送者與接收者報(bào)告 RTP接收者使用RTCP報(bào)告包提供接收質(zhì)量反饋，報(bào)告包根據(jù)接收者是否是

14、發(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è)接收報(bào)告塊。發(fā)布報(bào)告不是為列在CSRC列表上的起作用的源，每個(gè)接收報(bào)告塊提供從特殊源接收數(shù)據(jù)的統(tǒng)計(jì)。既然最大可有31個(gè)接收報(bào)告塊嵌入在SR 或 RR包中， 丟失包累計(jì)數(shù)差別給出間隔期間丟掉的數(shù)量，而所收到擴(kuò)展的最后一個(gè)系列號的差別給出間隔期間希望發(fā)送的包數(shù)量，兩者之比等于經(jīng)過間隔期間包丟失百分比。如兩報(bào)告連續(xù)，比值應(yīng)該等于丟失段部分；否則，就不等。每秒包丟失綠可通過

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

16、攏? 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，可是用戶想要的任意形式。對諸如會(huì)議應(yīng)用，這種名稱也許是參

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

18、 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。這部分信息對調(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, cant talk，或在講座期間用于傳送談話的題目。它應(yīng)該只用于攜帶例外信息，而不應(yīng)包含在全部參

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

20、字符串值。前綴長度段為8位。前綴字符串是定義PRIV項(xiàng)人員選擇的名稱，唯一對應(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)名稱的使用。 注意，前綴消耗了總長為255個(gè)八進(jìn)制項(xiàng)的一些空間，因此，前綴應(yīng)盡可能的短。這個(gè)設(shè)備和受到約束的RTCP帶寬不應(yīng)過載，其目的不在于滿足所有應(yīng)用的全部控制通訊要求。SDES PRIV前綴沒在IANA處注冊。如證實(shí)某些形式的PRIV項(xiàng)具有通用性， IANA應(yīng)給它分配一個(gè)正式的SDES項(xiàng)類型，這樣就不再需要前綴。這簡化了應(yīng)用，并提高了傳輸?shù)男省?

21、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)制填充。 APP：定義應(yīng)用的RTCP包 APP包用于開發(fā)新應(yīng)用和新特征的實(shí)驗(yàn)，不要求注冊包類型值。帶有不可識(shí)別

22、名稱的APP包應(yīng)被忽略掉。測試后，如確定應(yīng)用廣泛，推薦重新定義每個(gè)APP包，而不用向IANA注冊子類型和名稱段。實(shí)時(shí)流協(xié)議RTSP 實(shí)時(shí)流協(xié)議RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，該協(xié)議定義了一對多應(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請求由客戶機(jī)發(fā)出，服務(wù)器作出響應(yīng)；使用RTSP時(shí)，客戶機(jī)和服務(wù)器都可以發(fā)出請求，即RTSP可以是雙向的。6.3

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

24、SP用戶可打開或關(guān)閉多個(gè)對服務(wù)器的可靠傳輸連接以發(fā)出RTSP 請求。此外，可使用無連接傳輸協(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ù)器邀請進(jìn)入會(huì)議： 媒體服務(wù)器可被邀請參加正進(jìn)行的會(huì)議，或回放媒體，或記錄其中一部分，或全部。這種模式在

25、分布式教育應(yīng)用上很有用，會(huì)議中幾方可輪流按遠(yuǎn)程控制按鈕。 將媒體加到現(xiàn)成講座中： 如服務(wù)器告訴用戶可獲得附加媒體內(nèi)容，對現(xiàn)場講座顯得尤其有用。如HTTP/1.1中類似，RTSP請求可由代理、通道與緩存處理。 協(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)用級可靠，可使用可靠流協(xié)議。 多服務(wù)器支持： 每個(gè)流可放在不同服務(wù)器上，用戶端自動(dòng)同不同服務(wù)器建立幾個(gè)并發(fā)控制

26、連接，媒體同步在傳輸層執(zhí)行。 記錄設(shè)備控制： 協(xié)議可控制記錄和回放設(shè)備。 流控與會(huì)議開始分離： 僅要求會(huì)議初始化協(xié)議提供，或可用來創(chuàng)建唯一會(huì)議標(biāo)識(shí)號。特殊情況下， SIP或H.323 可用來邀請服務(wù)器入會(huì)。 適合專業(yè)應(yīng)用： 通過SMPTE 時(shí)標(biāo)，RTSP支持幀級精度，允許遠(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)包括Int

27、ernet 內(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ī)制讓用戶決定那種方法沒生效。這允許用戶提出適合的用戶界面。 擴(kuò)展RTSP 由于不是所有媒體服務(wù)器有著相同的功能，媒體服務(wù)器有必要支持不同請求集。RTSP 可以如下三種方式擴(kuò)展，這里以改變大小排序： 以新參數(shù)擴(kuò)展。如用戶需要拒絕通知，而方法擴(kuò)展不支持，相應(yīng)標(biāo)記就加入要求的段中。 加入新方法。如信息

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

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

30、無關(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請求，服務(wù)器連 接產(chǎn)生連接標(biāo)識(shí)。 與其他協(xié)議關(guān)系 RTSP在功能上與HTTP有重疊，與HTTP相互作用體現(xiàn)在與流內(nèi)容的初始接觸是通過網(wǎng)頁的。目前的協(xié)議規(guī)范目的在于允許在網(wǎng)頁服務(wù)器與實(shí)現(xiàn)RTSP媒體服務(wù)器之間存在不同傳遞點(diǎn)。例如，演

31、示描述可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨(dú)立RTSP 服務(wù)器與用戶不全依靠HTTP。 但是，RTSP與HTTP 的本質(zhì)差別在于數(shù)據(jù)發(fā)送以不同協(xié)議進(jìn)行。HTTP是不對稱協(xié)議，用戶發(fā)出請求，服務(wù)器作出響應(yīng)。RTSP中，媒體用戶和服務(wù)器都可發(fā)出請求，且其請求都是無狀態(tài)的；在請求確認(rèn)后很長時(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í)屬性。

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)較低，處理效率沒引起注意。如仔細(xì)研究，文本協(xié)議很容易以腳本語言（如：Tcl、Visual Basic與Perl）實(shí)現(xiàn)研究原型。 10646字符集避免敏感字符集切換，但對應(yīng)用來說不可見。RTCP也采用這種編碼方案。帶有重要意義位的ISO 8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通過任何低層傳輸協(xié)議

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

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