4. オーディオ

オーディオ

4.1 エンコーディングに依存しない規則

音声をパケットで送信する主な動機の一つは無音状態を抑制することであるため、RTP ヘッダーにはシーケンス番号とタイムスタンプの両方が含まれており、受信側でパケット損失とデータが送信されなかった期間を区別できるようになっています。不連続送信（無音抑制）は、どのオーディオペイロード形式でも使用してもよい（MAY）。受信側は、送信側が無音抑制を行う可能性があると想定しなければなりません（MUST）。ただし、これが他の場所で指定されたシグナリングによって制限されている場合は除きます。（送信側が無音抑制を行わない場合でも、パケットが失われる可能性があるため、受信側はデータが存在しない期間を処理できるように準備する必要があります。）

一部のペイロード形式（セクション 4.5.3 および 4.5.6 を参照）では、無音期間中に生成される人工ノイズのパラメータを指定して、ソースのバックグラウンドノイズを近似するための「無音挿入記述子」または「コンフォートノイズ」フレームを定義しています。他のペイロード形式については、一般的なコンフォートノイズ (CN) ペイロード形式が RFC 3389 [9] で指定されています。CN ペイロード形式が別のペイロード形式と一緒に使用される場合、RTP ペイロードタイプフィールドの異なる値によって、コンフォートノイズパケットと選択されたペイロード形式のパケットが区別されます。

無音期間中にパケットを送信しないか、または時折コンフォートノイズパケットを送信するアプリケーションの場合、トークスパートの最初のパケット、つまりパケットが連続して送信されなかった無音期間の後の最初のパケットは、RTP データヘッダーのマーカービットを 1 に設定することによって区別されるべきです（SHOULD）。他のすべてのパケットのマーカービットはゼロです。トークスパートの開始を使用して、変化するネットワーク遅延を反映するように再生遅延を調整してもよい（MAY）。無音抑制のないアプリケーションは、マーカービットをゼロに設定しなければなりません（MUST）。

RTP タイムスタンプの生成に使用される RTP クロックレートは、チャネル数やエンコーディングとは無関係です。これは通常、1 秒あたりのサンプリング周期の数に等しくなります。N チャネルエンコーディングの場合、各サンプリング周期（たとえば、1/8,000 秒）で N 個のサンプルが生成されます。（この用語は標準的ですが、多少紛らわしいです。なぜなら、1 秒あたりに生成されるサンプルの総数は、サンプリングレートにチャネル数を掛けたものになるからです。）

複数のオーディオチャネルが使用される場合、チャネルは左から右へ 1 から始まる番号が付けられます。RTP オーディオパケットでは、番号の小さいチャネルからの情報が、番号の大きいチャネルからの情報よりも先に配置されます。

2 つ以上のチャネルの場合、特定のエンコーディングまたはペイロード形式で他の規則が指定されていない限り、AIFF-C オーディオ交換形式に従った規則に従うべき（SHOULD）であり [3]、以下の表記法を使用します。

  l  左 (left)
  r  右 (right)
  c  中央 (center)
  S  サラウンド (surround)
  F  前方 (front)
  R  後方 (rear)

  チャネル  説明        チャネル
                            1     2   3   4   5   6
  _________________________________________________
  2         ステレオ        l     r
  3                         l     r   c
  4                         l     c   r   S
  5                        Fl     Fr  Fc  Sl  Sr
  6                         l     lc  c   r   rc  S

     注：RFC 1890 では、4 つのオーディオチャネルの順序について 2 つの規則が定義されていました。順序はチャネル数によって暗黙的に示されていたため、これは曖昧でした。この改訂版では、曖昧さを取り除くために、「4 チャンネルステレオ（quadrophonic）」として記述されていた順序は削除されました。この選択は、4 チャンネルステレオの消費者向けオーディオ形式は普及しませんでしたが、サラウンドサウンドはその後普及したという観察に基づいています。

単一のサンプリング瞬間に属するすべてのチャネルのサンプルは、同じパケット内になければなりません（MUST）。異なるチャネルからのサンプルのインターリーブは、エンコーディングによって異なります。一般的なガイドラインは、セクション 4.3 および 4.4 に記載されています。

サンプリング周波数は、8,000、11,025、16,000、22,050、24,000、32,000、44,100、および 48,000 Hz のセットから選択されるべきです（SHOULD）。（古い Apple Macintosh コンピュータのネイティブサンプルレートは 22,254.54 Hz でしたが、20 ms フレームで 4 サンプルをドロップすることで、許容できる品質で 22,050 に変換できます。）ただし、ほとんどのオーディオエンコーディングは、より制限されたサンプリング周波数のセットに対して定義されています。受信側はマルチチャネルオーディオを受け入れるように準備すべき（SHOULD）ですが、単一のチャネルのみを再生することを選択してもよい（MAY）。

