轉載地址：http://blog.csdn.net/sendy888/archive/2007/12/19/1953288.aspx

實時流協議(RTSP)
( Real Time Streaming Protocol (RTSP) )

備忘錄的狀態：

本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建議以得到改進。請參考最新版的“Internet正式協議標準”(STD1)來獲得本協議的標準化程度和狀態。本備忘錄的發布不受任何限制。

版權為The Internet Society 所有。所有權利保留。

摘要：

實時流協議（RTSP）是應用層協議，控制實時數據的傳送。RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻的受控、點播成為可能。數據源包括現場數據與存儲在剪輯中數據。該協議目的在于控制多個數據發送連接，為選擇發送通道，如UDP、組播UDP與TCP，提供途徑，并為選擇基于RTP(RFC1889)上傳送機制提供方法。

1 緒論      5
1.1 目的      5
1.2 要求      6
1.3 術語      6
1.4 協議特點      7
1.5 RTSP擴展      8
1.6 操作模式      9
1.7 RTSP狀態      9
1.8 與其他協議關系      10
2 符號協定      10
3 協議參數      10
3.1 RTSP版本      10
3.2 RTSP URL      11
3.3 會議標識      13
3.4 會話標識      13
3.5 SMPTE 相對時間戳      13
3.6正常播放時間      14
3.7 絕對時間      15
3.8 選擇標簽      15
3.8.1 用IANA注冊新的選擇標簽      15
4 RTSP消息      15
4.1 消息類型      16
4.2 消息標題      17
4.3 消息主體      17
4.4 消息長度      18
5 普通標題域      18
6 請求      19
6.1 請求隊列      19
6.2 請求標題域      19
7 回應      20
7.1 狀態行      20
7.1.1 狀態代碼和原因分析      20
7.1.2 回應標題域      23
8 實體      23
8.1 實體標題域      24
8.2 實體主體      24
9 連接      25
9.1 流水線操作      25
9.2 可靠性及確認      25
10 方法定義      25
10.1 選擇      26
10.2 描述      26
10.3 通告      26
10.4 建立      26
10.5 播放      27
10.6 暫停      27
10.7 斷開      27
10.8 獲取參數      28
10.9 設置參數      28
10.10 重定向      28
10.11 錄制      29
10.12 嵌入二進制數據      29
11狀態代碼定義（Status Code Definitions）      29
11.1成功2xx（Success 2xx）      30
11.1.1 存儲空間低 250      30
11.2 重定向（Redirection 3xx）      31
11.3 客戶端錯誤（Client Error ）4xx      31
11.3.1方法不允許      32
11.3.2參數不能理解      32
11.3.3會議未找到      33
11.3.4 帶寬不足      33
11.3.5 會話未找到      34
11.3.6 本狀態下該方法無效      34
11.3.7 標題域對資源無效      34
11.3.8 無效范圍      35
11.3.9 參數只讀      35
11.3.10 不允許合操作      36
11.3.11 只允許合操作      36
11.3.12 不支持的傳輸      36
11.3.13 目標不可達      37
11.3.14 選擇不支持      37
12 標題域定義（Header Field Definitions）      38
12.1 接受      38
12.2 接受編碼      38
12.3 接受語言      39
12.4 允許（Allow）      39
12.5 授權（Authorization）      40
12.6 帶寬      40
12.7 塊大小      40
12.8 緩存控制      41
12.9 會議      41
12.10 連接      41
12.11 基本內容      42
12.12 內容編碼（Content-Encoding）      42
12.13 內容語言      43
12.14 內容長度（Content-Length）      43
12.15 內容位置      43
12.16 內容類型（Content-Type）      44
12.17 序列號      44
12.18 日期（Date）      44
12.19 過期（Expires）      45
12.20 來自（From）      45
12.21 主機      45
12.22 如果匹配      45
12.23 從何時更改（If-Modified-Since）      46
12.24 最近更改（Last-Modified）      46
12.25 位置（Location）      46
12.26 代理授權      47
12.27 代理要求      47
12.28 公用性      47
12.29 范圍      49
12.30 提交方（Referer）      49
12.31 稍后再試      49
12.32 要求      49
12.33 RTP信息      49
12.34 比例      49
12.35 速度      49
12.36 服務器（Server）      49
12.37 會話      49
12.38 時間戳      49
12.39 傳輸      49
12.40 不支持      49
12.41 用戶代理（User-Agent）      49
12.42 變化      49
12.43 通過      49
12.44 WWW-授權（WWW-Authenticate）      50
13 緩存      50
14 實例      50
14.1 要求媒體（單播）      50
14.2 容器文件的流      51
14.3 單個流容器文件      51
14.4 組播現場媒體表示      51
14.5 在存在的會話中播放媒體      51
14.6 錄制      52
15 語法      52
15.1 基本語法      52
16 安全考慮（Security Considerations）      52
附錄A RTSP協議狀態機      53
A.1 客戶端狀態機      53
A.2 服務器端狀態機      53
附錄B 同RTP協議的交互      53
附錄C 使用SDP進行RTSP會話描述      54
C.1 定義      54
C.1.1 控制URL      55
C.1.2 媒體流      55
C.1.3 有效載荷類型      55
C.1.4 詳細格式參數      55
C.1.5 表示的范圍      56
C.1.6 有效時間      56
C.1.7 連接信息      56
C.1.8 實體標簽      57
C.2 合控制不可用      57
C.3 合控制可用      57
附錄D 最簡單的RTSP實現      58
D.1 客戶端      58
D.1.1回放      58
D.1.2 授權      58
D.2 服務器      59
D.2.1回放      59
D.2.2授權      59
附錄E 作者地址      60
附錄F 致謝      60
參考書目      60
版權申明      61

