Wireshark 抓包分析 RTSP/RTP/RTCP 基本工作過程
整體而言，RTSP 通常工作於可靠的傳輸協議 TCP 之上，就像 HTTP 那樣，用於發起/結束流媒體傳輸，交換流媒體元資訊。RTP 通常工作於 UDP 之上，用於傳輸實際的流媒體資料，其中的載荷格式因具體流媒體型別的不同而不同，通常有專門的 RFC 規範對其進行定義，如 H.264 編碼格式視訊資料的載荷格式在 RFC 6184, RTP Payload Format for H.264 Video 中定義，其它流媒體資料型別有其它的規範進行定義。RTCP 同樣通常工作於 UDP 之上，用於對 RTP 進行控制，流媒體資料的收發端在傳輸過程中相互發送 RTCP 資料包，將自己這一端檢測到的 QoS 等資訊傳遞給對方，使用 RTP/RTCP 協議的應用程式，利用這些資訊對收發過程進行控制。RTP 和 RTCP 在傳輸過程中，工作於不同的埠上。
我們通過 Wireshark 抓包來看一下 RTSP/RTP/RTCP 的基本工作過程。我們啟動 live555MediaServer，其工作目錄下存有一些流媒體檔案，其中包括 H.264 原始碼流格式的檔案 raw_h264_stream.264。啟動 Wireshark 抓包。然後通過 ffplay 請求 live555MediaServer 並播放 raw_h264_stream.264：
$ ffplay rtsp://10.240.248.20:8554/raw_h264_stream.264其中 URI 中的 IP 地址為 live555MediaServer 執行的主機的 IP 地址，埠號為其採用的埠號。在 Wireshark 中，通過
Display Filter 過濾僅顯示 RTSP/RTP/RTCP 包，將看到類似下面這樣的包序列：
method direction object requirement DESCRIBE C->S P,S recommended ANNOUNCE C->S, S->C P,S optional GET_PARAMETER C->S, S->C P,S optional OPTIONS C->S, S->C P,S required (S->C: optional) PAUSE C->S P,S recommended PLAY C->S P,S required RECORD C->S P,S optional REDIRECT S->C P,S optional SETUP C->S S required SET_PARAMETER C->S, S->C P,S optional TEARDOWN C->S P,S required
回到 Wireshark 抓的包來看 RTSP/RTP/RTCP 的基本工作過程。
客戶端首先向伺服器傳送了一個方法為 OPTIONS 的請求，如第 112 號包，該請求內容如上圖所示，攜帶有 URL，RTSP 版本號，User-Agent 等資訊。RTSP 的 OPTIONS 與 HTTP/1.1 的對應方法具有相同的語義，具體在 HTTP/1.1 規範 RFC 2616 的 9.2 節 中定義。客戶端通過這個方法瞭解伺服器為 URL 提供了哪些方法的支援。
第 112 號包是 RTSP 伺服器對客戶端的 OPTIONS 請求的響應，其具體內容如下：
伺服器將該 URL 支援的方法的列表返回給客戶端。對於這裡的情況，也就是 OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER。
然後客戶端向伺服器傳送了一個 DESCRIBE 請求，即第 116 號包，該請求內容如下：
DESCRIBE 方法用於客戶端提取由所請求的 URL 標識的表示或媒體物件的描述資訊。它可以使用 Accept 頭部指定客戶端理解的描述格式。伺服器則用所請求的資源的描述作為響應。DESCRIBE 應答響應對構成RTSP的媒體初始化階段。
對於這裡的情況，DESCRIBE 請求的 Accept 頭部值為 application/sdp，表示客戶端希望收到 SDP 格式的媒體表示。
伺服器以一個 RTSP/SDP 包作為響應，如圖中的第 118 號包：
這個 SDP 包實際內容的文字格式如下：
v=0
o=- 1504179985128927 1 IN IP4 10.240.248.20
s=H.264 Video, streamed by the LIVE555 Media Server
i=raw_h264_stream.264
t=0 0
a=tool:LIVE555 Streaming Media v2017.07.18
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:raw_h264_stream.264
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=42802A;sprop-parameter-sets=Z0KAKtoBEA8eXlIKDAoNoUJq,aM4G4g==
a=control:track1
伺服器通過 SDP 包，告知流媒體資料傳輸所用的協議，以及流媒體本身的一些資訊，這裡所用的協議為 RTP/RTCP。通常的 SDP 檔案中，“Media Description” 選項，即以 “m” 開頭的那一行中會指定，會指定客戶端接收 RTP 包所需要監聽的埠，但在這裡這個埠為 0。傳輸中客戶端和伺服器所選擇的用於 RTP/RTCP 包收發的埠將在後面的 RTSP 請求中交換。
客戶端在收到伺服器發來的 SDP 包之後，會選擇兩個埠，分別用於 RTP 和 RTCP 包的收發，併發送了一個 SETUP 請求用於建立媒體會話，如第 119 號包：
客戶通過 SETUP 請求的 Transport 頭部，將為 RTP 和 RTCP 選擇的埠、協議及通訊方式（UDP 單播還是多播）傳送給客戶端。這裡可以看到，客戶端選擇了 19008 和 19009 兩個埠來進行 RTP 和 RTCP 包的收發。
隨後伺服器對 SETUP 請求做出了響應，如第121 號包：
伺服器通過這個響應，把它為媒體會話開啟的用於收發 RTP、RTCP 包的埠，會話的識別符號，超時時間等資訊通知給客戶端。隨後，客戶端分別在 RTP 和 RTCP 的埠上，向伺服器的 RTP 和 RTCP 埠上傳送了兩個包，如第 122 號包和第 123 號包：
這兩個包中攜帶的都是無意義的資料。傳送它們的目的，大概主要是為了 NAT 穿牆。
隨後客戶端向伺服器傳送了一個 PLAY 請求，來啟動播放，如第 124 號包：
PLAY 請求中會攜帶從前面的 SETUP 請求的響應獲得的會話識別符號。
隨後伺服器向客戶端傳送了一個 RTCP 包，如第 125 號包：
在這個包中，伺服器把 RTP 時間戳，伺服器的 SSRC，伺服器的 CNAME 等資訊傳送給客戶端。之後，伺服器傳送了 PLAY 請求的響應：
在這個包中，傳送的 RTP 包的初始序列號，RTP 時間等重要資訊被髮送給客戶端。
至此媒體會話最終建立完成，後面就可以開始通過 RTP 傳輸視訊資料了。請求的 H.264 視訊檔案的前兩個 NALU，即 SPS 和 PPS 如下所示：
00000000 00 00 00 01 67 42 80 2A DA 01 10 0F 1E 5E 52 0A ....gB.*.....^R.
00000010 0C 0A 0D A1 42 6A 00 00 00 01 68 CE 06 E2開始的兩個 RTP 包，即第 127 號包和第 128 號包內容如下：
它們的內容與 H.264 視訊檔案的前兩個 NALU 的內容完全吻合，即 live555 通過兩個 RTP 包傳送了前兩個 NALU SPS 和 PPS。
從 RTSP 的 OPTIONS 請求開始，到首個視訊資料 NALU 開始傳送，經過了總共大概 102 ms 的時間，媒體會話完全建立完成。
視訊資料經過一端時間的穩定傳輸，最終以伺服器向客戶端傳送的一個 RTCP BYE 包而結束，如第 6451 號包：
總結一下這個過程：
- 客戶端首先向伺服器傳送一個方法為
OPTIONS的請求，瞭解伺服器為 URL 提供了哪些方法的支援。 - 伺服器將該 URL 支援的方法的列表返回給客戶端。
- 客戶端向伺服器傳送了一個
DESCRIBE請求，提取由所請求的 URL 標識的表示或媒體物件的描述資訊。 - 伺服器通過 SDP 包，告知流媒體資料傳輸所用的協議，以及流媒體本身的一些資訊。
- 客戶端在收到伺服器發來的 SDP 包之後，會選擇兩個埠，分別用於 RTP 和 RTCP 包的收發，併發送了一個
SETUP請求用於建立媒體會話。 - 伺服器發回
SETUP響應，把它為媒體會話開啟的用於收發 RTP、RTCP 包的埠，會話的識別符號，超時時間等資訊通知給客戶端。 - 客戶端分別在 RTP 和 RTCP 的埠上，向伺服器的 RTP 和 RTCP 埠上傳送了兩個包。
- 客戶端向伺服器傳送一個
PLAY請求，來啟動播放。 - 伺服器向客戶端傳送一個 RTCP 包，把 RTP 時間戳，伺服器的 SSRC，伺服器的 CNAME 等資訊傳送給客戶端。
- 伺服器傳送
PLAY請求的響應，其中包含 RTP 包的初始序列號，RTP 時間等重要資訊。至此媒體會話最終建立完成。 - 通過 RTP/RTCP 傳送流媒體資料。
- 伺服器向客戶端傳送一個 RTCP BYE 包結束會話。
轉自-簡書-hanpfei