4.2 運用上の推奨事項

以下の推奨事項は、デフォルトの運用パラメータです。アプリケーションは他の値を処理できるように準備すべきです（SHOULD）。示されている範囲は、アプリケーション作成者にガイダンスを提供することを目的としており、これらのガイドラインに準拠する一連のアプリケーションが追加のネゴシエーションなしで相互運用できるようにします。これらのガイドラインは、会議制御プロトコルなどを介して相互運用可能なパラメータのセットをネゴシエーションできるアプリケーションの運用パラメータを制限することを意図したものではありません。

パケット化されたオーディオの場合、デフォルトのパケット化間隔は、表 1（「ms/パケット」列）に特段の記載がない限り、20 ms または 1 フレームのいずれか長い方の期間を持つべきです（SHOULD）。パケット化間隔によって最小のエンドツーエンド遅延が決まります。パケットが長いほどヘッダーのオーバーヘッドは少なくなりますが、遅延が大きくなり、パケット損失が目立つようになります。講義などの非対話型アプリケーションや、帯域幅の制約が厳しいリンクの場合は、より高いパケット化遅延を使用してもよい（MAY）。受信側は、0 ～ 200 ms のオーディオデータを表すパケットを受け入れるべきです（SHOULD）。（フレームベースのオーディオエンコーディングの場合、受信側は、200 ms をフレーム期間で割って切り上げた数のフレームを持つパケットを受け入れるべきです（SHOULD）。）この制限により、受信側のバッファサイズを合理的に設定できます。

4.3 サンプルベースのオーディオエンコーディングのガイドライン

サンプルベースのエンコーディングでは、各オーディオサンプルは固定数のビットで表されます。圧縮オーディオデータ内では、個々のサンプルのコードがオクテット境界にまたがる場合があります。RTP オーディオパケットには任意の数のオーディオサンプルを含めることができますが、サンプルあたりのビット数にパケットあたりのサンプル数を掛けたものが整数のオクテット数になるという制約があります。分数エンコーディングでは、サンプルあたり 1 オクテット未満になります。

オーディオパケットの期間は、パケット内のサンプル数によって決まります。

サンプルあたり 1 つ以上のオクテットを生成するサンプルベースのエンコーディングの場合、同じサンプリング瞬間にサンプリングされた異なるチャネルからのサンプルは、連続したオクテットにパックされるべきです（SHOULD）。たとえば、2 チャネルエンコーディングの場合、オクテットシーケンスは（左チャネル、最初のサンプル）、（右チャネル、最初のサンプル）、（左チャネル、2 番目のサンプル）、（右チャネル、2 番目のサンプル）、... となります。マルチオクテットエンコーディングの場合、オクテットはネットワークバイトオーダー（つまり、最上位オクテットが先）で送信されるべきです（SHOULD）。

サンプルあたり 1 オクテット未満を生成するサンプルベースのエンコーディングのパッキングは、エンコーディング固有です。

RTP タイムスタンプは、パケット内の最初のサンプルがサンプリングされた瞬間、つまりパケット内で最も古い情報を反映します。

4.4 フレームベースのオーディオエンコーディングのガイドライン

フレームベースのエンコーディングは、固定長のオーディオブロックを別の圧縮データブロック（通常も固定長）にエンコードします。フレームベースのエンコーディングの場合、送信側は、そのようなフレームをいくつか組み合わせて単一の RTP パケットにすることを選択してもよい（MAY）。すべてのフレームが同じ長さであれば、受信側は RTP ペイロード長をエンコーディングの一部として定義されているオーディオフレームサイズで割ることにより、RTP パケットに含まれるフレーム数を知ることができます。これは、フレームサイズが互いに素でない限り、異なるサイズのフレームを運ぶ場合には機能しません。そうでない場合、フレームはそのサイズを示さなければなりません（MUST）。

フレームベースのコーデックの場合、チャネル順序はブロック全体に対して定義されます。つまり、2 チャネルオーディオの場合、右と左のサンプルは独立してコード化されるべき（SHOULD）であり、左チャネルのエンコードされたフレームが右チャネルのエンコードされたフレームよりも先に配置されます。

すべてのフレーム指向オーディオコーデックは、単一のパケット内でいくつかの連続したフレームをエンコードおよびデコードできるべきです（SHOULD）。フレーム指向コーデックのフレームサイズは決まっているため、同じエンコーディングに対して別の名称を使用する必要はありませんが、パケットあたりのフレーム数は異なります。

RTP パケットには整数のフレームが含まれなければならず（SHALL）、フレームはパケット内の経過時間順に挿入され、最も古いフレーム（最初に再生されるもの）が RTP パケットヘッダーの直後に配置されます。RTP タイムスタンプは、最初のフレームの最初のサンプルがサンプリングされた瞬間、つまりパケット内で最も古い情報を反映します。