1 緒論
1.1 目的
實時流協議（RTSP）建立并控制一個或幾個時間同步的連續流媒體。盡管連續媒體流與控制流有可能交叉，但RTSP本身通常并不發送連續媒體流。換言之，RTSP充當多媒體服務器的網絡遠程控制。

表示描述(presentation description)定義了被控流，但本文并沒有定義表示描述的格式。

這里沒有使用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中解釋。
1.3 術語
一些術語原由HTTP/1.1采用。在HTTP/1.1中定義的術語這里不再列舉。

合控制：
服務器使用單條時間線對多個流的控制。對音頻/視頻回饋來講，這就意味著客戶端僅需發送一條播放或者暫停消息就可同時控制音頻和視頻的回饋。
會議：
多方參與的多媒體表示，這里的多方意味著大于或者等于一方。
客戶端：
指請求媒體服務器上連續流媒體數據的客戶端。
連接：
      兩個應用程序以通訊為目的在傳輸層建立虛擬電路。
容器文件：
      可以容納多個共同播放時包含表示(presentation)的媒體流的文件。RTSP服務器可以為這些容器文件提供合控制，但容器文件的概念本身并不是本協議內容。
連續媒體：
      接受器和數據源之間存在時序關系的數據。也就是說，接受器需要重新產生存在于源數據中的時序關系。最普通的連續媒體的例子是音頻和動畫視頻。連續媒體可以是實時的（但是不交互的），它們在源和接受器之間是一種緊密的時序關系；或者是流的形式，這種關系就沒有那么嚴格了。
實體：
作為請求或者回應的有效負荷傳輸的信息。由以實體標題域（entity-header field）形式存在的元信息和以實體主體（entity body）形式存在的內容組成，如第八章所述。
媒體的初始化：
數據類型/編碼的具體初始化，這些包括時鐘輸率，顏色表等。用戶請求媒體回放的任何獨立傳輸信息，是在創建流時初始化媒體流相位時產生的。
媒體參數:
針對回放前或回放過程中有可能改變的媒體類型而專門設定的參數。
媒體服務器：
可對一個或多個媒體流提供回放和錄制服務的服務器。同一個表示(presentation)中不同的媒體流可能來自于不同的媒體服務器。媒體服務器可以建立在作為傳送請求表示(presentation)的Web服務器的主機上，也可以建立在不同的主機上。
媒體服務器重定向：
      重新定向媒體客戶端到另外一個媒體服務器。
(媒體)流：
      單個媒體實例，比如，在應用中共用音頻流或視頻流。當使用RTP時，流包括由RTP 會話(session)中源所創建的所有RTP和RTCP包。這和定義DSM-CC流時相同。
