RTSP協定學習筆記

RTSP(Real-Time Stream Protocol )是一種基于文本的應用層協定，在文法及一些消息參數等方面，RTSP協定與HTTP協定類似。

RTSP被用于建立的控制媒體流的傳輸，它為多媒體服務扮演“網絡遠端控制”的角色。盡管有時可以把RTSP控制資訊和媒體資料流交織在一起傳送，但一般情況RTSP本身并不用于轉送媒體流資料。媒體資料的傳送可通過RTP/RTCP等協定來完成。

一次基本的RTSP操作過程是:首先，用戶端連接配接到流伺服器并發送一個RTSP描述指令（DESCRIBE）。流伺服器通過一個SDP描述來進行回報，回報資訊包括流數量、媒體類型等資訊。用戶端再分析該SDP描述，并為會話中的每一個流發送一個RTSP建立指令(SETUP)，RTSP建立指令告訴伺服器用戶端用于接收媒體資料的端口。流媒體連接配接建立完成後，用戶端發送一個播放指令(PLAY)，伺服器就開始在UDP上傳送媒體流（RTP包）到用戶端。 在播放過程中用戶端還可以向伺服器發送指令來控制快進、快退和暫停等。最後，用戶端可發送一個終止指令(TERADOWN)來結束流媒體會話

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.   使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合目前HTML的國際化；

6.   RTSP使用URI請求時包含絕對URI。而由于曆史原因造成的向後相容性問題，HTTP/1.1隻在請求中包含絕對路徑，把主機名放入單獨的标題域中；

對多個流的同時控制。對音頻/視訊來講，用戶端僅需發送一條播放或者暫停消息就可同時控制音頻流和視訊流。

作為請求或者回應的有效負荷傳輸的資訊。由以實體标題域（entity-header field）形式存在的元資訊和以實體主體（entity body）形式存在的内容組成

可以容納多個媒體流的檔案。RTSP伺服器可以為這些容器檔案提供集合控制。

RTSP互動的全過程。對一個電影的觀看過程,會話(session)包括由用戶端建立媒體流傳輸機制(SETUP)，使用播放(PLAY)或錄制(RECORD)開始傳送流，用停止(TEARDOWN)關閉流。

方法 URI RTSP版本       CR LF

       消息頭 CR LF          CR LF         

       消息體 CR LF

RTSP版本一般都是 RTSP/1.0。每行後面的CR LF表示回車換行，需要接受端有相應的解析，最後一個消息頭需要有兩個CR LF

消息體是可選的，有的Request消息并不帶消息體。

       RTSP版本 狀态碼 解釋      CR LF

       消息頭 CR LF          CR LF

其中RTSP版本一般都是RTSP/1.0,狀态碼是一個數值，用于表示Request消息的執行結果,比如200表示成功,解釋是與狀态碼對應的文本解釋.

用于得到伺服器提供的可用方法；

如:

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

用戶端向伺服器端發送DESCRIBE，用于得到URI所指定的媒體描述資訊，一般是SDP資訊。用戶端通過Accept頭指定用戶端可以接受的媒體述資訊類型。

如：

C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0

CSeq: 312

Accept: application/sdp, application/rtsl, application/mheg)

伺服器回應URI指定媒體的描述資訊:

S->C: RTSP/1.0 200 OK

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

[email protected] (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

媒體初始化是任何基于RTSP系統的必要條件，但RTSP規範并沒有規定它必須通過DESCRIBE方法完成。RTSP用戶端可以通過以下方法來接收媒體描述資訊：

a)   通過DESCRIBE方法；

b)   其它一些協定（HTTP，email附件，等）；

c)   通過指令行或标準輸入裝置

用于确定轉輸機制，建立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

伺服器端對SETUP Request産生一個Session Identifiers。

Session: 47112344  //産生一個Session ID

Transport: RTP/AVP;unicast;

client_port=4588-4589;server_port=6256-6257

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

CSeq: 836

Range: npt=20-25

CSeq: 837

Range: npt=30-

Range頭可能包含一個時間參數。該參數以UTC格式指定了播放開始的時間。如果在這個指定時間後收到消息，那麼播放立即開始。時間參數可能用來幫助同步從不同資料源擷取的資料流。

不含Range頭的PLAY請求也是合法的。它從媒體流開頭開始播放，直到媒體流被暫停。如果媒體流通過PAUSE暫停，媒體流傳輸将在暫停點（the pause point）重新開始。

