RTSP(Real-Time Stream Protocol)協定是一個基于文本的多媒體播放控制協定，屬于應用層。 是由Real Network和Netscape共同提出的如何有效地在IP網絡上傳輸流媒體資料的應用層協定。RTSP提供一種可擴充的架構，能夠提供可控制的，按需 傳輸的實時資料，比如音頻和視訊檔案。源資料可以包括現場資料的回報和存儲的檔案。RTSP對流媒體提供了諸如暫停，快進等控制，而它本身并不傳輸數 據，RTSP的作用相當于流媒體伺服器的遠端控制。傳輸資料可以通過傳輸層的TCP/UDP協定，RTSP也提供了基于RTP傳輸機制的一些有效的方法。該标準由IETF指定，對應的協定是RFC2326。
RTSP作為一個應用層協定，提供了一個可供擴充的架構，使得流媒體的受控和點播變得可能，它主要用來控制具有實時特性的資料的發送，但其本身并不用于傳送流媒體資料，而必須依賴下層傳輸協定(如RTP/RTCP)所提供的服務來完成流媒體資料的傳送。RTSP負責定義具體的控制資訊、操作方法、狀态碼，以及描述與RTP之間的互動操作。RTSP媒體服務協定架構如下：
RTSP包含Normal RTSP(資料通過RTP傳輸，應用廠商有蘋果和微軟等)，以及Real-RTSP(資料通過RDT傳輸)。本篇我們主要講Normal RTSP。
RTSP傳輸的一般是TS、MP4格式的流，其傳輸一般需要2~3個通道，指令和資料通道分離。使用RTSP協定傳輸流媒體資料需要有專門的媒體播放器和媒體伺服器，也就是需要支援RTSP協定的用戶端和伺服器。
用戶端要播放RTSP媒體流，就需要知道媒體源的URL，RTSP的URL格式一般如下：
rtsp://host[:port]/[abs_path]/content_name
host: 有效的域名或IP位址；
port: 端口号，預設為554，若為預設可不填寫，否則必須寫明。
例如，一個完整的RTSP URL可寫為：
rtsp://192.168.1.67:554/test
又如目前市面上常用的海康網絡攝像頭的RTSP位址格式為：
rtsp://[username]:[password]@[ip]:[port]/[codec]/[channel]/[subtype]/av_stream
示例： rtsp://admin:[email protected]:554/h264/ch1/main/av_stream
rtsp://admin:[email protected]/mpeg4/ch1/sub/av_stream
RTSP封包
對RTSP協定的使用有了一個大概的了解之後，我們來看一下RTSP封包結構。
RTSP是一種基于文本的協定，用CRLF(回車換行)作為每一行的結束符，其好處是，在使用過程中可以友善地增加自定義參數，也友善抓包分析。從消息傳送方向上來分，RTSP的封包有兩類：請求封包和響應封包。請求封包是指從用戶端向伺服器發送的請求(也有少量從伺服器向用戶端發送的請求)，響應封包是指從伺服器到用戶端的回應。
RTSP請求封包的常用方法與作用：
1.OPTIONS
目的是得到伺服器提供的可用方法：
OPTIONS rtsp://192.168.22.136:5000/v0 RTSP/1.0
CSeq: 1 //每個消息都有序号來标記，第一個包通常是OPTIONS請求消息
User-Agent: bestilyq //自定義的字元串
伺服器的回應資訊包括提供的一些方法。例如：
RTSP/1.0 200 OK
Cseq: 1 //每個回應消息的cseq數值和請求消息的cseq相對應
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY //伺服器提供的可用的方法
2.DESCRIBE
C向S發起DESCRIBE請求，為了得到會話描述資訊(SDP)：
DESCRIBE rtsp://192.168.20.136:5000/v0 RTSP/1.0
CSeq: 2
Accept: application/sdp
Authorization: Basic YWRtaW46YWRtaW4= //有認證，不需要認證時不需要該字段
User-Agent: bestilyq
伺服器回應一些對此會話的描述資訊(sdp)：
RTSP/1.0 200 OK
Cseq: 2
Date: Sat Feb 5 22:49:39 2009 GMT
Content-Type: application/sdp
Content-Length: 182
v=0 //以下都是sdp資訊
o=- 0 0 IN IPV4 127.0.0.1
t=0 0
s=No Name
a=tool:libavformat
m=video 0 RTP/AVP 96 //m表示媒體描述，下面是對會話中視訊通道的媒體描述
b=AS:2000
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=1
a=control:streamid=0 //streamid＝0表示視訊流用的是通道0
3.SETUP
用戶端提醒伺服器建立會話，并确定傳輸模式：
(1)TCP模式
SETUP rtsp://192.168.20.136:5000/v0/streamid=0 RTSP/1.0
CSeq: 3
Authorization: Basic YWRtaW46YWRtaW4=
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
User-Agent: bestilyq
(2)UDP模式
SETUP rtsp://192.168.20.136:5000/v0/streamid=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=3008-3009
Authorization: Basic YWRtaW46YWRtaW4=
User-Agent: bestilyq
URI中帶有streamid＝0，表示對該通道進行設定。
Transport參數設定了傳輸模式。RTP/AVP/TCP表示通過TCP傳輸RTP包，RTP/AVP表示使用UDP傳輸RTP包。unicast表示單點傳播。interleaved 值有兩個：0和1，0表示RTP包，1表示RTCP包，接收端根據interleaved的值來差別是哪種資料包。client_port值有3008和 3009，3008表示用戶端接收RTP包的端口，3009表示用戶端接收RTCP包的端口，服務端要分别将RTP包和RTCP包發送到這兩個端口。
伺服器回應資訊：
(1)TCP模式
RTSP/1.0 200 OK
CSeq: 3
Date: Sat Feb 5 22:35:27 2009 GMT
Session: a522bbb4335617db
Transport: RTP/AVP/TCP;interleaved=0-1
(2)UDP模式
RTSP/1.0 200 OK
CSeq: 3
Date: Sat Feb 5 22:49:39 2009 GMT
Session: 01fa4ca2566a6301 //伺服器回應的會話辨別符
Transport: RTP/AVP/UDP;unicast;client_port=3008-3009;server_port=1024-1025
4.PLAY
用戶端發送播放請求：
PLAY rtsp://192.168.20.136:5000/v0 RTSP/1.0
CSeq: 4
Session: a522bbb4335617db //SETUP傳回的會話辨別符
Range: npt=0.000- //設定播放時間的範圍
User-Agent: bestilyq
伺服器回應資訊：
RTSP/1.0 200 OK
CSeq: 4
Date: Sat Feb 5 22:49:39 2009 GMT
Session: a522bbb4335617db
5.TEARDOWN
用戶端發起關閉請求:
TEARDOWN rtsp://192.168.20.136:5000/v0 RTSP/1.0
CSeq: 5
Session: a522bbb4335617db
User-Agent: bestilyq
伺服器回應:
RTSP/1.0 200 OK
Cseq: 5
Date: Sat Feb 5 22:49:47 2009 GMT
Session: a522bbb4335617db
以上方法都是互動過程中最為常用的,其它還有一些重要的方法如GET_PARAMETER,SET_PARAMETER,PAUSE,REDIRECT等等。
一次基本的RTSP互動過程：
C表示RTSP用戶端，S表示RTSP服務端
1.C->S：OPTIONS request //詢問S有哪些方法可用
1.S->C：OPTIONS 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描述請求(DESCRIBE request)，伺服器通過一個SDP(Session DescriptionProtocol)描述來進行回報(DESCRIBEresponse)，回報資訊包括流數量、媒體類型等資訊。用戶端分析該SDP描述，并為會話中的每一個流發送一個RTSP連接配接建立請求(SETUPrequest)，該指令會告訴伺服器用于接收媒體資料的端口，伺服器響應該請求(SETUP response)并建立連接配接之後，就開始傳送媒體流(RTP包)到用戶端。在播放過程中用戶端還可以向伺服器發送請求來控制快進、快退和暫停等。最後，用戶端可發送一個終止請求(TEARDOWN request)來結束流媒體會話。