ITU-T G.711.1勧告のためのRTPペイロード形式

この文書はIETFがインターネット標準として公開している仕様書"RFC5391 RTP Payload Format for ITU-T Recommendation G.711.1"をSTUDIO DDT ONLINEが学習目的で日本語に翻訳したものです。正式な仕様書は英語版のみであり、この日本語訳は参考にすぎません。

この文書には翻訳上の誤りが含まれるかもしれません。STUDIO DDT ONLINEは翻訳の正確性を保証しません。

この文書のレイアウトはMediaWikiの記法に依存するため、オリジナルの文書とは文書構成、HTMLのセマンティクス、見栄え等が異なります。

この文書の位置づけ: この文書はインターネット社会のためにインターネット標準化の途上にあるプロトコルを定め、改善のために議論と提案を求めるものである。このプロトコルの位置づけと標準化状況については、「インターネット公式プロトコル標準（STD 1）」の最新版を参照されたい。この文書の配布は無制限である。
著作権表示: 著作権(c) 2008 IETF事務局と文書著者として記載された人物が、全ての権利を留保している。; この文書はBCP 78と、この文書の発効日から有効なIETF事務局のIETF文書に関する法規定の下にある。この文書に関する権利と制限が記載されているので、入念にこれらの文書を評価されたい。
概要: この文書はITU電気通信標準化部門（ITU-T）G.711.1音響符号化のために用いるリアルタイム配送プロトコル（RTP）ペイロード形式を規定するものであり、二つのメディア形式の登録を含む。

この翻訳文の著作権はSTUDIO DDT ONLINEおよびサイト管理者が保持しています。この翻訳文の利用などについては免責事項を参照してください。ただし、原文のライセンス内容によっては免責事項よりも原文のライセンスが優先されます。

導入[編集]

ITU電子通信標準化部門（ITU-T)のG.711.1勧告は、G.711パルス符号変調（G.711）勧告に広帯域拡張を埋め込んだものである。この文書ではリアルタイム配送プロトコル（RTP）にG.711.1で符号化された音声信号をパケット化するためのペイロード形式を規定する。

この文書において"しなければならない[MUST]"、"してはならない[MUST NOT]"、"要求されている[REQUIRED]"、"することになる[SHALL]"、"することはない[SHALL NOT]"、"する必要がある[SHOULD]"、"しないほうがよい[SHOULD NOT]"、"推奨される[RECOMMENDED]"、"してもよい[MAY]"、"選択できる[OPTIONAL]"といった単語は RFC 2119に記述されているように解するものとする。

この翻訳では、必ずしも上記のように翻訳されていませんが、原文に明記されている箇所では、翻訳でも明らかであるようにしています。

背景[編集]

G.711.1は、G.711に広帯域の音声・音響を埋め込んだものであり、64、80、96kbpsで作用する符号化アルゴリズムである。64kbpsについては、G.711.1はG.711と完全な相互運用性を持つ。従って、既存のG.711を元にしたIP上での音声（VoIP）基盤内での効率的な展開が見込める。

コーデック（符号化器）は5ms分のフレームに作用し、既定の標本化レートは16kHzである。8kHzでの入出力は、狭帯域モードのために扱われる。

エンコーダは有効なビットレート、すなわち64、80、96kbpsの三つに対応する三層（レイヤ）構造で埋め込まれたビットストリームを作成する。ビットストリームは望ましい値のビットレートに「即座に」調整されるために、デコーダ側で、あるいは伝達システムの任意の構成部分によって、切り詰められうる。

次の表が三つのレイヤの詳細である。

表1: レイヤ説明
レイヤ	説明	ビットレート
L0	G.711互換	64 kbps
L1	狭帯域付加	16 kbps
L2	広帯域付加	16 kbps

三つのレイヤの組み合わせは、次の表のような4つのモードを定義する。

表2: モード説明
モード	L0	L1	L2	音声帯域	ビットレート
R1	x			狭帯域	64 kbps
R2a	x	x		狭帯域	80 kbps
R2ｂ	x		x	広帯域	80 kbps
R3	x	x	x	広帯域	96 kbps

RTPヘッダの利用[編集]

RTPヘッダ形式はRFC 3550で定められている。この文書で定めるペイロード形式は、その仕様書と矛盾しない方法でヘッダフィールドを用いる。

