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

附錄A: RTSP協(xié)議狀態(tài)機（RTSP Protocol State Machines）

RTSP客戶端和服務(wù)器狀態(tài)機描述了從RTSP會話初始化到結(jié)束的所有行為。

狀態(tài)定義在每個對象的基礎(chǔ)上，每個對象通過流URL和RTSP會話標(biāo)識符進行唯一標(biāo)識。任何使用聚合URL的請求/回復(fù)會作用于構(gòu)成其呈現(xiàn)的所有流上。舉個例子，如果呈現(xiàn)/movie中包含兩個流，分別為/movie/audio和/movie/video，那么下列命令：

PLAY rtsp://foo.com/movie RTSP/1.0
CSeq: 559
Session: 12345678

會同時改變/movie/audio和/movie/video的狀態(tài)。

請求方法中OPTIONS，ANNOUNCE，DESCRIBE，GET_PARAMETER，SET_PARAMETER對客戶端或服務(wù)器狀態(tài)并不會有任何影響，因此并未再狀態(tài)表中列出。

A.1 客戶端狀態(tài)機（Client State Machine）

客戶端會有如下狀態(tài)：

• Init
  SETUP已發(fā)出，等待回復(fù)

• Ready
  已接收SETUP回復(fù)或播放中收到PAUSE回復(fù)

• Playing
  已接收PLAY回復(fù)

• Recording
  已接收RECORD回復(fù)

