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

12 頭域定義（Header Field Definitions）

HTTP/1.1或其他未標(biāo)準(zhǔn)化頭域未在這里列出妆档，接收者應(yīng)當(dāng)忽略暫未公認(rèn)定義的頭域配并。

下表中列出了RTSP中使用到的頭域亏推，類型"g"表示通用頭煤墙，類型"R"表示請(qǐng)求頭熄守，類型"r"表示回復(fù)頭睦疫，類型"e"表示實(shí)體頭判耕。標(biāo)記為"req."的頭說明是必需的（required）柑蛇，標(biāo)記為"opt."表示可選的（optional）弊琴。"entity"表示所有方法應(yīng)當(dāng)含有消息主體兆龙。

12.1 Accept

Accept請(qǐng)求頭域可被用于指定回復(fù)中可被接受的呈現(xiàn)描述內(nèi)容類型。

類型描述中的“l(fā)evel”參數(shù)應(yīng)該在MIME類型注冊(cè)中定義敲董，而不是這里紫皇。

示例：
    Accept: application/rtsl,application/sdp;level=2

12.2 Accept-Encoding

見[H14.3]

12.3 Accept-Language

見[H14.4]注意語言作用于呈現(xiàn)描述和原因詞組，而不是媒體內(nèi)容

12.4 Allow

Allow回復(fù)頭域中列出了請(qǐng)求URI中指定資源支持的所有方法腋寨，其目的是告知接收者資源相關(guān)的有效方法聪铺。Allow頭y域必須出現(xiàn)在405(方法不支持)回復(fù)中。

示例：
    Allow:SETUP,PLAY,RECORD,SET_PARAMETER

12.5 Authorization

見[H14.8]

12.6 Bandwidht

帶寬請(qǐng)求頭域描述了預(yù)計(jì)給客戶端的帶寬萄窜，為正整數(shù)铃剔，單位為位每秒（bps）。RTSP會(huì)話過程中帶寬可能發(fā)生變化查刻。

Bandwidth = "Bandwidth" ":" 1*DIGIT
示例：
    Bandwidth: 400

12.7 Blocksize

該請(qǐng)求頭域從客戶端發(fā)送至媒體服務(wù)器键兜，詢問服務(wù)器特定媒體分組大小。該分組大小不包括底層頭如IP穗泵、UDP或RTP普气。服務(wù)器可自由選擇比請(qǐng)求塊更小的size，服務(wù)器可能會(huì)截?cái)喾纸M以貼近媒體指定的最小塊大小佃延，或者r如有必要现诀，直接使用媒體指定的大小夷磕。塊大小必須為正的十進(jìn)制數(shù)，以字節(jié)為單位仔沿。只有在值出現(xiàn)語法錯(cuò)誤時(shí)坐桩，才可以返回（416）錯(cuò)誤。

12.8 Cache-Control

緩存控制通用頭域用于指定請(qǐng)求/回復(fù)鏈中所有緩存機(jī)制必須遵守的策略于未。
緩存策略必須通過代理或網(wǎng)關(guān)程序傳輸撕攒，而不用管是否對(duì)程序本身是否有意義，因?yàn)樵摬呗院苡锌赡軐?duì)請(qǐng)求/回復(fù)鏈中其他接收者有所作用烘浦。同時(shí)抖坪，對(duì)特定魂村指定緩存策略是不可能的。

緩存控制只能在SETUP請(qǐng)求和回復(fù)中指定闷叉，要注意的是擦俐，和HTTP一樣，緩存并不作用于回復(fù)握侧，而是作用于SETUP請(qǐng)求中標(biāo)識(shí)的流蚯瞧。除了DESCRIBE回復(fù)外，其他RTSP回復(fù)均不能進(jìn)行緩存品擎。

Cache-Control          = "Cache-Control" ":" 1#cache-directive
cache-directive         = cache-request-directive
                        | cache-response-directive
cache-request-directive = "no-cache"
                        | "max-stale"
                        | "min-fresh"
                        | "only-if-cached"
                        | cache-extension
cache-response-directive = "public"
                        | "private"
                        | "no-cache"
                        | "no-transform"
                        | "must-revalidate"
                        | "proxy-revalidate"
                        | "max-age" "=" delta-seconds
                        | cache-extension
cache-extension         = token ["=" (token | quoted-string)]

• no-cache:
  表示媒體流不應(yīng)該被緩存埋合，這使得即使服務(wù)器已經(jīng)配置緩存的情況下仍然可以及時(shí)回復(fù)客戶端。
• public:
  表示媒體流可使用任意緩存
• private:
  表示媒體流只針對(duì)單個(gè)用戶萄传，并且不能使用共享緩存進(jìn)行緩存甚颂，只能使用私有緩存進(jìn)行緩存
• no-transform:
  使用間接緩存（代理）時(shí)，能夠轉(zhuǎn)換具體流的媒體類型是比較有用的秀菱。比如振诬，一個(gè)代理可以轉(zhuǎn)換視頻格式以節(jié)省緩存空間以在慢鏈接上降低流量。當(dāng)然也可能會(huì)發(fā)生一些嚴(yán)重操作問題衍菱，比如赶么，當(dāng)這些轉(zhuǎn)換作用到到針對(duì)特定場(chǎng)景流上時(shí)。舉個(gè)例子脊串，醫(yī)療影像類應(yīng)用辫呻、科學(xué)數(shù)據(jù)分析以及其他端對(duì)端授權(quán)都嚴(yán)格依賴與原始實(shí)體主體中位完全一致。此外琼锋，如果回復(fù)中包含了不轉(zhuǎn)換的策略印屁，那么間接緩存或代理絕不能修改流中編碼。與HTTP不同的是斩例，RTSP不提供部分轉(zhuǎn)換雄人，如轉(zhuǎn)換為另一語言。
• only-if-cached:
  有些情況下，如特別差的網(wǎng)絡(luò)連接時(shí)础钠，客戶端可能只希望緩存返回已經(jīng)預(yù)存的媒體流恰力，而不要從原始服務(wù)器上獲取。為了達(dá)到這個(gè)目標(biāo)旗吁，客戶端必須在請(qǐng)求中包含only-if-cached指令踩萎。當(dāng)收到這個(gè)指令時(shí)，緩存可選擇要么發(fā)送已緩存的媒體流很钓，或者直接回復(fù)“504（Gateway Timeout）”狀態(tài)香府。如果一組緩存可以被統(tǒng)一組織、高效利用码倦，這樣的請(qǐng)求則可使用一組緩存企孩。
• max-stale:
  表示客戶端可以接受延時(shí)的媒體流，如果max-stale有給定值（單位為秒）袁稽，那么表示客戶端希望收到延時(shí)范圍在該值內(nèi)的媒體數(shù)據(jù)勿璃；如果沒有給定值，則可以接受任何延時(shí)范圍媒體流推汽。
• min-fresh:
  表示客戶端希望接收至少指定秒（當(dāng)前時(shí)間加上min-fresh）內(nèi)數(shù)據(jù)补疑，即客戶端希望至少提前指定時(shí)間就可以擁有后續(xù)新鮮數(shù)據(jù)
• must-revalidate:
  當(dāng)cache收到來自SETUP回復(fù)中的must-revalidate字段時(shí)，緩存不應(yīng)該在后續(xù)請(qǐng)求中沿用原入口歹撒。也就是說莲组，緩存必須每次都進(jìn)行端對(duì)端驗(yàn)證。

12.9 會(huì)議（Conference）