マーカー（marker M）: G.711.1では、不連続送信（Discontinuous Transmission DTX）あるいは無音抑制（silence suppression）に関して、いかなる仕様も定義していない。コーデック独特のメカニズムとして、RFC 3389で定められている一般的な擬似ノイズ（comfort-noise）ペイロード形式のようなものを用いても良い。; 無音の間、全くパケットを送信しない、もしくは不定期な擬似ノイズパケットを送信するアプリケーションのために、連続してパケットが送信されていない期間の静寂ののちの――しゃべり始めの時のような――最初のパケットでは、RTPデータヘッダの一つにあるマーカー値を指定することで区別させるべき[SHOULD]である。その他のあらゆるパケットでマーカー値はゼロ（0）である。しゃべり始めの先頭では、網遅延の変化を受けた再生遅延（playout delay）を調整するために用いても良い[MAY]。無音抑制をしないアプリケーションでは、マーカー値は常にゼロでなければならない[MUST]。
ペイロード形式（payload type PT）: このパケット形式のためのRTPペイロード形式の割り当てについては、この文書の範囲外であるし、ここで定められない。このペイロード形式が用いられている下でのRTPプロファイルは、このコーデックのためのペイロード形式を割り当てるだろうし、さもなくば動的に決定付けられたペイロード形式を指定するだろう（第5.3節を見よ）。
タイムスタンプ（timestamp）: RTPタイムスタンプのクロック周波数は、既定の標本化周波数である16kHzに等しい。; G.711.1は8kHzで標本化された入力/出力信号を扱う機能を兼ね備える。それはビットストリームに作用しないし、デコーダは、エンコーダでの入力において原信号の標本化レートについてわかるような情報を必要としない。そのため、機器の音響的特性や実装に依存し、エンコーダでの入力、およびデコーダでの出力で8kHzで構成することが可能であるが、16kHzのRTPクロックレートを常に用いなければならない[MUST]。; 一フレームは5ms、つまり16kHzでの80サンプルに相当するので、タイムスタンプは連続したフレームごとに80ずつ加算される。

ペイロード形式[編集]

完全なペイロードは1オクテットのペイロードヘッダで構成され、後述する一つ以上の連続した同一モードのG.711.1音響フレームによって成される。

モードはパケット間で変わるかもしれないが、パケット中では変わらない。

ペイロードヘッダ[編集]

ペイロードヘッダは下図のとおりである。

0	1	2	3	4	5	6	7
0	0	0	0	0	MI

最上位の5ビットは将来の拡張のために予約されており、ゼロを指定しなければならず[MUST]、また受信側で無視しなければならない[MUST]。

モードインデックス（Mode Index MI）フィールド（3ビット）は、次の表で表されるフレームのモードである。

表3: ペイロードヘッダ内のモード
モード番号	G.711.1モード	フレームサイズ
1	R1	40オクテット
2	R2a	50オクテット
3	R2b	50オクテット
4	R3	60オクテット

そのほか全てのMIの値は将来のために予約されており、使用してはならない[MUST NOT]。

未定義のMI値を持ったペイロードを受信したなら、破棄しなければならない[MUST]。

シグナリング（第5節を見よ）によって禁止されたモードが設定された場合、上記の表にないMI値が設定されたペイロードを受け取ったなら、破棄しなければならない[MUST]。

音声データ[編集]

このペイロードヘッダの後、連続した音響フレームが、最も古いものから時系列に沿って梱包される。全てのフレームは同一のモードとならなければならず[MUST]、ペイロードヘッダのMIフィールドによって示されねばならない[MUST]。

フレーム内で、レイヤは常に同じ順番、すなわち、R2aモードではL0の次にL1、R2bモードではL0の次にL2、R3モードではL0の次にL1、その次にL2というように梱包される。図示したものがこれである。

         +-------------------------------+
     R1  |              L0               |
         +-------------------------------+

         +-------------------------------+--------+
     R2a |              L0               |   L1   |
         +-------------------------------+--------+

         +-------------------------------+--------+
     R2b |              L0               |   L2   |
         +-------------------------------+--------+

         +-------------------------------+--------+--------+
     R3  |              L0               |   L1   |   L2   |
         +-------------------------------+--------+--------+

一つのフレームの大きさは、表3で表されたモードで決定される。フレームの実際の数値は音響データ部分のサイズから容易に推測できる。すなわち、

nb_frames = (オーディオデータの大きさ) / (フレームの大きさ)