消息：
RTSP通訊的基本單元。由15章語法定義的一串八位位組組成，并通過連接或者無連接協議傳送。
參與者：
一個會議成員。參與者可以是機器，比如是媒體記錄或回放服務器。
表示(presentation)：
對用戶請求所回饋的一組流，其使用下面的表示描述(presentation description)形式。在本文中的多數情況下，其意味著對流進行總體控制，但這并不是必須的。
表示描述(presentation description)：
表示描述包含在表示(presentation)中一個或者多個媒體流的信息。比如，編碼，網絡地址和內容的信息。另外，其他IETF協議，如SDP協議使用會話(session)代替現場presentation。表示描述可以采用包括會話描述(session description)SDP在內的多種格式。
回應：
?，TSP回應。如果能理解HTTP回應，就能清楚的理解RTSP回應。
請求；
?，TSP請求。如果能理解HTTP請求，就能清楚的理解RTSP請求。
RTSP會話(session)：
RTSP交互的全過程。比如，一個電影的觀看過程。會話(session)包括由客戶端建立連續媒體流傳輸機制(SETUP)，使用播放(PLAY)或錄制(RECORD)開始傳送流，用停止(TEARDOWN)關閉流。
傳輸初始化：
客戶端和服務器端之間傳輸信息（端口號，傳輸協議等）的交互。
1.4 協議特點
RTSP 特性如下：
可擴展性：
　 RTSP中很容易加入新方法和參數。
易解析：
　 RTSP可由標準 HTTP或MIME解析器解析。
安全：
RTSP使用網頁安全機制。所有HTTP授權機制如basic和digest授權都可直接使用。也可以傳輸層或網絡層安全機制。
獨立于傳輸：
RTSP可使用不可靠數據報協議（UDP）、可靠數據報協議（RDP），如要實現應用級可靠，可使用可靠流協議。
多服務器支持：
表示(presentation)中的每個流可放在不同服務器上，用戶端自動同不同服務器建立幾個并發控制連接，媒體同步在傳輸層執行。
記錄設備控制：
　協議可控制記錄和回放設備，也可控制可在記錄和回放切換的設備。
流控與會議開始分離：
流控與邀請媒體服務器入會分離；僅要求會議初始化協議提供，或可用來創建唯一會議標識號。特殊情況下， SIP或H.323 可用來邀請服務器入會。
適合專業應用：
　通過SMPTE 時標，RTSP支持幀級精度，允許遠程數字編輯。
表示描述中立：
協議沒強加特殊表示或元文件，可傳達所用格式類型；然而，表示描述至少必須包含一個RTSP URI。
代理與防火墻友好：
協議可由應用和傳輸層防火墻處理。防火墻需要理解SETUP方法，為UDP媒體流打開一個\"缺口\"。
HTTP友好：
此處，RTSP明智的采用HTTP觀念，使現在結構都可重用。結構包括Internet 內容選擇平臺（PICS）。由于在大多數情況下控制連續媒體需要服務器狀態， RTSP不僅僅向HTTP 添加方法。
適當的服務器控制：
　如用戶能啟動一個流，它必須也能停止一個流。服務器不能啟動一個用戶不能停止的流。
傳輸協調：
　實際處理連續媒體流前，用戶可協調傳輸方法。
性能協調：
如基本特征無效，必須有一些清理機制讓用戶決定那種方法沒生效。這允許用戶提出適合的用戶界面。例如，如果不允許尋找，用戶界面必定能禁止位置條滑動。
以前要求RTSP必須能支持多用戶，但現在得出一個更好的方法就是保證RTSP能很容易擴展成支持多用戶即可。因為流的標志可以被多個控制流使用，因此”遠程通過”成為可能。協議不涉及到多個客戶端如何協調入口，其由下層“社會協議”或其他下層控制機制提供。
1.5 RTSP擴展
由于不是所有媒體服務器有著相同的功能，媒體服務器有必要支持不同請求集。例如：
Ø      服務器可能只須支持回放，因此不必不支持錄制功能。
Ø      對于支持現場播放的服務器可能不支持尋找功能。
Ø      一些服務器可能不支持設置流參數，因此不支持GET_PARAMETER和SET_PARAMETER。
但服務器應該實現所有12章中要求的標題域。
表示描述(presentation description)應當保證不提出服務器不支持的功能，這種情形和HTTP/1.1中[H19.6]描述方法不支持across server的情形一致。
RTSP 可以如下三種方式擴展，這里以改變大小排序：
Ø      以新參數擴展。如用戶需要拒絕通知，而方法擴展不支持，相應標記就加入要求的段中。
Ø      加入新方法。如信息接收者不理解請求，返回501錯誤代碼（還未實現），發送者不應再次嘗試這種方法。用戶可使用OPTIONS方法查詢服務器支持的方法。服務器使用公共回應標題列出支持的方法。
Ø      定義新版本協議，允許改變所有部分。（除了協議版本號位置）
1.6 操作模式
　每個表示和媒體流可用RTSP URL識別。表示組成的整個表示與媒體屬性由表示描述(presentation description)文件定義，表示描述格式不在本協議中定義。使用HTTP或其它途徑用戶可獲得這個文件，它沒有必要保存在媒體服務器上。
　為了說明，假設表示描述(presentation description)描述了多個表示(presentation)，其中每個表示(presentation)維持了一個公共時間軸。為簡化說明，且不失一般性，假定表示描述(presentation description)的確包含這樣一個表示(presentation)。表示(presentation)可包含多個媒體流。
     表示描述(presentation description)即組成表示的流的描述，包括它們的編碼，語言和使用戶可以選擇最符合要求媒體的其他參數。在表示描述中，被RTSP分別控制的媒體流由RTSP URL表示。RTSP URL指出了處理具體媒體流的服務器以及存在于該服務器上流的名字。多個媒體流可以放到不同的服務器上，比如音頻和視頻流可以分別放到不同服務器而負載共享。描述（description)還列出了服務器傳輸可使用的方法。
