RTP / RTCP / SRTP — Web Protocol Lab

#このページで確認できること

RTP ヘッダーの主要フィールド(SSRC、シーケンス番号、タイムスタンプ、PT)の役割を理解する
RTCP の SR / RR がロス率・ジッタをどう報告するかを理解する
SRTP が「何を暗号化し、何を平文で残すか」を確認する
Wireshark の RTP ストリーム解析でロス・ジッタの統計を取る手順を確認する
観察する項目: rtp.ssrc、シーケンス番号の欠落、Wireshark の Telephony → RTP → RTP Streams

実装上の制約: メディアストリームの検証環境は本サイトでは提供していません。WebRTC 通話(ビデオ会議)や自前の SIP / VoIP 環境のキャプチャを前提に手順を記載しています。

#役割分担

	役割	ポイント
RTP	メディア(音声・映像)の運搬	UDPで使われることが多い。基本RTPは信頼性を保証しないが、RTX・NACK・FEC等を組み合わせる構成もある
RTCP	品質フィードバック	ロス率・ジッタを SR / RR で定期報告。RFC 3550の推奨初期値はセッション帯域の5%だが、プロファイルや設定で変更できる
SRTP	RTP / RTCP の暗号化・認証	基本RTPヘッダーは平文で、ペイロードを暗号化する。選択したヘッダー拡張を暗号化する方式もある

従来は RTP が偶数ポート、RTCP がその +1 ポートという慣習でしたが、現在の WebRTC では rtcp-mux により同一ポートに多重化するのが標準です。

#RTP ヘッダー

RTP header (12 bytes〜)

V=2 P X CC M PT: 111 (opusのSDPネゴシエーション例) Sequence: 43210 ← 1ずつ増加。並べ替え・RTX確認後の欠番はパケットロス候補 Timestamp: 3948123840 ← サンプリングクロック基準の再生時刻 SSRC: 0x2f9a8c31 ← RTPソース識別子。乱数選択し衝突を検出する [payload: エンコード済みメディア — 通常のSRTP暗号化対象]

シーケンス番号: パケットのロス検出と並べ直しに使う。欠番はパケット損失の候補であり、遅延到着やRTXを確認して判断する。1つのメディアフレームが複数RTPパケットに分割される場合もあるため、欠番とフレーム損失は同義ではない。
タイムスタンプ: 壁時計ではなくコーデックのサンプリングクロック(opus なら 48kHz)。ジッタ計算の基準。
SSRC: RTPソースの識別子。32ビット値を選び、衝突を検出した場合は変更する。1つの通話に音声・映像やRTX用など複数のSSRCが流れることがあるため、キャプチャ解析はまずSSRC単位で分ける。

#RTCP と SRTP

RTP メディアと RTCP レポートの並走

participants: Caller, Callee
Caller -> Callee: RTP (audio, SSRC=A, seq=100..)
Caller -> Callee: RTP (audio, seq=101, 102, ...)
Callee -> Caller: RTP (audio, SSRC=B)
note: この代表例ではメディアが UDP 上を連続的に流れる
Caller -> Callee: RTCP SR (送信統計 + NTP時刻)
Callee --> Caller: RTCP RR (受信報告: fraction lost, jitter)
note: RR のロス率・ジッタはネットワーク品質を判断する指標の一部

SR (Sender Report): 送信側が送ったパケット数・オクテット数と NTP 時刻を報告。RTT 計算にも使う。
RR (Receiver Report): 受信側が SSRC ごとのロス率(fraction lost)・累積ロス・ジッタを報告。
SRTP の暗号化範囲: 基本RTPヘッダーは平文のまま、ペイロードを暗号化して認証する。通常はSSRC・シーケンス番号・タイムスタンプを観測できるため、ペイロードを復号せずにロス・ジッタを解析できる。RFC 6904等で選択したヘッダー拡張を暗号化する場合は、その拡張値は読めない。鍵交換はWebRTCではDTLS-SRTP、SIP系ではSDES等の方式が使われる。

#Wireshark での観測手順

キャプチャと解析

# 通話中の UDP をキャプチャ (ポートは環境により異なる)
$ sudo tcpdump -i en0 -w call.pcap 'udp and not port 53'

# Wireshark での手順:
# 1. UDP パケットを右クリック → Decode As → RTP
# 2. filter: rtp        — ストリーム表示 (SSRC / seq / timestamp)
# 3. filter: rtcp       — SR / RR の中身 (fraction lost, jitter)
# 4. Telephony → RTP → RTP Streams — ロス率・ジッタの統計一覧

よく使うフィルタ

# 特定ストリームだけ表示
rtp.ssrc == 0x2f9a8c31

# シーケンス欠落 (ロス) をマークする
rtp.analysis.lost

# RTCP の受信レポートのみ
rtcp.pt == 201

#観測ポイント

DevTools	WebRTC なら `chrome://webrtc-internals` で SSRC ごとの packetsLost / jitter / bitrateを確認できる。これらは統計APIの集計値であり、RTCPパケットそのものを表示しているとは限らない。
Proxy	UDP上のRTPは従来型HTTPプロキシでは直接運べない。WebRTCではネットワークポリシーに応じてTURN/TCP・TURN/TLS等が選ばれることがあり、直接UDP経路より遅延やHead-of-line blockingの影響を受ける可能性がある。
tcpdump / Wireshark	Decode As → RTP が起点。SRTP でもヘッダー解析とロス・ジッタ統計は可能。ペイロードの復号は鍵がないため不可。
TLS inspection	通常のTLSインスペクション装置はDTLS-SRTPのエンドポイントではないため、SRTPを復号しない。装置が主に関与するシグナリング経路と、メディア経路を分けて観測する。
QoS 設計	ロス率とジッタは体感品質の指標だが、影響はコーデック、FEC、ジッタバッファ、ロスの連続性に依存する。固定の数%を一律な劣化境界にせず、実測品質と併せて評価する。DSCP (EF) マーキングが経路で保持されているかも確認できる。

#関連

WebRTC での鍵交換は DTLS、全体の接続確立は WebRTC を参照。SRTP の暗号の考え方は TLS と対比すると理解しやすいです。