最近一直在看 RTSP，但是RTSP協議是個啥？還沒有搞清楚。

首先流媒體百度百科上有這樣一段，從基本的名字上或多或少可以理解一下這些傳輸協議的區別。這很重要！！

傳輸協議
1、RSVP：資源預留協議
2、RTP：實時傳輸協議
3、RTCP：實時傳輸控制協議
4、MMS：微軟流媒體服務協議
5、RTSP：實時流傳輸協議
6、MIME：多目因特網電子郵件擴充套件協議
7、RTMP(RTMPE/RTMPS/RTMPT)：Adobe實時訊息協議簇
8、RTMFP：Adobe實施訊息流協議（P2P協議）

一.簡介

        RTSP（Real Time Streaming Protocol）實時流傳輸協議，是TCP/IP協議體系中的一個基於文字的應用層協議

        HTTP與RTSP相比，HTTP請求由客戶機發出，伺服器作出響應；使用RTSP時，客戶機和伺服器都可以發出請求，即RTSP可以是雙向的。RTSP是用來控制聲音或影像的多媒體串流協議，並允許同時多個串流需求控制，傳輸時所用的網路通訊協定並不在其定義的範圍內，伺服器端可以自行選擇使用TCP或UDP來傳送串流內容，它的語法和運作跟HTTP 1.1類似，但並不特別強調時間同步，所以比較能容忍網路延遲。而前面提到的允許同時多個串流需求控制（Multicast），除了可以降低伺服器端的網路用量，更進而支援多方視訊會議（Video Conference）。因為與HTTP1.1的運作方式相似，所以代理伺服器〈Proxy〉的快取功能〈Cache〉也同樣適用於RTSP，並因RTSP具有重新導向功能，可視實際負載情況來轉換提供服務的伺服器，以避免過大的負載集中於同一伺服器而造成延遲。

        RTSP與RTP最大的區別在於：RTSP是一種雙向實時資料傳輸協議，它允許客戶端向伺服器端傳送請求，如回放、快進、倒退等操作。當然，RTSP可基於RTP來傳送資料，還可以選擇TCP、UDP、組播UDP等通道來發送資料，具有很好的擴充套件性。RTP是用來提供實時傳輸的，它建立在UDP之上，因而可以看成是傳輸層的一個子層。

        目前碰到的一個應用：伺服器端實時採集、編碼併發送兩路視訊，客戶端接收並顯示兩路視訊。由於客戶端不必對視訊資料做任何回放、倒退等操作，可直接採用UDP+RTP+組播實現。

        RTSP被用於建立的控制媒體流的傳輸，它為多媒體服務扮演“網路遠端控制”的角色。儘管有時可以把RTSP控制資訊和媒體資料流交織在一起傳送，但一般情況RTSP本身並不用於轉送媒體流資料。媒體資料的傳送可通過RTP/RTCP等協議來完成。
        一次基本的RTSP操作過程是:首先，客戶端連線到流伺服器併發送一個RTSP描述命令（DESCRIBE）。流伺服器通過一個SDP描述來進行反饋，反饋資訊包括流數量、媒體型別等資訊。客戶端再分析該SDP描述，併為會話中的每一個流傳送一個RTSP建立命令(SETUP)，RTSP建立命令告訴伺服器客戶端用於接收媒體資料的埠。流媒體連線建立完成後，客戶端傳送一個播放命令(PLAY)，伺服器就開始在UDP上傳送媒體流（RTP包）到客戶端。 在播放過程中客戶端還可以向伺服器傳送命令來控制快進、快退和暫停等。最後，客戶端可傳送一個終止命令(TERADOWN)來結束流媒體會話。

二.RTSP重要術語

1.集合控制(Aggregatecontrol ):
        對多個流的同時控制。對音訊/視訊來講，客戶端僅需傳送一條播放或者暫停訊息就可同時控制音訊流和視訊流。
2.實體(Entity)：
        作為請求或者回應的有效負荷傳輸的資訊。由以實體標題域（entity-header field）形式存在的元資訊和以實體主體（entity body）形式存在的內容組成
3.容器檔案（Containerfile）：
        可以容納多個媒體流的檔案。RTSP伺服器可以為這些容器檔案提供集合控制。
4.RTSP會話(RTSP session )：
        RTSP互動的全過程。對一個視訊的播放過程，會話(session)包括由客戶端建立媒體流傳輸機制(SETUP)，使用播放(PLAY)或錄製(RECORD)開始傳送流，用停止(TEARDOWN)關閉流。

5.訊息(Message):

        RTSP通訊的基本單元，由特定語法結構，序列化的八位位元組流組成。

三.RTSP訊息格式

1.請求訊息

        其中方法包括OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等。URL是接接收方的地址，例如:rtsp://192.168.0.1/video.264。RTSP版本一般都是 RTSP/1.0。每行後面的CRLF表示回車換行，需要接收端有相應的解析，最後一個訊息頭需要有兩個CRLF。訊息體是可選的，有的請求訊息並不帶訊息體

