rtsp詳解

原創 cll_jj 2020-06-16 15:53
實時流協議（RTSP）是應用層協議，控制實時數據的傳送 。RTSP提供了一個可擴展框架，使受控、按需傳輸實時數據（如音頻與視頻）成爲可能。數據源包括現場數據與存儲在剪輯中的數據。本協議旨在於控制多個數據發送會話，提供了一種選擇傳送途徑（如UDP、組播UDP與TCP）的方法，並提供了一種選擇基於RTP (RFC1889)的傳送機制的方法。
1 介紹
 
1.1 目的
 
    實時流協議（RTSP）建立並控制一個或幾個時間同步的連續流媒體，比如音頻或視頻。儘管在連續媒體流中有可能插入控制流（見10.12節），但RTSP本身通常並不發送連續媒體流。換言之，RTSP充當多媒體服務器的"網絡遙控器"。
     表示描述定義了流的控制操作的集合，但本文並沒有規定表示描述的格式。
     RTSP沒有"連接"這個概念，而由RTSP會話(session)代替（服務器端保持一個由識別符標記的會話）。RTSP會話沒有綁定傳輸層連接（如TCP連接）。在RTSP會話期間，RTSP客戶端可以打開或關閉多個到服務器端的可靠傳輸連接以發出RTSP請求。但也可以使用無連接傳輸協議，比如UDP，來發送RTSP請求。
     RTSP所控制的流可能用到RTP，但RTSP的操作並不依賴用來傳送連續媒體的傳輸機制。實時流協議在語法和操作上有意地類似於HTTP/1.1，使得HTTP的擴展機制大都可加入RTSP。儘管如此，RTSP在很多重要方面與HTTP有所不同：
     *RTSP引入了很多新方法並且有不同的協議標識符。
       *RTSP服務器在絕大多數默認情況下需要維持狀態，而HTTP是無狀態協議。
      *RTSP客戶機和服務器都可以發出請求。
     *數據由信帶外的另一個協議傳送（但有一個特例）。
       *RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合當前HTML的國際化。
       *RTSP的URI請求時總是包含絕對URI。而由於歷史原因造成的後向兼容性問題，HTTP/1.1只在請求中包含絕對路徑，把主機名放入單獨的頭部域中。
     當只有一個IP的主機要提供多個文檔樹時，可使"虛擬主機"的實現更簡單。
 協議支持以下操作：
 從媒體服務器上獲得媒體：
    用戶可通過HTTP或其它途徑請求一個表示描述。如果該表示是組播，表示描述就包含用於該連續媒體的的多播地址和端口。如表示僅通過單播發送給用戶，用戶爲了安全應起見要提供目的地址。
 邀請媒體服務器進入會議：
    媒體服務器可被"邀請"加入已存在的的會議，包括向該表示內回放媒體，或記錄此表示中的一部分或全部媒體。這種模式在分佈式教學應用上很有用。會議中的各方可輪流"按網絡遙控器的按鈕"。
 將媒體加到已存在的表示中：
    現場表示 的專用概念。當服務器可以告訴客戶端"可以附加媒體"時有用。
 和HTTP/1.1類似，RTSP的請求可由代理、通道與緩存處理。
1.2 要求
在本文檔中的關鍵字"必須"，"必須不"、"需要"、"必須"、"必須不"、"應該"、"不應該"、"推薦"、"可能"、和"可選的"，都和RFC2119 [4]中的解釋一致。
 1.3 術語
 一些HTTP/1.1的術語被採用。這裏沒有舉出的術語，其定義與HTTP/1.1相同。
 合控制：
    服務器使用一條時間線對多個流進行控制。對音頻/視頻的回放來講，這意味着客戶端僅需發送一條播放或者暫停消息就可同時控制音頻和視頻的回放。
 會議：
    多方參與的多媒體表示，這裏的多方意味着大於或等於一方。
客戶端：
    指請求媒體服務器上連續流媒體數據的客戶端。
 連接：
    以通訊爲目的，在傳輸層建立的兩個程序間的虛擬信道。
 容器文件：
    可以容納多個媒體流的文件，而這些媒體流共同播放時通常還包含一個表示。RTSP服務器可以爲這些容器文件提供合控制，但容器文件的概念本身並不包含在本協議中。
 連續媒體：
    接受器和數據源之間存在時序關係的數據。也就是說，接受器需要重放原來存在於源數據中的時序關係。最普通的連續媒體的例子是音頻和動畫視頻。連續媒體可以是實時的（交互的），它們在源和接受器之間是一種緊密的時序關係；或者是流（回放）的形式，時序關係沒那麼嚴格。
 實體：
    請求或者響應的載荷部分中所傳輸的信息。實體由信息元組成，而每個信息元由由實體頭部域和實體主體組成。實體頭部域內是信息格式，實體主體內是信息內容，如第8章所述。
 媒體初始化：
    數據類型/編碼的具體初始化。這包括時鐘頻率，顏色空間等。客戶端請求一個媒體流回放時所需的任何獨立於傳輸的信息，都是在流創建時媒體初始化階段產生的。
 媒體參數:
    對於某種特定的媒體類型來說，回放前或者回放中有可能會發生改變的一些參數。
 媒體服務器：
    提供一個或多個媒體流之回放或錄製服務的服務器。同一個表示(presentation)中不同的媒體流可能來自於不同的媒體服務器。媒體服務器可以建在激活該表示(presentation)的Web服務器上，也可以建立在不同的主機上。
 媒體服務器重定向：
    重新把媒體客戶端定向到另外一個媒體服務器。
 (媒體)流：
    單個媒體實例，比如，一個音頻流或者一個視頻流，連同一個白板或者共享程序組。當使用RTP時，流包括由RTP會話(session)中同一個源所創建的所有RTP和RTCP包。這和DSM-CC流([5])的定義相同。
 消息：
    RTSP通訊的基本單元。由15章語法定義的結構化八位位組序列組成，並通過有連接或者無連接協議傳送。
 參與者：
一個會議的成員。參與者可以是機器，比如是媒體記錄或回放服務器。
 表示(presentation)：
    作爲一個完整的媒體信息，回饋性地表述給客戶端的一個或多個流的集合。表示使用下面的表示描述進行表述。大部分情況下，在RTSP中的文字部分中，這暗示集合中的流的合控制，但並非必須。
 表示描述(presentation description)：
    表示描述包含在表示(presentation)中一個或者多個媒體流的信息。比如，編碼，網絡地址和內容的信息，的集合。另外，其他IETF協議，如SDP協議使用術語"會話(session)"代替"現場表示"。表示描述可以採用包括會話描述(session description)SDP在內的多種格式。
 響應：
RTSP響應。如果能理解HTTP響應，就能清楚地理解RTSP響應。
 請求：
    RTSP請求。如果能理解HTTP請求，就能清楚地理解RTSP請求。
 RTSP會話(session)：
    包括一次RTSP"事務"（transaction）的全過程。比如，一個電影的觀看過程。會話(session)一般包括由客戶端爲連續媒體建立傳輸機制(SETUP)，使用播放(PLAY)或錄製(RECORD)開始傳送流，用停止(TEARDOWN)關閉流。
 傳輸初始化：
    客戶端和服務器端之間關於傳輸所需的相關信息（端口號，傳輸協議等）的協商。
 1.4 協議特點
 RTSP有以下特性：
易於擴展：
    可以很容易地向RTSP加入新方法和參數。
 易解析：
    RTSP可由標準HTTP或MIME解析器解析。 
 安全：
    RTSP重用 了網頁安全機制。所有HTTP授權機構如basic (RFC 2068 [2, Section 11.1])和digest (RFC 2069 [8])授權都可直接使用。也可以重用傳輸層或網絡層安全機制。
 獨立於傳輸：
    RTSP即可使用不可靠數據報協議（UDP）、可靠數據報協議（RDP），如要實現應用級可靠，也可使用可靠流協議如TCP。
 多服務器支持：
    表示(presentation)中的每個流可放在不同服務器上，客戶端自動同不同服務器建立幾個併發控制的會話，媒體同步在傳輸層執行。
 錄製設備控制：
    協議可控制記錄和回放設備，以及可在兩種模式之間切換的設備（VCR）。
流控制與會議初始化分離：
    流控制與邀請媒體服務器入會相分離；僅要求會議初始化協議可提供，或可用來創建具有唯一性的會議標識號。具體地說， SIP或H.323 可用來邀請服務器入會。
適合專業應用：
    通過SMPTE 時標，RTSP支持幀級別精度，以支持遠程數字編輯。
 適合專業應用：
    RTSP依賴SMPTE時間戳支持幀級精度，使得可以進行遠程數字編輯。
 表示描述中立：
    協議沒強行指定特定的表示或元文件格式，可傳達所用的格式類型；然而，表示描述必須至少包含一個RTSP URI。
 代理與防火牆友好：
    協議需由應用層協同傳輸層(SOCKS [14])防火牆友好地進行處理。防火牆需要理解SETUP方法，以爲UDP媒體流打開一個"洞口"。
 HTTP友好：
    此處，RTSP明智地重用了HTTP概念，使現有的基礎結構可被重用。這些基礎結構包括Internet 內容選擇平臺（PICS：Platform for Internet Content Selection [15,16]），以便通過相關標籤訪問內容。但由於在大多數情況下，控制連續媒體需要服務器狀態 ， RTSP不僅僅向HTTP 添加方法。
 合適的服務器控制：
    若客戶端能啓動一個流，它必須也能停止一個流。服務器不能啓動一個用戶不能停止的流。
傳輸協商：
    實際處理連續媒體流前，客戶端可協商傳輸方法。
性能協商：
若基礎特性被禁用，必須有某種明確的機制讓用戶決定哪種方法將不不被實現。這允許用戶提出適合的用戶界面。例如，如果不允許尋找，用戶界面必須能禁止位置條滑動。
早期曾要求RTSP支持多用戶，但現在有了更好的方案，就是保證RTSP能很容易擴展成支持多用戶即可。因爲流的標誌可以被多個控制流使用，因此可以"輪換持有控制器"。協議不涉及到多個客戶端如何協調入口--這項任務被留給"社會協議"或其他層。
1.5 擴展RTSP
由於不是所有媒體服務器有着相同的功能，媒體服務器有必要支持不同的請求集。例如：
服務器可能只能回放，因此不必支持錄製請求。
用於提供現場直播的服務器可能不支持尋找（絕對位置）功能。
一些服務器可能不支持設置流參數，因此不支持GET_PARAMETER和SET_PARAMETER請求。
 但服務器應該實現所有12章中要求的標題域。
 表示描述(presentation description)應當保證不提出服務器不支持的功能，這種情形和HTTP/1.1 [2]中，[H19.6]所描述的方法不太可能被所有服務器都支持的情形一致。
 RTSP 可以如下三種方式擴展，按所支持的改變多少排序：
     *已有的方法可以擴展加入新參數，只要這些參數可以被接收方安全地忽略。（這和給一種HTML tag增加新標籤是一樣的）如果客戶端在請求失敗時需要一個拒絕確認，需要在請求：字段(見Section 12.32)中加入一個對應於該擴展的標籤。
    *可以加入新方法。如果接收方不理解請求，它就返回一個501錯誤碼（意指未實現），發送方就不應再嘗試這種方法。客戶端可以用OPTIONS方法去詢問服務器支持的方法。服務器應該在公共迴應頭裏列出它所支持的所有方法。
     *可以定義新版本的協議，以支持幾乎所有方面的改變（除了版本協議號的位置）。
 1.6 整體運作
     每個表示和媒體流可用RTSP URL識別。表示組成的整個表示與媒體屬性由表示描述(presentation description)文件定義，其格式不在本協議中定義。客戶端可以通過HTTP或其它途徑（如email）獲得此表示描述文件，它沒有必要保存在媒體服務器上。
     根據此規範的目標，我們假想一個表示描述(presentation description)描述了多個表示(presentation)，每個表示(presentation)維持一個統一的時間軸。爲簡明但不失一般性，假定表示描述(presentation description)正好包含一個這樣的表示(presentation)。表示(presentation)可包含多個媒體流。
     表示描述(presentation description)包含組成表示的流的描述，包括它們的編碼，語言和使用戶可以選擇最符合要求媒體的其他參數。在表示描述中，各個由RTSP分別控制的媒體流各有一個RTSP URL。RTSP URL指出了處理具體媒體流的服務器以及存在於該服務器上流的名字。多個媒體流可以放到不同的服務器上，比如音頻和視頻流可以分別放到不同服務器而實現均分負載。描述（description)還列出了服務器可使用的傳輸方法。
     除媒體參數外，網絡目標地址和端口也需要決定。下面區分幾種操作模式：
 單播：
    以用戶選擇的端口號將媒體發送到RTSP請求的來源處。另一種選擇是，用和RTSP相同的可靠流傳輸媒體 。
 多播，服務器選擇地址：
    媒體服務器選擇多播地址和端口，這是現場直播或準點播常用的方式。
 多播，用戶選擇地址：
    若服務器要加入正在進行的多播會議，多播地址、端口和密匙由會議描述給出。會議描述的建立不在此規範中討論。
 1.7 RTSP狀態
     RTSP控制通過與控制通道無關的獨立協議發送的流。例如，RTSP控制可能是使用TCP連接，而數據流使用UDP。因此，即使媒體服務器沒有收到請求，數據也會繼續發送。在會話生命期，單個媒體流可通過不同TCP連接按順序發出的請求來控制。所以，服務器需要維護"會話狀態"以便使RTSP請求和流相互關聯。狀態之間的轉換在附錄A中描述。
    RTSP中很多方法與狀態無關，但下列方法在服務器流資源的定位和應用上起着重要的作用：SETUP, PLAY, RECORD, PAUSE, 和TEARDOWN.
 SETUP：
    讓服務器給流分配資源，啓動RTSP會話。
 PLAY與RECORD：
    啓動SETUP所分配的流的數據傳輸。
 PAUSE：
    臨時暫停流，而不釋放服務器資源。
 TEARDOWN：
    釋放流佔用的資源，RTSP會話停止，從服務器端退出。
     與狀態相關的RTSP方法使用會話頭部域（Session header field (Section 12.37)）來識別哪個RTSP會話的狀態需要處理，在SETUP請求(章節10.4)的響應中，服務器生成會話標識。
 1.8 與其他協議關係
     RTSP在功能上與HTTP有重疊。它也可能與HTTP相互作用，體現在與流內容的初始接觸是通過網頁的。目前的協議規範目的在於允許網頁服務器與RTSP媒體服務器之間有多種接力點。例如，表示描述(presentation description)可通過HTTP和RTSP得到，這降低了基於瀏覽器的應用模式的往返傳遞，也允許完全不依賴HTTP的獨立RTSP 服務器與客戶端。
     但是，RTSP與HTTP 的本質差別在於數據發送以信帶外的不同協議 進行。HTTP是不對稱協議，用戶發送請求，服務器作出響應。RTSP中，媒體用戶和服務器都可發送請求。RTSP請求也不是無狀態 的；在請求確認後很長時間後，仍可設置參數，繼續控制媒體流。
     重用HTTP功能至少在兩個方面有好處，即安全和代理。要求非常接近，在緩存、代理和授權上採用HTTP功能是有價值的。
     雖然大多數實時媒體使用RTP作爲傳輸層協議，RTSP並沒有綁定到RTP。
     RTSP假設存在可表示包含幾個媒體流的表示的靜態與臨時屬性的表示描述格式。
 2 符號約定
     既然很多定義和語法與HTTP/1.1中相同，這裏僅指出它們在HTTP/1.1中定義的位置而並沒有拷貝它們到本文檔。爲簡便起見，本文檔中[ HX.Y ]表示對應HTTP/1.1（RFC 2068 [2]）中的X.Y部分。（[譯者注：]爲更方便學習RTSP，本翻譯文檔將相關段落完全譯出）
 與[H2.1]類似，本文對所有機制的說明都是以增廣BNF的形式來描述的。此形式在RFC 2234中有詳細的描述，唯一的不同是RTSP中以"1#"代替","爲分隔符。
 ********************
簡單說明增廣BNF如下：
增廣BNF（augmented BNF）包括下面的結構：
 要解釋的名詞＝名詞解釋（name = definition）
規則的名字（name）就是它本身（不帶任何尖括號，"<"，">"），後面跟個等號＝，然後就是該規則的定義。如果規則需要用多個行來描述，利用空格進行縮進格式排版。某些基本的規則使用大寫，如SP, LWS, HT, CRLF, DIGIT, ALPHA,等等。定義中還可以使用尖括號來幫助理解規則名的使用。
 字面意思（"literal"）
    文字的字面意思放在引號中間，若無特別指定，則該段文字是大小寫敏感的。
 規則1｜規則2（rule1 | rule2）
    "｜"表示其分隔的元素是可選的，比如，"是｜否"要選擇‘是’或‘否’。
 （規則1 規則2）（(rule1 rule2)）
在圓括號中的元素表明必然出現。如（元素1（元素2｜元素3）元素4）可表明兩種意思，即"元素1 元素2 元素4"和"元素1 元素3 元素4"
 *規則（*rule）
在元素前加星號"*"表示循環，其完整形式是"<n>*<m>元素"，表明元素最少產生<n>次，最多<m>次。缺省值是0到無限，例如，"1*元素"意思是至少有一個，而"1*2元素"表明允許有1個或2個。
 ［規則］（[rule]）
方括號內是可選元素。如"［元素1 元素2］"與"*1（元素1 元素2）"是一回事。
 N 規則（N rule）
表明循環的次數："<n>（元素）"就是"<n>*<n>（元素）"，也就是精確指出<n>取值。因而，2DIGIT 就是2位數字, 3ALPHA 就是由三個字母組成字符串。
 ＃規則（#rule）
"#"與"*"類似，用於定義元素列表。
 完整形式是"<n>#<m>元素"表示至少有<n>個至多有<m>個元素，中間用","或任意數量的空格（LWS）來分隔，這將使列表非常方便，如"（*LWS 元素 *（ *LWS "," *LWS 元素））"就等同於"1#元素"。
 空元素在結構中可被任意使用，但不參與元素個數的計數。也就是說，"（元素1），，（元素2）"僅表示2個元素。但在結構中，應至少有一個非空的元素存在。缺省值是0到無限，即"#（元素）"表示可取任何數值，包括0；而"1#元素"表示至少有1個；而"1#2元素"表示有1個或2個。
 ；註釋（; comment）
    分號後面是註釋，僅在單行使用。
 隱含*LWS（implied *LWS）
