RTP、RTCP和RTSP協議基礎
1 RTSP概述
1.1 RTSP概念
RTSP(Real-Time Stream Protocol )是一種基于文本的應用層協議，在語法及一些消息參數等方面，RTSP協議與HTTP協議類似。
RTSP被用于建立的控制媒體流的傳輸，它為多媒體服務扮演“網絡遠程控制”的角色。RTSP本身并不用于傳送媒體流數據。媒體數據的傳送可通過RTP/RTCP等協議來完成。
1.2 基本的RTSP操作過程
首先，客戶端連接到流服務器并發送一個OPTIONS命令查詢服務器提供的方法收到服務器的回應后，發送DESCRIBE命令查詢某個媒體文件的SDP信息。流服務器通過一個SDP描述來進行回應，回應信息包括流數量、媒體類型等信息。客戶端分析該SDP描述，并為會話中的每一個流發送一個SETUP命令，SETUP命令告訴服務器客戶端用于接收媒體數據的端口。流媒體連接建立完成后，客戶端發送一個PLAY命令，服務器就開始傳送媒體流數據。在播放過程中客戶端還可以向服務器發送PAUSE等其他命令控制流的播放。通信完畢，客戶端可發送TERADOWN命令來結束流媒體會話。
1.3 RTSP與HTTP的區別
可以發現RTSP協議的格式與http協議很類似，都是基于文本的協議，語法也基本相同。但是它們并不相同，有以下主要差別：
首先，方法名稱不同。RTSP新增了DESCRIBE、SETUP、PLAY等方法。
其次，HTTP協議是無狀態的協議，方法之間的發送并無明顯的次序關系。而RTSP是有狀態的協議，各方法存在次序關系。
在者，HTTP協議可以以內帶載荷數據的方式傳送數據，如網頁數據。而RTSP僅僅提供流播放的控制，并不傳送流媒體數據。流媒體數據可以通過RTP/RTCP的方式傳送。
1.4 RTSP以及RTP等在TCP/IP協議簇中位置
2 RTSP消息
2.1 RTSP消息格式
2.1.1 RTSP請求消息格式
方法名稱 URL RTSP版本 回車換行 header 回車換行 回車換行 body 回車換行
注意：方法名稱 包括OPTIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等。
URL 是接受方的地址，如:rtsp://192.168.0.1/video1.3gp。
RTSP版本一般是RTSP/1.0
消息的每一行都會以回車換行結尾，為了便于定位識別，消息頭header的最后一行有兩個回車換行。
消息體body有時是可選的。
2.1.2 RTSP響應消息格式
RTSP版本 狀態碼 對應文本解釋 回車換行 header 回車換行 回車換行 body 回車換行
注音： RTSP版本 一般為RTSP/1.0。
狀態碼 表示對應消息的執行結果。
部分狀態碼與文本解釋對應列表如下：
狀態碼 文本解釋 含義
“200” OK 執行成功
“400” Bad Request 錯誤請求
“404” Not Found 未找到
“500” Internal Server Error 服務器內部錯誤
2.2 RTSP中各方法詳細介紹
2.2.1 OPTIONS
Client用OPTIONS來查詢Server提供的方法。Server在響應消息的public字段給出自己提供的方法集合。
注意：
1 OPTIONS方法并非必須，Client可以繞過OPTIONS，而直接向server發送其他消息。
2 OPTIONS可以再任何時間發送。有的客戶端會定時向服務器發送OPTION消息。而服務器也可以通過是否定時收到OPTIONS消息來判斷客戶端是否在線。但并不是所有客戶端和服務器都這樣做。
Server給Client的響應消息的各個字段的含義：
A CSeq字段 請求的序號
客戶端的每一個請求都會被賦值一個序號。每個請求消息也會對應一個同樣序號的回應消息。
B Public字段 Server給出自己提供的方法的集合。
Client給Server的請求消息的各個字段含義：
A UserAgent字段 用戶標識不同公司或是不同的客戶端
該域用于用戶標識不同公司或是不同的客戶端。不同客戶端發出的消息中的這個域的內容都不大相同。有時會指明客戶端的版本號、型號等等。
Clinet------>Server: 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) Server------>Client: 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.2.2 DESCRIBE
DESCRIBE消息是由客戶端發送到服務器端，用于客戶端得到請求鏈接中指定的媒體文件的相關描述，一般是SDP信息。
Server把SDP放在RTSP的響應消息中發給Client。 SDP（Session Description Protocol）包含了會話的描述、媒體編碼類型、媒體的碼率等信息。對于流媒體服務而言，以下幾個域是在SDP中一定要包含的。
“a=control:” “a=range:” “a=rtpmap:” “a=fmtp:”
當一個錄像中即包含音頻又包含視頻時，會有多個上述結構。每個媒體描述以m開始。m行又稱媒體行，描述了發送方所支持的媒體類型等信息，需要詳細說明下。a行為媒體的屬性行，以屬性的名稱：屬性值的方式表示。
音頻的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行的格式：
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，為動態分配的。
Server給Client的響應消息的各個字段的含義：
A Content-Base字段 指明對某個媒體的描述信息
B Content-Typte字段 請求類型
C Content-Length字段 SDP的長度（因為這里的body中）
Client給Server的請求消息的各個字段含義：
A Accept字段 用于指定客戶端可以接受的媒體描述信息類型，此處為SDP信息。
2.2.3 SETUP
SETUP消息用于確定轉輸機制，建立RTSP會話。
注意：客戶端也可以在建立RTSP后再次發出一個SETUP請求為正在播放的媒體流改變傳輸參數，服務器可能同意這些參數。若不同意，會回應 "455 Method Not Valid In This State"。
Server給Client的響應消息的各個字段的含義：
A Transport字段 由服務器確認后的傳輸參數
Client給Server的請求消息的各個字段含義：
A Transport字段 客戶端可接受的數據傳輸參數
如果該請求不包含SessionID，則服務器會產生一個SessionID。
例子1：使用RTP over UDP方式
Client-------------->Server: 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 Server-------------->Client: 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 //服務器端所指定的傳輸參數 這里要注意：RTP用偶數端口，RTCP為相鄰的奇數端口 Session: 54DAFD56;timeout=65 //SessionID
例子2: 使用RTP over TCP方式
CLient--------------->Server: request 消息 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 SETUP命令的Transport字段為RTP/AVP/TCP，同時多了一個interleaved=0-1字段。 由于RTP over TCP將RTP包和RTCP包發至同一個TCP端口， 因此使用interleaved的值來區分到底是RTP還是RTCP包。I nterleaved=0表示RTP包，interleaved=1表示RTCP包。 Server--------------->Client：response 消息 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
2.2.4 PLAY
PLAY方法通知服務器按照SETUP中指定的機制開始傳送數據。服務器會從PLAY消息指定范圍的開始時間開始傳送數據，直到該范圍結束。
注意：服務器可能會將PLAY請求放到隊列中，后一個PLAY請求需要等待前一個PLAY請求完成才能得到執行。
Client給Server的請求消息的各個字段含義：
A Range字段 指定了播放開始的時間。
如果在這個指定時間后收到消息，那么播放立即開始。不含Range頭的PLAY請求也是合法的，此時將從媒體流開始位置播放，直到媒體流被暫停。如果媒體流通過PAUSE暫停，媒體流傳輸將在暫停點繼續傳輸。如果媒體流正在播放，那么該PLAY請求將不起作用。客戶端可以利用此來測試服務器是否存活。
例子：
Client----------->Server: 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- / /指定開始播放的時間 Server----------->Client: 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時間戳
2.2.5 PAUSE
PAUSE消息通知服務器暫停流傳輸的傳輸。
如果請求URL中指定了具體的媒體流，那么只有該媒體流的播放被暫停。可以指定僅暫停音頻，此后的播放將會靜音。
如果請求URL指定了一組流，那么在該組中的所有流的傳輸將被暫停。
注意：服務器有可能不支持PAUSE消息。例如，實時流就有可能不支持暫停。當一個服務器不支持某一個消息時，會回應給客戶端“501 Not Implemented”。
Client給Server的請求消息的各個字段含義：
A Range字段（可選） 用來指定媒體流暫停的時間點，稱之為暫停點。
這里的Range頭必須包含一個精確的值，而不是一個時間范圍。如果Range頭指定了一個時間超出了PLAY請求的范圍，服務器將將返回"457 Invalid Range" 。如果Range頭缺失，那么在收到暫停消息后媒體流傳輸立即暫停，并將暫停點設置成當前播放時間。
2.2.6 TEARDOWN
TEARDOWN請求終止了給定URL的媒體流傳輸，并釋放了與該媒體流相關的資源。
3 RTP、RTCP協議
3.1 RTP協議
1 RTP概述
RTP是實時傳輸協議（Real-Time Transport Protocol）的縮寫，是針對多媒體數據流的實時傳輸協議。
通常建立在UDP協議之上，也可以建立在TCP協議之上。有人將其歸為應用層協議，也有人將其歸為傳輸層協議，這都是可以的。
Rtp協議提供了時間戳和序列號。發送端在采樣時設置時間戳，接收端收到后，會按照時間戳依次播放。RTP本身只保證實時數據的傳輸，并不能為按順序傳送的數據包提供可靠的傳送機制，也不提供流量和擁塞控制，它依靠RTCP來提供這些服務。
2 RTP報文格式
版本號（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包的源。
3.2 RTCP協議
1 RTCP協議概述
RTCP是實時控制協議（Real-Time Control Protocol）的縮寫。RTCP通常與RTP配合使用，用以管理傳輸質量在當前進程之間的交換信息。
在RTP會話期間，各參與者周期性的傳送RTCP包，RTCP包中包含已發送數據包的數量、丟失的數據包的數量等統計資料。服務器可以利用這些信息動態的改變傳輸速率，甚至改變有效載荷的類型。
RTP和RTCP配合使用，可以有效且以最小的開銷達到最佳傳輸效率，非常適合傳送實時流。
2 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協議的擴展。
3 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包到發送本包的延遲
4 音視頻同步
傳送的音頻和視頻流位于兩個不同的RTP會話中，每個RTP包均有自己的時間戳，同時RTCP包中的NPT字段（Network Protocol Time）保存的絕對時間可以用來將音視頻映射到同一時間軸上，從而實現音視頻同步。