萬字詳解RTR RTSP SDP RTCP

1 RTSP
- 1.1 RTSP基本簡介
- 1.2 RSTP架構
- 1.3 重點內容分析
2 RTR
- 2.1 RTR簡介
- 2.2 RTP 封裝 H.264
- 2.3 RTP 解封裝 H.264
- 2.4 RTP封裝 AAC
- 2.5 RTP解封裝AAC
3 SDP
- 3.1 基礎概念
- 3.2 SDP協議示例解析
- 3.3 重點知識
4 RTCP
- 4.1 RTCP基礎概念
- 4.2 重點
5 總結

1 RTSP

1.1 RTSP基本簡介

一、RTSP 是什么？（定義與定位）
RTSP（Real Time Streaming Protocol）是一個應用層協議，用于控制流媒體的播放行為。
類比生活場景：如果把流媒體比作 “自來水”，RTSP 就像是 “水龍頭開關”，負責開啟 / 暫停 / 調節水流，但不負責 “運輸水”（數據傳輸由 RTP 負責）。
二、RTSP 的核心功能是什么？（四大控制命令）
RTSP 通過請求 - 響應模型實現以下操作：

建立會話（SETUP）
客戶端告訴服務器：“我要播放這個視頻，用 RTP/UDP 協議，我的接收端口是 5000-5001”。
服務器回應：“好的，我用 6000-6001 端口給你發數據，會話 ID 是 12345”。
播放控制（PLAY/PAUSE/TEARDOWN）
PLAY：開始傳輸媒體數據（通過 RTP）。
PAUSE：暫停播放，但保留會話。
TEARDOWN：關閉會話，釋放資源。
查詢信息（DESCRIBE）
客戶端問：“這個視頻的格式、編碼是什么？”
服務器返回SDP 描述（如 H.264 編碼、90000Hz 采樣率）。
參數設置（GET/SET PARAMETER）
動態調整播放參數（如音量、碼率）。

** HTTP 協議的核心區別**

對比維度	RTSP	HTTP
協議方法	新增了 DESCRIBE、PLAY、SETUP、ANNOUNCE、RECORD 等方法	主要有 GET、POST、PUT 等方法
狀態管理	是有狀態協議，每個會話都有 session 概念	屬于無狀態協議
請求發起方	客戶端和服務器端都能發送 Request 請求	只有客戶端可以發送 Request 請求
數據傳輸方式	載荷數據一般通過帶外方式傳送（除交織情況），借助 RTP 協議在不同通道傳輸	載荷數據通過帶內方式傳送，例如請求的網頁數據在回應消息體中攜帶
字符編碼	使用 ISO 10646（UTF - 8），以適應 HTML 國際化需求	采用 ISO 8859 - 1 編碼
URI 請求	請求時包含絕對 URI	由于歷史兼容性問題，請求中只包含絕對路徑，主機名放在單獨標題域

1.2 RSTP架構

RTSP 分為兩種模式

UDP 模式（更常見）
RTSP 控制信令走 TCP（端口 554），保證可靠性。
RTP/RTCP 數據走 UDP（隨機端口，如客戶端 5000/5001，服務器 6000/6001）。
優勢：低延遲，適合直播。
缺點：丟包風險高，需 RTCP 補償。
TCP 模式（隧道模式）
所有數據（RTSP+RTP+RTCP）都走 TCP 端口 554。
優勢：穿透防火墻能力強（僅需開放一個端口）。
缺點：TCP 擁塞控制可能增加延遲。

深入剖析RTSP拉流客戶端與服務器的完整交互流程

一、建立TCP連接（握手階段）
目標：客戶端與服務器建立可靠的控制通道（默認TCP 554端口）。

客戶端發起TCP連接

Client → Server: SYN（源端口隨機，目標端口554）
Server → Client: SYN+ACK
Client → Server: ACK

關鍵點：

此連接僅用于傳輸RTSP控制命令，不傳輸媒體數據。
后續所有RTSP請求/響應都通過此TCP通道發送。

二、OPTIONS請求（能力探測）
目標：客戶端詢問服務器支持哪些RTSP方法。

2.1 客戶端發送OPTIONS請求

OPTIONS rtsp://example.com/stream.sdp RTSP/1.0
CSeq: 1
User-Agent: VLC/3.0.18 LibVLC/3.0.18

字段解析：

CSeq：請求序列號，用于匹配響應。
User-Agent：客戶端標識（如VLC播放器）。

2.2 服務器響應支持的方法

RTSP/1.0 200 OK
CSeq: 1
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER

關鍵點：

Public字段列出服務器支持的RTSP方法（如PLAY、PAUSE）。
客戶端后續只能使用服務器明確支持的方法。

三、DESCRIBE請求（獲取媒體描述）
目標：獲取流媒體的技術參數（編碼格式、時長等），以SDP格式返回。

3.1 客戶端發送DESCRIBE請求

DESCRIBE rtsp://example.com/stream.sdp RTSP/1.0
CSeq: 2
Accept: application/sdp

字段解析：

Accept：指定客戶端期望的響應格式（此處為SDP）。

3.2 服務器返回SDP描述

RTSP/1.0 200 OK
CSeq: 2
Content-Type: application/sdp
Content-Length: 468v=0
o=StreamingServer 3832474523 3832474524 IN IP4 192.168.1.100
s=Media Server
t=0 0
a=control:*
m=video 0 RTP/AVP 96  # 視頻媒體行
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=42001F;sprop-parameter-sets=...
a=control:trackID=0
m=audio 0 RTP/AVP 97  # 音頻媒體行
a=rtpmap:97 MPEG4-GENERIC/44100/2
a=fmtp:97 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1408
a=control:trackID=1

SDP關鍵信息：

m=video/m=audio：媒體類型（視頻/音頻）。
rtpmap：載荷類型與編碼映射（如96對應H.264）。
fmtp：編碼參數（如H.264的profile-level-id）。
control：媒體流的控制URL（如trackID=0）。

四、SETUP請求（建立傳輸通道）
目標：為每個媒體流（視頻/音頻）配置傳輸參數（協議、端口）。

4.1 客戶端設置視頻流傳輸

SETUP rtsp://example.com/stream.sdp/trackID=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=5000-5001
Session: 12345678

字段解析：

Transport：指定傳輸協議（RTP/AVP）、網絡類型（unicast）和客戶端端口（5000收RTP，5001收RTCP）。
Session：會話ID，由服務器在后續響應中分配。

4.2 服務器確認并分配端口

RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP;unicast;client_port=5000-5001;server_port=6000-6001
Session: 12345678;timeout=60

關鍵點：

服務器分配自己的端口（6000發RTP，6001發RTCP）。
timeout=60：會話超時時間（60秒內無活動則關閉）。

4.3 客戶端設置音頻流傳輸（類似視頻流程）

