RFC 2326
RTSP Spec中文版(1-11)
RTSP Spec中文版(12-16)
RTSP Spec中文版(附錄)

1 Introduction

1.1 Purpose

RTSP（Real-Time Straeming Protocol，實時流協議）建立并控制一至多個連接的時間同步流，盡管交錯（interleaving）媒體流和控制流是可行的，但通常RTSP并不直接參與數據傳送。換言之，RTSP實際上只為多媒體服務器中“網絡遠程控制”功能。

可被控制的一系列流整體定義為呈現描述（presentation description）。本篇并未定義呈現描述的具體格式。

RTSP中并沒有連接（connection）的概念，服務器（Server）只管理通過標識符進行標記的會話（session）。RTSP會話也從并未綁定至任何傳輸層連接（如TCP）。在一個RTSP會話生命周期中，RTSP客戶端（Client）可能打開、關閉許多可靠傳輸層連接以向服務器發(fā)出RTSP請求（request）。此外，RTSP也有可能使用如UDP的無連接傳輸協議。

RTSP控制的流可能通過RTP傳輸，但并不意味著RTSP依賴于某一種具體傳輸機制。RTSP在語法和操作上域HTTP/1.1比較類似，因此HTTP的大部分擴展機制均可以生效于RTSP。但RTSP在如下重要方面依然與HTTP有所不同：

• RTSP引入了一些新方法，并有了新的協議標識
• RTSP服務器默認情況下均需維護狀態(tài)，這一點與默認無狀態(tài)的HTTP截然相反
• RTSP中服務器和客戶端年均可以發(fā)出請求
• RTSP中數據通過其他協議以帶外方式傳輸
• RTSP使用ISO 10646（UTF-8）而不是ISO 8859-1標準，有效利用了許多HTML國際化成果
• RTSP-URI只能使用絕對URI，而HTTP/1.1為了兼容舊版本，將字段分成了兩部分

RTSP支持如下操作：

• 從媒體服務器獲取媒體數據
  客戶端可通過HTTP或其他方式獲取呈現描述，如果呈現描述是多播的，那么描述中將會包含多播地址和端口；如果呈現描述是單播的，則處于安全性考慮，客戶端需提供地址和端口。
• 邀請服務器參與會議
  服務器可被邀請至一個已存在的會議，或是向呈現中播放媒體文件，或是負責呈現的錄制。該模式在分布式教學應用中特別有效。同一會議中的不同參與者可能輪流掌握控制權。
• 動態(tài)插入媒體至已存在呈現中
  尤其在直播場景下，服務器如能通知客戶端可用的新增媒體將會十分有用

RTSP請求可能和HTTP/1.1一樣，被代理（proxy）、隧道（tunnel）以及緩存（cache）處理。

1.2 Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].

1.3 術語（Terminology）

部分術語采自HTTP/1.1，不再贅述。此處僅列出其余字段：

• 聚合控制（Aggregate control）
  服務器對遵循同一時間線的多個流的控制。對于音視頻而言，這代表著客戶端可通過一條play/pause消息來控制所有音視頻流。
• 會議（Conference）
  一個以上參與者的多媒體呈現。
• 客戶端（Client）
  客戶端從媒體服務器請求連續(xù)媒體數據。
• 連接（Connection）
  為了通訊而在兩個進程間建立的傳輸層虛擬回路。
• 容器文件（Container file）
  容器文件用于包含組成一個呈現的一至多個媒體流。盡管容器文件的概念并不屬于協議，當RTSP服務器仍可以為這些文件提供聚合控制。
• 連續(xù)媒體數據（Continuous media）
  source和sink間有時序關系的數據，即sink必須重現出source中數據間的時序關系。最普通的例子是音視頻動畫。連續(xù)媒體可能是交互式的嚴格實時流，也可以是寬松的點播流。
• Entity（實體）
  request/response中負載部分傳遞的信息，Entity由包含元信息的header域和包含內容的body域構成。
• 媒體初始化（Media initialization）
  Dattype/codec特定初始化，包括了時鐘頻率、顏色表等信息。任何客戶端所需的用于媒體流播放的（傳輸層以外的信息）均在流初始化中的媒體初始化階段發(fā)生。
• 媒體參數（Media Parameter）
  媒體類型的特定參數可在流播放期間動態(tài)調整。
• 媒體服務器（Media Server）
  服務器為一至多個流提供點播或錄制服務，同一呈現中的不同媒體流可能源自不同媒體服務器。媒體服務器既可以和Web服務器處于同一主機，也可位于不同主機上。
• 媒體服務器重定向（Media Server indirection）
  將媒體客戶端重定向至不同媒體服務器。
• 媒體流（Media Stream）
  媒體實例，如聲音流、視頻流等。使用RTP協議時，RTP會話中的Source可以創(chuàng)建一個包含所有RTP和RTCP分組的流。
• 消息（Message）
  RTSP通訊的基本單位，由[15節(jié)]中定義的結構化的八進制位組構成，并通過有連接和無連接協議進行傳輸。
• 參與者（Participant）
  會議參與者，有可能是機器。如媒體錄制、點播服務器。
• 呈現（Presentation）
  呈現使用呈現描述來表示一系列展示給客戶端的流，在大多數RTSP場景下，這表示對所有流的聚合操作，但并非強制。
