メインコンテンツまでスキップ

1. はじめに (Introduction)

本メモランダムは、リアルタイム特性を持つデータ（インタラクティブな音声やビデオなど）に対してエンドツーエンドの配信サービスを提供する、リアルタイム転送プロトコル (Real-time Transport Protocol, RTP) を規定します。これらのサービスには、ペイロードタイプ識別、シーケンス番号付け、タイムスタンプ、および配信監視が含まれます。アプリケーションは通常、多重化とチェックサムサービスを利用するために、UDP上でRTPを実行します。両プロトコルは転送プロトコル機能の一部を提供します。ただし、RTPは他の適切な基盤ネットワークまたは転送プロトコルと共に使用することもできます（セクション11を参照）。RTPは、基盤ネットワークによって提供される場合、マルチキャスト配信を使用した複数の宛先へのデータ転送をサポートします。

RTP自体は、タイムリーな配信を保証したり、その他のサービス品質保証を提供するメカニズムを持たず、下位層サービスに依存することに注意してください。配信を保証せず、順序外配信を防止せず、基盤ネットワークが信頼性があり、パケットを順番に配信すると仮定しません。RTPに含まれるシーケンス番号により、受信者は送信者のパケットシーケンスを再構築できますが、シーケンス番号は、たとえばビデオデコードにおいて、必ずしも順番にパケットをデコードすることなく、パケットの適切な位置を決定するためにも使用される場合があります。

RTPは主に多参加者マルチメディア会議のニーズを満たすように設計されていますが、その特定のアプリケーションに限定されません。連続データの保存、インタラクティブ分散シミュレーション、アクティブバッジ、制御および測定アプリケーションもRTPを適用可能と見なす場合があります。

本文書は、2つの密接に関連する部分で構成されるRTPを定義します:

  • リアルタイム転送プロトコル (Real-time Transport Protocol, RTP): リアルタイム特性を持つデータを伝送します。

  • RTP制御プロトコル (RTP Control Protocol, RTCP): サービス品質を監視し、進行中のセッションの参加者に関する情報を伝達します。RTCPの後者の側面は、「緩やかに制御された」セッション、すなわち明示的なメンバーシップ制御とセットアップがない場合には十分である可能性がありますが、必ずしもアプリケーションのすべての制御通信要件をサポートすることを意図しているわけではありません。この機能は、本文書の範囲外である別個のセッション制御プロトコルによって完全または部分的に代替される場合があります。

RTPは、ClarkとTennenhouseによって提案されたアプリケーションレベルフレーミングと統合層処理の原則に従う新しいスタイルのプロトコルを表します [10]。つまり、RTPは特定のアプリケーションに必要な情報を提供するために柔軟であることを意図しており、多くの場合、別個の層として実装されるのではなく、アプリケーション処理に統合されます。RTPは意図的に完全ではないプロトコルフレームワークです。本文書は、RTPが適切であるすべてのアプリケーションに共通すると予想される機能を規定します。追加機能がプロトコルをより一般的にするか、解析を必要とするオプションメカニズムを追加することによって対応される従来のプロトコルとは異なり、RTPは必要に応じてヘッダーへの変更および/または追加を通じてカスタマイズされることを意図しています。例はセクション5.3および6.4.3に示されています。

したがって、本文書に加えて、特定のアプリケーション向けのRTPの完全な仕様には、1つ以上の付属文書が必要です（セクション13を参照）:

  • プロファイル仕様文書: ペイロードタイプコードのセットとそれらのペイロードフォーマット（例: メディアエンコーディング）へのマッピングを定義します。プロファイルは、特定のクラスのアプリケーションに固有のRTPへの拡張または変更を定義する場合もあります。通常、アプリケーションは1つのプロファイルの下でのみ動作します。音声およびビデオデータのプロファイルは、付属のRFC 3551 [1] にあります。

  • ペイロードフォーマット仕様文書: 音声またはビデオエンコーディングなどの特定のペイロードがRTPでどのように伝送されるかを定義します。

リアルタイムサービスとその実装のためのアルゴリズムに関する議論、およびRTP設計決定に関する背景議論は [11] にあります。

1.1 用語 (Terminology)​

本文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、BCP 14、RFC 2119 [2] に記載されているとおりに解釈されるものとし、準拠するRTP実装の要件レベルを示します。

に最終更新