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

RFC 3550 - 5. RTP データ転送プロトコル

5. RTP データ転送プロトコル (RTP Data Transfer Protocol)​

5.1 RTP 固定ヘッダフィールド (RTP Fixed Header Fields)​

RTP ヘッダの形式は以下のとおりである。

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

最初の 12 オクテットはすべての RTP パケットに存在し、CSRC 識別子のリストはミキサによって挿入される場合にのみ存在する。各フィールドの意味は以下のとおり。

version (V)：2 ビット このフィールドは RTP のバージョンを識別する。本書で定義されるバージョンは 2 である。（値 1 は RTP の最初のドラフト版で用いられ、値 0 は "vat" 音声ツールで最初に実装されたプロトコルで用いられる。）

padding (P)：1 ビット パディングビットがセットされている場合、パケットの末尾に、ペイロードの一部ではない 1 つ以上の追加パディングオクテットが含まれる。パディングの最後のオクテットは、それ自身を含めていくつのパディングオクテットを無視すべきかのカウントを保持する。パディングは、固定ブロックサイズの暗号化アルゴリズムや、下位層プロトコルデータユニット内に複数の RTP パケットを運ぶ場合に必要となることがある。

extension (X)：1 ビット 拡張ビットがセットされている場合、固定ヘッダの直後には、セクション 5.3.1 で定義される形式のヘッダ拡張が厳密に 1 つ続かなければならない。

CSRC count (CC)：4 ビット CSRC カウントは、固定ヘッダに続く CSRC 識別子の数を含む。

marker (M)：1 ビット マーカの解釈はプロファイルにより定義される。フレーム境界などの重要なイベントをパケットストリーム内にマークできるように意図されている。プロファイルは、ペイロード種別フィールドのビット数を変更することで（セクション 5.3 参照）、追加のマーカビットを定義したり、マーカビットが存在しないことを規定したりしてよい。

payload type (PT)：7 ビット このフィールドは RTP ペイロードの形式を識別し、アプリケーションによるその解釈を決定する。プロファイルは、ペイロード種別コードからペイロード形式へのデフォルトの静的マッピングを規定してよい。追加のペイロード種別コードは、非 RTP 手段を通じて動的に定義されてよい（セクション 3 参照）。音声と映像のデフォルトマッピングの一式は、関連 RFC 3551 [1] で規定されている。RTP 送信元はセッション中にペイロード種別を変更してよいが、このフィールドを別々のメディアストリームの多重化に用いるべきではない（セクション 5.2 参照）。

  受信側は、理解できないペイロード種別を持つパケットを無視しなければならない。

sequence number：16 ビット シーケンス番号は、送信された各 RTP データパケットごとに 1 ずつ増加し、受信側がパケット欠落を検出しパケットシーケンスを復元するために用いられてよい。シーケンス番号の初期値は、暗号文攻撃（known-plaintext attack）をより困難にするため、ランダム（予測不能）であるべきである。たとえ送信元自身がセクション 9.1 の方式に従って暗号化しなくとも、パケットがそうするトランスレータを通過する可能性があるからである。予測不能な数を選ぶ技法は [17] で論じられている。