• 呈現描述（Presentation description）
  呈現描述包含了呈現中所有流的信息，如編碼、網絡地址以及內容信息。其他IETF協議如SDP(RFC 2327[6])使用名詞“會話”來表示運行中呈現。呈現描述有多種格式，包含但不限于SDP格式。
• 回復（Response）
  RTSP回復，與HTTP回復類似
• 請求（Request）
  RTSP請求，與HTTP請求類似
• RTSP會話（session）
  RTSP完整交互過程，如影片播放。典型交互過程包括：
  • SETUP 客戶端建立用于傳輸連續(xù)媒體的機制
  • PLAY/RECORD 開始串流
  • TEARDOWN 關閉串流
• 傳輸初始化（Transport initialization）
  客戶端和服務器間傳輸信息初始化

1.4 協議特性（Protocol Properties）

RTSP具有如下特性：

• 可擴展（Extendable）
  新方法和參數可方便地添加至RTSP
• 易解析（Easy to parse）
  RTSP可被標準HTTP或MIME解析器解析
• 安全性（Secure）
  RTSP重用了Web安全機制，所有的HTTP授權機制如basic、digest授權均可直接使用。甚至RTSP還可以重用傳輸層和網絡層的安全機制。
• 傳輸層獨立性（Transport-independent）
  RTSP可能會使用不可靠數據報協議UDP、可靠數據報協議RDP（RFC 1151，不常用）、或保證了應用層可靠性的可靠流協議如TCP。
• 多服務器兼容（Multi-server capable）
  呈現中的各個媒體流可分布在不同服務器上，客戶端會與不同服務器自動建立多個并行的控制會話，而同步功能則在傳輸層完成即可
• 錄制設備控制（Control of recording devices）
  RTSP可控制錄制和點播設備，當然也能控制可在兩種模式切換的設備（VCR）
• 媒體控制和會議初始化相獨立（Separation of stream control and conference initiation）
  媒體控制在邀請一個媒體服務器進入會議時分割，唯一的前提是會議初始化協議需要提供或可被用于創(chuàng)建一個單獨的會議標識符。實踐中，通常會使用SIP和H.323協議來邀請某個服務器進入會議。
• 適用于專業(yè)應用（Suitable for professional applications）
  RTSP可通過SMPTE時間戳來提供幀精度的遠程數字化編輯
• 中立的呈現描述（Presentation description neutral）
  RTSP并沒有將呈現描述具體化，并且可攜帶當前使用的描述格式。但至少，呈現描述中要包含一個RTSP URI.
• 代理和防火墻親和性（Proxy and firewall friendly）
  RTSP協議可被應用和傳輸層防火墻處理，防火墻可能需要識別SETUP方法，以為特定UDP媒體流開辟通道。
• HTTP親和性（HTTP-friendly）
  由于RTSP明智地重用了HTTP的概念，所以現有的框架都可以被重用，如用于關聯內容和標簽的PICS(Platform for Internet Content Selection)。除此之外，RTSP也不僅僅只是在HTTP基礎上添加方法而已，多數時候，RTSP還需要維護服務器狀態(tài)來實現連續(xù)媒體的控制。
• 恰當的服務器控制（Appropriate server control）
  如果一個客戶端可以開啟一個流，那么理論上它應關閉該流的能力，這種情況下，服務器決不能向客戶端傳輸客戶端本身不能關閉的流。
• 傳輸協商（Transport negotiation）
  客戶端可根據實際需要協商連續(xù)媒體流的傳輸方法
• 能力協商（Capability negotiation）
  如某些基礎特性已禁用，則應該要有一些明確的機制告知客戶端不去實現哪些方法，這使得客戶端可以提供合適的用戶接口。例如，當seeking不支持時。用戶界面應禁止移動滾動條。

1.5 擴展RTSP(Extending RTSP)

由于并非所有媒體服務器都提供相同功能，媒體服務器也自然會支持不同的請求集。例如：

• 一個服務器可能只支持點播，也就不用支持RECORD請求
• 如果一個服務器只支持直播，那么它可能不支持seeking
• 有些服務器并不支持流參數的設置，也自然不需要支持GET_PARAMETER和SET_PARAMETER

*當然服務器必須實現[12小節(jié)]中提及的所有header域，而[H19.6]中所有方法都不用做支持。 *

RTSP可通過三種方式進行擴展，根據變化大小排列如下：

• 已存在方法可添加新參數，接收者也可以安全地選擇忽略新增參數。如果客戶端需要在某個方法擴展部分不支持時得到否定確認，需要在Require: 域中添加標簽（見12.32小節(jié)）
• 可添加新方法，如果接收者不理解該請求，可回復錯誤代碼501（未實現），之后發(fā)送者不應再嘗試使用該方法。客戶端可以使用OPTIONS方法來查詢服務器所支持的方法，服務器則應在公共回復頭（Public response header）中列出所支持的方法
• 可定義新版本協議，幾乎允許變動所有元素

1.6 全局操作（Overall Operations）

每個呈現和流都使用RTSP URL進行標識，整體呈現及媒體其他屬性均定義于呈現描述文件中，用戶可通過HTTP或其他方式（如email）進行獲取，因此呈現描述文件不一定非要存放在媒體服務器上。

