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命令俏拱，該間隔默認(rèn)為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一致，媒體代理會認(rèn)定呈現(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 負(fù)載類型

負(fù)載類型在"m="域中指定，當(dāng)負(fù)載類型是RFC 1890中的靜態(tài)負(fù)載類型時牺丙，無需其他信息则涯。而如果是一個動態(tài)負(fù)載類型，"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進一步獲取詳細(xì)媒體流信息時非常有用或颊。

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)時需要認(rèn)證猜谚，客戶端必須添加如下支持：

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

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在確保滑動條位置正確時是必需的捌朴。

D.2.2 Authentication-enabled

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

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