RTSP 協議簡單互動過程

阿新 • • 發佈：2019-02-12

Real Time Streaming Protocol或者RTSP（實時流媒體協議），是由Real network 和 Netscape共同提出的如何有效地在IP網路上傳輸流媒體資料的應用層協議。RTSP提供一種可擴充套件的框架，使能夠提供可控制的，按需傳輸實時資料，比如音訊和視訊檔案。源資料可以包括現場資料的反饋和存貯的檔案。rtsp對流媒體提供了諸如暫停，快進等控制，而它本身並不傳輸資料，rtsp作用相當於流媒體伺服器的遠端控制。傳輸資料可以
通過傳輸層的tcp，udp協議，rtsp也提供了基於rtp傳輸機制的一些有效的方法。

RTSP訊息格式:

RTSP的訊息有兩大類,一是請求訊息(request),

一是迴應訊息(response),兩種訊息的格式不同.
請求訊息:
方法 URI RTSP版本 CR LF
訊息頭 CR LF CR LF
訊息體 CR LF
其中方法包括OPTION迴應中所有的命令,URI是接受方的地址,例如
:rtsp://192.168.20.136
RTSP版本一般都是 RTSP/1.0.每行後面的CR LF表示回車換行，需要接受端有相應的解
析，最後一個訊息頭需要有兩個CR LF
迴應訊息:
RTSP版本狀態碼解釋 CR LF
訊息頭 CR LF CR LF
訊息體 CR LF
其中RTSP版本一般都是RTSP/1.0,狀態碼是一個數值,200表示成功,解釋是與狀態碼對應
的文字解釋.

簡單的rtsp互動過程:

C表示rtsp客戶端,S表示rtsp服務端
1.C->S:OPTION request //詢問S有哪些方法可用
1.S->C:OPTION response //S迴應資訊中包括提供的所有可用方法

2.C->S:DESCRIBE request //要求得到S提供的媒體初始化描述資訊
2.S->C:DESCRIBE response //S迴應媒體初始化描述資訊，主要是sdp

3.C->S:SETUP request //設定會話的屬性，以及傳輸模式，提醒S建立會
話
3.S->C:SETUP response //S建立會話，返回會話識別符號，以及會話相關資訊

4.C->S:PLAY request //C請求播放
4.S->C:PLAY response //S迴應該請求的資訊

S->C:傳送流媒體資料
5.C->S:TEARDOWN request //C請求關閉會話
5.S->C:TEARDOWN response //S迴應該請求

上述的過程是標準的、友好的rtsp流程，但實際的需求中並不一定按部就班來。
其中第3和4步是必需的！第一步，只要伺服器客戶端約定好，有哪些方法可用，則option請求可以不要。第二步，如果我們有其他途徑得到媒體初始化描述資訊（比如http請求等等），則我們也不需要通過rtsp中的describe請求來完成。第五步，可以根據系統需求的設計來決定是否需要。

rtsp中常用方法:

1.OPTION
目的是得到伺服器提供的可用方法:
OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 1 //每個訊息都有序號來標記，第一個包通常是option請求訊息
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

伺服器的迴應資訊包括提供的一些方法,例如:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 1 //每個迴應訊息的cseq數值和請求訊息的cseq相對應
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SCALE,
GET_PARAMETER //伺服器提供的可用的方法
2.DESCRIBE
C向S發起DESCRIBE請求,為了得到會話描述資訊(SDP):
DESCRIBE rtsp://192.168.20.136:5000/xxx666 RTSP/1.0

CSeq: 2
token:
Accept: application/sdp
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

伺服器迴應一些對此會話的描述資訊(sdp):
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 2
x-prev-url: rtsp://192.168.20.136:5000
x-next-url: rtsp://192.168.20.136:5000
x-Accept-Retransmit: our-retransmit
x-Accept-Dynamic-Rate: 1
Cache-Control: must-revalidate
Last-Modified: Fri, 10 Nov 2006 12:34:38 GMT
Date: Fri, 10 Nov 2006 12:34:38 GMT
Expires: Fri, 10 Nov 2006 12:34:38 GMT
Content-Base: rtsp://192.168.20.136:5000/xxx666/
Content-Length: 344
Content-Type: application/sdp

v=0 //以下都是sdp資訊
o=OnewaveUServerNG 1451516402 1025358037 IN IP4 192.168.20.136
s=/xxx666
u=http:///
[email protected]
c=IN IP4 0.0.0.0
t=0 0
a=isma-compliance:1,1.0,1

a=range:npt=0-
m=video 0 RTP/AVP 96 //m表示媒體描述，下面是對會話中視訊通道的媒體描述
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96
profile-level-id=245;config=000001B0F5000001B509000001000000012000C888B0E0E0FA62D089028307