對于本篇而言，呈現描述用于描述一至多個呈現，每個呈現維護正常時間軸。為了便于解釋以及保持通用性，這里假設呈現描述中只包含一個這樣的呈現，而每個呈現可能進一步包含多個媒體流。

呈現描述文件包含了組成呈現的所有媒體流的描述，包括編碼、語言及其他供客戶端正確選擇最合適媒體組合的信息。媒體呈現中每個被RTSP獨立控制的媒體流都有一個RTSP URL作為標識，該URL指向媒體流被存放的服務器。不同媒體流可源自不同服務器，例如，音頻和視頻流可能因為負載均衡而被分割至不同服務器。媒體呈現中同樣還枚舉了所有支持的傳輸方式。

除媒體參數外，網絡目標地址和端口必須確認下來，具體需區(qū)分為如下幾類：

• 單播（Unicast）
  媒體傳送至RTSP請求的發(fā)起者，端口由客戶端選擇。
• 多播，服務器選擇地址和端口
  服務器選擇多播地址和端口，典型應用時直播和點播傳輸。
• 多播，客戶端選擇地址和端口
  如果服務器被中途邀請至一個已存在的多播會議，會議描述中會包含地址和端口，具體建立過程不在本篇討論范圍之內。

1.7 RTSP 狀態(tài)

RTSP可能控制一個通過單獨協議、獨立于控制頻道傳輸的流。例如，RTSP可能使用TCP連接來控制通過UDP傳輸的數據流，這樣一來，即使服務器中間沒有收到任何RTSO請求，數據依然可以保持連續(xù)傳送。整個生命周期內，同一個流可能依次被通過不同TCP連接傳輸而來的RTSP請求控制。因此，服務器需要維護會話狀態(tài)以便能夠正確關聯同一個流的RTSP請求。狀態(tài)轉換在[附錄A]中有詳細描述。

RTSP中許多方法并不會改變狀態(tài)，會修改狀態(tài)的方法有如下幾個：

• SETUP
  使服務器為流分配資源并開啟RTSP會話
• PLAY和RECORD
  在SETUP中分配的流上開始數據傳送
• PAUSE
  臨時凍結流，并不會釋放服務器資源
• TEARDOWN
  釋放流相關的資源，服務器上RTSP會話會被停止

會修改會話狀態(tài)的方法會在header域中指明會話標識符以明確方法作用對象，該會話標識符在SETUP步驟中生成。

1.8 與其他協議的關系（Relationship with Other Protocols）

RTSP和HTTP在功能上有重疊的部分，甚至流內容可能會通過網頁形式與HTTP交互獲得。當前協議規(guī)格目標是允許網絡服務器和實現了RTSP的媒體服務器有不同的切換點。如描述實現可通過HTTP或RTSP獲取，這減少了網絡瀏覽場景下的響應時間，當然只通過RTSP服務器和客戶端而不依賴HTTP也是可行的。

然而，RTSP在數據傳輸上與HTTP有本質區(qū)別，因為RTSP是用不同協議以帶外方式傳輸。HTTP是一個不對稱協議，只允許客戶端發(fā)出請求，然后服務器負責回復。而在RTSP中，客戶端和媒體服務器均可以發(fā)出請求。進一步有，RTSP請求是有狀態(tài)的，他們可能需要在請求得到確認應答后才會進一步設置參數和后續(xù)控制。

重用HTTP功能至少帶來了兩個好處，即安全性和代理。所需基礎十分類似，因此擁有在HTTP緩存、代理和認證的能力是十分有益的。

盡管大多數實時媒體均會選擇RTP作為傳輸協議，但RTSP并沒有綁定使用RTP。

RTSP假設呈現描述格式可以表達呈現中媒體流的靜態(tài)和臨時特性。

2. 標志性公約（Notational Conventions）

由于很多定義和語法都與HTTP/1.1相同，因此本規(guī)格只是給出了對應章節(jié)的位置而不是重復拷貝。為了簡短說明，[HX.Y]表示HTTP/1.1當前規(guī)格（RFC 2068）中對應的這章節(jié) X.Y。

文中提到的所有機制都以[H2.1]中使用的ABNF（augmented Backus-Naur form）格式給出，ABNF在RFC 2234中有詳細說明，with the
difference that this RTSP specification maintains the "1#" notation
for comma-separated lists.

3. 協議參數

3.1 RTSP版本

RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT

3.2 RTSP URL

"rtsp"和"rtspu"用于在RTSP協議中關聯網絡資源。