除媒體參數外，網絡目標地址和端口也需要決定。下面區分幾種操作模式：
單播：
　以用戶選擇的端口號將媒體發送到RTSP請求源。
組播，服務器選擇地址：
　媒體服務器選擇組播地址和端口，這是現場直播或準點播常用的方式。
組播，用戶選擇地址：
　如服務器加入正在進行的組播會議，組播地址、端口和密匙由會議描述給出。
1.7 RTSP狀態
　 RTSP控制通過單獨協議發送的流，與控制通道無關。例如，RTSP控制可通過TCP連接，而數據流通過UDP。因此，即使媒體服務器沒有收到請求，數據也會繼續發送。在會話生命期，單個媒體流可通過不同TCP連接順序發出請求來控制。所以，服務器需要維持能聯系流與RTSP請求的會話狀態。
RTSP中很多方法與狀態無關，但下列方法在定義服務器流資源的分配與應用上起著重要的作用：
SETUP：
　讓服務器給流分配資源，啟動RTSP會話。
PLAY與RECORD：
　啟動SETUP 分配流的數據傳輸。
PAUSE：
　臨時停止流，而不釋放服務器資源。
TEARDOWN：
　釋放流的資源，RTSP會話停止。
　標識狀態的RTSP方法使用會話(session)標題域識別RTSP會話，為回應SETUP請求，服務器生成會話標識。
1.8 與其他協議關系
　 RTSP在功能上與HTTP有重疊，與HTTP相互作用體現在與流內容的初始接觸是通過網頁的。目前的協議規范目的在于允許在網頁服務器與實現RTSP媒體服務器之間存在不同傳遞點。例如，表示描述(presentation description)可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨立RTSP 服務器與用戶不全依靠HTTP。
　但是，RTSP與HTTP 的本質差別在于數據發送以不同協議進行。HTTP是不對稱協議，用戶發出請求，服務器作出回應。RTSP中，媒體用戶和服務器都可發出請求，且其請求都是無狀態的；在請求確認后很長時間內，仍可設置參數，控制媒體流。
重用HTTP功能至少在兩個方面有好處，即安全和代理。要求非常接近，在緩存、代理和授權上采用HTTP功能是有價值的。
　當大多數實時媒體使用RTP作為傳輸協議時，RTSP沒有綁定到RTP。
RTSP假設存在表示描述格式可表示包含幾個媒體流的表示的靜態與臨時屬性。
2 符號協定
既然很多定義和語法與HTTP/1.1中相同，這里僅指出它們在HTTP/1.1中定義的位置而并沒有拷貝它們到本文檔。為簡便起見，本文檔中[ HX.Y ]表示對應HTTP/1.1（RFC 2068）中的X.Y部分。（[譯者注：]為更方便學習RTSP，本翻譯文檔將相關段落完全譯出）

