RTSP 流媒體協議

這個文檔詳細說明了網際網路傳輸協議中的一種網際網路標準路徑協議，而且為了提高需要不斷討論和建議。請查閱正確的,與這協議相關的標準化的聲明和情況的網際網路方協議標準協議.分發這備忘錄是沒有限制的.

摘要：
Real Time流媒體協議或者RTSP，是一種在應用程式層上控制即時傳輸資料的工具。RTSP提供一種可擴充的架構，使能夠提供能控制的，按需傳輸即時資料，比如音頻和視頻檔案。來源資料可以包括現場資料的反饋和存貯的檔案。這協議有意識的控制多重資料,傳遞會議,提供一種選擇傳遞通道,比如UDP,多點傳遞UDP,
和TCP,以及一種基於RTP(RFC1889)選擇傳遞機制.
目錄內容:(略).

1. 介紹
1.1 目的
即時資料流媒體傳輸協議建立和控制一種簡單的,或者幾種時間同步,連續的媒體流,比如音頻和視頻.他不是代表性的傳遞連續流,儘管交錯受到控制的連續媒體流是可能的(看10.12章).另一點,RTSP擔當著為多媒體服務提供網路遙控控制.

被控制的流的設定是被一個介紹描寫定義的.這個備忘錄不是為介紹圖象定義的格式.

這裡沒有RTSP串連的概念：作為代替，一個伺服器的維護，一個被驗證人標籤的會議。一個RTSP會議是絕不會連到傳輸層串連的，比如，TCP串連。在一個RTSP會議中，一個 RTSP會議用戶端可以開和關許多可靠的傳送器，串連到發送RTSP請求的伺服器上，作為選擇，它可以使用無串連傳輸協議，比如UDP。

用RTSP控制流程可以使用RTP，但是RTSP的操作不依靠通常傳輸連續媒體的傳輸機制。這個協議有意地在運作在上與HTTP/1.1相似。所以HTTP地擴充機制能夠最大程度上被加到RTSP。但是RTSP與HTTP地許多重要不同在於：
* RTSP介紹許多新模式，並且有一個不同地協議標識符。
* 一個RTSP伺服器需要預設地幾乎所有地情況來維持正常運行。
* RTSP服務端和用戶端都要能發出請求。
* 資料通過不同地協議傳送。
* RTSP是用比ISO 8859-1要好地ISO 10646定義的，使它與當前的HTML的國際化努力相一致。
* 要求URI總使包括絕對URI.因為向後相容性在曆史上範過大錯，HTTP/1.1隻能傳遞要求的絕對路徑，把主機名稱放入沒有聯絡的標題列上。
這使“虛擬機器主機”更簡單，這時，帶1 IP地址的單一的主機可以服務幾個檔案樹。

本協議支援一下操作：
從媒體伺服器端取回媒體資料：
用戶端能夠要求一個圖象描述通過HTTP或者其它模式。如果圖象使被多點傳輸的，圖象描述包含了多點傳輸的地址和連接埠，用來傳輸連續媒體。如果映像只能經過UNICAST，那用戶端就要因為安全而提供給目的檔案。

對會議的媒體伺服器的邀請：
一個媒體伺服器端能夠被邀請參加一個存在的會議，可以向後播放映像，記錄媒體檔案的全部或者一部分。這種模式對分布式教學軟體是有用的。查看會議中的幾個部分可以按遙控控制按鈕。

對存在映像的媒體追加：
尤其為存在的映像，如果伺服器能告訴用戶端可以利用的補充性的媒體，那它是有用的。

在http/1.1 [ 2 ]中RTSP要求可以是通過代理，通道和緩衝。

1.2 要求
在這些文檔中的關鍵字“必需”，“一定不能”，“必需的”，“會”，“不會”，“應該”，“不應該”，“被推薦的”，“可以”，和“可選擇的”都在RFC2119中解釋描述。