a=control:trackID=0//trackID＝0表示視訊流用的是通道0

3.SETUP
客戶端提醒伺服器建立會話,並確定傳輸模式:
SETUP rtsp://192.168.20.136:5000/xxx666/trackID=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
//uri中帶有trackID＝0，表示對該通道進行設定。Transport引數設定了傳輸模式，包
的結構。接下來的資料包頭部第二個位元組位置就是interleaved，它的值是每個通道都
不同的，trackID＝0的interleaved值有兩個0或1，0表示rtp包，1表示rtcp包，接受端
根據interleaved的值來區別是哪種資料包。

伺服器迴應資訊:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 3
Session: 6310936469860791894 //伺服器迴應的會話識別符號
Cache-Control: no-cache
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=6B8B4567
4.PLAY
客戶端傳送播放請求:
PLAY rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 4
Session: 6310936469860791894
Range: npt=0.000- //設定播放時間的範圍
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
伺服器迴應資訊:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 4
Session: 6310936469860791894
Range: npt=0.000000-
RTP-Info: url=trackID=0;seq=17040;rtptime=1467265309
//seq和rtptime都是rtp包中的資訊
5.TEARDOWN
客戶端發起關閉請求:
TEARDOWN rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 5
Session: 6310936469860791894
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
伺服器迴應:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 5
Session: 6310936469860791894
Connection: Close

以上方法都是互動過程中最為常用的,其它還有一些重要的方法如
get/set_parameter,pause,redirect等等
ps:
sdp的格式
v=<version>
o=<username> <session id> <version> <network type> <address type> <address>
s=<session name>
i=<session description>
u=<URI>
e=<email address>
p=<phone number>
c=<network type> <address type> <connection address>
b=<modifier>:<bandwidth-value>
t=<start time> <stop time>
r=<repeat interval> <active duration> <list of offsets from start-time>
z=<adjustment time> <offset> <adjustment time> <offset> ....
k=<method>
k=<method>:<encryption key>
a=<attribute>
a=<attribute>:<value>
m=<media> <port> <transport> <fmt list>
v = （協議版本）
o = （所有者/建立者和會話識別符號）
s = （會話名稱）
i = * （會話資訊）
u = * （URI 描述）
e = * （Email 地址）
p = * （電話號碼）
c = * （連線資訊）
b = * （頻寬資訊）
z = * （時間區域調整）
k = * （加密金鑰）
a = * （0 個或多個會話屬性行）
時間描述：
t = （會話活動時間）
r = * （0或多次重複次數）
媒體描述：
m = （媒體名稱和傳輸地址）
i = * （媒體標題）
c = * （連線資訊 — 如果包含在會話層則該欄位可選）
b = * （頻寬資訊）
k = * （加密金鑰）
a = * （0 個或多個媒體屬性行）
參考文章：rfc2326（rtsp）；rfc2327（sdp）
RTSP點播訊息流程例項（客戶端：VLC， RTSP伺服器：LIVE555 Media Server)

1)C(Client)-> M(Media Server)
OPTIONS rtsp://192.168.1.109/1.mpg RTSP/1.0
CSeq: 1
user-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20)

1)M -> C
RTSP/1.0 200 OK
CSeq: 1
Date: wed, Feb 20 2008 07:13:24 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

2)C -> M
DESCRIBE rtsp://192.168.1.109/1.mpg RTSP/1.0
CSeq: 2
Accept: application/sdp
User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20)

2)M -> C
RTSP/1.0 200 OK
CSeq: 2
Date: wed, Feb 20 2008 07:13:25 GMT
Content-Base: rtsp://192.168.1.109/1.mpg/
Content-type: application/sdp
Content-length: 447
v=0
o =- 2284269756 1 IN IP4 192.168.1.109
s=MPEG-1 or 2 program Stream, streamed by the LIVE555 Media Server
i=1.mpg
t=0 0
a=tool:LIVE555 Streaming Media v2008.02.08
a=type:broadcast
a=control:*
a=range:npt=0-66.181
a=x-qt-text-nam:MPEG-1 or Program Stream, streamed by the LIVE555 Media Server
a=x-qt-text-inf:1.mpg
m=video 0 RTP/AVP 32
c=IN IP4 0.0.0.0
a=control:track1
m=audio 0 RTP/AVP 14
c=IN IP4 0.0.0.0
a=control:track2

3)C -> M
SETUP rtsp://192.168.1.109/1.mpg/track1 RTSP/1.0
CSeq: 3
Transport: RTP/AVP; unicast;client_port=1112-1113
User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20)