與[H2.1]類似，本文對所有機制的說明都是以散文和補充反饋的方式來描述的。除RTSP中以”1#”代替”,”為分隔符不同外，其余在RFC 2234中有詳細的描述。簡單說明補充反饋方式如下：

補充反饋方式（augmented BNF）包括下面的結構：

要解釋的名詞＝名詞解釋（name = definition）
規則的名字（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-linear whitespace）來分隔，這將使列表非常方便，如“（*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即可。

如下：
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:" ) "http://" host [ ":" port ] [ abs_path ]
host?，，? <合法的Internet主機域名或IP地址(用十進制數及點組成), 見RFC1123，2.1節定義>
port?，，? *DIGIT
abs_path 在 [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 | "/" )

        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協議）。

如是端口為空或沒指定，則缺省為80端口。對于rtsp_URI來說，擁有被請求的
資源的服務器主機通過偵聽該端口的TCP連接(rtsp)或UDP包(rtspu)來接收該URI請求。

只要可能，應盡量避免的在URL中直接使用IP地址。（請參考RFC1924）

文本媒體標識符使用URL中的字符集及轉義規則（參考RFC1738）來標識一個表示(presentation)與單個流(stream)。URL可以用于單個流或者多個流的集合，比如表示(presentation)。因此，在第十章所描述的請求(request)可以用于整個表示(presentation)或表示中的單個流。注意，有些請求方法僅能用于流而不能用于表示，反之亦然。

例如：RTSP URL:
rtsp://media.example.com:554/twister/audiotrack
標識了twister表示(presentation)中，可以通過media.example.com554端口的TCP連接發送RTSP請求來控制的音頻流。

也可以是這樣RTSP URL：
rtsp://media.example.com:554/twister
標識了由音頻和視頻流組成的twister表示(presentation)。

這并沒有給出URL中相關流的標準方法。表示描述定義了表示中的層次關系以及單獨流的URL。如一個表示描述可能將一個流命名為a.mov，而將整個表示命名為b.mov。
RTSP URL的路徑組成對客戶端來說不可見并且也并沒有給出服務器的具體文件系統結構。

只需進行簡單替換后，表示描述同樣可以用于非RTSP媒體控制協議。
3.3 會議標識
會議標識采用URI標準編碼方法編碼，并對RTSP來說是不可見的。它們能包含任一八位位組值。必須保證會議標識在全局中的唯一性。在H.323中，將用到會議的標識值。

conference-id = 1*xchar

會議標識允許RTSP會話從媒體服務器參與的多媒體會議中獲取參數。比如，可以要求媒體服務器用會議描述中的標識值來代替RTSP客戶端以提供詳細的傳輸信息。多媒體會議的建立不屬于本協議內容，具體請參見H.323或SIP協議。
3.4 會話標識
會話標識符是不可見的任意長度的字符串。線性空格必須是URL-escaped。會話標識符必須隨機產生并且至少應有8個八位位組長以保證其難以被猜出。（詳見16章）
session-id = 1*( ALPHA | DIGIT | safe )
3.5 SMPTE 相對時間戳
SMPTE相對時間戳表示相對于開始剪輯的時間。相對時間戳以SMPTE時間編碼形式表示而可以達到幀級量級的精度。時間編碼的格式為：時：分：秒；幀.子幀，并以剪輯開始為起點。缺省的SMPTE格式為“SMPTE 30 drop”格式，其幀速是29.97幀每秒?？赏ㄟ^選擇使用不同“SMPTE time”來選擇其他SMPTE編碼格式（如“SMPTE 25”格式）。幀域的時間值在0到29之間。30幀每秒和29.97幀每秒的不同之處在于后者除每第十分鐘外的每分鐘都要丟掉頭兩個幀（00和01）。忽略幀值為0的幀，子幀以百分之一幀為單位。

