RTSP協(xié)議分析-3

jonry

10 方法定義
方法表征（method token）表示了對請求統(tǒng)一資源標(biāo)志符（Request-URI）識別的資源所執(zhí)行的操作。方法名區(qū)分大小寫。將來可能定義新的方法。方法名可能不以美元符'＄'（十進(jìn)制數(shù)24）開頭，但必須具有表征意義(must be a token)。
表格2是對方法的一個小結(jié)。
method direction object requirement
------------------------------------------------------------------
DESCRIBE C -> S P,S recommended
ANNOUNCE C -> S,S ->C P,S optional
GET PARAMETER C -> S,S ->C P,S optional
OPTIONS C -> S,S ->C P,S required(S ! C: optional)
PAUSE C -> S P,S recommended
PLAY C -> S P,S required
RECORD C -> S P,S optional
REDIRECT S ->C P,S optional
SETUP C -> S S required
SET PARAMETER C -> S,S ->C P,S optional
TEARDOWN C -> S P,S required
表2：對RTSP方法，和其操作方向及所操作對象（P: 表示, S: 媒體流）的一個概覽
注意：PAUSE方法是推薦的, 但在構(gòu)建一個全功能的服務(wù)器（fully functional
server）時可能不支持此方法，這時就不需要它，比如對于live feeds。如果服務(wù)器不支持某個特殊方法，它必將返回"501 Not
Implemented"，并且客戶端應(yīng)該不再向該服務(wù)器請求該方法。
（注：Presentation是一個以完整的media feed呈現(xiàn)給client的一個或多個媒體流的集合，暫且翻譯成表示）
10.1 OPTIONS
其行為與[H9.2]中描述的等同。OPTIONS請求可能在任何時候發(fā)出，例如客戶端將要發(fā)出一個非標(biāo)準(zhǔn)的請求時。它不影響服務(wù)器狀態(tài)。
示例：
C->S: OPTIONS * RTSP/1.0
CSeq: 1
Require: implicit-play
Proxy-Require: gzipped-messages
S->C: RTSP/1.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
注意：這些都是必要的構(gòu)造特征（necessarily fictional features）。 (你可能不希望我們?nèi)ビ幸夂雎阅切�實際上有用的特征，因此在這一部分中我們將給出一個詳細(xì)的例子)。
10.2 DESCRIBE
DESCRIBE方法從服務(wù)器檢索表示的描述或媒體對象，這些資源通過請求統(tǒng)一資源定位符（the request
URL）識別。此方法可能結(jié)合使用Accept首部域來指定客戶端理解的描述格式。服務(wù)器端用被請求資源的描述對客戶端作出響應(yīng)。DESCRIBE的答復(fù)
-響應(yīng)對（reply-response pair）組成了RTSP的媒體初始化階段。
示例：
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl, application/mheg
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 376
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
a=orient:portrait
DESCRIBE響應(yīng)必須包含它所描述資源的所有媒體初始化信息。如果媒體客戶端從一個數(shù)據(jù)源獲得表示描述，而非通過DESCRIBE，并且該描述包含了一個媒體初始化參數(shù)的全集，那么客戶端就應(yīng)該使用這些參數(shù)，而不是再通過RTSP請求相同媒體的描述。
再有，服務(wù)器不應(yīng)該（SHOULD NOT）使用DESCRIBE響應(yīng)作為media indirection的方法。
需要建立基本的規(guī)則，使得客戶端有明確的方法了解何時通過DESCRIBE請求媒體初始化信息，何時不請求。強(qiáng)制DESCRIBE響應(yīng)包含它所描述媒體流
集合的所有初始化信息，不鼓勵將DESCRIBE用作media
indirection的方法，通過這兩點避免了使用其他方法可能會引起的循環(huán)問題（looping problems）。
媒體初始化是任何基于RTSP系統(tǒng)的必要條件，但RTSP規(guī)范并沒有規(guī)定它必須通過DESCRIBE方法完成。RTSP客戶端可以通過3種方法來接收媒體初始化信息：
. DESCRIBE方法；
.其它一些協(xié)議（HTTP，email附件，等）；
.命令行或標(biāo)準(zhǔn)輸入（同一個SDP或其它媒體初始化格式的文件一起啟動，工作方式類似于瀏覽器的幫助程序）。
為了實際協(xié)同工作，嚴(yán)重（）推薦最精簡的服務(wù)器也支持DESCRIBE方法，最精簡的客戶端也支持從標(biāo)準(zhǔn)輸入，命令行和/或其它對于客戶端操作環(huán)境合適的方法來接收媒體初始化文件的能力。
10.3 ANNOUNCE
ANNOUNCE方法有兩個用途：
當(dāng)客戶端向服務(wù)器發(fā)送時，ANNOUNCE將通過請求URL識別的表示描述或者媒體對象提交給服務(wù)器；
當(dāng)服務(wù)器向客戶端發(fā)送時，ANNOUNCE實時更新會話描述。
如果有新的媒體流加到表示中（比如在一個現(xiàn)場表示中），整個表示描述應(yīng)該重發(fā)；而不只是增加組件，如果這樣做的話，組件也可以被刪除了。
示例：
C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Content-Type: application/sdp
Content-Length: 332
v=0
o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
S->C: RTSP/1.0 200 OK
CSeq: 312
10.4 SETUP
SETUP請求為URI指定流式媒體的傳輸機(jī)制�？蛻舳四軌虬l(fā)出一個SETUP請求為正在播放的媒體流改變傳輸參數(shù)，服務(wù)器可能同意這些參數(shù)的改變。若是
不同意，它必須響應(yīng)錯誤"455 Method Not Valid In This State"。
為了盡量繞開防火墻干涉，即使它不會影響參數(shù)，客戶端也必須指出傳輸參數(shù)，例如，指出服務(wù)器向外發(fā)布的固定的廣播地址。
由于SETUP包括了所有傳輸初始化信息，防火墻和其他中間的網(wǎng)絡(luò)設(shè)備（它們需要這些信息）分讓了解析DESCRIBE響應(yīng)的繁瑣任務(wù)，這些任務(wù)留給了媒體初始化。
Transport首部域指定了客戶端數(shù)據(jù)傳輸時可接受的傳輸參數(shù)；響應(yīng)包含了由服務(wù)器選出的傳輸參數(shù)。
C->S: SETUP
rtsp://example.com/foo/bar/baz.rm
RTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589
S->C: RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Transport: RTP/AVP;unicast;
client_port=4588-4589;server_port=6256-6257
作為對SETUP請求的響應(yīng)，服務(wù)器產(chǎn)生了會話標(biāo)志符。如果對服務(wù)器的請求中包含了會話標(biāo)志符，服務(wù)器必須將此setup請求捆綁到一個存在的會話，或者返回"459 Aggregate Operation Not Allowed"。
10.5 PLAY
PLAY方法告知服務(wù)器通過SETUP中指定的機(jī)制開始發(fā)送數(shù)據(jù)
。在尚未收到SETUP請求的成功應(yīng)答之前，客戶端不可以發(fā)出PLAY請求。PLAY請求將正常播放時間（normal play
time）定位到指定范圍的起始處，并且傳輸數(shù)據(jù)流直到播放范圍結(jié)束。PLAY請求可能被管道化（pipelined），即放入隊列中（queued）；
服務(wù)器必須將PLAY請求放到隊列中有序執(zhí)行。也就是說，后一個PLAY請求需要等待前一個PLAY請求完成才能得到執(zhí)行。
比如，在下例中，不管到達(dá)的兩個PLAY請求之間有多緊湊，服務(wù)器首先play第10到15秒，然后立即第20到25秒，最后是第30秒直到結(jié)束。
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 835
Session: 12345678
Range: npt=10-15
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 836
Session: 12345678
Range: npt=20-25
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 837
Session: 12345678
Range: npt=30-
結(jié)合PAUSE請求的描述，看更深一層的示例。
不含Range首部域的PLAY請求也是合法的。它從媒體流開頭開始播放，直到媒體流被暫停。如果媒體流通過PAUSE暫停，媒體流傳輸將在暫停點（the pause point）重新開始。
如果媒體流正在播放，那么這樣一個PLAY請求將不起更多的作用，只是客戶端可以用此來測試服務(wù)器是否存活。
Range首部域可能包含一個時間參數(shù)。該參數(shù)以UTC格式指定了播放（palayback）開始的時間。如果在這個指定時間后收到消息，那么播放立即開始。時間參數(shù)可能用來幫助同步從不同數(shù)據(jù)源獲取的數(shù)據(jù)流。
對于一個點播（On-demand）媒體流，服務(wù)器用播放（play back）的實際范圍答復(fù)請求。This may differ from
the requested range if alignment of the requested range to valid frame
boundaries is required for the media
source.如果在請求中沒有指定范圍，當(dāng)前位置將在答復(fù)中返回。答復(fù)中播放范圍的單位與請求中相同。在播放完被要求的范圍后，表示將自動暫停，就好像
發(fā)出了一個PAUSE請求。
下面的示例在play整個表示時從SMPTE時間0:10:20直到剪輯（clip）結(jié)束。播放開始于1997年1月23號，15點36分
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0
CSeq: 833
Session: 12345678
Range: smpte=0:10:20-;time=19970123T153600Z
S->C: RTSP/1.0 200 OK
CSeq: 833
Date: 23 Jan 1997 15:35:06 GMT
Range: smpte=0:10:22-;time=19970123T153600Z
For playing back a recording of a live presentation, it may be desirable to use clock units:
C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0
CSeq: 835
Session: 12345678
Range: clock=19961108T142300Z-19961108T143520Z
S->C: RTSP/1.0 200 OK
CSeq: 835
Date: 23 Jan 1997 15:35:06 GMT
只有播放的媒體服務(wù)器必須支持npt時間格式，可能支持clock和smpte格式。
10.6 PAUSE
PAUSE請求引起媒體流傳輸?shù)臅簳r中斷。如果請求URL中指定了具體的媒體流，那么只有該媒體流的播放和記錄被暫停（halt）。比如，指定暫停音頻，
播放將會無聲。如果請求URL指定了一個表示或者媒體流已成組，那么在該表示或組中的所有當(dāng)前活動流的傳輸將被暫停。在重啟播放或記錄后，必須維護(hù)不同媒
體軌跡（track）的同步。盡管服務(wù)器可能在暫停后，在timeout的時間內(nèi)關(guān)閉會話，釋放資源，但是任何資源都必須保存，其中timeout參數(shù)位
于SETUP消息的會話頭中。
示例：
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 834
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT
PAUSE請求中可能包含一個Range首部域用來指定何時媒體流或表示暫停，我們稱這個時刻為暫停點（pause
point）。該首部域必須包含一個精確的值，而不是一個時間范圍。媒體流的正常播放時間設(shè)置成暫停點。當(dāng)服務(wù)器遇到在任何當(dāng)前掛起（pending）的
PLAY請求中指定的時間點后，暫停請求生效。如果Range首部域指定了一個時間超出了任何一個當(dāng)前掛起的PLAY請求，將返回錯誤"457
Invalid Range"
。如果一個媒體單元（比如一個音頻或視頻禎）正好在一個暫停點開始，那么表示將不會被播放或記錄。如果Range首部域缺失，那么在收到暫停消息后媒體流
傳輸立即中斷，并且暫停點設(shè)置成當(dāng)前正常播放時間。
利用PAUSE請求可忽視所有排隊的PLAY請求，但必須維護(hù)媒體流中的暫停點。不帶Range首部域的后繼PLAY請求從暫停點重啟播放。
比如，如果服務(wù)器有兩個掛起的播放請求，播放范圍（range）分別是10到15和20到29，這時收到一個暫停請求，暫停點是NPT21，那么它將會開
始播放第二個范圍，并且在NPT21處停止。如果服務(wù)器正在服務(wù)第一個請求播放到NPT13位置，收到暫停請求，暫停點NPT12，那么它將立即停止。如
果請求在NPT16暫停，那么服務(wù)器在完成第一個播放請求后停止，放棄了第二個播放請求。
再如，服務(wù)器收到播放請求，播放范圍從10到15和13到20（即之間有重疊），PAUSE暫停點是NPT14，則當(dāng)服務(wù)器播放第一段范圍時，PAUSE
請求將生效，而第二個PLAY請求會被忽略重疊部分，就好像服務(wù)器在開始播放第二段前收到PAUSE請求。不管PAUSE請求何時到達(dá)，它總是設(shè)置NPT
到14。//？
如果服務(wù)器已經(jīng)在Range首部域指定的時間外發(fā)送了數(shù)據(jù)，后繼的PLAY仍會在暫停點及時重啟，因為它認(rèn)為客戶端會丟棄在暫停點后收到的數(shù)據(jù)。這就確保了連續(xù)、無隙的暫停/播放循環(huán)。
10.7 TEARDOWN
TEARDOWN請求終止了給定URI的媒體流傳輸，并釋放了與該媒體流相關(guān)的資源。如果該URI是對此表示的表示URI，那么任何與此會話相關(guān)的任何RTSP會話標(biāo)志符將不再有效。除非所有傳輸參數(shù)由會話描述符定義，否則SETUP請求必須在會話能被再次播放之前發(fā)出。
示例：
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 892
10.8 GET PARAMETER
GET PARAMETER請求檢索URI指定的表示或媒體流的參數(shù)值。答復(fù)和響應(yīng)的內(nèi)容留給了實現(xiàn)。不帶實體主體的GET PARAMETER可用來測試客戶端或服務(wù)器是否存活（"Ping"）。
示例：
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 431
Content-Type: text/parameters
Session: 12345678
Content-Length: 15
packets_received
jitter
C->S: RTSP/1.0 200 OK
CSeq: 431
Content-Length: 46
Content-Type: text/parameters
packets_received: 10
jitter: 0.3838
"text/parameters"段只是參數(shù)類型的一個例子。對此方法有意的進(jìn)行了松散的定義，對于答復(fù)和響應(yīng)的內(nèi)容將在更深一層的實驗中給出定義。
10.9 SET PARAMETER
此方法給URI指定的表示或媒體流設(shè)置參數(shù)值。
幫助客戶端檢查某個特殊的請求為何失敗的請求（暈~）應(yīng)該只附帶一個參數(shù)。當(dāng)請求附帶多個參數(shù)時，服務(wù)器只有在這些參數(shù)全都設(shè)置正確時才作出響應(yīng)。服務(wù)器必須允許某個參數(shù)被重復(fù)設(shè)置成相同的值，但可能不允許改變參數(shù)值。
注意：必須只能使用SETUP命令來給媒體流設(shè)置傳輸參數(shù)。
限制只有SETUP能設(shè)置傳輸參數(shù)有利于防火墻設(shè)計。
示例：
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 421
Content-length: 20
Content-type: text/parameters
barparam: barstuff
S->C: RTSP/1.0 451 Invalid Parameter
CSeq: 421
Content-length: 10
Content-type: text/parameters
barparam
"text/parameters"段只是參數(shù)類型的一個例子。對此方法有意的進(jìn)行了松散的定義，對于答復(fù)和響應(yīng)的內(nèi)容將在更深一層的實驗中給出定義。
10.10 REDIRECT
REDIRECT請求告知客戶端連接到另一個服務(wù)器位置。它包含首部域Location，該域指出了客戶端應(yīng)該發(fā)出請求的URL。它可能包含參數(shù)
Range，在重定向生效時，該域指明了媒體流的范圍。如果客戶端希望繼續(xù)發(fā)送或接收其URI指定的媒體，它必須發(fā)出一個TEARDOWN請求來關(guān)閉當(dāng)前
會話，并向委派的主機(jī)發(fā)送SETUP以建立新的會話。
本例中，在給定的播放時間將URI請求重定向到新的服務(wù)器：
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 732
Location: rtsp://bigserver.com:8001
Range: clock=19960213T143205Z-
10.11 RECORD
此方法根據(jù)表示描述開始記錄媒體數(shù)據(jù)。時間戳（timestamp）表現(xiàn)了起始和結(jié)束時間（UTC）。如果沒有給定時間范圍，就使用表示描述中提供的開始
和結(jié)束時間。如果會話已經(jīng)開啟，立即開始記錄。由服務(wù)器來決定是否存儲記錄的數(shù)據(jù)到請求URI下或者其它URI下。如果服務(wù)器沒有使用請求URI，那么響
應(yīng)代碼應(yīng)該是201（創(chuàng)建），并且包含一個實體，該實體描述了請求的狀態(tài)，并通過Location首部域指向新資源。
允許記錄現(xiàn)場表示（live presentations）的媒體服務(wù)器必須支持時鐘范圍格式（the clock range format），smpte格式對此無用。
在本示例中，媒體服務(wù)器被邀請到指定的會議
C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0
CSeq: 954
Session: 12345678
Conference: 128.16.64.19/32492374
10.12 Embedded (Interleaved) Binary Data
可能某些防火墻設(shè)計和環(huán)境會強(qiáng)制服務(wù)器交叉RTSP方法和媒體流數(shù)據(jù)。這種交叉增加了客戶端和服務(wù)器操作的復(fù)雜性，帶來了額外的開銷，因此通常情況下應(yīng)該避免；除非必須交叉。只有RTSP在TCP上運(yùn)載時，交叉的二進(jìn)制數(shù)據(jù)才能使用。
媒體流數(shù)據(jù)，如RTP包，被封裝成下列形式：ASCII的美元符（十進(jìn)制數(shù)24），一個字節(jié)的通道標(biāo)志符（channel
identifier），被封裝的二進(jìn)制數(shù)據(jù)的長度，以網(wǎng)絡(luò)字節(jié)順序編碼的2字節(jié)整數(shù)。緊接著的是上層的協(xié)議頭。每個＄塊都正確地包含了一個上層協(xié)議數(shù)據(jù)
單元，比如一個RTP包。
通道標(biāo)志符使用交叉參數(shù)定義在傳輸頭。
當(dāng)使用實時傳輸協(xié)議傳輸時，RTP和RTCP消息也會在TCP連接上相互交叉。默認(rèn)情況下，RTCP包會在第一個可用的通道上發(fā)送，高于RTP通道。而客戶端可能在另一個通道顯式地請求RTCP包。在傳輸頭的交叉參數(shù)中指定兩個通道可解決此問題。
C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0
CSeq: 2
Transport: RTP/AVP/TCP;interleaved=0-1
S->C: RTSP/1.0 200 OK
CSeq: 2
Date: 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;interleaved=0-1
Session: 12345678
C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0
CSeq: 3
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 3
Session: 12345678
Date: 05 Jun 1997 18:59:15 GMT
RTP-Info: url=rtsp://foo.com/bar.file;
seq=232433;rtptime=972948234
S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\001{2 byte length}{"length" bytes RTCP packet}
               
               
               

本文來自ChinaUnix博客，如果查看原文請點：http://blog.chinaunix.net/u1/59592/showart_1192958.html