本文的語法描述是基於單詞的。除非另有指定，否則線性空格（LWS）可以在兩個鄰近符號或分隔符（tspecials）之間任意使用，而不會對整句的意思造成影響。在兩個符號之間必須有至少一個分隔符，因爲它們也要做爲單獨的符號來解釋。實際上，應用程序在產生HTTP結構時，應當試圖遵照"通常方式"，因爲現在的確有些實現方式在通常方式下無法正常工作。
********************
     在本備忘錄中，我們用縮進的小型段落來提供背景和動機。這將使沒有參與制定RTSP規範的讀者更容易理解RTSP中各部分爲什麼要以該方式來實現。
 3 協議參數
 3.1 RTSP版本
     同[H3.1]定義，僅用RTSP代替HTTP即可。
********************
[H3.1]：
    RTSP採用主從（<major>.<minor>）數字形式來表示版本。協議的版本政策傾向於讓發送方表明其消息的格式及功能，而不僅僅爲了獲得通訊的特性，這樣做的目的是爲了與更高版本的RTSP實現 通訊。只增加擴展域的值或增加了不影響通訊行爲的消息組件都不會導致版本數據的變化。當協議消息的主要解析算法沒變，而消息語法及發送方的隱含功能增加了，將會導致從版本號（<minor>）增加；當協議中消息的格式變化了，主版本號（<major>）也將發生改變。
    RTSP消息的版本由消息第一行中的RTSP版本域來表示。
 RTSP-Version            = "RTSP" "/" 1*DIGIT "." 1*DIGIT
 注意，主從版本應當被看作單獨的整數，因爲它們都有可能增加，從而超過一位整
數。因而，RTSP/2.4比RTSP/2.13版本低，而RTSP/2.13又比RTSP/12.3版本低。
版本號前面的0將被接收方忽略，而在發送方處也不應產生。
    本文檔定義了RTSP協議的1.0版本。發送本規範定義的請求（Request）或響應（Response）消息的應用必須指明RTSP的版本爲"RTSP/1.0"。使用該版本號意味着發送消息的應用至少有條件的遵循本規範。
 應用的RTSP版本即爲應用至少能有條件遵循的RTSP版本中的最高版本。
     當代理及網關收到與其自身版本不同的RTSP請求時，必須小心處理請求的推送，因爲協議版本表明發送方的能力，代理或網關不應發出高於自身版本的消息。如果收到高版本的請求，代理或網關必須降低該請求的版本，並響應一個錯誤。而低版本的請求也應在被推送前升級。代理或網關響應請求時必須和請求的版本相同。
********************
 3.2 RTSP URL
 "rtsp"和"rtspu"前綴表示要通過RTSP協議來定位網絡資源。本節詳細定義了RTSP URL的語法和語義。
 rtsp_URL= ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [ abs_path ]
 host= <合法的Internet主機域名或IP地址(用十進制數及點組成), 見RFC1123，2.1節定義>
 port       = *DIGIT
 abs_path 在 [H3.2.1]中定義。
********************
[H3.2.1]：
     abs_path     = "/" rel_path
    rel_path     = [ path ] [ ";" params ] [ "?" query ]
     path         = fsegment *( "/" segment )
    fsegment     = 1*pchar
    segment      = *pchar
     params       = param *( ";" param )
    param        = *( pchar | "/" )
     scheme       = 1*( ALPHA | DIGIT | "+" | "-" | "." )
    net_loc       = *( pchar | ";" | "?" )
    query        = *( uchar | reserved )
    fragment     = *( uchar | reserved )
     pchar        = uchar | ":" | "@" | "&" | "=" | "+"
    uchar        = unreserved | escape
    unreserved    = ALPHA | DIGIT | safe | extra | national
    escape       = "%" HEX HEX
    reserved      = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
    extra        = "!" | "*" | "'" | "(" | ")" | ","
    safe         = "$" | "-" | "_" | "."
    unsafe       = CTL | SP | <"> | "#" | "%" | "<" | ">"
    national      = <any OCTET excluding ALPHA, DIGIT,
                reserved, extra, safe, and unsafe>
    權威的URL語法及語義信息請參見RFC1738[4]和RFC1808[9]。
********************
 注意：fragment和query標識符在這時沒有明確的定義，需要到RTSP服務器上解釋。
 rtsp前綴要求使用可靠協議（在Internet上指TCP協議）發出命令，而rtspu前綴則說明使用不可靠協議（在Internet指UDP協議）。
 如是端口爲空或沒指定，則缺省爲554端口。語義如下：擁有被請求的資源的服務器主機通過監聽TCP連接(rtsp方案)或主機上相應端口的UDP包(rtspu方案)，來控制所標記的資源。資源的請求URI是rtsp_URL。
 應儘可能避免在URL中直接使用IP地址。（請參考RFC1924）
 一個表示或者流是通過基於文本的媒體標記來標識的，此媒體標記使用URLs (RFC 1738 [20])中的字符集和轉義規則[H3.2]。URLs可以指向一個流或者一個流的集合，即是說，一個表示。請求視情況可以指向一個完整的表示或者表示中的單個流，見第十章。注意，某些請求方法只能用於流，而不能用於表示，反之亦然。
 例如：RTSP URL:
rtsp://media.example.com:554/twister/audiotrack
 標識了表示"twister"中的音頻流，它可以通過發送基於TCP連接的RTSP請求至主機media.example.com的554端口進行控制。
 也可以是這樣RTSP URL：
rtsp://media.example.com:554/twister
 標識了表示"twister"，它可能是由音頻和視頻流組成的。
 這裏並沒有暗示相關流URL的標準。表示的結構關係和各個流的URL在表示描述中定義。如一個表示描述可能將一個流命名爲a.mov，而將整個表示命名爲b.mov。
 RTSP URL的路徑組成對客戶端是不透明的，也不暗含任何服務器的具體文件系統結構。
簡單替換URL中的前綴後，表示描述同樣可以用於非RTSP媒體控制協議。
3.3 會議標識
會議標識採用URI標準編碼方法（即是說，LWS被轉義爲%）編碼，並對RTSP不透明。它們能包含任意字節值。【必須】保證會議標識在全局中的唯一性。在H.323中，將用到會議的標識值。
 conference-id = 1*xchar
 會議標識用以允許RTSP會話從媒體服務器參與的多媒體會議中獲取參數。這些會議是用該規範之外的協議創建的，例如H.323 [13] 或 SIP [12]協議。這樣就不用RTSP客戶端顯式地提供傳輸信息，而改用其他方式代替，例如，客戶端要求媒體服務器使用會議描述中的值。
 3.4 會話標識
 會話標識符是非直讀 的任意長度的字符串。線性空格必須是URL轉義的。會話標識符【必須】隨機產生並且【必須】至少由8個字節組成，以保證其難以被猜出。（詳見16章）
 session-id = 1*( ALPHA | DIGIT | safe )
 3.5 SMPTE 相對時間戳
 SMPTE 相對時間戳表示相對於開始剪輯的時間。相對時間戳以SMPTE時間編碼形式表示以保證幀級的訪問精度。時間編碼的格式爲：時：分：秒：幀.子幀，並以剪輯開始爲起點。缺省的SMPTE格式爲"SMPTE 30 drop"格式，其幀率是29.97幀每秒。也可能可通過選擇使用不同"SMPTE time"來選擇其他SMPTE編碼格式（如"SMPTE 25"）。幀域（"frames" field）的時間值在0到29之間。30幀每秒和29.97幀每秒的不同之處在於後者除了整十分鐘外的每分鐘都要丟掉頭兩個幀（00和01）。忽略幀值爲0的幀，子幀以百分之一幀爲單位。
    smpte-range  =   smpte-type "=" smpte-time "-" [ smpte-time ]
   smpte-type   =   "smpte" | "smpte-30-drop" | "smpte-25"
                                   ; other timecodes may be added
   smpte-time   =   1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ]
                       [ "." 1*2DIGIT ]
 例如：
 smpte=10:12:33:20-
 smpte=10:07:33-
 smpte=10:07:00-10:07:33:05.01
 smpte-25=10:07:00-10:07:33:05.01
 3.6正常播放時間
 正常播放時間(NPT)指示流相對於表示(presentation)開始的位置。時間戳由一個十進制小數組成，以秒爲單位，小數點左邊可以是秒或者以小時：分：秒的形式表示。小數點右邊表示秒的小數部分。
表示開始時對應0.0秒。負值沒有意義。特殊的常數"now"定義爲現場事件當前瞬間。它只能用於現場事件。
 在DSM -CC中，正常播放時間（NPT）是這樣定義的："直觀地講，NPT是用戶和程序聯繫的時鐘。它經常在VCR上數字顯示出來。當處於普通播放模式 (倍速= 1)時，NPT正常前進。當處於快進掃描模式時(倍速爲大於1的正數)，NPT快速前進。當處於反向掃描模式(倍速小於-1)時，NPT快速後退。當處於暫停模式時，NPT停止。NPT（邏輯上）等同於SMPTE時間編碼。
 npt-range= ( npt-time "-" [ npt-time ] ) | ( "-" npt-time )
npt-time = "now" | npt-sec | npt-hhmmss
npt-sec= 1*DIGIT [ "." *DIGIT ]
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]
npt-hh = 1*DIGIT ; any positive number
npt-mm = 1*2DIGIT; 0-59
npt-ss = 1*2DIGIT; 0-59
 例如：
 npt=123.45-125
 npt=12:05:35.3-
 npt=now-
 
    語法遵循ISO 8601規則。npt-sec標誌法便於自動生成， ntp-hhmmss標誌法便於人閱讀。"now"常數允許客戶端請求接收實時反饋而不是存儲或者延時的版本。因爲對於這種情況而言，絕對時間和0時間都不適用。
 3.7 絕對時間
 絕對時間表示爲ISO 8601時間戳，使用UTC(GMT)時間。秒的小數部分也可能會出現。
 utc-range= "clock" "=" utc-time "-" [ utc-time ]
utc-time = utc-date "T" utc-time "Z"
utc-date = 8DIGIT; < YYYYMMDD >
utc-time = 6DIGIT [ "." fraction ] ; < HHMMSS.fraction >
比如，1996年11月8日14點37分20.25秒
UTC時間爲：
 19961108T143720.25Z
 3.8 選擇標籤
選項標籤是用來指示RTSP新選項的唯一標識符。這些標籤用於要求(Require)(12.32節)和代理要求(Proxy Require)(12.27節)頭部域中。
 語法：
 option-tag = 1*xchar
 要建立新的RTSP選項，可以在選項前加入反轉域名的前綴（如：對於能訪問到foo.com則com.foo.mynewfeature" 是個合適的名字），或者在英特網權威數字分派委員會註冊（IANA）新的選項。
 3.8.1 用IANA註冊新的選項標籤
 當註冊新RTSP選項標籤的時候，應該提供以下信息：
     *選項的名字和描述。名字長度不限，但是應該不多於20字符。名字【必須不】包含任何空格，控制符或句點。
     *指出誰擁有選項的改變控制權（例如，IETF，國際標準化組織，國際電信聯盟-T，其他的國際標準化體，一個團體，一個公司，或者一組公司）。
     *描述更爲詳細的參考文檔（如果有），比如（按推薦程度排序），RFC，公開發表的論文，專利文檔，技術報告，源代碼，或者計算機手冊。
     *對於私有的選項，需要給出聯繫地址（郵政地址及電子郵箱）。
 4 RTSP消息
     RTSP是基於文本的協議，採用ISO 10646 字符集和UTF-8編碼方案。每行結束處行以CRLF標記，但接收方需有能力將CR和LF自行解釋成行終止符。
 基於文本的協議使得易於以自描述方式增加可選參數。由於參數的數量和命令出現的頻率較低，處理效率不予考慮。如定義得較仔細，文本協議很容易以腳本語言（如：Tcl、Visual Basic與Perl）實現研究原型。
 10646字符集避免了繁瑣的字符集切換，但若應用程序使用US-ASCII字符集，它將不可見 。RTCP也採用這種編碼方案。ISO 8859-1通過在高位填充0，直接轉成Unicode。標誌位不爲0的ISO 8859-1字符被表示如100001x 10xxxxxx.。(見 RFC 2279 [21])
 RTSP信息可通過任何8-bit clean 的低層傳輸協議傳送。
 請求包括方法、方法作用於其上的對象和進一步描述方法的參數。除非另外說明，否則方法是冪等 的。方法還被設計爲在服務器端只需要少量或不需要狀態維護。
 4.1 消息類型
 見[H4.1]
********************
[H4.1]：
 RTSP消息由客戶端到服務器的請求和由服務器到客戶端的響應組成。
 RTSP -message = Request | Response            ; RTSP /1.0 messages
 請求（Request）和響應（Response）消息都使用RFC822中實體傳輸部分規定（作爲消息中的有效載荷）的消息格式。兩者的消息都可能包括一起始行，一個或多個頭部域（headers）、一行表示頭部域結束的空行（即CRLF前沒有內容的行），和一個消息主體（message-body, 可選）。
 generic-message = start-line *message-header
CRLF
[ message-body ]
 start-line = Request-Line | Status-Line
 爲了健壯性考慮，服務器應該忽略任何在期望收到請求行時收到的空行。換句話說，如果服務器正在讀協議流，在一個消息開始時如果首先收到了CRLF，這個CRLF符應被忽略。
 ********************
 4.2 消息頭部
 見[H4.2]。
********************
[H4.2]：
     RTSP頭部域，包括主頭部（General-Header,4.3節）、請求頭部（Request-Header ,5.2節）、響應頭部（Response-Header ,6.2節）及實體頭部（Entity-Header,7.1節），都遵照RFC822-3.1節[7]給出的通用格式定義。每個頭部域由後緊跟冒號的名字，單空格（SP），字符及域值組成。域名是大小寫敏感的。雖然不提倡，頭部域還是可以擴展成多行使用，只要這些行以一個以上的SP或HT開頭就行。
 RTSP-header            = field-name ":" [ field-value ] CRLF
 field-name            = token
field-value            = *( field-content | LWS )
 field-content            = <the OCTETs make up the field-value
                and consisting of either *TEXT or combinations
                of token, tspecials, and quoted-string>
頭部域接收的順序並不重要，但良好的習慣是，先發送主頭部，然後是請求頭部或響應頭部，最後是實體頭部。
     當且僅當頭部域的全部域值都用逗號分隔的列表示時（即，#（值）），多個有相同域名的RTSP頭部域纔可以表示在一個消息裏。而且必須能在不改變消息語法的前提下，將併發的域值加到第一個值後面，之間用逗號分隔，最終能將多個頭部域結合成"域名：域值"對。
********************
4.3 消息主體
見[H4.3]。
********************
[H4.3]：
RTSP消息的消息主體（如果有）用來攜帶請求或響應的主體。僅在使用傳輸編碼(Transfer-Encoding)時消息主體和實體主體纔有所不同，這種情況在傳輸編碼頭部域中有詳細說明。（見[H14.40]）
 message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
 傳輸編碼必須能解釋所有保證傳輸安全和正確的應用程序的傳輸編碼。傳輸編碼是消息而不是實體的一個屬性，因此可以由任一應用程序隨着請求/響應鏈添加或者刪除。
 什麼時候允許消息帶消息體的規則在請求和響應兩種情況下有所不同。
 在請求中有無消息主體的標誌是是否包含內容長度或請求消息頭部域中的傳輸編碼頭部域。只有當請求方法允許有實體主體的時候才能在請求中包含消息主體。
 而對於響應消息來說，無論消息中是否存在消息主體都與請求方法和響應狀態編碼無關。所有響應頭部請求方法的消息都不能包含消息主體，儘管有時會因爲存在實體頭部域而使人產生誤解。所有1××（信息），204（無內容），304（未修改）響應都不包含消息主體。而其他響應則都包含主體，儘管其長度有可能長度爲零。
********************
 4.4 消息長度
 當信息體包含在信息中時，信息體長度由如下因素決定（按優先度排列）：
 1.       任何【必須不】包含消息體message body的響應消息（如1XX，204，及304響應），總是在頭域後的第一個空行後就結束，而不管實體頭部域是否出現在信息中。（注意：空行中只有CRLF。）
 2.       如果存在內容長度頭部域（Content-Length header field），它的值（單位爲byte）就表示消息體的長度。如果此頭部域沒有出現，則假設其值爲0。
 3.       通過服務器關閉連接。（關閉連接不能被用於指示請求主體（request body）的結束，因爲那樣將使服務器無法回送響應。）
 注意：RTSP目前並不支持HTTP/1.1"塊"傳輸編碼(見 [H3.6])，需要有內容頭部域。
 假如返回了長度適當的表示描述，服務器應該總是可以確定它的長度--即便它是動態產生，使得沒有必要採用塊傳輸編碼。如有實體，即使必須有內容長度，且長度沒顯式給出，上述規則也可確保行爲的合理性。
 5 普通頭部域
     除了Pragma、Transfer-Encoding 和 Upgrade頭部，其餘見[H4.5]
       general-header     =     Cache-Control     ; Section 12.8
                         |     Connection        ; Section 12.10
                         |     Date              ; Section 12.18
                         |     Via               ; Section 12.43
 6 請求
 從客戶端到服務器端或與之相反的請求消息，在消息首行中包括：應用於資源的方法、資源的標識符及所使用的協議。
 Request = Request-Line ; 6.1節
    *( general-header ; 5章
    | request-header ; 6.2節
    | entity-header ) ; 8.1節
    CRLF
    [ message-body ] ; 4.3節
 6.1 請求行
   請求行 = 方法空格請求-URI 空格 RTSP-版本 CRLF
    Method         =         "DESCRIBE"              ; Section 10.2
                  |         "ANNOUNCE"              ; Section 10.3
                  |         "GET_PARAMETER"         ; Section 10.8
                  |         "OPTIONS"               ; Section 10.1
                  |         "PAUSE"                 ; Section 10.6
                  |         "PLAY"                  ; Section 10.5
                  |         "RECORD"                ; Section 10.11
                  |         "REDIRECT"              ; Section 10.10
                  |         "SETUP"                 ; Section 10.4
                  |         "SET_PARAMETER"         ; Section 10.9
                  |         "TEARDOWN"              ; Section 10.7
                  |         extension-method
   extension-method = token
  Request-URI = "*" | absolute_URI
   RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT
 6.2 請求頭部域
   request-header  =          Accept                   ; Section 12.1
                  |          Accept-Encoding          ; Section 12.2
                  |          Accept-Language          ; Section 12.3
                  |          Authorization            ; Section 12.5
                  |          From                     ; Section 12.20
                  |          If-Modified-Since        ; Section 12.23
                  |          Range                    ; Section 12.29
                  |          Referer                  ; Section 12.30
                  |          User-Agent               ; Section 12.41
 注意：相對於HTTP/1.1[2]而言，RTSP請求總是包含絕對URL（包括rtsp或rtspu前綴，主機，端口號）而不僅僅是絕對路徑。
 HTTP/1.1 要求服務器能夠理解絕對URL, 但還是期望客戶端使用主機請求頭部。這樣做完全是爲了向後兼容HTTP/1.0服務器端，因此在RTSP中不需要這樣做。
 在請求-URI中星號"*"表示此請求不用於其他資源，只用於服務器本身，且只能在該方法對於資源並非必要方法時才能使用。如下面的例子：
 OPTIONS * RTSP/1.0。
 7 響應
     使用 [H6] 的規則，只是其中的HTTP版本號要被替換成RTSP版本號。還有，RTSP增加了一些狀態碼，也棄用了一些HTTP狀態碼。在表一中，對有效的響應碼和可用的方法進行了定義。
 在收到並解釋了一條請求消息後，接收方以一條RTSP響應消息作爲迴應。
      Response    =     Status-Line         ; Section 7.1
                 *(    general-header      ; Section 5
                 |     response-header     ; Section 7.1.2
                 |     entity-header )     ; Section 8.1
                       CRLF
                       [ message-body ]    ; Section 4.3
 
