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

RFC 3550 - 3. 定義

3. 定義 (Definitions)​

RTP ペイロード (RTP payload)：RTP がパケットで運ぶデータ。たとえば音声サンプルや圧縮映像データ。ペイロードの形式と解釈は本書の範囲外である。

RTP パケット (RTP packet)：固定 RTP ヘッダ、寄与送信元の（後述の）空であり得るリスト、およびペイロードデータからなるデータパケット。いくつかの下位プロトコルは、RTP パケットのカプセル化の定義を必要とする場合がある。典型的には、下位プロトコルの 1 パケットに単一の RTP パケットが含まれるが、カプセル化方式が許せば複数の RTP パケットが含まれてもよい（セクション 11 参照）。

RTCP パケット (RTCP packet)：RTP データパケットと似た固定ヘッダ部に続き、RTCP パケット種別によって異なる構造化要素が続く制御パケット。形式はセクション 6 で定義される。典型的には、複数の RTCP パケットがまとめて、下位プロトコルの単一パケット内の複合 RTCP パケットとして送信される。これは、各 RTCP パケットの固定ヘッダ内の length フィールドによって可能となる。

ポート (Port)：「トランスポートプロトコルが、与えられたホストコンピュータ内の複数の宛先を区別するために用いる抽象概念。TCP/IP プロトコルは小さな正の整数を用いてポートを識別する。」[12] OSI トランスポート層が用いるトランスポートセレクタ（TSEL）はポートと等価である。RTP は、セッションの RTP および RTCP パケットを多重化するため、ポートなどの何らかの仕組みを下位層プロトコルに依存して提供する。

トランスポートアドレス (Transport address)：トランスポートレベルの端点を識別する、ネットワークアドレスとポートの組。たとえば IP アドレスと UDP ポート。パケットは送信元トランスポートアドレスから宛先トランスポートアドレスへ送信される。

RTP メディアタイプ (RTP media type)：単一の RTP セッション内で運べるペイロード種別の集合。RTP プロファイルは、RTP メディアタイプを RTP ペイロード種別に割り当てる。

マルチメディアセッション (Multimedia session)：共通の参加者グループ間の、同時に行われる一連の RTP セッション。たとえばビデオ会議（これはマルチメディアセッションである）は、音声 RTP セッションと映像 RTP セッションを含み得る。

RTP セッション (RTP session)：RTP で通信する一組の参加者間の関連。参加者は同時に複数の RTP セッションに関与してよい。マルチメディアセッションでは、符号化自体が複数メディアを単一のデータストリームに多重化しない限り、各メディアは通常、独自の RTCP パケットを持つ別々の RTP セッションで運ばれる。参加者は、異なる宛先トランスポートアドレスの組を用いて異なるセッションを受信することで、複数の RTP セッションを区別する。ここでトランスポートアドレスの組とは、1 つのネットワークアドレスと、RTP 用および RTCP 用の 1 組のポートからなる。RTP セッションのすべての参加者は、IP マルチキャストの場合のように共通の宛先トランスポートアドレス組を共有してもよいし、各参加者ごとに組が異なってもよい（個別ユニキャストのネットワークアドレスとポートの組の場合）。ユニキャストの場合、参加者はセッション内の他のすべての参加者から同じポートの組を用いて受信しても、各参加者ごとに異なるポートの組を用いてもよい。

  RTP セッションを特徴づける点は、各セッションが SSRC 識別子（次に定義）の完全に独立した空間を維持することである。1 つの RTP セッションに含まれる参加者の集合は、いずれかの参加者が送信した SSRC 識別子を、RTP の SSRC または CSRC（いずれも以下で定義）として、あるいは RTCP で受信できる者すべてからなる。たとえば、ユニキャスト UDP を用いて実装され、各参加者が別のポートの組で他の 2 者から受信する 3 者会議を考えよう。各参加者が、他の 1 参加者から受信したデータについての RTCP フィードバックをその参加者だけに送り返す場合、その会議は 3 つの独立した点对点 RTP セッションから構成される。各参加者が、他の 1 参加者についての自らの受信に関する RTCP フィードバックを、他の 2 参加者の両方に提供する場合、その会議は 1 つの多者 RTP セッションから構成される。後者の場合は、3 者間で IP マルチキャスト通信を行った場合に生じる振る舞いをシミュレートする。

  RTP フレームワークはここで定義された変種を許すが、特定の制御プロトコルやアプリケーション設計は、通常これらの変種に制約を課す。