SETUP rtsp://example.com/stream.sdp/trackID=1 RTSP/1.0
CSeq: 4
Transport: RTP/AVP;unicast;client_port=5002-5003
Session: 12345678

五、PLAY請求（開始播放）
目標：命令服務器開始通過RTP發送媒體數據。

5.1 客戶端請求播放

PLAY rtsp://example.com/stream.sdp RTSP/1.0
CSeq: 5
Session: 12345678
Range: npt=0.000-  # 從0秒開始播放

字段解析：

Range：播放范圍（npt=0.000-表示從頭開始）。

5.2 服務器響應并提供RTP信息

RTSP/1.0 200 OK
CSeq: 5
Session: 12345678
RTP-Info: url=rtsp://example.com/stream.sdp/trackID=0;seq=12345;rtptime=67890,url=rtsp://example.com/stream.sdp/trackID=1;seq=20000;rtptime=90000

關鍵點：

seq：初始RTP序列號（用于排序）。
rtptime：初始RTP時間戳（用于同步音視頻）。

六、媒體數據傳輸（RTP/RTCP）
目標：通過UDP傳輸音視頻數據，并通過RTCP反饋質量。

6.1 RTP視頻數據包（UDP 6000 → 5000）

[RTP Header]- Version: 2- Payload Type: 96 (H.264)- Sequence Number: 12345- Timestamp: 67890- SSRC: 0x1234ABCD
[RTP Payload]- H.264 NAL Unit (e.g., IDR frame, P frame)

6.2 RTCP接收報告（UDP 5001 → 6001）

[RTCP Header]- Packet Type: 201 (Receiver Report)- SSRC: 0xEF012345 (客戶端標識)
[Report Block]- SSRC of sender: 0x1234ABCD (對應RTP發送方)- Fraction lost: 0.02 (2%丟包率)- Cumulative packets lost: 5- Interarrival jitter: 32ms

技術細節：

RTP：通過序列號重組數據包，時間戳實現音視頻同步。
RTCP：每5秒左右發送一次，發送方根據丟包率調整碼率。

七、控制命令與會話終止
7.1 PAUSE請求（暫停播放）

PAUSE rtsp://example.com/stream.sdp RTSP/1.0
CSeq: 6
Session: 12345678

RTSP/1.0 200 OK
CSeq: 6
Session: 12345678

關鍵點：暫停后，服務器保留會話狀態，可通過PLAY恢復。

7.2 TEARDOWN請求（終止會話）

TEARDOWN rtsp://example.com/stream.sdp RTSP/1.0
CSeq: 7
Session: 12345678

RTSP/1.0 200 OK
CSeq: 7
Session: 12345678; timeout=0

關鍵點：服務器關閉RTP/RTCP端口，釋放資源。

拉流交互流程總結圖

Client                          Server|                                |├─TCP Connect (554)────────────?||                                |├─OPTIONS──────────────────────?||?───────────200 OK─────────────┤|                                |├─DESCRIBE─────────────────────?||?───────200 OK (SDP)───────────┤|                                |├─SETUP (video)────────────────?||?───────200 OK (port 6000)─────┤|                                |├─SETUP (audio)────────────────?||?───────200 OK (port 6002)─────┤|                                |├─PLAY─────────────────────────?||?───────200 OK (RTP Info)──────┤|                                |▼                                ▼
[RTP Data (UDP 6000→5000)]        |
[RTCP Feedback (UDP 5001→6001)]   ||                                |├─PAUSE/PLAY/TEARDOWN──────────?||?───────────200 OK─────────────┤

推流流程（Client → Server 發送數據）
- 第一步：OPTION：客戶端向服務器查詢可用方法，服務器在響應的 public 頭字段中返回所有可用方法，如 OPTIONS、DESCRIBE、SETUP 等。
- 第二步：ANNOUNCE：客戶端向服務器發送媒體描述信息（SDP 格式），服務器響應并返回 Session ID。
- 第三步：SETUP：客戶端通過 Transport 頭字段列出可接受的傳輸選項（如 RTP/UDP 端口），請求建立會話，服務器返回選定的傳輸選項和 Session ID。
- 第四步：RECORD：客戶端請求服務器開始傳輸數據。
- 第五步：RTP 數據推送：客戶端通過 RTP 協議向服務器發送音視頻數據，同時可能伴隨 RTCP 控制包。
- 第六步：TEARDOWN：客戶端請求關閉會話，服務器確認響應。

1.3 重點內容分析

1. 基礎概念類

問題 1：RTSP 的主要作用是什么？與 RTP/RTCP 的關系是什么？
- 回答：RTSP 主要用于建立和控制媒體流會話，像 OPTION、SETUP、PLAY 等方法用于協商傳輸參數，而媒體數據實際通過 RTP 傳輸，RTCP 則用于監控傳輸質量和同步。
問題 2：Session ID 和 SSRC 的區別是什么？分別由誰生成？
- 回答：Session ID 是會話標識，由服務器在 ANNOUNCE 或 SETUP 響應中生成，客戶端后續請求需攜帶該 ID；SSRC（同步源標識符）用于標識 RTP 流的來源，推流時由客戶端自定義，拉流時由服務器在 SETUP 響應中返回。
問題 3：Transport 頭字段的作用是什么？常見參數有哪些？
- 回答：該字段用于協商傳輸協議和端口，客戶端在請求中列出可選方案（如 RTP/UDP、客戶端端口范圍），服務器在響應中選定實際參數（如服務器端口、SSRC）。常見參數包括協議類型（RTP/AVP）、傳輸方式（unicast/multicast）、端口范圍（client_port/server_port）、模式（record/play）等。

2. 流程與協議對比類

問題 1：推流和拉流的核心流程差異有哪些？
- 回答：
  - 第二步不同：推流使用 ANNOUNCE 發送媒體描述，拉流使用 DESCRIBE 獲取媒體描述。
  - 第四步不同：推流通過 RECORD 請求發送數據，拉流通過 PLAY 請求接收數據。
  - RTP 方向不同：推流是客戶端到服務器，拉流是服務器到客戶端。
問題 2：RTSP 為什么被稱為“帶外控制協議”？
- 回答：因為 RTSP 的控制信令（如 SETUP、PLAY）和媒體數據（RTP 流）通過不同通道傳輸，控制信令通常在 RTSP 連接中傳輸，媒體數據通過獨立的 RTP/RTCP 通道傳輸，所以是“帶外”方式。
問題 3：RTSP 能否基于 TCP 傳輸？實際應用中如何選擇傳輸協議？
- 回答：RTSP 協議本身可基于 TCP 或 UDP 傳輸，默認使用 UDP（效率高、適合實時流）。若網絡環境復雜（如防火墻限制），可改用 TCP 傳輸控制信令和媒體數據，但會增加延遲。文檔中推流和拉流示例均使用 UDP（Transport: RTP/AVP/UDP）。