7.1 狀態行
    響應消息的第一行就是狀態行，它由協議版本、數字形式的狀態碼、與狀態碼對應的文本解釋依次組成，各元素間以空格（SP）分隔，除了結尾的CRLF外，不允許出現CR或LF符。
狀態行 = HTTP-版本空格狀態碼空格原因解釋 CRLF
7.1.1 狀態碼和原因解釋
狀態碼（Status-Code）由3位數字組成，表示請求是否被理解或被滿足。這些狀態碼的完整定義在第十一章。原因解釋（Reason-Phrase）是用簡短的文字來描述狀態碼產生的原因。狀態碼用來支持自動操作，原因解釋用來方便人的查看。客戶端不需要檢查或顯示原因解釋。
 狀態碼的第一位數字定義了響應的類別，後面兩位數字沒有具體分類。首位數字有5取值可能：
     *1xx：通知 - 已收到請求，繼續處理
   *2xx：成功 - 操作被成功接收和理解，並被接受
     *3xx：重定向 - 要完成請求必須進行進一步操作。
     *4xx：客戶端出錯 - 請求有語法錯誤或無法實現
     *5xx：服務器端出錯 - 服務器無法滿足合法的請求。
 HTTP/1.0的狀態碼、對應原因解釋在下面給出。下面的原因解釋只是建議採用，可用其他等價形式替換，而不會對協議造成影響。注意：RTSP採用了大多數HTTP/1.1 [2]狀態碼，並增加了一些形如x50的RTSP特有的狀態碼以避免與最新定義的HTTP狀態碼衝突。
    狀態碼  =     "100"      ; 繼續
                |     "200"      ; OK
                |     "201"      ; 已創建
                |     "250"      ; 存儲空間不足
                |     "300"      ; 有多個選項
                |     "301"      ; 被永久移除
                |     "302"      ; 被臨時移除
                |     "303"      ; 見其他
                |     "304"      ; 沒有修改
                |     "305"      ; 使用代理
                |     "400"      ; 錯誤的請求
                |     "401"      ; 未通過認證
                |     "402"      ; 需要付費
                |     "403"      ; 禁止
                |     "404"      ; 沒有找到
                |     "405"      ; 不允許該方法
                |     "406"      ; 不接受
                |     "407"      ; 代理需要認證
                |     "408"      ; 請求超時
                |     "410"      ; 不在服務器
                |     "411"      ; 需要長度
                |     "412"      ; 預處理失敗
                |     "413"      ; 請求實體過長
                |     "414"      ; 請求-URI過長
                |     "415"      ; 媒體類型不支持
                |     "451"      ; 不理解此參數
                |     "452"      ; 找不到會議
                |     "453"      ; 帶寬不足
                |     "454"      ; 找不到會話
                |     "455"      ; 此狀態下此方法無效
                |     "456"      ; 此頭部域對該資源無效
                |     "457"      ; 無效範圍
                |     "458"      ; 參數是隻讀的
                |     "459"      ; 不允許合控制
                |     "460"      ; 只允許合控制
                |     "461"      ; 傳輸方式不支持
                |     "462"      ; 無法到達目的地址
                |     "500"      ; 服務器內部錯誤
                |     "501"      ; 未實現
                |     "502"      ; 網關錯誤
                |     "503"      ; 無法得到服務
                |     "504"      ; 網關超時
                |     "505"      ; 不支持此RTSP版本
                |     "551"      ; 不支持選項
                |     擴展碼
    擴展碼 = 3位數字
    原因解釋 = *<文本, 包括 CR, LF>
 RTSP狀態碼是可擴展的。RTSP應用程序不被要求瞭解全部註冊的狀態碼，當然很明顯這種瞭解是被期望的。儘管如此，應用程序【必須】理解任何一個狀態碼的首位所標識的類別，將任何不理解的狀態碼等同爲那個類的x00狀態碼，只是【必須不】緩存無法識別 的響應。例如，如果客戶端收到一個無法識別的狀態碼431，可以安全地假定是請求出了問題，認爲其響應的狀態碼就是400。在這種情況下，用戶界面應當在把響應消息的實體顯示給用戶，因爲實體中可能包括一些人類可以識別的關於此非正常狀態的描述信息。
 代碼           原因
 100            繼續                   所有
 200            OK                    所有
201            已創建                 錄製
250            存儲空間不足           錄製
 300            有多個選項             所有
301            被永久移除             所有
302            被臨時移除             所有
303            見其他                 所有
305            使用代理               所有
 400            錯誤的請求             所有
401            未通過認證             所有
402            需要付費               所有
403            禁止                   所有
404            沒有找到               所有
405            不允許該方法           所有
406            不接受                 所有
407            代理需要認證           所有
408            請求超時               所有
410            不在服務器             所有
411            需要長度               所有
412            預處理失敗             DESCRIBE, SETUP
413            請求實體過長           所有
414            請求-URI過            所有
415            媒體類型不支持         所有
451            不理解此參數           SETUP
452            找不到會議             SETUP
453            帶寬不足               SETUP
454            找不到會話             所有
455            此狀態下不接受此方法   所有
456            此頭部域對該資源無效   所有
457            無效範圍               PLAY
458            參數是隻讀的           SET_PARAMETER
459            不允許合控制           所有
460            只允許合控制           所有
461            傳輸方式不支持         所有
462            無法到達目的地址       所有
 500            服務器內部錯誤         所有
501            未實現                 所有
502            網關錯誤               所有
503            無法得到服務           所有
504            網關超時               所有
505            不支持此RTSP版本      所有
551            不支持選項             所有
 表一: 狀態碼及適用RTSP方法
 7.1.2 響應頭部域
 響應頭部域使得請求接收方可以發送不能放在狀態行中的附加響應信息。這些頭部域提供服務器的信息，以及對請求-URI所指定資源進行進一步訪問信息。
    response-header  =     Location             ; Section 12.25
                    |     Proxy-Authenticate   ; Section 12.26
                    |     Public               ; Section 12.28
                    |     Retry-After          ; Section 12.31
                    |     Server               ; Section 12.36
                    |     Vary                 ; Section 12.42
                    |     WWW-Authenticate     ; Section 12.44
 響應頭部域名只有在與協議版本的變化結合起來後，才能進行可靠的擴展。儘管如此，響應頭部域語法中可能會加入新的或實驗性的頭部域--只要通訊各方能識別它是響應頭部域，其語法就可使用。而無法識別的頭部域都將被視爲實體頭部域。
 8 實體
 如不受請求方法或響應狀態碼限制，請求和響應消息可以傳送任何實體。實體由若干實體頭部域和一個實體主體組成，但有些響應僅包括實體頭部域。
 在本章中，根據誰發送實體、誰接收實體，用戶和服務器都可能指發送者或者接收者。
 8.1 實體頭部域
 實體頭部域定義了實體主體的可選元信息；如沒有實體主體，那些定義則是關於請求標識的資源的。
     entity-header       =    Allow               ; Section 12.4
                         |    Content-Base        ; Section 12.11
                         |    Content-Encoding    ; Section 12.12
                         |    Content-Language    ; Section 12.13
                         |    Content-Length      ; Section 12.14
                         |    Content-Location    ; Section 12.15
                         |    Content-Type        ; Section 12.16
                         |    Expires             ; Section 12.19
                         |    Last-Modified       ; Section 12.24
                         |    extension-header
     extension-header    =    message-header
 擴展頭部機制允許定義附加實體頭部域，而不用改變協議，但並不能假定接收者能識別這些附加域。不被識別的頭部域應被接收者忽略，而讓代理髮送。
 8.2 實體主體
 見[H7.2]及其全部子章節
 9 連接
     RTSP請求可以幾種不同方式傳送：
     *1、持久傳輸連接，用於多個請求-響應傳輸。
     *2、每個請求-響應傳輸對應一個連接。
    *3、無連接模式。
 傳輸連接類型由RTSP URI（見3.2節）來定義。"rtsp" 方案說明需要持續連接；而"rtspu"方案，則要求不建立連接就直接發送RTSP請求。
 和HTTP不同的是，RTSP允許媒體服務器給媒體用戶發送請求。然而，這僅在持久連接模式中才支持，否則媒體服務器沒有可靠途徑到達用戶。這也是通過防火牆從媒體服務器傳送請求到用戶的唯一辦法。
 9.1 管道
     支持持久連接或無連接的客戶端可能會使用"管道方式"傳送請求（即是說：發送多個請求而不需等待單個的響應）。服務器必須以和收到的請求同樣的順序發出響應。
 9.2 可靠性及確認
 接受方需要確認請求，除非請求是發給多播組。如沒有確認信息，發送者可在超過一個來回時間（RTT） 後重發同一信息。RTT在TCP中估計，初始值爲500 ms。一個實現可能會緩存最後所測量的RTT，作爲將來連接的初始值。
 如使用可靠傳輸協議來承載RTSP，則請求不允許重發，RTSP應用程序必須依賴低層傳輸協議來保證可靠性。
 如低層可靠傳輸協議（如TCP）和RTSP應用程序都重發請求，有可能每次丟包都導致兩次重傳。由於傳輸棧在第一次嘗試到達接收者以前不會發送應用層重傳，所以接收者並不能充分利用應用層重傳。若丟包由網絡阻塞引起，多個層上的的共同重發將使阻塞進一步惡化。
 如果RTSP被用在小RTT 網絡，使用標準的初始TCP RTT時間測量優化過程，像T/TCP (RFC 1644) [22]那樣，將是有益的。
 時間戳頭部（見章節12.38）被用來避免重傳後亂序的問題[23, p. 301]，以及迴避對Karn算法的依賴。
 每個請求都帶有一個序列號，位於CSeq頭部（見章節12.17），每發出一個單獨的請求，這個序列號就加一。如果由於缺少確認而重發一個請求，該請求必須攜帶原來的序列號（即是說，序列號不增加）。
 支持RTSP的系統必須支持通過TCP承載RTSP，然後也可以支持通過UDP承載。UDP和TCP的默認RTSP端口都是554.
 一定數量的發往同一個控制末端的包可以放進一個低層PDU或者封裝進一個TCP流裏。RTSP數據中間可以交叉插入RTP和RTCP包。和HTTP不同，一條RTSP消息只要包含載荷（payload），就必須包含內容長度頭部。否則，一個RTSP包通過最後一個消息頭部後的第一個空行馬上截止。
 10 方法定義 
    方法關鍵字表示將要用於請求-URL所指示的資源上的方法。方法是大小寫敏感的。將來可能會定義新的方法。方法名稱不應以$符號（數字24）開始，並且必須是一個關鍵字。所有的方法被列在表二上。
       方法               方向            對象       要求
      DESCRIBE          C->S             P,S        推薦
      ANNOUNCE          C->S, S->C       P,S        可選
      GET_PARAMETER     C->S, S->C       P,S        可選
      OPTIONS           C->S, S->C       P,S          必要
                                                    (S->C: 可選)
      PAUSE             C->S             P,S        推薦
      PLAY              C->S             P,S        必要
      RECORD            C->S             P,S        可選
      REDIRECT          S->C             P,S        可選
      SETUP             C->S             S          必要
      SET_PARAMETER     C->S, S->C       P,S        可選
      TEARDOWN          C->S             P,S        必要
     表二：RTSP方法一覽，它們的方向，以及它們用來操作的對象（P：表示； S：流）
 注意關於表二：PAUSE是推薦的，但是不強制要求一個實現了完整功能的服務器支持此方法，例如，對於直播節目。如果一個服務器不支持一個特定的方法，它必須返回"501 未實現"，同時客戶端不應該在此服務器上再次嘗試此方法。
 10.1 OPTIONS（可選項）
     它的行爲和[H9.2]所描述的相同。OPTIONS請求在任何時候都可能產生，例如：當一個客戶端準備嘗試一個非標準的請求時。它不影響服務器的狀態。
 例子：
      C->S:  OPTIONS * RTSP/1.0
            CSeq: 1
            Require: implicit-play
            Proxy-Require: gzipped-messages
 
     S->C:  RTSP/1.0 200 OK
            CSeq: 1
            Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
 注意：這些是有需要的虛構特性（有些人可能希望，我們不會有意忽略一個確實有用的特性，以便在這章得到有力的例子）。
 10.2 描述（DESCRIBE）
     DESCRIBE方法從服務器取得請求URL所標識的表示或者媒體對象的描述。它可能使用同意頭部（Accept header）來指出客戶端能理解的描述格式。服務器以所請求的資源的描述作爲迴應。DESCRIBE 回覆-響應對繼續了RTSP的媒體初始化階段。
 例子：
      C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
           CSeq: 312
           Accept: application/sdp, application/rtsl, application/mheg
 
     S->C: RTSP/1.0 200 OK
           CSeq: 312
           Date: 23 Jan 1997 15:35:06 GMT
           Content-Type: application/sdp
           Content-Length: 376
 
           v=0
           o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4                                    
           s=SDP Seminar
           i=A Seminar on the session description protocol
           u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
           [email protected] (Mark Handley)
           c=IN IP4 224.2.17.12/127
           t=2873397496 2873404696
           a=recvonly
           m=audio 3456 RTP/AVP 0
           m=video 2232 RTP/AVP 31
           m=whiteboard 32416 UDP WB
           a=orient:portrait
 DESCRIBE響應必須包含它所描述的資源的所有媒體初始化信息。如果媒體客戶端通過DESCRIBE以外的途徑從一個源得到了一個表示描述，並且此描述包含了媒體初始化參數的完整集合，那麼客戶端應該使用那些參數，並不再通過RTSP爲同一個媒體請求描述。
 另外，服務器不應該把DESCRIBE響應當作媒體重定向的手段。
 爲了使客戶端清楚無誤地知道什麼時候通過DESCRIBE去請求媒體初始化信息，什麼時候不需要，需要建立明確的章程。通過強制要求DESCRIBE響應包含媒體初始化包含它要描述的流集合的所有媒體初始化信息，以及不推薦的媒體間接DESCRIBE用法，我們避免了其他途徑可能帶來的死循環問題。
 媒體初始化是所有基於RTSP的系統的要求，但是RTSP規範沒有規定這必須通過DESCRIBE方法來實現。RTSP客戶端可以有三種途徑來得到初始化信息：
     *通過RTSP的DESCRIBE方法；
    *通過其他協議（HTTP、email 附件，等等）；
    *通過命令行或標準輸入（從而像瀏覽器輔助程序以SDP文件或其他媒體初始化格式啓動一樣工作 ）。
 爲方便實際交互，強烈建議在最小服務 中包括DESCRIBE方法，同時強烈建議最小客戶端 支持"輔助程序"這樣的功能來從標準輸入、命令行，及其他適合客戶端工作環境的途徑，來接受媒體初始化文件。
 10.3 通知（ANNOUNCE）
     ANNOUNCE方法有兩個目的：
 當從客戶端發往服務器端，ANNOUNCE向服務器端上傳請求URL所標識的表示或媒體對象的描述。當從服務器端發往客戶端，ANNOUNCE實時更新會話描述。
 當一個新的媒體流加入一個表示（例如：在一個現場表示活動期間）時，整個表示而不僅是所增加的部分，應該被重發，以便部分刪除。
 例子：
     C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0
           CSeq: 312
           Date: 23 Jan 1997 15:35:06 GMT
           Session: 47112344
           Content-Type: application/sdp
           Content-Length: 332
            v=0
           o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4
            s=SDP Seminar
           i=A Seminar on the session description protocol
           u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
           [email protected] (Mark Handley)
           c=IN IP4 224.2.17.12/127
           t=2873397496 2873404696
           a=recvonly
           m=audio 3456 RTP/AVP 0
           m=video 2232 RTP/AVP 31
      S->C: RTSP/1.0 200 OK
           CSeq: 312
 10.4 建立（SETUP）
     針對一個URI的SETUP詳細說明了將要用於流媒體的傳輸機制。客戶端可以針對已開始播放的流發出SETUP請求，來改變傳輸參數--服務器可能會同意。如果它不同意，它必須響應一個"455 此狀態下此方法無效"錯誤。爲便於穿透防火牆，客戶端必須指示傳輸參數，即便它不能影響這些參數，例如：服務器向哪裏放固定的多播地址的廣告。
 由於SETUP包含了所有的傳輸初始化信息，防火牆和其他中間網絡設備（那些需要這些信息的）就不用去解析相對費力些的DESCRIBE響應--DESCRIBE響應是爲媒體初始化預留的。
 傳輸頭部（Transport header）詳細列出了客戶端能接受的數據傳輸參數 ；響應中會包含服務器選定的傳輸參數。
     C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
          CSeq: 302
          Transport: RTP/AVP;unicast;client_port=4588-4589
     S->C: RTSP/1.0 200 OK
          CSeq: 302
          Date: 23 Jan 1997 15:35:06 GMT
          Session: 47112344
          Transport: RTP/AVP;unicast;
            client_port=4588-4589;server_port=6256-6257
 服務器在響應SETUP請求時生成會話標識。如果發往服務器的SETUP請求中包含了會話標識，服務器必須把這個SETUP請求綁定到已存在的會話中，或是返回"459 不允許合控制"錯誤。
 10.5 播放（PLAY）
   PLAY方法告訴服務器通過SETUP規定的機制開始傳輸數據。客戶端【必須不】在SETUP請求被明確確認爲成功以前發送PLAY請求。
 PLAY請求通過給出相對於正常播放時間的開始時間和結束時間，來給出播放範圍。從開始時間開始傳輸流數據直到到達結束時間。PLAY請求可以用管道（隊列）的形式；服務器【必須】按順序執行收到的PLAY請求。即：在前一個PLAY請求依然活動期間收到的PLAY請求，要延遲到前一個PLAY請求執行完畢後纔開始生效。 
 這允許了精確控制。
 例如：不管下面例子中的兩個PLAY請求的到達間隔多短，服務器將先從第10秒播放到第15秒，然後馬上繼以20到25秒，再從第30秒放到結束。
     C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
           CSeq: 835
           Session: 12345678
           Range: npt=10-15
     C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
           CSeq: 836
           Session: 12345678
           Range: npt=20-25
    C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
           CSeq: 837
           Session: 12345678
           Range: npt=30-
   更多例子請見關於PAUSE的敘述。
