RFC 3550 - 13. RTP プロファイルとペイロード形式仕様

13. RTP プロファイルとペイロード形式仕様 (RTP Profiles and Payload Format Specifications)

特定のアプリケーション向けの RTP の完全な仕様は、ここで記述する 2 種類の同伴文書、すなわちプロファイルおよびペイロード形式仕様のいずれか 1 つ以上を必要とする。

RTP は多少異なる要求を持つ様々なアプリケーションに用いられ得る。それらの要求への適応の柔軟性は、主プロトコル仕様において複数の選択を許し、ついで特定の環境およびアプリケーションクラスに対し適切な選択を選ぶか拡張を定義するを、別のプロファイル文書で行うことで提供される。典型的にはアプリケーションは特定の RTP セッション下で 1 つのプロファイルのみで動作するため、RTP プロトコル自身の中にどのプロファイルが用いられているかの明示的な指示はない。音声および映像アプリケーション向けのプロファイルは同伴 RFC 3551 にある。プロファイルは典型的には「RTP Profile for ...」と題される。

第 2 の種類の同伴文書はペイロード形式仕様であり、H.261 符号化映像のような特定の種類のペイロードデータを RTP でどう運ぶかを定義する。これらの文書は典型的には「RTP Payload Format for XYZ Audio/Video Encoding」と題される。ペイロード形式は複数のプロファイルで有用であり得るため、特定のプロファイルから独立に定義されてよい (MAY)。プロファイル文書は、必要ならその形式からペイロード種別値へのデフォルトマッピングを割り当てる責任を負う。

本仕様内で、プロファイル内で定義され得る項目として以下が挙げられているが、この一覧は網羅的であることを意図しない。

RTP データヘッダ：マーカビットおよびペイロード種別フィールドを含む RTP データヘッダのオクテットは、異なる要求に合わせ、たとえばより多いまたはより少ないマーカビットを用いるなど、プロファイルにより再定義されてよい (MAY)（セクション 5.3、p. 18）。

ペイロード種別：ペイロード種別フィールドが含まれると仮定して、プロファイルは通常、一連のペイロード形式（メディア符号化など）と、それらの形式からペイロード種別値へのデフォルト静的マッピングを定義する。いくつかのペイロード形式は別のペイロード形式仕様への参照により定義されてよい。定義される各ペイロード種別について、プロファイルは使用すべき RTP タイムスタンプクロックレートを規定しなければならない (MUST)（セクション 5.1、p. 14）。

RTP データヘッダ追加：ペイロード種別に依存しないプロファイルのアプリケーションクラス全体で追加機能が必要な場合、固定 RTP データヘッダに追加フィールドを付加してよい (MAY)（セクション 5.3、p. 18）。

RTP データヘッダ拡張：実装固有拡張のためにそのメカニズムがプロファイル下で許可される場合、RTP データヘッダ拡張構造の先頭 16 ビットの内容は定義されなければならない (MUST)（セクション 5.3.1、p. 18）。

RTCP パケット種別：新たなアプリケーションクラス固有の RTCP パケット種別は定義され IANA に登録されてよい (MAY)。

RTCP 報告間隔：プロファイルは、RTCP 報告間隔の計算に用いられる定数についてセクション 6.2 で提案された値が使用されることを規定すべきである (SHOULD)。それらはセッション帯域幅に占める RTCP の割合、最小報告間隔、および送信側と受信側間の帯域幅分割である。プロファイルは、スケーラブルな方法で機能することが実証されていれば代替値を規定してよい (MAY)。

SR/RR 拡張：送信側または受信側について定期的に報告すべき追加情報がある場合、RTCP SR および RR パケット向けの拡張セクションが定義されてよい (MAY)（セクション 6.4.3、p. 42 および 43）。

SDES 利用：プロファイルは、送信または完全に除外すべき RTCP SDES 項の相対優先順位（セクション 6.3.9）、CNAME 項の代替構文または意味論（セクション 6.5.1）、LOC 項の形式（セクション 6.5.5）、NOTE 項の意味論と利用（セクション 6.5.7）、または IANA に登録される新 SDES 項種別を規定してよい (MAY)。

セキュリティ：プロファイルはアプリケーションが提供すべきセキュリティサービスおよびアルゴリズムを規定してよく (MAY)、その適切な利用についての助言を提供してよい (MAY)（セクション 9、p. 65）。

文字列から鍵へのマッピング：プロファイルは、ユーザが提供したパスワードまたはパスフレーズを暗号鍵にどうマッピングするかを規定してよい (MAY)。

輻輳：プロファイルはそのプロファイルに適した輻輳制御の挙動を規定すべきである (SHOULD)。

下位プロトコル：RTP パケットを運ぶため特定の下位ネットワークまたはトランスポート層プロトコルの利用が必須とされてよい (MAY)。

トランスポートマッピング：セクション 11（p. 68）で定義される標準マッピング以外の、トランスポートレベルアドレス（UDP ポートなど）への RTP および RTCP のマッピングが規定されてよい (MAY)。

カプセル化：1 つの下位層パケットに複数の RTP データパケットを運ぶ、あるいはすでにそうでない下位プロトコルてフレーミングを提供するため、RTP パケットのカプセル化が定義されてよい (MAY)（セクション 11、p. 69）。

すべてのアプリケーションに新たなプロファイルが必要となることは期待されない。1 つのアプリケーションクラス内では、相互運用を促進するため、新たなプロファイルを作るよりも既存のプロファイルを拡張するほうがよい。なぜなら各アプリケーションは典型的には 1 つのプロファイルのみで動作するからである。追加ペイロード種別値や RTCP パケット種別の定義のような単純な拡張は、それらを IANA に登録し、プロファイルの追補やペイロード形式仕様にその記述を公表することで達成されてよい (MAY)。