RTP 制御プロトコル

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

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

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

RTCP 自体は、フローの暗号化や認証方法を提供しません。このようなメカニズムは、たとえば、 RFC 3711 で定義されているSecure Real-time Transport Protocol (SRTP) を使用して実装できます。

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

• RTCP の主な機能は、セッション中のメディア配信の品質に関する統計情報を収集し、このデータをセッション メディア ソースとその他のセッション参加者に送信することです。このような情報は、ソースによって適応型メディア エンコーディング (コーデック) と伝送障害の検出に使用されます。セッションがマルチキャスト ネットワーク経由で伝送される場合、これにより非侵入的なセッション品質監視が可能になります。
• RTCP は、すべてのセッション参加者に標準エンドポイント識別子 (CNAME) を提供します。RTP ストリームのソース識別子 (SSRC) は一意であることが期待されますが、ソース識別子とエンドポイントの瞬間的なバインドはセッション中に変更される可能性があります。CNAME は、アプリケーション インスタンス全体 (メディア ツールの複数の使用) およびサードパーティの監視のために、エンドポイントの一意の識別を確立します。
• セッション制御機能のプロビジョニング。RTCP はすべてのセッション参加者に到達するための便利な手段ですが、RTP 自体はそうではありません。RTP はメディア ソースによってのみ送信されます。

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

RTCP レポート間隔は、レポートの意図しない同期を防ぐためにランダム化されます。ステーションあたりの推奨最小 RTCP レポート間隔は 5 秒です。ステーションは、5 秒に 1 回以上 RTCP レポートを送信しないでください。

• バージョン: (2ビット) RTPのバージョンを識別します。これは、RTCPパケットでもRTPデータパケットでも同じです。この仕様で定義されているバージョンは2です。^[2]
• P (パディング) : (1 ビット) RTP パケットの末尾に追加のパディング バイトがあるかどうかを示します。パディングは、たとえば暗号化アルゴリズムの要件に応じて、特定のサイズのブロックを埋めるために使用される場合があります。パディングの最後のバイトには、追加されたパディング バイトの数 (それ自体を含む) が含まれます。^[2]
• RC（受信レポート数） :（5ビット）このパケットに含まれる受信レポートブロックの数。値0が有効です。^[2]
• PT（パケットタイプ） :（8ビット）RTCPパケットタイプを識別する定数が含まれます。^[2]
• 長さ: (16ビット) このRTCPパケットの長さ(ヘッダー自体を含む)を32ビット単位から1を引いた値で示します。^[2]
• SSRC : (32ビット)同期ソース識別子はストリームのソースを一意に識別します。^[2]

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

RTCPは、送信者レポート、受信者レポート、ソース記述、およびさようならといういくつかの種類のパケットを区別します。さらに、このプロトコルは拡張可能であり、アプリケーション固有のRTCPパケットを許可します。RTCPの標準ベースの拡張は、RFC 3611で導入された拡張レポートパケットタイプです^。[3]

送信者レポート (SR)

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

受信者レポート (RR)

受信者レポートは、RTP パケットを送信しない受動的な参加者向けです。レポートは、送信者と他の受信者にサービスの品質を通知します。

ソースの説明 (SDES)

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

さようなら（BYE）

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

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

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

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

階層的集約（または RTCP フィードバック階層とも呼ばれる）は、RTCP フィードバック モデルの最適化であり、その目的は、サービス品質（QoS）測定とともに、最大ユーザー数の制限をさらにシフトすることです。^{[6] [7]} RTCP帯域幅は一定で、セッション帯域幅のわずか 5% を占めます。したがって、QoS に関するレポート間隔は、とりわけセッションメンバー の数に依存し、非常に大規模なセッションでは非常に長くなる可能性があります（数分または数時間）。^[2]ただし、許容されるレポート間隔は約 10 秒です。値を大きくすると、現在のセッション ステータスに関するステータスの報告に時間がずれ、非常に不正確になり、送信者が行った最適化がネットワークまたは QoS 状態に悪影響を与える可能性があります。

階層的集約は、単一のソースのみが許可されるソース固有のマルチキャスト( IPTVなど) で使用されます。別のタイプのマルチキャストとしてAny-Source Multicastがありますが、これは膨大な数のユーザーがいる大規模なアプリケーションには適していません。

2007 年 6 月現在^[update]、最新の IPTV システムのみが階層型集約を使用しています。^{[引用が必要]}

^{フィードバックターゲットは、インターネットドラフトdraft-ietf-avt-rtcpssm-13 [8]}で初めて導入された新しいタイプのメンバーです。階層的集約方式により機能が拡張されました。このメンバーの機能は、受信者レポート(RR)( RTCPを参照)を受信し、要約されたRRパケット、いわゆる受信者要約情報(RSI) ^[8]を送信者に再送信することです(単一レベル階層の場合)。

• RFC  3550、標準 64、RTP: リアルタイム アプリケーション用のトランスポート プロトコル

• ストリーミングメディア
• ボイスオーバー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。