會(huì)議請(qǐng)求頭域在RTSP流和已建立會(huì)議之間建立了一條邏輯連接暖夭，對(duì)于同一RTSP會(huì)話胁编，其會(huì)議id必須保持一致。

Conference = "Conference" ":" conference-d
e.g.  Conference:199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr

當(dāng)無法找到會(huì)議id時(shí)可回復(fù)“452（未找到會(huì)議）”鳞尔。

12.10 連接（Connection）

見[H14.10]

12.11 內(nèi)容基礎(chǔ)（Content-Base）

見[H14.11]

12.12 內(nèi)容編碼（Content-Encoding）

見[H14.12]

12.13 內(nèi)容語言（Content-Language）

見[H14.13]

12.14 內(nèi)容長(zhǎng)度（Content-Length）

該域包含了本方法中內(nèi)容的長(zhǎng)度（從緊跟最后一個(gè)頭的兩個(gè)CRLF開始計(jì)算）。與HTTP不同的是早直，該域必須存在于所有攜帶除頭信息內(nèi)容以外的消息中寥假，如果該域不存在，默認(rèn)值將賦為0霞扬。解釋部分可參見[H14.14]

12.15 內(nèi)容位置（Content-Location）

見[H14.15]

12.16 內(nèi)容類型（Content-Type）

見[H14.18]糕韧，注意RTSP內(nèi)容類型可能會(huì)被呈現(xiàn)描述和參數(shù)值類型所限制

12.17 序號(hào)CSeq

CSeq域標(biāo)識(shí)RTSP請(qǐng)求-回復(fù)對(duì)序號(hào)，該域所有請(qǐng)求和回復(fù)中必須有喻圃。對(duì)于每一個(gè)包含特定序號(hào)的RTSP請(qǐng)求而言萤彩，一定有一個(gè)擁有相同序號(hào)的對(duì)應(yīng)回復(fù)。重傳的請(qǐng)求必須使用和原始序號(hào)一致的值斧拍。

12.18 Date

見[H14.19]

12.19 過期（Expires）

Expires實(shí)體頭域給出了一個(gè)日期和時(shí)間雀扶，超過該時(shí)間的媒體流或描述將被視為過期的。最終解釋權(quán)歸方法所有。

過期了的緩存入口可能不會(huì)被返回愚墓，除非它是首次與原始服務(wù)器驗(yàn)證予权。進(jìn)一步討論可閱讀13小節(jié)。

出現(xiàn)Expires域時(shí)并不代表原始資源會(huì)在該時(shí)間點(diǎn)前浪册、該時(shí)間點(diǎn)上扫腺、以及時(shí)間點(diǎn)后修改或停止存在。

Expires使用HTTP-date中定義的絕對(duì)日期和時(shí)間村象，它必須遵循RFC1123-date格式：

Expires="Expires" ":" HTTP-date
e.g. Expires: Thu, 01 Dec 1994 16:00:00 GMT

RTSP/1.0客戶端和緩存必須視其他日期格式笆环，特別是值“0”為已經(jīng)過期。

如需標(biāo)記一個(gè)回復(fù)為已過期（“already expired”）厚者，一個(gè)原始服務(wù)器必須使用與Date頭中相同的過期值躁劣。如需標(biāo)記一個(gè)回復(fù)為永不過期，原始服務(wù)器應(yīng)使用回復(fù)發(fā)送時(shí)間加上一年作為過期時(shí)間籍救。

The presence of an Expires header field with a date value of some time in the future on a media stream that otherwise would by default be non-cachable indicates that the media stream is cacheable, unless indicated otherwise by a Cache-Control header field.

12.20 From

見[H14.22]

12.21 Host

該HTTP請(qǐng)求頭域?qū)τ赗TSP并非必需习绢，可在發(fā)送時(shí)直接忽略。

12.22 If-Match

見[H14.25]
該域?qū)τ诖_保呈現(xiàn)描述的完整性特別有用蝙昙，如通過RTSP以外方式獲取呈現(xiàn)描述闪萄，或服務(wù)器實(shí)現(xiàn)中用于確保DESCRIBE消息和SETUP消息間描述的完整性。

標(biāo)識(shí)符并不透明奇颠，因此不會(huì)指向任何特定會(huì)話描述語言败去。

12.23 If-Modified-Since

If-modified-Since請(qǐng)求頭域配合DESCRIBE和SETUP方法使用，使得它們成為附帶條件的烈拒。如果請(qǐng)求的變量從該域指定的時(shí)間開始一直沒有被修改圆裕，則方法為DESCRIBE時(shí)，描述永遠(yuǎn)不會(huì)從服務(wù)器返回荆几，而當(dāng)方法為SETUP時(shí)吓妆，流不會(huì)被建立。相反吨铸，會(huì)返回一條無任何消息主體"304（未修改）"的回復(fù)行拢。

If-Modified-Since = "If-Modified-Since" ":" HTTP-date
e.g. If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

12.24 Last-Modified

Last-Modified實(shí)體頭域標(biāo)明服務(wù)器中承諾描述呈現(xiàn)或流最后修改的時(shí)間和日期。見[H14.29]诞吱。對(duì)于DESCRIBE和ANNOUNCE而言舟奠，該頭域表示描述的最后修改時(shí)間，對(duì)于SETUP而言則針對(duì)媒體流房维。

12.25 Location

見[H14.30]

12.26 代理授權(quán)（Proxy-Authenticate）

見[H14.33]

12.27 代理請(qǐng)求（Proxy-Require）

代理請(qǐng)求頭用于指明代理必須支持的proxy-sensitive特性沼瘫，代理對(duì)于任何代理不支持的請(qǐng)求頭必須給予否定確認(rèn)應(yīng)答。服務(wù)器應(yīng)將該域和請(qǐng)求域視為相同咙俩。

本消息的更多細(xì)節(jié)詳見12.32小節(jié)耿戚。

12.28 Public

見[H14.35]

12.29 Range

請(qǐng)求和回復(fù)頭域中指定一個(gè)時(shí)間范圍，其單位有幾種。本篇規(guī)格中定義smpte溅话、npt和clock范圍單元晓锻。在RTSP中，byte ranges[H14.36.1]沒有意義且不能被使用飞几。頭中可能還包含一個(gè)UTC格式的時(shí)間參數(shù)砚哆，標(biāo)明該操作何時(shí)生效。支持Range頭的服務(wù)器必須也支持NPT范圍格式屑墨，應(yīng)該支持SMPTE范圍格式躁锁。Range回復(fù)頭表示實(shí)際播放和錄制的時(shí)間。如果Range頭是以不能理解的格式給出的卵史，那么接收者應(yīng)回復(fù)"501 未實(shí)現(xiàn)"錯(cuò)誤战转。

Range是半閉合區(qū)間，包含低點(diǎn)以躯，而不包含高點(diǎn)槐秧。換言之，a-b表示從a點(diǎn)開始忧设，在b點(diǎn)前結(jié)束刁标。只偶有音視頻的起始點(diǎn)才是有關(guān)聯(lián)的，比如每隔40ms產(chǎn)生一個(gè)視頻幀址晕，10.0-10.1的范圍說明一個(gè)視頻幀從10.0開始膀懈，最后一個(gè)視頻幀時(shí)間為10.08而不是10.1。

Range             = "Range" ":" 1\#range-specifier
                  [":" "time" "=" utc-time ]
ranges-specifier  = npt-range | utc-range | smpte-range
e.g. 
    Range: clock=19960213T143205Z-;time=19970123T143720Z