沒有範圍頭部（Range header）的PLAY請求是合法的。這表示從流的開始處播放，除非流被暫停。如果流被PAUSE暫停，繼續流傳輸時從暫停點開始。如果流正在播放，這種PLAY請求不會引起任何動作，客戶端可以用它來測試服務器是否在直播。
範圍頭部也可能包含時間參數。這個參數給出回放開始的UTC時間 。如果消息是在所指定的時間之後收到的，回放就立即從當前開始。時間參數可以被用於幫助同步從不同源得來的流。
對於一個按需點播的流，服務器以將實際回放的範圍迴應。如果媒體源要求把所請求的範圍轉換爲有效的幀範圍，這將有可能和所請求的範圍不同 。如果請求中沒有指定範圍，在迴應中返回當前位置。迴應中範圍的單位和請求一致。
播放完所需範圍以後，表示將自動暫停，如同收到了PAUSE請求一樣。
下面的例子從表示的0:10:20（SMPTE時間碼）處開始播放，直到剪輯結束。回放動作從1997年1月23日15:36開始。
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0
           CSeq: 833
           Session: 12345678
           Range: smpte=0:10:20-;time=19970123T153600Z
S->C: RTSP/1.0 200 OK
           CSeq: 833
           Date: 23 Jan 1997 15:35:06 GMT
           Range: smpte=0:10:22-;time=19970123T153600Z
爲回放一個現場表示的錄像，使用時鐘單位比較理想：
C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0
           CSeq: 835
           Session: 12345678
           Range: clock=19961108T142300Z-19961108T143520Z
S->C: RTSP/1.0 200 OK
           CSeq: 835
           Date: 23 Jan 1997 15:35:06 GMT
只支持回放的服務器【必須】支持npt時間格式，【可能】支持時鐘格式、smpte格式。
10.6 暫停（PAUSE）
PAUSE請求使得流傳輸被臨時暫停（中斷）。如果請求URL指向一個流，僅該流的回放和錄製會被中斷。例如：對於音頻，這相當於靜音 。如果請求URL指向一個表示或者一組流，該表示或該組流中所有正在活動的流的傳輸都被中斷。繼續回放或錄製後，各個多媒體軌【必須】進行同步。所有服務器資源被保留--儘管服務器【可能】會根據SETUP消息中會話頭部（Session header）裏的超時（timeout）參數，在暫停一段時間後關閉會話並釋放資源。
 例子：
 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 834
           Session: 12345678
 
     S->C: RTSP/1.0 200 OK
           CSeq: 834
           Date: 23 Jan 1997 15:35:06 GMT
 PAUSE請求可能包含一個範圍頭部來指示從什麼時候起開始中斷流或者表示。我們把這個點叫做"暫停點"。該頭部包含的必須是一個精確的值而不是一個範圍。流的正常播放時間被設爲暫停點。服務器遇到第一個包含此暫停點的當前未決的PLAY請求時，pause請求 生效。如果如果範圍頭部指示的時間範圍在所有當前未決的PLAY請求的範圍之外，返回一個"457 無效範圍"錯誤。如果一個媒體單元（如音頻或視頻的一個幀）正好從暫停點開始表示，將不被播放或錄製。如果沒有範圍頭部，則流傳輸從收到該消息的第一時間起暫停，暫停點被設置爲當前的正常播放時間。
 PAUSE請求丟棄所有列隊等候中的PLAY請求。但是【必須】維護媒體流的暫停點。下一個沒有範圍頭部的PLAY請求將從該暫停點繼續播放。
 例如：如果服務器有範圍從10到15和從20到29的兩個未決play請求，之後收到一個要求在NTP 21處暫停的pause請求，它將開始播放第二個範圍並在NPT 21處停止。如果pause請求是在NPT 12處暫停，而服務器正在把第一個請求播放到NPT 13處，服務器馬上暫停。如果pause請求在NPT 16處暫停，服務器將在播放完第一個play請求後停止並丟棄第二個play請求。
 另一個例子：如果服務器收到了要求先播放範圍10到15，再播放13到20（即範圍有重疊）的兩個請求，位於NPT=14的PAUSE請求將在服務器播放第一個範圍時起作用，並使第二個PLAY請求被忽略--假設PAUSE請求在服務器開始播放第二個重疊的範圍之前到達。不管PAUSE請求何時到達，它使NPT被設置爲14。
 如果服務器已經開始發送範圍頭部所指示時間之後的數據，PLAY仍然從該時間點開始繼續，就如假設客戶端拋棄了那些處於時間點之後的數據一樣。這保證連續的暫停/播放循環間沒有間隙。
 10.7 斷開（TEARDOWN）
  TEARDOWN請求會停止所給URI的流傳輸，釋放與它相關的資源。如果所給的URI是這個表示的表示URI，任何與此會話相關的會話標識都將不再有效。除非所有傳輸參數都在會話描述中定義了，否則在再次播放之前必鬚髮送SETUP請求。
 例子：
     C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 892
           Session: 12345678
     S->C: RTSP/1.0 200 OK
           CSeq: 892
 10.8 獲取參數（GET_PARAMETER）
    GET_PARAMETER請求用於獲取URI所標識的一個表示或者流的參數的值。回覆和響應的內容被留給具體實現。沒有實體的GET_PARAMETER可能被用於測試客戶端或者服務器端是否現場直播（"ping"）。
 例子：
 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 431
           Content-Type: text/parameters
           Session: 12345678
           Content-Length: 15
            packets_received
           jitter
 C->S: RTSP/1.0 200 OK
           CSeq: 431
           Content-Length: 46
           Content-Type: text/parameters
            packets_received: 10
           jitter: 0.3838
 "text/parameters"只是一個用於示範的參數類型。這個方法被有意地定義得比較鬆散，意在通過將來的實踐來定義迴應內容和響應內容。
 10.9 設置參數（SET_PARAMETER）
    該方法用來請求設置URI對應的表示或者流的參數的值。
 一個請求【應該】只包含一個參數，以便客戶端知道爲什麼一個特定的請求會失敗。如果請求包含多個參數，服務器【必須】僅在所有參數都能成功設置時纔去做所請求的動作 。服務器【必須】允許同一個參數被重複設定爲同一個值，但是它【可能】不同意改變參數的值。
 注意：媒體流的傳輸參數【必須】只通過SETUP命令來設置。
 把傳輸參數的設定嚴格限制在SETUP是爲了利於通過防火牆。
參數被劃分爲細粒度的形式，以便可給出更有意義的錯誤說明。 儘管如此，當需要原子設置操作 時，允許一次設置多個參數還是有意義的。想象一下這裏的設備控制：除非攝像頭能實時調整到合適的角度，否則客戶不想讓攝像頭拍特寫。
 例子：
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 421
           Content-length: 20
           Content-type: text/parameters
           barparam: barstuff
 S->C: RTSP/1.0 451 Invalid Parameter
           CSeq: 421
           Content-length: 10
           Content-type: text/parameters
            barparam
 "text/parameters"只是一個用於示範的參數類型。這個方法被有意地定義得比較鬆散，意在通過將來的實踐來定義迴應內容和響應內容。
10.10 重定向（REDIRECT）
    REDIRECT請求用於通知客戶端：必須連接到另一個服務器地址。它包含一個強制的地址（Location）頭部，該頭部指示客戶端該向哪個URL發送請求。它可能包含範圍（Range）參數，該參數指示重定向何時生效。如果客戶端想要轉向所指示的URI以繼續發送或接受媒體，客戶端【必須】向當前會話發送一個TEARDOWNQ請求，併爲新會話向所指示的主機發送一個SETUP請求。
 下面這個請求的例子，把傳輸在給定播放時間 重定向到新服務器的下述URI:
 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 732
           Location: rtsp://bigserver.com:8001
           Range: clock=19960213T143205Z-
 10.11 錄製（RECORD）
   該方法根據表示描述，開始錄製一個範圍內的媒體數據。時間戳反映開始和結束時間（UTC）.如果沒給出時間範圍，就使用表示描述提供的開始及結束時間。如果會話已經開始，則立即開始錄製。
 服務器決定是在請求-URI還是其他URI來錄製數據。如果服務器不使用請求-URI，響應【應該】是201（已建立），幷包含一個實體-該實體描述了請求的狀態並給出新資源，還包含一個位置頭部（Location header）。
 一個支持錄製現場表示的服務器【必須】支持時鐘範圍（clock range）格式；smpte格式是沒有意義的。
 在此例子中，媒體服務器在之前被邀請進所指示的會議中。
 C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0
           CSeq: 954
           Session: 12345678
           Conference: 128.16.64.19/32492374
 10.12 嵌入（交織）的二進制數據
 一些防火牆設計和其他環境可能會迫使服務器交織插入RTSP方法和流數據。除非必要，否則應該避免這種交織，因爲它使客戶端和服務器的操作複雜化並強加了額外的負擔。交織的二進制數據【應該】只在RTSP通過TCP承載時使用。
像RTP包這樣的流數據被封裝爲這樣的形式：以ASCII碼的"$"符號（0x24）爲封裝標誌，後面是一個單字節信道標識符，然後緊跟一個網絡字節序的雙字節二進制整數值，該整數表示所封裝二進制數據的長度。再後面緊跟着沒有CRLF，但包含上層協議頭部的流數據。每個 $ 塊包含且僅包含一個上層協議數據單元，例如，一個RTP包。
 信道標識符在傳輸頭部（Transport header）通過參數交織（interleaved）定義(章節12.39)。
 當選擇RTP作爲應用層傳輸協議，TCP連接上的RTCP消息也被服務器交織處理。默認把RTCP包放在比RTP信道高的第一個可用信道上。客戶端【可能】會顯式地在另一信道上請求RTCP包。這通過在傳輸頭部（Transport header，章節12.39）的交織（interleaved）參數上給出兩個信道來實現。
 如果這種形式下有兩個或更多流被交織，就需要RTCP。同時，在網絡配置有要求時 ，這提供了用TCP控制連接來隧道式地傳輸RTP/RTCP包的便利方法，並在可能時用UDP傳輸它們。
 C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0
           CSeq: 2
           Transport: RTP/AVP/TCP;interleaved=0-1
 S->C: RTSP/1.0 200 OK
           CSeq: 2
           Date: 05 Jun 1997 18:57:18 GMT
           Transport: RTP/AVP/TCP;interleaved=0-1
            Session: 12345678
 C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0
           CSeq: 3
           Session: 12345678
 S->C: RTSP/1.0 200 OK
           CSeq: 3
           Session: 12345678
           Date: 05 Jun 1997 18:59:15 GMT
           RTP-Info: url=rtsp://foo.com/bar.file;
             seq=232433;rtptime=972948234
   S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
     S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
     S->C: $\001{2 byte length}{"length" bytes  RTCP packet}
 11 狀態碼定義
     當HTTP狀態碼適用時，重用HTTP狀態碼。這裏不再給出意義與HTTP相同的狀態碼。表一給出了哪個請求會返回哪個狀態碼的列表。
 11.1 成功 2xx
 11.1.1 250 存儲空間不足
     服務器在收到一個由於存儲空間不足而無法完全滿足的RECORD請求時，返回這個警告。如果可能，服務器應該使用範圍（Range）頭部來指示仍然能夠錄製的時間範圍。因爲服務器的其他進程可能會同時消耗存儲空間，客戶端應該僅把這當作一個估計值。
 11.2 重定向 3xx
  見[H10.3].
     在RTSP裏，重定向被用於平衡附在或者把流請求重定向到拓撲上距離客戶端更近的服務器。判斷拓撲距離遠近的機制不在本規範中給出。
 11.3 客戶端錯誤 4xx
 11.3.1 405 不允許該方法
     請求URI所指示的資源不允許使用當前方法所述的請求。響應【必須】包含一個允許（Allow）頭部，該頭部包含一個對於當前所請求的資源有效的方法的列表。該當請求試圖使用在SETUP期間沒有列出的方法時，也可以用此狀態碼，例如：雖然傳輸（Transport）頭部的模式（mode）參數只列出了PLAY方法，但卻發送了一個RECORD請求。
 11.3.2 451 不理解此參數
    請求的接收方不支持請求所包含的一個或多個參數。
11.3.3 452 找不到會議
    媒體服務器找不到會議（Conference）頭部域所指示的會議
11.3.4 453 帶寬不足
    由於帶寬不足，請求被拒絕。這可能，例如，是由於資源預約失敗。
11.3.5 454 找不到
    會話（Session）頭部中的RTSP會話標識符丟失、失效，或已超時。
11.3.6 455 此狀態下此方法無效
 客戶端或服務器端無法在它的當前狀態下處理此請求。該響應【應該】包含一個允許（Allow）頭部以方便修正錯誤。
11.3.7 456 此頭部域對該資源無效
    服務器無法對請求頭部域做出反應。例如，當一個PLAY請求包含範圍（Range）頭部，但流不允許搜索。
11.3.8 457 無效範圍
 給出的範圍值越界，例如，超過了表示的末端。
11.3.9 458 參數是隻讀的
    SET_PARAMETER想要設置的參數只能讀取不能修改。