rtsp_URL = ("rtsp:" | “rtspu:") "http://" host [":" port] [abs_path]

注意：上述字段均無嚴格定義，最終解釋權歸RTSP服務器所有

rtsp表示使用可靠協議傳輸（如TCP），而rtspu表示使用不可靠協議傳輸（如Internet, UDP）。
如port未給出，則默認使用554端口。字段中盡量避免直接使用IP地址，而應該使用域名代替。

描述或流均通過文本形式的媒體標識符進行表示，URL可能指向某一個流，也可能指向一系列聚合流。注意有的方法只能針對流或只能針對呈現，不能混用。

rtsp://media.example.com:554/twist/audiotrack   只操作audio
rtsp://media.example.com:554/twist              聚合操作

注意上述各字段暫無公認定義，最終解釋權仍舊歸屬于RTSP服務器，應盡量避免在URL中直接使用IP地址。

3.3 會議標識符（Conference Identifiers）

會議標識符使用標準URI編碼方式編碼，對RTSP是不透明的。標識符中可包含任意八進制值，但標識符必須是全局唯一的。

conference-id = 1*xchar

RTSP會話可使用會議標識符來獲取媒體服務器要加入的多媒體會議參數，這些會議由本篇外協議創(chuàng)建，如H.323或SIP。與通常由RTSP客戶端提供傳輸信息相反，這種情況下通常媒體服務器直接使用直接會議描述值。

3.4 會話標識符（Session Identifiers）

會話標識符以變長字符串形式存在，中間如有空格，則以URL轉義。會話標識符必須隨機選擇且至少八位八進制值以上，以避免與現有標識符發(fā)生沖突。

session-id = 1*(ALPHA | DIGTI | safe)

3.5 SMPTE相對時間戳（SMPTE Relative Timestamps）

SMPTE表示當前相對于起始位置（start）的時間，使用SMPTE時間格式（hours:minutes:seconds:frames.subframes）的相對時間戳可以達到幀級別精度。SMPTE格式默認值為“SMPTE 30 drop”格式，對應到幀率為29.97fps。其他SMPTE碼值（如SMPTE 25）可能通過使用替代的"smpte time"進行支持。幀率30和幀率29.97的主要區(qū)別是29.97會丟掉每分鐘的前兩幀，但每第十分鐘跳過丟棄操作。如smpte-time值為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]

Examples:
    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 正常播放時間（Normal Play Time）

NPT表示從開始呈現到現在流的絕對位置，該時間戳包含一個十進制小數，小數點左側的可能是小時、分鐘和秒，右側部分則為秒的小數部分。

呈現開始位置NPT值為0.0秒，不能去負值。特殊常量now定義于直播場景下表示當前實例，它可能僅在直播情境下被支持。

直觀地講，NPT是聯系用戶和程序的時鐘，它經常以數字形式顯示在VCR上，當播放速率為1時，它正常遞增；當大于1時，加速遞增；當小于-1時，加速遞減，直到經過pause狀態(tài)時恢復為1。邏輯上講，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-69

Examples:
    npt=123.45-125
    npt=12:05:35.3-
    npt=now-

其語法符合ISO 8601. npt-sec概念主要用于自動化生成，npt-hhmmss概念則是為了便于用戶閱讀。
常量"now"則用于在直播情境下實時獲取當前時間戳而非存儲或有延遲的版本。

3.7 絕對時間（Absolute Time）

絕對時間使用UTC標準，遵循ISO 8601時間戳格式。

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>

Example:
    19961108T143720.25Z

3.8 選項標簽（Option Tags）

選項標簽是RTSP中用于指派新選項的唯一標識符，這些標簽在Require[12.32小節(jié)]和Proxy-Require[12.27小節(jié)]header域中使用。

option-tag = 1*xchar

RTSP選項的創(chuàng)建者可以選擇以倒置的域名作為前綴，或在IANA上注冊新的選項。

3.8.1 IANA注冊新選項標簽（Registering New Option Tags with IANA）

在注冊新RTSP選項時，需提供如下信息：

• 選項名稱及描述，名稱長度可變，但建議小于20字符長度。同樣，名稱不建議包含空格等特殊字符
• 指明選項修改控制權歸屬，如IETF，ISO，ITU-T及其他國際化標準組織
• 盡可能提供詳述連接，如RFC
• 聯系方式，如email

4. RTSP消息（RTSP Message）

RTSP是文本協議，使用ISO 10646字符集，并采用UTF-8編碼。文本行通常以CRLF結尾，但接收者應做好以CR/LF為行尾標志的準備。

文本協議使得以自我描述的方式添加新參數成為可能，基于參數個數以及命令使用頻率較低，效率部分可不必過分在意。如果謹慎處理文本協議，還可以更好地與腳本語言如Tcl，Visual Basic及Perl進行對接。  

RTSP消息可通過任何8-bit clean(每個字符使用8位傳輸)的傳輸層協議傳輸。

RTSP包含方法、作用對象及進一步調整方法的參數。方法可設計為需要少量或完全不需要服務器配合維護狀態(tài)。

4.1 消息類型（Message Types）

RTSP-message = Request | Response   

考慮到健壯性，服務器應忽略任何在期望收到請求行時收到的空白行CRLF。

4.2 消息頭（Message Headers）

RTSP-header = field-name ":" [field-name] CRLF

4.3 消息體（Message Body）

僅在使用傳輸編碼時消息體和實體主體才有所不同

message-body = entity-body | <entity-body encoded as per Transfer-Encoding>

4.4 消息長度（Message Length）

當消息中包含消息體時，body長度按如下次序進行確認：

• 回復消息中不允許包含消息體，通常會在header域后的空行終止
• Content-Length 默認值為0，如不為0則其值為消息體字節(jié)數
• 服務器關閉連接時

注意RTSP并不支持HTTP/1.1中塊傳輸編碼，它要求必須要有Content-Length字段。

5. 通用頭域（General Header Fields）

general-header = Cache-Control | Connection | Date | Via

6. 請求（Request）

Request = Request-Line 
        *( general-header | request-header | entity-header )
        CRLF
        [ message-body ]