1.3 術語
一些術語採用於HTTP/1.1.在這裡就不列舉了。
總體控制：
多重流的控制通過伺服器使用一種簡單的時間軸。為了音頻/視頻的反饋，可以通過用戶端發送一個簡單的開始或暫停指令去控制視頻/音訊反饋。
討論：
一個多組件的，多媒體的映像，這裡的多表示大於或者等於一。
用戶端：
用戶端從伺服器端請求連續的媒體資料。
串連：
為了通訊的目的在兩個程式之間確定的傳輸層虛擬線路。
容器檔案：
可以包含多媒體，包含映像的檔案被開啟的時候。RTSP伺服器可以在這些檔案上提供總體控制，儘管容器檔案的觀念沒有被植入協議中。
連續媒體：
資料是資料來源和串連之間的即時關係，也就是說，接受器和資料來源之間要不斷產生關係聯結。最普通的連續媒體的例子是音頻和動畫視頻。串連媒體可以互動工作，它們在源和接受器之間是一種緊密的即時關係。或者是流的形式，這種關係就沒有那麼嚴格了。
實體：
是作為一個請求或者回應的有效負荷的資訊傳遞。一個實體包含在頭部的資訊形式和在實體中的內容。這些在第八張中介紹。
媒體的初始化：
多媒體數字編解碼特殊的初始化，這些包括時鐘輸率，顏色表等。任何獨立傳輸器資訊的請求，是通過用戶端在媒體初始化設定階段當中媒體流發生的重放來實現的。
媒體參數:
一個媒體類型的特定參數可以在流重放前或者重放時改變。
媒體伺服器：
伺服器倘若在重放一個或者多個媒體流，不同的媒體流內部的映像可以來源於不同的媒體伺服器。一個媒體伺服器可以放在相同或者不同的主機上作為的調用網路伺服器。
媒體伺服器迂迴：
重新定向一個媒體用戶端到不同的媒體伺服器。
流：
一個簡單的媒體執行個體，比如一個音頻流或者也是一個簡單白班或者共用應用程式組，當用到RTP時，一個流在RTP周期內由建立的RTP和RTCP組成的，這是和DSM-CC流的定義相同的。
訊息：
RTSP通訊的基本單元。由15章裡面定義的八位匹配文法的結構化序列組成，並且經過一個串連或者無連線協定轉移。
參與者：
一個會議成員。一個參與者可以是機器，比如是一個媒體記錄或者重放伺服器。
陳述：
一套由一條或者幾條流作為完全的媒體反饋，使用下面的表達陳述送到用戶端。在RTSP上下文中的多數場合，這表示這些流的主體控制，但是不是一定要的。
陳述描寫：
一個陳述描寫包括關於一個陳述裡面的一個或者多個媒體流的資訊。比如，一套關於串連編碼，網路地址和資訊。另外，象SDP的TETF協議，使用現場陳述作為會議。這個陳述可以採用不同的格式，不僅僅限制於會議描述對SDP的安排。
回應：
一個RTSP回應。如果一個HTTP回應能夠接受，那就能被清楚的表示。
請求；
一個RTSP請求。如果一個HTTP請求能夠接受，那就能被清楚的表示。
RTSP會議：
一個完整的RTSO處理。比如，一個電影的觀看過程。一個會議通常由用戶端為連續媒體流建立一個傳輸機制，用播放或者錄影開始一個流，用停止來關閉流。
傳輸器初始化：
在用戶端和伺服器端之間的傳輸器資訊（連接埠號碼，傳輸協議等）的商議。

1.4 協議屬性
RTSP有以下屬性：
可擴充性：
新的模式和參數可以很容易的加到RTSP當中。
易於解析：
RTSP能夠被標準的HTTP或者MIME解析。
安全性：
RTSP也使用網路的安全機制。所有的HTTP驗證機制比如基本的（RFC 2068[2,11章]）和分類堅定可以直接使用，也可以重新使用傳輸器或者網路層安全機制。
傳輸獨立性：
RTSP即可以使用使用者資料包通訊協定（RFC 768）,可靠傳輸協議（RDP,RFC 1151,沒有被廣泛使用）或者可靠的流協議，比如TCP，作為可靠的執行應用程式層。
多伺服器能力：
每一個媒體流在其播放時能夠從不同的伺服器傳來，用戶端不同的媒體伺服器自動的建立幾個並發控制會議，媒體同步是在傳輸層執行的。
記錄裝置的控制：
這個協議能夠同時控制錄影和播放，也可以選擇其中的一種模式。
流量控制的分離和會議開始:
流量控制是從為一個會議媒體伺服器分離出來的。唯一的要求是會議開始協議即可以提供，也能被建立新的會議標識符。在特殊情況下，STP或H.233可以建立會議的伺服器。
適合專業人員應用：
RTSP支援架構層的精度。通過SMPTE時間來標記，允許細微的資料編輯。
播放種類的中立性：
本協議沒有加強一種特別的播放描述或者圖檔案格式，以及能夠使傳遞用過的類型。但是播放描述必須包含至少一個RTSP串連。
代理和防火牆的友好性：
本協議應該同時通過應用程式層和傳輸層防火牆容易地掌握。一個防火牆對於理解為UDP媒體流開地“洞”建立模式是需要地。
HTTP友好性：
在明確RTSP重新使用HTTP觀念後。這樣，目前地基礎設施就能夠再使用了。這個基礎設施包含了為了標籤聯絡起來和內容地PICS在內。不過，控制連續的媒體在大部分的例子需要伺服器狀態之後，RTSP不能加到HTTP上。
分配伺服器控制：
如果用戶端能開始一個流，它必須能停止流。伺服器不應該給用戶端開始流，這樣用戶端就不能停止流的流動。
傳輸協商：
用戶端能在需要辦理連續的媒體流之前實際上協商傳輸方法。
能力協商：
如果基本的特點不能使用，用戶端為了決定哪個方法不去被實現必須有一些清理的機制。這允許用戶端出示適當的使用者介面。例如，如果尋找不被允許，使用者介面必須能拒絕承認移動滑行的位置指標。