通常，客戶端會在收到請求回復(fù)情況下改變狀態(tài)。注意有些請求會在將來的某一時間或位置生效（如PAUSE），那么狀態(tài)也會對應(yīng)再發(fā)生改變。如果對象不需要顯式SETUP(如多播組中可行的），狀態(tài)從Ready開始。該情況下，只有兩種有效狀態(tài)，Ready和PLAYING。當(dāng)請求中Range結(jié)尾點抵達后，客戶端狀態(tài)同樣會從Playing/Recording切換至Ready。

“next state”欄表示收到成功回復(fù)（2xx）后將會切換至的目標(biāo)狀態(tài)。如果請求響應(yīng)的是3xx的狀態(tài)碼，那么狀態(tài)會切換至Init，而狀態(tài)碼4xx時不會做出任何改變。未列出的消息中，除了之前提到不會影響狀態(tài)的消息，其他均不應(yīng)該由該狀態(tài)客戶端發(fā)出。

*從服務(wù)器接收到REDIRECT等同于從服務(wù)器收到收到3xx重定向狀態(tài)。 *

A.2 服務(wù)器狀態(tài)機（Server State Machine）

服務(wù)器有如下狀態(tài)：

• Init
  初始化狀態(tài)，未收到有效SETUP請求

• Ready
  完成上一次SETUP接收，已回復(fù)或在playing后回復(fù)；
  完成上一次PAUSE接收，已回復(fù)

• Playing
  完成上一次PLAY接收，已回復(fù)，數(shù)據(jù)已發(fā)送

• Recording
  服務(wù)器正在錄制媒體數(shù)據(jù)

通常來講，服務(wù)器在接收請求后會改變狀態(tài)。如果服務(wù)器處于單播模式的Playing或Recording狀態(tài)時，如未收到健康信息（如定義好的從客戶端以多少間隔發(fā)送的RTSP報告或RTSP命令，該間隔默認為1分鐘），它可能回退到Init或退出RTSP會話。服務(wù)器可在會話回復(fù)頭中修改延時值。如果服務(wù)器處于Ready狀態(tài)，它可能會在指定間隔或超過一分鐘內(nèi)未收到RTSP請求后回退到Init。注意有些命令將在將來的某一時間或位置才生效，此時服務(wù)器會在合適時間轉(zhuǎn)換狀態(tài)。當(dāng)請求中Range結(jié)尾點抵達后，服務(wù)器會從Playing或Recording狀態(tài)切換為Ready狀態(tài)。

發(fā)送REDIRECT消息后，將會立即生效，除非消息中帶有Range頭以指定生效時間。這種情況下，服務(wù)器狀態(tài)也會在合適時間進行切換。

如果對象沒有要求顯式SETUP，那么狀態(tài)從Ready開始，且只有兩種有效狀態(tài)：Ready和Playing。

“next state”欄表示收到成功回復(fù)（2xx）后將會切換至的目標(biāo)狀態(tài)。如果請求結(jié)果狀態(tài)碼為3xx，狀態(tài)切換為Init。狀態(tài)碼為4xx的結(jié)果不會引起任何變化。

附錄B：與RTP交互

RTSP允許媒體客戶端控制選擇的、非連續(xù)的媒體呈現(xiàn)塊，并將這些流交給RTP媒體層處理。RTP流的媒體層處理不應(yīng)受NPT跳躍的影響。也就是說，RTP序號和RTP時間戳都應(yīng)該是連續(xù)的、單調(diào)遞增的，即使跨越了非連續(xù)的NPT。

舉個例子，假設(shè)一個時鐘頻率為8000Hz，分組間隔為100ms，初始序號和時間戳均為0。首先我們播放NPT 10至15，然后跳至18至20。第一段RTP分組中序號從0到49，時間戳則從0到39,200。第二段序號從50開始到69，時間戳從40,000到55,200。

我們不能假定RTSP客戶端可以與RTP媒體代理溝通，因為兩者可能是獨立進程。如果RTP時間戳缺口和NPT一致，媒體代理會認定呈現(xiàn)中存在pause操作。如果NPT中的缺口足夠大，RTP時間戳可能roll over，媒體代理會判定滯后的分組為已經(jīng)播放過的副本。

對于具體數(shù)據(jù)類型，RTSP層和RTP層之間進行緊密聯(lián)系可能是必需的。沒有方法可以排除上下屬限制，組合了RTSP/RTP媒體的客戶端應(yīng)使用RTP-Info域來決定收到的RTP分組是在seek前還是滯后發(fā)出的。

對于連續(xù)音頻，服務(wù)器應(yīng)當(dāng)在新的PLAY請求中設(shè)置RTP標(biāo)志位，從而允許客戶端處理播放延時。

對于scaling(見12.34小節(jié))，RTP時間戳應(yīng)當(dāng)參照播放時間線。比如說，當(dāng)以兩倍速率播放一個30幀視頻時，服務(wù)器每秒需要每隔一幀進行丟棄以按正常時間戳傳送視頻幀，但NPT仍然需以每視頻幀1/15秒的幅度進行增加。

客戶端可通過重組后的第一個到達的分組RTP時間戳值來達成在NPT的正確播放，RTP-Info中的序列號提供了下一個分段中的第一個分組序列號。

附錄C: RTSP會話描述中SDP的使用

會話描述協(xié)議（SDP, Session Description Protocol）可能會在RTSP中用于描述流或呈現(xiàn)。使用場景僅限于為如下應(yīng)用指定獲取編碼的方法：

• 聚合控制
  呈現(xiàn)中的流來自不同服務(wù)器時將不支持聚合操作，這樣的描述通常也是通過HTTP或其他非RTSP方法獲取。當(dāng)然，也可以通過ANNOUNCE方法獲得。

• 非聚合操作
  由同一服務(wù)器中的多個流組成的呈現(xiàn)支持聚合操作，這樣的描述通常通過DESCRIBE URL請求獲取，或者通過ANNOUNCE方法進行獲取

該附錄描述了SDP文件如何接收，例如，通過HTTP。SDP文件決定了RTSP會話的操作，它還描述了客戶端如何解析DESCRIBE回復(fù)中的SDP內(nèi)容。SDP未提供無需人參與情況下，客戶端應(yīng)如何在多個同時呈現(xiàn)的媒體流間進行區(qū)分的機制或是其他備選方案（如兩個不同語言的音頻流）。

C.1 定義（Definitions）

本文中涉及的“session-level”, "media-level"及其他key/attribute名稱和值均定義于SDP(RFC 2327)中。

C.1.1 控制URL（ControlURL）

"a=control:"屬性用于轉(zhuǎn)換控制URL，該屬性同時用于會話和媒體描述。如用于單獨媒體，它表示控制特定媒體流的URL，如果在會話級別有該關(guān)鍵字，則表示URL用于聚合操作。

e.g. 
    a=control:rtsp://example.com/foo

該屬性中可能包含相對或絕對URL，緊跟RFC 1808中定義的規(guī)則和約定。實現(xiàn)時應(yīng)按如下順序查找基礎(chǔ)URL:

• RTSP Content-Base 域
• RTSP Content-Location 域
• RTSP request URL

如概述性只包含"*"，則URL被視為空的嵌入式URL，即繼承了整個base URL。

C.1.2 媒體流

“m=”域用于枚舉媒體流，理想情況下所有指定流哦都會被合適同步處理。如果會話是單播，那么服務(wù)器提供給客戶端的port值僅作為建議值，客戶端仍然需要在SETUP請求中包含它，并有可能忽略該建議。如果服務(wù)器沒有優(yōu)先值，則應(yīng)設(shè)置port值為0。

e.g.
    m=audio 0 RTP/AVP 31

C.1.3 負載類型

負載類型在"m="域中指定，當(dāng)負載類型是RFC 1890中的靜態(tài)負載類型時，無需其他信息。而如果是一個動態(tài)負載類型，"rtpmap"中的 "encoding name"必須為RFC 1890中指定的屬性之一，或是SDP中以“X-”作為前綴實驗性編碼方法。編碼器相關(guān)的特定參數(shù)將在此處指定，而是在后面要講到的"fmtp"屬性中討論。注冊新編碼方式時應(yīng)遵循RFC 1890中的流程。如果媒體類型不適于任何RTP AV profile，那么推薦創(chuàng)建新的合適的profile，其名稱需在"RTP/AVP"中"m="域內(nèi)標(biāo)明。

C.1.4 格式特定參數(shù)（ Format-specific parameters）

格式特定的參數(shù)使用"fmtp"媒體屬性進行傳輸，"fmtp"屬性語法用于指定相關(guān)的編碼方法。注意分組間隔通過"ptime"屬性傳遞。

C.1.5 呈現(xiàn)范圍（Range of presentation）

"a=range"屬性定義了存儲會話的總時間范圍（活躍會話的長度可從"t"和"r"參數(shù)推導(dǎo)得出），除非呈現(xiàn)中包含了不同duration的媒體流，否則range屬性是一個會話級別的屬性。range單位需先指定，然后緊跟范圍值。

e.g.
    a=range:npt=0-34.4368
    a=range:clock=19971113T2115-19971113T2203

C.1.6 可用時間（Time of availability）

"t="域中必須包含合適的值，以為聚合或非聚合流操作提供起止時間。

在聚合操作中，服務(wù)器應(yīng)給出一個終止時間，該時間等于其可確保描述可用的時間；同時各處一個起始時間，該時間等于或小于接收到DESCRIBE請求的時間。如這兩個值為0，則表示會話將一直有效。

在費聚合操作中，起止時間應(yīng)能反映出會話可通過SDP語義，而不是依賴其他方式（如存有描述的網(wǎng)頁生命周期）維持可用的實際時間周期。

C.1.7 連接信息（Connection Information）

在SDP中，"c="域中包含了媒體流的目標(biāo)地址。對于點播（單播）流和一些多播流而言，目標(biāo)地址是通過客戶端的SETUP請求確定的。除非媒體內(nèi)容有一個固定的目標(biāo)地址，此時"c="域?qū)⒈辉O(shè)置為合適的控制。如對于“IP4”類型該空值為"0.0.0.0"。