Range概念類似于HTTP/1.1中byte-range頭的概念谨垃，它允許客戶端從媒體對(duì)象中選擇片段启搂，然后正常播放出來。播放的起始點(diǎn)可以試試未來的任一位置刘陶，盡管有些服務(wù)器會(huì)拒絕長(zhǎng)時(shí)間保持資源胳赌。

12.30 Referer

見[H14.37] URL指向呈現(xiàn)描述，通吵赘簦可通過HTTP獲取

12.31 Retry-After

見[H14.38]

12.32 Require

Require頭被客戶端用于查詢服務(wù)器是否支持某選項(xiàng)疑苫，對(duì)于不支持的選項(xiàng)，服務(wù)器必須明確給出否定應(yīng)答牡直。
這是為了確保客戶端-服務(wù)器交互中當(dāng)選項(xiàng)彼此都支持時(shí)可以沒有延時(shí)纳决，而只有選項(xiàng)不能識(shí)別是才會(huì)有延緩碰逸。對(duì)于良好匹配的客戶端-服務(wù)器對(duì)而言，交互必須是快速的阔加，而減少往返時(shí)間通常需要溝通機(jī)制饵史。此外，它還能消除服務(wù)器不理解客戶端所請(qǐng)求特性時(shí)可能的狀態(tài)歧義。

Require = "Require" ":" 1#option-tag
e.g.
    C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
            CSeq: 302
            Require: funky-feature
            Funky-Parameter: funkystuff
    
    S->C:   RTSP/1.0 551 Option not supported
            CSeq: 302
            Unsupported: funky-feature
        
    C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
            CSeq: 303
    
    S->C:   RTSP/1.0 200 OK
            CSeq: 303

本例中胳喷，"funky-feature"是標(biāo)明Funky-Parameter域是必需的特性標(biāo)簽湃番，“funky-feature”和Funky-Parameter間的關(guān)系并不通過RTSP交換進(jìn)行溝通，因?yàn)檫@種關(guān)系本來就是“funky-feature”的恒定屬性吭露，因此無需溝通吠撮。

代理及其他中介設(shè)備應(yīng)當(dāng)忽略該域內(nèi)不能理解的特性，如某一特定擴(kuò)展需要中介設(shè)備支持讲竿，那么該擴(kuò)展應(yīng)在Proxy-Require域內(nèi)標(biāo)記泥兰。

12.33 RTP-Info

該域用于在PLAY回復(fù)中設(shè)置RTP相關(guān)的參數(shù)。

• url:
  指明之后RTP參數(shù)所針對(duì)的流URL
• seq:
  指明流中的第一個(gè)分組序號(hào)题禀，這使得客戶端在Seek時(shí)可以更便捷地處理分組鞋诗，因?yàn)榭蛻舳丝墒褂迷撝祬^(qū)分seek操作前后不同的分組
• rtptime
  指明基于Range回復(fù)頭中的RTP時(shí)間戳，客戶端使用該值來完成RTP時(shí)間至NPT的映射迈嘹。（Note: For aggregate control, a particular stream may not actually generate a packet for the Range time value returned or implied. Thus, there is no guarantee that the packet with the sequence number indicated by seq actually has the timestamp indicated by rtptime）

RTP時(shí)間戳至NTP時(shí)間戳的映射表可以通過RTCP獲得削彬，但該信息對(duì)于映射并沒有多少助力。更進(jìn)一步地說秀仲，為了確保該信息在某些時(shí)間（如緊跟啟動(dòng)后或一次seek后）可用融痛，映射表應(yīng)至于RTSP控制通道中。

In order to compensate for drift for long, uninterrupted presentations, RTSP clients should additionally map NPT ot NTP, using initial RTCP sender reports to do the mapping, and later reports to check drift against the mapping.

語法：
    RTP-Info    = "RTP-Info" ":" 1#stream-url 1*parameter
    stream-url   = "url" "=" url
    parameter    = ";" "seq" "=" 1*DIGIT
                   | ";" "rtptime" "=" 1*DIGIT
e.g.
    RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102,
              url=rtsp://foo.com/bar.avi/streamid=1;seq=30211

12.34 Scale

Scale表示當(dāng)前速率和正常觀看速率之間的比例啄育。為1時(shí)表示以正常觀看速度播放或錄制酌心。例如，scale為2時(shí)表示兩倍的觀看速度（快進(jìn)）挑豌，為0.5時(shí)表示正常觀看速度的一半（慢放）安券。換言之，scale為2時(shí)將時(shí)鐘頻率倍乘2氓英，每秒內(nèi)將會(huì)傳送出2秒的數(shù)據(jù)侯勉。而Scale為負(fù)數(shù)時(shí)表示操作方向相反。

雖然Scale改變了播放的速度铝阐，但數(shù)據(jù)傳輸?shù)乃俣葻o法改變址貌，因此scale實(shí)現(xiàn)方式依賴具體服務(wù)器和媒體類型，對(duì)于視頻徘键，服務(wù)器可能通過只傳送關(guān)鍵幀甚至預(yù)選了的關(guān)鍵幀來達(dá)到目的练对，而對(duì)于音頻，服務(wù)器可能會(huì)在保持音調(diào)的基礎(chǔ)上按時(shí)間縮放音頻甚至別無選擇地傳送音頻分片吹害。

服務(wù)器應(yīng)當(dāng)盡可能貼近觀看速度螟凭，但必須嚴(yán)格遵循支持Scale的范圍值∷剑回復(fù)中必須包含服務(wù)器所選擇的的確切Scale值螺男。

如請(qǐng)求中包含Range參數(shù)棒厘，新的Scale參數(shù)必須立即生效。

Scale = "Scale" ":" ["-"] 1*DIGIT ["." *DIGIT]
e.g.   Scale: -3.5

12.35 Speed

Speed在請(qǐng)求頭中用于設(shè)置客戶端向服務(wù)器傳送數(shù)據(jù)的速率下隧，具體實(shí)現(xiàn)取決于服務(wù)器的能力和態(tài)度奢人。該能力對(duì)于服務(wù)器而言是可選的，默認(rèn)為流的比特率淆院。

參數(shù)值使用十進(jìn)制小數(shù)比表示何乎，如2.0表示數(shù)據(jù)以兩倍速率傳輸。0值時(shí)無效的迫筑。如請(qǐng)求中包含Range參數(shù)宪赶，新的速度值將在對(duì)應(yīng)時(shí)刻生效。

Speed = "Speed" ":" 1*DIGIT ["." *DIGIT]
e.g.   Speed: 2.5

使用該域會(huì)影響數(shù)據(jù)傳輸?shù)膸捀迹翘囟ōh(huán)境下以更高或更低預(yù)覽呈現(xiàn)的一種調(diào)整方式搂妻。實(shí)現(xiàn)者應(yīng)記住會(huì)話的帶寬可能會(huì)預(yù)先商定（通過RTSP以外的方式），因此重新協(xié)商是可能有必要的辕棚。當(dāng)數(shù)據(jù)通過UDP傳送時(shí)欲主，推薦使用類似RTCP方式進(jìn)行分組丟失率的追蹤。

12.36 Server

見[H14.39]

12.37 Session

Session在請(qǐng)求回復(fù)頭中標(biāo)識(shí)RTSP會(huì)話中的媒體流逝嚎，該流在服務(wù)器SETUP回復(fù)中啟動(dòng)扁瓢，在TEARDOWN呈現(xiàn)URL時(shí)結(jié)尾。會(huì)話標(biāo)識(shí)符由媒體服務(wù)器選擇（見3.4小節(jié)）补君。一旦客戶端接收到會(huì)話標(biāo)識(shí)符引几，it must return it for any request related to that session. 如有其它方式進(jìn)行標(biāo)識(shí)會(huì)話，如動(dòng)態(tài)生成的URL挽铁，那么服務(wù)器也沒必要一定設(shè)置會(huì)話標(biāo)識(shí)符伟桅。