6.1 Request Line

Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Method = "DESCRIBE" 
        | "ANNOUNCE" 
        | "GET_PARAMETER" 
        | "OPTIONS" 
        | "PAUSE" 
        | "PLAY"
        | "RECORD" 
        | "REDIRECT" 
        | "SETUP" 
        | "SET_PARAMETER" 
        | "TEARDOWN"
        | extension-method
extension-method = token
Request-URI = "*" | absolute_URI
RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT

6.2 Request Header Fields

request-header = Accept
                | Accept-Encoding
                | Accept-Language
                | Authorization
                | From
                | If-Modified-Since
                | Range
                | Referer
                | User-Agent

注意：與HTTP/1.1不同，RTSP請求中始終使用絕對URL，而非只是用絕對路徑。

RTSP-URI中'*'表示請求并非針對某一特定資源，而是針對服務器本身，且該方式只能在不針對特定資源時使用。舉例如下：

OPTIONS * RTSP/1.0

7 回復（Response）

回復除了HTTP-Version字段替換為RTSP-version外，基本沿用了HTTP中內容。當然，RTSP還選擇性實現了一些HTTP狀態(tài)碼，并增加了部分特定狀態(tài)碼。

Response = Status-Line
        *(general-header
        | response-header
        | entity-header)
        CRLF
        [meassage-body]

7.1 狀態(tài)行（Status-Line）

Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF

結尾處必須以CRLF標志結尾，不允許以CR或LF形式單獨存在

7.1.1 狀態(tài)碼和原因詞組（Status Code and Reason Phrase）

狀態(tài)碼是一個3位十進制數，表示對端對于之前請求的理解和執(zhí)行狀態(tài)。這些狀態(tài)碼在11小節(jié)會完整列出，便于機器識別。
原因詞組意在給出狀態(tài)碼的簡略文本描述，便于用戶讀取。客戶端并不要求去檢查或顯示狀態(tài)詞組。

狀態(tài)碼首位用于定義不同類型的回復，其余兩位暫未定義：

• 1xx: 提示信息（Informational）- 請求已收到，處理中
• 2xx：成功（Success）- 操作已被成功接收、理解并執(zhí)行
• 3xx：重定向（Redirection）- 需進一步操作以完成整個請求
• 4xx：客戶端錯誤（Client Error）- 請求中包含錯誤語法或不完整
• 5xx：服務器錯誤（Server Error）- 服務器無法正確執(zhí)行請求

下面列出RTSP/1.0中特有的狀態(tài)碼及原因詞組：

Status-Code = "100"     ; Continue
            | "200"     ; OK
            | "201"     ; Created
            | "250"     ; Low on Storage Space
            | "300"     ; Multiple Choices
            | "301"     ; Moved Permanently
            | "302"     ; Moved Temporarily
            | ”303“     ; See Other
            | "304"     ; Not Modified
            | "305"     ; Use Proxy
            | "400"     ; Bad Request
            | "401"     ; Unauthorized
            | "402"     ; Payment Required
            | "403"     ; Forbidden
            | "404"     ; Not Found
            | "405"     ; Method Not Allowed
            | "406"     ; Not Acceptable
            | "407"     ; Proxy Authentication Required
            | "408"     ; Request Time-out
            | "410"     ; Gone
            | "411"     ; Length Required
            | "412"     ; Precondition Failed
            | "413"     ; Request Entity Too Large
            | "414"     ; Request-URI Too Large
            | "415"     ; Unsupported Media Type
            | "451"     ; Parameter Not Understood
            | "452"     ; Conference Not Found
            | "453"     ; Not Enougn Bandwidth
            | "454"     ; Session Not Found
            | "455"     ; Method Not Valid in This State
            | "456"     ; Header Field Not Valid for Resource
            | "457"     ; Invalid Range
            | "458"     ; Parameter Is Read-Only
            | "459"     ; Aggregate operation not allowed
            | "460"     ; Only aggregate operation allowed
            | "461"     ; Unsupported transport
            | "462"     ; Destination unreachable
            | "500"     ; Internal Server Error
            | "501"     ; Not Implemented
            | "502"     ; Bad Gateway
            | "503"     ; Service Unavailable
            | "504"     ; Gateway Time-out
            | "505"     ; RTSP Version not supported
            | "551"     ; Option not supported
            | extension-code
            
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>

RTSP狀態(tài)碼是可擴展的，RTSP應用并不要求支持所有已注冊狀態(tài)碼，當然能夠支持則更好。但是，應用必須了解狀態(tài)碼的分類，在碰到不能識別的狀態(tài)碼時應將其等同于x00，并將不能識別的回復進行緩存。

舉個例子，客戶端收到一個不能識別的狀態(tài)碼431，它完全可以將其等同于400，并認定是自己發(fā)出的請求出現了問題。在這種情況下，由于實體（entity）中通常會包含關于異常的可讀信息，因此客戶端應該要將的實體部分呈獻給用戶。

7.1.2 回復頭域（Response Header Fields）

回復頭域中傳遞了狀態(tài)行不能表達的額外信息，這些頭域中給出了服務器和通過Request-URI標識的資源的其他信息。

response-header = Location
                | Proxy-Authenticate
                | Public 
                | Retry-After
                | Server
                | Vary
                | WWW-Authenticate

