狗尾巴草的一畝三分地兒
阿新 • • 發佈：2019-01-04
第一部分:RTSP協議
一、RTSP協議概述
RTSP(Real-TimeStream Protocol )是一種基於文字的應用層協議，在語法及一些訊息引數等方面，RTSP協議與HTTP協議類似。
RTSP被用於建立的控制媒體流的傳輸，它為多媒體服務扮演“網路遠端控制”的角色。儘管有時可以把RTSP控制資訊和媒體資料流交織在一起傳送，但一般情況RTSP本身並不用於轉送媒體流資料。媒體資料的傳送可通過RTP/RTCP等協議來完成。
一次基本的RTSP操作過程是:首先，客戶端連線到流伺服器併發送一個RTSP描述命令（DESCRIBE）。流伺服器通過一個SDP描述來進行反饋，反饋資訊包括流數量、媒體型別等資訊。客戶端再分析該SDP描述，併為會話中的每一個流傳送一個RTSP建立命令(SETUP)，RTSP建立命令告訴伺服器客戶端用於接收媒體資料的埠。流媒體連線建立完成後，客戶端傳送一個播放命令(PLAY)，伺服器就開始在UDP上傳送媒體流（RTP包）到客戶端。 在播放過程中客戶端還可以向伺服器傳送命令來控制快進、快退和暫停等。最後，客戶端可傳送一個終止命令(TERADOWN)來結束流媒體會話
二、RTSP協議與HTTP協議區別
1. RTSP引入了幾種新的方法，比如DESCRIBE、PLAY、SETUP 等，並且有不同的協議識別符號，RTSP為rtsp 1.0,HTTP為http 1.1；
2. HTTP是無狀態的協議，而RTSP為每個會話保持狀態；
3. RTSP協議的客戶端和伺服器端都可以傳送Request請求，而在HTTPF協議中，只有客戶端能傳送Request請求。
4. 在RTSP協議中，載荷資料一般是通過帶外方式來傳送的(除了交織的情況)，及通過RTP協議在不同的通道中來傳送載荷資料。而HTTP協議的載荷資料都是通過帶內方式傳送的，比如請求的網頁資料是在迴應的訊息體中攜帶的。
5. 使用ISO10646(UTF-8) 而不是ISO 8859-1，以配合當前HTML的國際化；
6. RTSP使用URI請求時包含絕對URI。而由於歷史原因造成的向後相容性問題，HTTP/1.1只在請求中包含絕對路徑，把主機名放入單獨的標題域中；
三、RTSP重要術語
1. 集合控制(Aggregatecontrol ):
對多個流的同時控制。對音訊/視訊來講，客戶端僅需傳送一條播放或者暫停訊息就可同時控制音訊流和視訊流。
2. 實體(Entity)：
作為請求或者回應的有效負荷傳輸的資訊。由以實體標題域（entity-header field）形式存在的元資訊和以實體主體（entity body）形式存在的內容組成
3. 容器檔案（Containerfile）：
可以容納多個媒體流的檔案。RTSP伺服器可以為這些容器檔案提供集合控制。
4. RTSP會話(RTSP session )：
RTSP互動的全過程。對一個電影的觀看過程,會話(session)包括由客戶端建立媒體流傳輸機制(SETUP)，使用播放(PLAY)或錄製(RECORD)開始傳送流，用停止(TEARDOWN)關閉流。
四、RTSP請求訊息
1. 訊息格式：
方法 URI RTSP版本 CR LF
訊息頭 CRLF CRLF
訊息體 CR LF
其中方法包括OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等,URI是接受方的地址,例如:rtsp://192.168.0.1/video1.3gp。
RTSP版本一般都是 RTSP/1.0。每行後面的CR LF表示回車換行，需要接受端有相應的解析，最後一個訊息頭需要有兩個CR LF
訊息體是可選的，有的Request訊息並不帶訊息體。
五、RTSP迴應訊息
1. 訊息格式：
RTSP版本狀態碼解釋 CR LF
訊息頭 CR LF CR LF
訊息體 CR LF
其中RTSP版本一般都是RTSP/1.0,狀態碼是一個數值，用於表示Request訊息的執行結果,比如200表示成功,解釋是與狀態碼對應的文字解釋.
六、RTSP 重要方法
1. OPTIONS:
用於得到伺服器提供的可用方法；
如:
OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 1
伺服器的迴應資訊會在Public欄位列出提供的方法。如:
RTSP/1.0 200 OK
CSeq: 1 //每個迴應訊息的cseq數值和請求訊息的cseq相對應
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
2. DESCRIBE：
客戶端向伺服器端傳送DESCRIBE，用於得到URI所指定的媒體描述資訊，一般是SDP資訊。客戶端通過Accept頭指定客戶端可以接受的媒體述資訊型別。
如：
C->S: DESCRIBE rtsp://server.example.com/fizzle/fooRTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl,application/mheg)
伺服器迴應URI指定媒體的描述資訊:
如:
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp //表示迴應為SDP資訊
Content-Length: 376
//這裡為一個空行
//以下為具體的SDP資訊
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
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
媒體初始化是任何基於RTSP系統的必要條件，但RTSP規範並沒有規定它必須通過DESCRIBE方法完成。RTSP客戶端可以通過以下方法來接收媒體描述資訊：
a) 通過DESCRIBE方法；
b) 其它一些協議（HTTP，email附件，等）；
c) 通過命令列或標準輸入裝置
3. SETUP：
用於確定轉輸機制，建立RTSP會話。客戶端能夠發出一個SETUP請求為正在播放的媒體流改變傳輸引數，伺服器可能同意這些引數的改變。若是不同意，它必須響應錯誤"455 Method Not Valid In This State"。
Request中的Transport頭欄位指定了客戶端可接受的資料傳輸引數；Response中的Transport 頭欄位包含了由伺服器選出的傳輸引數。
如:
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589
伺服器端對SETUPRequest產生一個Session Identifiers。
如:
S->C: RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344 //產生一個SessionID
Transport: RTP/AVP;unicast;
client_port=4588-4589;server_port=6256-6257
4. PLAY：
PLAY方法告知伺服器通過SETUP中指定的機制開始傳送資料 。在尚未收到SETUP請求的成功應答之前，客戶端不可以發出PLAY請求。
PLAY請求將正常播放時間（normal play time）定位到指定範圍的起始處，並且傳輸資料流直到播放範圍結束。PLAY請求可能被管道化（pipelined），即放入佇列中（queued）；伺服器必須將PLAY請求放到佇列中有序執行。也就是說，後一個PLAY請求需要等待前一個PLAY請求完成才能得到執行。
比如，在下例中，不管到達的兩個PLAY請求之間有多緊湊，伺服器首先play第10到15秒，然後立即第20到25秒，最後是第30秒直到結束。
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-
Range頭可能包含一個時間引數。該引數以UTC格式指定了播放開始的時間。如果在這個指定時間後收到訊息，那麼播放立即開始。時間引數可能用來幫助同步從不同資料來源獲取的資料流。
不含Range頭的PLAY請求也是合法的。它從媒體流開頭開始播放，直到媒體流被暫停。如果媒體流通過PAUSE暫停，媒體流傳輸將在暫停點（the pause point）重新開始。
如果媒體流正在播放，那麼這樣一個PLAY請求將不起更多的作用，只是客戶端可以用此來測試伺服器是否存活。
5. PAUSE：
PAUSE請求引起媒體流傳輸的暫時中斷。如果請求URL中指定了具體的媒體流，那麼只有該媒體流的播放和記錄被暫停（halt）。比如，指定暫停音訊，播放將會無聲。如果請求URL指定了一組流，那麼在該組中的所有流的傳輸將被暫停。如：
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）。該頭必須包含一個精確的值，而不是一個時間範圍。媒體流的正常播放時間設定成暫停點。當伺服器遇到在任何當前掛起（pending）的PLAY請求中指定的時間點後，暫停請求生效。如果Range頭指定了一個時間超出了任何一個當前掛起的PLAY請求，將返回錯誤"457 Invalid Range" 。如果一個媒體單元（比如一個音訊或視訊禎）正好在一個暫停點開始，那麼表示將不會被播放或記錄。如果Range頭缺失，那麼在收到暫停訊息後媒體流傳輸立即中斷，並且暫停點設定成當前正常播放時間。
6. TEARDOWN：
TEARDOWN請求終止了給定URI的媒體流傳輸，並釋放了與該媒體流相關的資源。如：
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 892
七、RTSP重要頭欄位引數
1. Accept:
用於指定客戶端可以接受的媒體描述資訊型別。比如:
Accept: application/rtsl, application/sdp;level=2
2. Bandwidth:
用於描述客戶端可用的頻寬值。
3. CSeq：
指定了RTSP請求迴應對的序列號，在每個請求或迴應中都必須包括這個頭欄位。對每個包含一個給定序列號的請求訊息，都會有一個相同序列號的迴應訊息。
4. Rang：
用於指定一個時間範圍，可以使用SMPTE、NTP或clock時間單元。
5. Session:
Session頭欄位標識了一個RTSP會話。Session ID 是由伺服器在SETUP的迴應中選擇的，客戶端一當得到Session ID後，在以後的對Session 的操作請求訊息中都要包含Session ID.
6. Transport:
Transport頭欄位包含客戶端可以接受的轉輸選項列表，包括傳輸協議，地址埠，TTL等。伺服器端也通過這個頭欄位返回實際選擇的具體選項。如:
Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",
RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"
八、簡單的RTSP訊息互動過程
C表示RTSP客戶端,S表示RTSP服務端
1. 第一步：查詢伺服器端可用方法
1.C->S:OPTIONrequest //詢問S有哪些方法可用
1.S->C:OPTIONresponse //S迴應資訊的public頭欄位中包括提供的所有可用方法
2. 第二步：得到媒體描述資訊
2.C->S:DESCRIBE request //要求得到S提供的媒體描述資訊
2.S->C:DESCRIBE response //S迴應媒體描述資訊，一般是sdp資訊
3. 第三步：建立RTSP會話
3.C->S:SETUPrequest //通過Transport頭欄位列出可接受的傳輸選項，請求S建立會話
3.S->C:SETUPresponse //S建立會話，通過Transport頭欄位返回選擇的具體轉輸選項，並返回建立的Session ID;
4. 第四步：請求開始傳送資料
4.C->S:PLAY request //C請求S開始傳送資料
4.S->C:PLAYresponse //S迴應該請求的資訊
5. 第五步： 資料傳送播放中
S->C:傳送流媒體資料 // 通過RTP協議傳送資料
6. 第六步：關閉會話，退出
6.C->S:TEARDOWN request //C請求關閉會話
6.S->C:TEARDOWN response //S迴應該請求
上述的過程只是標準的、友好的rtsp流程，但實際的需求中並不一定按此過程。
其中第三和第四步是必需的！第一步，只要伺服器客戶端約定好，有哪些方法可用，則option請求可以不要。第二步，如果我們有其他途徑得到媒體初始化描述資訊（比如http請求等等），則我們也不需要通過rtsp中的describe請求來完成。
第二部分:SDP協議
一、SDP協議概述
SDP(SessionDescription Protocol )會話描述協議，用於描述多媒體會話，它為會話通知、會話初始和其它形式的多媒體會話初始等操作提供服務。
SDP的設計宗旨是通用性協議，所有它可以應用於很大範圍的網路環境和應用程式，但 SDP 不支援會話內容或媒體編碼的協商操作。
SDP資訊包括：
會話名稱和目標；
會話活動時間；
構成會話的媒體；
有關接收媒體的資訊、地址等。
二、SDP格式
SDP 資訊是文字資訊，UTF-8 編碼採用 ISO 10646 字元設定。SDP 會話描述如下（標註*符號的表示可選欄位）：
v= （協議版本）
o= （所有者/建立者和會話識別符號）
s= （會話名稱）
i=* （會話資訊）
u=* （URI 描述）
e=* （Email 地址）
p=* （電話號碼）
c=* （連線資訊 ― 如果包含在所有媒體中，則不需要該欄位）
b=* （頻寬資訊）
一個或更多時間描述（如下所示）：
z=* （時間區域調整）
k=* （加密金鑰）
a=* （0個或多個會話屬性線路）
0個或多個媒體描述（如下所示）
時間描述
t= （會話活動時間）
r=* （0或多次重複次數）
媒體描述
m= （媒體名稱和傳輸地址）
i=* （媒體標題）
c=* （連線資訊 — 如果包含在會話層則該欄位可選）
b=* （頻寬資訊）
k=* （加密金鑰）
a=* （0個或多個會話屬性線路）
三、SDP示例
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
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb
a=orient:portrait
//欄位解釋
V=0 ;Version 給定了SDP協議的版本
o=<username><session id> <version> <network type> <address type>
<address>； Origin ,給定了會話的發起者資訊
s=<sessionname> ;給定了Session Name
i=<sessiondescription> ; Information 關於Session的一些資訊
u=<URI> ; URI
e=<emailaddress> ;Email
c=<networktype> <address type> <connection address> ;Connect Data包含連線資料
t=<start time><stop time> ;Time
a=<attribute> ; Attribute
a=<attribute>:<value>
一、RTSP協議概述
RTSP(Real-TimeStream Protocol )是一種基於文字的應用層協議，在語法及一些訊息引數等方面，RTSP協議與HTTP協議類似。
RTSP被用於建立的控制媒體流的傳輸，它為多媒體服務扮演“網路遠端控制”的角色。儘管有時可以把RTSP控制資訊和媒體資料流交織在一起傳送，但一般情況RTSP本身並不用於轉送媒體流資料。媒體資料的傳送可通過RTP/RTCP等協議來完成。
一次基本的RTSP操作過程是:首先，客戶端連線到流伺服器併發送一個RTSP描述命令（DESCRIBE）。流伺服器通過一個SDP描述來進行反饋，反饋資訊包括流數量、媒體型別等資訊。客戶端再分析該SDP描述，併為會話中的每一個流傳送一個RTSP建立命令(SETUP)，RTSP建立命令告訴伺服器客戶端用於接收媒體資料的埠。流媒體連線建立完成後，客戶端傳送一個播放命令(PLAY)，伺服器就開始在UDP上傳送媒體流（RTP包）到客戶端。 在播放過程中客戶端還可以向伺服器傳送命令來控制快進、快退和暫停等。最後，客戶端可傳送一個終止命令(TERADOWN)來結束流媒體會話
二、RTSP協議與HTTP協議區別
1. RTSP引入了幾種新的方法，比如DESCRIBE、PLAY、SETUP 等，並且有不同的協議識別符號，RTSP為rtsp 1.0,HTTP為http 1.1；
2. HTTP是無狀態的協議，而RTSP為每個會話保持狀態；
3. RTSP協議的客戶端和伺服器端都可以傳送Request請求，而在HTTPF協議中，只有客戶端能傳送Request請求。
4. 在RTSP協議中，載荷資料一般是通過帶外方式來傳送的(除了交織的情況)，及通過RTP協議在不同的通道中來傳送載荷資料。而HTTP協議的載荷資料都是通過帶內方式傳送的，比如請求的網頁資料是在迴應的訊息體中攜帶的。
5. 使用ISO10646(UTF-8) 而不是ISO 8859-1，以配合當前HTML的國際化；
6. RTSP使用URI請求時包含絕對URI。而由於歷史原因造成的向後相容性問題，HTTP/1.1只在請求中包含絕對路徑，把主機名放入單獨的標題域中；
三、RTSP重要術語
1. 集合控制(Aggregatecontrol ):
對多個流的同時控制。對音訊/視訊來講，客戶端僅需傳送一條播放或者暫停訊息就可同時控制音訊流和視訊流。
2. 實體(Entity)：
作為請求或者回應的有效負荷傳輸的資訊。由以實體標題域（entity-header field）形式存在的元資訊和以實體主體（entity body）形式存在的內容組成
3. 容器檔案（Containerfile）：
可以容納多個媒體流的檔案。RTSP伺服器可以為這些容器檔案提供集合控制。
4. RTSP會話(RTSP session )：
RTSP互動的全過程。對一個電影的觀看過程,會話(session)包括由客戶端建立媒體流傳輸機制(SETUP)，使用播放(PLAY)或錄製(RECORD)開始傳送流，用停止(TEARDOWN)關閉流。
四、RTSP請求訊息
1. 訊息格式：
方法 URI RTSP版本 CR LF
訊息頭 CRLF CRLF
訊息體 CR LF
其中方法包括OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等,URI是接受方的地址,例如:rtsp://192.168.0.1/video1.3gp。
RTSP版本一般都是 RTSP/1.0。每行後面的CR LF表示回車換行，需要接受端有相應的解析，最後一個訊息頭需要有兩個CR LF
訊息體是可選的，有的Request訊息並不帶訊息體。
五、RTSP迴應訊息
1. 訊息格式：
RTSP版本狀態碼解釋 CR LF
訊息頭 CR LF CR LF
訊息體 CR LF
其中RTSP版本一般都是RTSP/1.0,狀態碼是一個數值，用於表示Request訊息的執行結果,比如200表示成功,解釋是與狀態碼對應的文字解釋.
六、RTSP 重要方法
1. OPTIONS:
用於得到伺服器提供的可用方法；
如:
OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 1
伺服器的迴應資訊會在Public欄位列出提供的方法。如:
RTSP/1.0 200 OK
CSeq: 1 //每個迴應訊息的cseq數值和請求訊息的cseq相對應
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
2. DESCRIBE：
客戶端向伺服器端傳送DESCRIBE，用於得到URI所指定的媒體描述資訊，一般是SDP資訊。客戶端通過Accept頭指定客戶端可以接受的媒體述資訊型別。
如：
C->S: DESCRIBE rtsp://server.example.com/fizzle/fooRTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl,application/mheg)
伺服器迴應URI指定媒體的描述資訊:
如:
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp //表示迴應為SDP資訊
Content-Length: 376
//這裡為一個空行
//以下為具體的SDP資訊
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
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
媒體初始化是任何基於RTSP系統的必要條件，但RTSP規範並沒有規定它必須通過DESCRIBE方法完成。RTSP客戶端可以通過以下方法來接收媒體描述資訊：
a) 通過DESCRIBE方法；
b) 其它一些協議（HTTP，email附件，等）；
c) 通過命令列或標準輸入裝置
3. SETUP：
用於確定轉輸機制，建立RTSP會話。客戶端能夠發出一個SETUP請求為正在播放的媒體流改變傳輸引數，伺服器可能同意這些引數的改變。若是不同意，它必須響應錯誤"455 Method Not Valid In This State"。
Request中的Transport頭欄位指定了客戶端可接受的資料傳輸引數；Response中的Transport 頭欄位包含了由伺服器選出的傳輸引數。
如:
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589
伺服器端對SETUPRequest產生一個Session Identifiers。
如:
S->C: RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344 //產生一個SessionID
Transport: RTP/AVP;unicast;
client_port=4588-4589;server_port=6256-6257
4. PLAY：
PLAY方法告知伺服器通過SETUP中指定的機制開始傳送資料 。在尚未收到SETUP請求的成功應答之前，客戶端不可以發出PLAY請求。
PLAY請求將正常播放時間（normal play time）定位到指定範圍的起始處，並且傳輸資料流直到播放範圍結束。PLAY請求可能被管道化（pipelined），即放入佇列中（queued）；伺服器必須將PLAY請求放到佇列中有序執行。也就是說，後一個PLAY請求需要等待前一個PLAY請求完成才能得到執行。
比如，在下例中，不管到達的兩個PLAY請求之間有多緊湊，伺服器首先play第10到15秒，然後立即第20到25秒，最後是第30秒直到結束。
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-
Range頭可能包含一個時間引數。該引數以UTC格式指定了播放開始的時間。如果在這個指定時間後收到訊息，那麼播放立即開始。時間引數可能用來幫助同步從不同資料來源獲取的資料流。
不含Range頭的PLAY請求也是合法的。它從媒體流開頭開始播放，直到媒體流被暫停。如果媒體流通過PAUSE暫停，媒體流傳輸將在暫停點（the pause point）重新開始。
如果媒體流正在播放，那麼這樣一個PLAY請求將不起更多的作用，只是客戶端可以用此來測試伺服器是否存活。
5. PAUSE：
PAUSE請求引起媒體流傳輸的暫時中斷。如果請求URL中指定了具體的媒體流，那麼只有該媒體流的播放和記錄被暫停（halt）。比如，指定暫停音訊，播放將會無聲。如果請求URL指定了一組流，那麼在該組中的所有流的傳輸將被暫停。如：
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）。該頭必須包含一個精確的值，而不是一個時間範圍。媒體流的正常播放時間設定成暫停點。當伺服器遇到在任何當前掛起（pending）的PLAY請求中指定的時間點後，暫停請求生效。如果Range頭指定了一個時間超出了任何一個當前掛起的PLAY請求，將返回錯誤"457 Invalid Range" 。如果一個媒體單元（比如一個音訊或視訊禎）正好在一個暫停點開始，那麼表示將不會被播放或記錄。如果Range頭缺失，那麼在收到暫停訊息後媒體流傳輸立即中斷，並且暫停點設定成當前正常播放時間。
6. TEARDOWN：
TEARDOWN請求終止了給定URI的媒體流傳輸，並釋放了與該媒體流相關的資源。如：
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 892
七、RTSP重要頭欄位引數
1. Accept:
用於指定客戶端可以接受的媒體描述資訊型別。比如:
Accept: application/rtsl, application/sdp;level=2
2. Bandwidth:
用於描述客戶端可用的頻寬值。
3. CSeq：
指定了RTSP請求迴應對的序列號，在每個請求或迴應中都必須包括這個頭欄位。對每個包含一個給定序列號的請求訊息，都會有一個相同序列號的迴應訊息。
4. Rang：
用於指定一個時間範圍，可以使用SMPTE、NTP或clock時間單元。
5. Session:
Session頭欄位標識了一個RTSP會話。Session ID 是由伺服器在SETUP的迴應中選擇的，客戶端一當得到Session ID後，在以後的對Session 的操作請求訊息中都要包含Session ID.
6. Transport:
Transport頭欄位包含客戶端可以接受的轉輸選項列表，包括傳輸協議，地址埠，TTL等。伺服器端也通過這個頭欄位返回實際選擇的具體選項。如:
Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",
RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"
八、簡單的RTSP訊息互動過程
C表示RTSP客戶端,S表示RTSP服務端
1. 第一步：查詢伺服器端可用方法
1.C->S:OPTIONrequest //詢問S有哪些方法可用
1.S->C:OPTIONresponse //S迴應資訊的public頭欄位中包括提供的所有可用方法
2. 第二步：得到媒體描述資訊
2.C->S:DESCRIBE request //要求得到S提供的媒體描述資訊
2.S->C:DESCRIBE response //S迴應媒體描述資訊，一般是sdp資訊
3. 第三步：建立RTSP會話
3.C->S:SETUPrequest //通過Transport頭欄位列出可接受的傳輸選項，請求S建立會話
3.S->C:SETUPresponse //S建立會話，通過Transport頭欄位返回選擇的具體轉輸選項，並返回建立的Session ID;
4. 第四步：請求開始傳送資料
4.C->S:PLAY request //C請求S開始傳送資料
4.S->C:PLAYresponse //S迴應該請求的資訊
5. 第五步： 資料傳送播放中
S->C:傳送流媒體資料 // 通過RTP協議傳送資料
6. 第六步：關閉會話，退出
6.C->S:TEARDOWN request //C請求關閉會話
6.S->C:TEARDOWN response //S迴應該請求
上述的過程只是標準的、友好的rtsp流程，但實際的需求中並不一定按此過程。
其中第三和第四步是必需的！第一步，只要伺服器客戶端約定好，有哪些方法可用，則option請求可以不要。第二步，如果我們有其他途徑得到媒體初始化描述資訊（比如http請求等等），則我們也不需要通過rtsp中的describe請求來完成。
第二部分:SDP協議
一、SDP協議概述
SDP(SessionDescription Protocol )會話描述協議，用於描述多媒體會話，它為會話通知、會話初始和其它形式的多媒體會話初始等操作提供服務。
SDP的設計宗旨是通用性協議，所有它可以應用於很大範圍的網路環境和應用程式，但 SDP 不支援會話內容或媒體編碼的協商操作。
SDP資訊包括：
會話名稱和目標；
會話活動時間；
構成會話的媒體；
有關接收媒體的資訊、地址等。
二、SDP格式
SDP 資訊是文字資訊，UTF-8 編碼採用 ISO 10646 字元設定。SDP 會話描述如下（標註*符號的表示可選欄位）：
v= （協議版本）
o= （所有者/建立者和會話識別符號）
s= （會話名稱）
i=* （會話資訊）
u=* （URI 描述）
e=* （Email 地址）
p=* （電話號碼）
c=* （連線資訊 ― 如果包含在所有媒體中，則不需要該欄位）
b=* （頻寬資訊）
一個或更多時間描述（如下所示）：
z=* （時間區域調整）
k=* （加密金鑰）
a=* （0個或多個會話屬性線路）
0個或多個媒體描述（如下所示）
時間描述
t= （會話活動時間）
r=* （0或多次重複次數）
媒體描述
m= （媒體名稱和傳輸地址）
i=* （媒體標題）
c=* （連線資訊 — 如果包含在會話層則該欄位可選）
b=* （頻寬資訊）
k=* （加密金鑰）
a=* （0個或多個會話屬性線路）
三、SDP示例
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
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb
a=orient:portrait
//欄位解釋
V=0 ;Version 給定了SDP協議的版本
o=<username><session id> <version> <network type> <address type>
<address>； Origin ,給定了會話的發起者資訊
s=<sessionname> ;給定了Session Name
i=<sessiondescription> ; Information 關於Session的一些資訊
u=<URI> ; URI
e=<emailaddress> ;Email
c=<networktype> <address type> <connection address> ;Connect Data包含連線資料
t=<start time><stop time> ;Time
a=<attribute> ; Attribute
a=<attribute>:<value>
m=<media><port> <transport> <fmt list> ; MediaAnnouncements
Thanks 雷博