電子郵件係統 RTSP

{

\"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\"

}