4.5 オーディオエンコーディング

name of sampling default encoding sample/frame bits/sample rate ms/frame ms/packet

DVI4 sample 4 var. 20 G722 sample 8 16,000 20 G723 frame N/A 8,000 30 30 G726-40 sample 5 8,000 20 G726-32 sample 4 8,000 20 G726-24 sample 3 8,000 20 G726-16 sample 2 8,000 20 G728 frame N/A 8,000 2.5 20 G729 frame N/A 8,000 10 20 G729D frame N/A 8,000 10 20 G729E frame N/A 8,000 10 20 GSM frame N/A 8,000 20 20 GSM-EFR frame N/A 8,000 20 20 L8 sample 8 var. 20 L16 sample 16 var. 20 LPC frame N/A 8,000 20 20 MPA frame N/A var. var. PCMA sample 8 var. 20 PCMU sample 8 var. 20 QCELP frame N/A 8,000 20 20 VDVI sample var. var. 20

表 1：オーディオエンコーディングのプロパティ（N/A：該当なし、var.：可変）

このドキュメントで説明されているオーディオエンコーディングの特性を表 1 に示します。これらは、表 4 のペイロードタイプの順序でリストされています。ほとんどのオーディオコーデックは固定サンプリングレートに対してのみ指定されていますが、一部のサンプルベースのアルゴリズム（表 1 のサンプリングレート列に "var." と記載されているもの）は、異なるサンプリングレートで使用でき、その結果、異なるコード化ビットレートになります。静的ペイロードタイプが定義されているサンプリングレート以外で使用する場合、このメモの範囲外の非 RTP 手段を使用して動的ペイロードタイプを定義しなければならず（MUST）、選択された RTP タイムスタンプクロックレート（通常はオーディオのサンプリングレートと同じ）を示さなければなりません（MUST）。

4.5.1 DVI4

DVI4 は、Interactive Multimedia Association (IMA) によって「IMA ADPCM wave type」として指定された適応差分パルス符号変調 (ADPCM) エンコーディングスキームを使用します。ただし、ここで DVI4 として定義されているエンコーディングは、以下の 3 つの点で IMA 仕様とは異なります。

o RTP DVI4 ヘッダーには、IMA ADPCM ブロックヘッダーに含まれる最初のサンプル値ではなく、予測値が含まれています。

o IMA ADPCM ブロックには、奇数個のサンプルが含まれています。これは、ブロックの最初のサンプルがヘッダー（非圧縮）にのみ含まれ、その後に偶数個の圧縮サンプルが続くためです。DVI4 には偶数個の圧縮サンプルのみが含まれ、ヘッダーの predict ワードを使用して最初のサンプルをデコードします。

o DVI4 の場合、4 ビットサンプルは、最初のサンプルが最上位の 4 ビットに、2 番目のサンプルが最下位の 4 ビットになるようにパックされます。IMA ADPCM コーデックでは、サンプルは逆の順序でパックされます。

各パケットには、単一の DVI ブロックが含まれます。このプロファイルでは、サンプルあたり 4 ビットのバージョンのみが定義されていますが、IMA ではサンプルあたり 3 ビットのエンコーディングも指定されています。

各チャネルの「ヘッダー」ワードは、以下の構造を持っています。

  int16  predict;  /* predicted value of first sample
                      from the previous block (L16 format) */
  u_int8 index;    /* current index into stepsize table */
  u_int8 reserved; /* set to zero by sender, ignored by receiver */

ヘッダーに続く各オクテットには 2 つの 4 ビットサンプルが含まれるため、部分的に埋められた最後のオクテットを示す手段がないため、パケットあたりのサンプル数は偶数でなければなりません（MUST）。

複数のチャネルのサンプルのパッキングについては、今後の研究課題です。

IMA ADPCM アルゴリズムは、ドキュメント「IMA Recommended Practices for Enhancing Digital Audio Compatibility in Multimedia Systems (version 3.0)」で説明されています。ただし、Interactive Multimedia Association は 1997 年に活動を停止しました。そのドキュメントのアーカイブコピーと RTP DVI4 エンコーディングのソフトウェア実装のリソースについては、セクション 13 に記載されています。

4.5.2 G722

G722 は、ITU-T 勧告 G.722「64 kbit/s 内の 7 kHz オーディオコーディング」で指定されています。G.722 エンコーダーはオクテットのストリームを生成し、各オクテットは RTP パケット内でオクテット整列されなければなりません（SHALL）。G.722 オクテットで送信される最初のビット（上位サブバンドサンプルの最上位ビット）は、RTP パケット内のオクテットの最上位ビットに対応しなければなりません（SHALL）。

G.722 オーディオの実際のサンプリングレートは 16,000 Hz ですが、G722 ペイロード形式の RTP クロックレートは 8,000 Hz です。これは、RFC 1890 でその値が誤って割り当てられ、後方互換性のために変更できないためです。オクテットレートまたはサンプルペアレートは 8,000 Hz です。

