RTP制御プロトコル
RTP制御プロトコル
通信プロトコル
略語RTCP
目的サービス品質に関するフィードバックを提供する
開発者コロンビア大学
はじめに2003年7月 （2003-07年）
RFC3550

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

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レポートを送信しないでください。

パケットヘッダー

RTCPパケットヘッダー[ 3 ]
オフセットオクテット0 1 2 3
オクテット ビット0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 バージョンPRCPT長さ
4 32 SSRC識別子
バージョン：2ビット
RTPのバージョンを識別します。RTCPパケットとRTPデータパケットで同じです。この仕様で定義されているバージョンは2です
パディング （P）：1ビット
RTPパケットの末尾に追加のパディングバイトがあるかどうかを示します。パディングは、例えば暗号化アルゴリズムの要件などにより、特定のサイズのブロックを埋めるために使用される場合があります。パディングの最後のバイトには、追加されたパディングバイトの数（そのバイト自体を含む）が含まれます。
受信レポートカウント （RC）：5ビット
このパケットに含まれる受信レポートブロックの数。有効な値は0です。
パケットタイプ （PT）：8ビット
RTCP パケット タイプを識別する定数が含まれます。
長さ：16ビット
このRTCPパケットの長さ（ヘッダー自体を含む）を32ビット単位から1を引いた値で示します
SSRC識別子: 32ビット
同期ソース識別子は、ストリームのソースを一意に識別します。

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

メッセージの種類

RTCPは、送信者レポート、受信者レポート、ソース記述、そしてグッドバイという複数の種類のパケットを区別します。さらに、このプロトコルは拡張可能であり、アプリケーション固有のRTCPパケットを許可します。RTCPの標準ベースの拡張として、拡張レポートパケットタイプがあります。[ 4 ]

送信者レポート（SR）
送信者レポートは、会議中のアクティブな送信者によって定期的に送信され、その間隔中に送信されたすべてのRTPパケットの送受信統計を報告します。送信者レポートには、2つの異なるタイムスタンプが含まれます。1つはネットワークタイムプロトコル（NTP）のタイムスタンプ形式（1900年1月1日午前0時（UTC）を基準とした秒単位）で表される絶対タイムスタンプ、もう1つはNTPタイムスタンプと同じ時間に対応するRTPタイムスタンプです。RTPタイムスタンプは、この送信者レポートで記述されたデータパケット内のRTPタイムスタンプと同じ単位とランダムオフセットを持ちます。[ 3 ]：12,37 絶対タイムスタンプにより、受信側はRTPメッセージを同期できます。オーディオとビデオのストリームはそれぞれ独立した相対タイムスタンプを使用するため、オーディオとビデオの両方が同時に送信される場合は特に重要です
受信者レポート（RR）
受信者レポートは、RTPパケットを送信しない受動的な参加者のためのものです。このレポートは、送信者と他の受信者にサービス品質に関する情報を通知します
ソース記述（SDES）
ソース記述メッセージは、セッション参加者にCNAMEアイテムを送信するために使用されます。また、ソースの所有者または管理者の名前、メールアドレス、電話番号、住所などの追加情報を提供するためにも使用される場合があります
さようなら（BYE）
ソースはストリームを終了するためにBYEメッセージを送信します。これにより、エンドポイントは会議から退出することを通知できます。他のソースはソースの不在を検出できますが、このメッセージは直接的な通知です。メディアミキサーにも役立ちます
アプリケーション固有メッセージ（APP）
アプリケーション固有メッセージは、RTCPプロトコルのアプリケーション固有の拡張を設計するためのメカニズムを提供します

大規模展開におけるスケーラビリティ

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

階層的集約

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

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

2007 年 6 月現在、階層型集約を使用しているのは最新の IPTV システムのみです。

フィードバックターゲット

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

標準文書

  • RFC  3550 - 「RTP：リアルタイムアプリケーションのためのトランスポートプロトコル」 、インターネット標準64

参照

参考文献

  1. ^ C. Huitema (2003年10月).セッション記述プロトコル（SDP）におけるリアルタイム制御プロトコル（RTCP）属性. ネットワークワーキンググループ. doi : 10.17487/RFC3605 . RFC 3605 .提案された標準
  2. ^ M. Baugher 、 D. McGrew 、M. Naslund、E. Carrara、K. Norrman（2004年3月）。セキュアリアルタイムトランスポートプロトコル（SRTP）。ネットワークワーキンググループ。doi : 10.17487/ RFC3711。RFC 3711情報提供。RFC 9335、5506、6904  により更新されました。
  3. ^ a b c H. Schulzrinne; S. Casner; R. Frederick; V. Jacobson (2003年7月). RTP: リアルタイムアプリケーションのためのトランスポートプロトコル. ネットワークワーキンググループ. doi : 10.17487/RFC3550 . STD 64. RFC 3550 .インターネット標準64。RFC 8860、7160、5761、5506、6051、6222、7022、7164、8083  により更新。RFC 1889は廃止。​​​​​​​​​​​ ​​
  4. ^ T. Friedman、R . Caceres、A. Clark編（2003年11月）。RTP制御プロトコル拡張レポート（RTCP XR） 。ネットワークワーキンググループ。doi ：10.17487/ RFC3611。RFC 3611。提案された標準
  5. ^ Vít Novotný、Dan Komosný、 Large-Scale RTCP Feedback Optimization、Journal of Networks、Vol.3 (3)、2008 年 3 月
  6. ^インターネットプロトコルテレビのリアルタイム制御プロトコルとその改良
  7. ^ KOMOSNY D., NOVOTNY V. Tree Structure for Specific-Source Multicast with feedback Aggregation, ICN07 - The Sixth International Conference on Networking . Martinique, 2007 ISBN 0-7695-2805-8
  8. ^ NOVOTNY, V., KOMOSNY, D. ICWMC 2007における大規模RTCPフィードバック報告の最適化。ICWMC 2007 - 第3回国際無線通信会議。グアドループ、2007年ISBN 0-7695-2796-5
  9. ^ a b J. Ott、J. Chesterfield、E. Schooler（2010年2月）。ユニキャストフィードバック付きシングルソースマルチキャストセッションのためのRTCP拡張。インターネット技術タスクフォース。doi : 10.17487/ RFC5760。RFC 5760提案 された標準。RFC 6128 によって更新されました。

参考文献

  • パーキンス、コリン（2003年）。RTP 、アディソン・ウェスレー。414ページ。ISBN 978-0-672-32249-5。
  • ラリー・L・ピーターソン、ブルース・S・デイビー（2007年）。『コンピュータネットワーク』（第4版）。モーガン・カウフマン。806ページ。ISBN 978-0-12-374013-7。
  • 「RTCP」 .ネットワークプロトコルハンドブック. Javvin Technologies. 2005. ISBN 978-0-9740945-2-6。
「 https://en.wikipedia.org/w/index.php?title=RTP_Control_Protocol&oldid=1333245221」より取得