一、RTSP協議介紹
1.什么是rtsp?
RTSP協議以客戶服務器方式工作，，如：暫停/繼續、后退、前進等。它是一個多媒體播放控制協議，用來使用戶在播放從因特網下載的實時數據時能夠進行控制,
因此 RTSP 又稱為“因特網錄像機遙控協議”。
RTSP(Real-Time Stream Protocol)是一種基於文本的應用層協議，在語法及一些消息參數等方面，RTSP協議與HTTP協議類似。
是TCP/IP協議體系中的一個應用層協議, 由哥倫比亞大學, 網景和RealNetworks公司提交的IETF RFC標准. 對應的RFC編號是2326，可以在這里搜索 RFC Editor
該協議定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據. RTSP在體系結構上位於RTP和RTCP之上, 它使用TCP或RTP完成數據傳輸. RTSP被用於建立的控制媒體流的傳輸，它為多媒體服務扮演“網絡遠程控制”的角色。盡管有時可以把RTSP控制信息和媒體數據流交織在一起傳送，但一般情況RTSP本身並不用於轉送媒體流數據。
媒體數據的傳送可通過RTP/RTCP等協議來完成。
該協議用於C/S模型, 是一個基於文本的協議, 用於在客戶端和服務器端建立和協商實時流會話.
雖然RTSP服務器同樣也使用標識符來區別每一流連接會話（Session），但RTSP連接並沒有被綁定到傳輸層連接（如TCP等），也就是說在整個 RTSP連接期間，
RTSP用戶可打開或者關閉多個對RTSP服務器的可靠傳輸連接以發出RTSP 請求。此外，RTSP連接也可以基於面向無連接的傳輸協議（如UDP等）。
2.網絡體系
RTSP是類似http的應用層協議，一個典型的流媒體框架網絡體系可參考下圖:
3.一次基本的RTSP操作過程
1).首先，客戶端連接到流服務器並發送一個RTSP描述命令（DESCRIBE）。
2).流服務器通過一個SDP描述來進行反饋，反饋信息包括流數量、媒體類型等信息。
3).客戶端再分析該SDP描述，並為會話中的每一個流發送一個RTSP建立命令(SETUP)，RTSP建立命令告訴服務器客戶端用於接收媒體數據的端口。流媒體連接建立完成后，
4).客戶端發送一個播放命令(PLAY)，服務器就開始在UDP上傳送媒體流（RTP包）到客戶端。 在播放過程中客戶端還可以向服務器發送命令來控制快進、快退和暫停等。
5).最后，客戶端可發送一個終止命令(TERADOWN)來結束流媒體會話
sequenceDiagram
客戶端->>服務器:DESCRIBE
服務器->>客戶端: 200 OK (SDP)
客戶端->>服務器:SETUP
服務器->>客戶端: 200 OK
客戶端->>服務器:PLAY
服務器->>客戶端: (RTP包)
4.協議特點
1).可擴展性: 新方法和參數很容易加入RTSP.
2).易解析: RTSP可由標准HTTP或MIME解析器解析.
3).安全: RTSP使用網頁安全機制.
4).獨立於傳輸: RTSP可使用不可靠數據報協議(EDP), 可靠數據報協議(RDP); 如要實現應用級可靠, 可使用可靠流協議.
5).多服務器支持: 每個流可放在不同服務器上, 用戶端自動與不同服務器建立幾個並發控制連接, 媒體同步在傳輸層執行.
6).記錄設備控制: 協議可控制記錄和回放設備.
7).流控與會議開始分離: 僅要求會議初始化協議提供, 或可用來創建惟一會議標識號. 特殊情況下, 可用SIP或H.323來邀請服務器入會.
8).適合專業應用: 通過SMPTE時標, RTSP支持幀級精度, 允許遠程數字編輯.
9).演示描述中立: 協議沒強加特殊演示或元文件, 可傳送所用格式類型; 然而, 演示描述至少必須包括一個RTSP URL.
10).代理與防火牆友好: 協議可由應用和傳輸層防火牆處理. 防火牆需要理解SETUP方法, 為UDP媒體流打開一個“缺口”.
11).HTTP友好: 此處, RTSP明智地采用HTTP觀念, 使現在結構都可重用. 結構包括Internet內容選擇平台(PICS). 由於在大多數情況下控制連續媒體需要服務器狀態, RTSP不僅僅向HTFP添加方法.
12).適當的服務器控制: 如用戶啟動一個流, 必須也可以停止一個流.
13).傳輸協調: 實際處理連續媒體流前, 用戶可協調傳輸方法.
14).性能協調: 如基本特征無效, 必須有一些清理機制讓用戶決定哪種方法沒生效. 這允許用戶提出適合的用戶界面.
5.RTSP協議與HTTP協議區別
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只在請求中包含絕對路徑，把主機名放入單獨的標題域中；
二、RTSP重要術語
1. 集合控制(Aggregatecontrol ):
對多個流的同時控制。對音頻/視頻來講，客戶端僅需發送一條播放或者暫停消息就可同時控制音頻流和視頻流。
2. 實體(Entity)：
作為請求或者回應的有效負荷傳輸的信息。由以實體標題域（entity-header field）形式存在的元信息和以實體主體（entity body）形式存在的內容組成
3. 容器文件（Containerfile）：
可以容納多個媒體流的文件。RTSP服務器可以為這些容器文件提供集合控制。
4. RTSP會話(RTSP session )：
RTSP交互的全過程。對一個電影的觀看過程,會話(session)包括由客戶端建立媒體流傳輸機制(SETUP)，使用播放(PLAY)或錄制(RECORD)開始傳送流，用停止(TEARDOWN)關閉流。
三、RTSP 的報文結構
1.RTSP URL的語法結構
一個終端用戶是通過在播放器中輸入URL地址開始進行觀看流媒體業務的第一步，而對於使用RTSP協議的移動流媒體點播而言，URL的一般寫法如下：
一個以“rtsp”或是“rtspu”開始的URL鏈接用於指定當前使用的是RTSP 協議。RTSP URL的語法結構如下：
rtsp_url = (“rtsp:”| “rtspu:”) “//” host [“:”port”] /[abs_path]/content_name
host：可以是一個有效的域名或是IP地址。
port：端口號，對於RTSP協議來說，缺省的端口號為554。當我們在確認流媒體服務器提供的端口號為554時，此項可以省略 說明：當HMS服務器使用的端口號為554時，我們在寫點播鏈接時，可以不用寫明端口號，但當使用非554端口時，在RTSP URL中一定要指定相應的端口。
abs_path: 為RTSPServer中的媒體流資源標識
RTSPURL用來標識RTSPServer的媒體流資源，可以標識單一的媒體流資源，也可以標 識多個媒體流資源的集合。
2.RTSP的報文結構
RTSP是一種基於文本的協議，用CRLF作為一行的結束符。使用基於文本協議的好處在於我們可以隨時在使用過程中的增加自定義的參數，也可以隨便將協議包抓住很直觀的進行分析。
RTSP有兩類報文：請求報文和響應報文。請求報文是指從客戶向服務器發送請求報文，響應報文是指從服務器到客戶的回答。
由於 RTSP 是面向正文的(text-oriented)，因此在報文中的每一個字段都是一些 ASCII 碼串，因而每個字段的長度都是不確定的。
RTSP報文由三部分組成，即開始行、首部行和實體主體。在請求報文中，開始行就是請求行.
2.1.請求報文
請求報文的結構如下圖所示
也就是說：
方法 URI RTSP版本 CR LF
消息頭 CR LF CR LF
消息體 CR LF
1).請求消息的第一行的語法結構如下：
Request-Line = Method 空格 Request-URI 空格 RTSP-Version CRLF
其中方法包括OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等,URI是接受方的地址,例如:rtsp://192.168.0.1/video1.3gp。
RTSP版本一般都是 RTSP/1.0。每行后面的CR LF表示回車換行，需要接受端有相應的解析，
2).在消息頭中除了第一行的內容外，還有一些需求提供附加信息。其中有些是一定要的，后續我們會詳細介紹經常用到的幾個域的含義。
消息頭 = Accept
| Accept-Encoding
| Accept-Language
| Authorization
| From
| If-Modified-Since
| Range
| Referer
| User-Agent
3).最后一個消息頭需要有兩個CR LF。消息體是可選的，有的Request消息並不帶消息體。
2.2.響應報文
響應報文的開始行是狀態行，RTSP響應報文的結構如下圖所示
也就是說：
RTSP版本狀態碼解釋 CR LF
消息頭 CR LF CR LF
消息體 CR LF
1).響應消息的第一行是狀態行（status-line），每個元素之間用空格分開。除了最后的CRLF之外，在此行的中間不得有CR或是LF的出現。它的語法格式如下，
Status-Line = RTSP-Version 空格 Status-Code 空格 Reason-Phrase CRLF
狀態碼（Status-Code） 是一個三位數的整數，用於描述接收方對所收到請求消息的執行結果，
Status-Code的第一位數字指定了這個回復消息的種類，一共有5類：
1XX: Informational – 請求被接收到，繼續處理
2XX: Success – 請求被成功的接收，解析並接受
3XX: Redirection – 為完成請求需要更多的操作
4XX: Client Error – 請求消息中包含語法錯誤或是不能夠被有效執行
5XX: Server Error – 服務器響應失敗，無法處理正確的有效的請求消息
我們在處理問題時經常會遇到的狀態碼有如下：
| | |
---|---|---|---|--- Status-Code | = |“200”| : OK . || | “400”| : Bad Request . || | “404”| : Not Found . || | “500”| : Internal Server Error
2).在響應消息的域中存放的是無法放在Status-Line中,而又需要傳送給請求者的一些附加信息。
消息頭 = Location
| Proxy-Authenticate
| Public
| Retry-After
| Server
| Vary
| WWW-Authenticate
3.RTSP的主要方法
| 方法 |
方向 |
對象 |
要求 |
含義 |
| DESCRIBE |
C->S |
P,S |
推薦 |
檢查演示或媒體對象的描述，也允許使用接收頭指定用戶理解的描述格式。DESCRIBE的答復-響應組成媒體RTSP初始階段 |
| ANNOUNCE |
C->S S->C |
P,S |
可選 |
當從用戶發往服務器時，ANNOUNCE將請求URL識別的演示或媒體對象描述發送給服務器；反之，ANNOUNCE實時更新連接描述。如新媒體流加入演示，整個演示描述再次發送，而不僅僅是附加組件，使組件能被刪除 |
| GET_PARAMETER |
C->S S->C |
P,S |
可選 |
GET_PARAMETER請求檢查RUL指定的演示與媒體的參數值。沒有實體體時，GET_PARAMETER也許能用來測試用戶與服務器的連通情況 |
| OPTIONS |
C->S S->C |
P,S |
要求 |
可在任意時刻發出OPTIONS請求，如用戶打算嘗試非標准請求，並不影響服務器狀態 |
| PAUSE |
C->S |
P,S |
推薦 |
PAUSE請求引起流發送臨時中斷。如請求URL命名一個流，僅回放和記錄被停止；如請求URL命名一個演示或流組，演示或組中所有當前活動的流發送都停止。恢復回放或記錄后，必須維持同步。在SETUP消息中連接頭超時參數所指定時段期間被暫停后，盡管服務器可能關閉連接並釋放資源，但服務器資源會被預訂 |
| PLAY |
C->S |
P,S |
要求 |
PLAY告訴服務器以SETUP指定的機制開始發送數據；直到一些SETUP請求被成功響應，客戶端才可發布PLAY請求。PLAY請求將正常播放時間設置在所指定范圍的起始處，發送流數據直到范圍的結束處。PLAY請求可排成隊列，服務器將PLAY請求排成隊列，順序執行 |
| RECORD |
C->S |
P,S |
可選 |
該方法根據演示描述初始化媒體數據記錄范圍，時標反映開始和結束時間；如沒有給出時間范圍，使用演示描述提供的開始和結束時間。如連接已經啟動，立即開始記錄，服務器數據請求URL或其他URL決定是否存儲記錄的數據；如服務器沒有使用URL請求，響應應為201（創建），並包含描述請求狀態和參考新資源的實體與位置頭。支持現場演示記錄的媒體服務器必須支持時鍾范圍格式，smpte格式沒有意義 |
| REDIRECT |
S->C |
P,S |
可選 |
重定向請求通知客戶端連接到另一服務器地址。它包含強制頭地址，指示客戶端發布URL請求；也可能包括參數范圍，以指明重定向何時生效。若客戶端要繼續發送或接收URL媒體，客戶端必須對當前連接發送TEARDOWN請求，而對指定主執新連接發送SETUP請求 |
| SETUP |
C->S |
S |
要求 |
對URL的SETUP請求指定用於流媒體的傳輸機制。客戶端對正播放的流發布一個SETUP請求，以改變服務器允許的傳輸參數。如不允許這樣做，響應錯誤為"455 Method Not Valid In This State”。為了透過防火牆，客戶端必須指明傳輸參數，即使對這些參數沒有影響 |
| SET_PARAMETER |
C->S S->C |
P,S |
可選 |
請求設置演示或URL指定流的參數值。請求僅應包含單個參數，允許客戶端決定某個特殊請求為何失敗。如請求包含多個參數，所有參數可成功設置，服務器必須只對該請求起作用。服務器必須允許參數可重復設置成同一值，但不讓改變參數值。注意：媒體流傳輸參數必須用SETUP命令設置。將設置傳輸參數限制為SETUP有利於防火牆。將參數划分成規則排列形式，結果有更多有意義的錯誤指示 |
| TEARDOWN |
C->S |
P,S |
要求 |
TEARDOWN請求停止給定URL流發送，釋放相關資源。如URL是此演示URL，任何RTSP連接標識不再有效。除非全部傳輸參數是連接描述定義的，SETUP請求必須在連接可再次播放前發布 |
注：P---演示，C---客戶端,S---服務器， S（對象欄）---流
信令指的是在Request-URI中指定的需要被接收者完成的操作。信令（The method）大小寫敏感，不能以字符”$”開始，並且一定要是一個標記符。
4.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 OPTION request //詢問S有哪些方法可用
S->C OPTION response //S回應信息的public頭字段中包括提供的所有可用方法
2.第二步：得到媒體描述信息
C->S DESCRIBE request //要求得到S提供的媒體描述信息
S->C DESCRIBE response //S回應媒體描述信息，一般是sdp信息
3.第三步：建立RTSP會話
C->S SETUP request //通過Transport頭字段列出可接受的傳輸選項，請求S建立會話
S->C SETUP response //S建立會話，通過Transport頭字段返回選擇的具體轉輸選項，並返回建立的Session ID;
4.第四步：請求開始傳送數據
C->S PLAY request //C請求S開始發送數據
S->C PLAY response //S回應該請求的信息
5.第五步： 數據傳送播放中
S->C 發送流媒體數據 // 通過RTP協議傳送數據
6.第六步：關閉會話，退出
C->S EARDOWN request //C請求關閉會話
S->C TEARDOWN response //S回應該請求
上述的過程只是標准的、友好的rtsp流程，但實際的需求中並不一定按此過程。
其中第三和第四步是必需的！第一步，只要服務器和客戶端約定好有哪些方法可用，則option請求可以不要。第二步，
如果我們有其他途徑得到媒體初始化描述信息（比如http請求等等），則我們也不需要通過rtsp中的describe請求來完成。
五、RTSP的請求響應示例
其中C是客戶端，S是服務端。
1. OPTIONS:
用於得到服務器提供的可用方法；
如:
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
2. DESCRIBE：
客戶端向服務器端發送DESCRIBE，用於得到URI所指定的媒體描述信息，一般是SDP信息。客戶端通過Accept頭指定客戶端可以接受的媒體述信息類型。
如：
C->S: DESCRIBE rtsp://server.example.com/fizzle/fooRTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl,application/mheg)
服務器回應URI指定媒體的描述信息:
如:
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
//字段解釋
V=0 ;Version 給定了SDP協議的版本
o=<username><session id> <version> <network type> <address type>
<address>； Origin ,給定了會話的發起者信息
s=<sessionname> ;給定了Session Name
i=<sessiondescription> ; Information 關於Session的一些信息
u=<URI> ; URI
e=<emailaddress> ;Email
c=<networktype> <address type> <connection address> ;Connect Data包含連接數據
t=<start time><stop time> ;Time
a=<attribute> ; Attribute
a=<attribute>:<value>
m=<media><port> <transport> <fmt list> ; MediaAnnouncements
媒體初始化是任何基於RTSP系統的必要條件，但RTSP規范並沒有規定它必須通過DESCRIBE方法完成。RTSP客戶端可以通過以下方法來接收媒體描述信息：
a) 通過DESCRIBE方法；
b) 其它一些協議（HTTP，email附件，等）；
c) 通過命令行或標准輸入設備
另一個例子：
命令名稱：DESCRIBE
命令作用：請求SDP
命令格式：
DESCRIBE<BLANK><RTSP URI><BLANK>RTSP/<RTSP VERSION>\r\nCSeq:<BLANK><COMMAND SEQUENCE>\r\n\r\n
（Note：<BLANK>：空格；<COMMAND SEQUENCE>：命令序列，每一次發送命令該數字加1）
命令示例：
DESCRIBE rtsp://127.0.0.1/ansersion RTSP/1.0
CSeq: 1
（Note：雖然看不見，但示例中最后是有空行的，必不可少哦！看看“命令格式”最后連着兩個"\r\n"你就明白了。空行（\r\n）是RTSP數據包的結束標識。）
服務端返回信息格式：
RTSP/<RTSP VERSION><BLANK><STATE ID><BLANK><STATE DESCRIBE>\r\nCSeq:<BLANK><COMMAND SEQUENCE>\r\n<OTHER>\r\n\r\n<SDP>
（Note：<OTHER>: 其他描述信息；<SDP>: SDP描述信息，SDP不屬於RTSP的打包數據，這里可以看到空行（\r\n）在SDP之前）
服務端返回信息示例：
RTSP/1.0 200 OK
CSeq: 1
Date: Sun, Dec 27 2015 02:16:50 GMT
Content-Base: rtsp://127.0.0.1/ansersion/
Content-Type: application/sdp
Content-Length: 510
v=0
o=- 1451182595570866 1 IN IP4 192.168.81.145
s=Session streamed by "testOnDemandRTSPServer"
i=ansersion
t=0 0
a=tool:LIVE555 Streaming Media v2015.11.09
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:Session streamed by "testOnDemandRTSPServer"
a=x-qt-text-inf:ansersion
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:500
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=4D4033;sprop-parameter-sets=Z01AM5JUDAS0IAAAAwBAAAAM0eMGVA==,aO48gA==
a=control:track1
（Note：以RTSP客戶端的角度，以上紅字部分信息必須理解。
首先是"RTSP/1.0 200 OK"，這個表示RTSP服務端成功受理客戶端的請求。
再者是“m=video 0 RTP/AVP 96”，該信息指出了RTSP客戶端提供傳輸的流媒體類型，“a=control:track1”指出了訪問該流媒體的方式，是后續SETUP命令的重要參數，這是一個簡化的版本，有時候服務端會返回完整版本：“a=control:rtsp://127.0.0.1/ansersion/track1”。
最后是“Z01AM5JUDAS0IAAAAwBAAAAM0eMGVA==”和“aO48gA==”，這是H264的SPS和PPS的Base64編碼。老實說，要讓RTSP客戶端去考慮具體編碼格式的問題，着實是一個設計上的瑕疵。后續我打算把這部分改掉，現在我們將其看作H264的重要參數即可）
在SDP中也說明了本次會話的屬性
SDP 參數
下面描述了如何在 SDP 中表示一個 H.264 流:
. "m=" 行中的媒體名必須是 "video"
. "a=rtpmap" 行中的編碼名稱必須是 "H264".
. "a=rtpmap" 行中的時鍾頻率必須是 90000.
. 其他參數都包括在 "a=fmtp" 行中.
如:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; packetization-mode=1; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
下面介紹一些常用的參數.
1). packetization-mode:
表示支持的封包模式.
當 packetization-mode 的值為 0 時或不存在時, 必須使用單一 NALU 單元模式.
當 packetization-mode 的值為 1 時必須使用非交錯(non-interleaved)封包模式.
當 packetization-mode 的值為 2 時必須使用交錯(interleaved)封包模式.
每個打包方式允許的NAL單元類型總結(yes = 允許, no = 不允許, ig = 忽略)
Type Packet Single NAL Non-Interleaved Interleaved
Unit Mode Mode Mode
-------------------------------------------------------------
0 undefined ig ig ig
1-23 NAL unit yes yes no
24 STAP-A no yes no
25 STAP-B no no yes
26 MTAP16 no no yes
27 MTAP24 no no yes
28 FU-A no yes yes
29 FU-B no no yes
30-31 undefined ig ig ig
這個參數不可以取其他的值.
2). sprop-parameter-sets: SPS,PPS
這個參數可以用於傳輸 H.264 的序列參數集和圖像參數 NAL 單元. 這個參數的值采用 Base64 進行編碼. 不同的參數集間用","號隔開.
3).profile-level-id:
這個參數用於指示 H.264 流的 profile 類型和級別. 由 Base16(十六進制) 表示的 3 個字節. 第一個字節表示 H.264 的 Profile 類型, 第三個字節表示 H.264 的 Profile 級別:
4).max-mbps:
這個參數的值是一個整型, 指出了每一秒最大的宏塊處理速度.
3. SETUP：
用於確定轉輸機制，建立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
服務器端對SETUPRequest產生一個Session Identifiers。
如:
S->C: RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344 //產生一個SessionID
Transport: RTP/AVP;unicast;
client_port=4588-4589;server_port=6256-6257
另一個例子:
命令名稱：SETUP
命令作用：建立流媒體會話，告知RTSP服務端准備資源，以待后續進一步操作（比如“PLAY”）
命令格式：
SETUP<BLANK><RTSP URI>/<SDP ATTRIBUTE CONTROL>RTSP/<RTSP VERSION>\r\nTransport:<BLANK><PROTOCOL>;<CAST METHOD>;client_port=<RTP PORT>-<RTCP PORT>\r\nCSeq:<BLANK><COMMAND SEQUENCE>\r\n\r\n
（Note：<SDP ATTRIBUTE CONTROL>：SDP中“a=control:track1”；<PROTOCOL>：實時流傳輸協議，一般為RTP+UDP；<CAST METHOD>：傳輸方式，單播或組播；）
命令示例：
SETUP rtsp://127.0.0.1/ansersion/track1 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=10330-10331
CSeq: 2
（Note：使用RTP傳輸（RTP/AVP/UDP），傳輸方式為單播（unicast），RTP和RTCP的端口號分別為10330和10331（client_port=10330-10331））
服務端返回信息格式：
RTSP/<RTSP VERSION><BLANK><STATE ID><BLANK><STATE DESCRIBE>\r\nCSeq:<BLANK><COMMAND SEQUENCE>\r\n<OTHER>\r\n<SESSION ID>\r\n\r\n
（Note：<SESSION ID>：服務端建立好資源后，通過該標識訪問其媒體流資源。）
服務端返回信息示例：
RTSP/1.0 200 OK
CSeq: 2
Date: Sun, Dec 27 2015 02:28:01 GMT
Transport: RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=10330-10331;server_port=6970-6971
Session: ABF519D9;timeout=65
（Note：其中“ABF519D9”為SESSION ID，PLAY命令以此為參數，告知服務端以SETUP命令中指定的方式（RTP、unicast、client_port=10330-10331）進行媒體流傳輸）
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請求終止了給定URI的媒體流傳輸，並釋放了與該媒體流相關的資源。如：
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 892
六、參考的原文:
https://github.com/EasyDarwin/Course/tree/master/流媒體開發實戰進階(RTSP視頻播放器)
http://blog.csdn.net/leixiaohua1020/article/details/11955341
http://blog.csdn.net/pu1030/article/details/7619908
http://www.cnblogs.com/ansersion/p/5079758.html
http://blog.csdn.net/ajiva/article/details/276909
http://www.rfc-editor.org/info/rfc2326
http://blog.csdn.net/zblue78/article/details/5948538