4.5.3 G723

G723 は、ITU 勧告 G.723.1「5.3 および 6.3 kbit/s で送信するマルチメディア通信用デュアルレート音声符号化」で指定されています。G.723.1 5.3/6.3 kbit/s コーデックは、ITU-T H.324 GSTN テレビ電話端末アプリケーションの必須コーデックとして ITU-T によって定義されました。アルゴリズムは、G.723.1 附属書 B に浮動小数点仕様、G.723.1 附属書 A に無音圧縮アルゴリズム、G.723.1 附属書 C に無線アプリケーション用のスケーラブルチャネルコーディングスキームを持っています。

この勧告は、マルチメディアサービスの音声信号成分を非常に低いビットレートで圧縮するために使用できる符号化表現を指定しています。オーディオは 30 ms フレームでエンコードされ、先読みにより 7.5 ms の追加遅延が発生します。G.723.1 フレームは、24 オクテット（6.3 kb/s フレーム）、20 オクテット（5.3 kb/s フレーム）、または 4 オクテットの 3 つのサイズのいずれかになります。これらの 4 オクテットフレームは SID フレーム（無音挿入記述子）と呼ばれ、コンフォートノイズパラメータを指定するために使用されます。4、20、および 24 オクテットフレームの混在方法に制限はありません。フレーム内の最初のオクテットの最下位 2 ビットによって、フレームサイズとコーデックタイプが決まります。

     ビット  内容                         オクテット/フレーム
  高レート音声 (6.3 kb/s)          24
  低レート音声 (5.3 kb/s)          20
  SID フレーム                     4
  予約

任意の 30 ms フレーム境界で 2 つのレートを切り替えることが可能です。（5.3 kb/s および 6.3 kb/s）両方のレートは、エンコーダーおよびデコーダーの必須部分です。受信側は、これらの機能の制限がシグナリングされていない限り、両方のデータレートを受け入れなければならず（MUST）、SID フレームを受け入れなければなりません（MUST）。RFC 3555 [7] における G723 の MIME 登録では、単一のデータレートに制限したり、SID フレームの使用を制限したりするために MIME または SDP とともに使用してもよい（MAY）パラメータが指定されています。この符号化器は、限られた量の複雑さを使用して、上記のレートで長距離電話品質に近い音声を表すように最適化されています。

エンコードされたビットストリームのオクテットへのパッキングおよびオクテットの送信順序は、G.723.1 勧告で指定されており、G.723 C コード参照実装によって生成されるものと同じです。6.3 kb/s データレートの場合、このパッキングは図 1 に示すとおりです。ここで、ヘッダー (HDR) ビットは、6.3 kb/s での動作を示すために図 1 に示すように常に "0 0" であり、Z ビットは常にゼロに設定されます。図は、「ネットワークバイトオーダー」（ビッグエンディアンオーダーとも呼ばれる）でのビットパッキングを示しています。各 32 ビットワードのビットは 0 から 31 までの番号が付けられ、最上位ビットが左側で番号 0 になります。各ワードのオクテット（バイト）は、最上位オクテットから順に送信されます。各データフィールドのビットは、エンコーディングのビットストリーム表現の順序（最下位ビットが先）で番号が付けられています。縦棒はフィールドフラグメント間の境界を示します。

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC |HDR| LPC | LPC | ACL0 |LPC| | | | | | | | |0 0 0 0 0 0|0 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACL2 |ACL|A| GAIN0 |ACL|ACL| GAIN0 | GAIN1 | | | 1 |C| | 3 | 2 | | | |0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 | | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSBPOS |Z|POS| MSBPOS | POS0 |POS| POS0 | | | | 0 | | | 1 | | |0 0 0 0 0 0 0|0|0 0|1 1 1 0 0 0|0 0 0 0 0 0 0 0|0 0|1 1 1 1 1 1| |6 5 4 3 2 1 0| |1 0|2 1 0 9 8 7|9 8 7 6 5 4 3 2|1 0|5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS1 | POS2 | POS1 | POS2 | POS3 | POS2 | | | | | | | | |0 0 0 0 0 0 0 0|0 0 0 0|1 1 1 1|1 1 0 0 0 0 0 0|0 0 0 0|1 1 1 1| |9 8 7 6 5 4 3 2|3 2 1 0|3 2 1 0|1 0 9 8 7 6 5 4|3 2 1 0|5 4 3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS3 | PSIG0 |POS|PSIG2| PSIG1 | PSIG3 |PSIG2| | | | 3 | | | | | |1 1 0 0 0 0 0 0|0 0 0 0 0 0|1 1|0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0| |1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|2 1 0|4 3 2 1 0|4 3 2 1 0|5 4 3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              図 1：G.723 (6.3 kb/s) ビットパッキング

