【ITニュース解説】🛠️ RTCP - The RTP Caretaker

RTP (Real-time Transport Protocol) は、音声や動画といったリアルタイム性の高いメディアデータをインターネット上で送るための重要な仕組みである。しかし、RTPだけでは、そのデータがきちんと届いているか、通信の品質は良いのか悪いのかといった状況を把握することはできない。そこで登場するのが、RTCP (Real-Time Control Protocol) だ。RTCPは、RTPが運ぶメディアストリームの「番人」とも言える存在で、通信の品質監視、ストリームの同期、通信状況の報告といった役割を担っている。

RTCPは、RTPと同じくRFC 3550という技術仕様書で定められており、RTPストリームを制御する「コントロールプレーン」として機能する。RTPが実際の音声や動画のデータを送り届ける「メディアプレーン」であるのに対し、RTCPは、そのメディアプレーンの動きを監視し、必要な情報を提供する役割分担をしているのだ。

RTCPが存在する主な理由はいくつかある。まず第一に、通信品質のフィードバックを行うことだ。インターネットの通信状況は常に変化するため、送られたパケットの一部が失われたり、遅延したり、届く順番が乱れたりすることがある。これを「パケットロス」「遅延」「ジッター」と呼ぶが、RTCPはこれらの通信品質に関する統計情報を収集し、定期的に報告する。これにより、送信側はネットワークの状況を把握し、必要に応じてデータ送信方法を調整できる。

次に、ストリームの同期もRTCPの重要な役割だ。例えば、ビデオ会議では音声と動画が同時に送られるが、これらがバラバラに届いてしまうと、話している人の口の動きと音声がずれてしまう。RTCPは、NTP (Network Time Protocol) タイムスタンプとRTPタイムスタンプを用いて、異なるメディアストリーム（例えば音声と動画）の時間軸を正確に合わせる手助けをする。

さらに、参加者の識別も行う。リアルタイム通信では、複数の参加者がいる場合がある。RTCPは、各参加者にSSRC (Synchronization Source) と呼ばれるユニークな識別子を割り当てることで、誰がどのストリームを送っているのかを明確にする。これにより、例えばビデオ会議で誰が話しているのか、どの映像が誰のものなのかを判別できるようになる。また、RTCPは自身の帯域幅をRTPのメディアストリームと競合しないように管理することで、システムの拡張性（スケーラビリティ）を保つ役割も果たす。

RTCPパケットは、数秒おきに定期的に送られる。このパケットには、パケットロス、ジッター、RTT（Round-Trip Time：送受信間の往復時間）といった品質情報が含まれる。また、送信側が送ったRTPパケットの総数などの統計情報や、CNAME（Canonical Name）のような送信元に関する情報（Source Description）も運ぶ。さらに、必要に応じて特定のRTPパケットの再送を要求するNACK (Negative Acknowledgment) や、ビデオストリームで映像が乱れた際に新しいキーフレームの送信を要求するPLI (Picture Loss Indication) といったフィードバックメカニズムも提供する。

プロトコルスタックにおいて、RTCPはRTPと同じ層で動作する。アプリケーションのシグナリング（SIPやSDPなど）の下に位置し、RTCPとRTPがその下でUDPやDTLSといったトランスポート層プロトコルを利用し、さらにその下にIP層がある。RTPがメディアストリームを運び、RTCPが制御やフィードバックストリームを運ぶが、これらは通常、隣接するUDPポート番号を使って通信される。例えば、RTPがポートNを使えば、RTCPはポートN+1を使うといった具合だ。

RTCPパケットの構造は、共通のヘッダー部分から始まる。このヘッダーには、プロトコルのバージョン（通常は2）、パディングの有無を示すビット、パケットの種類によって意味が変わるカウント値、そしてRTCPメッセージの具体的な種類を示すパケットタイプ、最後にこのRTCPパケット全体の長さを示すフィールドが含まれる。

RTCPにはいくつかの主要なメッセージタイプがある。 最も重要なものが「Sender Report (SR) 」だ。これは、アクティブにメディアデータを送信している参加者（送信者）が送る。SRには、リアルタイムの時刻を示すNTPタイムスタンプと、メディアデータの時間軸を示すRTPタイムスタンプが含まれ、これらはストリームの同期に使われる。また、送信したパケット数やバイト数といった統計情報も報告され、全体の送受信状況の監視に役立つ。

