LIVE555研究之二: RTSP、RTP/RTCP協議介紹
LIVE555研究之二RTSP、RTP/RTCP協議介紹
一、概述
RTSP(Real-Time Stream Protocol )是一種基於文字的應用層協議，在語法及一些訊息引數等方面，RTSP協議與HTTP協議類似。
RTSP被用於建立的控制媒體流的傳輸，它為多媒體服務扮演“網路遠端控制”的角色。RTSP本身並不用於傳送媒體流資料。媒體資料的傳送可通過RTP/RTCP等協議來完成。
基本的RTSP操作過程
首先，客戶端連線到流伺服器併發送一個OPTIONS命令查詢伺服器提供的方法收到伺服器的迴應後，傳送DESCRIBE
是通過wireshark抓包獲得的完整客戶端與伺服器進行的RTSP互動。黑色字體表示客戶端請求，紅色字體表示伺服器迴應。
OPTIONS rtsp://10.34.3.80/D:/a.264 RTSP/1.0
CSeq: 2
User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)
RTSP/1.0 200 OK
CSeq: 2
Date: Tue, Jul 22 2014 02:41:21 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER
可以發現RTSP協議的格式與http協議很類似，都是基於文字的協議，語法也基本相同。但是它們並不相同，有以下主要差別：
首先，方法名稱不同。RTSP新增了DESCRIBE、SETUP、PLAY等方法。
其次，HTTP協議是無狀態的協議，方法之間的傳送並無明顯的次序關係。而RTSP是有狀態的協議，各方法存在次序關係。
在者，HTTP協議可以以內帶載荷資料的方式傳送資料，如網頁資料。而RTSP僅僅提供流播放的控制，並不傳送流媒體資料。流媒體資料可以通過RTP/RTCP的方式傳送。
二、RTSP訊息
1. RTSP請求訊息格式
方法名稱 URL RTSP版本回車換行
訊息頭回車換行回車換行
訊息體回車換行
方法名稱包括OPTIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等。
URL是接受方的地址，如:rtsp://192.168.0.1/video1.3gp。
RTSP版本一般是RTSP/1.0
訊息的每一行都會以回車換行結尾，為了便於定位識別，訊息頭的最後一行有兩個回車換行。
訊息體有時是可選的。
2. 迴應訊息格式
RTSP版本狀態碼對應文字解釋回車換行
訊息頭回車換行回車換行
訊息體回車換行
RTSP版本一般為RTSP/1.0。
狀態碼錶示對應訊息的執行結果。
部分狀態碼與文字解釋對應列表如下：
狀態碼文字解釋含義
“200” OK 執行成功
“400” Bad Request 錯誤請求
“404” Not Found 未找到
“500” Internal Server Error 伺服器內部錯誤
3. 各方法詳細介紹
(1)OPTIONS
客戶端使用OPTION來查詢伺服器提供的方法。伺服器會在public欄位給出自己提供方法集合。從上面的抓包中可以看到此伺服器提供了OPTIONS、DESCRIBE、 SETUP、 TEARDOWN、 PLAY,、PAUSE,、GET_PARAMETER、SET_PARAMETER等方法。
OPTIONS方法並不是必須的。客戶端可以繞過OPTIONS，直接向伺服器傳送其他訊息。
CSeq欄位表示請求的序號。客戶端的每一個請求都會被賦值一個序號。每個請求訊息也會對應一個同樣序號的迴應訊息。
OPTIONS訊息可以在任何時間傳送。有的客戶端會定時向伺服器傳送OPTION訊息。而伺服器也可以通過是否定時收到OPTIONS訊息來判斷客戶端是否線上。但並不是所有客戶端和伺服器都這樣做。
User Agent
該域用於使用者標識.不同公司或是不同的客戶端。不同客戶端發出的訊息中的這個域的內容都不大相同。有時會指明客戶端的版本號、型號等等。
下面的對話中該欄位指明採用VLC作為客戶端，並給出版本號和使用LIVE555庫的版本。
OPTIONS rtsp://10.34.3.80/D:/a.264 RTSP/1.0
CSeq: 2 //請求序號
User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)
RTSP/1.0 200 OK
CSeq: 2 //回覆序號
Date: Tue, Jul 22 2014 02:41:21 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER
(2)DESCRIBE
DESCRIBE訊息是由客戶端傳送到伺服器端，用於客戶端得到請求連結中指定的媒體檔案的相關描述，一般是SDP資訊。SDP（Session Description Protocol）包含了會話的描述、媒體編碼型別、媒體的位元速率等資訊。對於流媒體服務而言，以下幾個域是在SDP中一定要包含的。
“a=control:”
“a=range:”
“a=rtpmap:”
“a=fmtp:”
當一個錄影中即包含音訊又包含視訊時，會有多個上述結構。每個媒體描述以m開始。下面綠色和黃色背景的字型分別表示對視訊和音訊媒體的描述。請求中的Accept欄位用於指定客戶端可以接受的媒體描述資訊型別，此處為SDP資訊。
DESCRIBE rtsp://10.34.3.80/D:/a.264 RTSP/1.0
CSeq: 3
User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)
Accept: application/sdp //請求獲得SDP資訊
RTSP/1.0 200 OK
CSeq: 3
Date: Tue, Jul 22 2014 02:41:21 GMT
Content-Base: rtsp://10.34.3.80/D:/a.264/ //指明對某媒體的描述資訊
Content-Type: application/sdp //請求型別
Content-Length: 494 //SDP長度
v=0 //Version SDP協議的版本
o=- 1405995833260880 1 IN IP4 10.34.3.80 //Origion 會話的發起者資訊
s=H.264 Video, streamed by the LIVE555 Media Server //會話名稱
i=D:/a.264 //會話的描述資訊
t=0 0 //會話的開始和結束時間
a=tool:LIVE555 Streaming Media v2014.07.04 //Attribute
a=type:broadcast
a=control:* //控制資訊
a=range:npt=0-
a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Server
a=x-qt-text-inf:D:/a.264
m=video 0 RTP/AVP 96 //傳送方所支援的媒體型別（視訊）等資訊
c=IN IP4 0.0.0.0 //會話連線資訊，支出真正的媒體流使用的IP地址。
b=AS:500 //視訊頻寬
a=rtpmap:96 H264/90000 //媒體屬性行，視訊（H264為視訊格式，90000為取樣率）
a=fmtp:96 packetization-mode=1;profile-level-id=42001E;sprop-parameter-sets=Z0IAHpWoLQSZ,aM48gA==
a=control:track1 //該視訊使用的track為1
m=audio 0 RTP/AVP 97 //媒體型別（音訊）以下均是對該音訊的描述資訊
b=AS:19 //音訊頻寬
a=rtpmap:97 MP4A-LATM/11025/1 //視訊格式（MP4A-LATM為視訊格式，11025為取樣率）
a=fmtp:97 profile-level-id=15; object=2; cpresent=0; config=40002A103FC0
a=mpeg4-esid:101=x-envivio-verid:00011118
a=control:trackID=2 /該音訊使用的track為2
m行又稱媒體行，描述了傳送方所支援的媒體型別等資訊，需要詳細說明下。
m=audio 3458 RTP/AVP 0 96 97
第一個引數audio為媒體名稱：表明支援音訊型別。
第二個引數3488為埠號，表明UE在本地埠為3458上傳送音訊流。
第三個引數RTP/AVP為傳輸協議，表示基於UDP的RTP協議。
第四到七個引數為所支援的四種淨荷型別編號。
a=rtpmap:0 PCMU
a=rtpmap:96 G726-32/8000
a=rtpmap:97 AMR-WB
a行為媒體的屬性行，以屬性的名稱：屬性值的方式表示。
格式為：a=rtpmap:<淨荷型別><編碼名稱>
淨荷型別0固定分配給了PCMU，
淨荷型別96對應的編碼方案為G.726,為動態分配的。
淨荷型別97對應的編碼方式為自適應多速率寬頻編碼（AMR-WB），為動態分配的。
對於視訊
m=video 3400 RTP/AVP 98 99
第一個引數video為媒體名稱：表明支援視訊型別。
第二個引數3400為埠號，表明UE在本地埠為3400上傳送視訊流。
第三個引數RTP/AVP為傳輸協議,表示RTP over UDP。
第四、五引數給出了兩種淨荷型別編號
a=rtpmap:98 MPV
a=rtpmap:99 H.261
淨荷型別98對應的編碼方案為MPV,為動態分配的。
淨荷型別97對應的編碼方式為H.261，為動態分配的。
(3)SETUP
SETUP訊息用於確定轉輸機制，建立RTSP會話。客戶端也可以在建立RTSP後再次發出一個SETUP請求為正在播放的媒體流改變傳輸引數，伺服器可能同意這些引數。若不同意，會迴應 "455 Method Not Valid In This State"。
Request 中的Transport頭欄位指定了客戶端可接受的資料傳輸引數；
Response中的Transport 頭欄位包含了由伺服器確認後的傳輸引數。
如果該請求不包含SessionID，則伺服器會產生一個SessionID。
SETUP rtsp://10.34.3.80/D:/a.264/track1 RTSP/1.0 //track1表示對1號通道進行設定
CSeq: 4
User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18) //客戶端版本資訊
Transport: RTP/AVP;unicast;client_port=60094-60095 //約定傳輸引數 RTP/AVP表示採用RTP over UDP， unicast表示單播，用以區別組播。Client_port約定客戶端RTP埠為60094，RTCP埠為60095
RTSP/1.0 200 OK
CSeq: 4
Date: Tue, Jul 22 2014 02:41:25 GMT
Transport: RTP/AVP;unicast;destination=10.34.3.80;source=10.34.3.80;client_port=60094-60095;server_port=6970-6971 //伺服器端所指定的傳輸引數
Session: 54DAFD56;timeout=65 //SessionID
從上面的SETUP會話中可以看到RTP埠用偶數表示，RTCP對於tcp埠相鄰的奇數埠。
上面展示的是RTP over UDP方式。以下為使用RTP over TCP的SETUP對話。
SETUP rtsp://10.34.3.80/D:/a.264/track1 RTSP/1.0 //track1表示對1號通道進行設定
CSeq: 4
User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)
Transport: RTP/AVP/TCP;unicast;interleaved= 0-1
RTSP/1.0 200 OK
CSeq: 4
Date: Tue, Jul 22 2014 02:41:25 GMT
Transport:
RTP/AVP/TCP;interleaved=0-1
Session: 54DAFD56;timeout=65
可以看到SETUP命令的Transport欄位為RTP/AVP/TCP，同時多了一個interleaved=0-1欄位。由於RTP over TCP將RTP包和RTCP包發至同一個TCP埠，因此使用interleaved的值來區分到底是RTP還是RTCP包。Interleaved=0表示RTP包，interleaved=1表示RTCP包。
(4)PLAY
PLAY方法通知伺服器按照SETUP中指定的機制開始傳送資料。伺服器會從PLAY訊息指定範圍的開始時間開始傳送資料，直到該範圍結束。伺服器可能會將PLAY請求放到佇列中，後一個PLAY請求需要等待前一個PLAY請求完成才能得到執行。
Range指定了播放開始的時間。如果在這個指定時間後收到訊息，那麼播放立即開始。
不含Range頭的PLAY請求也是合法的，此時將從媒體流開始位置播放，直到媒體流被暫停。如果媒體流通過PAUSE暫停，媒體流傳輸將在暫停點繼續傳輸。如果媒體流正在播放，那麼該PLAY請求將不起作用。客戶端可以利用此來測試伺服器是否存活。
PLAY rtsp://10.34.3.80/D:/a.264/ RTSP/1.0
CSeq: 5
User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)
Session: 54DAFD56 //SessionID，SETUP迴應中返回
Range: npt=0.000- / /指定開始播放的時間
RTSP/1.0 200 OK
CSeq: 5
Date: Tue, Jul 22 2014 02:41:25 GMT
Range: npt=0.000-
Session: 54DAFD56
RTP-Info: url=rtsp://10.34.3.80/D:/a.264/track1;seq=10244;rtptime=2423329550 //RTP資訊
Url欄位為RTP引數對應的流媒體連結地址，seq欄位為流媒體第一個包的序列號，rtptime為range域對應的RTP時間戳
(5)PAUSE
PAUSE訊息通知伺服器暫停流傳輸的傳輸。如果請求URL中指定了具體的媒體流，那麼只有該媒體流的播放被暫停。可以指定僅暫停音訊，此後的播放將會靜音。如果請求URL指定了一組流，那麼在該組中的所有流的傳輸將被暫停。伺服器有可能不支援PAUSE訊息。例如，實時流就有可能不支援暫停。當一個伺服器不支援某一個訊息時，會迴應給客戶端“501 Not Implemented”。
PAUSE請求中可能包含一個Range頭，用來指定媒體流暫停的時間點，稱之為暫停點。Range頭必須包含一個精確的值，而不是一個時間範圍。如果Range頭指定了一個時間超出了PLAY請求的範圍，伺服器將將返回"457 Invalid Range" 。如果Range頭缺失，那麼在收到暫停訊息後媒體流傳輸立即暫停，並將暫停點設定成當前播放時間。
(6) TEARDOWN
TEARDOWN請求終止了給定URL的媒體流傳輸，並釋放了與該媒體流相關的資源。
三、RTP/RTCP協議
RTP是實時傳輸協議（Real-Time Transport Protocol）的縮寫。是針對多媒體資料流的實時傳輸協議。通常建立在UDP協議之上，也可以建立在TCP協議之上。有人將其歸為應用層協議，也有人將其歸為傳輸層協議，這都是可以的。Rtp協議提供了時間戳和序列號。傳送端在取樣時設定時間戳，接收端收到後，會按照時間戳依次播放。RTP本身只保證實時資料的傳輸，並不能為按順序傳送的資料包提供可靠的傳送機制，也不提供流量和擁塞控制，它依靠RTCP來提供這些服務。
版本號（V）:0-1 2b 用來標識使用的RTP版本。
填充位（P）:2 1b 如果該位被置為1，則RTP包的尾部會跟附加的填充位元組。
擴充套件位（X）：3 1b 如果該位被置為1，則RTP包的尾部會跟附加擴充套件幀頭。
CSRC計數器（CC）: 4-7 4b 固定頭部後跟著的CSRC數目。
標記位（M）: 8 1b 該位的解釋由配置文件解釋。
載荷型別（PT）:9-15 7b標識RTP載荷的型別。
序列號（SN）: 16- 31 16b傳送方在傳送完每一個RTP包後會將該域 的值加1，接收方可以通過檢測序列號來判斷是否出現RTP丟包現象。注意：序列號的初始值是隨機的。
時間戳：32 32b 該包中第一個位元組的取樣時刻。時間戳有一個初始值，隨著時間的流逝而不斷增加。即使此時沒有包被髮出，時間戳也會不段增加。時間戳是實現去除抖動和實現同步必不可少的。
SSRC:同步源識別符號： 32b RTP包的來源，在同一個RTP會話中不能 有兩個相同的SSRC值。該欄位是根據一定的演算法隨機生成。
CSRC List:貢獻源列表 0-15個，每項32b 用來標識對一個RTP混合器產生的新包有貢獻的所有RTP包的源。
RTCP協議
RTCP是實時控制協議（Real-Time Control Protocol）的縮寫。RTCP通常與RTP配合使用，用以管理傳輸質量在當前程序之間的交換資訊。在RTP會話期間，各參與者週期性的傳送RTCP包，RTCP包中包含已傳送資料包的數量、丟失的資料包的數量等統計資料。伺服器可以利用這些資訊動態的改變傳輸速率，甚至改變有效載荷的型別。RTP和RTCP配合使用，可以有效且以最小的開銷達到最佳傳輸效率，非常適合傳送實時流。
RTSP通常使用RTP協議來傳送實時流，RTP一般使用偶數埠，而RTCP使用相鄰的奇數埠，即RTP埠號+1。
在RTCP通訊控制中，RTCP協議的功能是通過不同型別的RTCP包來實現的。RTCP也是基於UDP包來傳送的，主要有五種型別的封包：
1.SR：傳送端報告，由傳送RTP資料報的應用程式或中端發出的。
2.RR：接收端報告，由接受但不傳送RTP資料報的應用程式或中端發出。
3.SDES: 源描述，傳遞與會話成員有關的標識資訊的載體，如使用者名稱、郵件、電話等。
4.BYE: 通知離開，通知回話中的其他成員將退出會話。
5.APP: 由應用程式自己定義，作為RTCP協議的擴充套件。
版本（V）：同RTP包頭部
填充(P) ：同RTP包頭部。
接收報告計數器（RC）:5b 該SR包中接收的報告塊的數目。
包型別（PT）： 8bit SR包型別為200
長度（length）：SR包以32bit為1單位的長度減1
同步源（SSRC）：SR包傳送的同步源識別符號。與對應RTP包中的SSRC一樣。
NTP時間戳（Network Time Protocol）:SR包傳送時的絕對時間。用於同步不同的流。
RTP時間戳：與NTP時間戳對應，與RTP包中的時間戳具有相同的初始值。
Send’s Packet count：從開始發包到產生這個SR包的這段時間內傳送者傳送的有效資料的總位元組數，不包括頭部和填充，傳送者改變SSRC時，該域要清零。
同步源n的SSRC識別符號：該報告中包含的是從該源接收到的包的統計資訊。
丟失率：表明從上一個SR或RR包發出依來從同步源n傳送的RTP包的丟失率。
累計丟失資料：從開始接受SSRC_n的包到傳送SR這個時間段內SSRC_n傳送的RTP丟失的總數目。
收到的擴充套件最大序列號：從SSRC_n收到的從RTP資料包中的最大序列號。
接收抖動（Interarrival jitter）：RTP資料包接收時間的統計方差估計。
上次SR時間戳（Last SR）：取最近從SSRC_n收到的SR包中的NTP時間戳中的中間32bit。如果還未收到SR包，則為0。
上次依賴SR延遲（Delay since Last SR）：從上次SSRC_n收到SR包到傳送本包的延遲。
音視訊同步
傳送的音訊和視訊流位於兩個不同的RTP會話中，每個RTP包均有自己的時間戳，同時RTCP包中的NPT欄位（Network Protocol Time）儲存的絕對時間可以用來將音視訊對映到同一時間軸上，從而實現音視訊同步。
上述各協議在TCP/IP中的位置
下篇文章將介紹LIVE555基礎。
2014.8.2於浙江杭州