一方で、すべてのフレームは詳細に調べなければならない。上記の除算に剰余が存在するならば、受信したペイロードの中の剰余に相当するバイト列は無視しなければならない[MUST]。

ペイロード形式の要素[編集]

今節では、G.711.1でのRTP送信で付加的な機能を構成するために用いられるかもしれない値を定義する。

G.711のA-lawとμ-lawの両方を、基盤レイヤ（core layer）L0として扱う。しかし、A-lawとμ-lawの間には相互運用性がない。そこで、同一の値を持った二つのメディアタイプ、すなわちA-law用にaudo/PCMA-WBが、μ-law用にaudio/PCMU-WBが定義される。これは、G.711のためのメディアタイプ仕様であるaudio/PCMAとaudio/PCMUに相当する。

その値はG.711.1用メディアサブタイプの登録の一環として、この文書で定義される。セッション記述プロトコル（SDP）[RFC 4566]の内での値の配置についても、SDPを用いるアプリケーション向けに提供される。MIMEあるいはSDPを用いない制御プロトコルでは、メディアタイプ値はその制御プロトコル特有の形式で配置されねばならない。

PCMA-WBメディアタイプ登録[編集]

この登録は[RFC 4288]と[RFC 4855]で定義された定型書式を用いて成される。

型名（Type name）

audio

補助型名（Subtype name）

PCMA-WB

必須値（Required parameters）

なし。

付加値（Optional parameters）

mode-set

有効なコーデックモードの集まりは、全てのモードの部分集合に限定する。設定可能な値はコンマ（,）で分割されたモードの一覧、すなわち1、2、3、4（表3にあるモードインデックスを見よ）である。モードは優先度の高い順に並べられ、先頭のものが推奨される。もしmode-setが定められているならば、互換性のないモードを用いてエンコードされた任意のRTPペイロード内のフレームは送信されてはならない[MUST NOT]。この値が存在しないのならば、あらゆるコーデックモードが許容される。

ptime

パケット中にメディアを表す時間の推奨値（ミリセカンド）。整数で（フレームサイズである）5の倍数となる値となるはずである。RFC 4566の第6節を見よ。

maxptime

パケット内に格納することのできる時間の最大値（ミリセカンド）。整数で（フレームサイズである）5の倍数となるはずである。RFC 4566の第6節を見よ。

エンコーディングの考え方（Encoding considerations）: このメディアタイプはバイナリデータを含んでフレーム化される。RFC 4288の第8節を見よ。
セキュリティの考え方（Security considerations）: 第8節を見よ。
相互運用性の考え方（Interoperability considerations）: なし。
文書化された仕様: RFC 5391
このメディアタイプを用いるアプリケーション: 音響および映像会議ツール。
追加情報: なし。
詳細情報の照会先担当者名と電子メールアドレス: Aurelien Sollaud, [1]
使用目的: 一般利用
制限事項: このメディアタイプはRTPフレーム化に依存するので、RTPを通した通信にのみ適用される。
著者: Aurelien Sollaud
改版管理者: IESGから委任されたIETF音響/映像通信作業部会

PCMU-WBメディアタイプ登録[編集]

この登録は[RFC 4288]と[RFC 4855]で定義された定型書式を用いて成される。

型名（Type name）

audio

補助型名（Subtype name）

PCMU-WB

必須値（Required parameters）

なし。

付加値（Optional parameters）

mode-set

有効なコーデックモードの集まりは、全てのモードの部分集合に限定する。設定可能な値はコンマ（,）で分割されたモードの一覧、すなわち1、2、3、4（表3にあるモードインデックスを見よ）である。モードは優先度の高い順に並べられ、先頭のものが推奨される。もしmode-setが定められているならば、互換性のないモードを用いてエンコードされたRTPペイロード内のフレームは送信されてはならない[MUST NOT]。この値が存在しないのならば、あらゆるコーデックモードが許容される。

ptime

パケット中にメディアを表す時間の推奨値（ミリセカンド）。整数で（フレームサイズである）5の倍数となる値となるはずである。RFC 4566の第6節を見よ。

maxptime

パケット内に格納することのできる時間の最大値（ミリセカンド）。整数で（フレームサイズである）5の倍数となるはずである。RFC 4566の第6節を見よ。