smpte-range= smpte-type "=" smpte-time "-" [ smpte-time ]
smpte-type = "smpte" | "smpte-30-drop" | "smpte-25"
?，，，，，，，，，，，，，，，?; 還可以加入其他時間編碼
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上。當處于普通播放模式(scale = 1)時，NPT正常前進。當處于快進掃描模式時(scale率為大于1的正數)，NPT快速前進。當處于反向掃描模式(scale率小于-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字符集避免敏感字符集切換，但對應用來說不可見。RTCP也采用這種編碼方案。帶有重要意義位的ISO 8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通過任何低層傳輸協議攜帶。
　請求包括方法、方法作用于其上的對象和進一步描述方法的參數。方法也可設計為在服務器端只需要少量或不需要狀態維護。當信息體包含在信息中，信息體長度有如下因素決定：
　不管實體標題域是否出現在信息中，不包括信息體的的回應信息總以標題域后第一和空行結束。
　如出現內容長度標題域，其值以字節計，表示信息體長度。如未出現標題域，其值為零。
　服務器關閉連接。
　注意：RTSP目前并不支持HTTP/1.1\"塊\"傳輸編碼，需要有內容長度頭。假如返回適度表示描述長度，即使動態產生，使塊傳輸編碼沒有必要，服務器也應該能決定其長度。如有實體，即使必須有內容長度，且長度沒顯式給出，規則可確保行為合理。
　從用戶到服務器端的請求信息在第一行內包括源采用的方法、源標識和所用協議版本。RTSP定義了附加狀態代碼，而沒有定義任何HTTP代碼。

4.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]。
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]。
RTSP消息的消息主體（如果有）用來攜帶請求或回應的主體。僅在使用傳輸編碼(Transfer-Encoding)時消息主體和實體主體才有所不同，這種情況在傳輸編碼標題域中有詳細說明。（見[H14.40]）

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

傳輸編碼必須能解釋所有保證傳輸安全和正確的應用程序的傳輸編碼。傳輸編碼是消息而不是實體的一個屬性，因此可以由任一應用程序隨著請求/回應鏈添加或者刪除。

什么時候允許消息帶消息體的規則在請求和回應兩種情況下有所不同。

在請求中有無消息主體的標志是是否包含內容長度或請求消息標題域中的傳輸編碼標題域。只有當請求方法允許有實體主體的時候才能在請求中包含消息主體。

而對于回應消息來說，無論消息中是否存在消息主體都與請求方法和回應狀態編碼無關。所有回應標題請求方法的消息都不能包含消息主體，盡管有時會因為存在實體標題域而使人產生誤解。所有1××（信息），204（無內容），304（未修改）回應都不包含消息主體。而其他回應則都包含主體，盡管其長度有可能長度為零。
4.4 消息長度
當消息包含消息主體時，消息主體的長度由以下規則來決定（按優先級高低順序排列）：
1.      任何回應消息都不包含消息主體（如1××，204和304回應），并且不管消息中是否存在實體標題域都以消息標題域后的第一行空行表示結束。
2.      如果內容長度標題域存在，它在字節中的值就是消息主體的長度。如果內容標題域不存在，則假設值為零。
3.      服務器關閉連接時。（關閉連接沒有用來表明請求主體結束，否則可能導致服務器不能回應。
注意，RTSP不支持（至少現在）HTTP/1.1的塊傳輸編碼（詳見[H3.6]）并且要求有內容長度標題域。
     盡管表示描述長度動態產生，但由于可獲得了表示描述返回長度，使得服務器總是能決定表示描述長度而不需使用塊傳輸編碼方式。只要有實體主體就必須有內容長度項，這些規則保證了即使沒有給出明確長度也能做出合理的操作。

5 普通標題域
有幾種標題域是請求與回應都要使用的，但并不用于被傳輸的實體。這些標題只用于被
傳輸的消息。

General-Header = Date                  ; Section 10.6
        | Pragma            ; Section 10.12
     普通標題域名稱只有在與協議版本的變化結合起來后，才能進行可靠的擴展。實際上，
新的或實驗中的標題域只要能被通訊各方識別，其語法就可使用，而無法識別的標題域都將
被視為實體域。
6 請求
從客戶端到服務器端的請求消息包括，消息首行中，對資源的請求方法、資源的標識符
及使用的協議。

Request = Request-Line ; 6.1節
*( general-header ; 5章
| request-header ; 6.2節
| entity-header ) ; 8.1節
CRLF
[ message-body ] ; 4.3節

注意：相對于HTTP/1.1而言，RTSP請求要求絕對路徑（并包括rtsp或rtspu方案，主機，端口號）。