もう一つ重要なのが「Receiver Report (RR) 」だ。これは、メディアデータを受信している参加者（受信者）が送る。RRには、受信側から見たパケットロス率、ジッターの数値、最後に受信したSRパケットのタイムスタンプとそれからの遅延などの情報が含まれる。これにより、送信側は各受信側でのメディア品質の状況を把握できる。

「Source Description (SDES)」は、参加者に関するメタデータを提供する。例えば、参加者の正式名称（CNAME）、名前、使用しているツールなどの情報が含まれる。 「BYE」は、参加者が通信を終了する際に、他の参加者にその旨を知らせるためのメッセージだ。 「APP」は、アプリケーション固有の拡張機能のために予約されており、特定の用途でカスタムなRTCPメッセージを定義する際に用いられる。 「Extended Reports (XR)」は、後に定義された拡張で、より詳細な統計情報（例えば、往復遅延の測定値やバースト通信の状況）を報告するために使われる。 さらに、RTP/AVPFの拡張機能として、「NACK（Negative ACK）」は失われたRTPパケットの再送を要求するものであり、「PLI (Picture Loss Indication)」はビデオストリームで映像が乱れた際に、新しい完全なフレーム（キーフレーム）の送信を要求する。

実際のRTCPパケットを見ると、これらの情報がどのように格納されているかが分かる。例えば、WiresharkでキャプチャされたRTCP Sender Report（SR）パケットの例では、ヘッダー部分からプロトコルバージョン、パケットタイプがSRであること、パケットの長さなどが読み取れる。続いて、送信者を一意に識別するSSRC、時刻同期のためのNTPタイムスタンプとRTPタイムスタンプ、そして送信者がどれだけのパケットやバイト数を送ったかを示すカウント値が続く。さらに、受信側からの品質情報を含むレポートブロックも含まれる。このレポートブロックには、パケットロス率、累積のロス数、受信したシーケンス番号の最高値、ジッター、そして前回のSRからの遅延といった、受信側での品質指標が詳細に記録されている。

このように、たった一つのRTCPパケットが、誰が送信者であるか、いつメディアが送信されたか、どれくらいのメディアが送られたか、そして受信側がどのような品質でそれを受け取っているか、といった多岐にわたる重要な情報を提供している。Sender Report（SR）とReceiver Report（RR）が連携することで、RTPによるリアルタイム通信の信頼性と品質を維持するための制御ループが形成されるのである。

RTCPは実生活の様々なシーンで利用されている。例えば、VoIP（Voice over IP）通話の品質監視では、RTCPのReceiver Reportが示すパケットロス率やジッターの統計情報から、通話品質の問題を特定できる。WiresharkのようなVoIP監視ツールは、これらのRTCP統計を利用して通話の状況を可視化している。ビデオ通話では、受信側で映像が破損した場合にPLIメッセージを送信することで、送信側は新しいキーフレームを送って映像を回復させることができる。また、大規模な会議システムでは、複数の参加者からの音声と動画ストリームを正確に同期させるために、Sender Reportのタイムスタンプ情報が不可欠となる。

ポートの使用方法についても、歴史的にはRTPが特定のポートNを使い、RTCPはその隣のポートN+1を使うのが一般的であった。しかし、現代のシステムでは「RTCP Mux (RFC 5761)」や「Bundle (RFC 8843)」といった技術が使われることが多い。RTCP Muxでは、RTPとRTCPが同じUDPポートを共有することで、リソースを節約し、NATやファイアウォールを通過しやすくする。Bundleでは、さらに複数のメディアストリーム（音声、動画、データなど）が単一のIPアドレスとポート番号の組み合わせ（5-tuple）を共有することで、より効率的な通信と管理を実現する。これらは、NATやファイアウォールを越えた通信を容易にし、管理するポート数を減らし、ICE/STUN/TURNといった接続確立プロトコルとの連携をよりスムーズにするという利点がある。

RTCPは、RTPがメディアを運び、そのメディアの流れを監視し、品質に関するレポートやフィードバック、メタデータを提供することで、リアルタイム通信が公正かつ円滑に動作することを保証する。最新の環境では、RTCP-muxやBundleといった技術によって、その利用がさらに効率化されている。RTCPは、リアルタイム通信の世界において、目立つ存在ではないが、その裏側で通信の品質と安定性を支える、非常に重要なプロトコルなのだ。