回復頭域名稱只有和協議版本一塊修改時才能保證可靠性，也就是說，只有當通訊的所有參與者都能正確識別某一字段為回復頭域時，才會將其新增至頭域中。不能識別的頭域則會統(tǒng)一視為實體頭域（entity-header fields）。

8 實體（Entity）

如請求方法和回復狀態(tài)碼未限制，可在請求或回復中傳輸實體。一個實體由實體頭和實體主體（entity-body）組成，雖然有些回復中只有實體頭部分。

本節(jié)中客戶端和服務器均可能成為發(fā)送端和接收端，身份依具體情況而定。

8.1 實體頭域（Entity Header Fields）

實體頭域定義了關于實體主體的可選元信息，或當主體不存在時用于描述請求中的資源描述符。

entity-header   = Allow
                | Content-Base
                | Content-Encoding
                | Content-Language
                | Content-Length
                | Content-Location
                | Content-Type
                | Expires
                | Last-Modified
                | extension-header
extension-header = message-header

可擴展頭機制使得不修改協議的情況下也可以增加頭域成為可能，但這些域接收端不一定能夠識別，對于不能識別的域，接收端可直接忽略并傳遞給代理。

8.2 實體主體（Entity Body）

實體主體只在請求方法有要求時才會被放到請求消息中，且會再Content-Length中指明是否存在主體部分。

9 連接（Connections）

RTSP請求可通過如下三種方式傳送：

• 永久性連接，貫穿數個交互（請求/回復） -> rtsp
• 易失性連接，每次交互單獨建立 -> rtsp
• 無連接方式，如UDP -> rtspu

傳輸連接的類型由RTSP URI定義。與HTTP不同的是，RTSP允許服務器向客戶端發(fā)送請求，但這只能在使用永久性連接時才行，因為除此之外媒體服務器沒有其他可靠方法能夠與客戶端聯系。同時，這也是媒體服務器可穿透防火墻和客戶端通訊的唯一方式。

9.1 流水操作（Pipelining）

支持永久性連接或無連接模式的客戶端可將其請求流水線化后發(fā)出，對應的有，服務器也必須按接收到的請求次序進行回復。

9.2 可靠性和確認應答（Reliability and Acknowledgements）

除非請求是發(fā)送給廣播組的，否則接收者收到請求后必須被確認應答。如果沒有確認應答，那么發(fā)送者會在觸發(fā)往返時間RTT(round-trip time)延時后，重新發(fā)送同一條消息。往返時間RTT是由TCP進行動態(tài)評估的，其初始值為500ms。部分RTSP實現可能會選擇緩存最后一個RTT內所有操作，以作為后續(xù)連接的初始狀態(tài)。

但如果傳輸層協議是TCP時，則不應手動重傳，而是依賴TCP所提供的可靠性機制。

如果TCP和RTSP同時重傳請求，那么有可能每個分組（packet）丟失都會引起兩次重傳，接收者也無法真正從應用層重傳中獲益，因為只有當傳輸層重傳抵達接收端后，才會開始傳遞應用層的重傳分組。更糟糕的是，如果丟失是由與帶寬饑荒（congestion）引起，那么多次重傳反而會加重饑荒程度。

頭中時間戳字段用于配合重傳機制，同時也為Kam的算法提供支持。

每個請求頭中都有一個單調遞增的序號CSeq，需要重傳時，將使用原始CSeq。

實現RTSP系統(tǒng)時必須支持通過TCP傳輸RTSP，然后可選擇實現基于UDP的RTSP。RTSP服務器（TCP或UDP）默認端口為554。

一些發(fā)給相同控制終端的RTSP分組可能被打包入PUD或封裝進TCP流，RTSP數據可與RTP或RTCP分組交錯。與HTTP不同的是，RTSP消息中必須含有Content-Length頭，即使消息中并無負載。此外，RTSP分組通過最后一個消息頭后的空行直接終止。

10 方法定義（Method Definitions）

方法符標識作用于Request-URI指代資源的方法，它是大小寫敏感的，且命名時不應以‘$’開頭。未來可添加新方法。

P: 呈現（Presentation），S:流（Stream）

PAUSE推薦實現，但也不是必須的，如直播情境。如果一個服務器不支持某一方法，它必須返回“501未實現”錯誤，且之后客戶端不應再嘗試請求該方法。

10.1 OPTIONS

OPTIONS請求可能在任意時刻發(fā)出，如客戶端嘗試非標準化請求，并不會影響服務器狀態(tài)。

示例：
    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'頭中指定客戶端可以理解的描述信息的格式。服務器則返回請求資源所對應的描述信息。DESCRIBE請求-回復對構成了整個RTSP初始化過程。