5.3 kb/s データレートの場合、ヘッダー (HDR) ビットは常に "0 1" であり、5.3 kb/s での動作を示すために図 2 に示すようになります。

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC |HDR| LPC | LPC | ACL0 |LPC| | | | | | | | |0 0 0 0 0 0|0 1|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACL2 |ACL|A| GAIN0 |ACL|ACL| GAIN0 | GAIN1 | | | 1 |C| | 3 | 2 | | | |0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 | | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|4 3 2 1|1 0 9 8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS0 | POS1 | POS0 | POS1 | POS2 | | | | | | | |0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS3 | POS2 | POS3 | PSIG1 | PSIG0 | PSIG3 | PSIG2 | | | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|3 2 1 0|3 2 1 0|3 2 1 0|3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              図 2：G.723 (5.3 kb/s) ビットパッキング

G.723.1 SID（無音）フレームのパッキングは、ヘッダー (HDR) ビットが "1 0" のパターンを持つことで示され、図 3 に示されています。

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC |HDR| LPC | LPC | GAIN |LPC| | | | | | | | |0 0 0 0 0 0|1 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               図 3：G.723 SID モードビットパッキング

4.5.4 G726-40, G726-32, G726-24, および G726-16

ITU-T 勧告 G.726 は、（とりわけ）単一の 64 kbit/s A-law または mu-law PCM チャネル（8,000 サンプル/秒でエンコード）を 40、32、24、または 16 kbit/s チャネルとの間で変換するために推奨されるアルゴリズムについて説明しています。変換は、適応差分パルス符号変調 (ADPCM) トランスコーディング技術を使用して PCM ストリームに適用されます。ADPCM 表現は、PCM ストリーム内のサンプルと 1 対 1 に対応する一連のコードワードで構成されます。G726 の 40、32、24、および 16 kbit/s のデータレートには、それぞれ 5、4、3、および 2 ビットのコードワードがあります。

16 および 24 kbit/s のエンコーディングは、長距離電話品質の音声を提供しません。これらは、過負荷のデジタル回線多重化装置 (DCME) で使用するために設計されています。ITU-T G.726 は、サンプルあたりの平均サンプルサイズを 3.5 ～ 3.7 ビットにするために、16 および 24 kbit/s のエンコーディングをより高いデータレートのエンコーディングと交互に使用することを推奨しています。

G.726 のエンコーディングは、ここでは G726-40、G726-32、G726-24、および G726-16 と表記されます。1990 年以前は、G721 が 32 kbit/s ADPCM エンコーディングを記述し、G723 が 40、32、および 16 kbit/s エンコーディングを記述していました。したがって、G726-32 は RFC 1890 の G721 と同じアルゴリズムを指定します。

G726 コードワードのストリームには、使用されているエンコーディングに関する情報が含まれていないため、パックされたコードワードのシーケンス内での G726 エンコーディングタイプ間の遷移は許可されません。アプリケーションは、RTP ペイロード識別子からパックされたコードワードのエンコーディングタイプを決定しなければなりません（MUST）。

ペイロード固有のヘッダー情報は、オーディオデータの一部として含まれてはなりません（SHALL）。G726 コードワードのストリームは、次のようにオクテットにパックされなければなりません（MUST）：最初のコードワードは、コードワードの最下位ビットがオクテットの最下位ビットに揃うように最初のオクテットに配置され、2 番目のコードワードは、その最下位ビットがオクテット内の最下位の空きビットと一致するようにパックされます。完全なコードワードをオクテットに配置できない場合、オクテット境界に重なるビットは、次のオクテットの最下位ビットに配置されます。パッキングは、完全にパックされた最終オクテットで終了しなければなりません（MUST）。したがって、パックされるコードワードの数は、G726-40、G726-32、G726-24、および G726-16 の場合、それぞれ 8、2、8、および 4 の倍数になります。G726-32 コードワードのパッキングスキームの例を以下に示します。ここで、ビット 7 は最初のオクテットの最下位ビットであり、ビット A3 は最初のコードワードの最下位ビットです。

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     |B B B B|A A A A|D D D D|C C C C| ...
     |0 1 2 3|0 1 2 3|0 1 2 3|0 1 2 3|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

G726-24 コードワードのパッキングスキームの例を以下に示します。ここで、ビット 7 は再び最初のオクテットの最下位ビットであり、ビット A2 は最初のコードワードの最下位ビットです。

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     |C C|B B B|A A A|F|E E E|D D D|C|H H H|G G G|F F| ...
     |1 2|0 1 2|0 1 2|2|0 1 2|0 1 2|0|0 1 2|0 1 2|0 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