Session = "Session" ":" session-id [";" "timeout" "=" delta-seconds]

timeout參數(shù)僅允許在回復(fù)頭中使用，服務(wù)器使用它來告知客戶端其多久不活動(dòng)（發(fā)送RTSP命令）后會(huì)話將會(huì)被關(guān)閉叽掘。timeout以秒為單位楣铁，默認(rèn)值為60s（1分鐘）。

注意一個(gè)會(huì)話標(biāo)識(shí)符可跨傳輸會(huì)話或連接使用更扁，操作多個(gè)RTSP URL的控制消息可能通過同一個(gè)RTSP會(huì)話進(jìn)行發(fā)送盖腕。因此，客戶端使用同一會(huì)話控制同一呈現(xiàn)中來自同一服務(wù)器的多個(gè)流也是有可能的浓镜。此外溃列，同一客戶端中對(duì)于相同URL的不同的用戶會(huì)話必須使用不同的會(huì)話標(biāo)識(shí)符。

會(huì)話標(biāo)識(shí)符用于區(qū)分來自同一客戶端對(duì)于相同URL的不同傳輸請(qǐng)求膛薛。

如會(huì)話標(biāo)識(shí)符無效听隐，則返回“454（未找到會(huì)話）”錯(cuò)誤。

12.38 Timestamp

Timestamp描述了客戶端何時(shí)發(fā)送請(qǐng)求給服務(wù)器相叁。該值僅對(duì)客戶端有意義遵绰，可能使用任意時(shí)間格式。服務(wù)器必須返回完全相同的時(shí)間增淹，并且如有可能椿访，附上接收到處理完成進(jìn)行回復(fù)所經(jīng)過的整體時(shí)間。Timestamp用于客戶端計(jì)算到服務(wù)器的往返時(shí)間虑润，以便調(diào)整重傳延時(shí)最大值成玫。

Timestamp   = "Timestamp" ":" *(DIGIT) ["." *(DIGIT)] [ delay ]
delay       = *(DIGIT) ["." *(DIGIT)]

12.39 Transport

Transport頭標(biāo)明要使用何種傳輸協(xié)議，并為流配置其參數(shù)如目標(biāo)地址拳喻、壓縮哭当、多播TTL（time-to-live）以及目標(biāo)端口。它設(shè)置那些呈現(xiàn)描述未能確定的值冗澈。

Transport之間以逗號(hào)分隔钦勘，依次列出。每個(gè)transport可添加參數(shù)亚亲，以分號(hào)隔開彻采。

Transport還可能用于修改具體transport參數(shù)，服務(wù)器可以拒絕修改已存在流上的參數(shù)捌归。

服務(wù)器可在回復(fù)中的Transport頭里標(biāo)明實(shí)際使用的參數(shù)值肛响。

Transport請(qǐng)求頭域中可能包含一系列客戶端支持的傳輸選項(xiàng)，這種情況下惜索，服務(wù)器必須返回實(shí)際選擇的某一選項(xiàng)特笋。

transport/profile/lower-tranpsort

"lower-tranport"的默認(rèn)參數(shù)值與profile密切相關(guān)。對(duì)于RTP/AVP巾兆，默認(rèn)為UDP猎物。

通用參數(shù)

• unicast | multicast
  互斥選項(xiàng)，要么單播要么多播，默認(rèn)值為多播棉圈。同時(shí)支持多播和單播的客戶端必須在參數(shù)中分別列出完整傳輸規(guī)格（transport-spec）以說明能力范圍

• destination
  流發(fā)送的目標(biāo)地址铭乾，客戶端可在destination參數(shù)中指定多播地址。為了避免在不經(jīng)意間成為遠(yuǎn)程控制dos(denial-of-service)攻擊的肇事者质帅，服務(wù)器應(yīng)當(dāng)對(duì)客戶端進(jìn)行認(rèn)證，并且在允許客戶端將媒體流直接給予未經(jīng)過服務(wù)器選擇的地址留攒。這在RTSP命令通過UDP發(fā)送時(shí)尤為重要煤惩，但實(shí)現(xiàn)也不能依賴TCP作為客戶端識(shí)別的有效方式。一個(gè)服務(wù)器不應(yīng)該允許客戶端傳送媒體流至一個(gè)與命令來源不同過得地址炼邀。

• source
  如果流的源地址與可傳輸?shù)腞TSP端點(diǎn)地址不同（服務(wù)器在播放或客戶端在錄制中）魄揉，source字段將被指定。
  該信息還可從SDP中獲取拭宁。由于這更多地是像一個(gè)傳輸特性而不是媒體初始化洛退，因此該信息的權(quán)威source應(yīng)是SETUP回復(fù)中出現(xiàn)過的瓣俯。

• layers
  該流可使用的多播層數(shù)量，所有層將發(fā)送給以目標(biāo)地址開頭的連續(xù)地址

• mode
  mode參數(shù)用于標(biāo)示當(dāng)前會(huì)話支持的所有方法兵怯，有效值為PLAY和RECORD彩匕。如不提供，則默認(rèn)為PLAY

• append
  如果mode參數(shù)包含了RECORD媒区，緊跟的參數(shù)標(biāo)示媒體數(shù)據(jù)應(yīng)當(dāng)追加到已存在的資源上而不是覆蓋驼仪。如請(qǐng)求中追加的參數(shù)服務(wù)器并不支持，它必須拒絕該請(qǐng)求而不是使用URI覆蓋資源標(biāo)識(shí)符袜漩。如mode未包含RECORD绪爸，則追加參數(shù)互備直接忽略。

• interleaved
  交錯(cuò)參數(shù)表示在控制流使用的任何協(xié)議中交錯(cuò)傳輸媒體流和控制流宙攻，交錯(cuò)方法使用10.12小節(jié)中的機(jī)制奠货。interleaved提供了語句中將要使用到的channel序號(hào)。該參數(shù)可能被指派一個(gè)范圍座掘，如interleaved=4-5 以便媒體流選擇傳輸時(shí)做決定仇味。

  這使得RTP/RTCP可使用與UDP一致的方法處理，如RTP一個(gè)channel雹顺，其他channel則給RTCP使用丹墨。

• 多播相關(guān)（Multicast specific）

  • ttl
    多播time-to-live

• RTP Specific

  • port
    port參數(shù)為多播會(huì)話提供RTP/RTCP端口對(duì)，以范圍形式給出嬉愧，如 port=3456-3457

  • client_port
    該參數(shù)為被選擇用于接收媒體數(shù)據(jù)和控制信息的客戶端提供了單播RTP/RTCP端口對(duì)贩挣，以范圍形式給出，如 client_port=3456-3457

  • server_port
    參數(shù)為被選擇用于接收媒體數(shù)據(jù)和控制信息的服務(wù)器提供了單播RTP/RTCP端口對(duì)没酣，以范圍形式給出王财，如 server_port=3456-3457

  • ssrc
    ssrc參數(shù)標(biāo)明了RTP SSRC值可能會(huì)被媒體服務(wù)器使用（請(qǐng)求中應(yīng)當(dāng)使用，而回復(fù)中一定會(huì)使用到）裕便，該參數(shù)僅對(duì)單播傳輸有效绒净。它標(biāo)示與媒體流相聯(lián)系的同步源。

