最近一直在看 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協議分析

一.簡介

? ? ? ? RTSP（Real Time Streaming Protocol）實時流傳輸協議，是TCP/IP協議體系中的一個基于文本的應用層協議，由哥倫比亞大學、網景和RealNetworks公司提交的IETF RFC2326標準。該協議定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據。RTSP在體系結構上位于RTP和RTCP之上，它使用TCP或UDP完成數據傳輸。

? ? ? ? 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
? ? ? ? ? ? e=mjh@isi.edu (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
e=mjh@isi.edu (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=”開頭

參考鏈接：RTSP協議學習筆記

參考鏈接：RTSP協議總結

參看鏈接：live555源代碼分析

總結

以上是生活随笔為你收集整理的RTSP再学习 -- RTSP协议分析（转载）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。