ここで指定されている G726-16、-24、-32、および -40 ペイロード形式でサンプルがオクテットにパックされる「リトルエンディアン」方向は、ITU-T 勧告 X.420 と一致していますが、ATM AAL2 転送用の ITU-T 勧告 I.366.2 附属書 E で指定されているものとは逆であることに注意してください。I.366.2 附属書 E のパケット化と一致し、MIME サブタイプ AAL2-G726-16、-24、-32、および -40 で識別される 2 番目の RTP ペイロード形式のセットは、別のドキュメントで指定されます。

4.5.5 G728

G728 は、ITU-T 勧告 G.728「低遅延コード励起線形予測を使用した 16 kbit/s での音声符号化」で指定されています。

G.278 エンコーダーは、5 つの連続するオーディオサンプルを 10 ビットのコードブックインデックスに変換し、毎秒 8,000 サンプルのオーディオに対して 16 kb/s のビットレートになります。5 つの連続するサンプルのグループは、ベクトルと呼ばれます。V1 から V4 とラベル付けされた 4 つの連続するベクトル（V1 が受信側で最初に再生される）で、1 つの G.728 フレームを構築します。40 ビットの 4 つのベクトルは、B1 から B5 とラベル付けされた 5 つのオクテットにパックされます。B1 は、RTP パケット内で最初に配置されなければなりません（SHALL）。

下の図を参照すると、ビット順序の原則は「ビットの重要性の維持」です。古いベクトルからのビットは、新しいベクトルからのビットよりも重要です。フレームの MSB は B1 の MSB になり、フレームの LSB は B5 の LSB になります。

               1         2         3        3
     0         0         0         0        9
     ++++++++++++++++++++++++++++++++++++++++
     <---V1---><---V2---><---V3---><---V4---> ベクトル
     <--B1--><--B2--><--B3--><--B4--><--B5--> オクテット
     <------------ フレーム 1 -------------->

具体的には、B1 には V1 の 8 つの最上位ビットが含まれ、V1 の MSB は B1 の MSB になります。B2 には V1 の 2 つの最下位ビット（2 つのうちの上位ビットが MSB）と、V2 の 6 つの最上位ビットが含まれます。B1 は RTP パケット内で最初に配置され、B5 は最後に配置されなければなりません（SHALL）。

4.5.6 G729

G729 は、ITU-T 勧告 G.729「共役構造代数符号励起線形予測 (CS-ACELP) を使用した 8 kbit/s での音声符号化」で指定されています。このコーデックは、G.728 が低遅延であり、G.723.1 が低ビットレートであるのに対し、高品質で音声を表現するように最適化されています。G.729 エンコーダーは、毎秒 8000 サンプルのサンプリングレートで 80 サンプルに対応する 10 ms の音声フレームで動作します。生成されるビットストリームのビットレートは 8 kbit/s です。したがって、各フレームには 80 ビットが含まれます。

エンコードされたビットストリームのオクテットへのパッキングおよびオクテットの送信順序は、G.729 勧告で指定されており、G.729 C コード参照実装によって生成されるものと同じです。各 80 ビットフレームのビットは 1 から 80 までの番号が付けられ、最上位ビットが左側で番号 1 になります。各ワードのオクテット（バイト）は、最上位オクテットから順に送信されます。各データフィールドのビットは、エンコーディングのビットストリーム表現の順序（最下位ビットが先）で番号が付けられています。縦棒はフィールドフラグメント間の境界を示します。

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L0 | L1 | L2 | L3 | P1 | | | | | | | |0|0 0 0 0 0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0 0 0 0 0 0| | |6 5 4 3 2 1 0|4 3 2 1 0|4 3 2 1 0|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P1 | P2 | C1 | S1 | C2 | S2 | P1 | | | | | | | | | |0 0|0 0 0|0 0 0 0 0|0 0 0|0 0 0 0 0|0 0 0|0 0 0 0 0 0 0 0| |9 8|4 3 2 1 0|c c c c c|3 2 1 0|c c c c c|3 2 1 0|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2 | C3 | S3 | C4 | S4 | | | | | | | |0 0 0|0 0 0 0 0|0 0 0|0 0 0 0 0|0 0 0| |4 3 2 1 0|c c c c c|3 2 1 0|c c c c c|3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

G.729 への附属書 A は、G.729 アルゴリズムの複雑さを軽減したバージョンを指定しています。附属書 A のコーダーは、G.729 コーダーと同じビットストリームを生成します。

G.729 への附属書 B は、G.729 または G.729 附属書 A とともに使用される無音圧縮アルゴリズムを定義しています。無音期間を検出すると、エンコーダーはコンフォートノイズパラメータを指定する 2 オクテットの SID フレーム（無音挿入記述子）を送信します。10 オクテットフレームと 2 オクテットフレームの混在方法に制限はありません。SID フレームは、部分的に合計コードブックインデックスであり、部分的に無音圧縮アルゴリズムのパラメータです。SID フレームのフィールドを下の図に示します。

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L0 | L1 | L2 | L3 | GAIN | | | | | | | |0|0 0 0 0 0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0 0 0| | |6 5 4 3 2 1 0|4 3 2 1 0|4 3 2 1 0|4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