Transport             =    "Transport" ":"
                           1\#transport-spec
transport-spec        =    transport-protocol/profile[/lower-transport]
                          *parameter
transport-protocol    =    "RTP"
profile               =    "AVP"
lower-transport       =    "TCP" | "UDP"
parameter             =    ( "unicast" | "multicast" )
                    |    ";" "destination" [ "=" address ]
                    |    ";" "interleaved" "=" channel [ "-" channel ]
                    |    ";" "append"
                    |    ";" "ttl" "=" ttl
                    |    ";" "layers" "=" 1*DIGIT
                    |    ";" "port" "=" port [ "-" port ]
                    |    ";" "client_port" "=" port [ "-" port ]
                    |    ";" "server_port" "=" port [ "-" port ]
                    |    ";" "ssrc" "=" ssrc
                    |    ";" "mode" = <"> 1\#mode <">
ttl                    =    1*3(DIGIT)
port                =    1*5(DIGIT)
ssrc                =    8*8(HEX)
channel             =    1*3(DIGIT)
address             =    host
mode                =    <"> *Method <"> | Method

示例：
    Transport: RTP/AVP;multicast;ttl=127;mode="PLAY"
               RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"

    傳輸頭用于描述單一RTP流（RTSP也可用于像一個(gè)整體一樣控制多個(gè)流）偿衰，將其作為RTSP的一部分而不是依賴一堆會(huì)話描述格式可以極大簡(jiǎn)化防火墻的設(shè)計(jì)挂疆。  

12.40 不支持（Unsupported）

Unsupported回復(fù)頭中列出了服務(wù)器不支持的特性，在前述通過Proxy-Require域（12.32小節(jié)）指定特性情況中下翎，如果在客戶端訥河服務(wù)器間有同路缤言，那么proxy必須在回復(fù)中插入“551 選項(xiàng)不支持”錯(cuò)誤消息。

使用示例可見12.32小節(jié)视事。

12.41 User-Agent

見[H14.42]

12.42 Vary

見[H14.43]

12.43 Via

見[H14.44].

12.44 WWW-Authentica

見[H14.46].

13 緩存（Caching）
在HTTP中胆萧，請(qǐng)求-回復(fù)對(duì)會(huì)被緩存。在這一點(diǎn)上俐东，RTSP明顯不同跌穗《┥危回復(fù)是不進(jìn)行緩存的，除非是通過DESCRIBE或ANNOUNCE方法返回呈現(xiàn)描述（因?yàn)镈ESCRIBE和GET_PARAMETER并不返回任何數(shù)據(jù)蚌吸，因此緩存回復(fù)對(duì)請(qǐng)求沒有影響）腾仅。而且，對(duì)于連續(xù)媒體數(shù)據(jù)套利、會(huì)話描述，特別是RTSP中通過帶外傳輸鹤耍，都建議被緩存肉迫。

在接收到SETUP或PLAY請(qǐng)求后，代理檢查其是否有一個(gè)連續(xù)媒體內(nèi)容及其描述的最新副本稿黄。它可以通過SETUP或DESCRIBE請(qǐng)求來確定副本是否最新喊衫。如果不是最新，則將SETUP傳輸參數(shù)修改合適并將請(qǐng)求遞送給原始服務(wù)器杆怕。后續(xù)控制命令如PLAY或PAUSE則繼續(xù)傳送未經(jīng)代理修改過的版本族购。代理在傳輸連續(xù)媒體數(shù)據(jù)給客戶端的同時(shí)，如有可能應(yīng)制作副本方便后續(xù)使用陵珍。允許魂村的確切操作是通過12.8小節(jié)中cache-response指令完成寝杖。如果緩存為請(qǐng)求者提供流，那么它必須回復(fù)任何DESCRIBE請(qǐng)求互纯，因?yàn)榱髅枋龅讓蛹?xì)節(jié)可能被原始服務(wù)器進(jìn)行修改瑟幕。

注意RTSP緩存與HTTP緩存不同，是“cut-through”類型留潦。與從原始服務(wù)器獲取整個(gè)資源不同只盹，緩存只拷貝經(jīng)過其流向客戶端的流數(shù)據(jù)。也就是說兔院，它并不會(huì)引入額外延時(shí)殖卑。

對(duì)于客戶端而言，RTSP代理緩存就像一個(gè)正常媒體服務(wù)器坊萝，對(duì)于服務(wù)器而言孵稽，又像一個(gè)客戶端。正如HTTP緩存需為其緩存的對(duì)象存儲(chǔ)內(nèi)容類型十偶、內(nèi)容語言等等肛冶，媒體緩存也需要存儲(chǔ)呈現(xiàn)描述。典型的有扯键，緩存消除了描述呈現(xiàn)中的所有傳輸應(yīng)用（如睦袖，多播信息），由于這些獨(dú)立的數(shù)據(jù)從緩存?zhèn)魉偷娇蛻舳巳傩獭＞幋a信息仍保持原狀馅笙，如果緩存要能夠轉(zhuǎn)換緩存的媒體數(shù)據(jù)伦乔，它必須創(chuàng)建一個(gè)包含所有能提供編碼可能的新的呈現(xiàn)描述。

14 示例（Examples）

下列示例參考了未標(biāo)準(zhǔn)化的流描述格式董习，如RTSL烈和，并不能作為這些格式使用參考。

14.1 媒體點(diǎn)播（單播）（Media on Demand (Unicast)）

客戶端C從服務(wù)器A(audio.example.com)和服務(wù)器V（video.example.com）請(qǐng)求一個(gè)影片皿淋。媒體描述存儲(chǔ)在web服務(wù)器W上招刹。

媒體描述中包括呈現(xiàn)及其所有流信息、支持的編碼器窝趣、動(dòng)態(tài)RTP負(fù)載類型疯暑、協(xié)議棧以及如語言、版權(quán)等內(nèi)容信息哑舒。甚至有可能涉及影片的timeline妇拯。

本例中，客戶端只希望接收影片的最后一部分洗鸵。

C->W:   GET /twister.sdp HTTP/1.1
        Host: www.example.com
        Accept: application/sdp

W->C:   HTTP/1.0 200 OK
        Content-Type: application/sdp
        v=0
        o=- 2890844526 2890842807 IN IP4 192.16.24.202
        s=RTSP Session
        m=audio 0 RTP/AVP 0
        a=control:rtsp://audio.example.com/twister/audio.en
        m=video 0 RTP/AVP 31
        a=control:rtsp://video.example.com/twister/video
        
C->A:   SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
        CSeq: 1
        Transport: RTP/AVP/UDP;unicast;client_port=3056-3057
        
A->C:   RTSP/1.0 200 OK
        CSeq: 1
        Session: 12345678
        Tranport: RTP/AVP/UDP;unicast;client_port=3056-3057;
                  server_port=5000-5001

C->V:   SETUP rtsp://video.example.com/twister/vidoe RTSP/1.0
        CSeq: 1
        Transport: RTP/AVP/UDP;unicast;client_port=3058-3059
        
V->C:   RTSP/1.0 200 OK
        CSeq: 1
        Session: 23456789
        Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;
                   server_port=5002-5003
                   
C->V:   PLAY rtsp://video.example.com/twister/video RTSP/1.0
        CSeq: 2
        Session: 23456789
        Range: smpte=0:10:00-

V->C:   RTSP/1.0 200 OK
        CSeq: 2
        Session: 23456789
        Range: smpte=0:10:00-0:20:00
        RTP-Info: url=rtsp://video.example.com/twister/video;
                  seq=12312232;rtptime=78712811