timestamp：32 ビット タイムスタンプは、RTP データパケット内の最初のオクテットのサンプリング瞬間を反映する。サンプリング瞬間は、同期とジッタ計算を可能にするため（セクション 6.4.1 参照）、時間とともに単調かつ線形に増加するクロックから導出されなければならない。クロックの分解能は、望ましい同期精度およびパケット到着ジッタの測定（ビデオフレームごとに 1 刻みでは通常不十分）のために十分でなければならない。クロック周波数は、ペイロードとして運ばれるデータの形式に依存し、その形式を定義するプロファイルまたはペイロード形式仕様で静的に規定されるか、非 RTP 手段で定義されたペイロード形式に対して動的に規定されてよい。RTP パケットが定期的にも生成される場合、システムクロックの読み取りではなく、サンプリングクロックから決定される名目のサンプリング瞬間を用いるべきである。例として、固定レートの音声では、タイムスタンプクロックは各サンプリング周期ごとにおそらく 1 ずつ増加する。ある音声アプリケーションが入力デバイスから

  160 サンプリング周期を覆うブロックを読み取る場合、そのブロックがパケットで送信されるか無音として破棄されるかにかかわらず、タイムスタンプはそのようなブロックごとに 160 増加する。

  タイムスタンプの初期値はシーケンス番号と同様にランダムであるべきである。複数の連続する RTP パケットは、それらが（論理的に）一度に生成される場合、たとえば同一のビデオフレームに属する場合、等しいタイムスタンプを持つ。連続する RTP パケットは、MPEG 補間ビデオフレームの場合のように、データがサンプリングされた順序で伝送されないとき、単調でないタイムスタンプを含んでよい。（伝送されるパケットのシーケンス番号は依然として単調である。）

  異なるメディアストリームの RTP タイムスタンプは異なるレートで進み、通常は独立したランダムなオフセットを持つ。したがって、これらのタイムスタンプは単一ストリームのタイミングを再構成するには十分であるが、異なるメディアの RTP タイムスタンプを直接比較しても同期には有効ではない。代わりに、各メディアについて、RTP タイムスタンプは、その RTP タイムスタンプに対応するデータがサンプリングされた時刻を表す基準クロック（掛時計）のタイムスタンプと組みにすることでサンプリング瞬間に関連付けられる。基準クロックは、同期すべきすべてのメディアで共有される。タイムスタンプの組はすべてのデータパケットで送信されるのではなく、セクション 6.4 で記述されるように RTCP SR パケットでより低いレートで送信される。

  サンプリング瞬間は、送信端点に既知であり、符号化遅延やその他の処理から独立してすべてのメディアに共通の定義を持つため、RTP タイムスタンプの基準点として選ばれる。目的は、同時にサンプリングされたすべてのメディアの同期再生を可能にすることである。

  実時間でサンプリングされたのではなく蓄積されたデータを伝送するアプリケーションは、典型的には掛時計時刻から導出された仮想再生タイムラインを用いて、蓄積データ内の各メディアの次のフレームや他の単位をいつ再生すべきかを決定する。この場合、RTP タイムスタンプは各単位の再生時刻を反映する。すなわち、各単位の RTP タイムスタンプは、その単位が仮想再生タイムライン上で現在となる掛時計時刻に関連付けられる。実際の再生は、受信側が決定するようにその後で生じる。

  事前録画したビデオにライブの音声解説を付ける例は、基準点としてサンプリング瞬間を選ぶことの重要性を示す。このシナリオでは、ビデオは解説者が閲覧するためにローカルで再生され、同時に RTP を用いて送信される。RTP で送信されるビデオフレームの「サンプリング瞬間」は、そのビデオフレームが解説者に提示された掛時計時刻を参照することで確立される。解説者の音声を含む音声 RTP パケットのサンプリング瞬間は、音声がサンプリングされた同じ掛時計時刻を参照することで確立される。2 つのホストの基準クロックが NTP などの何らかの手段で同期されていれば、音声と映像は異なるホストから送信されてもよい。受信側は、RTCP SR パケット内のタイムスタンプの組を用いて音声と映像のパケットの再生を同期させることができる。

SSRC：32 ビット SSRC フィールドは同期送信元を識別する。この識別子はランダムに選ばれるべきであり、同じ RTP セッション内の 2 つの同期送信元が同じ SSRC 識別子を持たないことを意図する。ランダム識別子を生成するアルゴリズムの例は付録 A.6 にある。複数の送信元が同じ識別子を選ぶ確率は低いが、すべての RTP 実装は衝突の検出と解決に備えなければならない。セクション 8 は、SSRC 識別子の一意性に基づく衝突解決および RTP レベル転送ループ検出のメカニズムとともに、衝突の確率を記述する。送信元が送信元トランスポートアドレスを変更する場合、ループされた送信元として解釈されないよう（セクション 8.2 参照）、新たな SSRC 識別子を選ばなければならない。

CSRC list：0 〜 15 項目、各 32 ビット CSRC リストは、このパケットに含まれるペイロードの寄与送信元を識別する。識別子の数は CC フィールドで与えられる。寄与送信元が 15 を超える場合、識別できるのは 15 までである。CSRC 識別子はミキサ（セクション 7.1 参照）により、寄与送信元の SSRC 識別子を用いて挿入される。たとえば音声パケットでは、1 つのパケットを生成するためにミキシングされたすべての送信元の SSRC 識別子が列挙され、受信側での正しい発話者表示を可能にする。

5.2 RTP セッションの多重化 (Multiplexing RTP Sessions)​

効率的なプロトコル処理のため、多重化ポイントの数は最小化されるべきである。これは統合レイヤ処理設計原則 [10] で記述されている。RTP では、多重化は各 RTP セッションごとに異なる宛先トランスポートアドレス（ネットワークアドレスとポート番号）によって提供される。たとえば、音声と映像のメディアを別々に符号化する電話会議では、各メディアは独自の宛先トランスポートアドレスを持つ別々の RTP セッションで運ばれるべきである。

別々の音声ストリームと映像ストリームを単一の RTP セッションで運び、ペイロード種別や SSRC フィールドに基づいて分離（demultiplex）すべきではない。異なる RTP メディアタイプでありながら同じ SSRC を用いるパケットをインターリーブ（交錯）すると、いくつかの問題が生じる。

  1. たとえば 2 つの音声ストリームが同じ RTP セッションと同じ SSRC 値を共有し、一方が符号化を変更して別の RTP ペイロード種別を得た場合、どちらのストリームが符号化を変更したかを識別する一般的な方法がない。

  2. SSRC は単一のタイミングおよびシーケンス番号空間を識別するよう定義される。メディアクロックレートが異なれば多重化された異なるタイミング空間が、どのペイロード種別がパケット欠落に遭ったかを見分けるには異なるシーケンス番号空間が必要となるため、複数のペイロード種別をインターリーブするには異なる空間が必要になる。

  3. RTCP 送信側および受信側報告（セクション 6.4 参照）は、SSRC ごとに 1 つのタイミングおよびシーケンス番号空間しか記述できず、ペイロード種別フィールドを運ばない。

  4. RTP ミキサは、互換性のないメディアのインターリーブされたストリームを 1 つのストリームに結合できない。

  5. 1 つの RTP セッションで複数メディアを運ぶことは、以下を妨げる。すなわち、適切であれば異なるネットワークパスやネットワーク資源割り当ての利用、望む場合のメディアの一部受信（たとえば映像が利用可能帯域を超える場合は音声のみ）、および異なるメディアに別プロセスを用いる受信側実装（一方別々の RTP セッションを用いれば単一プロセス実装も複数プロセス実装も可能）である。