2 RTR

2.1 RTR簡介

一、RTP協議的定位與核心作用
RTP（Real-Time Transport Protocol）是專為實時媒體流傳輸設計的網絡傳輸協議，屬于OSI 模型的傳輸層，但通常與應用層結合使用。其核心作用包括：

媒體數據封裝：將音頻、視頻等實時數據封裝為適合網絡傳輸的數據包。
時序控制：通過序列號和時間戳確保數據包按順序重組和媒體同步。
多源標識：支持多播和單播場景，標識不同數據來源（如多個攝像頭或麥克風）。

RTP不保證傳輸可靠性，也不提供流量控制或擁塞控制，通常與 UDP 協議結合使用，利用 UDP 的低延遲特性實現快速傳輸**，而可靠性由上層協議（如 RTCP）補償。**

二、RTP報文格式與關鍵字段解析
RTP報文由 12字節固定報頭 和 有效載荷 組成，報頭結構如下：

字段	長度	功能描述
版本號（V）	2位	當前協議版本為2，用于協議兼容性判斷。
填充標志（P）	1位	若P=1，報文尾部包含填充字節，非有效載荷內容，用于對齊數據。
擴展標志（X）	1位	若X=1，報頭后跟隨一個擴展報頭，用于自定義協議擴展。
CSRC計數器（CC）	4位	指示CSRC標識符的數量（0~15），用于標識混合流中的原始信源。
標記位（M）	1位	含義由具體應用定義，如視頻中標識幀結束（I幀），音頻中標識幀開始。
有效載荷類型（PT）	7位	標識載荷數據格式（如H.264=96，AAC=101），接收方據此選擇解碼器。
序列號	16位	每發送一個報文遞增1，用于檢測丟包和重組數據順序。
時間戳（Timestamp）	32位	反映采樣時刻，單位為時鐘頻率（如90kHz），用于計算延遲和同步音視頻。
同步信源（SSRC）	32位	唯一標識數據源（如攝像頭、麥克風），隨機生成，同一會話中不重復。
特約信源（CSRC）	32位×n	混合流場景中，記錄原始信源的SSRC列表（n≤15），由混合器插入。

示例代碼結構（C語言）：

typedef struct _rtp_header_t {uint32_t v:2;    // 版本號uint32_t p:1;    // 填充標志uint32_t x:1;    // 擴展標志uint32_t cc:4;   // CSRC計數器uint32_t m:1;    // 標記位uint32_t pt:7;   // 有效載荷類型uint32_t seq:16; // 序列號uint32_t timestamp; // 時間戳uint32_t ssrc;    // 同步信源
} rtp_header_t;

三、同步信源（SSRC）與特約信源（CSRC）的區別

同步信源（SSRC）
- 定義：直接產生媒體流的信源，如麥克風、攝像機或RTP混合器本身。
- 作用：接收方通過SSRC區分不同數據源，同一會話中每個SSRC唯一。
- 示例：視頻會議中，每個參會者的攝像頭對應一個獨立的SSRC。
特約信源（CSRC）
- 定義：當混合器（如視頻會議服務器）合并多個信源的流時，將原始信源的SSRC記錄為CSRC，混合器自身的SSRC作為新流的標識。
- 作用：接收方通過CSRC表了解混合流的來源組成。
- 示例：三路音頻流（SSRC1、SSRC2、SSRC3）經混合器生成新流（SSRC4），混合后的RTP包中CSRC字段記錄SSRC1-3，便于接收方識別原始發言者。

混合流程示意圖：

SSRC1（音頻1） ──?
SSRC2（音頻2） ──? 混合器 ──? 新流（SSRC4，CSRC=[SSRC1, SSRC2]）
SSRC3（視頻）  ──?

四、RTP的工作流程（發送端與接收端）

發送端處理
- 上層應用（如編碼器）將媒體數據（如H.264幀、AAC音頻塊）傳遞給RTP模塊。
- RTP模塊添加報頭（設置序列號、時間戳、SSRC等），封裝為RTP報文。
- 通過Socket接口選擇UDP協議發送，目標端口由傳輸協議（如RTSP）協商確定。
接收端處理
- 通過Socket接收RTP報文，分離報頭與載荷。
- 解析報頭：
  - 用序列號檢測丟包，重組亂序包。
  - 用時間戳計算延遲抖動，同步音視頻流。
  - 根據SSRC/CSRC區分數據源，分發至不同解碼器。
- 將載荷數據傳遞給上層應用（如解碼器）進行后續處理。

五、RTP的典型應用場景

視頻會議（如WebRTC）
- 每個參會者的音視頻流分配獨立SSRC，混合器通過CSRC記錄多源信息。
- 時間戳用于唇音同步，序列號處理網絡抖動導致的包亂序。
實時直播（如RTSP/RTP流）
- 服務器通過RTP發送H.264視頻和AAC音頻，客戶端根據PT字段選擇解碼器。
- RTCP周期性反饋丟包率，發送端動態調整碼率（如降低分辨率）。
監控系統
- 多個攝像頭的流通過不同SSRC標識，接收端按源分離畫面。
- 支持多播傳輸，減少服務器負載。

六、RTP與RTCP的協同工作
RTP負責數據傳輸，而 RTCP（RTP控制協議） 負責監控傳輸質量并反饋：

RTCP功能：
- 發送端發送 SR（發送報告），包含已發送包數、字節數、時間戳等。
- 接收端發送 RR（接收報告），包含丟包率、抖動、最后接收時間等。
- 通過SSRC/CSRC關聯RTP流與參與者身份（如用戶名）。
協同機制：
- 發送端根據RR調整編碼參數（如降低碼率應對高丟包）。
- 接收端利用SR中的時間戳實現跨流同步（如音頻與視頻對齊）。

總結：RTP的核心價值
RTP通過輕量化報頭設計和時序控制機制，在實時性與可靠性之間取得平衡，成為音視頻流媒體的基礎協議。其核心優勢包括：

多源支持：SSRC/CSRC靈活標識單播、多播和混合流場景的數據源。
低延遲傳輸：依賴UDP，適合實時互動場景（如直播、視頻會議）。
擴展性：通過擴展標志（X）和載荷類型（PT）適配多種編碼格式（H.264、VP9、Opus等）。

理解RTP報文結構與工作流程，是深入學習WebRTC、RTMP、RTSP等上層協議的基礎。

2.2 RTP 封裝 H.264

一、封包核心目標與前提條件
RTP 封裝 H.264 的目標是將 H.264 編碼后的 NALU 單元（Network Abstraction Layer Unit）按照 RTP 協議規范進行打包，以便在網絡中傳輸。