C->A:   PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
        CSeq: 2
        Session: 12345678
        Range: smpte=0:10:00-
        
A->C:   RTSP/1.0 200 OK
        CSeq: 2
        Session: 12345678
        Range: smpte=0:10:00-0:20:00
        RTP-Info: url=rtsp://audio.example.com/twister/audio.en;
                  seq=876655;rtptime=1032181

C->A:   TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0
        CSeq: 3
        Session: 12345678
        
A->C:   RTSP/1.0 200 OK
        CSeq: 3
        
C->V:   TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
        CSeq: 3
        Session: 23456789

V->C:   RTSP/1.0 200 OK
        CSeq: 3

即使音視頻軌可能來自不同的服務(wù)器越锈，甚至有不同的起始時(shí)間，客戶端都能夠通過標(biāo)準(zhǔn)RTP方法將兩者同步膘滨，特別是RTCP發(fā)送報(bào)告總的時(shí)間刻度甘凭。

14.2 容器文件串流（Streaming of a Container file）

本例中，容器文件表示一個(gè)存儲(chǔ)實(shí)體中含有同一終端呈現(xiàn)相關(guān)的多個(gè)連續(xù)媒體類型火邓，實(shí)際上对蒲，容器文件表示了一個(gè)RTSP呈現(xiàn)，它的每個(gè)組件都是RTSP流贡翘。容器文件是存儲(chǔ)這類呈現(xiàn)的通用方法蹈矮。由于所有組件都以獨(dú)立流形式傳輸，因此需要在服務(wù)器端為所有流維護(hù)一個(gè)通用上下文（Context）鸣驱。

這使得服務(wù)器保持一個(gè)簡(jiǎn)單存儲(chǔ)句柄變得簡(jiǎn)單泛鸟，它還允許平等對(duì)待所有流以防服務(wù)器對(duì)流進(jìn)行優(yōu)先級(jí)排序。

有可能呈現(xiàn)的作者不希望客戶端選擇性獲取流踊东，以便保護(hù)媒體呈現(xiàn)的藝術(shù)效果北滥。同樣地，對(duì)于這樣緊密結(jié)合的呈現(xiàn)闸翅，通過一條簡(jiǎn)單的作用于聚合URL的控制消息來控制所有流也是比較合適的再芋。

下面給出了一個(gè)使用RTSP會(huì)話來控制多個(gè)流的例子，它還演示了聚合URL的使用坚冀。

客戶端C從媒體服務(wù)器M上獲取一個(gè)呈現(xiàn)济赎，影片存放在一個(gè)容器文件中。客戶端已獲得一個(gè)指向容器文件的RTSP URL司训。

C->M:   DESCRIBE rtsp://foo/twister RTSP/1.0
        CSeq: 1
        
M->C:   RTSP/1.0 200 OK
        CSeq: 1
        Content-Type: application/sdp
        Content-Length: 164
        v=0
        o=- 28908442586 2890842808 IN IP4 172.16.2.93
        s=RTSP Session
        i=An Example of RTSP Session Usage
        a=control:rtsp://foo/twister
        t=0 0
        m=audio 0 RTP/AVP 0
        a=control:rtsp://foo/twister/audio
        m=video 0 RTP/AVP 26
        a=control:rtsp://foo/twister/video
        
C->M:   SETUP rtsp://foo/twister/audio RTSP/1.0
        CSeq: 2
        Transport: RTP/AVP;unicast;client_port=8000-8001
        
M->C:   RTSP/1.0 200 OK
        CSeq: 2
        Transport: RTP/AVP;unicast;client_port=8000-8001;
                   server_port=9000-9001
        Session: 12345678

C->M:   SETUP rtsp://foo/twister/video RTSP/1.0
        CSeq: 3
        Transport: RTP/AVP;unicast;client_port=8002-8003
        Session: 12345678

M->C:   RTSP/1.0 200 OK
        CSeq: 3
        Transport: RTP/AVP;unicast;client_port=8002-8003;
                   server_port=9004-9005
        Session: 12345678

C->M:   PLAY rtsp://foo/twister RTSP/1.0
        CSeq: 4
        Range: npt=0-
        Session: 12345678
        
M->C:   RTSP/1.0 200 OK
        CSeq: 4
        Session: 12345678
        RTP-Info: url=rtsp://foo/twister/video;seq=9810092;rtptime=3450012

C->M:   PAUSE rtsp://foo/twister/video RTSP/1.0
        CSeq: 5
        Session: 12345678

M->C:   RTSP/1.0 460 Only aggregate operation allowed
        CSeq: 5

C->M:   PAUSE rtsp://foo/twister RTSP/1.0
        CSeq: 6
        Session: 12345678

M->C:   RTSP/1.0 200 OK
        CSeq: 6
        Session: 12345678
        
C->M:   SETUP rtsp://foo/twister RTSP/1.0
        CSeq: 7
        Transport: RTP/AVP;unicast;client_port=10000

M->C:   RTSP/1.0 459 Aggregate operation not allowed
        CSwq: 7

第一次錯(cuò)誤是因?yàn)榭蛻舳藝L試只暫停呈現(xiàn)中的某一個(gè)流（這里是視頻）构捡，而服務(wù)器并不支持對(duì)呈現(xiàn)做該操作。
第二次錯(cuò)誤中則是因?yàn)閁RL不能用在SETUP方法中壳猜，必須對(duì)其中流分別進(jìn)行參數(shù)SETUP勾徽。

這使得傳輸頭變得簡(jiǎn)單而且更便于防火墻解析傳輸信息。

14.3 單一流容器文件（Single Stream Container Files）

部分RTSP服務(wù)器可能將所有文件都視為容器文件统扳，而其他服務(wù)器可能并沒有這個(gè)概念喘帚。因此，客戶端應(yīng)當(dāng)使用會(huì)話描述中規(guī)則去請(qǐng)求URL咒钟，而不是假設(shè)會(huì)一直使用同一個(gè)URL吹由。下面是一個(gè)期望multi-stream服務(wù)器提供single-stream服務(wù)的例子：

        Accept: application/x-rtsp-mh, application/sdp
        CSeq: 1
        
S->C:   RTSP/1.0
        CSeq: 1
        Content-base: rtsp://foo.com/test.wav/
        Content-type: applciation/sdp
        Content-length: 48
        
        v=0
        o=- 872653257 872653257 IN IP4 172.16.2.187
        s=mu-law wave file
        i=audio test
        t=0 0 
        m=audio 0 RTP/AVP 0
        a=control:streamid=0
        
C->S:   SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
        Transport: RTP/AVP/UDP;unicast;client_port=6970-6971;mode=play
        CSeq: 2

S->C:   RTSP/1.0 200 OK
        Transport: RTP/AVP/UDP;unicast;client_port=6970-6971;
                   server_port=6970-6971;mode=play
        CSeq: 2
        Session: 2034820394

C->S:   PLAY rtsp://foo.com/test.wav RTSP/1.0
        CSeq: 3
        Session: 2034820394

S->C:   RTSP/1.0 200 OK
        CSeq: 3
        Session: 2034820394
        RTP-Info: url=rtsp://foo.com/test.wav/streamid=0;
                  seq=98188;rtptime=3781123

注意SETUP命令中的URL有所不同腕够，緊跟著的PLAY命令仍然使用聚合URL。這使得對(duì)多個(gè)流進(jìn)行聚合控制的概念更加完整，而當(dāng)流數(shù)目只有一個(gè)時(shí)资柔，會(huì)略顯得沒有那么直觀。

