RTP制御プロトコル

RTP制御プロトコル（RTCP）は、リアルタイムトランスポートプロトコル（RTP）と連携して動作する、バイナリエンコードされた帯域外シグナリングプロトコルです。RTCPは、RTPセッションの統計情報と制御情報を提供します。マルチメディアデータの配信とパッケージ化においてRTPと連携しますが、RTCP自体はメディアデータを転送しません。

RTCPの主な機能は、ストリーミングマルチメディアセッションの参加者に対し、送信されたオクテット数やパケット数、パケット損失、パケット遅延変動、往復遅延時間などの統計情報を定期的に送信することで、メディア配信におけるサービス品質（QoS）に関するフィードバックを提供することです。アプリケーションはこの情報を使用して、フローを制限したり、異なるコーデックを使用したりすることで、サービス品質パラメータを制御することができます。

通常、RTPは偶数番号のUDPポートで送信され、RTCPメッセージは次に大きい奇数番号のポートで送信されます。^{[ 1 ]}

RTCP自体はフロー暗号化や認証の方法を提供しません。このようなメカニズムは、例えばセキュアリアルタイムトランスポートプロトコル（SRTP）^{[ 2 ]で実装できます。}

RTCPは、すべてのRTPセッションで実装されることが期待される基本的な機能を提供します。

• RTCPの主な機能は、セッション中のメディア配信の品質に関する統計情報を収集し、そのデータをセッションのメディアソースおよび他のセッション参加者に送信することです。この情報は、ソース側で適応型メディアエンコーディング（コーデック）や伝送障害の検出に利用できます。セッションがマルチキャストネットワーク上で実行される場合、これにより非侵襲的なセッション品質監視が可能になります。
• RTCPは、セッション参加者全員に正規エンドポイント識別子（CNAME）を提供します。RTPストリームの送信元識別子（SSRC）は一意であることが期待されますが、送信元識別子とエンドポイントの即時的な関連付けはセッション中に変化する可能性があります。CNAMEは、アプリケーションインスタンス全体（複数のメディアツールの使用）およびサードパーティによる監視において、エンドポイントの一意な識別を確立します。
• セッション制御機能の提供。RTCPはすべてのセッション参加者に簡単にアクセスできる手段ですが、RTP自体はそうではありません。RTPはメディアソースを介してのみ送信されます。

RTCPレポートは、数千人の受信者が参加するマルチキャストセッションであっても、すべての参加者から送信されることが想定されます。このようなトラフィックは参加者数に比例して増加します。そのため、ネットワークの混雑を避けるために、プロトコルにはセッション帯域幅管理機能が組み込まれている必要があります。これは、レポート送信の頻度を動的に制御することで実現されます。RTCPの帯域幅使用量は、一般的にセッション全体の帯域幅の5%を超えないようにする必要があります。さらに、大規模な会議において、新規参加者が送信者のCNAME識別子を過度の遅延なく受信できるように、RTCP帯域幅の25%は常にメディアソース用に確保しておく必要があります。

RTCPレポートの送信間隔は、意図しない同期を防ぐためにランダム化されています。ステーションごとの推奨最小RTCPレポート間隔は5秒です。ステーションは、5秒に1回よりも頻繁にRTCPレポートを送信してはなりません。

バージョン： 2ビット

RTPのバージョンを識別します。これはRTCPパケットとRTPデータパケットで同じです。この仕様で定義されているバージョンは2です。

パディング （P）： 1ビット

RTPパケットの末尾に余分なパディングバイトがあるかどうかを示します。パディングは、例えば暗号化アルゴリズムで必要とされるように、特定のサイズのブロックを埋めるために使用されることがあります。パディングの最後のバイトには、追加されたパディングバイトの数（自身を含む）が格納されます。

受信レポート数 （RC）： 5ビット

このパケットに含まれる受信報告ブロックの数。0も有効な値です。

パケットタイプ （PT）： 8ビット