HTTP/1.1 要求服務器理解絕對URL, 但是客戶端需要假設為主機請求標題域。這樣做完全是為了HTTP/1.0服務器端向后兼容性，因此RTSP并不需要這樣做。

在請求URI中星號“*”表示此請求不用于其他資源，只用于服務器本身，并且它只能在使用的方法不要求應用于資源時才能使用。

比如：OPTIONS * RTSP/1.0。

7 回應
7.1 狀態行
完整回應消息的第一行就是狀態行，它依次由協議版本、數字形式的狀態代碼、及相應
的詞語文本組成，各元素間以空格（SP）分隔，除了結尾的CRLF外，不允許出現單獨的
CR或LF符。

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

7.1.1 狀態代碼和原因分析
狀態代碼（Status-Code）由3位數字組成，表示請求是否被理解或被滿足。原因分析是
用簡短的文字來描述狀態代碼產生的原因。狀態代碼用來支持自動操作，原因分析是為人類
用戶準備的?？蛻舳瞬恍枰獧z查或顯示原因分析。

狀態代碼的第一位數字定義了回應的類別，后面兩位數字沒有具體分類。首位數字有5
種取值可能：

o 1xx:：保留，將來使用。

o 2xx：成功－操作被接收、理解、接受（received, understood, accepted）。

o 3xx：重定向（Redirection）－要完成請求必須進行進一步操作。

o 4xx：客戶端出錯－請求有語法錯誤或無法實現。

o 5xx：服務器端出錯－服務器無法實現合法的請求。

HTTP/1.0的狀態代碼、原因解釋在下面給出。下面的原因解釋只是建議采用，可任意
更改，而不會對協議造成影響。完整的代碼定義在第9節。

HTTP狀態代碼是可擴展的，而只有上述代碼才可以被當前全部的應用所識別。HTTP
應用不要求了解全部注冊的狀態代碼，當然，如果了解了更好。實際上，應用程序必須理解
任何一種狀態代碼，如果碰到不識別的情況，可根據其首位數字來判斷其類型并處理。另外，
不要緩存無法識別的回應。

例如，如果客戶端收到一個無法識別的狀態碼431，可以安全地假定是請求出了問題，
可認為回應的狀態碼就是400。在這種情況下，用戶代理應當在回應消息的實體中通知用戶，
因為實體中可以包括一些人類可以識別的非正常狀態的描述信息。

Code reason
100 Continue all
200 OK all
201 Created RECORD
250 Low on Storage Space RECORD
300 Multiple Choices all
301 Moved Permanently all
302 Moved Temporarily all
303 See Other all
305 Use Proxy all
400 Bad Request all
401 Unauthorized all
402 Payment Required all
403 Forbidden all
404 Not Found all
405 Method Not Allowed all
406 Not Acceptable all
407 Proxy Authentication Required all
408 Request Timeout all
410 Gone all
411 Length Required all
412 Precondition Failed DESCRIBE, SETUP
413 Request Entity Too Large all
414 Request-URI Too Long all
415 Unsupported Media Type all
451 Invalid parameter SETUP
452 Illegal Conference Identifier SETUP
453 Not Enough Bandwidth SETUP
454 Session Not Found all
455 Method Not Valid In This State all
456 Header Field Not Valid all
457 Invalid Range PLAY
458 Parameter Is Read-Only SET_PARAMETER
459 Aggregate Operation Not Allowed all
460 Only Aggregate Operation Allowed all
461 Unsupported Transport all
462 Destination Unreachable all
500 Internal Server Error all
501 Not Implemented all
502 Bad Gateway all
503 Service Unavailable all
504 Gateway Timeout all
505 RTSP Version Not Supported all
551 Option not support all
Table 1: Status codes and their usage with RTSP methods

7.1.2 回應標題域
回應標題域中包括不能放在狀態行中的附加回應信息。該域還可以存放與服務器相關的
信息，以及在對請求URI所指定資源進行訪問的下一步信息。

回應標題域名只有在與協議版本的變化結合起來后，才能進行可靠的擴展。實際上，新
的或實驗中的標題域只要能被通訊各方識別，其語法就可使用，而無法識別的標題域都將被
視為實體域。