在這個(gè)特定場(chǎng)景下，服務(wù)器最好能兼容（it is recommended that servers be forgiving of implementations）如下操作：

C->S:   PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
        CSeq: 3

實(shí)在不行纵搁，服務(wù)器至少應(yīng)回復(fù)：

S->C:   RTSP/1.0 460 Only aggregate operation allowed
        CSeq: 3

如有可能，服務(wù)器也可以支持如下操作：

C->S:   SETUP rtsp://foo.com/test.wav RTSP/1.0
        Transport: rtp/avp/udp;client_port=6970-6971;mode=play
        CSeq: 2

因?yàn)槲募胁]有其他流惑灵，所以并不會(huì)引起歧義哮伟。

14.4 使用多播的直播呈現(xiàn)（Live Media Presentation Using Multicast）

媒體服務(wù)器M選擇多播地址和端口池凄。假設(shè)web服務(wù)器只包含指向完整描述的指針，而媒體服務(wù)器M維護(hù)著完整描述信息。

C->W:   GET /concert.sdp HTTP/1.1
        Host: www.example.com

W->C:   HTTP/1.1 200 OK
        Content-Type: application/x-rtsl
        
        <session>
            <track src="rtsp://live.example.com/concert/audio">
        </session>

C->M:   DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0
        CSeq: 1
        
M->C:   RTSP/1.0 200 OK
        CSeq: 1
        Content-Type: application/sdp
        Content-Length: 44
        
        v=0
        o=- 2890844526 2890842807 IN IP4 192.168.24.202
        s=RTSP Session
        m=audio 3456 RTP/AVP 0
        a=control:rtsp://live.example.com/concert/audio
        c=IN IP4 224.2.0.1/16
    
C->M:   SETUP rtsp://live.example.com/concert/audio RTSP/1.0
        CSeq: 2
        Transport: RTP/AVP;multicast

M->C:   RTSP/1.0 200 OK
        CSeq: 2
        Transport: RTP/AVP;multicast;destination=224.2.0.1匪煌；
                   port=3456-3457;ttl=16
        Session: 0456804596
        
M->C:   RTSP/1.0 200 OK
        CSeq: 2
        Transport: RTP/AVP;multicast;destination=224.2.0.1;
                   port=3456-3457;ttl=16
        Session: 0456804596

C->M:   PLAY rtsp://live.example.com/concert/audio RTSP/1.0
        CSeq: 3
        Session: 0456804596
        
M->C:   RTSP/1.0 200 OK
        CSeq: 3
        Session: 0456804596

14.5 在已存在會(huì)話中播放媒體（Playing media into an existing session）

一個(gè)會(huì)議參與者C希望媒體服務(wù)器M在現(xiàn)有會(huì)議中播放一個(gè)demo，C告知了媒體服務(wù)器M會(huì)議的網(wǎng)絡(luò)地址和加密后的key支子，所以服務(wù)器沒必要進(jìn)行地址選擇巩搏。下例中忽略了簡(jiǎn)單的ACK回復(fù)丰辣。

C->M:   DESCRUBE rtsp://server.example.com/demo/548/sound RTSP/1.0
        CSeq: 1
        Accept: application/sdp

M->C:   RTSP/1.0 200 1 OK
        Content-type: application/sdp
        Content-Length: 44
        
        v=0
        0=- 2890844526 2890842807 IN IP4 192.16.24.202
        s=RTSP Session
        i=See above
        t=0 0
        m=audio 0 RTP/AVP 0

C->M:   SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0
        CSeq: 2
        Transport: RTP/AVP;multicast;destination=225.219.201.15;
                   port=7000-7001;ttl=127
        Conference: 199702170042.SAA08642@obivan.arl.wustl.edu%20Starr
        
M->C:   RTSP/1.0 200 OK
        CSeq: 2
        Transport: RTP/AVP;multicast;destination=225.219.201.15;
                    port=7000-7001;ttl=127
        Session: 91389234234
        Conference: 199702170042.SAA08642@obivan.arl.wustl.edu%29Starr
        
C->M:   PLAY rtsp://server.example.com/demo/548/sound RTSP/1.0
        CSeq: 3
        Session: 91389234234
        
M->C:   RTSP/1.0 200 OK
        CSeq: 3

14.6 錄制（Recording）

會(huì)議參與者客戶端C請(qǐng)求服務(wù)器M去錄制會(huì)議音視頻部分，客戶端使用ANNOUNCE方法來想服務(wù)器提供錄制會(huì)話的元信息。

C->M:   ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0
        CSeq: 90
        Content-Type: application/sdp
        Content-Length: 121
        
        v=0
        o=cameral 3080117314 3080118787 IN IP4 195.27.192.36
        s=IETF Meeting, Munich - 1
        i=The thirty-ninth IETF meeting will be held in Munich, Germany
        u=http://www.ietf.org/meetings/Munich.html
        e=IETF Channel 1 <ietf39-mbone@uni-koeln.de>
        p=IETF Channel 1 +49-172-2312 451
        c=IN IP4 224.0.1.11/127
        t=3080271600 3080703600
        a=tool:sdr v2.4a6
        a=type:test
        m=audio 21010 RTP/AVP 5
        c=IN IP4 224.0.1.11/127
        a=ptime:40
        m=video 61010 RTP/AVP 31
        c=IN IP4 224.0.1.12/127

M->C:   RTSP/1.0 200 OK
        CSeq: 90

C-M:    SETUP rtsp://server.example.com/meeting/audiotrack RTSP/1.0
        CSeq: 91
        Transport: RTP/AVP;multicast;destination=224.0.1.11;
                   port=21010-21011;mode=record;ttl=127

M->C:   RTSP/1.0 200 OK
        CSeq: 91
        Session: 50887676
        Transport: RTP/AVP;multicast;destination=224.0.1.11;
                   port=21010-21011;mode=record;ttl=127

C->M:   SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0
        CSeq: 92
        Session: 50887676
        Transport: RTP/AVP;multicast;destination=224.0.1.12;
                   port=61010-61011;mode=record;ttl=127
                   
M-C:   RTSP/1.0 200 OK
        CSeq: 92
        Transport: RTP/AVP;multicast;destination=224.0.1.12;
                   port=61010-61011;mode=record;ttl=127
                   
C->M:   RECORD rtsp://server.example.com/meeting RTSP/1.0
        CSeq: 93
        Session: 50887676
        Range: clock=19961110T1925-19961110T2015

M-C:   RTSP/1.0 200 OK
        CSeq: 93

15 語法（Syntax）

RTSP語法使用RFC 2068中的巴科斯范式（BNF腕扶，argumented Backus-Naur form）進(jìn)行描述。

15.1 基礎(chǔ)語法（Base Syntax）

OCTET           = <any 8-bit sequence of data>
CHAR             = <any US-ASCII character (octets 0-127)>
UPALPHA       = <any US-ASCII uppercase letter "A".."Z">
LOALPHA       = <any US_ASCII lowercase letter "a".."z">
ALPHA           = UPALPHA | LOALPHA
DIGIT           = <any US-ASCII digit "0".."9">
CTL           = <any US-ASCII control character (octets 0-31) and DEL(127)>
CR             = <US-ASCII CR, carriage return(13)>
LF             = <US-ASCII LF, linefeed(10)>
SP             = <US-ASCII SP, space(32)>
HT             = <US-ASCII HT, horizontal-tab(9)>
<">           = <US-ASCII double-quote mark(34)>
CRLF             = CR LF
LWS           = [CRLF] 1*( SP | HT )
TEXT             = <any OCTET except CTLs>
tspecials      = "(" | ")" | "<" | ">" | "@"
                 | "," | ";" | ":" | "\" | <">
                 | "/" | "[" | "]" | "?" | "="
                 | "{" | "}" | SP | HT