前提條件：
已獲取 H.264 編碼器輸出的原始 NALU 流（包含 SPS/PPS、IDR 幀、P 幀等）。
確定 RTP 載荷類型（PT），通常為 96-127 之間的數值（需與接收端協商一致）。

二、H.264 NALU 分類與特性
H.264 的 NALU 按類型可分為三大類，封裝時需區別對待：

1. 關鍵參數集（Type=7/8）：

SPS（序列參數集）：包含編碼級別、分辨率、幀率等全局參數。
PPS（圖像參數集）：包含熵編碼模式、片組等圖像級參數。
處理方式：通常單獨封裝為 RTP 包，或與 SEI（補充增強信息）聚合封裝。

2. 視頻編碼數據（Type=1/5）

IDR 幀（Type=5）：關鍵幀，解碼必須從 IDR 幀開始。
P 幀 / B 幀（Type=1）：預測幀，依賴前面的幀解碼。
處理方式：根據大小選擇單 NALU 模式或分片模式。

3. 輔助數據（Type=6）

SEI（補充增強信息）：包含時間碼、用戶數據等輔助信息。
處理方式：通常與 SPS/PPS 聚合封裝，或單獨封裝。

三、RTP 封裝模式選擇

1. 單 NALU 模式（Single NAL Unit）
適用場景：NALU 長度 ≤ MTU（通常 1460 字節，MTU=1500-IP 頭 20-UDP 頭 8）。

RTP Header (12字節) + NALU Header (1字節) + NALU Data

關鍵步驟：

創建 RTP 報頭，設置序列號（遞增）、時間戳（基于采樣時刻）、SSRC（隨機生成）。
將完整 NALU 作為 RTP 載荷(數據包)，直接添加到報頭后。
設置 RTP 標記位（M）：若為 IDR 幀的最后一個分片，M=1；否則 M=0。

2. 分片模式（Fragmentation Unit, FU）
適用場景：NALU 長度 > MTU，需拆分為多個 RTP 包。
分片類型：

FU-A（Type=28）：無依賴的分片，常用。
FU-B（Type=29）：帶時間戳的分片，適用于低延遲場景。

FU-A 封裝格式：

RTP Header + FU Indicator (1字節) + FU Header (1字節) + NALU Fragment

FU Indicator：
前 3 位：NALU 頭的 F（禁止位）和 NRI（重要性指示）。
后 5 位：固定值 28（表示 FU-A 類型）。
FU Header：
第 1 位（S）：起始位，1 表示當前是 NALU 的第一個分片。
第 2 位（E）：結束位，1 表示當前是 NALU 的最后一個分片。
第 3 位（R）：保留位，必須為 0。
后 5 位：原始 NALU 的 Type 字段（如 5 表示 IDR 幀）。

分片步驟：

計算可承載的最大數據長度（MaxSize = MTU - RTP 頭 - FU Indicator - FU Header）。
首個分片（S=1）：
FU Indicator = (NALU[0] & 0xE0) | 28
FU Header = 0x80 | (NALU[0] & 0x1F)
載荷 = FU Indicator + FU Header + NALU Data [1:MaxSize]
中間分片（S=0, E=0）：
FU Indicator = (NALU[0] & 0xE0) | 28
FU Header = 0x00 | (NALU[0] & 0x1F)
載荷 = FU Indicator + FU Header + NALU Data [偏移量：偏移量 + MaxSize]
最后分片（E=1）：
FU Indicator = (NALU[0] & 0xE0) | 28
FU Header = 0x40 | (NALU[0] & 0x1F)
載荷 = FU Indicator + FU Header + NALU 剩余數據

3. 聚合包模式（Aggregation Packet）
適用場景：多個小 NALU（如 SPS+PPS+SEI）合并為一個 RTP 包，減少開銷。

四、RTP 時間戳與序列號管理

時間戳生成：
單位：90kHz（即 1 秒 = 90000 個時間戳單位）。
計算方法：Timestamp = 采樣時間（秒） × 90000。
示例：25fps 視頻，每幀間隔 = 90000/25=3600 時間戳單位。
序列號管理：
初始值隨機生成，后續每發送一個 RTP 包遞增 1。
溢出處理：16 位序列號范圍 0-65535，溢出后自動回繞（如 65535→0）。

五、封包流程總結

NALU 分類：
分離 SPS/PPS/SEI、IDR 幀、P 幀 / B 幀。
檢查 NALU 長度，決定使用單 NALU、分片或聚合模式。
構建 RTP 報頭：
設置版本（V=2）、填充位（P=0）、擴展位（X=0）、CSRC 計數（CC=0）。根據 NALU 類型設置標記位（M）。分配序列號和時間戳。
選擇封裝模式：
小 NALU（≤MTU）：單 NALU 模式。
大 NALU（>MTU）：分片模式（FU-A）。
多個小 NALU：聚合模式（STAP-A）。
發送 RTP 包：
通過 UDP 套接字發送，目標地址和端口由 RTSP 協商確定。

2.3 RTP 解封裝 H.264

一、解封裝核心目標與前提條件
RTP 解封裝 H.264 的目標是從 RTP 數據包中提取完整的 H.264 NALU 單元，恢復為編碼器輸出的原始格式，供后續解碼使用。

已知 RTP 載荷類型（PT）為 H.264 對應的數值（如 96）。
解析 RTP 報頭中的序列號（Seq）和時間戳（Timestamp），用于重組和同步。

二、解封裝關鍵步驟
1. 解析 RTP 報頭與載荷類型判斷

提取 RTP 固定頭：獲取版本號（V=2）、標記位（M）、序列號、時間戳等字段。
判斷載荷類型（PT）：若 PT=96（H.264 默認 PT 值），則進入 H.264 解封裝流程。
檢查標記位（M）：對于視頻流，M=1 通常表示 NALU 結束（如 IDR 幀的最后一個分片）

2. 識別 NALU 打包模式
H.264 的 RTP 打包有三種模式，解封裝需先判斷當前數據包屬于哪種模式

單 NALU 模式（Single NAL Unit）：
RTP 載荷直接對應一個完整 NALU，格式為：

RTP Header + NALU Header（1字節） + NALU Data

識別方法：NALU 頭的 Type 字段為 1-23 或 24-29（需結合實際載荷長度）。
處理方式：直接提取載荷作為完整 NALU，無需重組。

聚合包模式（STAP/MTAP）
一個 RTP 包包含多個 NALU（如 SPS、PPS、SEI 組合），格式為：

RTP Header + [NALU1 + NALU2 + ... + NALUn]

識別方法：NALU 頭的 Type 為 24（STAP-A）、25（STAP-B）等聚合類型。
處理方式：按 NALU 邊界（如起始碼 0x000001 或 0x00000001）拆分多個 NALU。

分片模式（FU-A/FU-B）：
大 NALU 被拆分為多個 RTP 包，需重組，格式為：

