3. 追加のエンコーディングの登録

追加のエンコーディングの登録

このプロファイルは、特定のメディアデータ圧縮または表現と、RTP 内でカプセル化するためのペイロード形式で構成される一連のエンコーディングをリストします。それらのペイロード形式の一部はここで指定されていますが、他のものは個別の RFC で指定されています。ここにリストされているセットを超える追加のエンコーディングが将来作成され、追加のペイロード形式 RFC で指定されることが期待されています。

このプロファイルはまた、各エンコーディングに短い名前を割り当てます。この名前は、セッション記述プロトコル (SDP)、RFC 2327 [6] などの上位レベルの制御プロトコルによって、特定の RTP セッションで選択されたエンコーディングを識別するために使用してもかまいません（MAY）。

一部のコンテキストでは、MIME コンテンツタイプの形式でこれらのエンコーディングを参照することが役立つ場合があります。これを容易にするために、RFC 3555 [7] は、RFC 2048 [8] で指定された MIME 登録手順を通じて、ここにリストされているすべてのエンコーディング名の登録を、"audio" および "video" MIME タイプの下の MIME サブタイプ名として提供します。

このプロファイル（またはその他）で使用するために指定された追加のエンコーディングも、Internet Assigned Numbers Authority (IANA) に MIME サブタイプとして登録された名前を割り当てられる場合があります。このレジストリは、追加のエンコーディングに割り当てられた名前が一意に保たれることを保証する手段を提供します。RFC 3555 は、RTP エンコーディングの登録に必要な情報を指定します。

エンコーディングに名前を割り当てることに加えて、このプロファイルはそれらの一部に静的 RTP ペイロードタイプ番号も割り当てます。ただし、ペイロードタイプ番号空間は比較的小さく、すべての既存および将来のエンコーディングの割り当てに対応することはできません。RTP 開発の初期段階では、エンコーディングをペイロードタイプにバインドする他のメカニズムが指定されていなかったため、静的に割り当てられたペイロードタイプを使用する必要がありました。ペイロードタイプとエンコーディングの間の動的マッピングを確立するために、本メモの範囲外の非 RTP 手段（ディレクトリサービスや招待プロトコルなど）が指定されることが予想されていました。現在、動的ペイロードタイプバインディングを定義するメカニズムは、セッション記述プロトコル (SDP) や、ITU-T 勧告 H.323/H.245 などの他のプロトコルで指定されています。これらのメカニズムは、エンコーディング/ペイロード形式の登録名、および RTP タイムスタンプクロックレートやチャネル数などの追加の必須パラメータを、ペイロードタイプ番号に関連付けます。この関連付けは、動的ペイロードタイプバインディングが行われた RTP セッションの期間中のみ有効です。この関連付けは、それが作成された RTP セッションにのみ適用されるため、番号は異なるセッションの異なるエンコーディングに再利用でき、番号空間の制限が回避されます。

このプロファイルは、96-127 の範囲のペイロードタイプ番号を動的割り当て専用に予約します。アプリケーションは、最初にこの範囲の値を動的ペイロードタイプに使用すべきです（SHOULD）。32 個を超える動的ペイロードタイプを定義する必要があるアプリケーションは、96 未満のコードをバインドしてもかまいませんが（MAY）、その場合、未割り当てのペイロードタイプ番号を最初に使用することが推奨されます（RECOMMENDED）。ただし、静的に割り当てられたペイロードタイプはデフォルトのバインディングであり、必要に応じて新しいエンコーディングに動的にバインドしてもかまいません（MAY）。96 未満のペイロードタイプを再定義すると、動的ペイロードタイプを定義するセッション記述情報を取得せずにセッションに参加しようとした場合に、誤った動作を引き起こす可能性があります。

動的ペイロードタイプは、マッピングを示す明確に定義されたメカニズムなしに使用すべきではありません（SHOULD NOT）。このプロファイルの下で動作する他のシステムと相互運用することを期待するシステムは、独自のエンコーディングを特定の固定ペイロードタイプに独自に割り当てるべきではありません（SHOULD NOT）。

本仕様は、本文書で定義されているものを超えて追加の静的ペイロードタイプは割り当てられないというポリシーを確立します。このポリシーを確立することで、静的割り当てを受け入れるための一連の基準を作成しようとする問題を回避し、動的ペイロードタイプメカニズムの実装と展開を促進します。

静的ペイロードタイプ割り当ての最終セットは、表 4 および 5 に示されています。