2.響應訊息

        其中RTSP版本一般都是RTSP/1.0。狀態碼是一個數值，用於表示請求訊息的執行結果，比如200表示成功。短語是與狀態碼對應的文字解釋。

四.RTSP重要方法

1.OPTIONS:（選項）
用於得到伺服器提供的可用方法。
如:

C->S:OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
          CSeq: 1        
伺服器的迴應資訊會在Public欄位列出提供的方法。

如:
S->C:RTSP/1.0 200 OK
         CSeq: 1        //每個迴應訊息的cseq數值和請求訊息的cseq相對應
         Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

2.DESCRIBE：（描述）
客戶端向伺服器端傳送DESCRIBE，用於得到URL所指定的媒體描述資訊，一般是SDP資訊。客戶端通過Accept頭指定客戶端可以接受的媒體述資訊型別。
如：
C->S:DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
          CSeq: 312
          Accept: application/sdp, application/rtsl,application/mheg
伺服器迴應URL指定媒體的描述資訊:
如:
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
            [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)  通過命令列或標準輸入裝置。

3.SETUP：（組織）
用於確定轉輸機制，建立RTSP會話。客戶端能夠發出一個SETUP請求為正在播放的媒體流改變傳輸引數，伺服器可能同意這些引數的改變。若是不同意，它必須響應錯誤"455 Method Not Valid In This State"。
請求中的Transport頭欄位指定了客戶端可接受的資料傳輸引數；響應中的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請求產生一個Session ID。
如:
S->C:RTSP/1.0 200 OK
          CSeq: 302
          Date: 23 Jan 1997 15:35:06 GMT
          Session: 47112344 //產生一個Session ID
          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請求終止了給定URL的媒體流傳輸，並釋放了與該媒體流相關的資源。

如：
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.第一步：查詢伺服器端可用方法
C->S:OPTIONrequest          //詢問S有哪些方法可用
S->C:OPTIONresponse       //S迴應資訊的public頭欄位中包括提供的所有可用方法

2.第二步：得到媒體描述資訊
C->S:DESCRIBE request    //要求得到S提供的媒體描述資訊
S->C:DESCRIBE response  //迴應媒體描述資訊，一般是sdp資訊

3.第三步：建立RTSP會話
C->S:SETUPrequest            //通過Transport頭欄位列出可接受的傳輸選項，請求S建立會話
S->C:SETUPresponse          //建立會話，通過Transport頭欄位返回選擇的具體轉輸選項，並返回建立的Session ID;

4.第四步：請求開始傳送資料
C->S:PLAY request               //C請求S開始傳送資料
S->C:PLAYresponse              //S迴應該請求的資訊

5.第五步：資料傳送播放中
S->C:傳送流媒體資料             //通過RTP協議傳送資料

6.  第六步：關閉會話，退出
C->S:TEARDOWN request    //C請求關閉會話
S->C:TEARDOWN response //S迴應該請求
上述的過程只是標準的、友好的rtsp流程，但實際的需求中並不一定按此過程。
其中第三和第四步是必需的！第一步，只要伺服器客戶端約定好，有哪些方法可用，則option請求可以不要。第二步，如果我們有其他途徑得到媒體初始化描述資訊（比如http請求等等），則我們也不需要通過rtsp中的describe請求來完成。

七.SDP協議

1.SDP協議概述
SDP(Session Description Protocol )會話描述協議，用於描述多媒體會話，它為會話通知、會話初始和其它形式的多媒體會話初始等操作提供服務。它的標準檔案是IETF RFC4566。
SDP的設計宗旨是通用性協議，所有它可以應用於很大範圍的網路環境和應用程式，但 SDP不支援會話內容協商或媒體編碼。它時一個純粹的會話描述格式，不包含任何傳輸協議。

SDP資訊包括：
☆會話名稱和目標；
☆會話活動時間；
☆構成會話的媒體；
☆有關接收媒體的資訊、地址等。

2.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個或多個會話屬性線路）

3.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 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>：給定了會話的發起者資訊
s=<session name>：給定了會話名稱
i=<session description> ：提供了 關於會話的一些資訊
u=<uri> ：URI（Uniform Resource Identifier）用於網路客戶端，它指向了關於會話的額外資訊
e=<email address>：Email地址
c=<networktype> <address type> <connection address> ：包含連線資料
t=<start time><stop time> ：指定了會話開始和結束的時間
a=<attribute> ：屬性主要用來擴充套件SDP，通常這種屬性是會話的一部分，比如a=recvonly
a=<attribute>:<value>：帶值的屬性，比如說白板上的內容，a=orient:portrait、a=landscape或者a=seascape。        比較常用的是a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>]

m=<media><port> <transport> <fmt list> ：包含許多媒體描述，每個描述都以“m=”開頭