示例：
    C->S:   DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
            CSeq: 1
            Accept: application/sdp, application/rtsl, application/mheg
        
    S->C:   RTSP/1.0 200 OK
            CSeq: 312
            Date: 23 Jan 1997 15:25:06 GMT
            Content-Type: applicaiton/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
            e=mjh@isi.edu(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回復中必須包含所描述的資源初始化相關所有媒體信息，如果客戶端從別處獲取了內含完整媒體初始化參數的呈現描述pd，那么客戶端應該直接使用那些參數而不用通過RTSP重復請求描述信息。

此外，服務器不能將DESCRIBE回復作為媒體重定向的方法。

無規(guī)矩不成方圓，客戶端應當明確DESCRIBE方法僅用于獲取媒體初始化信息，而不能用來實現媒體重定向。我們也通過其他方法來避免循環(huán)問題（looping problems）。

對基于RTSP的系統(tǒng)而言，媒體初始化是必不可少的部分，但RTSP規(guī)格中并沒有嚴格指出初始化必須通過DESCRIBE方法。事實上，RTSP客戶端通常有如下3種方法來獲取初始化信息：

• 通過DESCRIBE方法
• 通過其他協議，如HTTP，email附件等
• 命令行或其他標準輸入（類似網絡幫助文件，內容sdp或其他媒體格式文件）

實踐中，十分推薦精簡版服務器去支持DESCRIBE方法，而精簡版服務器則十分推薦持根據使用環(huán)境從標準輸入、命令行或其他方式中獲取媒體初始化文件。

10.3 ANNOUNCE

ANNOUNCE方法有兩個用途：

• 從服務器發(fā)送給客戶端時：用于更新實時會話描述
• 從客戶端發(fā)送給服務器時：推送URL指定的呈現或媒體對象的描述

如果呈現途中插入新流，應重發(fā)完整描述，而不僅僅是增量。這樣一來，也就支持了動態(tài)移除組件。

示例：
    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
            e=mjh@isi.edu (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

SETUP請求用于為URI指定傳輸機制，客戶端可以發(fā)出SETUP請求來改變運行中流的傳輸參數（如服務端不支持，需返回“455 當前狀態(tài)不支持該方法”），為了盡可能利用交錯的防火墻，客戶端必須指明其傳輸參數，即使并無實際影響（如服務器通知一個廣播組地址）。

示例：
    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
            Tranport: RTP/AVP;unicast;client_port=4588-4589;server_port=6256-6257

服務器在SETUP回復中生成了會話標識符（Session），如SETUP請求中已有會話標識符，則服務器應當要么綁定至該會話，要么回復“459聚合操作被禁止”。

10.5 PLAY

PLAY方法通知服務器使用SETUP中確定的機制開始傳輸數據，客戶端不應在SETUP請求未被確認應答成功前發(fā)出PLAY請求。

PLAY請求將正常播放時間（Normal Play Time）置為指定范圍的開始端，并傳輸數據直到抵達范圍的末端。PLAY請求可能被隊列化，即需要排隊；服務器必須依次處理隊列中的PLAY請求。也就是說，后到的PLAY請求必須等待前一個請求處理完成后才能進行處理。

這使得精細編輯成為可能。

舉例來說，無論兩個PLAY請求到達服務器時有多接近，服務器依然會先播放10s_{15s內容，然后20s}25s，并最終從30s到結束。

C->S:   PLAY rtsp://audio.example.com/audio RTSP/1.0
        CSeq: 835
        Session: 12345678
        
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-

沒有Range頭的PLAY請求是合法的，它會從頭開始播放流（除非流已被暫停PAUSE），而如果流已處于暫停狀態(tài)，則從暫停點開始播放。如果一個流正處于播放狀態(tài)，那么新的PLAY請求不會有任何作用，因此可被用于測試服務器是否在線（liveness）。

Range頭中也可能存在時間參數，該參數使用UTC標準時間，它指定了開始播放的時間點。如請求到達時已經過了指定時間點，則立即開始播放。時間參數還可用于同步從不同源獲得的流。

對于一個點播流而言，服務器回復將播放的準確Range，該值可能與請求的Range有所不同，因為需根據實際的幀邊界來重新對齊。如請求中未指定range，回復中返回當前位置。請求和回復將使用同一單位。

當播放完指定Range后，呈現將自動暫停，就像有收到PAUSE請求一樣。

示例：
    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

播放一個直播中錄制的流，可能需要使用clock單位：

    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時間格式，而clock和smpte格式則是可選的。

10.6 PAUSE

PAUSE請求會臨時終端流傳輸，如果URL指定的是某一個流，則該流的播放和錄制會被暫停。例如，對于音頻而言，相當于靜音操作。如果URL指定的是一組流，則呈現或組中所有活動流將會被暫停。當恢復播放或錄制時，所有軌道的流必須進行同步。
此過程中，所有服務器資源均會保留，除非SETUP時，頭中有參數指定延時，那么服務器可能在觸發(fā)延時后關閉會話并釋放資源。

示例：
    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請求中可能包含Range頭以指定何時暫停流或呈現，我們將這個點成為暫停點（pause point），該頭中必須指定某一個點而不是時間范圍。正常播放時間會設置給暫停點，當服務器第一次碰到暫停點時，暫停請求生效。如果設置的暫停點不在播放段中，則返回“457無效Range”錯誤。如媒體單元（如音視頻幀）正好從暫停點開始播放，那么將不會有任何效果。如不存在Range頭，則立即暫停現有狀態(tài)。

PAUSE請求會忽略所有隊列中的PLAY請求，無論如何，媒體流中的暫停點都是需要被維護的。當然后續(xù)PLAY不帶Range參數時，將從暫停點開始恢復。

舉個例子，假如一個服務器收到兩個PLAY請求，范圍分別是10_15s，2029s，然后緊接著收到NPT21s為暫停點。那么服務器會再播放完第一段后停在NPT21。而如果當服務器在已經播放到13s時收到一個NPT12暫停點的請求，那么將會立即暫停。再假設暫停點為NPT16，那么服務器將在完整播放完第一段后忽略第二段播放請求，進入暫停狀態(tài)。

如果收到請求時，服務器已發(fā)出Range外數據，那么PLAY操作仍然會從指定點開始恢復，因為它假設客戶端會忽略暫停點后的數據。這樣一來，才能夠保證連續(xù)的PAUSE/PLAY循環(huán)。

10.7 TEARDOWN

TEARDOWN請求將會停止URI指定的流傳輸，并釋放關聯資源。如果URI關聯的是一個呈現，那么RTSP會話標識符將不再有效。停止后，除非所有傳輸參數都通過繪畫描述來定義，否則重新播放前必須發(fā)出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

10.9 SET_PARAMETER

SET_PARAMETER請求用于設置URI指定呈現或流的參數值。

每條請求應當只包含一個參數以允許客戶端確定失敗原因，如果請求中包含多個參數，服務器必須只在所有參數都能成功設置情況下生效。服務器應當允許同一參數多次設置同一值，但可拒絕設置為不同值。

注意：媒體流傳輸參數必須通過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

10.10 REDIRECT

REDIRECT請求用于提示客戶端它必須連接至另一個服務器，其中強制包含了Location頭，以指明新的服務器URL。其中還可能包含Range參數，指明何時重定向將生效。如果客戶端希望向該URI發(fā)送和接收媒體，則客戶端必須先對當前會話發(fā)出TEARDOWN請求，然后向目標主機發(fā)出SETUP請求新的會話。

示例：
    S->C:   REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
            CSeq: 732
            Location: rtsp://bigserver.com:8001
            Range: clock=19960213T143205Z-

10.11 RECORD

RECORD方法用于開始錄制當前呈現描述中的一段媒體數據，UTC格式時間戳包含開始點和結尾點。如未給出時間范圍，則使用呈現描述中的開始點和結尾點。如會話已處于運行中，則立即開始錄制。

服務器決定將錄制數據保存在請求URI或其他URI，如使用其他URI，需回復“201（Created）”并包含實體以描述請求狀態(tài)和新資源位置信息。

一個支持直播情境下錄制的服務器必須支持clock格式，這里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 嵌入式二進制數據（Embedded(Interleaved) Binary Data）

某些防火墻設計或其他環(huán)境因素可能迫使服務器將RTSP方法交錯進流數據中。該種交錯操作應盡可能避免，因為它提高了客戶端和服務器操作的復雜度，也增加了額外的開銷。嵌入式二進制數據應當只在RTSP通過TCP傳輸時使用。

示例：
    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 狀態(tài)碼定義（Status Code Definitions）

RTSP盡可能重用HTTP狀態(tài)碼，這里不再重復相同部分。

11.1 Success 2xx

11.1.1 250 Low on Storage Space

當服務器收到RECORD請求后發(fā)現由于沒有足夠磁盤空間來存放錄制內容時，將會返回該警告信息。如有可能，服務器應當使用Range頭指明哪一段可被錄制。由于服務器其他進程可能同時消耗磁盤空間，因此該警告信息僅供參考。

11.2 Redirection 3xx

RTSP中，重定向可能用于負載均衡或將請求交給拓撲上更靠近客戶端的服務器。確認拓撲上是否更接近的機制不在本規(guī)格中討論。

11.3 Client Error 4xx

11.3.1 405 Method Not Allowed

請求的方法并不允許作用于URI所指定資源，回復中需列出所支持的方法列表。該狀態(tài)碼還可用于回復SETUP申請外的方法。

11.3.2 451 Parameter Not Understood

請求接收者不支持其中一個或多個參數。

11.3.3 452 Conference Not Found

媒體服務器無法識別會議頭域中的會議。

11.3.4 453 Not Enough Bandwidth

因為帶寬不足而拒絕請求，如預留資源失敗

11.3.5 454 Session Not Found

會話頭中的RTSP會話標識符未找到、無效或已過期

11.3.6 455 Method Not Valid in This State

客戶端或服務器在當前狀態(tài)下不能處理請求，回復中應包含Allow頭以便于錯誤恢復

11.3.5 456 Header Field Not Valid for Resource

服務器不能使某一必需的請求頭生效，如PLAY請求中包含Range頭域，但服務器不允許seeking。

11.3.8 457 Invalid Range

給定的Range越界，如超出呈現的結尾點

11.3.9 458 Parameter Is Read-Only

SET_PARAMETER設置的參數只讀，不能被修改

11.3.10 459 Aggregate Operation Not Allowed

請求的方法不能作用于聚合URL，該方法可能只支持作用于流URL。

11.3.11 460 Only Aggregate Operation Allowed

請求的方法不能作用于非聚合URL，該方法可能只支持作用于聚合URL。

11.3.12 461 Unsupported Transport

傳輸域中未包含支持的傳輸規(guī)格

11.3.13 462 Destination Unreachable

因為客戶端地址不可達而不能建立數據傳輸通道。該錯誤也可能由客戶端在傳輸域中存放了無效的目標地址造成。

11.3.14 551 Option not supported

不支持Require或Proxy-Require域中給定選項，回復中必須指明不支持哪個選項