C.1.8 實體標(biāo)簽（Entity Tag）

可選的"a=etag"屬性標(biāo)識了會話描述的版本，它對于客戶端是不透明的。SETUP請求中可能在"If-Match"域中包含該標(biāo)識符，以只在版本匹配當(dāng)前描述時建立會話。該屬性值是不透明的，其中可能包含SDP屬性值所允許的任何字符。

e.g.
    a=etag:158bb3e7c7fd62ce67f12b533f06b83a

One could argue that the "o=" field provides identical
functionality. However, it does so in a manner that would put
constraints on servers that need to support multiple session
description types other than SDP for the same piece of media
content.

C.2 不支持聚合操作

如果一個呈現(xiàn)不支持聚合操作且已制定多個媒體段，每段必須通過"a=control:"屬性制定其控制URL。

e.g.
    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中的位置表示客戶端向服務(wù)器audio.com和video.com分別建立獨立的RTSP控制會話。

即使SDP文件通過非RTSP方式傳給客戶端時，也推薦其中包含所有媒體初始化信息。這在無法通知客戶端需通過DESCRIBE進一步獲取詳細媒體流信息時非常有用。

C.3 支持聚合操作

在這種情況下，服務(wù)器上有可被作為整體控制的多個流。此時既有針對流URL的"a=control:"屬性，也有支持聚合操作的向會話層的"a=control:"屬性。如果媒體層（media-level）URL是相對URL，則應(yīng)參照C.1.1小節(jié)轉(zhuǎn)換為絕對URL。

如呈現(xiàn)僅有一個流組成，媒體層的"a=control:"屬性會被同時省略，而當(dāng)包含多個流時，每個媒體流段必須包含各自的"a=control"屬性。

e.g.
    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

上面例子中，客戶端向服務(wù)器請求建立一個簡單RTSP會話，并使用URL "rtsp://example.com/movie/trackID=1"和"rtsp://example.com/movie/trackID=2"來設(shè)置音視頻流，而URL "rtsp://example.com/movie/"則控制整個影片。

附錄D: 極簡RTSP實現(xiàn)