G.729 附属書 B の場合、チャネルコード化された VAD/DTX 生成には、長さがわずか 10 ビット（1.25 オクテット）の 1/16 レート（800 bps）フレームの送信が含まれます。これらは整数のオクテット数に収まらないため、これらのフレームのパッキングは今後の研究課題です。このペイロード形式で動作する受信機は、80 ビットの音声フレームと 16 ビットの SID フレームを受け入れなければなりません（MUST）。受信機は、もしあれば 10 ビットフレームを破棄してもよい（MAY）。

4.5.7 G729D および G729E

G.729 への附属書 D は、アルゴリズムへの低ビットレート拡張（6.4 kb/s）を定義しています。G.729 附属書 D コーダーは 64 ビットフレームを生成します。

G.729 への附属書 E は、アルゴリズムへの高ビットレート拡張（11.8 kb/s）を定義しています。G.729 附属書 E コーダーは 118 ビットフレームを生成します。

エンコードされたビットストリームのオクテットへのパッキングおよびオクテットの送信順序は、G.729 勧告で指定されており、G.729 C コード参照実装によって生成されるものと同じです。各 64 ビットまたは 118 ビットフレームのビットは 1 から n までの番号が付けられ、最上位ビットが左側で番号 1 になります。各ワードのオクテット（バイト）は、最上位オクテットから順に送信されます。各データフィールドのビットは、エンコーディングのビットストリーム表現の順序（最下位ビットが先）で番号が付けられています。

ITU-T 勧告 G.729 附属書 D および E は、現在、音声アクティビティ検出 (VAD) および不連続送信 (DTX) をどのように処理すべきかを指定していません。したがって、このペイロード形式ではこれらを使用すべきではありません（SHOULD NOT）。

4.5.8 GSM

GSM (Group Speciale Mobile) は、13 kb/s の RPE/LTP（残差パルス励起/長期予測）符号化に基づく、フルレート音声トランスコーディングの欧州 GSM 06.10 規格、ETS 300 961 を示します [11,12,13]。規格のテキストは、ETSI（欧州電気通信標準化機構）の Web サイト http://www.etsi.org から入手できます。

4.5.8.1 一般的なパッケージングの問題

GSM 規格はコーデックによって生成されるビットストリームを指定していますが、これらのビットを送信のためにどのようにパックするかは指定していません。このドキュメントで指定されている他のオーディオエンコーディングのペイロード形式とは異なり、GSM ペイロード形式は、GSM 06.10 C 参照実装で使用される標準表現とは異なる方法でバイトをパックします。

標準の GSM 06.10 実装は、1 つの GSM フレームの 260 ビットを 33 オクテット（16 ビットシステムでは 16 ワード）にパッケージ化し、ビットは各バイト/ワードの最下位ビットを占めます。これらを RTP で送信するには、ETSI TS 101 318 [4] で定義されているように、260 ビットを 33 オクテットにパックします。後者は事実上 VoIP/VoFR/VoATM の標準となっており、セクション 13 で引用されている GSM 実装で使用されている "Toast" 形式と同じです。

RTP ペイロード形式では、最後のオクテットの 4 つの予備ビットをゼロで埋めることにより、1 つのフレームが 33 オクテット（264 ビット）にパックされます。2 つのフレームが 66 オクテットにパックされます。フィールドマッピングを表 2 に示します。

4.5.8.2 GSM 変数名と番号

GSM オーディオコーデックのパラメータは、GSM 06.10 規格に従って、次のように命名されています。

                         表 2：GSM ペイロード形式

Field Field Name Bits Octet Bit

1 LARc[0] 6 1 0--5 2 LARc[1] 6 1, 2 6--7, 0--3 3 LARc[2] 5 2, 3 4--7, 0 4 LARc[3] 5 3 1--5 5 LARc[4] 4 3, 4 6--7, 0--1 6 LARc[5] 4 4 2--5 7 LARc[6] 3 4, 5 6--7, 0 8 LARc[7] 3 5 1--3 9 Nc[0] 7 5, 6 4--7, 0--2 10 bc[0] 2 6 3--4 11 Mc[0] 2 6 5--6 12 xmaxc[0] 6 6, 7 7, 0--4 13 xmc[0] 3 7 5--7 14 Nc[1] 7 8 0--6 15 bc[1] 2 8, 9 7, 0 16 Mc[1] 2 9 1--2 17 xmaxc[1] 6 9, 10 3--7, 0 18 xmc[1] 3 10 1--3 19 Nc[2] 7 10, 11 4--7, 0--2 20 bc[2] 2 11 3--4 21 Mc[2] 2 11 5--6 22 xmaxc[2] 6 11, 12 7, 0--4 23 xmc[2] 3 12 5--7 24 Nc[3] 7 13 0--6 25 bc[3] 2 13, 14 7, 0 26 Mc[3] 2 14 1--2 27 xmaxc[3] 6 14, 15 3--7, 0 28 xmc[3] 3 15 1--3