11.3.10 459 不允許合控制
     由於是一個合（表示）URL，所請求的方法不會被應用在該URL上。該方法可能可以用在單個的流URL上。
 11.3.11 460 只允許合控制
     由於不是一個合（表示）URL,所請求的方法不會被應用在該URL上。該方法可能可以用在表示URL上。
 11.3.12 461 傳輸方法不支持
    傳輸（Transport）域不包含能夠支持的傳輸協議。
 11.3.13 462 無法到達目的地址
     由於無法到達客戶端地址，無法建立傳輸通道。最可能的產生此錯誤的情況是，客戶端試圖把無效的目的地址參數放到傳輸（Transport）域。
 11.3.14 551 不支持該選項
    不支持需求（Require）或代理需求（Proxy-Require）域所給的某個選項。應當返回不被支持的頭部，列出不支持的選項。
 12 頭部域定義
     HTTP/1.1 [2]以及其他，現未列於此處的應該被接收方忽略的沒有確切定義的非標準頭部域。
 表三總結了RTSP使用的頭部域。"g"型別表示是請求和響應通用的請求頭部；"R"型別表示是請求頭部；"r"型別表示是響應頭部；"e"表示是實體頭部域。列欄中標記爲"req."的域【必須】被接收方針對某些特定的方法實現出來；而標記爲"opt."是可選的。注意：不是所有的標記爲"req."的域都得在每一個該類請求中發送。"req."意味着僅只客戶端（針對響應頭部）和服務器端（針對請求頭部）【必須】實現此頭部。最後一列列出了頭部域對哪些方法有意義；所有返回消息主體（message body）的方法都用"entity"標識。在本規範中，DESCRIBE 和GET_PARAMETER處於此列。
    頭部                型  別    支  持     方  法
   Accept               請求      可選.     entity
   Accept-Encoding      請求      可選      entity
   Accept-Language      請求      可選      all
   Allow                響應      可選      all
   Authorization        請求      可選      all
   Bandwidth            請求      可選      all
   Blocksize            請求      可選      all除了OPTIONS, TEARDOWN
   Cache-Control        通用      可選      SETUP
   Conference           請求      可選      SETUP
   Connection           通用      必須      all
   Content-Base         實體      可選      entity
   Content-Encoding     實體      必須      SET_PARAMETER
   Content-Encoding     實體      必須      DESCRIBE, ANNOUNCE
   Content-Language     實體      必須      DESCRIBE, ANNOUNCE
   Content-Length       實體      必須      SET_PARAMETER, ANNOUNCE
   Content-Length       實體      必須      entity
   Content-Location     實體      可選      entity
   Content-Type         實體      必須      SET_PARAMETER, ANNOUNCE
   Content-Type         響應      必須      entity
   CSeq                 通用      必須      all
   Date                 通用      可選      all
   Expires              實體      可選      DESCRIBE, ANNOUNCE
   From                 請求      可選      all
   If-Modified-Since    請求      可選      DESCRIBE, SETUP
   Last-Modified        實體      可選      entity
   Proxy-Authenticate
   Proxy-Require        請求      必須      all
   Public               響應      可選      all
   Range                請求      可選      PLAY, PAUSE, RECORD
   Range                響應      可選      PLAY, PAUSE, RECORD
   Referer              請求      可選      all
   Require              請求      必須      all
   Retry-After          響應      可選      all
   RTP-Info             響應      必須      PLAY
   Scale              請求響應    可選      PLAY, RECORD
   Session            請求響應    必須      all除了SETUP, OPTIONS
   Server               響應      可選      all
   Speed              請求響應    可選      PLAY
   Transport          請求響應    必須      SETUP
   Unsupported          響應      必須      all
   User-Agent           請求      可選      all
   Via                  通用      可選      all
   WWW-Authenticate     響應      可選      all
    RTSP頭部域一覽
 12.1 接受（Accept）
    接受（Accept）請求-頭部域可以用來描述確切的響應可接受的表示描述的內容類型。
 表述描述的等級（level）參數被適當地定義爲MIME類型註冊中的一部分，，而不是在這裏。
 見[H14.1]中的語法。
 例子：
     Accept: application/rtsl, application/sdp;level=2
 12.2 接受-編碼（Accept-Encoding）
     見[H14.3]
 12.3 接受-語言（Accept-Language）
     見[H14.4]。注意所描述的語言是應用於描述表述和原因短語，而不是媒體內容。
 12.4 允許（Allow）
     允許（Allow）響應頭部域列舉出請求-URI所指向的資源的所有支持的方法。該域的目的在於通知接收方，具體哪些方法對該資源有效。允許（Allow）頭部域必須在405（不允許該方法）中出現。
 用例：
     Allow: SETUP, PLAY, RECORD, SET_PARAMETER
 12.5 授權（Authorization）
     見[H14.8]
 12.6 帶寬（Bandwidth）
     帶寬（Bandwidth）請求頭部域用於描述可分配給客戶端的帶寬估計值，以單位爲bit/秒的正整數表示。在RTSP會話期間，客戶端可用帶寬可能會改變，例如，由於modem調整。
    Bandwidth = "Bandwidth" ":" 1*DIGIT
 例子：
     Bandwidth: 4000
 12.7 塊大小（Blocksize）
     該請求頭部域從客戶端發向媒體服務器，以詢問服務器某種媒體包的大小。這裏的包大小不包括低層包頭，如IP, UDP, 或 RTP。服務器可以隨意使用比所要求的包大小更小的包。服務器【可能】會以最接近此塊大小的媒體指定的包大小的整數倍作爲實際塊大小，在必要情況下也可能忽略此包大小而使用媒體指定的大小。塊大小【必須】是一個正十進制數字，以字節爲單位。如果值的語法不正確，服務器只返回416錯誤。
 12.8 緩存控制（Cache-Control）
     緩存控制（Cache-Control）通用頭部域用於給出所有緩存機制在請求/響應連接路徑上【必須】遵循的指令。
 因爲緩存指令可能對請求/響應連接路徑沿線的所有接收方都有用，所以緩存指令必須能通過代理或網關程序，不管它們對這些程序是否有意義。不太可能爲一個具體的緩存指定緩存指令。
 緩存控制（Cache-Control）應該只在SETUP請求和它的響應中給出。注意：緩存控制不像HTTP那樣管理着響應緩存，而是管理着SETUP請求所標識的流。除了DESCRIBE的響應外，RTSP請求的響應都是不緩存的。
    Cache-Control            =   "Cache-Control" ":" 1#cache-directive
   cache-directive          =   cache-request-directive
                            |   cache-response-directive
   cache-request-directive  =   "no-cache"
                            |   "max-stale"
                            |   "min-fresh"
                            |   "only-if-cached"
                            |   cache-extension
   cache-response-directive =   "public"
                            |   "private"
                            |   "no-cache"
                            |   "no-transform"
                            |   "must-revalidate"
                             |   "proxy-revalidate"
                            |   "max-age" "=" delta-seconds
                            |   cache-extension
   cache-extension          =   token [ "=" ( token | quoted-string ) ]
 不緩存（no-cache）：
    指示媒體流【必須不】在任何地方緩存。這允許原始服務器阻止緩存動作，哪怕是配置爲需要向客戶端返回“陳舊”（stale）響應的緩存。
 公有（public）：
    指示任何緩存都可緩存此媒體流。
 私有（private）：
    指示媒體流只供某單個用戶使用，共享緩存【必須不】緩存它。私有（非共享的）緩存可能會緩存該媒體流。
 非傳輸（no-transform）：
    可用於中間緩存（代理）轉換某種流的媒體類型。例如，代理可以轉換視頻格式以節省緩存空間，或減少慢速鏈接之間的傳輸。但當這種轉換被應用在特殊程序所用的流上時，可能會導致嚴重的運行問題。例如，醫學圖像的傳輸程序，科學數據分析程序，以及使用端對端鑑權 ，它們全依賴於接收到的流和原始實體的比特數據一一對應。因此，如果響應當中包含no-transform指令，中間緩衝或代理【必須不】改變流的編碼。和HTTP不同，RTSP在這一點上不提供局部轉換，例如，允許翻譯成另一種語言。
 僅若已緩存（only-if-cached）：
    某些情況下，如在延時非常嚴重的網絡環境中，客戶端可能想讓緩存只給出剛剛所緩存的媒體流，而不是從原始服務器接收它們。爲此客戶端可能會在請求中包含only-if-cached指令。如果它接收到了該指令，緩存【應該】要麼用已緩存的符合請求中其他要求的媒體流作爲應答，要麼響應一個504（網關超時）狀態。然而，如果一組緩存像有很好內部連通性的統一系統那樣被操控着，該請求【可能】會在這組緩存內發送。
 最大-陳舊（max-stale）：
    指示客戶端願意接收已經超過了有效生命期 （freshness lifetime）的媒體流。如果max-stale被賦值，那麼該客戶端願意接收超過了截止有效期（expiration time ），但超出值不超過該值所標示秒數的響應。如果max-stale沒有賦值，則客戶端願意接收任意年齡（age）的陳舊響應。
 最小-新鮮（min-fresh）：
    指示客戶端願意接收有效生命期（freshness lifetime）不少於當前年齡加上所給出秒數的媒體流。即客戶端想要響應在未來的至少所給的的秒數內仍然有效。
 必須-重驗證（must-revalidate）：
    當SETUP響應中出現的must-revalidate指令被緩存接收後，緩存【必須不】在向原始服務器重新驗證它前，使用過期的條目來響應下一個請求。即，如果僅基於原始服務器的過期時間，緩存的響應是過期的，則緩存必須每次都進行端對端的重驗證。
 12.9 會議（Conference）
     該請求頭部域建立了一個預建立的會議到RTSP流之間的邏輯連接。對於同一個RTSP會話，conference-id必須不能改變。
    Conference = "Conference" ":" conference-id Example:
     Conference: [email protected]%20Starr
 若conference-id無效，返回一個452（452 找不到會議）響應碼。
 12.10 連接（Connection）
     見[H14.10]
 12.11 內容-基礎（Content-Base）
    見[H14.11]
 12.12 內容-編碼（Content-Encoding）
     見[H14.12]
 12.13 內容-語言（Content-Language）
    見[H14.13]
 12.14 內容-長度（Content-Length）
     該域包含方法的內容的長度（即是說，從最後一個頭部後面的兩個CRLF之後）。和HTTP不同的是，它【必須】包含在所有頭部後有內容（content）的消息內。如果它丟失了，則假設其值爲0。根據[H14.14]給出解釋。
 12.15 內容-位置（Content-Location）
    見[H14.15]
 12.16 內容-類型（Content-Type）
     見[H14.18]。注意適用於RTSP的Content-Type傾向於限制在表示描述的慣例和parameter-value類型範圍內。
 12.17 應答序列號（CSeq）
     CSeq域指示了RTSP請求-響應對的序列號。該域【必須】出現在所有的請求和響應中。對於每一個包含了序列號的RTSP請求，它對應的響應會有相同的序列號。任何重傳的請求必須包含和原來一樣的序列號（即是說，重傳同一個請求時，序列號不增加）。
 12.18 日期（Data）
    見[H14.19]
 12.19 過期（Expires）
     Expires實體-頭部域給出了一個日期和時間，超過該時間的描述或者媒體流就不再被視爲有效的。具體涵義視方法而定：
 DESCRIBE響應：
    Expires頭部指明瞭描述的最後有效日期和時間。
 緩存（包括代理緩存和用戶程序緩存）一般不會返回過期的條目，除非先向原始服務器（或者緩存有該條目的有效拷貝的中間服務器）驗證過。關於過期模式的進一步解釋見章節13.
 出現Expires域並不暗示原始資源會在所述時間內，或之前、之後改變或被刪除。
 該格式是一種絕對時間，和[H3.3]中HTTP-date的相同，它【必須】是RFC1123-date格式：
   Expires = "Expires" ":" HTTP-date
 用例：
      Expires: Thu, 01 Dec 1994 16:00:00 GMT
    RTSP/1.0的客戶端和緩存【必須】把其他無效的數據格式尤其是"0"值，當作是過去產生的（也就是“已經過期的”）。
 要把一個響應標記爲“已經過期”，原始服務器應該使用等於時間頭部值的過期時間（Expires date）。要把響應標記爲“永不過期”，則原始服務器應該用從響應發送時起大約一年後的時間作爲過期時間。RTSP/1.0服務器不應該發送超過當前時間一年之久的過期時間。
 除非另有緩存-控制（Cache-Control）頭部域指示，否則對於一個默認是不可緩存的媒體流，如果出現了數據值爲將來某個時間的Expires頭部域，則爲指示該媒體流是可緩存的。
 12.20 來自（From）
    見[H14.22].
 12.21 主機（Host）
     RTSP不需要該HTTP請求頭部域。如果發送了該頭部，接收方應該無動作地直接忽略它。
12.22 如果-符合(If-Match)
   見[H14.25]。
無論是通過RTSP以外的途徑（例如HTTP）取得表示描述，還是服務器實現需要保證從DESCRIBE消息到SETUP消息時間段內描述（description）的完整性，該域在保障表示描述的完整性方面都尤其實用。
由於標識符是種不透明的標識符，因此並不侷限於某種特定的會話描述語言。 
12.23 如果-被修改-自從（If-Modified-Since）
    If-Modified-Since請求頭部域是用來和DESCRIBE和SETUP方法一起來形成條件判斷。如果被請求的變量從該域所指定的時間以來沒有被修改過，則服務器不會返回描述（DESCRIBE）或流不會被建立（SETUP）。作爲代替，會返回一個沒有任何消息體的304（沒有修改）響應。
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
該域的一個例子：
     If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
12.24 最後-修改（Last-Modified）
    Last-Modified頭部域指示原始服務器認爲表示描述或媒體流最後被修改的日期和時間。見[H14.29]。對於DESCRIBE或ANNOUNCE方法，該頭部域指示最後修改描述的日期和時間，對於SETUP則是修改媒體流的日期和時間。
12.25 位置（Location）
   見[H14.30]。
12.26 代理-鑑權（Proxy-Authenticate）
    見[H14.33]。
12.27 代理-要求（Proxy-Require）
    Proxy-Require頭部是用於指出代理【必須】支持的代理-敏感的特性。任何代理不支持的Proxy-Require頭部特性【必須】由代理向客戶端作出否定確認，如果它不支持的話。服務器應該和處理Require域一樣地處理該域。
更多該消息的機制和用例的細節見12.32節。
12.28 公佈（Public）
    見[H14.35]。
12.29 範圍（Range）
    該請求及響應頭部域定義了一個時間範圍。該範圍可用多種單位給出。該規範定義了smpte (3.5節), npt (3.6節), 和 clock (3.7節) 範圍單位。在RTSP中，字節範圍[H14.36.1] 是沒有意義的且【必須不】使用。頭部也可能包含UTC形式的時間參數，指出操作將在什麼時候啓動。支持範圍頭部的服務器【必須】理解NPT範圍格式，且【應該】理解SMPTE範圍格式。範圍響應頭部指出實際播放或錄製的時間範圍。如果範圍頭部用無法理解的時間格式給出，接收方應該返回"501 未實現"。
範圍是個半開區間，包括下邊界點，但不包括上邊界點。換句話說，一個a-b範圍精確地從時間a開始，但是b之前停止。只有如視頻或音頻幀這樣的媒體單元的開始時間是相關的 。例如，假設視頻是每40毫秒生成一幀。範圍10.0-10.1將包括從10.0或稍後開始的視頻幀，也會包括10.08開始的視頻幀--儘管它的持續期跨過了範圍區間。換句話說，範圍10.0-10.08，將把10.08的幀排除在外。
  Range            = "Range" ":" 1\#ranges-說明符
                      [ ";" "time" "=" utc-time ]
   ranges-說明符 = npt-range | utc-range | smpte-range
示例：
     Range: clock=19960213T143205Z-;time=19970123T143720Z
該符號的使用類似於HTTP/1.1 [2] byte-range頭部。這允許客戶端從媒體對象中選取剪輯，和從給定時間點播放到末尾，以及從當前位置播放到給定時間點。可以把開始回放的時間排到將來的任何時間，儘管服務器可能會拒絕爲額外的空閒期保持服務器資源。
12.30 提交方（Referer）
    見[H14.37]。指提及表示描述的URL，典型地是從HTTP中取得。
12.31 重試-自從（Retry-After）
    見[H14.38]
12.32 要求（Require）
    要求頭部被客戶端用於向服務器詢問其能夠或不能夠支持的選項。服務器【必須】使用不支持（Unsupported）頭部來響應該頭部，以對不支持的選項作出否定確認。
這意在確保客戶端-服務器交互將在所有選項頭能被雙方理解的情況下無延遲地進行，並僅在不能理解選項時（如上文情況）降低速度。對於一對配合得很好的客戶端-服務器，交互將進行得很快，節約了協商機制經常需要的來回時間。另外，這也消除了當客戶端需要服務器無法理解的特性時產生的不明確性。
   Require =   "Require" ":"  1#選項-標籤
   示例:
     C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
             CSeq: 302
             Require: funky-feature
             Funky-Parameter: funkystuff
     S->C:   RTSP/1.0 551 Option not supported
             CSeq: 302
             Unsupported: funky-feature
     C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
             CSeq: 303
     S->C:   RTSP/1.0 200 OK
             CSeq: 303
在該示例中，"funky-feature"是向客戶端指示需要虛構的Funky-Parameter域的特性標籤。"funky-feature"和Funky-parameter之間的關係不通過RTSP交互來溝通，因爲此關係是"funky-feature"的不變的屬性，因此不應該在每次RTSP交互中都傳輸。
代理和其他中間設備【應該】忽略該域中不理解的特性。如果有需要中間設備支持的特殊擴展，此擴展應該用代理-要求（Proxy-Require）域（見12.27節）標籤代替。
12.33 RTP-信息（RTP-info）
    該域用於設定PLAY響應中的RTP相關參數。
   url：
指示後面的RTP參數跟哪個流UTL相關聯。
   seq：
指示流的第一個包的序列號。這使得客戶端在搜索 時方便地處理包。客戶端使用該值來區分搜索位置前生成的包和搜索位置後生成的包。
   rtptime：
指示和Range響應頭部的時間值對應的RTP時間戳。（注意：對於合控制，某些特定的流可能在返回或暗含的Range時間內實際上不產生包。因此，無法保證用seq指示序列號的包實際上含有用rtptime指示的時間戳。）客戶端用此值來實現從RTP時間到NPT的映射計算。
從RTP時間戳映射到NTP時間戳（時鐘時間）可以藉助RTCP。但是，該信息還不足以完成從RTP時間戳到NTP的映射 。此外，爲了保證可以在必要的時候（啓動後立即或搜索後）獲得該信息，並且可靠地傳輸，該映射被置於RTSP控制信道內。
爲了糾正較長的、不間斷的表示的偏移，RTSP客戶端還要額外地進行從NPT到NPT的映射，使用初始RTCP發送方報告來實現此映射，並用後續的報告來檢查相對映射的偏移。
 語法：
    RTP-Info        = "RTP-Info" ":" 1#stream-url 1*parameter
   stream-url      = "url" "=" url
   parameter       = ";" "seq" "=" 1*DIGIT
                   | ";" "rtptime" "=" 1*DIGIT
 例子：
     RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102,
               url=rtsp://foo.com/bar.avi/streamid=1;seq=30211
 12.34 倍速（Scale）
     爲1的倍速值表示和正常播放速度一樣的播放、錄製速度。如果不是1，該值表示相對正常播放速度的比值。例如，比值2表示比正常播放速度快兩倍（快進）；而比值0.5表示只有正常播放速度的一半。也就是說，比值2使正常播放時間的時鐘頻率增加了兩倍。在時鐘時間的每一秒內，放了兩秒的內容。負值表示反方向。
 除非Speed參數另有要求，否則數據速率【應該】不被改變。倍速改變的實現依賴於服務器和媒體類型。對於視頻，服務器可能，例如，只傳送關鍵幀或者所選的關鍵幀。對於音頻，可能在保留完整音頻的前提下調整時間倍速，或者作爲次選，傳輸音頻的小片段。
 服務器應該試着估計播放速率，但可能把倍速值限制在自己支持的範圍內。響應【必須】包含服務器實際選擇的倍速值。
 如果請求中包含Range參數，新的倍速值將影響此時間。
    Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]
 以相對正常的3.5倍的速度快退的例子：
      Scale: -3.5
 12.35 速度（Speed）
    該請求頭部要求服務器以特定的速度向客戶端發送數據，根據服務器的能力和意願去用給定的速度來提供媒體流。服務器端對它的實現是【可選的】。默認值是流本身的比特率。
 該參數值以十進制小數的一個比率給出，例如，2.0說明數據被以正常的兩倍的速度傳輸。Speed值爲0是不允許的。如果請求中包含Range參數，則新的速度值將影響此時間。
    Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ]
    例子:
     Speed: 2.5
 該域的使用會改變數據傳輸所用的帶寬。它可以用在特殊的環境中，如需要高速或低速預覽表示時。開發者應該記住會話所用帶寬的協商可能會預先進行（通過RTSP以外的途徑），因此有必要重新協商。用UDP傳輸數據時，高度推薦使用如RTCP這樣的方式來監視丟包率。
12.36 服務器（Server）
     見[H14.39]
12.37 會話
    該請求和響應頭部域標識出一個根據表示URL，由媒體服務器的SETUP響應開始，由TEARDOWN終止的會話。會話標識由媒體服務器給出（見3.4節）。一旦客戶端收到一個會話標識，它【必須】對每個與該會話關聯的請求都返回該標識。如果服務器有其他能唯一標識出一個會話的途徑，如動態產生的URL，它並不一定要建立一個會話標識。
Session  = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ]
超時（timeout）參數只允許出現在響應頭部。服務器用它向客戶端指示，服務器打算在由於缺少反饋信息（見章節A）而關閉會話前等RTSP命令等多久。timeout的單位是秒，默認值爲60秒（1分鐘）。
 注意：會話標識把橫跨傳輸會話或連接的RTSP會話標識出來。一個RTSP會話可能會發送對應多個RTSP URL的控制消息。因此，客戶端可以用同一個會話控制一個表示中的多個流，只要這些流來自於同一個服務器。（見章節14的例子）。但是，同一個客戶端對於同一個URL的多個“用戶”【必須】使用不同的會話標識。
 區分來自於同一個客戶端針對同一個URL的不同傳輸請求時需要會話標識。
 如果會話標識是非法的，則返回454響應（找不到會話）。
