整體而言，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
可以看到，首先是 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 請求的響應，其具體內容如下：
客戶端首先向伺服器傳送了一個方法為 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 號包：
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 包的收發，併發送了一個 SETUP 請求用於建立媒體會話，如第 119 號包：
客戶通過 SETUP 請求的 Transport 頭部，將為 RTP 和 RTCP 選擇的埠、協議及通訊方式（UDP 單播還是多播）傳送給客戶端。這裡可以看到，客戶端選擇了 19008 和 19009 兩個埠來進行 RTP 和 RTCP 包的收發。
隨後伺服器對 SETUP 請求做出了響應，如第121 號包：
隨後客戶端向伺服器傳送了一個 PLAY 請求，來啟動播放，如第 124 號包：
PLAY 請求中會攜帶從前面的 SETUP 請求的響應獲得的會話識別符號。
隨後伺服器向客戶端傳送了一個 RTCP 包，如第 125 號包：
至此媒體會話最終建立完成，後面就可以開始通過 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 包結束會話。
沒有留言:
張貼留言