token           = 1*<any CHAR except CTLs or tspecials>
quoted-string   = (<"> * (qdtext) <">)
qdtext         = <any TEXT except <">>
quoted-pari   = "\" CHAR
message-header  = field-name ":" [field-value] CRLF
field-name    = token
field-value  = *( field-content | LWS )
field-content   = <the OCTETs making up the field-value and 
                    consisiting of either *TEXT or 
                    combinations of token, tspecials, 
                    and quoted-string>
safe            = "\$" | "-" | "_" | "." | "+"
extra          = "!" | "*" | "$'$" | "(" | ")" | ","
hex          = DIGIT | "A" | "B" | "C" | "D" | "E" | "F"
                        | "a" | "b" | "c" | "d" | "e" | "f"
escape        = "\%" hex hex
reserved       = ";" | "/" | "?" | ":" | "@" | "&" | "="
unreserved      = alpha | digit | safe | extra
xchar       = unreserved | reserved | escape

16 安全須知（Security Considerations）

由于RTSP服務(wù)器和HTTP服務(wù)器語法上類似棉磨，因此主要安全須知已在[H15]中列出策泣。其他需要注意的如下： 、

• 認(rèn)證機(jī)制（Authentication Mechanisms）
  RTSP和HTTP共享通用認(rèn)證方案，因此也必須遵循相同的認(rèn)證描述方式。客戶端認(rèn)證可參考[H15.1]棚瘟，對(duì)于多種認(rèn)證機(jī)制則可參考[H15.2]

• 服務(wù)器日志信息的濫用（Abuse of Server Log Information）
  RTSP和HTTP服務(wù)器應(yīng)該也是使用相同的日志機(jī)制返顺，因此也都需要保護(hù)日志內(nèi)容，及對(duì)服務(wù)器用戶的隱私進(jìn)行保護(hù)慧邮∫湮剑可參考[H15.3]中HTTP服務(wù)器對(duì)一些日志的建議

• 敏感信息傳輸（Transfer of Sensitive Information）
  沒有理由可以相信通過RTSP傳輸信息會(huì)比直接通過HTTP傳輸更不敏感茎活。事實(shí)上，所有關(guān)于數(shù)據(jù)隱私和用戶隱私的防御措施都應(yīng)用到RTSP客戶端、服務(wù)器和代理的實(shí)現(xiàn)上，進(jìn)一步細(xì)節(jié)可參考[H15.4]

• 基于文件和路徑名稱的攻擊（Attacks Based On File and Path Names）
  盡管RTSP URL是不透明的操作句柄，使用時(shí)沒必要有文件系統(tǒng)的語義摻入，但預(yù)期很多實(shí)現(xiàn)還是會(huì)將請(qǐng)求URL部分轉(zhuǎn)換為文件系統(tǒng)調(diào)用。這種情況下途凫，文件系統(tǒng)應(yīng)當(dāng)遵循[H15.5]中提到的主要預(yù)防措施，如路徑中檢查".."關(guān)鍵字等阅畴。

• 個(gè)人信息（Personal Information）
  RTSP客戶端中通常將HTTP客戶端中視為隱私的信息（如用戶名冯事、位置等）進(jìn)行保護(hù)摔笤，更多建議請(qǐng)閱讀[H15.6]

• 與Accept頭有關(guān)隱私問題（Privacy Issues Connected to Accept Headers）
  由于RTSP和HTTP中可能存在相同"Accept"頭命辖，其他注意事項(xiàng)已在[H15.7]中列出终娃，使用時(shí)根據(jù)具體情況進(jìn)行調(diào)整

• DNS欺騙（DNS Spoofing）
  相對(duì)HTTP會(huì)話辉巡，有可能給予更長(zhǎng)連接時(shí)間給RTSP會(huì)話，RTSP客戶端DNS客戶端也暫未流行放椰。此外砾医，[H15.8]中提供了基于DNS-to-IP映射實(shí)現(xiàn)相應(yīng)的建議

• 位置頭和欺騙（Location Headers and Spoofing）
  如一個(gè)簡(jiǎn)單服務(wù)器支持多個(gè)互不信賴的組織，那么服務(wù)器必須校驗(yàn)控制生成的回復(fù)中Location和Content-Location頭衣厘，以確保他們不會(huì)嘗試廢棄沒有權(quán)限的資源（[H15.9]）如蚜。

在現(xiàn)有HTTP規(guī)格基礎(chǔ)上，未來HTTP可能會(huì)提供對(duì)安全問題提供額外的保障影暴。

下列內(nèi)容時(shí)RTSP實(shí)現(xiàn)時(shí)應(yīng)額外考慮的部分：

• 集中DOS攻擊(Concentrated denial-of-service attack)
  RTSP提供了遠(yuǎn)程控制DOS攻擊的機(jī)會(huì)错邦，這些攻擊者可能通過在SETUP請(qǐng)求中指定一至多個(gè)IP地址初始化工作流。由于這種情況下攻擊者的IP地址是可見的型宙，在防御更多攻擊和查明攻擊者身份后撬呢，攻擊并不總能有效。RTSP服務(wù)器應(yīng)當(dāng)只允許認(rèn)證過身份的客戶端在RTSP初始化時(shí)指定目標(biāo)地址妆兑，認(rèn)證方法可以是通過RTSP授權(quán)機(jī)制（preferably digest authentication or stronger）建立用戶數(shù)據(jù)庫魂拦，或者其他安全措施毛仪。

• 會(huì)話劫持（Session jijacking）
  由于傳輸層和RTSP會(huì)話層沒有關(guān)聯(lián)，有可能存在惡意客戶端使用隨機(jī)會(huì)話標(biāo)識(shí)符進(jìn)行請(qǐng)求從而影響其他未知客戶端芯勘。服務(wù)器應(yīng)當(dāng)使用一個(gè)大潭千、隨機(jī)而且無序的會(huì)話標(biāo)識(shí)符來盡可能減小此種攻擊的可能性。

• 認(rèn)證（Authentication）
  服務(wù)器應(yīng)當(dāng)實(shí)現(xiàn)basic和digest認(rèn)證借尿，當(dāng)環(huán)境需要給控制消息更嚴(yán)格的安全機(jī)制時(shí)刨晴，RTSP控制流可能需要被加密。

• 流問題（Stream issues）
  RTSP只提供流控制部分路翻，流傳輸?shù)膯栴}并不包含在本文內(nèi)狈癞。RTSP實(shí)現(xiàn)很大程度上需要依賴其他協(xié)議如RTP，IP多播茂契，RSVP和IGMP蝶桶，所以要在這些協(xié)議及其他可使用規(guī)格中提請(qǐng)解決安全考慮。

• 持續(xù)的可疑行為（Persistently suspicious behavior）
  RTSP服務(wù)器應(yīng)當(dāng)對(duì)判定存在安全風(fēng)險(xiǎn)的行為回應(yīng)“403（Forbidden）”錯(cuò)誤掉冶，RTSP服務(wù)器應(yīng)當(dāng)能夠察覺是否有客戶端在搜尋服務(wù)器漏洞和入口的嘗試真竖，如發(fā)現(xiàn)則應(yīng)判定為違反本地安全策略，并果斷斷開并忽略后續(xù)任何請(qǐng)求厌小。