RTP Header + FU Indicator（1字節） + FU Header（1字節） + NALU Fragment

識別方法：NALU 頭的 Type 為 28（FU-A）或 29（FU-B）。
處理方式：根據序列號緩存分片，按 S/E 標志組合成完整 NALU
3. 分片 NALU 的重組（以 FU-A 為例）

解析 FU Indicator 和 FU Header：
- FU Indicator：前 3 位為 NALU 頭的 F 和 NRI，后 5 位固定為 28（FU-A 類型）。
- FU Header：
  S 位（開始位）：1 表示當前分片是 NALU 的起始部分。
  E 位（結束位）：1 表示當前分片是 NALU 的結束部分。
  Type：原始 NALU 的類型（如 5 表示 IDR 幀）。
重組邏輯：
創建緩存隊列：以序列號為鍵，存儲同一 NALU 的所有分片。
- 處理首個分片（S=1）：
  提取 FU Header 中的 Type，構造完整 NALU 頭（F+NRI+Type）。
  將 FU 載荷作為 NALU 數據的起始部分。
- 處理中間分片（S=0, E=0）：直接追加載荷到對應 NALU 數據。
- 處理最后分片（E=1）：追加載荷并標記 NALU 完整，觸發解封裝完成。

示例：IDR 幀分片重組
首個分片（S=1, E=0）：
FU Indicator=0x7C（二進制 01111100），FU Header=0x85（二進制 10000101）
→ 完整 NALU 頭 = 0b01100101（0x65，對應 IDR 幀類型 5）。
中間分片（S=0, E=0）：FU Header=0x05（二進制 00000101）→ 直接追加數據。
最后分片（S=0, E=1）：FU Header=0x45（二進制 01000101）→ 組合完成 NALU。

4. 恢復 NALU 原始格式
去除 RTP 相關字段：
單 NALU 模式直接使用載荷中的 NALU Header 和 Data；分片模式重組后需確保 NALU 頭正確（F、NRI、Type）。
補充起始碼：
H.264 裸流通常以起始碼（0x000001 或 0x00000001）標識 NALU 邊界，解封裝后需在每個 NALU 前添加起始碼，供解碼器識別。
5. 時間戳與同步處理

時間戳提取：從 RTP 報頭的 Timestamp 字段獲取采樣時刻，單位為 90kHz（如 Timestamp=67890 表示 754.33ms）。
同步機制：
同一 NALU 的所有分片共享相同時間戳。
音頻與視頻流通過 RTCP 的 SR/RR 報告進行跨流同步。

三解封裝與解碼的銜接
解封裝后的 NALU 流需按以下步驟交付解碼器：

排序 NALU：按序列號和時間戳順序排列，確保解碼順序正確。傳遞給 H.264 解碼器：
解碼器輸入要求：NALU 流以起始碼分隔，包含 SPS/PPS（解碼必需參數集）。
示例流程：

解封裝得到NALU列表 → 檢查是否包含SPS/PPS（Type=7/8）→ 按順序送入解碼器 → 輸出YUV視頻幀

2.4 RTP封裝 AAC

一、AAC封裝到RTP的核心邏輯
AAC音頻流在RTP中的封裝需遵循 RFC3640 規范，核心步驟是去除ADTS頭并添加RTP特定格式的頭部信息。

1. 封裝前的準備：解析AAC原始數據

ADTS頭處理：
AAC原始數據通常包含7字節的ADTS頭（或9字節，含CRC校驗），封裝時需跳過該頭部，僅保留音頻載荷。
- ADTS頭包含采樣率、通道數等信息，但RTP傳輸中這些參數通過SDP協商，因此無需保留。
載荷類型（PT）協商：
通過SDP確定RTP的PT值（如97），并配置相關參數（如a=rtpmap:97 mpeg4-generic/44100）。

2. RTP封裝步驟（單AU模式）
步驟1：構建RTP頭

設置版本（V=2）、序列號（Seq）、時間戳（Timestamp，單位90kHz）、SSRC等字段。
時間戳計算：根據采樣率確定每幀時間戳增量。例如，44.1kHz采樣的AAC，每幀1024樣本對應時間戳增量為 (1024/44100)×90000≈2097。

步驟2：添加AU頭信息
RTP載荷由以下部分組成（以單AU為例）：

RTP Header (12B) + AU-headers-length (2B) + AU-header (2B) + AAC Payload (去除ADTS后的數據)

AU-headers-length：表示后續AU-header的總位數，單AU時為16位（2字節）。
```
bytes[0] = 0x00; // 高位
bytes[1] = 0x10; // 低位（16位=2字節）
```

AU-header：高13位表示AU載荷長度，低3位保留。

uint16_t au_size = payload_length; // 去除ADTS后的AAC數據長度
bytes[2] = (au_size >> 5) & 0x1F;   // 高13位的前8位
bytes[3] = (au_size & 0x1F) << 3;   // 高13位的后5位，左移3位補零

步驟3：組合載荷數據
將AU頭與AAC載荷拼接，作為RTP的凈荷部分。例如，去除ADTS后的AAC數據為200字節，則載荷結構為：

[RTP頭12B] [0x0010] [0x0640] [AAC數據200B]

0x0640 對應AU-header的13位長度值 0b0000011001000（十進制200）。

3. 多AU封裝與參數配置
若一個RTP包包含多個AU（如連續音頻幀），需擴展AU-header數組：

AU-headers-length：總位數為 n×16（n為AU數量）。
AU-header：每個AU對應一個header，包含AU-size和AU-Index-delta（序號增量）。
SDP參數：需通過fmtp字段聲明sizeLength=13（AU-size占13位）、indexLength=3等。
```
a=fmtp:97 streamtype=5; profile-level-id=1; config=1288; sizeLength=13; indexLength=3;
```

2.5 RTP解封裝AAC

解封裝是封裝的逆過程，目標是從RTP包中恢復原始AAC幀（帶ADTS頭）。

一解封裝流程
1. 解析RTP頭與載荷結構

驗證PT值：確認PT為AAC對應的動態類型（如97）。
提取載荷：從RTP包中分離出AU-headers-length、AU-header和AAC Payload。

2. 解析AU頭信息
步驟1：讀取AU-headers-length

取值為16表示單AU，32表示雙AU，依此類推。
計算AU數量：(au_headers_length / 8) / 2 = n。

步驟2：解析AU-header

提取每個AU的大小（高13位）和序號（低3位）。

uint16_t au_header = (bytes[2] << 8) | bytes[3];
uint13_t au_size = (au_header >> 3) & 0x1FFF; // 高13位

步驟3：分離AAC載荷
根據au_size從載荷中拆分出每個AU的數據塊，例如單AU時直接取前au_size字節。

3. 恢復ADTS頭并輸出

