RTP/SRTP 媒體串流

RTP（Real-time Transport Protocol）是 VoIP 裡真正在傳語音和視訊的協定。SIP 把通話談好之後，實際的媒體就走 RTP；它搭 RTCP 回報品質，SRTP 則在上面加一層加密保護。

RTP 封包結構

RTP Header 格式

RTP 標頭（RFC 3550）最小為 12 個位元組，結構如下：

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       Sequence Number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             SSRC                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             CSRC                              |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

各欄位說明

欄位	位元數	說明
V（Version）	2	RTP 版本，固定為 2
P（Padding）	1	是否有填充位元組（用於加密對齊）
X（Extension）	1	是否有標頭擴展
CC（CSRC Count）	4	CSRC 識別碼數量（0-15）
M（Marker）	1	標記位，語音中表示靜默後的第一個封包
PT（Payload Type）	7	負載類型編號，對應 Codec
Sequence Number	16	封包序號，每發一個封包遞增 1
Timestamp	32	取樣時戳，語音通常每 20ms 遞增 160（8000Hz）
SSRC	32	同步來源識別碼，隨機產生，識別串流來源
CSRC	32 x CC	貢獻來源識別碼，用於混音場景

其中 Payload Type 這欄幾個常見值，靜態的幾個值是固定約定、96 以上才動態協商：

PT 值	Codec	說明
0	PCMU (G.711 u-law)	北美標準
8	PCMA (G.711 A-law)	歐洲/亞洲標準
9	G.722	寬頻語音
18	G.729	低頻寬語音
96-127	動態分配	透過 SDP rtpmap 協商

RTP 封包大小計算

以 G.711 搭配 20ms 封包間隔為例：

層級	大小	說明
語音負載	160 bytes	8000 Hz x 8 bits x 0.02s
RTP Header	12 bytes	固定標頭
UDP Header	8 bytes	—
IP Header	20 bytes	IPv4
L2 Header	14-18 bytes	Ethernet
總計	214-218 bytes	—
每秒封包數	50 pps	1000ms / 20ms
實際頻寬	約 87 kbps	含所有標頭 overhead

SRTP 加密機制

SRTP 概述

SRTP（Secure RTP, RFC 3711）在 RTP 基礎上增加加密與完整性保護，防止竊聽與篡改。

SRTP 提供的安全功能：

功能	說明
機密性（Confidentiality）	AES-128-CM 或 AES-256-CM 加密負載
訊息驗證（Authentication）	HMAC-SHA1 計算驗證標籤
重播防護（Replay Protection）	基於序號的重播偵測視窗

金鑰交換方式

SRTP 本身不定義金鑰交換機制，常見的方式有：

方式	說明	安全等級
SDES（RFC 4568）	金鑰明文放在 SDP 的 a=crypto 屬性中	低（需搭配 TLS）
DTLS-SRTP（RFC 5764）	透過 DTLS 握手交換金鑰	高（WebRTC 標準）
ZRTP（RFC 6189）	端對端 Diffie-Hellman 交換	高（無需信任伺服器）
MIKEY（RFC 3830）	多媒體金鑰管理	中高

SDES 有個要特別小心的地方：它把加密金鑰用明文放進 SDP，如果信令本身沒加密（不是 SIPS），那金鑰等於完全曝光。所以要加密的環境，SDES 一定要搭 SIP over TLS，或乾脆改用 DTLS-SRTP。

SRTP 封包格式

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        RTP Header（與標準 RTP 相同）           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Encrypted RTP Payload                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        SRTP MKI（選配）                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Authentication Tag（4-10 bytes）        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTCP 品質回報

RTCP 概述

RTCP（RTP Control Protocol）與 RTP 搭配使用，在通話期間定期交換品質統計資訊。RTCP 使用的埠號為 RTP 埠號加 1。

RTCP 封包類型

類型	縮寫	PT 值	說明
Sender Report	SR	200	發送端統計（發送封包數、位元組數）
Receiver Report	RR	201	接收端統計（丟包、抖動）
Source Description	SDES	202	來源描述（CNAME 等）
Goodbye	BYE	203	串流結束通知
Application-specific	APP	204	應用自定義資料

Receiver Report 關鍵指標

RR 中包含的品質指標對通話品質監控至關重要：