エンコーディングの考え方（Encoding considerations）: このメディアタイプはバイナリデータを含んでフレーム化される。RFC 4288の第8節を見よ。
セキュリティの考え方（Security considerations）: 第8節を見よ。
相互運用性の考え方（Interoperability considerations）: なし。
文書化された仕様: RFC 5391
このメディアタイプを用いるアプリケーション: 音響および映像会議ツール。
追加情報: なし。
詳細情報の照会先担当者名と電子メールアドレス: Aurelien Sollaud, [2]
使用目的: 一般利用
制限事項: このメディアタイプはRTPフレーム化に依存するので、RTPを通した通信にのみ適用される。
著者: Aurelien Sollaud
改版管理者: IESGから委任されたIETF音響/映像通信作業部会

SDP値への割り当て[編集]

このメディアタイプ仕様に沿って運ばれる情報は、主にRTPセッションを記述するために用いられる、セッション記述プロトコル（SDP）[RFC 4566]内の定められたフィールドへの割り当てを持っている。SDPがG.711.1コーデックを用いた特定のセッションで利用される場合、割り当ては以下のようになる。すなわち、

メディアタイプ（「audio」）は、メディア名を表すSDPの「m=」に入る
メディアサブタイプ（「PCMA-WB」もしくは「PCMU-WB」）は、符号化方法名としてSDPの「a=rtpmap」に入る。「a=rtpmap」の中のRTPクロックレートは、G.711.1のためには16000でなければならない[MUST]。
「mode-set」値は、文字列「mode-set=値」として複製される結果「a=fmtp」に入る。
「ptime」値と「maxptime」値はそれぞれ、SDPの「a=ptime」と「a=maxptime」に入る。

オファー/アンサーモデルでの考え方[編集]

RTPペイロードでG.711.1の利用を交渉するためにSDPオファー/アンサー手続きRFC 3264を用いるとき、以下の考え方を適用する。すなわち、

G.711.1はG.711の拡張なので、オファーでは「m=audio」行の中でG.711.1を表すと共に、G.711の受け入れについて通知すべきである[SHOULD]。これはG.711.1とG.711のみ利用可能な相手との両者で相互運用を許容するだろう。言わば、PCMA-WBに加えてPCMAメディアサブタイプを、あるいはPCMU-WBに加えてPCMUのオファーを行うものである。
そのようなオファーのA-lawでの例の一部を下に示す。
参考までに、G.711のためのペイロード形式はRFC 3551の第4.5.14節で定義されている。

        m=audio 54874 RTP/AVP 96 8
        a=rtpmap:96 PCMA-WB/16000
        a=rtpmap:8 PCMA/8000

「mode-set」値は双方向になる。すなわち、宣言した値によって送受信されるために、両者のメディアに限られたmode-set値が適用される。mode-set値がオファーに存在したなら、アンサーでは同一のmode-set値、あるいはそのmode-set値の部分集合の、少なくとも一方を返さねばならない[MUST]。アンサーでは優先順位を変更してもよい[MAY]。オファーにmode-setが存在しなかったなら、利用できるモードに限ってmode-set値を返してもよい[MAY]。どのような場合であっても、オファーの中のmode-set値は、アンサーによって削除されたモードのフレームで送信されてはならない[MUST NOT]。
マルチキャストセッションについて、オファーにmode-set値が存在して、オファーされたmode-set値を利用できるならば、アンサーはそのセッションで共有することになる[SHALL]。
多くの場合、「ptime」値と「maxptime」値は相互運用できないだろう。「ptime」値を扱うSDPオファー/アンサーは、RFC 3264で記述されている。「maxptime」値も同様の方法で取り扱われなければならない[MUST]。
オファー内の任意の未知の値は受信側で無視されねばならず[MUST]、アンサーに含んではならない[MUST NOT]。

SDPのオファー/アンサー交換のある例を以下に示す。

例1

オファー: G.711.1の全てのモードと代替手段であるG.711がμ-lawで記載されている

        m=audio 54874 RTP/AVP 96 97 0 8
        a=rtpmap:96 PCMU-WB/16000
        a=rtpmap:97 PCMA-WB/16000
        a=rtpmap:0 PCMU/8000
        a=rtpmap:8 PCMA/8000

アンサー: 全てのモードを受け入れ、μ-lawとA-lawの両方が記載されている

        m=audio 59452 RTP/AVP 96 97
        a=rtpmap:96 PCMU-WB/16000
        a=rtpmap:97 PCMA-WB/16000

例2

オファー: G.711.1の全てのモードと代替手段であるG.711がA-lawで記載されている

        m=audio 54874 RTP/AVP 96 97 8 0
        a=rtpmap:96 PCMA-WB/16000
        a=rtpmap:97 PCMU-WB/16000