RTSP裡的早期的要求是多用戶端的能力。不過，它決心已一種更好地方法去使得本協議能很容易地擴充多用戶端地想定。流標識符能被幾個控制流程使用，這樣，“遠程通過”將成為可能。本協議將不談到幾個用戶端協商接近的方法。這被委託給“社會協議書”和一些其他的層控制機制。

1.5RTSP擴充
全部媒體伺服器都沒有相同的功能性之後，媒體伺服器將有必要支援要求的不同的一套。例如：
* 這樣伺服器也許僅僅能作重放地能力，而不必有支援記錄要求的必要。
* 如果它僅僅支援現場的事件，伺服器也可以不要尋找地能力（絕對位置）。
* 一些伺服器可以不支援播放流參數和不GET_PARAMETER和SET_PARAMETER。
伺服器應該實現全部在第12節所描述的功能。
不詢問伺服器不可能是播放描述的創造者最高層次。這與在http/1.1 [ 2 ]中類似，這時，在裡邊[ H19.6 ]被闡述的方法不有可能被全部伺服器支援。RTSP能以3方法被擴充，在這裡按被支援的變化的大小的順序編成表。
* 要這些模式能被新參數被擴充，只要這些參數能夠被容器忽略。（這和把新參數加到HTML籤條上相等。）如果當模式擴充不被支援時，用戶端需要否定地能力。一個對擴充地相應標籤也要加到請求裡面：失敗（見12.32章）。
* 新方法能夠被加進去。如果資訊的接受方不理解要求，它用錯誤碼501應答（實現），並且，寄件者應該不試圖再一次使用這方法。另外，用戶端可以用任意選擇方法來詢問用伺服器支援的方法。伺服器應該把它支援使用的方法編成表作為應答公用的回答標題。
* 協議書的新版本允許幾乎所有方面（除了協議書版本編號的位置）地改變，而且能被定義。

1.6 總體操作
每個陳述都和媒體流在RTSP URL附近識別。全部的陳述和組成媒體描述的屬性是通過陳述描述檔案定義的，格式是說明書的範圍。播放描述檔案通過用戶端使用HTTP或者象EMAIL一樣的東西得到，可以不必放在媒體伺服器上。
為這說明的目的，有人假設陳述描述一個以上的——每個都包含相同的時間軸。因為說明簡單，並且喪失普遍性，一個陳述描述確切地說包括這樣的陳述。陳述可以包括幾個媒體流。
陳述描述檔案包含組成陳述的媒體流的定義描述，包括他們的編碼，語言和能使用戶端選擇媒體的最適當的結合的其他的參數。
在這陳述描述中，每個個別通過RTSP 控制的媒體流都是被RTSP URL識別，在那裡特殊媒體流指向媒體伺服器和命名存在伺服器上的流。幾個媒體流能被置於不同的伺服器；
例如，聲音和錄影流為了能通過伺服器而被切割。描述也列舉伺服器能作那些傳輸方法。
除媒體參數之外，網路目的地址和連接埠也需要被決定。幾個操作的方式也能被識別：
Unicast ：
媒體用用戶端選的連接埠號碼被傳送到RTSP要求的源。作為選擇，媒體在和RTSP同樣的可靠的溪流上傳送。
多點選擇，伺服器選擇地址：
媒體伺服器挑選地址和連接埠。這是現場或者VOD的傳輸的典型的情況。
多點選擇，用戶端選擇地址:
如果伺服器參與已經存在的多點傳送會議，多點傳送連接埠，地址和密碼化鑰匙會議描述，在這個說明的範圍外面。
1.7 RTSP 規定
RTSP可以經由一個分開的協議，一個獨立的控制通道控制被送的流。例如,RTSP當資料經由UDP流動時，控制在一個TCP串連。這樣,資料就算媒體沒有收到RTSP求被，任可以繼續傳遞。另外,在它的周期裡面，一條單個的媒介流可以是RTSP在不同的TCP串連上連續發出的請求控制的。因此，伺服器需要維護會議形態能把RTSP要求與流結合起來。這形態轉換在A部分描述。
不過，以下在伺服器上定義流資源的分配和使用中扮演核心的角色：
建立，播放，錄影，暫停和關閉。
建立：
使伺服器把資源分派給流，開始RTSP會議。
播放和錄影;
經過分配的流經過建立開始傳送了。
暫停：
臨時掛起伺服器上的流。
關閉：
獲得自由與溪流有關聯的資源。RTSP會議在伺服器上停止。
RTSP模式歸功於使用會議標識（第12.37節）來識別正在操作的RTSP會議。伺服器作為對於準備要求的反應產生會議標識符（第10.4節）。