4.5.9 GSM-EFR

GSM-EFR は、ETS 300 726 (GSM 06.60) で指定されています。これは、GSM コーデックとクロックレート (8000 Hz) およびビットレート (12.2 kb/s) が同じ拡張フルレート音声コーデックです。

4.5.10 L8

L8 は、128 のオフセットを持つ 8 ビットの精度を使用する線形オーディオデータサンプルを示します。つまり、最も負の信号は値 0 で表され、ゼロ信号は値 128 で表され、最も正の信号は値 255 で表されます。

4.5.11 L16

L16 は、(16 ビット) 符号付き線形オーディオデータサンプルを示します。線形 L16 オーディオサンプルは、ネットワークバイトオーダー（最上位オクテットが先）で送信されるべきです（SHOULD）。

4.5.12 LPC

LPC は、Xerox PARC の Ron Frederick によって提供された実験的な線形予測符号化を指定します。これは、ISI の Steve Casner によって最初に作成された実装に基づいています。エンコーダーおよびデコーダーのソースコードは、セクション 13 にリストされているように入手可能です。

4.5.13 MPA

MPA は、MPEG-1 または MPEG-2 オーディオエレメンタリストリームの使用を指定します。RTP ペイロード形式は、RFC 2250 [14] のセクション 3 で指定されているとおりです。

4.5.14 PCMA および PCMU

PCMA および PCMU は、ITU-T 勧告 G.711 で指定されています。オーディオデータは、対数スケーリング後にサンプルあたり 8 ビットとしてエンコードされます。PCMU は mu-law スケーリング、PCMA は A-law スケーリングを示します。詳細な説明は、Jayant and Noll [15] によって与えられています。各 G.711 オクテットは、RTP パケット内でオクテット整列していなければなりません（SHALL）。各 G.711 オクテットの符号ビットは、RTP パケット内のオクテットの最上位ビットに対応していなければなりません（SHALL）（つまり、G.711 サンプルがホストマシン上でオクテットとして処理されると仮定すると、符号ビットはホストマシン形式で定義されるオクテットの最上位ビットでなければなりません）。G.711 の 56 kb/s および 48 kb/s モードは、RTP には適用されません。PCMA および PCMU は常に 8 ビットサンプルとして送信されなければならないためです（MUST）。

4.5.15 QCELP

Qualcomm Code Excited Linear Prediction (QCELP) オーディオコーデックは、TIA/EIA IS-733「広帯域スペクトル拡散通信システム用の TR45 高レート音声サービスオプション 17」で指定されています。

QCELP コーデックは、TIA/EIA IS-95 CDMA 携帯電話システム規格で使用されています。QCELP コーデックは、フレームごとに選択できるさまざまなデータレートにスケーリングします。最大データレートは 13 kbit/s です。このペイロード形式では個別の無音フレームタイプは定義されていませんが、無音期間中はデータレートを約 1 kbit/s に下げることができます。

RTP ペイロード形式は [16] で指定されています。

4.5.16 RED

冗長オーディオペイロード形式 "RED" は、RFC 2198 [17] で指定されています。これは、オーディオパケットの複数の冗長コピーを単一の RTP ストリームで送信できる手段を定義しています。

4.5.17 VDVI

VDVI は、動的割り当てに使用可能な DVI4 の可変レートバージョンです。DVI4 サンプルはオクテットにパックされますが、サンプルあたりのビット数はパケットごとに異なる場合があり、パケットヘッダーで指定されます。VDVI の場合、RTP ヘッダーのペイロードタイプフィールドは "VDVI" にマッピングされる動的タイプです。

各パケットには、単一の DVI ブロックが含まれます。各チャネルの「ヘッダー」ワードは、以下の構造を持っています。

  int16  predict;  /* predicted value of first sample
                      from the previous block (L16 format) */
  u_int8 index;    /* current index into stepsize table */
  u_int8 sample_size; /* number of bits per sample */

サンプルサイズは、3、4、または 5 のいずれかでなければなりません（MUST）。サンプルサイズが 4 の場合、サンプルのパッキングは DVI4 と同じです。サンプルサイズが 3 または 5 の場合、サンプルは MSB から順に、パケットウィンドウの現在のオクテットの次の使用可能なビットにパックされます。サンプルがオクテット境界にまたがる場合、ビットは最初のオクテットの LSB と 2 番目のオクテットの MSB に配置されます。次のサンプルは、2 番目のオクテットの最初の使用可能な MSB からパッキングを開始します。このプロセスは、パケット全体に対して続きます。