D.1 客戶端

客戶端實現(xiàn)必須支持如下功能：

• 生成如下請求：SETUP，TEARDOWN，PLAY/RECORD之一。如果實現(xiàn)了RECORD，則也必須實現(xiàn)ANNOUNCE
• 在請求中包含如下頭：CSeq，Connection，Session，Transport。如果實現(xiàn)了ANNOUNCE，也必須支持Content-Language，Content-Encoding，Content-Length以及Content-Type也必須實現(xiàn)
• 解析并支持回復(fù)中的如下頭：CSeq，Connection，Session，Transport，Content-Language，Content-Encoding，Content-Length，Content-Type。如果實現(xiàn)了錄制，則Location也必須支持。RTP兼容的實現(xiàn)還必須實現(xiàn)RTP-Info
• 理解錯誤狀態(tài)碼類別并在狀態(tài)碼為4xx或5xx時通知用戶。消息通知可配置，以避免用戶不希望在出現(xiàn)哪些狀態(tài)碼時收到通知
• 回復(fù)來自服務(wù)器的異步請求，如ANNOUNCE。并不是說客戶端就必須實現(xiàn)ANNOUNCE方法，而是說在收到服務(wù)器請求后，必須給出否定或肯定回復(fù)

盡管并非必須，如下內(nèi)容也強烈建議實現(xiàn)以完整良好交互：

• 支持通過RTP/AVP/UDP傳輸
• 包含User-Agent頭
• 理解附錄C中的SDP會話描述
• 接收從標(biāo)準(zhǔn)輸入、命令行或其他可行方式接收媒體初始化格式（如SDP）

D.1.1 Basic Playback

為了支持媒體流點播功能，客戶端應(yīng)添加如下支持：

• 生成PAUSE請求
• 實現(xiàn)REDIRECT方法，以及Location頭

D.1.2 Authentication-enabled

為了實現(xiàn)在訪問RTSP服務(wù)器上媒體呈現(xiàn)時需要認證，客戶端必須添加如下支持：

• 識別401狀態(tài)碼
• 解析和包含 WWW-Authenticate頭
• 實現(xiàn)Basic認證和Digest認證

D.2 服務(wù)器

一個最精簡的服務(wù)器至少應(yīng)當(dāng)實現(xiàn)如下內(nèi)容：

• 實現(xiàn)如下方法：SETUP，TEARDOWN，OPTIONS，PLAY或RECORD之一。如果實現(xiàn)了RECORD，ANNOUNCE也必須被實現(xiàn)
• 回復(fù)中包含如下頭：Connection，Content-Length，Content-Type，Content-Language，Content-Encoding，Transport，Public。如實現(xiàn)了RECORD，則必須實現(xiàn)Location頭。RTP兼容版本同時還需要實現(xiàn)RTP-Info域
• 解析并恰當(dāng)?shù)鼗貜?fù)請求中的如下頭：Connection，Session，Transport，Require

盡管并非必須，如下內(nèi)容也強烈建議實現(xiàn)以完整良好交互：

• 支持RTP/AVP/UDP傳輸
• 包含Server頭
• 實現(xiàn)DESCRIBE方法
• 生成附錄C中定義的SDP會話描述

D.2.1 Basic Playback

為了支持媒體流點播，服務(wù)器必須額外支持如下內(nèi)容：

• 識別Range頭，并在seeking操作不支持時返回錯誤
• 實現(xiàn)PAUSE方法

此外，為了實現(xiàn)通用用戶接口特性，強烈建議在點播媒體服務(wù)器上實現(xiàn)如下內(nèi)容：

• 包含并解析NPT單位的Range參數(shù)，如有可能，支持SMPTE單位Range更佳
• 在媒體初始化信息中包含媒體呈現(xiàn)Length
• 支持從數(shù)據(jù)指定的時間戳映射為NPT。使用RTP時，RTP-Info域中的rtptime可能用于將RTP時間戳映射為NPT

客戶端可能使用Length確定分段是否支持seek，并對不支持Length信息的分段在視覺效果上禁用seek特性。通常呈現(xiàn)長度會用于實現(xiàn)滑動條，一方面提供當(dāng)前進度，另一方面提供時間位置信息。

從RTP時間戳映射至NPT在確?；瑒訔l位置正確時是必需的。

D.2.2 Authentication-enabled

為了正確處理客戶端認證，服務(wù)器必須額外添加如下實現(xiàn)：

• 當(dāng)資源必須認證時生成401狀態(tài)碼
• 解析并包含WWW-Authenticate頭
• 實現(xiàn)Basic認證和Digest認證