RTCPパケットの種類を識別するための定数が含まれています。

長さ： 16ビット

このRTCPパケットの長さ（ヘッダー自体を含む）を32ビット単位から1を引いた値で示します。

SSRC識別子： 32ビット

同期ソース識別子は、ストリームのソースを一意に識別します。

複数のレポートは、それぞれ独自のパケットヘッダーを持つ単一の複合RTCPパケットに連結できることに注意してください。

RTCPは、送信者レポート、受信者レポート、送信元記述、およびグッドバイなど、いくつかの種類のパケットを区別します。さらに、このプロトコルは拡張可能であり、アプリケーション固有のRTCPパケットを許可します。RTCPの標準ベースの拡張機能は、拡張レポートパケットタイプです。^{[ 4 ]}

送信者レポート（SR）

送信者レポートは、会議中のアクティブな送信者によって定期的に送信され、その期間中に送信されたすべての RTP パケットの送信および受信統計を報告します。送信者レポートには、2 つの異なるタイムスタンプが含まれます。1 つは、ネットワーク タイム プロトコル (NTP) のタイムスタンプ形式 (1900 年 1 月 1 日の 00 時 UTC を基準とした秒単位) で表された絶対タイムスタンプ、もう 1 つは、NTP タイムスタンプと同じ時刻ですが、この送信者レポートで説明されているデータ パケットの RTP タイムスタンプと同じ単位とランダム オフセットを持つ RTP タイムスタンプです。^{[ 3 ] : 12,37}絶対タイムスタンプにより、受信側は RTP メッセージを同期できます。音声とビデオが同時に送信される場合は、音声とビデオ ストリームが独立した相対タイムスタンプを使用するため、特に重要です。

受信者報告（RR）

受信側レポートは、RTPパケットを送信しない受動的な参加者向けです。このレポートは、送信者および他の受信者に対し、サービス品質に関する情報を提供します。

ソース記述（SDES）

ソース説明メッセージは、CNAME項目をセッション参加者に送信するために使用されます。また、ソースの所有者または管理者の名前、電子メールアドレス、電話番号、住所などの追加情報を提供するためにも使用できます。

さようなら（BYE）

ソースはBYEメッセージを送信してストリームをシャットダウンします。これにより、エンドポイントは会議から退出することを通知できます。他のソースはソースの不在を検出できますが、このメッセージは直接的な通知となります。また、メディアミキサーにとっても有用です。

アプリケーション固有のメッセージ（APP）

アプリケーション固有のメッセージは、RTCPプロトコルに対するアプリケーション固有の拡張機能を設計するためのメカニズムを提供する。

インターネット プロトコル テレビ(IPTV)などの大規模アプリケーションでは、輻輳を制御するために必要な RTCP 帯域幅制御メカニズム ( § プロトコル機能を参照) により、RTCP レポート間に非常に長い遅延 (数分から数時間) が発生する場合があります。許容される頻度は通常、1 分に 1 回未満です。これにより、受信側で関連する統計情報が不適切に報告される可能性が生じたり、メディア送信側による評価がセッションの現在の状態に対して不正確になったりする可能性があります。これらの問題を軽減するために、次の方法が導入されています。^{[ 5 ]} RTCP フィルタリング、RTCP バイアス、階層的集約。^{[ 6 ]}

• RFC 3550 – " RTP: リアルタイムアプリケーションのためのトランスポートプロトコル" 、インターネット標準64。 

• ストリーミングメディア
• VoIP（Voice over IP）

• パーキンス、コリン（2003）。RTP 。アディソン・ウェスリー。p.  414。ISBN 978-0-672-32249-5。
• ピーターソン、ラリー・L. 、ブルース・S. デイヴィー (2007)。コンピュータネットワーク（第4 版）。モーガン・カウフマン。p.  806。ISBN 978-0-12-374013-7。
• 「RTCP」。ネットワークプロトコルハンドブック。Javvin Technologies。2005年。ISBN 978-0-9740945-2-6。