最近一直在看 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
[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=”開頭
參考連結：RTSP協定學習筆記
參考連結：RTSP協定總結
參看連結：live555源代碼分析
最近一直在看 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
[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=”開頭
參考連結：RTSP協定學習筆記
參考連結：RTSP協定總結
參看連結：live555源代碼分析