12.38 時間戳（Timestamp）
  timestamp通用頭部描述客戶端何時向服務器發了請求。時間戳的值僅對客戶端有意義且可使用任何時間間隔單位。服務器【必須】回顯同一個值，且【可能】加上一些小數點後的數字來表示從收到請求後過了多少秒--如果它有相關精確信息的話。時間戳被客戶端用以計算到服務器的來回時間，以便爲重傳調整超時時間。
    Timestamp  = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
   delay      =  *(DIGIT) [ "." *(DIGIT) ]
12.39 傳輸（Transport）
    該請求頭部指示要用哪個傳輸協議，並配置如目的地址、壓縮、多播時的time-to-live和每個流的目的端口號這類參數。它設置那些表示描述沒有給定的值。
傳輸是用逗號分隔的，按優先級排序。參數可能被加到每個傳輸上，之間用分號隔開。
傳輸頭部【可能】也會被用於改變一些傳輸參數。服務器【可能】會拒絕改變已存在的流的參數。
 服務器【可能】會返回一個傳輸響應頭部以迴應性地指出實際選取的參數。
 傳輸請求頭部域可能包含客戶端可以接受的傳輸選項清單。此種情況下，服務器【必須】返回實際選定的某一個選項。
 傳輸說明清單的語法是：
     transport/profile/lower-transport.
 低層傳輸參數的默認值是視上層而定的。對於RTP/AVT，默認是UDP.
 下面是和transport相關的配置參數：
 通用參數：
    unicast（單播） | multicast（多播）:
二選一地指定是進行單播還是多播的傳輸嘗試。默認值是多播。單播和多播都能處理的客戶端【必須】通過包含兩個傳輸的完整具體參數來指出這樣的能力。
 destination（目的地）：
流將被髮往的地址。客戶端用destination參數來給出多播地址。爲了避免在不知情的情況下被用於拒絕服務攻擊，服務器【應該】對客戶端鑑權並【應該】在允許客戶端把一個媒體流定向到非服務器選取的地址之前記錄此類嘗試。這對通過UDP發的RTSP命令來說尤其重要，但是實現不能把TCP當作可靠的客戶端認證手段。服務器【應該】不允許客戶端把媒體流定向到同命令來源不同的地址上去。
 source（來源）：
如果流的源地址不同於可從RTSP末端點地址 （回放中的服務器或錄製中的客戶端）得到的，【可能】會給出source。
 該信息也可以通過SDP得到。但是，因爲這更多的是一項傳輸特性而不是媒體初始化特性，該信息的權威性的source應該放在SETUP響應中。
 layers（層）：
將要用於該媒體流的多播的層數。layers是發送到以目的地址起始的連續地址。
 mode（模式）：
mode參數指示該會話支持的方法。有效的值有PLAY和RECORD。如果沒有提供，默認值是PLAY。
 append（追加）：
如果mode參數中包括RECORD，則append參數指示媒體數據應該追加到已有的資源上而不是覆蓋它。如果要求了追加而服務器不支持，它【必須】拒絕該請求而不是覆蓋URI所標識的資源。如果mode參數中不包含RECORD，則append被忽略。
 interleaved（交織）：
interleaved參數意味着不管控制流使用何種協議，都把媒體流和控制流混合在一起，使用10.12節定義的機制。用 $ 語法提供表示信道號的參數。該參數可能會以一個範圍的形式提供，例如：interleaved=4-5 在這裏表示向媒體流提供的傳輸選擇。
 這允許用類似UDP的方式來處理RTP/RTCP，例如，一個信道給RTP,另一個給RTCP。
 Multicast specific（多播細節）：
 ttl：
多播的time-to-live
 RTP Specific（RTP細節）：
 port（端口號）：
該參數爲多播會話提供RTP/RTCP端口號對。它用範圍的形式給出，例如，port=3456-3457。
 client_port(客戶端端口)：
該參數提供客戶端選擇的接收媒體數據和控制信息的單播RTP/RTCP端口號對。它用範圍的形式給出，例如，client_port=3456-3457。
 server_port(服務器端口)：
該參數提供服務器選擇的用來接收媒體數據和 控制信息的單播RTP/RTCP端口號對。它用範圍的形式給出，例如，server_port=3456-3457。
 ssrc:
ssrc參數指示媒體服務器應該用的（請求）或將要用的（響應）RTP SSRC[24,章節3]值.該參數只對單播傳輸有效。它是和媒體流關聯的同步源的標識。
    Transport           =    "Transport" ":"
                            1\#transport-spec
   transport-spec      =    transport-protocol/profile[/lower-transport]
                            *parameter
   transport-protocol  =    "RTP"
   profile             =    "AVP"
   lower-transport     =    "TCP" | "UDP"
   parameter           =    ( "unicast" | "multicast" )
                       |    ";" "destination" [ "=" address ]
                       |    ";" "interleaved" "=" channel [ "-" channel ]
                       |    ";" "append"
                       |    ";" "ttl" "=" ttl
                       |    ";" "layers" "=" 1*DIGIT
                       |    ";" "port" "=" port [ "-" port ]
                       |    ";" "client_port" "=" port [ "-" port ]
                       |    ";" "server_port" "=" port [ "-" port ]
                       |    ";" "ssrc" "=" ssrc
                       |    ";" "mode" = <"> 1\#mode <">
   ttl                 =    1*3(DIGIT)
   port                =    1*5(DIGIT)
   ssrc                =    8*8(HEX)
   channel             =    1*3(DIGIT)
   address             =    host
   mode                =    <"> *Method <"> | Method
 例子:
     Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",
                RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"
 Transport頭部只能描述單個RTP流。（RTSP也可以把多個流當一個實體進行控制。）把它作爲RTSP的一部分而不是依賴它作爲最通用的會話描述格式，極大地簡化了防火牆的設計。
12.40 Unsupported 不支持的
    Unsupported響應頭部列出服務器不支持的特性。在特性是通過Proxy-Require域給出的情況下（12.32節），代理【必須】把出錯消息“551 選項不支持”插入迴應消息。
見12.32節的用例。
12.41 User-Agent（用戶-代理）
    見[H14.42]。
12.42 Vary（變化）
   見 [H14.43]
12.43 Via（通過）
   見 [H14.44].
12.44 WWW-Authentica（www-鑑權）
   見 [H14.46].
13 Caching
    在HTTP中，響應-請求對是被緩存了的。RTSP在這方面有顯著的不同。響應不可以緩存，除了DESCRIBE返回的或ANNOUNCE中包含的表示描述以外。（因爲除了DESCRIBE和GET_PARAMETER以外任何響應不返回任何數據，緩存對於請求來說不是一個真正的問題。）但是，連續媒體數據--一般是是在RTSP之外傳輸--和會話描述，期望被緩存。
 收到一個SETUP或PLAY請求後，代理要確認它是否有該連續媒體內容的最新拷貝和它的描述。它可以通過發出一個SETUP或DESCRIBE請求來判斷拷貝是否是最新的，並跟所緩存的拷貝比較Last-Modified頭部。如果拷貝不是最新的，它就修改SETUP transport參數爲合適值並向原始服務器轉發請求。緊跟的控制命令如PLAY或PAUSE就不修改地經過代理。代理把連續媒體數據傳送給客戶端，可能同時爲之後的重用生成本地拷貝。緩存允許的確切的行爲通過12.8節描述的cache-response指令給出。如果緩存正在服務於請求者所請求的流，緩存【必須】回答任何DESCRIBE請求，因爲原始服務器上的流描述的低級別細節可能已改變。
 注意：RTSP緩存和HTTP緩存不一樣，它有“cut-through ”多樣性。緩存直接拷貝流數據，就像數據是從它那裏經過到達客戶端一樣。因此它沒有引入額外的延時。
 對客戶端，RTSP代理的緩存表現得像是常規的媒體服務器一樣；對媒體原始服務器則像客戶端。就和HTTP需要儲存所緩存對象的內容類型、內容語言等等一樣，媒體緩存需要儲存表述描述。典型地，緩存會消除表示描述中的所有transport-引用（即多播信息），因爲從緩存到客戶端的傳送不需要這些。編碼信息則保持不變。如果緩存有能力轉譯 所緩存的媒體數據，它會生成一個新的包括了所有它能提供的編碼可能的表示描述。
14 示例
   下列示例涉及到非標準的流描述格式，如RTSL。下面的例子不是用作這些格式的參考。
14.1 按需點播（單播）
  客戶端C向媒體服務器A（audio.example.com）和V（video.example.com）請求一個電影。媒體描述儲存在web服務器W。媒體描述包含表示和它所有流的描述，包括有效的編解碼器、動態RTP載荷類型、協議棧，以及如語言或拷貝限制這類內容信息。它還可能會給出電影時間信息指示。
 在該例子中，客戶端只對電影的最後部分感興趣。
    C->W: GET /twister.sdp HTTP/1.1
           Host: www.example.com
           Accept: application/sdp
     W->C: HTTP/1.0 200 OK
           Content-Type: application/sdp
           v=0
           o=- 2890844526 2890842807 IN IP4 192.16.24.202
           s=RTSP Session
           m=audio 0 RTP/AVP 0
           a=control:rtsp://audio.example.com/twister/audio.en
           m=video 0 RTP/AVP 31
           a=control:rtsp://video.example.com/twister/video
      C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
           CSeq: 1
           Transport: RTP/AVP/UDP;unicast;client_port=3056-3057
      A->C: RTSP/1.0 200 OK
           CSeq: 1
           Session: 12345678
           Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;
                      server_port=5000-5001
      C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0
           CSeq: 1
           Transport: RTP/AVP/UDP;unicast;client_port=3058-3059
      V->C: RTSP/1.0 200 OK
           CSeq: 1
           Session: 23456789
           Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;
                      server_port=5002-5003
     C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
           CSeq: 2
           Session: 23456789
           Range: smpte=0:10:00-
      V->C: RTSP/1.0 200 OK
           CSeq: 2
           Session: 23456789
           Range: smpte=0:10:00-0:20:00
           RTP-Info: url=rtsp://video.example.com/twister/video;
             seq=12312232;rtptime=78712811
      C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
           CSeq: 2
           Session: 12345678
           Range: smpte=0:10:00-
      A->C: RTSP/1.0 200 OK
           CSeq: 2
           Session: 12345678
           Range: smpte=0:10:00-0:20:00
           RTP-Info: url=rtsp://audio.example.com/twister/audio.en;
             seq=876655;rtptime=1032181
      C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0
           CSeq: 3
           Session: 12345678
      A->C: RTSP/1.0 200 OK
           CSeq: 3
      C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
           CSeq: 3
           Session: 23456789
      V->C: RTSP/1.0 200 OK
           CSeq: 3
 儘管音軌和視頻軌在兩個不同的服務器上，並可能在起始時間上有時間上的微小差別及互相有偏移量，客戶端可以用標準RTP方法同步它們，具體就是RTCP發送方包括所包含的時間刻度。
14.2 容器文件的流化
    在本示例內，容器文件就是可以容納服務於同一個終端用戶的表示的多個連續媒體類型的存儲實體。在實際中，一個容器文件對應一個RTSP表示，它的每一種元素對應一個RTSP流。容器文件被廣泛用於存儲此類表示。而各元素作爲互相獨立的流來傳輸，它意在把一個服務端的多個流維護成一個公用的內容。
 這使服務器可以用一個存儲句柄方便地做打開操作。它還允許了服務器平等地處理各流，從而避免了對流的任何存在優先權的處理方式。
 這還使得表示所有者可以防止別人爲了得到該多媒體表示的藝術效果而通過客戶端選擇性地摘取流。類似地，在這樣緊密捆綁的表示中，我們可能希望可以通過一個控制消息，使用一個合URL來控制所有的流。
 下面是一個使用一個RTSP會話控制多個流的例子。它也示範了合URL的使用。
 客戶端C向媒體服務器M請求一個表示。該電影存在一個容器文件中。客戶端已經取得了該容器文件的RTSP URL。
      C->M: DESCRIBE rtsp://foo/twister RTSP/1.0
           CSeq: 1
      M->C: RTSP/1.0 200 OK
           CSeq: 1
           Content-Type: application/sdp
           Content-Length: 164
           v=0
           o=- 2890844256 2890842807 IN IP4 172.16.2.93
           s=RTSP Session
           i=An Example of RTSP Session Usage
           a=control:rtsp://foo/twister
           t=0 0
           m=audio 0 RTP/AVP 0
           a=control:rtsp://foo/twister/audio
           m=video 0 RTP/AVP 26
           a=control:rtsp://foo/twister/video
      C->M: SETUP rtsp://foo/twister/audio RTSP/1.0
           CSeq: 2
           Transport: RTP/AVP;unicast;client_port=8000-8001
      M->C: RTSP/1.0 200 OK
           CSeq: 2
           Transport: RTP/AVP;unicast;client_port=8000-8001;
                      server_port=9000-9001
           Session: 12345678
      C->M: SETUP rtsp://foo/twister/video RTSP/1.0
           CSeq: 3
           Transport: RTP/AVP;unicast;client_port=8002-8003
           Session: 12345678
      M->C: RTSP/1.0 200 OK
           CSeq: 3
           Transport: RTP/AVP;unicast;client_port=8002-8003;
                      server_port=9004-9005
           Session: 12345678
      C->M: PLAY rtsp://foo/twister RTSP/1.0
           CSeq: 4
           Range: npt=0-
           Session: 12345678
      M->C: RTSP/1.0 200 OK
           CSeq: 4
           Session: 12345678
           RTP-Info: url=rtsp://foo/twister/video;
             seq=9810092;rtptime=3450012
      C->M: PAUSE rtsp://foo/twister/video RTSP/1.0
           CSeq: 5
           Session: 12345678
      M->C: RTSP/1.0 460 Only aggregate operation allowed
           CSeq: 5
      C->M: PAUSE rtsp://foo/twister RTSP/1.0
           CSeq: 6
           Session: 12345678
     M->C: RTSP/1.0 200 OK
           CSeq: 6
           Session: 12345678
      C->M: SETUP rtsp://foo/twister RTSP/1.0
           CSeq: 7
           Transport: RTP/AVP;unicast;client_port=10000
      M->C: RTSP/1.0 459 Aggregate operation not allowed
           CSeq: 7
 第一個失敗實例裏，客戶端試圖暫停該表示的一個流（此處是視頻）。服務器不允許對該表示這樣操作。第二個實例裏，合URL不應該被用在SETUP上，每個流需要一個控制消息來設置傳輸參數。
 這保持了Transport頭部的語法，使防火牆可以容易地解析transport信息。
14.3 單流容器文件
 一些RTSP服務器可能會把所有的文件當作容器文件來處理，而另一些服務器可能不支持這樣的觀點。因此，客戶端【應該】用該請求URL的會話描述中給的規則，而不是假設在所有場合用的都是複合URL。這裏是一個多流服務器期望如何提供一個單流文件的示例：
           Accept: application/x-rtsp-mh, application/sdp
           CSeq: 1
     S->C  RTSP/1.0 200 OK
          CSeq: 1
          Content-base: rtsp://foo.com/test.wav/
          Content-type: application/sdp
          Content-length: 48
           v=0
          o=- 872653257 872653257 IN IP4 172.16.2.187
          s=mu-law wave file
          i=audio test
          t=0 0
          m=audio 0 RTP/AVP 0
          a=control:streamid=0
     C->S  SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
          Transport: RTP/AVP/UDP;unicast;
                     client_port=6970-6971;mode=play
          CSeq: 2
    S->C  RTSP/1.0 200 OK
          Transport: RTP/AVP/UDP;unicast;client_port=6970-6971;
                     server_port=6970-6971;mode=play
          CSeq: 2
          Session: 2034820394
     C->S  PLAY rtsp://foo.com/test.wav RTSP/1.0
          CSeq: 3
          Session: 2034820394
     S->C  RTSP/1.0 200 OK
          CSeq: 3
          Session: 2034820394
          RTP-Info: url=rtsp://foo.com/test.wav/streamid=0;
            seq=981888;rtptime=3781123
 注意SETUP命令裏的不同URL，和之後在PLAY命令裏切換回合URL。這在有多個流被合控制的情況下完全合理，但在流的數量爲一時就不那麼直觀了。
 這種特殊情況下，推薦的是服務器能夠容許實現發送：
    C->S  PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
          CSeq: 3
 在最壞的情況裏，服務器會返回：
     S->C  RTSP/1.0 460 Only aggregate operation allowed
          CSeq: 3
 有些人還希望服務器實現也能容許下面這樣的：
     C->S  SETUP rtsp://foo.com/test.wav RTSP/1.0
          Transport: rtp/avp/udp;client_port=6970-6971;mode=play
          CSeq: 2
 因爲文件裏只有一個流，所以它也不會產生歧義。
