RTCP 深入解析：掌握即時影音串流的品質監控與媒體同步機制

在即時影音傳輸中，RTP 負責搬運媒體資料，但誰來監控傳輸品質？答案是 RTCP。它是 RTP 的控制協定，靜默運行於背景，持續蒐集封包遺失、延遲與抖動等關鍵指標。

RTCP 的核心職責：品質監控

RTCP 透過定期交換控制封包來評估傳輸品質，本身不攜帶任何媒體資料。其中最關鍵的封包類型為 SR（Sender Report）與 RR（Receiver Report）。SR 由發送端提交，包含傳送封包總數與位元組數；RR 由接收端回報，記錄封包遺失率（Fraction Lost）、累積遺失數、抖動（Jitter）及往返延遲（RTT）。這些指標讓應用層得以動態調整編碼品質或切換傳輸路徑，實現自適應串流（Adaptive Streaming）。依 RFC 3550 規範，RTCP 流量應控制在總頻寬的 5% 以內，避免占用媒體傳輸資源。

媒體同步：SDES 與 NTP 時間戳的關鍵角色

多媒體會話中，音訊與視訊各走獨立的 RTP 串流，需要精確對齊播放時間點。RTCP 的 SR 封包內嵌 NTP 時間戳與對應的 RTP 時間戳，接收端透過兩者的映射關係，計算出不同串流間的絕對時間基準，從而消除音畫不同步（Lip-sync）問題。此外，SDES（Source Description）封包用於傳遞參與者的 CNAME 識別符，將同一來源的音訊與視訊 SSRC 綁定在一起，確保多路串流能正確關聯。BYE 封包則用於通知其他參與者會話已結束，維持會話成員清單的準確性。

💡 重點整理

• 不傳媒體：RTCP 僅傳輸控制封包，媒體資料完全由 RTP 負責。
• 品質指標：RR 封包提供封包遺失率、抖動與 RTT，驅動自適應調整。
• 音畫同步：SR 封包的 NTP/RTP 時間戳映射是解決 Lip-sync 的關鍵。
• 頻寬限制：RTCP 流量依規範不應超過總頻寬的 5%。

RTCP 是即時串流品質的隱形守門人。理解其封包結構與運作機制，是構建高品質 WebRTC 或 RTP 應用的必要基礎，也是排查串流異常的第一把鑰匙。

📚 參考文獻

1. Schulzrinne, H. et al.（2003）. RFC 3550 – RTP: A Transport Protocol for Real-Time Applications. IETF. https://www.rfc-editor.org/rfc/rfc3550
2. MDN Web Docs. WebRTC API – RTCPeerConnection.getStats(). https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/getStats

⚠️ 本文內容基於撰寫時的最新資訊，實際應用時請參考官方文件的最新版本。