1.8 與其它協議的聯絡
RTSP在功能中於http有一些重複。它也可以用流的內容的最初串連與HTTP聯絡，它時通過網頁完成工作的。現在的協議書說明想允許在實現RTSP的網路伺服器和媒體伺服器之間的不同的傳遞點。例如，陳述表達用HTTP或RTSP取得，這樣可以減少基於WEB瀏覽器的工作量，也允許獨立的RTSP伺服器和不依賴於HTTP的用戶端。
但是，RTSP在不同的協議中，資料轉送上與HTTP根本上不同的。HTTP是用戶端發出要求的不對稱的協議書，並且，伺服器作應答。在RTSP中，媒體用戶端和媒體伺服器能出來
進行應答。另外，RTSP要求是沒有界限的：在要求被接受之後，他們可以設定參數，繼續長期控制媒體流。
把HTTP功能性重複使用至少有兩個地方，安全和代理。它們必要條件非常類似，所以，它們有在緩衝，代理和證明適應HTTP工作的能力是有價值。
當大部分的即時媒體將象運輸議定書那樣使用RTP的時候，RTSP不被捆綁到RTP上。
RTSP設想陳述表達的存在格式能夠是靜態或者動態，包含幾個伺服器流的屬性。

2 國際協定
既然定義和文法與HTTP/1.1在很多地方相似，這說明僅僅是指他們是被定義而不是拷貝它的一部分。為了簡潔，[ HX.Y ]在的HTTP/說明1.1（RFC [ 2 ] 2068）的X.Y部分提到過。
在這檔案中所有被指定的機制都可以在散文和擴大的Backus-Naur方式的類似於[ H2.1 ]中的方法來描述。這將在RFC 2234 [17]中詳細的描述，它是不同於RTSP說明書主張的“1#”區分標誌。
在這記錄中，我們用交替的和小型段落來提供背景和動機。這打算給那些沒有在表達一種理解為什麼他們在RTSP的方法的公式化表述的讀者。