14.4 現場媒體表示使用多播
 媒體服務器M選擇多播地址和端口號。在這裏，我們假設web服務器只包含指向完整描述的指針，而媒體服務器M維護着完整描述。
      C->W: GET /concert.sdp HTTP/1.1
           Host: www.example.com
      W->C: HTTP/1.1 200 OK
           Content-Type: application/x-rtsl
            <session>
             <track src="rtsp://live.example.com/concert/audio">
           </session>
      C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0
           CSeq: 1
      M->C: RTSP/1.0 200 OK
           CSeq: 1
           Content-Type: application/sdp
           Content-Length: 44
            v=0
           o=- 2890844526 2890842807 IN IP4 192.16.24.202
           s=RTSP Session
           m=audio 3456 RTP/AVP 0
           a=control:rtsp://live.example.com/concert/audio
           c=IN IP4 224.2.0.1/16
      C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0
           CSeq: 2
           Transport: RTP/AVP;multicast
      M->C: RTSP/1.0 200 OK
           CSeq: 2
           Transport: RTP/AVP;multicast;destination=224.2.0.1;
                      port=3456-3457;ttl=16
           Session: 0456804596
      C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0
           CSeq: 3
           Session: 0456804596
      M->C: RTSP/1.0 200 OK
           CSeq: 3
           Session: 0456804596
 14.5 向已存在的會話播放媒體
 會議參與者C想要讓媒體服務器M向已存在的會議播放一段演示。C向媒體服務器指出網絡地址和密鑰已經由會議給出，所以服務器不需要選擇它們。該示例忽略了簡單的ACK響應。
      C->M: DESCRIBE rtsp://server.example.com/demo/548/sound RTSP/1.0
           CSeq: 1
           Accept: application/sdp
      M->C: RTSP/1.0 200 1 OK
           Content-type: application/sdp
           Content-Length: 44
            v=0
           o=- 2890844526 2890842807 IN IP4 192.16.24.202
           s=RTSP Session
           i=See above
           t=0 0
           m=audio 0 RTP/AVP 0
      C->M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0
           CSeq: 2
           Transport: RTP/AVP;multicast;destination=225.219.201.15;
                      port=7000-7001;ttl=127
           Conference: [email protected]%20Starr
      M->C: RTSP/1.0 200 OK
           CSeq: 2
           Transport: RTP/AVP;multicast;destination=225.219.201.15;
           port=7000-7001;ttl=127
           Session: 91389234234
           Conference: [email protected]%20Starr
      C->M: PLAY rtsp://server.example.com/demo/548/sound RTSP/1.0
           CSeq: 3
           Session: 91389234234
      M->C: RTSP/1.0 200 OK
           CSeq: 3
 14.6 錄製
 會議參與者客戶端C讓媒體服務器M錄製會議的音頻和視頻部分。客戶端使用ANNOUNCE方法來向服務器提供被錄製會話的元信息。
      C->M: ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0
           CSeq: 90
           Content-Type: application/sdp
           Content-Length: 121
           v=0
           o=camera1 3080117314 3080118787 IN IP4 195.27.192.36
           s=IETF Meeting, Munich - 1
           i=The thirty-ninth IETF meeting will be held in Munich, Germany
           u=http://www.ietf.org/meetings/Munich.html
           e=IETF Channel 1 <[email protected]>
           p=IETF Channel 1 +49-172-2312 451
           c=IN IP4 224.0.1.11/127
           t=3080271600 3080703600
           a=tool:sdr v2.4a6
           a=type:test
           m=audio 21010 RTP/AVP 5
           c=IN IP4 224.0.1.11/127
           a=ptime:40
           m=video 61010 RTP/AVP 31
           c=IN IP4 224.0.1.12/127
      M->C: RTSP/1.0 200 OK
           CSeq: 90
      C->M: SETUP rtsp://server.example.com/meeting/audiotrack RTSP/1.0
           CSeq: 91
           Transport: RTP/AVP;multicast;destination=224.0.1.11;
                      port=21010-21011;mode=record;ttl=127
      M->C: RTSP/1.0 200 OK
           CSeq: 91
           Session: 50887676
           Transport: RTP/AVP;multicast;destination=224.0.1.11;
                      port=21010-21011;mode=record;ttl=127
      C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0
           CSeq: 92
           Session: 50887676
           Transport: RTP/AVP;multicast;destination=224.0.1.12;
                      port=61010-61011;mode=record;ttl=127
      M->C: RTSP/1.0 200 OK
           CSeq: 92
           Transport: RTP/AVP;multicast;destination=224.0.1.12;
                      port=61010-61011;mode=record;ttl=127
      C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0
           CSeq: 93
           Session: 50887676
           Range: clock=19961110T1925-19961110T2015
      M->C: RTSP/1.0 200 OK
           CSeq: 93
 15 語法
     RTSP語法和RFC2068[2]一樣用增廣Backus-Naur form (BNF)來描述。
 15.1 基本語法
    OCTET              =      <任何 8位順序數據>
   CHAR               =      <任何 US-ASCII 字符 (0 - 127的八位組)>
   UPALPHA            =      <任何 US-ASCII 大寫字母 "A".."Z">
   LOALPHA            =      <任何 US-ASCII 小寫字母 "a".."z">
   ALPHA              =      UPALPHA | LOALPHA
    DIGIT              =      <任何 US-ASCII 數字 "0".."9">
   CTL                =      <任何 US-ASCII 控制字符
                              (0 - 31的八位組) 和 DEL (127)>
   CR                 =      <US-ASCII CR, 回車 (13)>
   LF                 =      <US-ASCII LF, 換行 (10)>
   SP                 =      <US-ASCII SP, 空格 (32)>
   HT                 =      <US-ASCII HT, 水平製表符 (9)>
   <">                =      <US-ASCII 雙引號 (34)>
   CRLF               =      CR LF
    LWS                =      [CRLF] 1*( SP | HT )
   TEXT               =      <任何 OCTET 除了 CTLs>
   tspecials          =      "(" | ")" | "<" | ">" | "@"
                      |       "," | ";" | ":" | "\" | <">
                      |       "/" | "[" | "]" | "?" | "="
                      |       "{" | "}" | SP | HT
    token              =      1*<任何 CHAR 除了 CTLs or tspecials>
   quoted-string      =      ( <"> *(qdtext) <"> )
   qdtext             =      <任何 TEXT 除了 <">>
   quoted-pair        =      "\" CHAR
    message-header     =      域-名稱 ":" [ 域-值 ] CRLF
   field-name         =      token
   field-value        =      *( 域-內容 | LWS )
   field-content      =      <the 構成 field-value ，組成
                              *TEXT 或token、 tspecials、
                              quoted-string組合成的OCTETs>
    safe               =  "\$" | "-" | "_" | "." | "+"
   extra              =  "!" | "*" | "$'$" | "(" | ")" | ","
    hex                =  DIGIT | "A" | "B" | "C" | "D" | "E" | "F" |
                        "a" | "b" | "c" | "d" | "e" | "f"
   escape             =  "\%" hex hex
   reserved           =  ";" | "/" | "?" | ":" | "@" | "&" | "="
   unreserved         =  alpha | digit | safe | extra
   xchar              =  unreserved | reserved | escape
 16 安全考慮
     由於RTSP服務器和HTTP服務器在語法和使用上的相似性，應用[H15]所述的安全機制。請特別注意以下內容：
 鑑權機制：
RTSP和HTTP分享相同的鑑權方案，因此應該遵循相同的鑑權原則。客戶端鑑權課題見[H15.1],多鑑權機制支持的相關課題見[H15.2]。
 服務器日誌信息的誤用：
RTSP和HTTP服務器將有大致類似的日誌記錄機制，因此應該平等地對待日誌內容保護，及用戶和服務器隱私的保護。HTTP服務器日誌相關的服務器推薦見[H15.3]。
 
敏感信息的傳遞：
沒有理由認爲RTSP上傳輸的信息會沒有一般HTTP上傳輸的信息那麼敏感。因此，所有涉及到保護數據隱私權和用戶隱私權的警示，是每個RTSP客戶端、服務器、代理的實現者都需要考慮的。更多細節見[H15.4]。
 基於文件和路徑名的攻擊：
儘管RTSP URL是不透明的句柄，沒必要有文件系統語義，但還是期望很多實現能夠把請求URL的一部分直接轉化成文件系統目錄。此種情況下，文件系統【應該】遵循[H15.5]給出的警示，例如檢查路徑元素中的“..”。
 個人信息：
一般在HTTP上是隱私的信息（用戶名，地址，等等），在RTSP上也是，因此它們應該對等。更多推薦意見見[H15.6]。
 Accept頭部相關的隱私問題：
由於RTSP中存在很多和HTTP一樣的“Accept”頭部，因此也要遵循[H15.7]中關於它們的使用的相同的警示。
 DNS欺騙：
可以推測，如果給典型的和HTTP會話相關的RTSP會話更長連接時間，RTSP客戶端DNS優化應該會少些普遍性。儘管如此，對於任何試圖依靠DNS-to-IP的映射來保持該映射的簡單使用的實現，[H15.8]提供的推薦意見仍然有普遍意義。
 地址頭部及欺騙：
如果一個支持多優化的服務器不相信其他服務器，那麼它必須檢查響應中在上述優化的控制下產生的Location和Content-Location頭部的值，以確保它們不會向沒有權限（[H15.9]）的無效資源作嘗試。
 作爲現有HTTP規範（本規範編寫時的RFC 2068 [2]）的推薦的補充，將來的HTTP規範可能提供安全方面的補充指導。
 下面是RTSP實現的額外考慮：
 集中的拒絕服務式攻擊：
協議提供了用遠程控制來進行拒絕服務式攻擊的機會。攻擊者可能會通過修改SETUP請求的目的地地址，向一個或多個IP地址發起傳輸流。該情況中可能可以看到攻擊者的IP，但對於預防更多的攻擊者或確認攻擊者的標識這並不總是管用。因此，RTSP服務器【應該】只允許客戶端爲RTSP發起的傳輸流指定目的地址，如果服務器驗證過客戶端標識--通過建立一個已知的使用RTSP鑑權機制的用戶的數據庫（可能是digest鑑權或者更強），或者其他手段--的話。
 會話劫持：
因爲傳輸層連際和RTSP之間沒有直接聯繫，惡意客戶端就可能以發起會話標識爲隨機值的請求來影響正常的客戶端。服務器【應該】使用較大的隨機無序會話標識來降低此種攻擊的機會。
 鑑權：
服務器應該同時實現基本的和digest[8]的鑑權。在需要控制消息有較強安全性的環境，RTSP控制流可能會被加密。
流課題：
RTSP僅提供流控制。在此章節及餘下的備忘裏，不包括流傳輸課題。RTSP實現最有可能採取的方式是依賴於其他協議如RTP、IP multicast、 RSVP 和 IGMP，並應解決這些或其他適用規範所帶來的安全問題。
 持續性可疑行爲：
RTSP服務器【應該】在收到一個進程的存在安全隱患的行爲後返回錯誤代碼403（禁止）。RTSP服務器也【應該】能意識到探測服務器弱點和進口的嘗試，並【可能】強行斷開連接並忽略認爲違反了本地安全策略的客戶端的其他請求。
附錄A：RTSP 協議狀態機
     RTSP客戶端和服務器狀態機給出了協議從RTSP會話初始化到RTSP會話終止之間的表現。
 狀態是基於每個對象定義的。一個對象由流URL和RTSP會話標識唯一地標識出來。任何使用跟多個流構成的表示的合URL相關的請求/回覆，都對所有單個的流的狀態有影響。例如，如果一個表示/movie包含兩個流，/movie/audio 和 /movie/video，那麼下列命令：
      PLAY rtsp://foo.com/movie RTSP/1.0
     CSeq: 559
     Session: 12345678
將對/movie/audio 和 /movie/video的狀態有影響。
 該示例沒有示範標準URL形式或和文件系統的關係的意思。見3.2節。
 OPTIONS, ANNOUNCE, DESCRIBE, GET_PARAMETER,SET_PARAMETER 請求對客戶端或服務器的狀態沒有影響，因此未列入狀態表。
 A.1 客戶端狀態機
 客戶端可以處於如下的狀態：
 Init（初始）：
    已經發出SETUP，等待迴應中。
 Ready（就緒）：
    SETUP回覆已收到或在Playing狀態中PAUSE回覆已收到。
 Playing（播放）：
    PLAY回覆已收到。
 Recording（錄製）：
    RECORD回覆已收到。
 總之，客戶端在收到請求的回覆之後改變狀態。注意某些請求是在未來的時間或位置起作用的（如PAUSE），而狀態的改變也要視情況而定。如果對象（例如多播組有效的）不要求顯式的SETUP，狀態自Ready開始。在此情況就只有兩種狀態，Ready和Playing。當到達所請求的range的結尾時，的客戶端也會從Playing/Recording狀態轉到Ready。
“下一狀態”欄指示接受到成功響應（2xx）後可能的狀態。如果請求所得來的狀態碼是3xx，那麼狀態變成Init，而4xx狀態碼不會導致狀態改變。沒有在對應狀態列出的消息，【必須不】在此狀態下被客戶端發出--例外是上文列出的對狀態沒有影響的消息。從服務器收到一個REDIRECT等同於收到3xx重定向狀態。
    狀 態       可發消息         響應後下一狀態
   Init        SETUP            Ready
               TEARDOWN         Init
   Ready       PLAY             Playing
               RECORD           Recording
               TEARDOWN         Init
               SETUP            Ready
   Playing     PAUSE            Ready
               TEARDOWN         Init
               PLAY             Playing
               SETUP            Playing (changed transport)
   Recording   PAUSE            Ready
               TEARDOWN         Init
               RECORD           Recording
               SETUP            Recording (changed transport)
A.2 服務器狀態碼
服務器可以處於如下狀態：
Init（初始）：
    初始化狀態，沒有收到有效SETUP。
Ready（就緒）：
    最近收到的SETUP請求成功，回覆已發送；或在播放中，最近收到的PAUSE請求成功，回覆已發送。
Playing（播放）：
    最近收到的PLAY請求成功，回覆已發送。數據開始發送。
Recording（錄製）：
    服務器正在錄製媒體數據。
總之，服務器根據收到的請求改變狀態。如果服務器處於Playing或Recording和單播模式下，且如果在給定期間沒有從客戶端收到“健康的”信息，例如RTCP報告或RTSP命令，服務器【可能】會轉到Init狀態或關閉RTSP會話。服務器可以在會話響應頭部（12.37節）聲明另一個超時值。如果服務器狀態爲Ready，且在一分鐘或者更長時間內沒有收到RTSP請求，它【可能】轉爲Init狀態。注意某些請求是在未來的時間或位置起作用（如PAUSE），服務器在合適的時間狀態的改變。在到達客戶端所請求範圍的末端後，服務器從Playing或Recording狀態轉爲Ready。
REDIRECT消息一旦發出就立即生效，除非在Range頭部中另外指出了重定向何時生效。此種情況中，服務器狀態也是在合適的時間才改變。
如果對象不要求有顯式的SETUP，則狀態從Ready開始，且只有Ready和Playing兩個狀態。
“下一狀態”欄指示接受到成功響應（2xx）後可能的狀態。如果請求所得來的狀態碼是3xx，那麼狀態變成Init，而4xx狀態碼不會導致狀態改變。
   狀 態            可收消息         下一狀態
     Init            SETUP             Ready
                     TEARDOWN          Init
     Ready           PLAY              Playing
                     SETUP             Ready
                     TEARDOWN          Init
                     RECORD            Recording
     Playing         PLAY              Playing
                     PAUSE             Ready
                     TEARDOWN          Init
                     SETUP             Playing
     Recording       RECORD            Recording
                     PAUSE             Ready
                     TEARDOWN          Init
                     SETUP             Recording
附錄B：同RTP交互
    RTSP允許媒體客戶端控制媒體表示中選擇出的非連續片段，表現爲RTP媒體層[24]的流。表現爲RTP流的媒體層不應該受NPT時間的跳躍的影響。因此，RTP序列號和RTP時間戳在跨越NPT時間跳躍時都【必須】是連續且單調遞增的。
例如，假設時鐘頻率是8000Hz，包之間的時間間隔是100毫秒，初始序列號和時間戳都是0。我們首先播放NPT 10到NPT 15，然後向前跳播放NPT 18到NPT 20。第一個片段在RTP包上表現爲序列號從0到49，時間戳從0到39，200。第二個片段則表現爲序列號從50到69，時間戳從40，000到55，200。
 我們不能假定RTSP客戶端可以與RTP媒體agent通信，因爲這可能是兩個獨立的進程。如果RTP時間戳的時間間隔和NPT一樣，媒體agent將假設表示有暫停 。如果NPT時間跳躍足夠大，RTP時間戳可能會到達上限而從頭開始，這樣媒體agent可能會認爲之後的包跟之前已播放的包重複了。
 對於某些數據類型，RTSP層和RTP層之間的緊密整合是有必要的。這完全不能排除上文所述的限制。RTSP/RTP組合媒體客戶端應該用RTP-Info域來判斷要來的RTP包是在搜索之前還是之後發的。
對於連續音頻，服務器【應該】在服務於新PLAY請求之始就設置RTP標誌位。這使客戶端可以進行播放延遲調整 。
 對於倍速改變（12.34節），RTP時間戳應該和回放計時一致。例如，當以兩倍速、speed爲1播放30幀/秒的視頻記錄，服務器應該每兩幀丟棄一幀以維持用間隔爲3000每幀的正常時間戳傳送視頻流，但是NPT每一視頻幀增加1/15秒。
 客戶端可以通過通知位置重設後的第一個包的RTP時間戳值，來維護正確NPT的播放。RTP-info（12.33）頭部的sequence參數提供下個片段的首個序列號。
 附錄C：用SDP描述RTSP會話
 會話描述協議（SDP, RFC 2327 [6]）可能會RTSP被用於描述流或表示。這類使用被限制在以下幾個方面，用於給出訪問方式和編碼：
 合控制：
不能夠合控制的由來自於一個或多個服務器多個流組成的表示。這類描述通常由其他途徑得來，以HTTP爲典型。不它們也可以通過ANNOUNCE方法接收。
 非合控制：