構建ADTS頭：需包含采樣率、通道數等信息，可從SDP的config字段解析。
- 示例：config=1288對應audioObjectType=2（AAC LC）、samplingFrequencyIndex=7（22050Hz）、channelConfiguration=1（單聲道）。

組合完整AAC幀：

ADTS Header (7B) + AAC Payload (從RTP提取的AU數據)

二關鍵參數與SDP配置

SDP中的AAC參數：
```
m=audio 0 RTP/AVP 97
a=rtpmap:97 mpeg4-generic/44100
a=fmtp:97 streamtype=5; profile-level-id=1; config=1408; sizeLength=13;
```
- config：前兩字節為AudioSpecificConfig，包含編碼參數。
- sizeLength=13：AU-size占13位，最大支持8191字節（2^13-1）。
時間戳同步：
- 接收端根據RTP時間戳計算播放時間，如時間戳增量2097對應44.1kHz的1024樣本幀（2097 = 90000×1024/44100）。
錯誤處理：
- 若AU-headers-length非16的倍數，視為無效包，觸發丟包重傳機制（通過RTCP反饋）。

總結：封裝與解封裝的核心差異

階段	核心操作	文檔關聯段落
封裝	去除ADTS頭，添加RTP頭和AU頭，按SDP配置填充參數	、
解封裝	解析RTP頭和AU頭，恢復ADTS頭，重組完整AAC幀	、
參數協商	通過SDP傳遞PT值、采樣率、通道數等，確保兩端兼容	、

3 SDP

3.1 基礎概念

一、SDP基礎概念
1. 協議定位與用途

定義：SDP（Session Description Protocol，會話描述協議）是一種文本格式的應用層協議，用于描述多媒體會話的參數（如媒體類型、編碼格式、傳輸地址等），但不負責傳輸控制，需與RTSP、SIP等協議結合使用。
核心作用：
- 在RTSP中用于傳遞媒體描述信息（如推流/拉流時的SDP協商）；
- 在WebRTC中用于交換音視頻編解碼器、網絡地址等連接參數。
特點：基于文本、可擴展，字段采用<類型>=<值>格式，類型為單個字符（如v=、m=），值為結構化文本。

2. 與RTSP的關系

RTSP負責會話控制（如SETUP、PLAY命令），SDP負責媒體描述（如編碼格式、端口）；
RTSP通過ANNOUNCE/DESCRIBE方法傳遞SDP內容，實現媒體協商。

二、SDP核心結構與語法
1. 整體結構
SDP分為會話級參數和媒體級參數，前者作用于整個會話，后者針對單個媒體流（如音頻、視頻）：

會話級參數（必填在前）
v= 協議版本號
o= 會話源
s= 會話名稱
t= 會話時間
可選字段（如c=連接信息、a=屬性）
媒體級參數（每個媒體流以m=開始）
m= 媒體類型、端口、協議、格式
可選字段（如a=屬性、c=連接信息）

會話級與媒體級的分界：第一個m=字段出現前為會話級，之后為媒體級。

2. 必需字段（必填項）

字段	格式與含義	示例
v=	協議版本號，當前固定為`0`	`v=0`
o=	會話源信息，包含6個子字段：用戶名、會話ID、版本、網絡類型、地址類型、地址	`o=- 1271659412 1271659412 IN IP4 10.56.136.37`
s=	會話名稱，不能為空（無意義時可填空格）	`s=Demo Meeting`
t=	會話時間，格式為`開始時間結束時間`（`0 0`表示永久有效）	`t=0 0`
m=	媒體描述，包含4個子字段：媒體類型、端口、傳輸協議、格式列表	`m=video 45678 RTP/AVP 96`（視頻流，端口45678，RTP協議，格式96）

3. 可選字段（擴展信息）

字段	作用范圍	含義	示例
c=	會話/媒體級	連接信息（網絡類型、地址類型、地址）	`c=IN IP4 192.168.1.100`（IP4地址）
a=	會話/媒體級	附加屬性（如編碼參數、傳輸控制）	`a=rtpmap:96 H264/90000`（格式96對應H264，時鐘速率90000）
b=	會話/媒體級	帶寬信息（單位kbit/s）	`b=AS:24`（音頻帶寬24kbit/s）
u=	會話級	會話相關URI地址	`u=http://example.com/session`

三、關鍵字段詳解
1. 媒體描述字段（m=）

格式：m=<媒體類型> <端口> <傳輸協議> <格式列表>
- 媒體類型：audio（音頻）、video（視頻）、application（應用數據）等；
- 傳輸協議：常見RTP/AVP（基于UDP的RTP）、TCP等；
- 格式列表：RTP負載類型（如0對應G.711音頻，96對應動態H264視頻）。

示例：

m=audio 45678 RTP/AVP 0 15 3  // 音頻流，端口45678，支持G.711（0）、G.728（15）、GSM（3）
m=video 0 RTP/AVP 96          // 視頻流，端口未確定（0表示待協商），格式96（需a=rtpmap補充說明）

2. 附加屬性字段（a=）

作用：擴展媒體參數或會話行為，分為特征屬性（如sendonly）和值屬性（如rtpmap）。
常見類型：
- 編碼格式說明：a=rtpmap:<負載類型> <編碼名>/<時鐘速率>
```
a=rtpmap:96 H264/90000  // 負載類型96對應H264，時鐘速率90000Hz
```
- 傳輸控制：a=control:streamid=0（指定媒體流ID，用于多流場景）；
- 方向控制：a=sendonly（只發送不接收）、a=recvonly（只接收不發送）。

3. 連接信息字段（c=）

格式：c=<網絡類型> <地址類型> <連接地址>
- 網絡類型：固定為IN（Internet）；
- 地址類型：IP4或IP6；
- 連接地址：單播地址（如192.168.1.100）或組播地址（如224.2.36.42）。

示例：

c=IN IP4 0.0.0.0  // 會話級連接地址（0.0.0.0表示未指定，由媒體級字段覆蓋）

3.2 SDP協議示例解析

示例1：Helix流媒體服務器的SDP（RTSP場景）

v=0                          // 版本號
o=- 1271659412 1271659412 IN IP4 10.56.136.37  // 會話源（用戶名-，會話ID重復，IP地址10.56.136.37）
s=<No title>                  // 會話名稱
c=IN IP4 0.0.0.0              // 會話級連接地址（未指定，媒體級單獨配置）
t=0 0                         // 永久有效
a=StreamCount:integer;2       // 會話級屬性：2個媒體流
m=audio 0 RTP/AVP 96          // 音頻流，端口0（待協商），協議RTP/AVP，格式96
b=AS:24                       // 音頻帶寬24kbit/s
a=control:streamid=1          // 媒體級屬性：指定流ID為1
a=rtpmap:96 MPEG4-GENERIC/32000/2  // 格式96對應AAC，采樣率32000Hz，2聲道
m=video 0 RTP/AVP 97          // 視頻流，端口0，協議RTP/AVP，格式97
a=control:streamid=2          // 流ID為2
a=rtpmap:97 MP4V-ES/2500      // 格式97對應MPEG-4視頻，時鐘速率2500Hz