如果媒體流正在播放，那麼這樣一個PLAY請求将不起更多的作用，隻是用戶端可以用此來測試伺服器是否存活。

PAUSE請求引起媒體流傳輸的暫時中斷。如果請求URL中指定了具體的媒體流，那麼隻有該媒體流的播放和記錄被暫停（halt）。比如，指定暫停音頻，播放将會無聲。如果請求URL指定了一組流，那麼在該組中的所有流的傳輸将被暫停。如：

C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0

CSeq: 834

PAUSE請求中可能包含一個Range頭用來指定何時媒體流暫停，我們稱這個時刻為暫停點（pause point）。該頭必須包含一個精确的值，而不是一個時間範圍。媒體流的正常播放時間設定成暫停點。當伺服器遇到在任何目前挂起（pending）的PLAY請求中指定的時間點後，暫停請求生效。如果Range頭指定了一個時間超出了任何一個目前挂起的PLAY請求，将傳回錯誤"457 Invalid Range" 。如果一個媒體單元（比如一個音頻或視訊禎）正好在一個暫停點開始，那麼表示将不會被播放或記錄。如果Range頭缺失，那麼在收到暫停消息後媒體流傳輸立即中斷，并且暫停點設定成目前正常播放時間。

TEARDOWN請求終止了給定URI的媒體流傳輸，并釋放了與該媒體流相關的資源。如：

C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0

CSeq: 892

用于指定用戶端可以接受的媒體描述資訊類型。比如:

Accept: application/rtsl, application/sdp;level=2

用于描述用戶端可用的帶寬值。

指定了RTSP請求回應對的序列号，在每個請求或回應中都必須包括這個頭字段。對每個包含一個給定序列号的請求消息，都會有一個相同序列号的回應消息。

用于指定一個時間範圍，可以使用SMPTE、NTP或clock時間單元。

 Session頭字段辨別了一個RTSP會話。Session ID 是由伺服器在SETUP的回應中選擇的，用戶端一當得到Session ID後，在以後的對Session 的操作請求消息中都要包含Session ID.

 Transport頭字段包含用戶端可以接受的轉輸選項清單，包括傳輸協定，位址端口，TTL等。伺服器端也通過這個頭字段傳回實際選擇的具體選項。如:

Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",

RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"

C表示RTSP用戶端,S表示RTSP服務端

 1.C->S:OPTION request       //詢問S有哪些方法可用

1.S->C:OPTION response    //S回應資訊的public頭字段中包括提供的所有可用方法

2.C->S:DESCRIBE request      //要求得到S提供的媒體描述資訊

2.S->C:DESCRIBE response    //S回應媒體描述資訊，一般是sdp資訊

3.C->S:SETUP request             //通過Transport頭字段列出可接受的傳輸選項，請求S建立會話

3.S->C:SETUP response          //S建立會話，通過Transport頭字段傳回選擇的具體轉輸選項，并傳回建立的Session ID;

4.C->S:PLAY request        //C請求S開始發送資料

4.S->C:PLAY response            //S回應該請求的資訊

S->C:發送流媒體資料    // 通過RTP協定傳送資料

6.C->S:TEARDOWN request      //C請求關閉會話

6.S->C:TEARDOWN response //S回應該請求

上述的過程隻是标準的、友好的rtsp流程，但實際的需求中并不一定按此過程。

其中第三和第四步是必需的！第一步，隻要伺服器用戶端約定好，有哪些方法可用，則option請求可以不要。第二步，如果我們有其他途徑得到媒體初始化描述資訊（比如http請求等等），則我們也不需要通過rtsp中的describe請求來完成。

SDP(Session Description Protocol )會話描述協定，用于描述多媒體會話，它為會話通知、會話初始和其它形式的多媒體會話初始等操作提供服務。

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=* （連接配接資訊 — 如果包含在會話層則該字段可選）

v=0

m=audio 49170 RTP/AVP 0

m=video 51372 RTP/AVP 31

m=application 32416 udp wb

//字段解釋

V=0     ;Version 給定了SDP協定的版本

o=<username> <session id> <version> <network type> <address type>

<address>； Origin ,給定了會話的發起者資訊

s=<session name> ;給定了Session Name

i=<session description> ; Information 關于Session的一些資訊

u=<URI> ; URI

e=<email address>    ;Email

c=<network type> <address type> <connection address> ;Connect Data包含連接配接資料

t=<start time> <stop time> ;Time

a=<attribute>     ; Attribute

a=<attribute>:<value>

m=<media> <port> <transport> <fmt list> ; Media Announcements