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 包，將看到類似下面這樣的包序列：

可以看到，首先是 RTSP 數據的交互，建立媒體傳輸會話，隨後開始通過 RTP/RTCP 傳輸數據。RTSP 協議在制定時較多地參考了 HTTP/1.1 協議，甚至許多內容與 HTTP/1.1 完全相同。與 HTTP/1.1 類似，RTSP 客戶端首先向服務器發送請求，隨後服務器發回響應，以此實現數據的交互。RTSP 同樣定義了一系列方法，表示對 URI 標識的資源所執行的操作。RTSP 具體定義的方法有如下這些：

      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 號包：

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 號包內容如下：

127 號包

128 號包

它們的內容與 H.264 視頻文件的前兩個 NALU 的內容完全吻合，即 live555 通過兩個 RTP 包發送了前兩個 NALU SPS 和 PPS。

從 RTSP 的 OPTIONS 請求開始，到首個視頻數據 NALU 開始發送，經過了總共大概 102 ms 的時間，媒體會話完全建立完成。

視頻數據經過一端時間的穩定傳輸，最終以服務器向客戶端發送的一個 RTCP BYE 包而結束，如第 6451 號包：

總結一下這個過程：

1. 客戶端首先向服務器發送一個方法爲 OPTIONS 的請求，瞭解服務器爲 URL 提供了哪些方法的支持。
2. 服務器將該 URL 支持的方法的列表返回給客戶端。
3. 客戶端向服務器發送了一個 DESCRIBE 請求，提取由所請求的 URL 標識的表示或媒體對象的描述信息。
4. 服務器通過 SDP 包，告知流媒體數據傳輸所用的協議，以及流媒體本身的一些信息。
5. 客戶端在收到服務器發來的 SDP 包之後，會選擇兩個端口，分別用於 RTP 和 RTCP 包的收發，併發送了一個 SETUP 請求用於建立媒體會話。
6. 服務器發回 SETUP 響應，把它爲媒體會話開啓的用於收發 RTP、RTCP 包的端口，會話的標識符，超時時間等信息通知給客戶端。
7. 客戶端分別在 RTP 和 RTCP 的端口上，向服務器的 RTP 和 RTCP 端口上發送了兩個包。
8. 客戶端向服務器發送一個 PLAY 請求，來啓動播放。
9. 服務器向客戶端發送一個 RTCP 包，把 RTP 時間戳，服務器的 SSRC，服務器的 CNAME 等信息發送給客戶端。
10. 服務器發送 PLAY 請求的響應，其中包含 RTP 包的初始序列號，RTP 時間等重要信息。至此媒體會話最終建立完成。
11. 通過 RTP/RTCP 發送流媒體數據。
12. 服務器向客戶端發送一個 RTCP BYE 包結束會話。

live555 源碼分析系列文章

live555 源碼分析：簡介
live555 源碼分析：基礎設施
live555 源碼分析：MediaSever
Wireshark 抓包分析 RTSP/RTP/RTCP 基本工作過程
live555 源碼分析：RTSPServer
live555 源碼分析： DESCRIBE 的處理
live555 源碼分析： SETUP 的處理
live555 源碼分析： PLAY 的處理
live555 源碼分析：RTSPServer 組件結構
live555 源碼分析：ServerMediaSession
live555 源碼分析：子會話 SDP 行生成
live555 源碼分析：子會話 SETUP
live555 源碼分析：播放啓動

小禮

作者：hanpfei
鏈接：https://www.jianshu.com/p/409f20b7e813
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯繫作者獲得授權並註明出處。