この記事は筆者オンリーの Advent Calendar 2025
7日目の記事です。
この間は RTP の概要を書きましたが、今回はその「裏方」である RTCP（RTP Control Protocol） について、ざっくり解説します。
1. RTCPとは？ざっくり一言でいうと
RTCP（RTP Control Protocol）は、
RTPストリームの状態をモニタリングしたり、参加者情報をやりとりしたりする制御用プロトコルです。
RTP が「メディア本体（音声・映像）」だとしたら、
RTCP は「メディアの健康診断結果と自己紹介カード」です。
主な役割は：
パケットロス/ジッタなどの 品質情報（統計）の報告
送信側と受信側の時刻情報の対応付け（同期）
参加者の CNAME・表示名など ソース情報の交換
大人数会議での 送信レート制御のヒント
など。
2. RTPとRTCPの関係
RTCP は、**通常 RTP と同じポート範囲の「偶数/奇数ペア」**で動きます。
典型例：
RTP：UDP 49170
RTCP：UDP 49171
SDP では、a=rtcp: 行で RTCP ポートを明示することもあります。
m=audio 49170 RTP/AVP 0
a=rtcp:49171
プロトコル的には：
RTP：メディアパケット
RTCP：数秒〜数十秒おきに少量だけ送る制御パケット
という感じで、RTCPは低頻度＆低帯域が前提です。
3. RTCPの主なパケット種別
RTCPにはいくつかのパケットタイプがあり、1つのRTCPメッセージの中に複数入ることもあります。
よく出てくるのはこのあたり：
SR（Sender Report）
メディア送信者からのレポート
RR（Receiver Report）
メディア受信者からのレポート
SDES（Source Description）
CNAME や表示名などのソース情報
BYE
セッション離脱通知
（拡張）APP / XR など
この記事では SR / RR / SDES / BYE をざっくり押さえます。
4. Sender Report（SR）
SR は RTPパケットを送っている側が送出する RTCP パケットです。
役割は：
自分が送っている RTP ストリームの統計情報を通知
「RTP timestamp」と「NTP時刻」の対応表を送る（同期用途）
ざっくり構造イメージ：
[SR]
- SSRC of sender
- NTP timestamp (上位32bit + 下位32bit)
- RTP timestamp
- 送信したパケット数（累積）
- 送信したオクテット数（累積）
- (後ろに複数の受信レポートブロックが付くことも)
特に重要なのが NTP timestamp と RTP timestamp の対応で、
これにより「このRTPの時刻は、実時間でこのあたり」という同期情報が得られます（音声と映像のリップシンクなど）。
5. Receiver Report（RR）
RR は RTPパケットを受信している側が送るレポートです。
（送信もしている場合は SR の中にも「受信レポートブロック」を含めます）
含まれる主な情報：
対象 SSRC
fraction lost（直近の喪失率）
cumulative number of packets lost（累積ロス数）
extended highest sequence number received（受信した最大シーケンス番号）
interarrival jitter（ジッタ）
LSR / DLSR（遅延計測用のフィールド）
これらを使って送信側は：
ネットワーク状態が悪いかどうか
ビットレートを落とすべきか
パケットロス補償のチューニング
などを判断します。
6. SDES（Source Description）
SDES は RTP ソース（SSRC）に関するメタ情報を伝えるパケットです。
代表的なアイテム：
CNAME（Canonical name）
NAME（表示名）
PHONE
TOOL（使用アプリ名）
NOTE（メモ）
一番重要なのは CNAME で、
「異なる SSRC だけど同一ユーザ／同一端末だよ」という識別に使います。
例：
CNAME = user@example.com
音声と映像で SSRC が違うときも、この CNAME が同じなら 同じ参加者の異なるメディアだとわかります。
7. BYE（セッション離脱通知）
RTCP BYE は 「この SSRC はセッションから抜けます」 という通知です。
会議から退出するとき
端末アプリを終了するとき
SSRC を変更するとき（再起動など）
に送られます。
RTP/RTCP の世界では、「黙ってフェードアウト」ではなく BYE を送るのがマナーです（ネットワーク障害時はもちろん無理ですが）。
8. RTCP の送信レート（帯域制御）
RTCP は 全体帯域のだいたい 5% 程度を目安に動作するよう設計されています（RFC3550 の目安）。
うち 25% は送信者用（SR）
残りは受信者用（RR）
つまりトータルのトラフィックの中で、RTCPはかなり軽量に抑えられるようになっています。
多人会議の場合：
参加者が増えると RTCP 送信間隔が自動で長くなる（頻度を下げる）
これにより、大人数でも RTCP が帯域を圧迫しにくい設計
9. SIP/SDP と RTCP の関係
SDP で RTP のポートが示された場合、RTCP は通常そのポート+1 で使われますが、
a=rtcp: 属性を使って 別ポートを指定することもできます。
例：
m=audio 49170 RTP/AVP 0
a=rtcp:53000
a=rtcp-mux
最近の WebRTC 系では RTCP multiplexing（rtcp-mux） が一般的で、
RTP と RTCP を同じポートで多重化することが多いです。
10. 実際のキャプチャを見るときのポイント
Wireshark などで RTP と RTCP を見るときは：
rtcp フィルタで RTCP パケットを抽出
SR / RR を時系列で見て、ロス率・ジッタを確認
CNAME を見て、どの SSRC が同じ参加者か把握
BYE が来ているかどうかで「正しく終了したか」をチェック
という見方をすると、メディア品質とセッション寿命を俯瞰しやすくなります。
11. まとめ
RTCP は RTP の制御用プロトコル
代表的なパケット：
SR：送信者レポート（統計＋NTP/RTP対応）
RR：受信者レポート（ロス/ジッタ報告）
SDES：CNAMEなどのソース情報
BYE：セッション離脱通知
全トラフィックの数％程度の軽い制御トラフィックとして設計
SIP/SDP からはポートや rtcp-mux などで関係が見える
Wireshark で SR/RR を読めると、品質トラブルの解析がかなり楽になる