3 協議參數
3.1協議版本
[H3.1]應用，用RTSP代替HTTP。
3.2 RTSP URL
“RTSP”和“RTSPU”計劃被用來經RTSP協議來訪問網路資源。這部分為RTSP URL定義特有的句法和語句。
rtsp_URL= ( "rtsp:" | "rtspu:" )
"//" host [ ":" port ] [ abs_path ]
host= <A legal Internet host domain name of IP address
(in dotted decimal form), as defined by Section 2.1 of RFC 1123 /cite{rfc1123}>
port= *DIGIT
ABS_PATH 在 [H3.2.1]中定義
片斷和疑問標識符在這一時間沒有用，要到RTSP伺服器上解釋。
配置RTSP需要指令經可靠的協議發出（在網際網路，TCP範圍內），另一方面，配置RTSPU識別協議是不可信賴的（在網際網路，UDP範圍內）。
如果連接埠是空的，或者沒有給，連接埠554就被假設。文法計劃被識別的資源能夠通過RTSP在伺服器上監聽TCP串連或者是在主機連接埠的UDP包的控制。這些資源的請求串連是RTSP-URL。
在URL的中IP地址無論什麼時候只要可能，應避免被開啟。
陳述或流通過原文的媒體標識符識別來使用URL的（RFC [ 20 ] 1738）字元集和逃跑規則[ H3.2 ]。URL可以提到流或者流的集合，比如描述。因此，在第10節所描述的要求能在陳述的範圍內適用於全部陳述和個人流。一些要求方法只能到流，不能到陳述，反之也然。
例如：RTSP URL rtsp://media.example.com:554/twister/audiotrack
在陳述內部，不同的音頻流纏繞在一起，經過RTSP請求發出控制訊號，經過一個TCP串連到media.example.com的554連接埠。
也可以是這樣的串連： rtsp://media.example.com:554/twister
不同的東西纏繞在一起，可以是音頻或者視頻組成的。
這不意味著在URL中有通往參照流的標準的路。表達描述在表達和URL中為個別的流定義階層性的關係。表達描述可以給流“a.mov”和全部陳述“b.mov”命名。對用戶端來說，RTSP URL的路組成部分是不透明的。伺服器不暗示著任何特別的檔案系統結構。
這種減弱措施也允許表達陳述用非RTSP媒體控制協議簡單地在URL代替協議書。
3.3 會議標識符
會議標識符是對RTSP不透明的並且用標準URI編碼方法（i.e.,lws是以％來進行擴充的）來編碼。它能包含任何的八位值。會議標識符必須在全域中是唯一的。對H.323，會議標識符的值是被用的。
conference-id = 1*xchar
會議標識符被用於允許RTSP會議獲得媒體伺服器參與的多媒體會議參數。那些會議被在這說明的範圍之外的協議建立，例如，H.323或SIP[12]。代替RTSP客戶明確的提供的傳輸資訊，例如，它請求媒體伺服器用會議報告中的數值代替。
3.4 話路標識符
話路標識符是對任意長度的字串不透明的。線性空白必定是URI擴充。一個話路標識符必須是隨意的和至少八位長來使其難以被猜出。（見16節）
session-id = 1*( ALPHA | DIGIT | safe )
3.5 SMPTE 相對時間標記
一個SMPTE相對時間標記表達了相對於剪輯開始的時間。相對時間標記是作為SMPTE 幀數通道精確度的時間代碼來表達的。時間代碼的格式為：時：分：秒；幀.分幀，在剪輯開始的原點。預設的SMPTE格式時“SMPTE 30 點”格式，與幀速是29.97幀每秒。其他SMPTE代碼可能被支援（例如“SMPTE 25”）通過用可選擇的“SMPTE 時間”的使用。對在時間值的“幀”域能被定義在0到29之間。在30和29.97幀每秒之間的不同每分鐘的頭兩個幀的失去，除了每第十分鐘。如果幀值是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）表示流的絕對的和表演的開始有關係的位置。數的左邊可以是秒或者是小時，分，秒。數的右邊可以測定一秒的一部分。節目的開始應對應於0.0秒開始。
否定的值不能定義。現在特殊的數被定義為現場的事件的現在的瞬息。它也許僅僅為現場的事件而使用。
NPT是在DSM-CC中被定義：直觀地講，NPT是聯絡觀眾和程式的鐘。它在VCR上經常被數字化的展示。NPT正常接近時，當快速向前時以正常播放模式（類比1）以較快的輸率運行，當反向時消耗以及在停止時固定。
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標誌消費。“現在”常數允許用戶端希望收到現場的反饋而不是儲備或者時間遲延版本。絕對的時間和0次不適於這情況之後，需要這東西。
3.7 絕對時間
絕對時間作為ISO 8601時間片是明確的。利用UTC的秒功能可以指出。
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 >
在14h37和20的1996年11月8日和第2.25個UTC的典範：
19961108T143720.25Z
3.8 選擇標籤
籤條在這些需要中被使用（第12.32節），並且需要Proxy標頭檔。
文法：option-tag = 1*xchar
新RTSP任意選擇的創造者應該給帶相反的網域名稱的（例如，“com.foo.mynewfeature”是發明者能在“foo.com”被碰觸到的特點的合式的名字）任意選擇加上首碼，或者用英特網權威數字指派委員會註冊（IANA）。
3.81 用IANA註冊新的選擇標籤
當登記新RTSP選擇標籤的時候，下列資訊應該被提供：
* 名字，並且任意選擇描述。名字可以是任何長度，但是應該長於20字元。名字不必包括任何空間，控制符或時期。
* 對任意選擇的變化（例如，IETF，國際標準組織，國際電信聯盟-T，其他的國際標準化實體，協會，或者一些公司）控制的指示；
* 如果可以利用，一個關於長遠方面的文檔，RFC，發表的紙，專利的檔案歸檔，技術性的報告，進一步的描述的參照，或者電腦手冊可以做成電子文檔；
* 為持有人的任意選擇，和資訊（郵政，並且電子信件地址）聯絡；
。