整體而言，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 requirementDESCRIBE C->S P,S recommendedANNOUNCE C->S, S->C P,S optionalGET_PARAMETER C->S, S->C P,S optionalOPTIONS C->S, S->C P,S required(S->C: optional)PAUSE C->S P,S recommendedPLAY C->S P,S requiredRECORD C->S P,S optionalREDIRECT S->C P,S optionalSETUP C->S S requiredSET_PARAMETER C->S, S->C P,S optionalTEARDOWN 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 號包：

總結一下這個過程：
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 源碼分析：與客戶端的交互

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的Wireshark 抓包分析 RTSP/RTP/RTCP 基本工作过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。