8 實體
如不受請求方法或回應狀態編碼限制，請求和回應消息可傳輸實體，實體由實體標題域和實體主體組成，有些回應僅包括實體頭。
在此，根據誰發送實體、誰接收實體，發送者和接收者可分別指用戶和服務器。
8.1 實體標題域
實體標題定義實體主體可選元信息，如沒有實體主體，指請求標識的資源。

擴展頭機制允許定義附加實體標題域，而不用改變協議，但這些段不能假定接收者能識別。不可識別標題域應被接收者忽略，而讓代理轉發。
8.2 實體主體
見[H7.2]
　與RTSP請求或回應一起發送的實體主體的格式和編碼信息都在實體標題域
（Entity-Header）中定義。

Entity-Body = *OCTET

     實體主體只在請求方法有要求時才會被放在請求消息中。請求消息標題域處的內容長度
標題域（Content-Length header field）的標志將指明請求中的實體主體是否存在。包含實體
主體的RTSP/1.0請求必須包含合法的內容長度標題域。

     對回應消息來說，消息中是否包含實體主體取決于請求方法和回應代碼。所有的HEAD
請求方法的回應都不應包括主體，即便是實體標題域中指明有主體也一樣。在主體中不應包
括這些回應信息，全部1xx（信息）、204（無內容）和304（未修改）。而其它的回應必須包
括實體主體或其內容長度標題（Content-Length header）域的定義值為0。

9 連接
　 RTSP請求可以幾種不同方式傳送：
　 1、持久傳輸連接，用于多個請求/回應傳輸。
　 2、每個請求/回應傳輸一個連接。
　 3、無連接模式。
　傳輸連接類型由RTSP URI來定義。對 \"rtsp\" 方案，需要持續連接；而\"rtspu\"方案，調用RTSP 請求發送，而不用建立連接。
　不象HTTP，RTSP允許媒體服務器給媒體用戶發送請求。然而，這僅在持久連接時才支持，否則媒體服務器沒有可靠途徑到達用戶，這也是請求通過防火墻從媒體服務器傳到用戶的唯一途徑。

9.1 流水線操作
　支持持久連接或無連接的客戶端可能給其請求排隊。服務器必須以收到請求的同樣順序發出回應。
9.2 可靠性及確認
如果請求不是發送給組播組，接收者就確認請求，如沒有確認信息，發送者可在超過一個來回時間（RTT）后重發同一信息。 RTT在TCP中估計，初始值為500 ms。應用緩存最后所測量的RTT，作為將來連接的初始值。
如使用一個可靠傳輸協議傳輸RTSP，請求不允許重發，RTSP應用反過來依賴低層傳輸提供可靠性。
如兩個低層可靠傳輸（如TCP 和RTSP）應用重發請求，有可能每個包損失導致兩次重傳。由于傳輸棧在第一次嘗試到達接收著者前不會發送應用層重傳，接收者也不能充分利用應用層重傳。如包損失由阻塞引起，不同層的重發將使阻塞進一步惡化。
時標頭用來避免重發模糊性問題，避免對圓錐算法的依賴。
每個請求在CSeq頭中攜帶一個系列號，每發送一個不同請求，它就加一。如由于沒有確認而重發請求，請求必須攜帶初始系列號。
　實現RTSP的系統必須支持通過TCP傳輸RTSP ，并支持UDP。對UDP和TCP，RTSP服務器的缺省端口都是554。許多目的一致的RTSP包被打包成單個低層PDU或TCP流。RTSP數據可與RTP和RTCP包交叉。不象HTTP，RTSP信息必須包含一個內容長度頭，無論信息何時包含負載。否則，RTSP包以空行結束，后跟最后一個信息頭。

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/sendy888/archive/2007/12/19/1953288.aspx

posted on 2009-07-22 11:17 阿蜜果閱讀(2113) 評論(0) 編輯收藏所屬分類: 協議

新用戶注冊刷新評論列表


只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關文章: SIP常用消息實例參考蜜果私塾：使用SIPP來進行SIP壓力測試（2）【電信知識】RFC3581——SIP中的rport機制【轉】SIP 擴展與相關 RFC 介紹蜜果私塾：http協議學習和總結系列——深入了解篇蜜果私塾：http協議學習和總結系列——協議詳解篇蜜果私塾：使用SIPP來進行SIP壓力測試(一) 使用Wireshark進行SIP包解析【轉】RFC3550 RTP 中文版蜜果私塾：RTSP實例