實時流協(xié)議(RTSP).doc_第1頁
實時流協(xié)議(RTSP).doc_第2頁
實時流協(xié)議(RTSP).doc_第3頁
實時流協(xié)議(RTSP).doc_第4頁
實時流協(xié)議(RTSP).doc_第5頁
已閱讀5頁,還剩8頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

Network Working Group H. SchulzrinneRequest for Comments: 2326 Columbia U.Category: Standards Track A. RaoNetscapeR. LanphierRealNetworksApril 1998翻譯: radium 2005.1實時流協(xié)議(RTSP) ( Real Time Streaming Protocol (RTSP) )備忘錄的狀態(tài):本文檔講述了一種Internet社區(qū)的Internet標準跟蹤協(xié)議,它需要進一步進行討論和建議以得到改進。請參考最新版的“Internet正式協(xié)議標準”(STD1)來獲得本協(xié)議的標準化程度和狀態(tài)。本備忘錄的發(fā)布不受任何限制。版權聲明:版權為The Internet Society 所有。所有權利保留。摘要:實時流協(xié)議(RTSP)是應用層協(xié)議,控制實時數(shù)據(jù)的傳送。RTSP提供了一個可擴展框架,使實時數(shù)據(jù),如音頻與視頻的受控、點播成為可能。數(shù)據(jù)源 包括現(xiàn)場數(shù)據(jù)與存儲在剪輯中數(shù)據(jù)。該協(xié)議目的在于控制多個數(shù)據(jù)發(fā)送連接,為選擇發(fā)送通道,如UDP、組播UDP與TCP,提供途徑,并為選擇基于 RTP(RFC1889)上傳送機制提供方法。 目錄:1 緒論 51.1 目的 51.2 要求 61.3 術語 61.4 協(xié)議特點 71.5 RTSP擴展 81.6 操作模式 91.7 RTSP狀態(tài) 91.8 與其他協(xié)議關系 102 符號協(xié)定 103 協(xié)議參數(shù) 103.1 RTSP版本 103.2 RTSP URL 113.3 會議標識 133.4 會話標識 133.5 SMPTE 相對時間戳 133.6正常播放時間 143.7 絕對時間 153.8 選擇標簽 153.8.1 用IANA注冊新的選擇標簽 154 RTSP消息 154.1 消息類型 164.2 消息標題 174.3 消息主體 174.4 消息長度 185 普通標題域 186 請求 196.1 請求隊列 196.2 請求標題域 197 回應 207.1 狀態(tài)行 207.1.1 狀態(tài)代碼和原因分析 207.1.2 回應標題域 238 實體 238.1 實體標題域 248.2 實體主體 249 連接 259.1 流水線操作 259.2 可靠性及確認 2510 方法定義 2510.1 選擇 2610.2 描述 2610.3 通告 2610.4 建立 2610.5 播放 2710.6 暫停 2710.7 斷開 2710.8 獲取參數(shù) 2810.9 設置參數(shù) 2810.10 重定向 2810.11 錄制 2910.12 嵌入二進制數(shù)據(jù) 2911狀態(tài)代碼定義(Status Code Definitions) 2911.1成功2xx(Success 2xx) 3011.1.1 存儲空間低 250 3011.2 重定向(Redirection 3xx) 3111.3 客戶端錯誤(Client Error )4xx 3111.3.1方法不允許 3211.3.2參數(shù)不能理解 3211.3.3會議未找到 3311.3.4 帶寬不足 3311.3.5 會話未找到 3411.3.6 本狀態(tài)下該方法無效 3411.3.7 標題域對資源無效 3411.3.8 無效范圍 3511.3.9 參數(shù)只讀 3511.3.10 不允許合操作 3611.3.11 只允許合操作 3611.3.12 不支持的傳輸 3611.3.13 目標不可達 3711.3.14 選擇不支持 3712 標題域定義(Header Field Definitions) 3812.1 接受 3812.2 接受編碼 3812.3 接受語言 3912.4 允許(Allow) 3912.5 授權(Authorization) 4012.6 帶寬 4012.7 塊大小 4012.8 緩存控制 4112.9 會議 4112.10 連接 4112.11 基本內容 4212.12 內容編碼(Content-Encoding) 4212.13 內容語言 4312.14 內容長度(Content-Length) 4312.15 內容位置 4312.16 內容類型(Content-Type) 4412.17 序列號 4412.18 日期(Date) 4412.19 過期(Expires) 4512.20 來自(From) 4512.21 主機 4512.22 如果匹配 4512.23 從何時更改(If-Modified-Since) 4612.24 最近更改(Last-Modified) 4612.25 位置(Location) 4612.26 代理授權 4712.27 代理要求 4712.28 公用性 4712.29 范圍 4912.30 提交方(Referer) 4912.31 稍后再試 4912.32 要求 4912.33 RTP信息 4912.34 比例 4912.35 速度 4912.36 服務器(Server) 4912.37 會話 4912.38 時間戳 4912.39 傳輸 4912.40 不支持 4912.41 用戶代理(User-Agent) 4912.42 變化 4912.43 通過 4912.44 WWW-授權(WWW-Authenticate) 5013 緩存 5014 實例 5014.1 要求媒體(單播) 5014.2 容器文件的流 5114.3 單個流容器文件 5114.4 組播現(xiàn)場媒體表示 5114.5 在存在的會話中播放媒體 5114.6 錄制 5215 語法 5215.1 基本語法 5216 安全考慮(Security Considerations) 52附錄A RTSP協(xié)議狀態(tài)機 53A.1 客戶端狀態(tài)機 53A.2 服務器端狀態(tài)機 53附錄B 同RTP協(xié)議的交互 53附錄C 使用SDP進行RTSP會話描述 54C.1 定義 54C.1.1 控制URL 55C.1.2 媒體流 55C.1.3 有效載荷類型 55C.1.4 詳細格式參數(shù) 55C.1.5 表示的范圍 56C.1.6 有效時間 56C.1.7 連接信息 56C.1.8 實體標簽 57C.2 合控制不可用 57C.3 合控制可用 57附錄D 最簡單的RTSP實現(xiàn) 58D.1 客戶端 58D.1.1回放 58D.1.2 授權 58D.2 服務器 59D.2.1回放 59D.2.2授權 59附錄E 作者地址 60附錄F 致謝 60參考書目 60版權申明 611 緒論 1.1 目的實時流協(xié)議(RTSP)建立并控制一個或幾個時間同步的連續(xù)流媒體。盡管連續(xù)媒體流與控制流有可能交叉,但RTSP本身通常并不發(fā)送連續(xù)媒體流。換言之,RTSP充當多媒體服務器的網(wǎng)絡遠程控制。表示描述(presentation description)定義了被控流,但本文并沒有定義表示描述的格式。這里沒有使用RTSP連接的概念,而由RTSP會話(session)代替(每次服務由服務器端保持一個帶標簽的會話)。RTSP會話沒有綁定到傳 輸層連接(如TCP連接)。因為雖然在RTSP會話期間,RTSP客戶端可打開或關閉多個對服務器端的可靠傳輸連接以發(fā)出RTSP 請求。但此外,也可能使用無連接傳輸協(xié)議,比如用UDP發(fā)送RTSP請求。RTSP控制的流可能用到RTP,但RTSP操作并不依賴用于攜帶連續(xù)媒體的傳輸機制。實時流協(xié)議在語法和操作上與HTTP/1.1類似,因此HTTP的擴展機制大都可加入RTSP。盡管如此,RTSP在很多方面還是和HTTP有很大的不同:2 RTSP引入了很多新方法并且有不同的協(xié)議標識符。2 RTSP服務器在大多數(shù)默認情況下需要維持一個狀態(tài),但HTTP是無狀態(tài)協(xié)議。2 RTSP客戶機和服務器都可以發(fā)出請求。2 數(shù)據(jù)由另一個協(xié)議傳送(有一特例除外)。2 RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1,以配合當前HTML的國際化。2 RTSP使用URI請求時包含絕對URI。而由于歷史原因造成的向后兼容性問題,HTTP/1.1只在請求中包含絕對路徑,把主機名放入單獨的標題域中。這使得“虛擬主機”實現(xiàn)更為簡便,一個單獨IP地址的主機可虛擬為幾個文件樹主機。協(xié)議支持的操作如下: 從媒體服務器上檢索媒體: 用戶可通過HTTP或其它方法請求一個表示描述。如表示是組播,表示描述就包含用于連續(xù)媒體的的組播地址和端口。如表示僅通過單播發(fā)送給用戶,用戶為了安全應提供目的地址。 媒體服務器邀請進入會議: 媒體服務器可被邀請參加正進行的會議,或回放媒體,或記錄其中一部分,或全部。這種模式在分布式教育應用上很有用,會議中幾方可輪流按遠程控制按鈕。 將媒體加到現(xiàn)成講座中: 如服務器告訴用戶可獲得附加媒體內容,對現(xiàn)場講座顯得尤其有用。如HTTP/1.1中類似,RTSP請求可由代理、通道與緩存處理。 1.2 要求在本文檔中的關鍵字“必須”,“一定不能”,“要求”,“會”,“不會”,“應該”,“不應該”,“被推薦的”,“可以”,和“可選擇的”都在RFC2119中解釋。1.3 術語一些術語原由HTTP/1.1采用。在HTTP/1.1中定義的術語這里不再列舉。合控制:服務器使用單條時間線對多個流的控制。對音頻/視頻回饋來講,這就意味著客戶端僅需發(fā)送一條播放或者暫停消息就可同時控制音頻和視頻的回饋。會議:多方參與的多媒體表示,這里的多方意味著大于或者等于一方??蛻舳耍褐刚埱竺襟w服務器上連續(xù)流媒體數(shù)據(jù)的客戶端。連接: 兩個應用程序以通訊為目的在傳輸層建立虛擬電路。容器文件: 可以容納多個共同播放時包含表示(presentation)的媒體流的文件。RTSP服務器可以為這些容器文件提供合控制,但容器文件的概念本身并不是本協(xié)議內容。連續(xù)媒體: 接受器和數(shù)據(jù)源之間存在時序關系的數(shù)據(jù)。也就是說,接受器需要重新產(chǎn)生存在于源數(shù)據(jù)中的時序關系。最普通的連續(xù)媒體的例子是音頻和動畫視頻。連續(xù)媒體可以 是實時的(但是不交互的),它們在源和接受器之間是一種緊密的時序關系;或者是流的形式,這種關系就沒有那么嚴格了。實體:作為請求或者回應的有效負荷傳輸?shù)男畔?。由以實體標題域(entity-header field)形式存在的元信息和以實體主體(entity body)形式存在的內容組成,如第八章所述。媒體的初始化:數(shù)據(jù)類型/編碼的具體初始化,這些包括時鐘輸率,顏色表等。用戶請求媒體回放的任何獨立傳輸信息,是在創(chuàng)建流時初始化媒體流相位時產(chǎn)生的。媒體參數(shù):針對回放前或回放過程中有可能改變的媒體類型而專門設定的參數(shù)。媒體服務器:可對一個或多個媒體流提供回放和錄制服務的服務器。同一個表示(presentation)中不同的媒體流可能來自于不同的媒體服務器。媒體服務器可以建立在作為傳送請求表示(presentation)的Web服務器的主機上,也可以建立在不同的主機上。媒體服務器重定向: 重新定向媒體客戶端到另外一個媒體服務器。(媒體)流: 單個媒體實例,比如,在應用中共用音頻流或視頻流。當使用RTP時,流包括由RTP 會話(session)中源所創(chuàng)建的所有RTP和RTCP包。這和定義DSM-CC流時相同。消息:RTSP通訊的基本單元。由15章語法定義的一串八位位組組成,并通過連接或者無連接協(xié)議傳送。參與者:一個會議成員。參與者可以是機器,比如是媒體記錄或回放服務器。表示(presentation):對用戶請求所回饋的一組流,其使用下面的表示描述(presentation description)形式。在本文中的多數(shù)情況下,其意味著對流進行總體控制,但這并不是必須的。表示描述(presentation description):表 示描述包含在表示(presentation)中一個或者多個媒體流的信息。比如,編碼,網(wǎng)絡地址和內容的信息。另外,其他IETF協(xié)議,如SDP協(xié)議使 用會話(session)代替現(xiàn)場presentation。表示描述可以采用包括會話描述(session description)SDP在內的多種格式?;貞篟TSP回應。如果能理解HTTP回應,就能清楚的理解RTSP回應。請求;RTSP請求。如果能理解HTTP請求,就能清楚的理解RTSP請求。RTSP會話(session):RTSP交互的全過程。比如,一個電影的觀看過程。會話(session)包括由客戶端建立連續(xù)媒體流傳輸機制(SETUP),使用播放(PLAY)或錄制(RECORD)開始傳送流,用停止(TEARDOWN)關閉流。傳輸初始化:客戶端和服務器端之間傳輸信息(端口號,傳輸協(xié)議等)的交互。1.4 協(xié)議特點 RTSP 特性如下:可擴展性: RTSP中很容易加入新方法和參數(shù)。 易解析: RTSP可由標準 HTTP或MIME解析器解析。安全:RTSP使用網(wǎng)頁安全機制。所有HTTP授權機制如basic和digest授權都可直接使用。也可以傳輸層或網(wǎng)絡層安全機制。 獨立于傳輸: RTSP可使用不可靠數(shù)據(jù)報協(xié)議(UDP)、可靠數(shù)據(jù)報協(xié)議(RDP),如要實現(xiàn)應用級可靠,可使用可靠流協(xié)議。 多服務器支持: 表示(presentation)中的每個流可放在不同服務器上,用戶端自動同不同服務器建立幾個并發(fā)控制連接,媒體同步在傳輸層執(zhí)行。 記錄設備控制: 協(xié)議可控制記錄和回放設備,也可控制可在記錄和回放切換的設備。 流控與會議開始分離: 流控與邀請媒體服務器入會分離;僅要求會議初始化協(xié)議提供,或可用來創(chuàng)建唯一會議標識號。特殊情況下, SIP或H.323 可用來邀請服務器入會。適合專業(yè)應用: 通過SMPTE 時標,RTSP支持幀級精度,允許遠程數(shù)字編輯。表示描述中立: 協(xié)議沒強加特殊表示或元文件,可傳達所用格式類型;然而,表示描述至少必須包含一個RTSP URI。 代理與防火墻友好: 協(xié)議可由應用和傳輸層防火墻處理。防火墻需要理解SETUP方法,為UDP媒體流打開一個缺口。 HTTP友好: 此處,RTSP明智的采用HTTP觀念,使現(xiàn)在結構都可重用。結構包括Internet 內容選擇平臺(PICS)。由于在大多數(shù)情況下控制連續(xù)媒體需要服務器狀態(tài), RTSP不僅僅向HTTP 添加方法。 適當?shù)姆掌骺刂疲?如用戶能啟動一個流,它必須也能停止一個流。 服務器不能啟動一個用戶不能停止的流。傳輸協(xié)調: 實際處理連續(xù)媒體流前,用戶可協(xié)調傳輸方法。 性能協(xié)調: 如基本特征無效,必須有一些清理機制讓用戶決定那種方法沒生效。這允許用戶提出適合的用戶界面。 例如,如果不允許尋找,用戶界面必定能禁止位置條滑動。以前要求RTSP必須能支持多用戶,但現(xiàn)在得出一個更好的方法就是保證RTSP能很容易擴展成支持多用戶即可。因為流的標志可以被多個控制流使用,因此”遠程通過”成為可能。協(xié)議不涉及到多個客戶端如何協(xié)調入口,其由下層“社會協(xié)議”或其他下層控制機制提供。1.5 RTSP擴展由于不是所有媒體服務器有著相同的功能,媒體服務器有必要支持不同請求集。例如:? 服務器可能只須支持回放,因此不必不支持錄制功能。? 對于支持現(xiàn)場播放的服務器可能不支持尋找功能。? 一些服務器可能不支持設置流參數(shù),因此不支持GET_PARAMETER和SET_PARAMETER。但服務器應該實現(xiàn)所有12章中要求的標題域。表示描述(presentation description)應當保證不提出服務器不支持的功能,這種情形和HTTP/1.1中H19.6描述方法不支持across server的情形一致。RTSP 可以如下三種方式擴展,這里以改變大小排序: ? 以新參數(shù)擴展。如用戶需要拒絕通知,而方法擴展不支持,相應標記就加入要求的段中。 ? 加入新方法。如信息接收者不理解請求,返回501錯誤代碼(還未實現(xiàn)),發(fā)送者不應再次嘗試這種方法。用戶可使用OPTIONS方法查詢服務器支持的方法。服務器使用公共回應標題列出支持的方法。 ? 定義新版本協(xié)議,允許改變所有部分。(除了協(xié)議版本號位置) 1.6 操作模式 每個表示和媒體流可用RTSP URL識別。表示組成的整個表示與媒體屬性由表示描述(presentation description)文件定義,表示描述格式不在本協(xié)議中定義。使用HTTP或其它途徑用戶可獲得這個文件,它沒有必要保存在媒體服務器上。 為了說明,假設表示描述(presentation description)描述了多個表示(presentation),其中每個表示(presentation)維持了一個公共時間軸。為簡化說明,且 不失一般性,假定表示描述(presentation description)的確包含這樣一個表示(presentation)。表示(presentation)可包含多個媒體流。表示描述 (presentation description)即組成表示的流的描述,包括它們的編碼,語言和使用戶可以選擇最符合要求媒體的其他參數(shù)。在表示描述中,被RTSP分別控制的媒 體流由RTSP URL表示。RTSP URL指出了處理具體媒體流的服務器以及存在于該服務器上流的名字。多個媒體流可以放到不同的服務器上,比如音頻和視頻流可以分別放到不同服務器而負載共 享。描述(description)還列出了服務器傳輸可使用的方法。除媒體參數(shù)外,網(wǎng)絡目標地址和端口也需要決定。下面區(qū)分幾種操作模式: 單播: 以用戶選擇的端口號將媒體發(fā)送到RTSP請求源。 組播,服務器選擇地址: 媒體服務器選擇組播地址和端口,這是現(xiàn)場直播或準點播常用的方式。 組播,用戶選擇地址: 如服務器加入正在進行的組播會議,組播地址、端口和密匙由會議描述給出。 1.7 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)無關,但下列方法在定義服務器流資源的分配與應用上起著重要的作用: SETUP: 讓服務器給流分配資源,啟動RTSP會話。 PLAY與RECORD: 啟動SETUP 分配流的數(shù)據(jù)傳輸。 PAUSE: 臨時停止流,而不釋放服務器資源。 TEARDOWN: 釋放流的資源,RTSP會話停止。 標識狀態(tài)的RTSP方法使用會話(session)標題域識別RTSP會話,為回應SETUP請求,服務器生成會話標識。 1.8 與其他協(xié)議關系 RTSP在功能上與HTTP有重疊,與HTTP相互作用體現(xiàn)在與流內容的初始接觸是通過網(wǎng)頁的。目前的協(xié)議規(guī)范目的在于允許在網(wǎng)頁服務器與實現(xiàn)RTSP媒 體服務器之間存在不同傳遞點。例如,表示描述(presentation description)可通過HTTP和RTSP檢索,這降低了瀏覽器的往返傳遞,也允許獨立RTSP 服務器與用戶不全依靠HTTP。 但是,RTSP與HTTP 的本質差別在于數(shù)據(jù)發(fā)送以不同協(xié)議進行。HTTP是不對稱協(xié)議,用戶發(fā)出請求,服務器作出回應。RTSP中,媒體用戶和服務器都可發(fā)出請求,且其請求都是無狀態(tài)的;在請求確認后很長時間內,仍可設置參數(shù),控制媒體流。重用HTTP功能至少在兩個方面有好處,即安全和代理。要求非常接近,在緩存、代理和授權上采用HTTP功能是有價值的。 當大多數(shù)實時媒體使用RTP作為傳輸協(xié)議時,RTSP沒有綁定到RTP。RTSP假設存在表示描述格式可表示包含幾個媒體流的表示的靜態(tài)與臨時屬性。 2 符號協(xié)定既 然很多定義和語法與HTTP/1.1中相同,這里僅指出它們在HTTP/1.1中定義的位置而并沒有拷貝它們到本文檔。為簡便起見,本文檔中 HX.Y 表示對應HTTP/1.1(RFC 2068)中的X.Y部分。(譯者注:為更方便學習RTSP,本翻譯文檔將相關段落完全譯出)與H2.1類似,本文對所有機制的說明都是以散文和補充反饋的方式來描述的。除RTSP中以”1#”代替”,”為分隔符不同外,其余在RFC 2234中有詳細的描述。簡單說明補充反饋方式如下:補充反饋方式(augmented BNF)包括下面的結構:要解釋的名詞名詞解釋(name = definition)規(guī)則的名字(name)就是它本身(不帶任何尖括號,“”),后面跟個等號,然后就是該規(guī)則的定義。如果規(guī)則需要用多個行來描述,利用空格進行縮進格式排版。某些基本的規(guī)則使用大寫,如SP, LWS, HT, CRLF, DIGIT, ALPHA,等等。定義中還可以使用尖括號來幫助理解規(guī)則名的使用。字面意思(literal)文字的字面意思放在引號中間,除非特別指定,該段文字是大小寫敏感的。規(guī)則1規(guī)則2(rule1 | rule2)“”表示其分隔的元素是可選的,比如,“是否”要選擇是或否。(規(guī)則1規(guī)則2)((rule1 rule2))在圓括號中的元素表明必選其一。如(元素1(元素2元素3)元素4)可表明兩種意思,即“元素1元素2元素4”和“元素1元素3元素4”*規(guī)則(*rule)在元素前加星號“*”表示循環(huán),其完整形式是“*元素”,表明元素最少產(chǎn)生次,最多次。缺省值是0到無限,例如,“1*元素”意思是至少有一個,而“1*2元素”表明允許有1個或2個。規(guī)則(rule)方括號內是可選元素。如“元素1元素2”與“*1(元素1元素2)”是一回事。N規(guī)則(N rule)表明循環(huán)的次數(shù):“(元素)”就是“*(元素)”,也就是精確指出取值。因而,2DIGIT 就是2位數(shù)字, 3ALPHA 就是由三個字母組成字符串。規(guī)則(#rule)“#”與“*”類似,用于定義元素列表。完整形式是“#元素”表示至少有個至多有個元素,中間用“,”或任意數(shù)量的空格(LWS-linear whitespace)來分隔,這將使列表非常方便,如“(*LWS 元素 *( *LWS , *LWS 元素 )”就等同于“1#元素”??赵卦诮Y構中可被任意使用,但不參與元素個數(shù)的計數(shù)。也就是說,“(元素1),(元素2)”僅表示2個元素。但在結構中,應至少有一個非空的元素存在。缺省值是0到無限,即“#(元素)”表示可取任何數(shù)值,包括0;而“1

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論