欄位	說明
Fraction Lost	上次報告以來的丟包率（0-255，255=100%）
Cumulative Lost	累計丟失封包數
Extended Highest Seq	收到的最高序號
Interarrival Jitter	封包間抖動（以取樣單位計）
Last SR（LSR）	最後收到的 SR 時戳
Delay since LSR（DLSR）	收到 SR 到發送 RR 的延遲

有了 LSR 和 DLSR，就能從 RTCP 算出來回延遲：RTT = 當前時間 − LSR − DLSR，這是評估網路延遲的重要依據。

RTCP-XR（Extended Reports）

RFC 3611 定義了擴展報告，提供更詳細的品質資訊：

• VoIP Metrics Block：包含 R-Factor、MOS-LQ、MOS-CQ 等語音品質評分
• Burst/Gap Statistics：區分突發性丟包與隨機丟包的統計
• Jitter Buffer Statistics：抖動緩衝的運作狀態

Jitter Buffer 運作

抖動問題

IP 網路中，封包到達的間隔不固定（Jitter），但語音播放需要穩定的取樣間隔。Jitter Buffer 用於平滑這個差異。

運作原理

封包到達時序（不規則）：  |--|----|--|------|--|--|----|
                           ↓
              [Jitter Buffer 緩衝]
                           ↓
播放時序（規則）：         |--|--|--|--|--|--|--|--|

Jitter Buffer 類型

類型	說明	優缺點
固定式（Static）	緩衝大小固定不變	簡單，但無法適應變化的網路狀況
適應式（Adaptive）	根據網路狀況動態調整緩衝大小	能平衡延遲與品質，現代設備主流

關鍵參數

參數	說明	建議值
最小緩衝	Jitter Buffer 最小深度	20-40 ms
最大緩衝	Jitter Buffer 最大深度	150-200 ms
初始緩衝	開始播放前的等待時間	60-80 ms

這裡有個取捨：Jitter Buffer 越大，越扛得住抖動，但延遲也跟著變大。客服中心是即時對話，單向延遲最好壓在 150ms 以內，而 Jitter Buffer 吃掉的那部分，要一起算進整體延遲預算裡。

媒體錨定（Media Anchoring）

概念

在標準 SIP 呼叫中，媒體（RTP）可以端對端直接傳輸，不經過 SIP Proxy。但在許多實際場景中，需要將媒體「錨定」在中間設備上。

直接媒體 vs 錨定媒體

直接媒體：
  話機 A  ←── RTP ──→  話機 B
  （SIP 信令經 Proxy，媒體直連）

錨定媒體：
  話機 A  ←── RTP ──→  SBC/Media Server  ←── RTP ──→  話機 B
  （信令和媒體都經過中間設備）

需要媒體錨定的場景

場景	說明
NAT 穿透	一方或雙方在 NAT 後方
錄音	需要在中間設備擷取媒體進行錄音
Transcoding	兩端使用不同 Codec 需要轉碼
合規監控	法規要求可攔截和監聽
QoS 管理	在中間設備進行頻寬管理
安全隔離	內外網媒體路徑分離
會議橋接	多方通話需要媒體混音

效能影響

媒體錨定會增加：

• 延遲：每經過一個媒體中繼點增加約 1-5ms
• 頻寬：中繼設備需要雙倍頻寬（收 + 發）
• 處理負載：中繼設備需處理每個 RTP 封包
• 單點故障風險：媒體錨定點故障影響所有通話

媒體相關的實務考量

埠號配置

項目	建議
RTP 埠範圍	10000-20000（或依設備配置）
埠號奇偶	RTP 使用偶數埠，RTCP 使用下一個奇數埠
防火牆規則	開放 RTP 埠範圍的 UDP 雙向
每通話埠數	至少 2 個（RTP + RTCP）

媒體問題排查

問題	可能原因	排查方向
無語音（雙向）	SDP IP 位址錯誤、防火牆阻擋 RTP	檢查 SDP c= 欄位、封包抓取
單向語音	NAT 問題、SDP 改寫不完整	比對兩端 SDP、檢查 NAT 規則
斷續語音	丟包、Jitter 過大	RTCP 報告、網路品質測試
迴音	設備聲學問題、延遲過大	檢查話機設定、降低延遲
機器音	Codec 問題、Transcoding 錯誤	確認雙方 Codec 一致

排查媒體問題，tcpdump 或 Wireshark 最好用。Wireshark 的 Telephony > RTP > Stream Analysis 能直接把 RTP 串流的 Jitter、丟包和時序圖畫出來，一看就知道問題出在哪。