能夠合控制的由多個來自於一個服務器的流組成的表示。這類描述通常在對一個URL的 DESCRIBE請求的回覆中給出，或通過ANNOUNCE方法接收。
 該附錄描述一個SDP文件，例如通過HTTP獲取的,如何決定一個RTSP會話上的操作。它還描述了客戶端如何解釋DESCRIBE請求的回覆所給的SDP內容。SDP不爲客戶端提供能夠不用人工指引，而區分多個要同時提交的媒體流和多個互爲替換的流的集合（例如，兩個講不同語言的音頻流）。
 C.1 定義
 該附件使用的詞條"會話級別", "媒體級別"和其他鍵/屬性名及值的定義在SDP（RFC 2327[6]中：
 C.1.1 控制URL
 “a=control”屬性用來傳送控制RUL。該屬性可用在會話和媒體描述上。；如果用於單個媒體，它指示用來控制那個特定媒體流的URL。如果用在會話級別，該屬性指示合控制的URL。
 例子：
     a=control:rtsp://example.com/foo
 該屬性可能包含相對或者絕對URL，遵循RFC 1808 [25]的規則和習慣。實現應該按以下順序尋找基URL：
   1.     RTSP Content-Base 域
   2.     RTSP Content-Location 域
   3.     RTSP 請求 URL
 如果此屬性只包含星號（*）,則URL被以空內嵌UL對待，因此繼承整個基URL。
 C.1.2 媒體－流
     "m="被用來列舉流。它期望所有列舉出的流都將有合適的同步處理。如果會話是單播，端口號則是服務器對客戶端的推薦；客戶端在SETUP中還是應該在包括它並有可能忽略此推薦。如果服務器沒有偏好，它【應該】把端口號值置零。
 例子：
     m=audio 0 RTP/AVP 31
 C.1.3 載荷類型
     載荷類型以"m="域給出。若載荷類型是RFC 1890[1]裏的靜態載荷類型，則不需要其他信息。若是動態載荷類型，則用媒體屬性“rtpmap”說明是什麼媒體。“rtpmap”屬性中的“encoding name”可能是RFC 1890（章節5和6）中規定的一中，或SDP（RFC 2327 [6]）規定的“X-”爲前綴的實踐性編碼。Codec-specific（編碼器－細節）參數不在此域之中，而在下文描述的“fmtp”屬性中。想要註冊新編碼的實現者應該遵循RFC 1890 [1]中的手續。如果媒體類型不匹配RTP AV規範，那麼推新建一個子集並使用合適的名字，以代替"m="域的"RTP/AVP"。
 C.1.4 格式－細節 參數
    格式細節參數用“fmtp“媒體參數表達。”fmtp“的語法具體對應於屬性所指的編碼。注意打包時間間隔用“ptime”屬性傳遞。
 C.1.5 表示的範圍
     "a=range"屬性定義所儲會話的總時間範圍。（現場會話的長度可以由“t”和“r”屬性推導出。）除非表示含有不同持續時間的媒體流，否則範圍屬性是會話級別的屬性。首先給出的是單位，後跟值範圍。單位和它們的值在3.5、3.6、3.7節中給出定義。
 例子：
     a=range:npt=0-34.4368
     a=range:clock=19971113T2115-19971113T2203
 C.1.6
  “t=”域【必須】包含合適的合控制或非合控制流的開始和停止時間的值。在合控制裏，服務器【應該】指示保證描述有效的停止時間值，以及等於或早於收到DESCRIBE請求時刻的開始時間。它也【可能】把開始和停止時間指示爲0，意爲會話始終有效。在非合控制裏，那些值應該反映會話能有效保持SDP語義的時期，且不需要藉助其他途徑（如包含描述的web頁面的生命期）來達到此目的。
 C.1.7 連接信息
  在SDP裏，“C=”域包含媒體流的目的地址。但是，對於按需點播流和一些多播流，目的地址由客戶端通過SETUP請求給出。除非媒體內容有固定的目的地址，否則”C=”域將被置爲合適的空值。對於型爲“IP4“的地址，該值爲"0.0.0.0"。
 C.1.8 實體標籤
  可選的“a=etag”屬性標識會話描述的版本。它對客戶端不透明。SETUP請求可能在If-Match域（見12.22節）包含此標識，以在當該屬性值仍和當前描述中的對應時只允建立會話。該屬性值是不透明的且可以包含SDP屬性所允許包含的任意值。
 例子：
     a=etag:158bb3e7c7fd62ce67f12b533f06b83a
 有人可能會說“o=”域提供相同的功能。但是，這樣做可以對需爲同一個媒體內容片段提供多種SDP以外的的會話描述類型支持的服務器進行強制要求。
 C.2 合控制無效
   如果一個給出了多個媒體部分的表示不支持合控制，【必須】通過"a=control:"屬性給出每個部分的控制URL。
 例子：
     v=0
     o=- 2890844256 2890842807 IN IP4 204.34.34.32
     s=I came from a web page
     t=0 0
     c=IN IP4 0.0.0.0
     m=video 8002 RTP/AVP 31
     a=control:rtsp://audio.com/movie.aud
     m=audio 8004 RTP/AVP 3
     a=control:rtsp://video.com/movie.vid
 注意：描述中控制URL的位置暗示客戶端要分別建立到服務器audio.com 和 video.com的RTSP控制會話。
 推薦在SDP文件中包含完整的媒體初始化信息，即使SDP是通過非RTSP途徑傳送到媒體客戶端的。這是有必要的，因爲沒有機制可以指示客戶端應該通過DESCRIBE請求更多媒體流細節信息。
 C.3 合控制有效
  此種前提下，服務器有可以被當作一個整體控制的多個流。在此情況下，就即有用於給出流URL的媒體級"a=control:"屬性，又有用作合控制的請求URL的會話級"a=control:"。如果媒體級URL是相對URL，它將根據上文C1.1節所述被處理爲絕對URL。
 如果表示只由單個流組成，媒體級"a=control:"將被全部忽略。但是，如果表示包含多於一個流，每個媒體流部分【必須】包含自己的"a=control:"屬性。
 例子：
     v=0
     o=- 2890844256 2890842807 IN IP4 204.34.34.32
     s=I contain
     i=<more info>
     t=0 0
     c=IN IP4 0.0.0.0
     a=control:rtsp://example.com/movie/
     m=video 8002 RTP/AVP 31
     a=control:trackID=1
     m=audio 8004 RTP/AVP 3
     a=control:trackID=2
在此實例裏，客戶端被要求建立一個到服務器的RTSP會話，並用分別用URL rtsp://example.com/movie/trackID=1 和rtsp://example.com/movie/trackID=2 建立視頻和音頻流。URL rtsp://example.com/movie/控制整個電影。
 附錄D：最小RTSP實現
D.1 客戶端
客戶端實現【必須】能夠做到如下幾點：
*生成下列請求：SETUP, TEARDOWN, 和 PLAY (意即, 一個最小回放客戶端) 或 RECORD (意即, 一個最小錄製客戶端)。如果RECORD被實現，ANNOUNCE【必須】也被實現。
 *在請求中包含下列頭部：CSeq, Connection, Session, Transport。如果 ANNOUNCE 被實現，也應該實現包含Content-Language, Content-Encoding, Content-Length, 及 Content-Type 頭部的能力。
*解析並理解下列響應中的頭部：CSeq,Connection, Session, Transport, Content-Language, Content-Encoding, Content-Length, Content-Type。如果實現了RECORD，則也必須理解Location頭部。RTP-compliant（RTP適用的）實現應該再實現RTP-Info。
 *如果收到一個型別爲4xx 或5xx的錯誤代碼，理解所收到錯誤代碼的型別並通知最終用戶。如果最終用戶明確指出不想要一個或所有狀態碼的產生條件，則可以不進行通知。
 *期待並回復服務器的異步請求，例如ANNOUNCE。這並不是說它一定要實現ANNOUNCE方法，而只是【必須】對收到的任何服務器請求作出肯定或否定響應。
 雖然不是必需，但爲了便於實際中同早期實現協同工作且/或成爲“好市民”，在發佈時仍強烈推薦實現下述功能。
      * 實現 RTP/AVP/UDP ，使其成爲有效 transport.
     * 包含 User-Agent 頭部.
     * 理解附件C中定義的 SDP 會話描述
     * 接受從標準輸入、命令行、及其他適合操作環境的效果如同一個程序（如web瀏覽器）的“幫助程序”的方式等,得來的媒體初始化格式(例如 SDP)。
 可能有些RTSP程序跟RTSP規範的創建者的預想不同，對於這些程序，上述要求並無意義。因此，上面的推薦僅作爲指導，而非嚴格的要求。
 D.1.1 基本回放
    爲支持按需點播媒體流，客戶端【必須】額外地支持：
*生成PAUSE請求
*實現REDIRECT方法及Location頭部
D.1.2 鑑權－激活
    爲訪問要求鑑權的RTSP服務器上的媒體表示，客戶端【必須】額外地支持：
*識別401狀態碼
*解析幷包括WWW-Authenticate頭部
*實現基本鑑權和Digest鑑權
D.2 服務器
    最小服務器實現【必須】能夠做到：
*實現下列方法：SETUP, TEARDOWN, OPTIONS 以及PLAY (對於最小回放服務器) or RECORD (對於最小錄製服務器)。如果實現RECORD, ANNOUNCE也應該實現。
*包含下列頭部：Connection, Content-Length, Content-Type, Content-Language, Content-Encoding, Transport, Public。如果實現RECORD方法，也應實現包含Location頭部的能力。RTP-compliant（RTP適應的）實現還應該實現RTP-info域。
*正確解析及響應請求中的下列頭部：Connection, Session, Transport, Require。
雖然不是必需，但爲了便於實際中同早期實現協同工作且/或成爲“好市民”，在發佈時仍強烈推薦實現下述功能。
* 實現 RTP/AVP/UDP ，使其成爲有效 transport。
* 包含 Server 頭部。
* 實現DESCRIBE方法。
* 按附錄C中的定義生成SDP會話描述。
可能有些RTSP程序跟RTSP規範的創建者的預想不同，對於這些程序，上述要求並無意義。因此，上面的推薦僅作爲指導，而非嚴格的要求。
D.2.1 基本回放
 爲支持媒體流按需點播，服務器【必須】額外地支持：
*識別Range頭部，並在不支持搜索時返回error。
*實現PAUSE方法。
此外，爲支持普遍接受的用戶界面特性，高度推薦按需點播媒體服務器支持以下幾點：
*包含並解析Range頭部，使用 NPT單位。並推薦實現SMPTE單位。
*在媒體初始化信息中包含媒體表示的長度。
*包含從數據－相關 時間戳到NPT的映射。使用RTP時，用RTP-info域的rtptime部分來把RTP時間戳映射到NPT。
客戶端實現可能會用length信息的出現與否來判斷剪輯是否可搜索，並據此屏蔽沒有length信息的剪輯的搜索特性。常見的表示長度的應用是實現一個“滑動條”，它即可以指示進度，又可以指示時間位置。
RTP時間戳到NPT的映射是必要的，以保證滑動條位置正確。
D.2.2 鑑權－激活
    爲正確處理客戶端鑑權，服務器【必須】額外支持：
*當資源需要鑑權時生成401狀態碼
*解析幷包括WWW-Authenticate頭部
*實現基本鑑權和Digest鑑權
 指此協議的發佈方式，與本協議內容無關。
 只提供控制層協議，不包括傳輸層
 如視頻會議等
 言下之意似乎是對於不同的媒體類型，Media parameter可能會不同？望高手指教。
 事實上我覺得沒有那麼簡單
 指延續使用了http上的一些機制
 http服務器是無狀態的，而rtsp服務器有
 指媒體流的傳輸和rtsp使用同一個tcp連接
 指獨立於RTSP協議所用的傳輸層協議，而HTTP協議的數據傳輸是和HTTP本身共用同一個傳輸層協議的。
 HTTP協議沒有狀態機制
 囉嗦一句，中文翻譯中有的“實現”是動詞，有的是“動名詞”，但有些是純粹的名詞，指解決方案，請大家根據上下文理解。
 指不是基於字符的，不限於某種字符集
 這應該是說僅支持US-ASCII的程序無法支持該字符集
 許多程式由於各式各樣的原因，並未考慮到輸入的資料可能是 non-ASCII 碼的問題。它往往假設了它所要處理的資料都是 ASCII 碼，更糟糕的是，當它遇到 non-ASCII 碼時，常常假設它不存在，而將它的第八個位元截去! 這是所謂的 8-bit clean 問題。
  unchanged in value following multiplication by itself
 指無法理解後兩位內容的
 round-trip-time，一項衡量網絡延遲的指標
 RTT(Round-Trip Time): 往返時延，在計算機網絡中它也是一個重要的性能指標，它表示從發送端發送數據開始，到發送端收到來自接收端的確認（接收端收到數據後便立即發送確認），總共經歷的時延;
 其實就是類似flashget等程序的啓動方式：一旦點擊或拷貝了下載路徑，就自動開始工作。（我只是舉例說明它的啓動方式，不是說要實現那種後臺監控功能）
 指使服務器端能支持RTSP標準協議的最小功能集
 指使客戶端能以最簡單的功能集支持RTSP標準協議
 所以客戶端應儘可能把自己支持的傳輸方式都列上去，以便服務器做出選擇：列出的方式越多，傳輸成功建立的可能性就越大
 這當然是指對同一個客戶端而言。
 一種絕對時間，其內容相當於2007年4月12日3:05:37這種。
 應該是意指範圍的形式不同，而實際意義相同
 即我們可以讓圖像繼續播放，而聲音暫停傳輸。
 應是指當前還沒結束或者還沒開始的一個PLAY請求。
 指對參數值的設定
 即儘量不把會由於不同原因被拒絕的參數放在一起
 原子操作即不可以或者不應該再分割的操作，寫過多線程程序的人應該有體會。又例如：智能收費卡的pos機上，"讀取當前餘額+扣除本次消費+更新餘額信息”應該被實現爲一次原子操作，要麼全部成功，要麼全部失敗，否則就容易出現學生卡已被扣費食堂卻說繳費失敗這類問題。
 指媒體內的時間而言
 常見的情況是網關不允許UDP傳輸或只打開了HTTP端口
 end-to-end authentication：與nod-to-nod authentication不同，中間有可能經過其他節點，但無論其他節點如何，會保證這兩端的鑑權
 這是一個時間段
 這是一個時間點
 在我找到的RFC文檔中應該是[H14.35.1] 和什麼相關？
 例如對視頻進行拖放
 應該是指光RTCP還不是充分條件
 endpoint address 端點地址: 對於任何賦予計算機能用作目的地地址的一類地址術語。例如,IP地址是一種端點地 址。
 意爲“直達，切入式，直通的”
 我不太清楚這是指語言翻譯呢還是編碼格式的轉換
 不太理解
發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

Qt/C++音視頻開發68-檢查是否含有B幀/轉碼推流/拉流顯示/監控拉流推流/海康大華宇視監控

一、前言 爲什麼需要判斷視頻文件是否含有B幀，這個在推流的時候很容易遇到這個問題，一般來說，沒有B幀的視頻文件，解碼後的數據幀pts和dts都是順序遞增的，而有B幀的則未必，可能有些需要先解碼後面顯示，B幀也是雙向預測圖像B，對它的編碼，即

原創 2024-03-07 11:03:27

儀表板對接海康威視攝像頭實現實時監控方案

前言 在數據分析中，常常會有設計管理駕駛艙，或者指揮中心等綜合性數據可視化大屏，在這種大屏設置中經常會有對接攝像頭的需求，希望能夠直接展示攝像頭查看實時監控，或者點擊大屏看板可以跳轉彈出實時監控，今天小編就爲大家介紹一下如何使用葡萄城公司的

原創 2024-03-04 22:53:26

ffmpeg編解碼、攝像頭直播、推流、混屏

ffmpeg轉碼 ffmpeg -y -i /opt/video/a.mpg -s 1280x720 -vcodec h264 -strict -2 /opt/video/b.mp4 本地攝像頭直播 ffmpeg -f dsho

weixin_43972854 2020-07-07 16:11:36

視頻系統 流媒體 rtsp hls h264 h265 aac 高併發 低延時 系統 設計 錄像 視頻合成 轉發 點播 快進 快退 單步播放 分佈式集羣

    系統改名爲:,升級包改使用jpg圖像封裝,從2.124版本開始,1.*的升級包停止使用          系統工具            下載地址(2019-04-19) :https://pan.baidu.com/s/1kPZ

小雉系统 2020-07-06 14:38:48

海康攝像頭rtsp流格式

1.海康攝像頭老版本 username: 攝像頭用戶名 password: 攝像頭密碼 ip: 攝像頭ip地址 videoType: 編碼格式 h264或mpeg4 no:通道號 ch1表示模擬通道1，ch2表示模擬通道2; ch33表示

cxx为什么被注册 2020-07-06 01:36:03

G726編解碼處理(ffmpeg,rtsp)

目錄 G.726簡介 FFMpeg編解碼G.726 rtsp傳輸G.726 VLC播放G.726音頻有問題 G.726簡介 維基百科：https://en.wikipedia.org/wiki/G.726 以下內容，摘抄於維基百科 G.7

～边城浪子～ 2020-07-02 02:05:17

HTML使用VLC WEB插件播放RTSP視頻，並實現視頻截圖

由於工作需要，需要使用RTSP直播攝像頭，實現方案是使用VLC頁面插件播放。另外需要實現視頻的截屏功能，實現方案是使用ffmpeg.exe實現。   頁面視頻直播實現代碼 <!DOCTYPE html> <html> <head> <m

九尘辛 2020-06-26 12:11:13

Kivy之Video控件播放遠程RTSP流

軟件版本 Python: 3.7.3 OS: Win7 Kivy: 1.11.1 VLC: 3.0.8 簡要介紹 VLC中，RTSP是基於UDP協議開發的1，服務端進行串流，客戶端可以播放其視頻流。Kivy的Video控件是

zbk_pointer 2020-06-23 12:01:06

公測rtsp/rtmp/http流地址記錄

目錄rtsprtmphls （http） rtsp rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov rtmp 香港財經 rtmp://202.69.

费城之鹰 2020-06-21 05:42:21

Qt+ffmpeg接受rtsp並顯示

效果 接受 #include "rtspplayer.h" #include <QDebug> VideoPlayer::VideoPlayer() { } VideoPlayer::~VideoPlayer() { }

心流剑 2020-06-20 20:57:42

RTSP（Real Time Streaming Protocol）實時流協議

RTSP（Real Time Streaming Protocol）實時流協議，是TCP/IP協議體系中的一個應用層協議。RTSP在體系結構上位於RTP和RTCP之上，它使用TCP或RTP完成數據傳輸。 RTSP沒有“連接”這個概念，

cll_jj 2020-06-16 15:53:46

web端視頻解決方案

web端視頻解決方案   1. FFmpeg+nginx+video.js 播放rtmp      （可以，flash播放器） 2.FFepeg+livego+flv.js 播放 http **.flv文件  http **.m3u8 流

leihuanhuan123 2020-06-16 10:34:12

海思3559下怎麼播放rtsp,rtmp流媒體

海思3559下怎麼播放rtsp,rtmp流媒體1.硬件準備2.zlib-1.2.11交叉編譯3.openssl-1.0.1f交叉編譯4.rtmpdump交叉編譯5.海思3559A上驗證 1.硬件準備 硬件平臺：hisi3559V1

苏菲的世界2020 2020-06-16 09:43:36

海思3559A流媒體解決方案思考

海思3559A流媒體解決方案思考海思3559A流媒體解決方案思考 海思3559A流媒體解決方案思考 最近網絡直播，帶貨是主流，手上也正有項目在做，小白入手就此方案作如下思考與分步完成： 1.熟悉什麼是rtsp, rtmp，支持什麼

苏菲的世界2020 2020-06-16 09:43:36

運行EasyRTSPSever組件提示程序無法啓動問題解決

RTSP協議以客戶服務器方式工作，它是一個多媒體播放控制協議，用來使用戶在播放從因特網下載的實時數據時能夠進行控制，如：暫停/繼 續、後退、前進等。因此 RTSP 又稱爲“因特網錄像機遙控協議”。 我們的RTSP-Sever組件Easy

TSINGSEE 2020-06-16 06:29:22