關鍵邏輯：
- 通過a=StreamCount聲明多流；
- 每個媒體流通過m=定義基礎參數，a=control區分流ID，a=rtpmap補充編碼細節。

示例2：WebRTC中的SDP（連接協商場景）

v=0
o=- 7595655801978680453 2 IN IP4 112.90.139.105  // 會話源（IP地址可忽略，由ICE協商實際地址）
s=-                            // 會話名稱為空
t=0 0                          // 永久有效
a=group:BUNDLE 0 1             // 會話級屬性：音頻（0）和視頻（1）復用同一傳輸通道
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104  // 音頻流，端口9（虛擬端口），加密RTP協議，支持Opus（111）等編碼
a=rtpmap:111 opus/48000/2      // Opus編碼，采樣率48000Hz，2聲道
m=video 9 UDP/TLS/RTP/SAVPF 122  // 視頻流，支持H264（122）
a=rtpmap:122 H264/90000        // H264編碼，時鐘速率90000Hz

關鍵邏輯：
- 通過a=group:BUNDLE實現音視頻流復用，減少端口占用；
- a=rtpmap明確動態負載類型的編碼參數，適應WebRTC的靈活協商需求。

3.3 重點知識

1. 基礎概念類

問題1：SDP的主要作用是什么？與RTSP的關系？
回答：SDP用于描述媒體會話參數（如編碼格式、傳輸地址），RTSP用于控制會話流程（如PLAY、SETUP）。RTSP通過ANNOUNCE/DESCRIBE方法傳遞SDP，實現媒體協商。
問題2：SDP的必需字段有哪些？
回答：必需字段包括v=（版本）、o=（會話源）、s=（會話名）、t=（時間）、m=（媒體描述）。

2. 字段與協議流程類

問題1：m=字段的作用是什么？常見子字段有哪些？
回答：m=定義媒體流的核心參數，包括媒體類型、端口、傳輸協議、格式列表。例如m=video 45678 RTP/AVP 96表示視頻流，端口45678，RTP協議，格式96。
問題2：a=rtpmap的作用是什么？何時需要？
回答：a=rtpmap用于描述動態RTP負載類型的編碼細節（如H264的時鐘速率）。當媒體格式為動態類型（非標準靜態類型，如G.711）時必須添加，例如：
```
m=video 0 RTP/AVP 96         // 動態格式96
a=rtpmap:96 H264/90000       // 補充編碼參數
```。  
```

3. 應用場景類

問題1：多流場景下如何區分不同媒體流？
回答：通過m=字段分別定義每個媒體流，并使用a=control或streamid屬性標識流ID。例如：
```
m=audio 0 RTP/AVP 96         // 音頻流，streamid=1
a=control:streamid=1
m=video 0 RTP/AVP 97         // 視頻流，streamid=2
a=control:streamid=2
```。  
```
問題2：WebRTC中SDP的核心作用是什么？
回答：WebRTC通過SDP交換音視頻編解碼器（如Opus、H264）、網絡候選地址（ICE協商）、傳輸協議（如SRTP加密）等信息，實現端到端連接的建立。

4 RTCP

4.1 RTCP基礎概念

1. 協議定位與核心功能

定義：RTCP（Real-Time Transport Control Protocol，實時傳輸控制協議）是RTP的配套協議，用于監控RTP傳輸質量、同步媒體流時間軸，并提供參與者標識等控制信息。
與RTP的協作：
- RTP負責傳輸音視頻數據（如H264、AAC），使用偶數UDP端口；
- RTCP負責發送控制報文，使用相鄰奇數端口（如RTP端口為8888，則RTCP端口為8889）。
核心功能：
- 質量反饋：通過接收方報告（RR）統計丟包率、抖動等網絡指標；
- 時間同步：利用發送方報告（SR）中的NTP/RTP時間戳對，對齊不同媒體流的時間軸；
- 參與者標識：通過源描述報告（SDES）中的CNAME唯一標識會話參與者。

2. 報文類型與格式
RTCP定義了5種報文類型，均基于統一的頭部格式（4字節固定頭）：

類型	PT值	功能描述	典型場景
發送方報告（SR）	200	發送方發送媒體數據的時間、流量等信息	推流端周期性發送，用于接收端同步
接收方報告（RR）	201	接收方反饋網絡質量（丟包、抖動等）	拉流端定期反饋傳輸狀態
源描述（SDES）	202	提供參與者元數據（如CNAME、用戶名）	會話初始化時協商標識
離開會話（BYE）	203	通知其他參與者退出會話	客戶端斷開連接時發送
應用定義（APP）	204	自定義擴展功能	試驗性協議擴展

關鍵字段解析：

SSRC：同步源標識符，必須與對應RTP流的SSRC一致；
NTP timestamp：64位網絡時間協議時間戳，用于絕對時間同步（從1900年1月1日起計）；
RTP timestamp：與RTP數據包時間戳同單位（如90kHz時鐘），用于相對時間對齊；
Length：報文長度（以4字節為單位），需確保總長度為4字節對齊。

二、RTCP核心機制
1. 時間同步：NTP與RTP時間戳的映射

問題背景：
不同媒體流（如音頻、視頻）使用獨立的RTP時間戳（如音頻48kHz、視頻90kHz），需通過絕對時間軸（NTP）實現同步。
關鍵原理：
- SR報文中的時間戳對：每個SR報文包含<NTP, RTP>時間戳對，表示“當前RTP時間戳對應NTP絕對時間”。
- 同步公式：
  假設音頻流時間軸為基準，視頻流需通過以下步驟對齊：
  1. 提取音頻SR的(Tan, Tar)和視頻SR的(Tvn, Tvr)；
  2. 計算時間差：
    $D = (T a r ? T v r) ? (T an ? T v n)$
  3. 調整視頻時間戳：Tvr' = Tvr + D。
代碼實現：
在FFmpeg中，RTP時間戳基于base_timestamp生成，RTCP的SR時間戳通過ntp_time - first_rtcp_ntp_time + base_timestamp計算。

2. 傳輸控制：發送間隔與流量調節

發送策略：
- 周期性發送：默認每5秒發送一次RTCP報文，確保時間同步時效性；
- 流量控制：RTCP流量不超過RTP流量的5%，通過公式動態調整：
  [
  rtcp_bytes = (octet_count - last_octet_count) \times 0.5%
  ]
  （octet_count為RTP發送字節數）。