3)M -> C
RTSP/1.0 200 OK
CSeq: 3
Date: wed, Feb 20 2008 07:13:25 GMT
Transport: RTP/AVP;unicast;destination=192.168.1.222;source=192.168.1.109;client_port=1112-1113;server_port=6970-6971
Session: 3

4)C -> M
SETUP rtsp://192.168.1.109/1.mpg/track2 RTSP/1.0
CSeq: 4
Transport: RTP/AVP; unicast;client_port=1114-1115
Session: 3
User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20)

4)M -> C
RTSP/1.0 200 OK
CSeq: 4
Date: wed, Feb 20 2008 07:13:25 GMT
Transport: RTP/AVP;unicast;destination=192.168.1.222;source=192.168.1.109;client_port=1114-1115;server_port=6972-6973
Session: 3

5)C -> M
PLAY rtsp://192.168.1.109/1.mpg/ RTSP/1.0
CSeq: 5
Session: 3
Range: npt=0.000-
User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20)

5)M -> C
RTSP/1.0 200 OK
CSeq: 5
Range: npt=0.000-
Session: 3
RTP-Info: url=rtsp://192.168.1.109/1.mpg/track1;seq=9200;rtptime=214793785,url=rtsp://192.168.1.109/1.mpg/track2;seq=12770;rtptime=31721

(開始傳輸流媒體...)

**************************************************************************************************************************************************************************************

************************************************************************ 分界線 ********************************************************************************

**************************************************************************************************************************************************************************************

http://www.cnblogs.com/moonvan/archive/2011/09/11/2173449.html

更清晰的描述方法

1. 實時流協議RTSP

RTSP[3]協議以客戶伺服器方式工作，它是一個多媒體播放控制協議，用來使使用者在播放從因特網下載的實時資料時能夠進行控制，如：暫停/繼續、後退、前進等。因此 RTSP 又稱為“因特網錄影機遙控協議”。

1.1. RTSP協議簡介

要實現 RTSP 的控制功能，不僅要有協議，而且要有專門的媒體播放器(media player)和媒體伺服器(media server)。媒體伺服器與媒體播放器的關係是伺服器與客戶的關係。

媒體伺服器與普通的全球資訊網伺服器的最大區別就是媒體伺服器支援流式音訊和視訊的傳送，因而在客戶端的媒體播放器可以邊下載邊播放（需要先快取一小段時間的節目）。但從普通全球資訊網伺服器下載多媒體節目時，是先將整個檔案下載完畢，然後再進行播放。

圖1 RTSP與RTP和RTCP的關係

RTSP 僅僅是使媒體播放器能控制多媒體流的傳送。因此，RTSP 又稱為帶外協議，而多媒體流是使用 RTP 在帶內傳送的。

1.2. RTSP的報文結構

RTSP有兩類報文：請求報文和響應報文。請求報文是指從客戶向伺服器傳送請求報文，響應報文是指從伺服器到客戶的回答。

由於 RTSP 是面向正文的(text-oriented)，因此在報文中的每一個欄位都是一些 ASCII 碼串，因而每個欄位的長度都是不確定的。

RTSP報文由三部分組成，即開始行、首部行和實體主體。在請求報文中，開始行就是請求行，RTSP請求報文的結構如圖2所示。

圖2 RTSP請求報文的結構

RTSP請求報文的方法包括：OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER。RTSP請求報文的常用方法及作用如表1所示。

表1 RTSP請求報文的常用方法及作用

方法	作用
OPTIONS	獲得伺服器提供的可用方法
DESCRIBE	得到會話描述資訊
SETUP	客戶端提醒伺服器建立會話，並確定傳輸模式
TEARDOWN	客戶端發起關閉請求
PLAY	客戶端傳送播放請求

響應報文的開始行是狀態行，RTSP響應報文的結構如圖3所示。

圖3 RTSP響應報文的結構

1.3. RTSP互動過程

C表示RTSP客戶端，S表示RTSP服務端

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

S->C: OPTION response //S迴應資訊中包括提供的所有可用方法

② C->S: DESCRIBE request //要求得到S提供的媒體初始化描述資訊

S->C: DESCRIBE response //S迴應媒體初始化描述資訊，主要是sdp

③ C->S: SETUP request //設定會話屬性，以及傳輸模式，提醒S建立會話

S->C: SETUP response //S建立會話，返回會話識別符號及會話相關資訊

④ C->S: PLAY request //C請求播放

S->C: PLAY response //S迴應請求資訊

S->C: 傳送流媒體資料

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

S->C: TEARDOWN response //S迴應請求

上述的過程是標準的RTSP流程，其中第3步和第4步是必需的。

RTSP 協議簡單互動過程