{
\"code\": 200,
\"title\": \"\",
\"content\": \"RTSP（RealTimeStreamingProtocol），實時流傳輸協議，是TCP\\/IP協議體係中的一個應用層協議，由哥倫比亞大學、網景和RealNetworks公司提交的IETFRFC標準。該協議定義了一對多應用程式如何有效地通過IP網路傳送多媒體資料。RTSP在體繫結構上位於RTP和RTCP之上，它使用TCP或RTP完成資料傳輸。HTTP與RTSP相比，HTTP傳送HTML，而RTSP傳送的是多媒體資料。HTTP請求由客戶機發出，伺服器作出響應；使用RTSP時，客戶機和伺服器都可以發出請求，即RTSP可以是雙向的。\\n\\nRTSP是用來控製聲音或影像的多媒體串流協議，並允許同時多個串流需求控製，傳輸時所用的網路通訊協定並不在其定義的範圍內，伺服器端可以自行選擇使用TCP或UDP來傳送串流內容，它的語法和運作跟HTTP1.1\\n\\nRTSP\\n\\n類似，但並不特彆強調時間同步，所以比較能容忍網\\n\\nRTSP絡延遲。而前麵提到的\\n\\n允許同時多個串流需求控製（Multicast），除了可以降低伺服器端的網路用量，更進而支援多方視訊會議（VideoConference）。因為與HTTP1.1的運作方式相似，所以代理伺服器〈Proxy〉的快取功能〈Cache〉也同樣適用於RTSP，並因RTSP具有重新導向功能，可視實際負載情況來轉換提供服務的伺服器，以避免過大的負載集中於同一伺服器而造成延遲。\\n\\n簡介\\n\\n該協議用於C\\/S模型，是一個基於文字的協議，用於在客戶端和伺服器端建立和協商實時流會話。\\n\\n實時流協議（RTSP）是應用級協議，控製實時資料的傳送。RTSP提供了一個可擴充套件框架，使實時資料，如音訊與視訊，的受控、點播成為可能。資料來源包括現場資料與儲存在剪輯中資料。該協議目的在於控製多個資料傳送連線，為選擇傳送通道，如UDP、組播UDP與TCP，提供途徑，併爲選擇基於RTP上傳送機製提供方法。\\n\\n實時流協議（RTSP）建立並控製一個或幾個時間同步的連續流媒體。儘管連續媒體流與控製流交換是可能的，通常它本身並不傳送連續流。換言之，RTSP充當多媒體伺服器的網路遠端控製。RTSP連線冇有繫結到傳輸層連線，如TCP。在RTSP連線期間，RTSP使用者可開啟或關閉多個對伺服器的可傳輸連線以發出RTSP請求。此外，可使用無連線傳輸協議，如UDP。RTSP流控製的流可能用到RTP，但RTSP操作並不依賴用於攜帶連續媒體的傳輸機製。\\n\\n協議支援的操作如下：\\n\\n(1)從媒體伺服器上檢索媒體：使用者可通過HTTP或其它方法提交一個演示描述。如演示是組播，演示式就包含用於連續媒體的的組播地址和。如演示僅通過單播傳送給使用者，使用者為了安全應提供目的地址。\\n\\n(2)媒體伺服器邀請進入會議：媒體伺服器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分散式教育應用上很有用，會議中幾方可輪流按遠端控製按鈕。\\n\\n(3)將媒體加到現成講座中：如伺服器告訴使用者可獲得附加媒體內容，對現場講座顯得尤其有用。如HTTP\\/1.1中類似，RTSP請求可由代理、通道與快取處理。\\n\\n協議特點\\n\\n(1)可擴充套件性：新方法和引數很容易加入RTSP。\\n\\n(2)易解析：RTSP可由標準HTTP或MIME解析器解析。\\n\\n(3)安全：RTSP使用網頁安全機製。\\n\\n(4)獨立於傳輸：RTSP可使用不可靠資料包協議(EDP)、可靠資料包協議(RDP)；如要實現應用級可靠，可使用可靠流協議。\\n\\n(5)多伺服器支援：每個流可放在不同伺服器上，使用者端自動與不同伺服器建立幾個併發控製連線，媒體同步在傳輸層執行。\\n\\n(6)記錄裝置控製：協議可控製記錄和回放裝置。\\n\\n(7)流控與會議開始分離：僅要求會議初始化協議提供，或可用來建立惟一會議標識號。特殊情況下，可用SIP或H.323來邀請伺服器入會。\\n\\n(8)適合專業應用：通過**PTE時標，RTSP支援幀級精度，允許遠端數字編輯。\\n\\n(9)演示描述中立：協議冇強加特殊演示或元檔案，可傳送所用格式型別；然而，演示描述至少必須包括一個RTSPURL。\\n\\n(10)代理與防火牆友好：協議可由應用和傳輸層防火牆處理。防火牆需要理解SETUP方法，為UDP媒體流開啟一個“缺口”。\\n\\n(11)HTTP友好：此處，RTSP明智地采用HTTP觀念，使現在結構都可重用。結構包括Internet內容選擇平台(PICS)。由於在大多數情況下控製連續媒體需要伺服器狀態，RTSP不僅僅向HTFP新增方法。\\n\\n(12)適當的伺服器控製：如使用者啟動一個流，必須也可以停止一個流。\\n\\n(13)傳輸協調：實際處理連續媒體流前，使用者可協調傳輸方法。\\n\\n(14)效能協調：如基本特征無效，必須有一些清理機製讓使用者決定哪種方法冇生效。這允許使用者提出適合的使用者介麵。\\n\\n協議結構\\n\\nRTSP是一種文字協議，采用UTF-8編碼中的ISO10646字元集。一行可通過CRLF終止，但接收端需要做好解釋CR和LF作為一行終止符的準備。關於頭欄位概述如下：\\n\\nHeaderTypeSupportMethods\\n\\nAcceptRopt.entity\\n\\nAccept-Encoding Ropt.entity\\n\\nAccept-LanguageRopt.all\\n\\nAllow Ropt.all\\n\\nAuthorizationRopt.all\\n\\nBandwidthRopt.all\\n\\nBlocksizeRopt.AllbutOPTIONS,TEARDOWN\\n\\nCache-ControlGopt.SETUP\\n\\nConferenceRopt.SETUP\\n\\nConnectionGreq.all\\n\\nContent-BaseEopt.entity\\n\\nContent-EncodingEreq.SET_PARAMETER\\n\\nContent-EncodingE req.DESCRIBE,ANNOUNCE\\n\\nContent-LanguageEreq.DESCRIBE,ANNOUNCE\\n\\nContent-LengthE req.SET_PARAMETER,ANNOUNCE\\n\\nContent-LengthEreq.entity\\n\\nContent-LocationEopt.entity\\n\\nContent-TypeEreq.SET_PARAMETER,ANNOUNCE\\n\\nContent-TypeRreq.entity\\n\\nCSeqGreq.all\\n\\nDateGopt.all\\n\\nExpiresEopt.DESCRIBE,ANNOUNCE\\n\\nFromRopt.all\\n\\nIf-Modified-SinceRopt.DESCRIBE,SETUP\\n\\nLast-ModifiedEopt.entity\\n\\nProxy-Authenticate\\n\\nProxy-RequireRreq.all\\n\\nPublicRopt.all\\n\\nRangeRopt.PLAY,PAUSE,RECORD\\n\\nRangeRopt.PLAY,PAUSE,RECORD\\n\\nRefererRopt.all\\n\\nRequireRreq.all\\n\\nRetry-AfterRopt.all\\n\\nRTP-InfoRreq.PLAY\\n\\nScaleRropt.PLAY,RECORD\\n\\nSession Rrreq.AllbutSETUP,OPTIONS\\n\\nServerRopt.all\\n\\nSpeedRropt.PLAY\\n\\nTransportRrreq.SETUP\\n\\nUnsupported Rreq.all\\n\\nUser-Agent Ropt.all\\n\\nVia Gopt.all\\n\\nWWW-Authenticate Ropt.all\\n\\n型別\\\"g\\\"表示請求和響應中的通用請求頭；型別“R”表示請求頭；型別“r”表示響應頭；型別\\\"e\\\"表示實體頭欄位。在“support”一欄中標有“req.”的欄位必須由接收者以特殊的方法實現；而“opt.”的欄位是可選的。注意，不是所有“req.”欄位在該型別的每個請求中都會被髮送。“req.”隻表示客戶機（支援響應頭）和伺服器（支援請求頭）必須執行該欄位。最後一欄列出了關於頭欄位產生作用的方法；其中“entity”針對於返回一個資訊主體的所有方法。\\n\\n協議引數\\n\\n1．RTSP版本\\n\\nH.321采用，用RTSP代替HTTP。\\n\\n2．RTSPURL\\n\\n“rksp\\\"和“rtspu\\\"方案用於指RTSP協議使用的網路資源，為RTSPURL定義方案特定的語法和語義。\\n\\n3．會議標識\\n\\n會議標識對RTSP來說是模糊的，采用標準URI編碼方法編碼，可包含任何八位組數值。會議標識必須全域性惟一。\\n\\n4．連線標識\\n\\n連線標識是長度不確定的字串，必須隨機選擇，至少要8個八位組長，使其很難被猜出。\\n\\n5．**PTE相關時標\\n\\n**PTE相關時標表示相對剪輯開始的時間，相關時標表示成**PTE時間程式碼，精確到幀級。時間程式碼格式為小時：分鐘：秒：幀。預設smpte格式是\\\"**PTE30\\\"，幀速率為每秒29.97幀。其他**PTE程式碼可選擇使用smpte時間獲得支援(如\\\"**PIE25\\\")。時間數值中幀段值可從0到29。每秒30與29.97幀的差彆可將每分鐘的頭兩幀丟掉來實現。如幀值為零，就可刪除。\\n\\n6．正常播放時間\\n\\n正常播放時間(NPT)表示相對演示開始的流絕對位置。時標由十進製分陣列成。左邊部分用秒或小時、分鐘、秒錶示；小數點右邊部分表示秒的部分。演示的開始對應0.0秒，負數冇有定義。特殊常數定義成現場事件的當前時刻，這也許隻用於現場事件。直觀上，NPT是聯絡觀看者與程式的時鐘，通常以數字式顯示在VCR上。\\n\\n7．絕對時間\\n\\n絕對時間表示成ISO8601時標，采用UTC(GMT)。\\n\\n8．可選標簽\\n\\n可選標簽是用於指定RTSP新可選項的惟一標記。這些標記用在請求和代理-請求頭段。當登記新RTSP選項時，需提供下列資訊：\\n\\n（1）名稱和描述選項。名稱長度不限，但不應該多於20個字元。名稱不能包括空格、控製字元。\\n\\n（2）表明誰改變選項的控製。如IETF，ISO，ITU-T，或其他國際標準團體、聯盟或公司。\\n\\n（3）深入描述的參考，如RFC、論文、專利、技術報告、文件原始碼和計算機手冊。\\n\\n（4）對專用選項，附上聯絡方式。\\n\\nRTSP資訊\\n\\nRTSP是基於文字的協議，采用ISO10646字元集，使用UTF-8編碼方案。行以CRLF中斷，但接收者本身可將CR和LF解釋成行終止符。基於文字的協議使以自描述方式增加可選引數更容易。由於引數的數量和命令的頻率出現較低，處理效率冇引起注意。文字協議很容易以指令碼語言(如：Tcl，VisualBasic與Perl)實現研究原型。\\n\\nISO10646字元集避免敏感字元集切換，但對應用來說不可見。RTCP也采用這種編碼方案。帶有重要意義位的ISO8859-1字元表示如100001x10xxxxxx。RTSP資訊可通過任何低層傳輸協議攜帶。\\n\\n請求包括方法、方法作用於其上的物件以及進一步描述方法的引數。方法也可設計為在伺服器端隻需要少量或不需要狀態維護。當資訊體包含在資訊中，資訊體長度由如下因素決定：\\n\\n(1)不管實體頭段是否出現在資訊中，不包括資訊體的響應，資訊總以頭段後第一個空行結束。\\n\\n(2)如出現內容長度頭段，其值以位元組計，表示資訊體長度。如未出現頭段，其值為零。\\n\\n(3)伺服器關閉連線。\\n\\n注意，RTSP目前並不支援HTTP1.1“塊”傳輸編碼，需要有內容長度頭。假如返回適度演示描述長度，即使動態產生，使塊傳輸編碼冇有必要，伺服器也應該能決定其長度。如有實體，即使必須有內容長度，且長度冇顯式給出，規則可確保行為合理。\\n\\n從使用者到伺服器端的請求資訊在第一行內包括源采用的方法、源標識和所用協議版本。RTSP定義了附加狀態程式碼，但冇有定義任何HTTP程式碼。\\n\\nRTSP實體\\n\\n如不受請求方法或響應狀態編碼限製，請求和響應資訊可傳輸實體，實體則由實體頭檔案和實體體組成，有些響應僅包括實體頭。在此，根據誰傳送實體、誰接收實體，傳送者和接收者可分彆指使用者和伺服器。\\n\\n實體頭定義實體體可選元資訊，如冇有實體體，指請求標識的資源。擴充套件頭機製允許定義附加實體頭段，而不用改變協議，但這些段不能假定接收者能識彆。不可識彆頭段應被接收者忽略，而讓代理轉發。\\n\\n連線\\n\\nRTSP請求可以幾種不同方式傳送：\\n\\n·持久傳輸連線，用於多個請求／響應傳輸。\\n\\n·每個請求／響應傳輸一個連線。\\n\\n·無連線模式。\\n\\n傳輸連線型別由RTSPURL來定義。對“rtsp'’方案，需要持續連線；而\\\"rtspu\\\"方案，呼叫RTSP請求傳送，而不用建立連線。\\n\\n不像HTTP，RTSP允許媒體伺服器給媒體使用者傳送請求。然而，這僅在持久連線時才支援，否則媒體伺服器冇有可靠途徑到達使用者，這也是請求通過防火牆從媒體伺服器傳到使用者的惟一途徑。\\n\\n方法定義\\n\\n方法記號表示資源上執行的方法，它區分大小寫。新方法可在將來定義，但不能以$開頭。已定義方法如下表所示。\\n\\n某些防火牆設計與其他環境可能要求伺服器插入RTSP方法和流資料。由於插入將使客戶端和伺服器操作複雜，並增加附加開銷，除非有必要，應避免這樣做。插入二進製資料僅在RTSP通過TCP傳輸時纔可使用。流資料(如RTP包)用一個ASCII字元$封裝，後跟一個一位元組通道標識，其後是封裝二進製資料的長度，兩位元組整數。流資料緊跟其後，冇有CRLF，但包括高層協議頭。每個$塊包含一個高層協議資料單元。\\n\\n當傳輸選擇為RTP，RTCP資訊也被伺服器通過TCP連線插入。預設情況下，RTCP包在比RTP通道高的第一個可用通道上傳送。客戶端可能在另一通道顯式請求RTCP包，這可通過指定傳輸頭插入引數中的兩個通道來做到。當兩個或更多流交叉時，為取得同步，需要RTCP。而且，這為當網路設定需要通過TCP控製連線透過RTP／RTCP提供了一條方便的途徑，可能時，在UDP上進行傳輸。\\n\\n流水線操作\\n\\n支援持久連線或無連線的客戶端可能給其請求排隊。伺服器必須以收到請求的同樣順序發出響應。如果請求不是傳送給多播組，接收者就確認請求，如冇有確認資訊，傳送者可在超過一個來回時間(RTT)後重發同一資訊。\\n\\n在TCP中RTT估計的初始值為500ms。應用快取最後所測量的RTT，作為將來連線的初始值。如使用一個可靠傳輸協議傳輸RTSP，請求不允許重發，RTSP應用反過來依賴低層傳輸提供可靠性。如兩個低層可靠傳輸(如TCP和RTSP)應用重發請求，有可能每個包損失導致兩次重傳。由於傳輸棧在第一次嘗試到達接收者前不會傳送應用層重傳，接收者也不能充分利用應用層重傳。如包損失由阻塞引起，不同層的重發將使阻塞進一步惡化。時標頭用來避免重發模糊性問題，避免對圓錐演演算法的依賴。每個請求在CSeq頭中攜帶一個係列號，每傳送一個不同請求，它就加一。如由於冇有確認而重發請求，請求必須攜帶初始係列號。\\n\\n實現RTSP的係統必須支援通過TCP傳輸RTSP，並支援UDP。對UDP和TCP，RTSP伺服器的預設都是554。許多目的一致的RTSP包被打包成單個低層PDU或TCP流。RTSP資料可與RTP和RTCP包交叉。不像HTTP，RTSP資訊必須包含一個內容長度頭，無論資訊何時包含負載。否則，RTSP包以空行結束，後跟最後一個資訊頭。\\n\\n擴充套件RTSP\\n\\n由於不是所有媒體伺服器有著相同的功能，媒體伺服器有必要支援不同請求集。RTSP可以如下三種方式擴充套件：\\n\\n(1)以新引數擴充套件。如使用者需要拒絕通知，而方法擴充套件不支援，相應標記就加人要求的段中。\\n\\n(2)加入新方法。如資訊接收者不理解請求，返回501錯誤程式碼，傳送者不應再次嘗試這種方法。使用者可使用OPTIONS方法查詢伺服器支援的方法。伺服器使用公共響應頭列出支援的方法。\\n\\n(3)定義新版本協議，允許改變所有部分(協議版本號位置除外)。\\n\\n操作模式\\n\\n每個演示和媒體流可用RTSPURL識彆。演示組成的整個演示與媒體屬性由演示描述檔案定義。使用HTTP或其他途徑使用者可獲得這個檔案，它冇有必要儲存在媒體伺服器上。為了說明這個問題，假設演示描述了多個演示，其中每個演示維持了一個公共時間軸。為簡化說明，且不失一般性，假定演示描述的確包含這樣一個演示。演示可包含多個媒體流。除媒體引數外，網路目標地址和也需要決定。\\n\\n下麵區分幾種操作模式。\\n\\n(1)單播：使用者選擇的號將媒體傳送到RTSP請求源。\\n\\n(2)伺服器選擇地址多播：媒體伺服器選擇多播地址和，這是現場直播或準點播常用的方式。\\n\\n(3)使用者選擇地址多播：如伺服器加入正在進行的多播會議，多播地址、和金鑰由會議描述給出。\\n\\nRTSP狀態\\n\\nRTSP控製通過單獨協議傳送的流，與控製通道無關。例如，RTSP控製可通過TCP連線，而資料流通過UDP。因此，即使媒體伺服器冇有收到請求，資料也會繼續傳送。在連線生命期，單個媒體流可通過不同TCP連線順序發出請求來控製。所以，伺服器需要維持能聯絡流與RTSP請求的連線狀態。RTSP中很多方法與狀態無關，但下列方法在定義伺服器流資源的分配與應用上起著重要的作用：\\n\\n(1)SETUP：讓伺服器給流分配資源，啟動RTSP連線。\\n\\n(2)PLAY與RECORD：啟動SETUP分配流的資料傳輸。\\n\\n(3)PAUSE：臨時停止流，而不釋放伺服器資源。\\n\\n(4)TEARDOWN：釋放流的資源，RTSP連線停止。\\n\\n標識狀態的RTSP方法使用連線頭段識彆RTSP連線，為響應SETUP請求，伺服器連線產生連線標識。\\n\\n與其他協議的關係\\n\\n實時流協議在語法和操作上與HTTP\\/1.1類似，因此HTTP的擴充套件機製大都可加入RTSP。然而，在很多重要方麵RTSP仍不同於HTTP：\\n\\nRTSP引入了大量新方法並具有一個不同的協議識別符號；\\n\\n在大多數情況下，RTSP伺服器需要保持預設狀態，與HTTP的無狀態相對；\\n\\nRTSP中客戶端和伺服器都可以發出請求；\\n\\n在多數情況下，資料由不同的協議傳輸；\\n\\nRTSP使用ISO10646（UTF-8）而並非ISO8859-1，與當前的國際標準HTML相一致；\\n\\nURI請求總是包含絕對URI。為了與過去的錯誤相互相容，HTTP\\/1.1隻在請求過程中傳送絕對路徑並將主機名置於另外的頭欄位。\\n\\nRTSP在功能上與HTTP有重疊，與HTTP相互作用體現在與流內容的初始接觸是通過網頁的。目前的協議規範目的在於允許在網頁伺服器與實現RTSP媒體伺服器之間存在不同傳遞點。例如，演示描述可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨立RTSP伺服器與使用者不全依靠HTTP。\\n\\n但是，RTSP與HTTP的本質差彆在於資料傳送以不同協議進行。HTTP是不對稱協議，使用者發出請求，伺服器作出響應。RTSP中，媒體使用者和伺服器都可發出請求，且其請求都是無狀態的；在請求確認後很長時間內，仍可設定引數，控製媒體流。重用HTTP功能至少在兩個方麵有好處，即安全和代理。要求非常接近時，在快取、代理和授權上采用HTTP功能是有價值的。\\n\\n當大多數實時媒體使用RTP作為傳輸協議時，RTSP冇有繫結到RTP。RTSP假設存在演示描述格式可表示包含幾個媒體流的演示的靜態與臨時屬性。\\n\\n微軟與RTSP\\n\\n簡述\\n\\nRTSP並非隻是微軟在用！ 這是一個公開的規範，在這個規範上開發了很多的流伺服器。甚至Linux服務提供者和蘋果的程式員也使用rtsp協議以及RealNetworks流媒體。似乎整個世界的網路流傳輸都用這個協議。然而，微軟並不隻在rtsp上有所作為。\\n\\n微軟和RTSP\\n\\n在寫這個文件的時候，微軟正處於從首選MMS協議轉換到首選采用RTSP協議的過程中。這個說明在MediaPlayer9.0版本和流媒體伺服器2003版本之後，我們會看到微軟將rtsp協議作為流媒體傳輸的主要協議。\\n\\n隨著時間慢慢的流逝，我們會發現mms協議正逐步走出人們的視野。ItisonlyassumedthatthisissoMScansaytheyarebeingopenwiththeirprotocols(rtspisanopenstandard)whileatthesametimedisregardingtheneedtopublicisetheirownMMSprotocolonceitsgonefrommediaplayer.然而，mms還冇有真的死亡，至少在接下來的幾年中我們依然可以看到它在流媒體傳輸中的身影。\\n\\n是否微軟的RTSP協議和標準的開放式RTSP不同？\\n\\n是的。跟在RFC2326（1998年四月）中定義的原始RTSP協議相比，微軟的rtsp協議有一些輕微的改動。我們網站上有本文件（還有後續版本）和一個簡單的研究，它們可以幫助你瞭解這些資訊。\\n\\n區彆\\n\\n微軟的rstp規範與標準rtsp協議相比最主要的改動是傳送包payloads到客戶端的方式，另外還有一些請求命令有一些改動。傳輸單個媒體包的機製並冇有文件（就我目前所知），這可能是微軟要保留的資訊。 就像MMS和HTTP1.0流協議使用一個媒體資料包頭一樣，RTSP也有。但是微軟的資料包頭格式冇有在任何的rtsp文件中註明。在企圖連線微軟的rtsp伺服器時，這是主要的問題。\\n\\n微軟RTSP協議的命令采用的語法和標準rtsp協議的命令語法一樣，隻有一些小的修改和新增，可以通過閱讀網上的一些文件，就可以知道怎麼去組成這些命令。微軟rtsp命令部分已經有文件了。\\n\\n\"
}