特殊場景：
- 推流時，RTCP包需發送至服務器，用于服務器監控傳輸質量；
- 拉流時，客戶端通過RTCP RR反饋網絡狀態，服務器據此調整碼率。

4.2 重點

1. 基礎概念類

問題1：RTCP與RTP的區別？
回答：
- RTP是數據傳輸協議，負責承載音視頻數據（如H264包），使用偶數端口；
- RTCP是控制協議，負責質量反饋、時間同步和參與者標識，使用相鄰奇數端口，流量占比≤5%。
問題2：SR報文的作用是什么？關鍵字段有哪些？
回答：
- 作用：提供發送方的時間戳（NTP/RTP）、發送包數、字節數，用于接收端同步媒體流；
- 關鍵字段：
  - SSRC：必須與對應RTP流一致，標識數據源；
  - NTP timestamp：絕對時間，用于跨流同步；
  - RTP timestamp：相對時間，用于計算媒體幀間隔。

2. 時間同步類

問題1：如何實現音視頻同步？RTCP的作用是什么？
回答：
- 原理：通過RTCP SR報文中的<NTP, RTP>時間戳對，將音頻和視頻的時間軸映射到NTP絕對時間軸；
- 步驟：
  1. 音頻和視頻流各自發送SR報文，包含當前時間戳對；
  2. 接收端根據時間戳對計算偏差D，調整視頻幀播放時間。
問題2：NTP與RTP時間戳的區別？
回答：
- NTP是絕對時間（從1900年起計），單位為秒+皮秒，用于跨設備同步；
- RTP是相對時間，單位為采樣率（如90kHz表示每幀間隔1/90000秒），用于媒體內時序控制。

3. 應用場景類

問題1：推流和拉流時，RTCP的流向有何不同？
回答：
- 推流（Client→Server）：RTCP由客戶端發送至服務器，服務器通過SR/RR監控傳輸質量；
- 拉流（Server→Client）：RTCP由服務器發送至客戶端，客戶端通過RR反饋丟包、抖動等信息。
問題2：能否不發送RTCP實現音視頻同步？
回答：
- 理論上可行，需滿足：
  1. 音視頻流的base_timestamp初始化一致；
  2. 采樣率已知且固定（如音頻48kHz、視頻90kHz）；
- 實際中RTCP是標準方案，可動態校準時鐘偏差。

4. 報文解析類

問題：根據以下SR報文片段，解析關鍵信息
```
Sender SSRC: 0xD801E570  
NTP MSW/LSW: 0xE34CC9FB / 0xEF1A9FBE  
RTP timestamp: 2794561330  
Packet count: 0  
Octet count: 0  
```
解析：
- SSRC對應視頻流（0xD801E570），發送方尚未發送數據（packet count=0）；
- NTP時間轉換為Unix時間：(MSW - 2208988800) + LSW/1e12，表示報告發送時刻；
- RTP時間戳2794561330對應實際播放時間：2794561330 / 90000 ≈ 31050.68秒。

5 總結

RTSP、RTP、SDP、RTCP 是音視頻流媒體傳輸的核心協議，分別負責會話控制、媒體數據傳輸、會話描述和傳輸控制。它們通過分層協作實現實時流的建立、傳輸與同步，以下是具體工作流程及協作機制：

一、協議分工與核心作用

協議	層次	核心功能	典型交互場景
RTSP	應用層	會話控制（建立/暫停/關閉流），傳輸協議協商	OPTION查詢方法、SETUP建立傳輸通道
SDP	應用層	描述會話媒體參數（編碼格式、端口、時間軸）	通過RTSP的DESCRIBE/ANNOUNCE傳遞
RTP	傳輸層	實時媒體數據封裝與傳輸（音視頻分片）	攜帶H264/AAC數據，通過UDP發送
RTCP	傳輸層	傳輸質量監控、時間同步、參與者標識	發送SR/RR報文反饋丟包率、同步NTP時間戳

二、協同工作流程（以拉流為例）
1. 會話建立與媒體協商（RTSP + SDP）

OPTION階段（RTSP）
- 客戶端發送OPTION請求查詢服務器支持的方法（如DESCRIBE、SETUP），服務器返回Public頭字段（含可用方法列表）。
DESCRIBE階段（RTSP + SDP）
- 客戶端發送DESCRIBE請求獲取媒體描述，服務器返回包含SDP數據的響應，內容包括：
  - 媒體類型（音頻/視頻）、編碼格式（H264/AAC）；
  - 傳輸協議（RTP/AVP）、端口范圍（如客戶端RTP端口21988-21989）；
  - 時間信息（t=0 0表示永久有效）。
SETUP階段（RTSP + RTP/RTCP端口協商）
- 客戶端發送SETUP請求，通過Transport頭字段指定RTP/RTCP端口（如client_port=21988-21989），服務器響應確認并分配服務器端口（如server_port=39188-39189）。
- 關鍵成果：確定RTP通道（偶數端口）和RTCP通道（奇數端口），建立會話關聯。

2. 媒體傳輸與控制（RTP + RTCP + RTSP）

PLAY階段（RTSP觸發數據傳輸）
- 客戶端發送PLAY請求啟動流，服務器通過RTP發送媒體數據，每個RTP包包含：
  - 時間戳（Timestamp）：基于媒體采樣率（如視頻90kHz），用于解碼順序控制；
  - 序列號（Sequence Number）：用于檢測丟包和重組。
RTCP實時監控（質量反饋與時間同步）
- 發送方報告（SR）：服務器周期性發送SR報文，包含：
  - NTP timestamp：絕對時間（如Nov 4, 2020 06:34:35 UTC），用于音視頻同步；
  - RTP timestamp：相對時間（如2794561330），對應媒體流的采樣時間。
- 接收方報告（RR）：客戶端反饋網絡狀態，包含：
  - 丟包率（Loss fraction=141/256表示約55%丟包）；
  - 抖動值（Interarrival jitter），用于調整緩沖區。
實時控制（RTSP命令）
- 客戶端可發送PAUSE/TEARDOWN命令暫停或關閉流，服務器通過RTSP響應確認。

3. 音視頻同步機制（SDP + RTP + RTCP）

SDP的時間基定義：在SDP中通過a=rtpmap指定編碼的時鐘速率（如90000 Hz對應視頻，48000 Hz對應音頻）。
RTCP的時間軸映射：
1. 服務器在SR報文中發送<NTP, RTP>時間戳對（如NTP=2023-10-01 12:00:00 UTC，RTP=2794561330）；
2. 客戶端根據公式計算媒體時間：
  [
  媒體時間(s) = \frac{RTP時間戳}{時鐘速率} = \frac{2794561330}{90000} \approx 31050.68s
  ]
3. 跨流同步：通過NTP時間對齊音頻和視頻的RTP時間戳，消除采樣率差異。