アンサー: A-lawのR3モードのみを要求している

        m=audio 59452 RTP/AVP 96
        a=rtpmap:96 PCMA-WB/16000
        a=fmtp:96 mode-set=4

例3

オファー: G.711.1の二つのモードR2bとR3をA-lawで求め、R3が推奨されている

        m=audio 54874 RTP/AVP 96
        a=rtpmap:96 PCMA-WB/16000
        a=fmtp:96 mode-set=4,3

アンサー: オファーを受け入れている; もしアンサーで単一のモードに限定したいのなら、mode-set値に単一の値のみ回答すればよく、この例ではR2bモードのためにmode-set=3とすればよい。

        m=audio 59452 RTP/AVP 96
        a=rtpmap:96 PCMA-WB/16000
        a=fmtp:96 mode-set=4,3

宣言型SDPでの考え方[編集]

SDPを宣言型で用いるためのいかなる仕様も、このペイロード形式用に定義されていない。SDPによって得られる設定は、そのセッションでメディアを送受信する時に用いられねばならない[MUST]。

G.711との相互運用性[編集]

G.711.1のL0レイヤはG.711と完全な相互運用性があり、L0レイヤはG.711.1の全モードに埋め込まれている。これは、G.711.1とG.711の相互変換処理を容易にする。

G.711.1パケットを受信するゲートウェイやその他の任意のネットワーク機器が、音響信号を再エンコードやデコードする必要なしに、G.711互換のペイロードを容易に展開することができる。上位レイヤ（L1、およびL2)があればそれをはぎ取って、ペイロードの音響データを簡単に取り出せねばならない。

G.711.1パケットがいくつかのフレームを含む場合、フレームごとにL0レイヤを連結したものがG.711互換のペイロードを形作るだろう。

輻輳制御[編集]

RTPのための輻輳制御は[RFC 3550]と何か適当なプロファイル（たとえば[RFC 3551]）に従って用いられる。

埋め込まれたG.711.1音響データの性質が、輻輳制御の助けとなることができるので、必要なときはより低いビットレートの符号化モードを選択することができる。この属性は複数のモードが能力交換されたとき（SDPに「mode-set」値が存在しない、あるいは「mode-set」値に少なくとも二つのモードがある）にのみ用いられる。

RTPペイロードのそれぞれにカプセル化されるフレームの数は、ヘッダ部分のオーバーヘッドを原因にしてRTPストリーム全体の帯域幅に影響を与える。それぞれのRTPペイロードにより多くのフレームを梱包することで、増大する遅と減少するエラー耐久性を犠牲にしながらも、送信パケットの数を減らしつつヘッダ部分のオーバーヘッドを減らすことができる。

セキュリティの考え方[編集]

この仕様書で定義されるペイロード形式を用いるRTPパケットは、RTP仕様[RFC 3550]と何か適当なプロファイル（例えば[RFC 3551]）で議論された一般的なセキュリティの考え方に従属している。

この形式が音声/音響をエンコードして配送するときに、主なセキュリティ問題には、音声/音響自身の機密性、完全性の防衛、そして認証がある。それ自身を形作るペイロードには任意のセキュリティ機構を内蔵しない。セキュアなリアルタイム配送プロトコル（SRTP）[RFC 3711]のような、適切な外部の機構が用いられてもよい[MAY]。

破損したデータグラムを受信したことによって、思いもよらないサービス無効化の危険を引き起こすことになるので、このペイロード形式とG.711.1エンコーディングは、受信側の演算中に著しく均一性を欠いたものを外部に送らない。加えて、スクリプトのような動的な内容のいかなる形式も含まない。

IANAへの考え方[編集]

二つの新たなメディアサブタイプ（audio/PCMA-WBとaudio/PCMU-WB）はIANAによって登録されている。第5.1節、第5.2節を見よ。

文献[編集]

参照[編集]

ITU-G.711.1: International Telecommunications Union, "Wideband embedded extension for G.711 pulse code modulation", ITU-T Recommendation G.711.1, March 2008.
RFC2119: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC3264: Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
RFC3550: Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
RFC3551: Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
RFC4288: Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
RFC4566: Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
RFC4855: Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.

参考[編集]

ITU-G.711: International Telecommunications Union, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988.
RFC3389: Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, September 2002.
RFC3711: Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

著者の連絡先: Aurelien Sollaud

以下は省略します。