RTSP Spec中文版(12-16)

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."的頭說(shuō)明是必需的（required），標(biāo)記為"opt."表示可選的（optional）。"entity"表示所有方法應(yīng)當(dāng)含有消息主體。

Header type support methods
Accept R opt. entity
Accept-Encoding R opt. entity
Accept-Language R opt. all
Allow r opt. all
Authorization R opt. all
Bandwidth R opt. all
Blocksize R opt. all but OPTIONS, TEARDOWN
Cache-Control g opt. SETUP
Conference R opt. SETUP
Connection g req. all
Content-Base e opt. entity
Content-Encoding e req. SET_PARAMETER
Content-Encoding e req. DESCRIBE, ANNOUNCE
Content-Language e req. DESCRIBE, ANNOUNCE
Content-Length e req. SET_PARAMETER, ANNOUNCE
Content-Length e req. entity
Content-Location 3 opt. entity
Content-Type e req. SET_PARAMETER, ANNOUNCE
Content-Type r req. entity
CSeq g req. all
Date g opt. all
Expires e opt. DESCRIBE, ANNOUNCE
From R opt. all
If-Modified-Since R opt. DESCRIBE, SETUP
Last-Modified e opt. entitiy
Proxy-Authenticate
Proxy-Require R req. all
Public r opt. all
Range R opt. PLAY,PAUSE,RECORD
Range r opt. PLAY,PAUSE,RECORD
Referer R opt. all
Require R req. all
Retry-After r opt. all
Rtp-Info r req. PLAY
Scale Rr opt. PLAY,RECORD
Session Rr req. all but SETUP,OPTIONS
Server r opt. all
Speed Rr opt. PLAY
Transport Rr req. SETUP
Unsupported r req. all
User-Agent R opt. all
Via g opt. all
WWW-Authenticate r opt. all

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]注意語(yǔ)言作用于呈現(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ì)話過(guò)程中帶寬可能發(fā)生變化。

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

12.7 Blocksize

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

12.8 Cache-Control

緩存控制通用頭域用于指定請(qǐng)求/回復(fù)鏈中所有緩存機(jī)制必須遵守的策略。
緩存策略必須通過(guò)代理或網(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)重操作問(wè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)換為另一語(yǔ)言。
  • 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收到來(lái)自SETUP回復(fù)中的must-revalidate字段時(shí)，緩存不應(yīng)該在后續(xù)請(qǐng)求中沿用原入口。也就是說(shuō)，緩存必須每次都進(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)無(wú)法找到會(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)容語(yǔ)言（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 過(guò)期（Expires）

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

過(guò)期了的緩存入口可能不會(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)過(guò)期。

如需標(biāo)記一個(gè)回復(fù)為已過(guò)期（“already expired”），一個(gè)原始服務(wù)器必須使用與Date頭中相同的過(guò)期值。如需標(biāo)記一個(gè)回復(fù)為永不過(guò)期，原始服務(wù)器應(yīng)使用回復(fù)發(fā)送時(shí)間加上一年作為過(guò)期時(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)描述的完整性特別有用，如通過(guò)RTSP以外方式獲取呈現(xiàn)描述，或服務(wù)器實(shí)現(xiàn)中用于確保DESCRIBE消息和SETUP消息間描述的完整性。

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

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ì)返回一條無(wú)任何消息主體"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的范圍說(shuō)明一個(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ì)象中選擇片段，然后正常播放出來(lái)。播放的起始點(diǎn)可以試試未來(lái)的任一位置，盡管有些服務(wù)器會(huì)拒絕長(zhǎng)時(shí)間保持資源。

12.30 Referer

見[H14.37] URL指向呈現(xiàn)描述，通?？赏ㄟ^(guò)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)系并不通過(guò)RTSP交換進(jìn)行溝通，因?yàn)檫@種關(guān)系本來(lái)就是“funky-feature”的恒定屬性，因此無(wú)需溝通。

代理及其他中介設(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í)間戳，客戶端使用該值來(lái)完成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í)間戳的映射表可以通過(guò)RTCP獲得，但該信息對(duì)于映射并沒有多少助力。更進(jìn)一步地說(shuō)，為了確保該信息在某些時(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.

語(yǔ)法：
    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(wú)法改變，因此scale實(shí)現(xiàn)方式依賴具體服務(wù)器和媒體類型，對(duì)于視頻，服務(wù)器可能通過(guò)只傳送關(guān)鍵幀甚至預(yù)選了的關(guān)鍵幀來(lái)達(dá)到目的，而對(duì)于音頻，服務(wù)器可能會(huì)在保持音調(diào)的基礎(chǔ)上按時(shí)間縮放音頻甚至別無(wú)選擇地傳送音頻分片。

服務(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í)無(wú)效的。如請(qǐng)求中包含Range參數(shù)，新的速度值將在對(duì)應(yīng)時(shí)刻生效。

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

使用該域會(huì)影響數(shù)據(jù)傳輸?shù)膸?，它是特定環(huán)境下以更高或更低預(yù)覽呈現(xiàn)的一種調(diào)整方式。實(shí)現(xiàn)者應(yīng)記住會(huì)話的帶寬可能會(huì)預(yù)先商定（通過(guò)RTSP以外的方式），因此重新協(xié)商是可能有必要的。當(dāng)數(shù)據(jù)通過(guò)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ù)器使用它來(lái)告知客戶端其多久不活動(dòng)（發(fā)送RTSP命令）后會(huì)話將會(huì)被關(guān)閉。timeout以秒為單位，默認(rèn)值為60s（1分鐘）。

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

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

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