各メディアに異なる SSRC を用いそれらを同じ RTP セッションで送信すれば、最初の 3 つの問題は避けられるが、最後の 2 つは避けられない。

一方、多重化セッションでは、同じメディアの複数の関連する送信元を異なる SSRC 値を用いて 1 つの RTP セッションに多重化するのが標準である。上記の問題は当てはまらない。たとえば RTP ミキサは複数の音声送信元を結合でき、すべてに対して同じ扱いが適用される。最後の 2 つの問題が当てはまらない他のシナリオでも、異なる SSRC 値を用いた同じメディアのストリームの多重化は適切であり得る。

5.3 RTP ヘッダに対するプロファイル固有の修正 (Profile-Specific Modifications to the RTP Header)​

既存の RTP データパケットヘッダは、RTP がサポートし得るすべてのアプリケーションクラスに共通して必要な機能の集合に対して完全であると考えられている。しかし ALF 設計原則に従い、ヘッダは、プロファイル独立の監視および記録ツールが機能し続けるようにしつつ、プロファイル仕様で定義された修正や追加によって調整されてよい。

o マーカビットとペイロード種別フィールドはプロファイル固有の情報を運ぶが、多くのアプリケーションがそれらを必要とし、さもなければそれらだけのために別の 32 ビットワードを追加せねばならないかもしれないため、固定ヘッダに割り当てられている。これらのフィールドを含むオクテットは、より多いあるいはより少ないマーカビットを用いるなど、異なる要求に合わせてプロファイルにより再定義されてよい。マーカビットが存在する場合、プロファイル独立のモニタがパケット欠落パターンとマーカビットの相関を観測できる可能性があるため、その 1 つはオクテットの最上位ビットに置かれるべきである。

o 特定のペイロード形式（映像符号化など）に必要な追加情報は、パケットのペイロード部に運ばれるべきである。これはペイロード部の先頭に常に存在するヘッダであるかもしれないし、データパターン中の予約値で示されるかもしれない。

o ある特定のアプリケーションクラスがペイロード形式から独立した追加機能を必要とする場合、それらのアプリケーションが動作するプロファイルは、既存の固定ヘッダの SSRC フィールドの直後に続く追加の固定フィールドを定義すべきである。それらのアプリケーションは追加フィールドに迅速かつ直接アクセスできる一方、プロファイル独立のモニタや記録器は最初の 12 オクテットのみを解釈することで RTP パケットを処理し続けられる。

すべてのプロファイルに共通して追加機能が必要になることが判明した場合、固定ヘッダへの恒久的な変更を加えるため、RTP の新たなバージョンを定義すべきである。

5.3.1 RTP ヘッダ拡張 (RTP Header Extension)​

個別の実装が、RTP データパケットヘッダに追加情報を運ぶことを必要とする、ペイロード形式に依存しない新たな機能を実験できるように、拡張メカニズムが用意されている。このメカニズムは、拡張されていない相互運用実装がこのヘッダ拡張を無視できるよう設計されている。

このヘッダ拡張は限定的な利用のみを意図している点に注意。このメカニズムのほとんどの潜在的利用は、前節で記述した方法を用いて別のやり方で行われる方がよい。たとえば、固定ヘッダに対するプロファイル固有の拡張は、条件付きでも可変位置でもないため、処理コストが低い。特定のペイロード形式に必要な追加情報は、このヘッダ拡張を用いるべきではなく、パケットのペイロード部に運ばれるべきである。

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | defined by profile | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | header extension | | .... |

RTP ヘッダの X ビットが 1 の場合、可変長のヘッダ拡張が、存在すれば CSRC リストに続いて RTP ヘッダに付加されなければならない。ヘッダ拡張は、拡張内の 32 ビットワードの数を数える 16 ビットの長さフィールドを含む。ただし 4 オクテットの拡張ヘッダは除外される（したがってゼロも有効な長さである）。RTP データヘッダには単一の拡張のみが付加できる。複数の相互運用実装がそれぞれ異なるヘッダ拡張を独立に実験したり、特定の実装が複数の種類のヘッダ拡張を実験したりできるよう、ヘッダ拡張の最初の 16 ビットは、識別子やパラメータを区別するために空けられている。これら 16 ビットの形式は、実装が動作しているプロファイル仕様により定義される。この RTP 仕様自体は、いかなるヘッダ拡張も定義しない。