RFC 3550 - 1. はじめに
1. はじめに (Introduction)
本覚書はリアルタイム転送プロトコル (Real-time Transport Protocol, RTP) を定義する。RTP は、対話型音声や映像といったリアルタイム特性を持つデータに対して、エンドツーエンドの配信サービスを提供する。これらのサービスには、ペイロード種別識別、シーケンス番号付け、タイムスタンプ付け、および配信監視が含まれる。アプリケーションは通常、UDP 上で RTP を動作させ、UDP の多重化およびチェックサムサービスを利用する。両プロトコルが協調して転送プロトコルとしての機能を構成する。ただし、RTP は他の適切な下位ネットワークまたはトランスポートプロトコルとともに使用することもできる（セクション 11 参照）。RTP は、下位ネットワークが提供する場合、マルチキャスト配信を用いた複数宛先へのデータ転送をサポートする。
なお RTP 自体は、タイムリーな配信を保証する仕組みや、その他のサービス品質 (Quality of Service, QoS) 保証を提供するものではなく、それらは下位層のサービスに依存する。RTP は配信の確実性を保証せず、順序外配信も防がない。また、下位ネットワークが信頼でき、パケットを順序通りに届けることも仮定しない。RTP に含まれるシーケンス番号により、受信側は送信側のパケットシーケンスを再構成できる。ただしシーケンス番号は、たとえば映像復号において必ずしも順番に復号せずとも、パケットの適切な位置を決定するためにも利用できる。
RTP は主として多参加者マルチメディア会議の要求を満たすように設計されているが、その特定のアプリケーションに限定されるものではない。連続データの蓄積、対話型分散シミュレーション、アクティブバッジ、および制御・計測アプリケーションにも RTP は適用可能である。
本書は RTP を定義し、密接に関連する 2 つの部分から構成される。
o リアルタイム転送プロトコル (RTP) — リアルタイム特性を持つデータを運ぶためのもの。
o RTP 制御プロトコル (RTP Control Protocol, RTCP) — サービス品質を監視し、進行中のセッションにおける参加者の情報を伝達するためのもの。RTCP の後者の側面は、「緩やかに制御された (loosely controlled)」セッション、すなわち明示的なメンバーシップ管理やセットアップのないセッションに対して十分である場合がある。ただし、アプリケーションのすべての制御通信要件をサポートすることは意図されていない。この機能は、本書の範囲外である別のセッション制御プロトコルによって、完全または部分的に包含されてもよい。
RTP は、Clark と Tennenhouse [10] が提唱したアプリケーション層フレーミング (Application Level Framing) および統合レイヤ処理 (Integrated Layer Processing) の原則に従う新しいスタイルのプロトコルを表す。すなわち RTP は、特定のアプリケーションが要求する情報を提供できるよう、柔軟に調整 (malleable) されるよう意図されており、しばしば別層としてではなくアプリケーション処理に統合される。RTP は、あえて完全なプロトコルではないフレームワークである。本書は、RTP が適切と考えられるあらゆるアプリケーションに共通すると期待される機能を規定する。従来のプロトコルでは追加機能をプロトコルの汎用化や、解析を要するオプションメカニズムの追加によって吸収するかもしれないが、RTP は必要に応じたヘッダの修正および／または追加によって調整されることを意図している。例はセクション 5.3 および 6.4.3 にある。
したがって、本書に加えて、特定のアプリケーション向けの RTP の完全な仕様には、1 つ以上の関連文書（セクション 13 参照）が必要となる。
o プロファイル仕様文書 — 一連のペイロード種別コードと、それらのペイロード形式（メディア符号化方式など）へのマッピングを定義する。プロファイルは、特定のアプリケーションクラスに特有の RTP の拡張や修正を定義することもある。典型的には、アプリケーションは 1 つのプロファイルの下でのみ動作する。音声および映像データのプロファイルは、関連 RFC 3551 [1] にある。
o ペイロード形式仕様文書 — 音声や映像の符号化方式などの特定のペイロードを 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 実装に対する要求レベルを示す。