同期送信元 (Synchronization source, SSRC)：RTP パケットのストリームの送信元。RTP ヘッダに担持される 32 ビットの数値 SSRC 識別子によって識別され、ネットワークアドレスに依存しない。同期送信元からのすべてのパケットは同一のタイミングおよびシーケンス番号空間の一部を成すので、受信側は再生のためにパケットを同期送信元ごとにグループ化する。同期送信元の例には、マイクロフォンやカメラといった信号源から導出されたパケットストリームの送信側、あるいは RTP ミキサ（後述）などがある。同期送信元は、時間とともにデータ形式（音声符号化など）を変えてよい。SSRC 識別子は、特定の RTP セッション内でグローバルに一意であることを意図したランダムに選ばれた値である（セクション 8 参照）。参加者は、マルチメディアセッション内のすべての RTP セッションに同じ SSRC 識別子を用いる必要はない。SSRC 識別子の束縛は RTCP を通じて提供される（セクション 6.5.1 参照）。参加者が 1 つの RTP セッション内で複数のストリーム（別々のビデオカメラからなど）を生成する場合、それぞれは異なる SSRC として識別されなければならない。

寄与送信元 (Contributing source, CSRC)：RTP ミキサ（後述）が生成した統合ストリームに寄与した RTP パケットのストリームの送信元。ミキサは、特定のパケットの生成に寄与した送信元の SSRC 識別子のリストを、そのパケットの RTP ヘッダに挿入する。このリストを CSRC リストという。応用例として、ミキサが出力パケットの生成に合成されたすべての発話者の音声を示す音声会議があり、すべての音声パケットが同じ SSRC 識別子（ミキサのもの）を含んでいても、受信側が現在の発話者を表示できる。

エンドシステム (End system)：RTP パケットで送信される内容を生成し、および／または受信した RTP パケットの内容を消費するアプリケーション。エンドシステムは特定の RTP セッション内で 1 つ以上の同期送信元として働き得るが、典型的には 1 つだけである。

ミキサ (Mixer)：1 つ以上の送信元から RTP パケットを受信し、場合によってはデータ形式を変更し、何らかの方法でパケットを結合したうえで新たな RTP パケットを転送する中間システム。複数の入力送信元間のタイミングは一般に同期していないため、ミキサはストリーム間でタイミングの調整を行い、統合ストリームに対して独自のタイミングを生成する。したがって、ミキサから発信されたすべてのデータパケットは、その同期送信元がミキサであると識別される。

トランスレータ (Translator)：同期送信元識別子をそのままに RTP パケットを転送する中間システム。トランスレータの例には、ミキシングなしで符号化を変換する装置、マルチキャストからユニキャストへの複製器、およびファイアウォール内のアプリケーション層フィルタなどがある。

モニタ (Monitor)：RTP セッション内の参加者が送信する RTCP パケット、とくに受信報告を受信し、配信監視、障害診断、長期統計のために現在のサービス品質を推定するアプリケーション。モニタ機能は、そのセッションに参加するアプリケーションに組み込まれる可能性が高いが、それ以外には参加せず、RTP データパケット（別のポート上にあるため）の送受信も行わない別のアプリケーションであってもよい。これらをサードパーティモニタという。サードパーティモニタが RTP データパケットを受信してもよいが、RTCP パケットを送信せず、セッション内で数えられることもない。

非 RTP 手段 (Non-RTP means)：利用可能なサービスを提供するために RTP に加えて必要となるかもしれないプロトコルとメカニズム。とくにマルチメディア会議では、制御プロトコルがマルチキャストアドレスと暗号化鍵を配布し、使用する暗号化アルゴリズムをネゴシエートし、あらかじめ定義されたペイロード種別値を持たない形式について、RTP ペイロード種別値とそれらが表すペイロード形式の間の動的マッピングを定義するかもしれない。このようなプロトコルの例には、セッション開始プロトコル（SIP）（RFC 3261 [13]）、ITU 勧告 H.323 [14]、および RTSP（RFC 2326 [16]）のような SDP（RFC 2327 [15]）を用いるアプリケーションがある。単純なアプリケーションでは、電子メールや会議データベースも用いられ得る。このようなプロトコルとメカニズムの仕様は本書の範囲外である。