12.38 Timestamp

Timestamp描述了客戶端何時(shí)發(fā)送請(qǐng)求給服務(wù)器。該值僅對(duì)客戶端有意義，可能使用任意時(shí)間格式。服務(wù)器必須返回完全相同的時(shí)間，并且如有可能，附上接收到處理完成進(jìn)行回復(fù)所經(jīng)過(guò)的整體時(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）以說(shuō)明能力范圍

  • 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)過(guò)服務(wù)器選擇的地址。這在RTSP命令通過(guò)UDP發(fā)送時(shí)尤為重要，但實(shí)現(xiàn)也不能依賴TCP作為客戶端識(shí)別的有效方式。一個(gè)服務(wù)器不應(yīng)該允許客戶端傳送媒體流至一個(gè)與命令來(lái)源不同過(guò)得地址。

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

  • 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提供了語(yǔ)句中將要使用到的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ù)器不支持的特性，在前述通過(guò)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)行緩存的，除非是通過(guò)DESCRIBE或ANNOUNCE方法返回呈現(xiàn)描述（因?yàn)镈ESCRIBE和GET_PARAMETER并不返回任何數(shù)據(jù)，因此緩存回復(fù)對(duì)請(qǐng)求沒有影響）。而且，對(duì)于連續(xù)媒體數(shù)據(jù)、會(huì)話描述，特別是RTSP中通過(guò)帶外傳輸，都建議被緩存。

在接收到SETUP或PLAY請(qǐng)求后，代理檢查其是否有一個(gè)連續(xù)媒體內(nèi)容及其描述的最新副本。它可以通過(guò)SETUP或DESCRIBE請(qǐng)求來(lái)確定副本是否最新。如果不是最新，則將SETUP傳輸參數(shù)修改合適并將請(qǐng)求遞送給原始服務(wù)器。后續(xù)控制命令如PLAY或PAUSE則繼續(xù)傳送未經(jīng)代理修改過(guò)的版本。代理在傳輸連續(xù)媒體數(shù)據(jù)給客戶端的同時(shí)，如有可能應(yīng)制作副本方便后續(xù)使用。允許魂村的確切操作是通過(guò)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)過(guò)其流向客戶端的流數(shù)據(jù)。也就是說(shuō)，它并不會(huì)引入額外延時(shí)。

對(duì)于客戶端而言，RTSP代理緩存就像一個(gè)正常媒體服務(wù)器，對(duì)于服務(wù)器而言，又像一個(gè)客戶端。正如HTTP緩存需為其緩存的對(duì)象存儲(chǔ)內(nèi)容類型、內(nèi)容語(yǔ)言等等，媒體緩存也需要存儲(chǔ)呈現(xiàn)描述。典型的有，緩存消除了描述呈現(xiàn)中的所有傳輸應(yīng)用（如，多播信息），由于這些獨(dú)立的數(shù)據(jù)從緩存?zhèn)魉偷娇蛻舳?。編碼信息仍保持原狀，如果緩存要能夠轉(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é)議棧以及如語(yǔ)言、版權(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

即使音視頻軌可能來(lái)自不同的服務(wù)器，甚至有不同的起始時(shí)間，客戶端都能夠通過(guò)標(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)，通過(guò)一條簡(jiǎn)單的作用于聚合URL的控制消息來(lái)控制所有流也是比較合適的。

下面給出了一個(gè)使用RTSP會(huì)話來(lái)控制多個(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方法來(lái)想服務(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 語(yǔ)法（Syntax）

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

15.1 基礎(chǔ)語(yǔ)法（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ù)器語(yǔ)法上類似，因此主要安全須知已在[H15]中列出。其他需要注意的如下： 、

  • 認(rèn)證機(jī)制（Authentication Mechanisms）
    RTSP和HTTP共享通用認(rèn)證方案，因此也必須遵循相同的認(rèn)證描述方式?？蛻舳苏J(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）
    沒有理由可以相信通過(guò)RTSP傳輸信息會(huì)比直接通過(guò)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ǔ)義摻入，但預(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)隱私問(wè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ǔ)上，未來(lái)HTTP可能會(huì)提供對(duì)安全問(wèn)題提供額外的保障。

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

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

  • 會(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ī)而且無(wú)序的會(huì)話標(biāo)識(shí)符來(lái)盡可能減小此種攻擊的可能性。

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

  • 流問(wèn)題（Stream issues）
    RTSP只提供流控制部分，流傳輸?shù)膯?wèn)題并不包含在本文內(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)求。

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容