Network Working Group J. Sjoberg
Request for Comments: 4352 M. Westerlund
Category: Standards Track Ericsson
A. Lakaniemi
S. Wenger
Nokia
January 2006
RTP Payload Format for the
Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document specifies a Real-time Transport Protocol (RTP) payload format for Extended Adaptive Multi-Rate Wideband (AMR-WB+) encoded audio signals. The AMR-WB+ codec is an audio extension of the AMR-WB speech codec. It encompasses the AMR-WB frame types and a number of new frame types designed to support high-quality music and speech. A media type registration for AMR-WB+ is included in this specification.
この文書では、拡張適応マルチレート広帯域（AMR-WB +）エンコードされたオーディオ信号のためのリアルタイム転送プロトコル（RTP）ペイロード形式を指定します。 AMR-WB +コーデックは、AMR-WB音声コーデックのオーディオ拡張したものです。これは、AMR-WBフレームタイプと、高品質の音楽やスピーチをサポートするために設計された新しいフレームタイプの数を包含する。 AMR-WB +のメディアタイプ登録は、本明細書に含まれます。
Table of Contents
目次
1. Introduction ....................................................3
2. Definitions .....................................................4
2.1. Glossary ...................................................4
2.2. Terminology ................................................4
3. Background of AMR-WB+ and Design Principles .....................4
3.1. The AMR-WB+ Audio Codec ....................................4
3.2. Multi-rate Encoding and Rate Adaptation ....................8
3.3. Voice Activity Detection and Discontinuous Transmission ....8
3.4. Support for Multi-Channel Session ..........................8
3.5. Unequal Bit-Error Detection and Protection .................9
3.6. Robustness against Packet Loss .............................9
3.6.1. Use of Forward Error Correction (FEC) ...............9
3.6.2. Use of Frame Interleaving ..........................10
3.7. AMR-WB+ Audio over IP Scenarios ...........................11
3.8. Out-of-Band Signaling .....................................11
4. RTP Payload Format for AMR-WB+ .................................12
4.1. RTP Header Usage ..........................................13
4.2. Payload Structure .........................................14
4.3. Payload Definitions .......................................14
4.3.1. Payload Header .....................................14
4.3.2. The Payload Table of Contents ......................15
4.3.3. Audio Data .........................................20
4.3.4. Methods for Forming the Payload ....................21
4.3.5. Payload Examples ...................................21
4.4. Interleaving Considerations ...............................24
4.5. Implementation Considerations .............................25
4.5.1. ISF Recovery in Case of Packet Loss ................26
4.5.2. Decoding Validation ................................28
5. Congestion Control .............................................28
6. Security Considerations ........................................28
6.1. Confidentiality ...........................................29
6.2. Authentication and Integrity ..............................29
7. Payload Format Parameters ......................................29
7.1. Media Type Registration ...................................30
7.2. Mapping Media Type Parameters into SDP ....................32
7.2.1. Offer-Answer Model Considerations ..................32
7.2.2. Examples ...........................................34
8. IANA Considerations ............................................34
9. Contributors ...................................................34
10. Acknowledgements ..............................................34
11. References ....................................................35
11.1. Normative References .....................................35
11.2. Informative References ...................................35
This document specifies the payload format for packetization of Extended Adaptive Multi-Rate Wideband (AMR-WB+) [1] encoded audio signals into the Real-time Transport Protocol (RTP) [3]. The payload format supports the transmission of mono or stereo audio, aggregating multiple frames per payload, and mechanisms enhancing the robustness of the packet stream against packet loss.
この文書[1]はリアルタイムトランスポートプロトコル（RTP）にオーディオ信号を符号化された拡張適応マルチレート広帯域（AMR-WB +）のパケットのペイロードのフォーマットを指定する[3]。ペイロード・フォーマットは、パケット損失に対するパケットストリームのロバスト性を向上させる複数のペイロード当たりのフレーム、及びメカニズムを凝集、モノまたはステレオ・オーディオの送信をサポートします。
The AMR-WB+ codec is an extension of the Adaptive Multi-Rate Wideband (AMR-WB) speech codec. New features include extended audio bandwidth to enable high quality for non-speech signals (e.g., music), native support for stereophonic audio, and the option to operate on, and switch between, several internal sampling frequencies (ISFs). The primary usage scenario for AMR-WB+ is the transport over IP. Therefore, interworking with other transport networks, as discussed for AMR-WB in [7], is not a major concern and hence not addressed in this memo.
AMR-WB +コーデックは適応マルチレート広帯域（AMR-WB）音声コーデックの拡張です。新機能には非音声信号用の高品質（例えば、音楽）、ステレオオーディオのネイティブサポート、および上で動作するオプションを有効にして、切り替える、いくつかの内部のサンプリング周波数（ISF申告）する拡張オーディオ帯域幅が含まれます。 AMR-WB +の主な使用シナリオは、IP経由の輸送です。したがって、他のトランスポートネットワークとのインターワーキングは、[7]にAMR-WBのために説明したように、したがって主要な関心と、このメモで扱われていません。
The expected key application for AMR-WB+ is streaming. To make the packetization process on a streaming server as efficient as possible, an octet-aligned payload format is desirable. Therefore, a bandwidth-efficient mode (as defined for AMR-WB in [7]) is not specified herein; the bandwidth savings of the bandwidth-efficient mode would be very small anyway, since all extension frame types are octet aligned.
AMR-WB +の期待キーアプリケーションがストリーミングされます。可能な限り効率的としてストリーミングサーバにパケット化処理を行うために、オクテット整列ペイロード形式が望ましいです。したがって、帯域幅効率モード（[7]でAMR-WBのために定義されたように）本明細書で指定されていません。すべての拡張フレームタイプがオクテット整列されているので、帯域幅効率的なモードの帯域幅の節約は、とにかく非常に小さくなります。
The stereo encoding capability of AMR-WB+ renders the support for multi-channel transport at RTP payload format level, as specified for AMR-WB [7], obsolete. Therefore, this feature is not included in this memo.
[7]、廃止されたAMR-WBのために指定されるように、AMR-WB +のステレオ符号化機能は、RTPペイロードフォーマットレベルでマルチチャネル・トランスポートのサポートをレンダリングします。そのため、この機能はこのメモには含まれていません。
This specification does not include a definition of a file format for AMR-WB+. Instead, it refers to the ISO-based 3GP file format [14], which supports AMR-WB+ and provides all functionality required. The 3GP format also supports storage of AMR, AMR-WB, and many other multi-media formats, thereby allowing synchronized playback.
この仕様は、AMR-WB +のファイル形式の定義が含まれていません。代わりに、AMR-WB +をサポートし、必要なすべての機能を提供し、ISOベースの3GPファイル形式[14]を指します。 3GPフォーマットは、それによって同期再生を可能にする、AMR、AMR-WB、および他の多くのマルチメディア形式のストレージをサポートします。
The rest of the document is organized as follows: Background information on the AMR-WB+ codec, and design principles, can be found in Section 3. The payload format itself is specified in Section 4. Sections 5 and 6 discuss congestion control and security considerations, respectively. In Section 7, a media type registration is provided.
次のように文書の残りが構成されています：AMR-WB +コーデックの背景情報、および設計原理は、3章で見つけることができるペイロードフォーマット自体は4セクション5と6は、輻輳制御とセキュリティの考慮事項について説明し、セクションに指定されています、それぞれ。セクション7で、メディアタイプ登録が提供されます。
3GPP - Third Generation Partnership Project AMR - Adaptive Multi-Rate (Codec) AMR-WB - Adaptive Multi-Rate Wideband (Codec) AMR-WB+ - Extended Adaptive Multi-Rate Wideband (Codec) CN - Comfort Noise DTX - Discontinuous Transmission FEC - Forward Error Correction FT - Frame Type ISF - Internal Sampling Frequency SCR - Source-Controlled Rate Operation SID - Silence Indicator (the frames containing only CN parameters) TFI - Transport Frame Index TS - Timestamp VAD - Voice Activity Detection UED - Unequal Error Detection UEP - Unequal Error Protection
3GPP - 第三世代パートナーシッププロジェクトAMR - 適応マルチレート（コーデック）AMR-WB - 適応マルチレート広帯域（コーデック）AMR-WB + - 拡張適応マルチレート広帯域（コーデック）CN - コンフォートノイズDTX - 不連続送信FEC - 前方誤り訂正FT - フレームタイプISF - 内部サンプリング周波数SCR - ソース - 制御された速度操作SID - サイレンスインジケータ（のみCNパラメータを含むフレーム）TFI - トランスポートフレームインデックスTS - タイムスタンプVAD - 音声アクティビティ検出UED - 不均一誤り検出UEP - 不均一誤り保護
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
The Extended Adaptive Multi-Rate Wideband (AMR-WB+) [1] audio codec is designed to compress speech and audio signals at low bit-rate and good quality. The codec is specified by the Third Generation Partnership Project (3GPP). The primary target applications are 1) the packet-switched streaming service (PSS) [13], 2) multimedia messaging service (MMS) [18], and 3) multimedia broadcast and multicast service (MBMS) [19]. However, due to its flexibility and robustness, AMR-WB+ is also well suited for streaming services in other highly varying transport environments, for example, the Internet.
拡張適応マルチレート広帯域（AMR-WB +）[1]のオーディオコーデックは、低ビットレートとの良好な品質で音声及びオーディオ信号を圧縮するように設計されています。コーデックは、第三世代パートナーシッププロジェクト（3GPP）によって指定されます。プライマリターゲットアプリケーション）が1であるパケット交換ストリーミングサービス（PSS）[13]、2）マルチメディアメッセージングサービス（MMS）[18]、および3）マルチメディアブロードキャストおよびマルチキャストサービス（MBMS）[19]。しかし、その柔軟性と堅牢性に、AMR-WB +は、インターネット、例えば、また、他の高度変化の輸送環境におけるストリーミングサービスに適しています。
3GPP originally developed the AMR-WB+ audio codec for streaming and messaging services in Global System for Mobile communications (GSM) and third generation (3G) cellular systems. The codec is designed as an audio extension of the AMR-WB speech codec. The extension adds new functionality to the codec in order to provide high audio quality for a wide range of signals including music. Stereophonic operation has also been added. A new, high-efficiency hybrid stereo coding algorithm enables stereo operation at bit-rates as low as 6.2 kbit/s.
3GPPは元々移動体通信（GSM）及び第3世代（3G）セルラーシステムのためのグローバルシステムにおけるストリーミングやメッセージングサービスのためのAMR-WB +オーディオコーデックを開発しました。コーデックは、AMR-WB音声コーデックのオーディオ拡張機能として設計されています。拡張子は音楽を含めた広範囲の信号のための高音質を提供するために、コーデックに新しい機能を追加します。ステレオ操作も追加されました。符号化アルゴリズム新しい、高効率ハイブリッドステレオ6.2キロビット/秒という低いビットレートでステレオ操作を可能にします。
The AMR-WB+ codec includes the nine frame types specified for AMR-WB, extended by new bit-rates ranging from 5.2 to 48 kbit/s. The AMR-WB frame types can employ only a 16000 Hz sampling frequency and operate only on monophonic signals. The newly introduced extension frame types, however, can operate at a number of internal sampling frequencies (ISFs), both in mono and stereo. Please see Table 24 in [1] for details. The output sampling frequency of the decoder is limited to 8, 16, 24, 32, or 48 kHz.
AMR-WB +コーデックは5.2から48キロビット/秒の範囲の新しいビットレートによって拡張AMR-WBに指定9つのフレームタイプを含みます。 AMR-WBフレームタイプは、16000 Hzのサンプリング周波数を使用し、モノラル信号にのみ動作することができます。新たに導入された拡張フレームタイプは、しかしながら、モノラルとステレオの両方で、内部サンプリング周波数（ISF申告）の数で動作することができます。詳細については、[1]の表24を参照してください。デコーダの出力サンプリング周波数は、8、16、24、32、または48 kHzに制限されます。
An overview of the AMR-WB+ encoding operations is provided as follows. The encoder receives the audio sampled at, for example, 48 kHz. The encoding process starts with pre-processing and resampling to the user-selected ISF. The encoding is performed on equally sized super-frames. Each super-frame corresponds to 2048 samples per channel, at the ISF. The codec carries out a number of encoding decisions for each super-frame, thereby choosing between different encoding algorithms and block lengths, so as to achieve a fidelity-optimized encoding adapted to the signal characteristics of the source. The stereo encoding (if used) executes separately from the monophonic core encoding, thus enabling the selection of different combinations of core and stereo encoding rates. The resulting encoded audio is produced in four transport frames of equal length. Each transport frame corresponds to 512 samples at the ISF and is individually usable by the decoder, provided that its position in the super-frame structure is known.
次のようにAMR-WB +符号化動作の概要が提供されます。エンコーダは、例えば、48キロヘルツのでサンプリングされたオーディオを受信します。符号化プロセスは、ユーザが選択したISFの前処理及びリサンプリング始まります。符号化は、同じサイズのスーパーフレーム上で実行されます。各スーパーフレームは、ISFに、チャネルあたり2048個のサンプルに相当します。ソースの信号特性に適合し忠実に最適化された符号化を達成するようにコーデックは、それによって異なる符号化アルゴリズムとブロック長との間で選択すると、各スーパーフレームのための符号化決定の数を行います。 （使用している場合）ステレオ符号化は、このようにコアとステレオ符号化レートの異なる組み合わせの選択を可能にする、モノラルコア符号化とは別に実行します。得られた符号化されたオーディオは、等しい長さの4つの搬送フレームで製造されます。各伝送フレームは、ISFで512個のサンプルに対応し、デコーダによって個別に使用可能な、スーパーフレーム構造内の位置が既知であることを条件とします。
The codec supports 13 different ISFs, ranging from 12.8 to 38.4 kHz, as described by Table 24 of [1]. The high number of ISFs allows a trade-off between the audio bandwidth and the target bit-rate. As encoding is performed on 2048 samples at the ISF, the duration of a super-frame and the effective bit-rate of the frame type in use varies.
コーデックは、表24で説明したように、12.8から38.4キロヘルツまでの範囲の、13種類のISF申告をサポートする[1]。 ISF申告の高い数は、オーディオ帯域幅とターゲットビットレートとのトレードオフを可能にします。符号化がISFで2048のサンプル上で実行されるように、スーパーフレームの期間および使用のフレームタイプの有効ビットレートが変化します。
The ISF of 25600 Hz has a super-frame duration of 80 ms. This is the 'nominal' value used to describe the encoding bit-rates henceforth. Assuming this normalization, the ISF selection results in bit-rate variations from 1/2 up to 3/2 of the nominal bit-rate.
25600ヘルツのISFは、80ミリ秒のスーパーフレームの持続時間を有します。このことは、今後の符号化ビットレートを記述するために使用される「公称」値です。公称ビットレートの3/2まで1/2からビットレートの変動にISFの選択結果は、この正規化を想定します。
The encoding for the extension modes is performed as one monophonic core encoding and one stereo encoding. The core encoding is executed by splitting the monophonic signal into a lower and a higher frequency band. The lower band is encoded employing either algebraic code excited linear prediction (ACELP) or transform coded excitation (TCX). This selection can be made once per transport frame, but must obey certain limitations of legal combinations within the super-frame. The higher band is encoded using a low-rate parametric bandwidth extension approach.
拡張モードのための符号化は、一つのモノラルコアエンコーディング一のステレオ符号化として実行されます。コア符号化は、より低い及びより高い周波数帯域にモノラル信号を分割することによって実行されます。下のバンドは、代数符号励振線形予測（ACELP）または符号化励起（TCX）を形質転換のいずれかを用いて符号化されます。この選択は、伝送フレーム毎に一度行うことができますが、スーパーフレーム内の法的な組み合わせの一定の制限に従わなければなりません。高帯域は、低レートパラメトリック帯域幅拡張のアプローチを使用して符号化されます。
The stereo signal is encoded employing a similar frequency band decomposition; however, here the signal is divided into three bands that are individually parameterized.
ステレオ信号は、同様の周波数バンド分解を用いた符号化されます。しかし、ここで信号は、個別にパラメータ化される3つのバンドに分割されています。
The total bit-rate produced by the extension is the result of the combination of the encoder's core rate, stereo rate, and ISF. The extension supports 8 different core encoding rates, producing bit-rates between 10.4 and 24.0 kbit/s; see Table 22 in [1]. There are 16 stereo encoding rates generating bit-rates between 2.0 and 8.0 kbit/s; see Table 23 in [1]. The frame type uniquely identifies the AMR-WB modes, 4 fixed extension rates (see below), 24 combinations of core and stereo rates for stereo signals, and the 8 core rates for mono signals, as listed in Table 25 in [1]. This implies that the AMR-WB+ supports encoding rates between 10.4 and 32 kbit/s, assuming an ISF of 25600 Hz.
伸長によって産生される総ビットレートは、エンコーダのコア速度、ステレオレート、およびISFの組み合わせの結果です。拡張は、10.4及び24.0キロビット/秒の間のビットレートを生成する、8つの異なるコア符号化レートをサポート。 [1]の表22を参照。 2.0及び8.0キロビット/秒の間のビットレートを生成する16人のステレオ符号化率が存在します。 [1]の表23を参照。 [1]の表25に記載されているように、フレームタイプが一意に、AMR-WBモード、4つの固定伸長速度（以下を参照）、ステレオ信号用コアとステレオ率の24個の組み合わせ、およびモノラル信号の8つのコアレートを識別する。これは、AMR-WB +は25600ヘルツのISFを仮定して、10.4および32キロビット/秒の間の符号化レートをサポートすることを意味します。
Different ISFs allow for additional freedom in the produced bit-rates and audio quality. The selection of an ISF changes the available audio bandwidth of the reconstructed signal, and also the total bit-rate. The bit-rate for a given combination of frame type and ISF is determined by multiplying the frame type's bit-rate with the used ISF's bit-rate factor; see Table 24 in [1].
別のISF申告は、生成ビットレートとオーディオ品質で追加の自由を可能にします。 ISFの選択は、使用可能なオーディオ再生信号の帯域幅、および総ビットレートを変更します。フレームタイプとISFの所与の組み合わせについてビットレートが使用ISFのビットレート係数とフレームタイプのビットレートを乗じることによって決定されます。 [1]の表24を参照。
The extension also has four frame types which have fixed ISFs. Please see frame types 10-13 in Table 21 in [1]. These four pre-defined frame types have a fixed input sampling frequency at the encoder, which can be set at either 16 or 24 kHz. Like the AMR-WB frame types, transport frames encoded utilizing these frame types represent exactly 20 ms of the audio signal. However, they are also part of 80 ms super-frames. Frame types 0-13 (AMR-WB and fixed extension rates), as listed in Table 21 in [1], do not require an explicit ISF indication. The other frame types, 14-47, require the ISF employed to be indicated.
拡張子はまた、ISF申告を固定している4つのフレームタイプがあります。表21にフレームタイプ10-13を参照してください[1]。これら四つの事前定義されたフレームタイプは16または24 kHzで設定することができるエンコーダ、固定入力サンプリング周波数を有します。 AMR-WBフレームタイプと同様に、これらのフレームタイプを利用して符号化されたトランスポートフレームは、オーディオ信号の正確に20ミリ秒を表します。しかし、彼らはまた、80ミリ秒のスーパーフレームの一部です。表21に記載されているフレームタイプ0-13（AMR-WBと固定伸長速度）は、[1]は、明示的なISF指示を必要としません。他のフレームタイプ、14-47は、使用ISFを示すことを必要とします。
The 32 different frame types of the extension, in combination with 13 ISFs, allows for a great flexibility in bit-rate and selection of desired audio quality. A number of combinations exist that produce the same codec bit-rate. For example, a 32 kbit/s audio stream can be produced by utilizing frame type 41 (i.e., 25.6 kbit/s) and the ISF of 32kHz (5/4 * (19.2+6.4) = 32 kbit/s), or frame type 47 and the ISF of 25.6 kHz (1 * (24 + 8) = 32 kbit/s). Which combination is more beneficial for the perceived audio quality depends on the content. In the above example, the first case provides a higher audio bandwidth, while the second one spends the same number of bits on somewhat narrower audio bandwidth but provides higher fidelity. Encoders are free to select the combination they deem most beneficial.
伸長の32個の異なるフレームタイプは、13件のISF申告と組み合わせて、所望のオーディオ品質のビットレートおよび選択における高い柔軟性を可能にします。組み合わせの数は、それが同じコーデックビットレートを生成存在します。例えば、32キロビット/秒音声ストリームがフレームタイプ41を利用して製造することができる（すなわち、25.6キロビット/秒）との32kHzのISF（5/4 *（19.2 + 6.4）は32キロビット/秒=）、またはフレームタイプ47および25.6 kHzの（1 *（24 + 8）= 32キロビット/秒）のISF。どの組み合わせの知覚オーディオ品質のために、より有益であるコンテンツに依存します。二つ目はやや狭いオーディオ帯域幅で同じ数のビットを費やすが、より高い忠実度を提供しながら、上記の例では、最初のケースは、より高いオーディオ帯域幅を提供します。エンコーダは、彼らが最も有益と考えるの組み合わせを自由に選択することができます。
Since a transport frame always corresponds to 512 samples at the used ISF, its duration is limited to the range 13.33 to 40 ms; see Table 1. An RTP Timestamp clock rate of 72000 Hz, as mandated by this specification, results in AMR-WB+ transport frame lengths of 960 to 2880 timestamp ticks, depending solely on the selected ISF.
伝送フレームが常に使用ISFで512個のサンプルに対応しているので、その持続時間は40ミリ秒の範囲13.33に限定されます。この仕様で義務として、72000ヘルツの表1】RTPタイムスタンプのクロックレートを参照して、960 2880へのタイムスタンプのAMR-WB +の伝送フレーム長の結果は、選択されたISFのみに依存し、マダニ。
Index ISF Duration(ms) Duration(TS Ticks @ 72 kHz)
------------------------------------------------------
0 N/A 20 1440
1 12800 40 2880
2 14400 35.55 2560
3 16000 32 2304
4 17067 30 2160
5 19200 26.67 1920
6 21333 24 1728
7 24000 21.33 1536
8 25600 20 1440
9 28800 17.78 1280
10 32000 16 1152
11 34133 15 1080
12 36000 14.22 1024
13 38400 13.33 960
Table 1: Normative number of RTP Timestamp Ticks for each Transport Frame depending on ISF (ISF and Duration in ms are rounded)
表1：規範ISFに応じて、各伝送フレームのためのRTPタイムスタンプティック数（ISFおよびMSで時間が丸められています）
The encoder is free to change both the ISF and the encoding frame type (both mono and stereo) during a session. For the extension frame types with index 10-13 and 16-47, the ISF and frame type changes are constrained to occur at super-frame boundaries. This implies that, for the frame types mentioned, the ISF is constant throughout a super-frame. This limitation does not apply for frame types with index 0-9, 14, and 15; i.e., the original AMR-WB frame types.
エンコーダは、セッション中にISFと符号化フレームタイプ（モノラルとステレオの両方）の両方を変更することが自由です。インデックス10-13と16-47と拡張フレームのタイプについては、ISFとフレームタイプの変更は、スーパーフレームの境界で発生するように制約されています。これは、前述のフレームタイプのため、ISFは、スーパーフレーム全体で一定である、ということを意味します。この制限は、インデックス0-9、14、及び15と、フレームタイプには適用されません。すなわち、元のAMR-WBフレームタイプ。
A number of features of the AMR-WB+ codec require special consideration from a transport point of view, and solutions that could perhaps be viewed as unorthodox. First, there are constraints on the RTP timestamping, due to the relationship of the frame duration and the ISFs. Second, each frame of encoded audio must maintain information about its frame type, ISF, and position in the super-frame.
AMR-WB +コーデックの特徴の数は、ビューの輸送ポイントから特別な配慮を必要とし、おそらく非正統的と見なすことができるソリューション。まず、フレーム期間とISF申告の関係に起因したRTPタイムスタンプの制約があります。第二に、符号化された音声の各フレームは、スーパーフレーム内のフレームタイプ、ISF、および位置についての情報を維持する必要があります。
The multi-rate encoding capability of AMR-WB+ is designed to preserve high audio quality under a wide range of bandwidth requirements and transmission conditions.
AMR-WB +のマルチレート符号化能力は、帯域幅要求及び送信条件の広い範囲の下で高い音声品質を維持するために設計されています。
AMR-WB+ enables seamless switching between frame types that use the same number of audio channels and the same ISF. Every AMR-WB+ codec implementation is required to support all frame types defined by the codec and must be able to handle switching between any two frame types. Switching between frame types employing a different number of audio channels or a different ISF must also be supported, but it may not be completely seamless. Therefore, it is recommended to perform such switching infrequently and, if possible, during periods of silence.
AMR-WB +オーディオチャネルの同じ数と同じISFを使用するフレームタイプとの間のシームレスな切り替えを可能にします。すべてのAMR-WB +コーデックの実装は、コーデックによって定義されたすべてのフレームタイプをサポートするために必要であり、任意の二つのフレームタイプを切り替えることができなければなりません。オーディオチャンネルまたは異なるISFの異なる数を採用したフレームタイプの切り替えもサポートしなければならないが、それは完全にシームレスではないかもしれません。したがって、可能な場合、無音期間中に、まれにこのような切り替えを行うとすることが推奨されます。
AMR-WB+ supports the same algorithms as AMR-WB for voice activity detection (VAD) and generation of comfort noise (CN) parameters during silence periods. However, these functionalities can only be used in conjunction with the AMR-WB frame types (FT=0-8). This option allows reducing the number of transmitted bits and packets during silence periods to a minimum. The operation of sending CN parameters at regular intervals during silence periods is usually called discontinuous transmission (DTX) or source controlled rate (SCR) operation. The AMR-WB+ frames containing CN parameters are called Silence Indicator (SID) frames. More details about the VAD and DTX functionality are provided in [4] and [5].
AMR-WB +は、音声アクティビティ検出（VAD）と無音期間中に快適ノイズ（CN）パラメータを生成するためのAMR-WBと同じアルゴリズムをサポートします。しかし、これらの機能は、AMR-WBフレームタイプ（FT = 0~8）と組み合わせて使用することができます。このオプションは最小に沈黙期間中に送信されるビットおよびパケットの数を低減することができます。沈黙期間中に一定の間隔でCNパラメータを送信する動作は、通常、不連続送信（DTX）またはソース制御された速度（SCR）動作と呼ばれます。 CNパラメータを含むAMR-WB +フレームがサイレンスインジケータ（SID）フレームと呼ばれます。 VADおよびDTX機能についての詳細は、で提供される[4]、[5]。
Some of the AMR-WB+ frame types support the encoding of stereophonic audio. Because of this native support for a two-channel stereophonic signal, it does not seem necessary to support multi-channel transport with separate codec instances, as specified in the AMR-WB RTP payload [7]. The codec has the capability of stereo to mono downmixing as part of the decoding process. Thus, a receiver that is only capable of playout of monophonic audio must still be able to decode and play signals originally encoded and transmitted as stereo. However, to avoid spending bits on a stereo encoding that is not going to be utilized, a mechanism is defined in this specification to signal mono-only audio.
AMR-WB +のフレームタイプのいくつかは、ステレオオーディオのエンコーディングをサポートしています。 AMR-WB RTPペイロードで指定されているので、2チャンネルステレオ信号のためのこのネイティブサポート、それは[7]、別のコーデックインスタンスとマルチチャネルトランスポートをサポートするのに必要な思われません。コーデックは、復号化プロセスの一部として、ダウンミックスモノステレオする能力を有します。従って、モノラルオーディオの再生のみが可能であり、受信機は依然として信号元々符号化され、ステレオとして送信をデコードして再生することができなければなりません。しかし、利用するつもりはないステレオ符号化への支出ビットを回避するために、機構がモノ音声のみを通知するために本明細書に定義されています。
The audio bits encoded in each AMR-WB frame are sorted according to their different perceptual sensitivity to bit errors. In cellular systems, for example, this property can be exploited to achieve better voice quality, by using unequal error protection and detection (UEP and UED) mechanisms. However, the bits of the extension frame types of the AMR-WB+ codec do not have a consistent perceptual significance property and are not sorted in this order. Thus, UEP or UED is meaningless with the extension frame types. If there is a need to use UEP or UED for AMR-WB frame types, it is recommended that RFC 3267 [7] be used.
各AMR-WBフレーム内符号化されたオーディオビットは、ビットエラーに対する異なる知覚感度に応じてソートされます。セルラシステムでは、例えば、このプロパティは、不均一誤り保護及び検出（UEPとUED）メカニズムを使用して、より良好な音声品質を実現するために利用することができます。しかし、AMR-WB +コーデックの拡張フレームタイプのビットは、一貫性の知覚的重要性の性質を持っていないと、この順にソートされていません。したがって、UEP又はUEDは、拡張フレームタイプと無意味です。 AMR-WBフレームタイプのUEP又はUEDを使用する必要がある場合は、RFC 3267 [7]に使用することが推奨されます。
The payload format supports two mechanisms to improve robustness against packet loss: simple forward error correction (FEC) and frame interleaving.
単純な前方誤り訂正（FEC）とフレームインターリーブ：ペイロードフォーマットは、パケット損失に対するロバスト性を向上させるために2つのメカニズムをサポートします。
Generic forward error correction within RTP is defined, for example, in RFC 2733 [11]. Audio redundancy coding is defined in RFC 2198 [12]. Either scheme can be used to add redundant information to the RTP packet stream and make it more resilient to packet losses, at the expense of a higher bit rate. Please see either RFC for a discussion of the implications of the higher bit rate to network congestion.
RTP内の一般的な順方向誤り訂正は、RFC 2733 [11]において、例えば、定義されています。オーディオ冗長符号化は、RFC 2198 [12]で定義されています。どちらの方式では、より高いビットレートを犠牲にして、RTPパケットストリームに冗長な情報を追加して、パケットロスに対してより弾力性にするために使用することができます。ネットワークの輻輳に高いビットレートの意味についての説明は、いずれかのRFCを参照してください。
In addition to these media-unaware mechanisms, this memo specifies an AMR-WB+ specific form of audio redundancy coding, which may be beneficial in terms of packetization overhead.
これらのメディア非認識機構に加えて、このメモは、パケットのオーバーヘッドの点で有益であり得るAMR-WB +オーディオ冗長符号化の具体的な形態を、特定します。
Conceptually, previously transmitted transport frames are aggregated together with new ones. A sliding window is used to group the frames to be sent in each payload. Figure 1 below shows an example.
概念的には、以前に送信された伝送フレームは、新しいものと一緒に集約されます。スライディングウィンドウは、グループに各ペイロードに送信するフレームを用いています。図1は、下記の例を示しています。
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
<---- p(n-1) ---->
<----- p(n) ----->
<---- p(n+1) ---->
<---- p(n+2) ---->
<---- p(n+3) ---->
<---- p(n+4) ---->
Figure 1: An example of redundant transmission
図1：冗長伝送の例
Here, each frame is retransmitted once in the following RTP payload packet. F(n-2)...f(n+4) denote a sequence of audio frames, and p(n-1)...p(n+4) a sequence of payload packets.
ここで、各フレームは、以下のRTPペイロードパケットに一回再送信されます。 Fは、（N-2）、···、F（N + 4）オーディオフレームのシーケンスを示し、P（N-1）... P（N + 4）ペイロード・パケットのシーケンス。
The mechanism described does not require signaling at the session setup. In other words, the audio sender can choose to use this scheme without consulting the receiver. For a certain timestamp, the receiver may receive multiple copies of a frame containing encoded audio data or frames indicated as NO_DATA. The cost of this scheme is bandwidth and the receiver delay necessary to allow the redundant copy to arrive.
説明のメカニズムは、セッション設定時にシグナリングを必要としません。言い換えれば、オーディオの送信者が受信機に相談することなく、この方式を使用するように選択することができます。特定のタイムスタンプのために、受信機は、NO_DATAとして示される符号化オーディオデータ又はフレームを含むフレームの複数のコピーを受信することができます。このスキームのコストは、帯域幅および冗長コピーが到着することを可能にするのに必要な受信遅延です。
This redundancy scheme provides a functionality similar to the one described in RFC 2198, but it works only if both original frames and redundant representations are AMR-WB+ frames. When the use of other media coding schemes is desirable, one has to resort to RFC 2198.
この冗長方式は、RFC 2198に記載したものと同様の機能を提供し、それは、元のフレームと冗長表現の両方が、AMR-WB +フレームである場合にのみ機能します。他のメディア符号化方式の使用が望ましい場合には、一つはRFC 2198に頼らなければなりません。
The sender is responsible for selecting an appropriate amount of redundancy based on feedback about the channel conditions, e.g., in the RTP Control Protocol (RTCP) [3] receiver reports. The sender is also responsible for avoiding congestion, which may be exacerbated by redundancy (see Section 5 for more details).
送信者は、[3]受信機レポートRTP制御プロトコル（RTCP）に、例えば、チャネル状態に関するフィードバックに基づいて、冗長性の適切な量を選択する責任があります。送信者はまた、冗長性（詳細は第5章を参照）によって悪化することができる混雑を回避する責任があります。
To decrease protocol overhead, the payload design allows several audio transport frames to be encapsulated into a single RTP packet. One of the drawbacks of such an approach is that in case of packet loss several consecutive frames are lost. Consecutive frame loss normally renders error concealment less efficient and usually causes clearly audible and annoying distortions in the reconstructed audio. Interleaving of transport frames can improve the audio quality in such cases by distributing the consecutive losses into a number of isolated frame losses, which are easier to conceal. However, interleaving and bundling several frames per payload also increases end-to-end delay and sets higher buffering requirements. Therefore, interleaving is not appropriate for all use cases or devices. Streaming applications should most likely be able to exploit interleaving to improve audio quality in lossy transmission conditions.
プロトコルオーバーヘッドを減少させるために、ペイロード設計は、いくつかの音声伝送フレームが単一のRTPパケットにカプセル化されることを可能にします。そのようなアプローチの欠点の1つは、パケット損失の場合にいくつかの連続するフレームが失われることです。連続したフレームの損失は、通常、エラー隠蔽が少なく、効率的なレンダリングと通常再構成されたオーディオにはっきり聞き取れると迷惑な歪みの原因となります。輸送フレームのインターリービングは、隠すことが容易である、単離されたフレーム損失の数に連続損失を分配することにより、このような場合には、オーディオ品質を向上させることができます。しかし、インターリービングおよびペイロード当たり数フレームバンドリングは、エンドツーエンド遅延を増大させ、より高いバッファリング要件を設定します。したがって、インタリーブは、すべてのユースケースやデバイスには適していません。ストリーミング・アプリケーションでは、最も可能性の高い損失伝送条件でのオーディオ品質を改善するためのインターリーブを活用することができるはずです。
Note that this payload design supports the use of frame interleaving as an option. The usage of this feature needs to be negotiated in the session setup.
このペイロードデザインはオプションとして、フレームのインターリーブの使用をサポートしていることに注意してください。この機能の使用方法は、セッションセットアップで交渉する必要があります。
The interleaving supported by this format is rather flexible. For example, a continuous pattern can be defined, as depicted in Figure 2.
この形式でサポートされているインタリービングはかなり柔軟です。図2に示すように、例えば、連続的なパターンは、定義することができます。
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
[ P(n) ] [ P(n+1) ] [ P(n+1) ] [ P(n+2) ] [ P(n+2) ] [ P(n+3) ] [P( [ P(n+4) ]
[P（N）] [P（N + 1）] [P（N + 1）] [P（N + 2）] [P（N + 2）] [P（N + 3）] [P（[ P（N + 4）]
Figure 2: An example of interleaving pattern that has constant delay
図2：一定の遅延を有するインタリーブパターンの一例
In Figure 2 the consecutive frames, denoted f(n-2) to f(n+4), are aggregated into packets P(n) to P(n+4), each packet carrying two frames. This approach provides an interleaving pattern that allows for constant delay in both the interleaving and deinterleaving processes. The deinterleaving buffer needs to have room for at least three frames, including the one that is ready to be consumed. The storage space for three frames is needed, for example, when f(n) is the next frame to be decoded: since frame f(n) was received in packet P(n+2), which also carried frame f(n+3), both these frames are stored in the buffer. Furthermore, frame f(n+1) received in the previous packet, P(n+1), is also in the deinterleaving buffer. Note also that in this example the buffer occupancy varies: when frame f(n+1) is the next one to be decoded, there are only two frames, f(n+1) and f(n+3), in the buffer.
図2 F（N + 4）の連続したフレーム、表記F（N-2）において、P（N + 4）、2つのフレームを搬送する各パケットにパケットP（N）に集約されています。このアプローチは、インタリーブとデインタリーブ処理の両方において一定の遅延を可能にするインターリーブパターンを提供します。デインターリーブバッファを消費する準備ができているものを含む、少なくとも3つのフレーム、のための部屋を持っている必要があります。 3つのフレームのための記憶空間をf（n）は復号化されるべき次のフレームである場合、例えば、必要とされる：フレームf（n）は、パケットP（N + 2）で受信されたため、また、フレームF（N +を行っています3）これらの両方のフレームバッファに格納されています。また、フレームF（N + 1）は前のパケット、P（N + 1）で受信し、デインターリーブバッファでもあります。また、この例では、バッファ占有率が変化注：フレームfが（N + 1）復号化されるべき次のものである場合、2つだけのフレームF（N + 1）が存在し、F（N + 3）、緩衝液中。
Since the primary target application for the AMR-WB+ codec is streaming over packet networks, the most relevant usage scenario for this payload format is IP end-to-end between a server and a terminal, as shown in Figure 3.
プライマリターゲットアプリケーションので、AMR-WB +コーデックはパケットネットワーク上でストリーミングされているため、図3に示すように、このペイロード形式のための最も関連性の高い使用シナリオでは、IPエンド・ツー・エンドのサーバと端末との間です。
+----------+ +----------+
| | IP/UDP/RTP/AMR-WB+ | |
| SERVER |<------------------------>| TERMINAL |
| | | |
+----------+ +----------+
Figure 3: Server to terminal IP scenario
図3：端末IPシナリオにサーバー
Some of the options of this payload format remain constant throughout a session. Therefore, they can be controlled/negotiated at the session setup. Throughout this specification, these options and variables are denoted as "parameters to be established through out- of-band means". In Section 7, all the parameters are formally specified in the form of media type registration for the AMR-WB+ encoding. The method used to signal these parameters at session setup or to arrange prior agreement of the participants is beyond the scope of this document; however, Section 7.2 provides a mapping of the parameters into the Session Description Protocol (SDP) [6] for those applications that use SDP.
このペイロード形式のオプションの一部は、セッション全体で一定のままです。そのため、彼らはセッションセットアップで交渉さ/制御することができます。本明細書を通じて、これらのオプションと変数は、「アウトオブバンド手段を介して確立されるパラメータ」と表記されています。セクション7で、すべてのパラメータが正式にAMR-WB +符号化のためのメディアタイプ登録の形式で指定されています。セッションセットアップでこれらのパラメータを通知したり、参加者の事前の同意を配置するために使用される方法は、このドキュメントの範囲を超えています。しかしながら、セクション7.2は、SDPを使用するアプリケーションのために[6]セッション記述プロトコル（SDP）へのパラメータのマッピングを提供します。
The main emphasis in the payload design for AMR-WB+ has been to minimize the overhead in typical use cases, while providing full flexibility with a slightly higher overhead. In order to keep the specification reasonably simple, we refrained from defining frame-specific parameters for each frame type. Instead, a few common parameters were specified that cover all types of frames.
AMR-WB +のペイロード設計の重点は、わずかに高いオーバーヘッドで完全な柔軟性を提供しながら、一般的なユースケースにオーバーヘッドを最小化することでした。合理的に単純な仕様を維持するために、我々は、各フレームタイプのフレーム固有のパラメータを定義する控え。代わりに、いくつかの一般的なパラメータは、フレームのすべてのタイプをカバーする指定されました。
The payload format has two modes: basic mode and interleaved mode. The main structural difference between the two modes is the extension of the table of content entries with frame displacement fields when operating in the interleaved mode. The basic mode supports aggregation of multiple consecutive frames in a payload. The interleaved mode supports aggregation of multiple frames that are non-consecutive in time. In both modes it is possible to have frames encoded with different frame types in the same payload. The ISF must remain constant throughout the payload of a single packet.
基本モードと、インターリーブモード：ペイロードフォーマットは、2つのモードがあります。インターリーブモードで動作しているときに、2つのモード間の主な構造上の違いは、フレーム変位フィールドを持つコンテンツエントリのテーブルの拡張です。基本モードは、ペイロード内の複数の連続するフレームの集約をサポートしています。インターリーブされたモードは、時間的に非連続である複数のフレームの集約をサポートしています。両方のモードにおいて、同じペイロード内の異なるフレームタイプで符号化されたフレームを有することが可能です。 ISFは、単一のパケットのペイロード全体で一定でなければなりません。
The payload format is designed around the property of AMR-WB+ frames that the frames are consecutive in time and share the same frame duration (in the absence of an ISF change). This enables the receiver to derive the timestamp for an individual frame within a payload. In basic mode, the deriving process is based on the order of frames. In interleaved mode, it is based on the compact displacement fields. The frame timestamps are used to regenerate the correct order of frames after reception, identify duplicates, and detect lost frames that require concealment.
ペイロードフォーマットは、AMR-WB +の性質に基づいて設計されているフレームが時間的に連続していると（ISF変化の非存在下で）同じフレーム持続時間を共有することフレーム。これは、ペイロード内の個々のフレームのためのタイムスタンプを導出するために受信機を可能にします。基本モードでは、導出過程は、フレームの順序に基づいています。インターリーブモードでは、コンパクトな変位場に基づいています。フレームのタイムスタンプは、受信後フレームの正しい順序を再重複を識別し、隠蔽を必要失われたフレームを検出するために使用されます。
The interleaving scheme of this payload format is significantly more flexible than the one specified in RFC 3267. The AMR and AMR-WB payload format is only capable of using periodic patterns with frames taken from an interleaving group at fixed intervals. The interleaving scheme of this specification, in contrast, allows for any interleaving pattern, as long as the distance in decoding order between any two adjacent frames is not more than 256 frames. Note that even at the highest ISF this allows an interleaving depth of up to 3.41 seconds.
このペイロード形式のインターリービング方式は、一定の間隔でインターリーブ群から採取したフレームで周期的パターンを使用することができるだけであるRFC 3267. AMRとAMR-WBペイロード形式で指定されたものよりも有意により柔軟です。本明細書のインターリービング方式は、対照的に、任意の2つの隣接フレーム間復号化順に距離が256の以上のフレームでない限り、任意のインターリーブパターンを可能にします。でも最高のISFで、これは最大で3.41秒のインターリーブ深さを可能にすることに注意してください。
To allow for error resiliency through redundant transmission, the periods covered by multiple packets MAY overlap in time. A receiver MUST be prepared to receive any audio frame multiple times. All redundantly sent frames MUST use the same frame type and ISF, and MUST have the same RTP timestamp, or MUST be a NO_DATA frame (FT=15).
冗長伝送を介してエラー回復を可能にするために、複数のパケットにより覆わ期間が時間的に重なってもよいです。受信機は、任意のオーディオフレームを複数回受信するように準備しなければなりません。全ての冗長フレームが同じフレームタイプとISFを使用しなければなりません、と同じRTPタイムスタンプを持たなければならない、又はNO_DATAフレーム（FT = 15）でなければならない送信しました。
The payload consists of octet-aligned elements (header, ToC, and audio frames). Only the audio frames for AMR-WB frame types (0-9) require padding for octet alignment. If additional padding is desired, then the P bit in the RTP header MAY be set, and padding MAY be appended as specified in [3].
ペイロードはオクテット整列要素（ヘッダ、目次、およびオーディオフレーム）から成ります。 AMR-WBフレームタイプ（0-9）のためにのみ音声フレームをオクテット整列のためのパディングが必要です。追加のパディングが所望される場合には、RTPヘッダ内のPビットがセットされてもよく、及び[3]で指定されるようにパディングを付加することができます。
The format of the RTP header is specified in [3]. This payload format uses the fields of the header in a manner consistent with that specification.
RTPヘッダのフォーマットは、[3]で指定されています。このペイロードフォーマットは、その仕様と一致する方法で、ヘッダのフィールドを使用します。
The RTP timestamp corresponds to the sampling instant of the first sample encoded for the first frame in the packet. The timestamp clock frequency SHALL be 72000 Hz. This frequency allows the frame duration to be integer RTP timestamp ticks for the ISFs specified in Table 1. It also provides reasonable conversion factors to the input/output audio sampling frequencies supported by the codec. See Section 4.3.2.3 for guidance on how to derive the RTP timestamp for any audio frame beyond the first one.
RTPタイムスタンプは、パケットの最初のフレームのための符号化された第1のサンプルのサンプリング時点に対応します。タイムスタンプクロック周波数は72000ヘルツでなければなりません。この周波数は、フレーム持続時間が整数RTPタイムスタンプを表1に指定されたISF申告のためティックするまた、コーデックによってサポートされる入力/出力オーディオサンプリング周波数に合理的な変換係数を提供することができます。最初の1を超えたすべてのオーディオフレーム用のRTPタイムスタンプを導出する方法に関するガイダンスについては、セクション4.3.2.3を参照してください。
The RTP header marker bit (M) SHALL be set to 1 whenever the first frame carried in the packet is the first frame in a talkspurt (see the definition of talkspurt in Section 4.1 of [9]). For all other packets, the marker bit SHALL be set to zero (M=0).
パケットで運ばれた最初のフレームが有音部の最初のフレームであるときはいつでも、RTPヘッダのマーカービット（M）は（[9]のセクション4.1におけるトークスパートの定義を参照）を1に設定しなければなりません。他のすべてのパケットのために、マーカービットがゼロ（M = 0）に設定されなければなりません。
The assignment of an RTP payload type for the format defined in this memo is outside the scope of this document. The RTP profile in use either assigns a static payload type or mandates binding the payload type dynamically.
このメモで定義されたフォーマットのためのRTPペイロードタイプの割り当ては、この文書の範囲外です。使用中のRTPプロファイルは動的ペイロードタイプを結合静的ペイロードタイプまたは義務を割り当てるのいずれか。
The media type parameter "channels" is used to indicate the maximum number of channels allowed for a given payload type. A payload type where channels=1 (mono) SHALL only carry mono content. A payload type for which channels=2 has been declared MAY carry both mono and stereo content. Note that this definition is different from the one in RFC 3551 [9]. As mentioned before, the AMR-WB+ codec handles the support of stereo content and the (eventual) downmixing of stereo to mono internally. This makes it unnecessary to negotiate for the number of channels for reasons other than bit-rate efficiency.
メディアタイプパラメータ「チャネル」は、所与のペイロードタイプに許可チャネルの最大数を示すために使用されます。 = 1（モノラル）チャンネルのみモノラルコンテンツを運ぶものとペイロードタイプ。チャンネル= 2が宣言されたペイロードタイプは、モノラルとステレオのコンテンツの両方を搬送することができます。この定義は、RFC 3551におけるものとは異なることに注意してください[9]。前に述べたように、AMR-WB +コーデックは、ステレオコンテンツと内部モノステレオの（最終的な）ダウンミックスのサポートを処理します。これは、ビットレート効率以外の理由のためにチャネルの数について交渉する必要がなくなります。
The payload consists of a payload header, a table of contents, and the audio data representing one or more audio frames. The following diagram shows the general payload format layout:
ペイロードは、ペイロードヘッダ、コンテンツの表、および1つまたは複数のオーディオフレームを表すオーディオデータから成ります。以下の図は一般的なペイロードフォーマットのレイアウトを示しています。
+----------------+-------------------+----------------
| payload header | table of contents | audio data ...
+----------------+-------------------+----------------
Payloads containing more than one audio frame are called compound payloads.
複数のオーディオフレームを含むペイロードは、化合物のペイロードと呼ばれています。
The following sections describe the variations taken by the payload format depending on the mode in use: basic mode or interleaved mode.
基本モード又はインターリーブモード：以下のセクションでは、使用中のモードに応じてペイロード形式で撮影したバリエーションを記載しています。
The payload header carries data that is common for all frames in the payload. The structure of the payload header is described below.
ペイロードヘッダは、ペイロード内のすべてのフレームのための共通のデータを搬送します。ペイロードヘッダの構成について説明します。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| ISF |TFI|L|
+-+-+-+-+-+-+-+-+
ISF (5 bits): Indicates the Internal Sampling Frequency employed for all frames in this payload. The index value corresponds to internal sampling frequency as specified in Table 24 in [1]. This field SHALL be set to 0 for payloads containing frames with Frame Type values 0-13.
ISF（5ビット）：このペイロード内のすべてのフレームのために使用内部サンプリング周波数を示します。 [1]の表24で指定されたインデックス値は、内部サンプリング周波数に対応します。このフィールドは、フレームタイプの値を0から13のフレームを含むペイロードの場合は0に設定されなければなりません。
TFI (2 bits): Transport Frame Index, from 0 (first) to 3 (last), indicating the position of the first transport frame of this payload in the AMR-WB+ super-frame structure. For payloads with frames of only Frame Type values 0-9, this field SHALL be set to 0 by the sender. The TFI value for a frame of type 0-9 SHALL be ignored by the receiver. Note that the frame type is coded in the table of contents (as discussed later); hence, the mentioned dependencies of the frame type can be applied easily by interpreting only values carried in the payload header. It is not necessary to interpret the audio bit stream itself.
TFI（2ビット）：伝送フレームインデックス、0から（最初の）3（最後）に、AMR-WB +スーパーフレーム構造内でこのペイロードの最初の伝送フレームの位置を示します。唯一のフレームタイプ値0-9のフレームとペイロードの場合、このフィールドは、送信者によって0に設定されなければなりません。タイプ0-9のフレームのTFI値は、受信機によって無視されます。 （後述するように）フレームタイプがコンテンツのテーブルで符号化されることに注意してください。したがって、フレームタイプの言及依存性は、ペイロードヘッダで運ばれた値のみを解釈することにより容易に適用することができます。オーディオビットストリーム自体を解釈する必要はありません。
L (1 bit): Long displacement field flag for payloads in interleaved mode. If set to 0, four-bit displacement fields are used to indicate interleaving offset; if set to 1, displacement fields of eight bits are used (see Section 4.3.2.2). For payloads in the basic mode, this bit SHALL be set to 0 and SHALL be ignored by the receiver.
L（1ビット）：インターリーブモードのペイロードのための長い変位フィールドフラグ。 0に設定した場合、4ビットの変位フィールドは、オフセットインターリーブを示すために使用されます。 1に設定されている場合、8ビットの変位フィールドは（セクション4.3.2.2を参照）が使用されます。基本モードでペイロードのために、このビットは0に設定されると、受信機によって無視されます。
Note that frames employing different ISF values require encapsulation in separate packets. Thus, special considerations apply when generating interleaved packets and an ISF change is executed. In particular, frames that, according to the previously used interleaving pattern, would be aggregated into a single packet have to be separated into different packets, so that the aforementioned condition (all frames in a packet share the ISF) remains true. A naive implementation that splits the frames with different ISF into different packets can result in up to twice the number of RTP packets, when compared to an optimal interleaved solution. Alteration of the interleaving before and after the ISF change may reduce the need for extra RTP packets.
異なるISF値を用いるフレームは別々のパケットにカプセル化を必要とすることに留意されたいです。このように、特別な考慮事項は、インターリーブパケットを生成する際に適用し、ISF変更が実行されます。上記の条件（パケットシェアのすべてのフレームISF）が真のままであるように、特に、以前に使用インタリーブパターンに応じて、単一のパケットに集約されるであろう、ということフレームは、異なるパケットに分割しなければなりません。異なるパケットに異なるISFのフレームを分割する単純な実装は、最適なインターリーブされた溶液と比較したRTPパケットの数倍にまでもたらすことができます。前とISFの変更後のインターリーブの変更は、余分なRTPパケットの必要性を減らすことができます。
The table of contents (ToC) consists of a list of entries, each entry corresponds to a group of audio frames carried in the payload, as depicted below.
目次（TOC）は、以下に示すように、各エントリは、ペイロードで運ばれたオーディオフレームのグループに対応し、エントリのリストから成ります。
+----------------+----------------+- ... -+----------------+
| ToC entry #1 | ToC entry #2 | ToC entry #N |
+----------------+----------------+- ... -+----------------+
When multiple groups of frames are present in a payload, the ToC entries SHALL be placed in the packet in order of increasing RTP timestamp value (modulo 2^32) of the first transport frame the TOC entry represents.
フレームの複数のグループがペイロード内に存在する場合、目次エントリは、TOCエントリが表す第一伝送フレームのRTPタイムスタンプ値（モジュロ2 ^ 32）を増加させるために、パケットに置きます。
A ToC entry of a payload in the basic mode has the following format:
基本モードでのペイロードの目次エントリの形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Frame Type | #frames |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F (1 bit): If set to 1, indicates that this ToC entry is followed by another ToC entry; if set to 0, indicates that this ToC entry is the last one in the ToC.
F（1ビット）：1に設定した場合、この目次項目が別のToCエントリが続いていることを示しています。 0に設定すると、この目次エントリは目次の最後の1であることを示しています。
Frame Type (FT) (7 bits): Indicates the audio codec frame type used for the group of frames referenced by this ToC entry. FT designates the combination of AMR-WB+ core and stereo rate, one of the special AMR-WB+ frame types, the AMR-WB rate, or comfort noise, as specified by Table 25 in [1].
フレームタイプ（FT）（7ビット）：この目次のエントリによって参照されるフレームのグループに使用される音声コーデックフレームタイプを示します。 FTは、表25で指定されるように、AMR-WB +のコアとステレオレート、特殊AMR-WB +のフレームタイプのいずれか、AMR-WBレート、又は快適ノイズの組み合わせを指定する[1]。
#frames (8 bits): Indicates the number of frames in the group referenced by this ToC entry. ToC entries with this field equal to 0 (which would indicate zero frames) SHALL NOT be used, and received packets with such a TOC entry SHALL be discarded.
#frames（8ビット）：この目次のエントリによって参照されるグループ内のフレームの数を示します。 0に等しいこのフィールドと目次エントリ（ゼロフレームを示すであろう）を使用し、そのようなTOCエントリとパケットを受信することがないものは捨てられるもの。
Two different ToC entry formats are defined in interleaved mode. They differ in the length of the displacement field, 4 bits or 8 bits. The L-bit in the payload header differentiates between the two modes.
二つの異なる目次エントリ形式は、インターリーブモードで定義されています。これらは、変位フィールドの長さが4ビットまたは8ビットを異なります。ペイロードヘッダにLビットは、2つのモードを区別する。
If L=0, a ToC entry has the following format:
L = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Frame Type | #frames | DIS1 | ... | DISi | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | DISn | Padd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F (1 bit): See definition in 4.3.2.1.
F（1ビット）：4.3.2.1で定義を参照してください。
Frame Type (FT) (7 bits): See definition in 4.3.2.1.
フレームタイプ（FT）（7ビット）：4.3.2.1で定義を参照してください。
#frames (8 bits): See definition in 4.3.2.1.
#frames（8ビット）：4.3.2.1に定義を参照してください。
DIS1...DISn (4 bits): A list of n (n=#frames) displacement fields indicating the displacement of the i:th (i=1..n) audio frame relative to the preceding audio frame in the payload, in units of frames. The four-bit unsigned integer displacement values may be between 0 and 15, indicating the number of audio frames in decoding order between the (i-1):th and the i:th frame in the payload. Note that for the first ToC entry of the payload, the value of DIS1 is meaningless. It SHALL be set to zero by a sender and SHALL be ignored by a receiver. This frame's location in the decoding order is uniquely defined by the RTP timestamp and TFI in the payload header. Note also that for subsequent ToC entries, DIS1 indicates the number of frames between the last frame of the previous group and the first frame of this group.
DIS1 ... DISN（4ビット）：Nのリスト（N =＃フレーム）Iの変位を示す変位場は、（i = 1..nの）オーディオフレームに対して第ペイロードに先行するオーディオフレームに、フレーム単位インチ4ビットの符号なし整数変位値は、（i-1）との復号化順序でオーディオフレームの数を示す、0と15の間であってもよい：iおよび目：ペイロードにフレーム目。ペイロードの最初のToCエントリに対して、DIS1の値が無意味であることに留意されたいです。これは、送信者によってゼロに設定されるものとし、受信機によって無視されなければなりません。復号順でこのフレームの位置を一意にペイロードヘッダ内のRTPタイムスタンプとTFIによって定義されます。メモはまた、後続のToCエントリに対して、DIS1は、前のグループの最後のフレームと、このグループの最初のフレームの間のフレームの数を示します。
Padd (4 bits): To ensure octet alignment, four padding bits SHALL be included at the end of the ToC entry in case there is odd number of frames in the group referenced by this entry. These bits SHALL be set to zero and SHALL be ignored by the receiver. If a group containing an even number of frames is referenced by this ToC entry, these padding bits SHALL NOT be included in the payload.
PADD（4ビット）：4つのパディングビットが、このエントリによって参照されるグループ内のフレームの奇数がある場合中のTOCエントリの末尾に含まれるものと、オクテット整列を確実にします。これらのビットはゼロに設定されると、受信機によって無視されます。フレームの偶数を含む基は、この目次エントリによって参照されている場合、これらのパディングビットは、ペイロードに含まれないもの。
If L=1, a ToC entry has the following format:
L = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Frame Type | #frames | DIS1 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | DISn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F (1 bit): See definition in 4.3.2.1.
F（1ビット）：4.3.2.1で定義を参照してください。
Frame Type (FT) (7 bits): See definition in 4.3.2.1.
フレームタイプ（FT）（7ビット）：4.3.2.1で定義を参照してください。
#frames (8 bits): See definition in 4.3.2.1.
#frames（8ビット）：4.3.2.1に定義を参照してください。
DIS1...DISn (8 bits): A list of n (n=#frames) displacement fields indicating the displacement of the i:th (i=1..n) audio frame relative to the preceding audio frame in the payload, in units of frames. The eight-bit unsigned integer displacement values may be between 0 and 255, indicating the number of audio frames in decoding order between the (i-1):th and the i:th frame in the payload. Note that for the first ToC entry of the payload, the value of DIS1 is meaningless. It SHALL be set to zero by a sender and SHALL be ignored by a receiver. This frame's location in the decoding order is uniquely defined by the RTP timestamp and TFI in the payload header. Note also that for subsequent ToC entries, DIS1 indicates the displacement between the last frame of the previous group and the first frame of this group.
DIS1 ... DISN（8ビット）：Nのリスト（N =＃フレーム）Iの変位を示す変位場は、（i = 1..nの）オーディオフレームに対して第ペイロードに先行するオーディオフレームに、フレーム単位インチ8ビット符号なし整数変位値は、（i-1）との復号化順序でオーディオフレームの数を示す、0と255の間であってもよい：iおよび目：ペイロードにフレーム目。ペイロードの最初のToCエントリに対して、DIS1の値が無意味であることに留意されたいです。これは、送信者によってゼロに設定されるものとし、受信機によって無視されなければなりません。復号順でこのフレームの位置を一意にペイロードヘッダ内のRTPタイムスタンプとTFIによって定義されます。後続のToCエントリにもなお、DIS1は、前のグループの最後のフレームと、このグループの最初のフレームとの間の変位を示します。
The RTP Timestamp value for a frame SHALL be the timestamp value of the first audio sample encoded in the frame. The timestamp value for a frame is derived differently depending on the payload mode, basic or interleaved. In both cases, the first frame in a compound packet has an RTP timestamp equal to the one received in the RTP header. In the basic mode, the RTP time for any subsequent frame is derived in two steps. First, the sum of the frame durations (see Table 1) of all the preceding frames in the payload is calculated. Then, this sum is added to the RTP header timestamp value. For example, let's assume that the RTP Header timestamp value is 12345, the payload carries four frames, and the frame duration is 16 ms (ISF = 32 kHz) corresponding to 1152 timestamp ticks. Then the RTP timestamp of the fourth frame in the payload is 12345 + 3 * 1152 = 15801.
フレームのRTPタイムスタンプの値は、フレーム内符号化された第1のオーディオサンプルのタイムスタンプ値でなければなりません。フレームのためのタイムスタンプ値は、ペイロードモード、塩基性またはインターリーブに応じて異なる導出されます。両方の場合において、化合物パケットの最初のフレームは、RTPヘッダで受信されたものと同じRTPタイムスタンプを有しています。基本モードでは、後続のフレームのRTPタイムは、2つのステップで導出されます。まず、ペイロード内のすべての先行するフレームのフレーム持続時間の合計（表1参照）を算出します。次いで、この合計は、RTPヘッダのタイムスタンプ値に加算されます。たとえば、のは、RTPヘッダのタイムスタンプ値が12345であると仮定する、ペイロードは、4つのフレームを搬送し、フレーム持続時間は16ミリ秒のタイムスタンプがティック1152に対応する（ISF = 32キロヘルツ）です。次いで、ペイロードに第4フレームのRTPタイムスタンプは、12345 + 3 * 1152 = 15801です。
In interleaved mode, the RTP timestamp for each frame in the payload is derived from the RTP header timestamp and the sum of the time offsets of all preceding frames in this payload. The frame timestamps are computed based on displacement fields and the frame duration derived from the ISF value. Note that the displacement in time between frame i-1 and frame i is (DISi + 1) * frame duration because the duration of the (i-1):th must also be taken into account. The timestamp of the first frame of the first group of frames (TS(1)) (i.e., the first frame of the payload) is the RTP header timestamp. For subsequent frames in the group, the timestamp is computed by
インターリーブモードでは、ペイロード内の各フレームのRTPタイムスタンプは、RTPヘッダのタイムスタンプと、このペイロードに先行するすべてのフレームの時間オフセットの和に由来します。フレームのタイムスタンプは、変位フィールドとISF値に由来するフレーム持続時間に基づいて計算されます。目も考慮しなければならない：（I-1）の期間があるため、フレーム間の時間のずれは、I-1とフレームiが（DISI + 1）*フレーム期間であることに留意されたいです。フレームの最初のグループの最初のフレームのタイムスタンプ（TS（1））（即ち、ペイロードの最初のフレーム）がRTPヘッダのタイムスタンプです。グループ内の後続のフレームのために、タイムスタンプは、によって計算されます
TS(i) = TS(i-1) + (DISi + 1) * frame duration, 2 < i < n
TS（I）=のTS（I-1）+（DISI + 1）*フレーム期間、2 <I <Nで
For subsequent groups of frames, the timestamp of the first frame is computed by
フレームの後続のグループについて、最初のフレームのタイムスタンプは、によって計算されます
TS(1) = TSprev + (DIS1 + 1) * frame duration,
TS（1）= TSprev +（DIS1 + 1）*フレーム期間、
where TSprev denotes the timestamp of the last frame in the previous group. The timestamps of the subsequent frames in the group are computed in the same way as for the first group.
TSprevは、前のグループの最後のフレームのタイムスタンプを表します。グループ内の後続のフレームのタイムスタンプは、第一のグループと同じ方法で計算されます。
The following example derives the RTP timestamps for the frames in an interleaved mode payload having the following header and ToC information:
次の例は、以下のヘッダおよびTOC情報を有するインターリーブモードペイロードのフレームのためのRTPのタイムスタンプを導出します。
RTP header timestamp: 12345 ISF = 32 kHz Frame 1 displacement field: DIS1 = 0 Frame 2 displacement field: DIS2 = 6 Frame 3 displacement field: DIS3 = 4 Frame 4 displacement field: DIS4 = 7
RTPヘッダのタイムスタンプ：12345 ISF = 32 kHzのフレーム1つの変位フィールド：DIS1 = 0フレーム2変位フィールド：DIS2 = 6フレーム3変位フィールド：DIS3 = 4フレーム4の変位フィールド：DIS4 = 7
Assuming an ISF of 32 kHz, which implies a frame duration of 16 ms, one frame lasts 1152 ticks. The timestamp of the first frame in the payload is the RTP timestamp, i.e., TS(1) = RTP TS. Note that the displacement field value for this frame must be ignored. For the second frame in the payload, the timestamp can be calculated as TS(2) = TS(1) + (DIS2 + 1) * 1152 = 20409. For the third frame, the timestamp is TS(3) = TS(2) + (DIS3 + 1) * 1152 = 26169. Finally, for the fourth frame of the payload, we have TS(4) = TS(3) + (DIS4 + 1) * 1152 = 35385.
16ミリ秒のフレーム期間を意味32キロヘルツ、のISFを仮定すると、一つのフレーム1152ティック続きます。ペイロードの最初のフレームのタイムスタンプは、TS（1）RTP TSを=すなわち、RTPタイムスタンプです。このフレームの変位フィールドの値は無視されなければならないことに注意してください。ペイロードにおける第二のフレームについて、タイムスタンプは、TSのように計算することができる（2）=のTS（1）+（DIS2 + 1）* 1152 = 20409.第3フレームの場合、タイムスタンプは、（3）=のTS（2 TSであります）+（DIS3 + 1）* 1152 = 26169.最後に、ペイロードの第四のフレームのために、我々はTS（4）=のTS（3）+（DIS4 + 1）* 1152 = 35385。
The value of Frame Type (FT) is defined in Table 25 in [1]. FT=14 (AUDIO_LOST) is used to denote frames that are lost. A NO_DATA (FT=15) frame could result from two situations: First, that no data has been produced by the audio encoder; and second, that no data is transmitted in the current payload. An example for the latter would be that the frame in question has been or will be sent in an earlier or later packet. The duration for these non-included frames is dependent on the internal sampling frequency indicated by the ISF field.
フレームタイプ（FT）の値は表25に定義されている[1]。 FT = 14（AUDIO_LOST）が失われたフレームを示すために使用されます。 NO_DATA（FT = 15）フレームは、2つの状況から生じ得る：まず、データがオーディオエンコーダによって生成されていないこと。第二、データが現在のペイロードで送信されていないこと。後者の例は当該フレームがされたか、前または後のパケットで送信されることであろう。これらの非含まれるフレームの継続時間は、ISFフィールドによって示さ内部サンプリング周波数に依存しています。
For frame types with index 0-13, the ISF field SHALL be set 0. The frame duration for these frame types is fixed to 20 ms in time, i.e., 1440 ticks in 72 kHz. For payloads containing only frames of type 0-9, the TFI field SHALL be set to 0 and SHALL be ignored by the receiver. In a payload combining frames of type 0-9 and 10-13, the TFI values need to be set to match the transport frames of type 10-13. Thus, frames of type 0-9 will also have a derived TFI, which is ignored.
これらのフレームタイプのフレーム期間が時間で20ミリ秒、72キロヘルツで、すなわち1440ティックに固定されている0インデックス0-13のフレームタイプの場合、ISFフィールドが設定されなければなりません。タイプ0-9のフレームのみを含むペイロードため、TFIフィールドが0に設定されると、受信機によって無視されます。ペイロードタイプ0-9及び10-13のフレームを組み合わせることで、TFI値は、タイプ10-13の移送フレームと一致するように設定する必要があります。したがって、タイプ0-9のフレームも無視される派生TFIを有するであろう。
If a ToC entry with an undefined FT value is received, the whole packet SHALL be discarded. This is to avoid the loss of data synchronization in the depacketization process, which can result in a severe degradation in audio quality.
未定義のFT値とのToCエントリを受信した場合、パケット全体が廃棄され。これは、オーディオ品質の深刻な低下につながることができます逆パケット化プロセスでのデータ同期の損失を回避することです。
Packets containing only NO_DATA frames SHOULD NOT be transmitted. Also, NO_DATA frames at the end of a frame sequence to be carried in a payload SHOULD NOT be included in the transmitted packet. The AMR-WB+ SCR/DTX is identical with AMR-WB SCR/DTX described in [5] and can only be used in combination with the AMR-WB frame types (0-8).
唯一のNO_DATAフレームを含むパケットが送信されるべきではありません。また、ペイロードで運ばれるべきフレームシーケンスの終わりにNO_DATAフレームは送信されたパケットに含めるべきではありません。 AMR-WB + SCR / DTX [5]でAMR-WB SCR / DTXと同一記載されているのみAMR-WBフレームタイプ（0-8）と組み合わせて使用することができます。
When multiple groups of frames are present, their ToC entries SHALL be placed in the ToC in order of increasing RTP timestamp value (modulo 2^32) of the first transport frame the TOC entry represents, independent of the payload mode. In basic mode, the frames SHALL be consecutive in time, while in interleaved mode the frames MAY not only be non-consecutive in time but MAY even have varying inter-frame distances.
フレームの複数のグループが存在する場合、それらのToCエントリは、RTPタイムスタンプ値（モジュロ2 ^ 32）を増加させるために、目次に配置されるものと第一伝送フレームのTOCエントリはペイロードモードとは無関係に、表します。インターリーブされたモードでフレームが唯一の時間における非連続的ではないかもしれないが、でも、様々なフレーム間の距離を持っているかもしれないが、基本的なモードでは、フレームは、時間的に連続するものとします。
The following example illustrates a ToC for three audio frames in basic mode. Note that in this case all audio frames are encoded using the same frame type, i.e., there is only one ToC entry.
次の例では、基本モードの3つのオーディオフレームの目次を示しています。この場合、全てのオーディオフレーム、すなわち、一つだけのToCエントリが、同じフレームタイプを用いて符号化されることに留意されたいです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Frame Type1 | #frames = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The next example depicts a ToC of three entries in basic mode. Note that in this case the payload also carries three frames, but three ToC entries are needed because the frames of the payload are encoded using different frame types.
次の例では、基本モードの3つのエントリの目次を示しています。ペイロードのフレームは、異なるフレームタイプを用いて符号化されるので、この場合には、ペイロードはまた、3つのフレームを搬送するが、3つのToCエントリが必要であることに留意されたいです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Frame Type1 | #frames = 1 |1| Frame Type2 | #frames = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Frame Type3 | #frames = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following example illustrates a ToC with two entries in interleaved mode using four-bit displacement fields. The payload includes two groups of frames, the first one including a single frame, and the other one consisting of two frames.
次の例では、4ビットの変位場を使用して、インターリーブモードで2つのエントリを持つ目次を示します。ペイロードは、フレームの二つのグループは、単一のフレームを含む最初のものと、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Frame Type1 | #frames = 1 | DIS1 | padd |0| Frame Type2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #frames = 2 | DIS1 | DIS2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Audio data of a payload consists of zero or more audio frames, as described in the ToC of the payload.
ペイロードの目次に記載されているように、ペイロードの音声データは、ゼロ以上のオーディオフレームからなります。
ToC entries with FT=14 or 15 represent frame types with a length of 0. Hence, no data SHALL be placed in the audio data section to represent frames of this type.
FT = 14又は15とのToCエントリは、したがって、データは、このタイプのフレームを表すために、オーディオデータ部に配置されてはならない0の長さのフレームタイプを表します。
As already discussed, each audio frame of an extension frame type represents an AMR-WB+ transport frame corresponding to the encoding of 512 samples of audio, sampled with the internal sampling frequency specified by the ISF indicator. As an exception, frame types with index 10-13 are only capable of using a single internal sampling frequency (25600 Hz). The encoding rates (combination of core bit-rate and stereo bit-rate) are indicated in the frame type field of the corresponding ToC entry. The octet length of the audio frame is implicitly defined by the frame type field and is given in Tables 21 and 25 of [1]. The order and numbering notation of the bits are as specified in [1]. For the AMR-WB+ extension frame types and comfort noise frames, the bits are in the order produced by the encoder. The last octet of each audio frame MUST be padded with zeroes at the end if not all bits in the octet are used. In other words, each audio frame MUST be octet-aligned.
既に論じたように、拡張フレームタイプの各オーディオフレームは、ISFインジケータによって指定された内部サンプリング周波数でサンプリングされたオーディオの512個のサンプルの符号化に対応するAMR-WB +の伝送フレームを表します。例外として、インデックス10-13のフレームタイプは、単一の内部サンプリング周波数（25600 Hz）を使用することが可能です。符号化率（コアビットレートステレオビットレートの組合せ）は、対応のToCエントリのフレームタイプフィールドに示されています。オーディオフレームのオクテットの長さは、暗黙的に、フレームタイプフィールドによって定義され、表21及び25に示されている[1]。ビットの順序と番号付け表記法[1]で指定された通りです。 AMR-WB +拡張フレームタイプと快適雑音フレームについて、ビットがエンコーダによって生成順序です。各オーディオフレームの最後のオクテットが終わりにゼロで埋めなければならない場合ではないオクテットのすべてのビットが使用されます。換言すれば、各オーディオフレームはオクテット整列されなければなりません。
The payload begins with the payload header, followed by the table of contents, which consists of a list of ToC entries.
ペイロードは、目次のエントリのリストで構成されたコンテンツのテーブル、続いてペイロードヘッダで始まります。
The audio data follows the table of contents. All the octets comprising an audio frame SHALL be appended to the payload as a unit. The audio frames are packetized in timestamp order within each group of frames (per ToC entry). The groups of frames are packetized in the same order as their corresponding ToC entries. Note that there are no data octets in a group having a ToC entry with FT=14 or FT=15.
オーディオデータは、コンテンツのテーブルに従います。オーディオフレームを含むすべてのオクテットはユニットとしてペイロードに付加するものとします。オーディオフレームは、（TOCエントリごとに）フレームの各グループ内のタイムスタンプ順にパケット化されます。フレームのグループは、それらの対応する目次エントリと同じ順序でパケット化されます。 FT = 14又はFT = 15とのToCエントリを有する基にデータオクテットが存在しないことに留意されたいです。
4.3.5.1. Example 1: Basic Mode Payload Carrying Multiple Frames Encoded Using the Same Frame Type
4.3.5.1。例1：複数のフレームを運ぶ基本モードのペイロードは、同じフレームタイプを使用してエンコード
Figure 4 depicts a payload that carries three AMR-WB+ frames encoded using 14 kbit/s frame type (FT=26) with a frame length of 280 bits (35 bytes). The internal sampling frequency in this example is 25.6 kHz (ISF = 8). The TFI for the first frame is 2, indicating that the first transport frame in this payload is the third in a super-frame. Since this payload is in the basic mode, the subsequent frames of the payload are consecutive frames in decoding order, i.e., the fourth transport frame of the current super-frame and the first transport frame of the next super-frame. Note that because the frames are all encoded using the same frame type, only one ToC entry is required.
図4は、280ビット（35バイト）のフレーム長の14キロビット/秒のフレームタイプ（FT = 26）を用いて符号化された3 AMR-WB +フレームを運ぶペイロードを示しています。この例では、内部サンプリング周波数が25.6キロヘルツ（ISF = 8）です。最初のフレームのためのTFIは、このペイロードの最初のトランスポートフレームはスーパーフレームにおける第三であることを示す、2です。このペイロードは、基本モードであるので、ペイロードの後続のフレームは、復号化順序、すなわち、現在のスーパーフレームの第4搬送フレーム及び次のスーパーフレームの最初のトランスポートフレームに連続するフレームです。フレームは、すべて同じフレームタイプを用いて符号化されるので、一つだけのToCエントリが必要であることに留意されたいです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ISF = 8 | 2 |0|0| FT = 26 | #frames = 3 | f1(0...7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | f1(272...279) | f2(0...7) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f2(272...279) | f3(0...7) | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | f3(272...279) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: An example of a basic mode payload carrying three frames of the same frame type
図4：同じフレームタイプの3つのフレームを運ぶ基本モードのペイロードの例
4.3.5.2. Example 2: Basic Mode Payload Carrying Multiple Frames Encoded Using Different Frame Types
4.3.5.2。例2：複数のフレームを運ぶ基本モードのペイロードが異なるフレームタイプを使用してエンコード
Figure 5 depicts a payload that carries three AMR-WB+ frames; the first frame is encoded using 18.4 kbit/s frame type (FT=33) with a frame length of 368 bits (46 bytes), and the two subsequent frames are encoded using 20 kbit/s frame type (FT=35) having frame length of 400 bits (50 bytes). The internal sampling frequency in this example is 32 kHz (ISF = 10), implying the overall bit-rates of 23 kbit/s for the first frame of the payload, and 25 kbit/s for the subsequent frames. The TFI for the first frame is 3, indicating that the first transport frame in this payload is the fourth in a super-frame. Since this is a payload in the basic mode, the subsequent frames of the payload are consecutive frames in decoding order, i.e., the first and second transport frames of the current super-frame. Note that since the payload carries two different frame types, there are two ToC entries.
図5は、三AMR-WB +フレームを運ぶペイロードを示す図です。最初のフレームは368ビット（46バイト）のフレーム長を有する18.4キロビット/秒のフレームタイプ（FT = 33）を使用して符号化され、2つの後続のフレームは、20キロビット/秒のフレームタイプ（FT = 35）フレームを有するを使用して符号化されます400ビット（50バイト）の長さ。この例では、内部サンプリング周波数は、後続のフレームのための全体的なペイロードの最初のフレームのための23キロビット/秒のビットレート、および25キロビット/秒を意味する、32キロヘルツ（ISF = 10）です。最初のフレームのためのTFIは、このペイロードの最初のトランスポートフレームはスーパーフレームにおける第であることを示す、3です。これは基本モードでペイロードであることから、ペイロードの後続のフレームは、復号化順序、すなわちにおける連続するフレーム、現在のスーパーフレームの第一及び第二の搬送フレームです。ペイロードは、2つの異なるフレームタイプを運ぶため二つのToCエントリがあることに留意されたいです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ISF=10 | 3 |0|1| FT = 33 | #frames = 1 |0| FT = 35 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #frames = 2 | f1(0...7) | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | f1(360...367) | f2(0...7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f2(392...399) | f3(0...7) | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | f3(392...399) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: An example of a basic mode payload carrying three frames employing two different frame types
図5：二つの異なるフレームタイプを使用する3つのフレームを運ぶ基本モードのペイロードの例
The example in Figure 6 depicts a payload in interleaved mode, carrying four frames encoded using 32 kbit/s frame type (FT=47) with frame length of 640 bits (80 bytes). The internal sampling frequency is 38.4 kHz (ISF = 13), implying a bit-rate of 48 kbit/s for all frames in the payload. The TFI for the first frame is 0; hence, it is the first transport frame of a super-frame. The displacement fields for the subsequent frames are DIS2=18, DIS3=15, and DIS4=10, which indicates that the subsequent frames have the TFIs of 3, 3, and 2, respectively. The long displacement field flag L in the payload header is set to 1, which results in the use of eight bits for the displacement fields in the ToC entry. Note that since all frames of this payload are encoded using the same frame type, there is need only for a single ToC entry. Furthermore, the displacement field for the first frame (corresponding to the first ToC entry with DIS1=0) must be ignored, since its timestamp and TFI are defined by the RTP timestamp and the TFI found in the payload header.
図6の例では、640ビット（80バイト）のフレーム長と32キロビット/秒のフレームタイプ（FT = 47）を用いて符号化された4つのフレームを運ぶ、インターリーブモードでペイロードを示しています。内部サンプリング周波数は、ペイロード内のすべてのフレームのための48キロビット/秒のビットレートを暗示、38.4キロヘルツ（ISF = 13）です。最初のフレームのためのTFIは0です。したがって、スーパーフレームの最初の伝送フレームです。後続のフレームに対する変位フィールドはDIS2 = 18、DIS3 = 15、それぞれ、後続のフレーム3のTFIS、3を持っていることを示し、そして2 DIS4 = 10、です。ペイロードヘッダに長い変位フィールドフラグLは、目次項目の変位フィールドの8ビットの使用をもたらす、1に設定されています。このペイロードのすべてのフレームが同じフレームタイプを用いて符号化されるので、単一のToCエントリが必要であることに留意されたいです。そのタイムスタンプとTFIは、RTPタイムスタンプ及びペイロードヘッダに見出さTFIによって定義されているので、（DIS1 = 0を有する第一のToCエントリに対応する）第一のフレームの変位フィールドは、無視されなければなりません。
The RTP timestamp values of the frames in this example are:
この例ではフレームのRTPタイムスタンプの値は次のとおりです。
Frame1: TS1 = RTP Timestamp Frame2: TS2 = TS1 + 19 * 960 Frame3: TS3 = TS2 + 16 * 960 Frame4: TS4 = TS3 + 11 * 960
フレーム1：TS1 = RTPタイムスタンプフレーム2：TS2 = TS1 + 19 * 960フレーム3：TS3 = TS2 + 16 * 960フレーム4：TS4 = TS3 + 11 * 960
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ISF=13 | 0 |1|0| FT = 47 | #frames = 4 | DIS1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DIS2 = 18 | DIS3 = 15 | DIS4 = 10 | f1(0...7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | f1(632...639) | f2(0...7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | f2(632...639) | f3(0...7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | f3(632...639) | f4(0...7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | f4(632...639) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: An example of an interleaved mode payload carrying four frames at the same frame type
図6：同じフレームタイプで4つのフレームを運ぶインターリーブモードペイロードの例
The use of interleaving requires further considerations. As presented in the example in Section 3.6.2, a given interleaving pattern requires a certain amount of the deinterleaving buffer. This buffer space, expressed in a number of transport frame slots, is indicated by the "interleaving" media type parameter. The number of frame slots needed can be converted into actual memory requirements by considering the 80 bytes per frame used by the largest combination of AMR-WB+'s core and stereo rates.
インターリーブの使用は、さらに配慮が必要です。セクション3.6.2の例に示されるように、所定のインターリーブパターンがデインタリーブバッファの一定量を必要とします。輸送フレームのスロットの数で表さこのバッファ空間は、「インターリーブ」メディアタイプパラメータによって示されます。必要なフレームスロットの数は、AMR-WB +のコアとステレオレートの最大組み合わせて使用されるフレーム当たり80のバイトを考慮して実際のメモリ要件に変換することができます。
The information about the frame buffer size is not always sufficient to determine when it is appropriate to start consuming frames from the interleaving buffer. There are two cases in which additional information is needed: first, when switching of the ISF occurs, and second, when the interleaving pattern changes. The "int-delay" media type parameter is defined to convey this information. It allows a sender to indicate the minimal media time that needs to be present in the buffer before the decoder can start consuming frames from the buffer. Because the sender has full control over ISF changes and the interleaving pattern, it can calculate this value.
フレームバッファのサイズに関する情報は、インターリービングバッファからフレームを消費開始することが適切であるかを決定するために必ずしも十分ではありません。 ISFの切り替えは、第二、発生したときに第一、インターリーブパターンが変化：追加の情報が必要とされている2つの場合があります。 「INT-遅延」メディアタイプパラメータは、この情報を伝えるために定義されています。これは、送信者は、デコーダがバッファからのフレームを消費し始めることができる前に、バッファ内に存在する必要最小限のメディア時間を示すことができます。送信者はISF変更とインターリーブパターンを完全に制御を持っているので、この値を計算することができます。
In certain cases (for example, if joining a multicast session with interleaving mid-session), a receiver may initially receive only part of the packets in the interleaving pattern. This initial partial reception (in frame sequence order) of frames can yield too few frames for acceptable quality from the audio decoding. This problem also arises when using encryption for access control, and the receiver does not have the previous key.
ある場合には（例えば、インタリーブ中間セッションとマルチキャスト・セッションに参加する場合）、受信機は、最初にインタリーブパターンでパケットの一部のみを受信してもよいです。フレーム（フレームシーケンス順）この最初の部分の受信は、音声復号から許容可能な品質のためにあまりにも少ないフレームを得ることができます。アクセス制御のための暗号化を使用する場合にこの問題が発生し、受信機は、以前の鍵を持っていません。
Although the AMR-WB+ is robust and thus tolerant to a high random frame erasure rate, it would have difficulties handling consecutive frame losses at startup. Thus, some special implementation considerations are described. In order to handle this type of startup efficiently, it must be noted that decoding is only possible to start at the beginning of a super-frame, and that holds true even if the first transport frame is indicated as lost. Secondly, decoding is only RECOMMENDED to start if at least 2 transport frames are available out of the 4 belonging to that super-frame.
AMR-WB +は、高いランダムフレーム消去レートに堅牢なので、寛容ですが、それは起動時に、連続するフレームロスを扱う難しさを持っているでしょう。このように、いくつかの特別な実装上の考慮事項が記載されています。効率的に、スタートアップのこのタイプを処理するためには、復号化は、スーパーフレームの先頭から開始することのみ可能であり、それが失われたように第1のトランスポートフレームが表示されている場合でも成り立つことに留意しなければなりません。次に、復号化のみ、少なくとも2つのトランスポートフレームはそのスーパーフレームに属する4のうち利用可能である場合に起動することをお勧めします。
After receiving a number of packets, in the worst case as many packets as the interleaving pattern covers, the previously described effects disappear and normal decoding is resumed.
インターリーブパターンを覆うように多くのパケットとして最悪の場合には、パケット数を受信した後、前述の効果が消えて通常の復号が再開されます。
Similar issues arise when a receiver leaves a session or has lost access to the stream. If the receiver leaves the session, this would be a minor issue since playout is normally stopped. It is also a minor issue for the case of lost access, since the AMR-WB+ error concealment will fade out the audio if massive consecutive losses are encountered.
受信機がセッションを残したり、ストリームへのアクセスを失った場合にも、同様の問題が生じます。受信機がセッションを離れる場合は再生が正常に停止されているので、これはマイナーな問題になります。大規模な連続した損失が発生した場合AMR-WB +のエラー隠蔽がオーディオをフェードアウトしますので、それは、また、失われたアクセスの場合のためにマイナーな問題です。
The sender can avoid this type of problem in many sessions by starting and ending interleaving patterns correctly when risks of losses occur. One such example is a key-change done for access control to encrypted streams. If only some keys are provided to clients and there is a risk of their receiving content for which they do not have the key, it is recommended that interleaving patterns not overlap key changes.
送信者は、損失のリスクが発生したときに正しくインターリーブパターンを開始および終了により多くのセッションではこの種の問題を回避することができます。その一例は、暗号化されたストリームへのアクセス制御のために行われ、キーの変更です。唯一のいくつかのキーがクライアントに提供され、彼らは鍵を持っていない彼らの受信内容の危険性がある場合は、インターリーブパターンは、キーの変更と重複しないことをお勧めします。
An application implementing this payload format MUST understand all the payload parameters. Any mapping of the parameters to a signaling protocol MUST support all parameters. So an implementation of this payload format in an application using SDP is required to understand all the payload parameters in their SDP-mapped form. This requirement ensures that an implementation always can decide whether it is capable of communicating.
このペイロード形式を実装したアプリケーションは、すべてのペイロードのパラメータを理解しなければなりません。シグナリングプロトコルのパラメータの任意のマッピングは、すべてのパラメータをサポートしなければなりません。そうSDPを使用してアプリケーションにこのペイロード形式の実装は、それらのSDPマッピングされた形で全てのペイロードのパラメータを理解する必要があります。この要件は、実装は常にそれが通信可能であるかどうかを決定できるようになります。
Both basic and interleaved mode SHALL be implemented. The implementation burden of both is rather small, and requiring both ensures interoperability. As the AMR-WB+ codec contains the full functionality of the AMR-WB codec, it is RECOMMENDED to also implement the payload format in RFC 3267 [7] for the AMR-WB frame types when implementing this specification. Doing so makes interoperability with devices that only support AMR-WB more likely.
どちらも基本的で、インターリーブモードが実装されなければなりません。両方の実装の負担がかなり小さい、との両方を必要とすることは、相互運用性を保証します。 AMR-WB +コーデックは、AMR-WBコーデックの完全な機能が含まれて、この仕様を実装する際にも、AMR-WBフレームタイプの[7] RFC 3267にペイロードフォーマットを実装することが推奨されます。そうすることだけ可能性が高いAMR-WBに対応した機器との相互運用性を作ります。
The switching of ISF, when combined with packet loss, could result in concealment using the wrong audio frame length. This can occur if packet losses result in lost frames directly after the point of ISF change. The packet loss would prevent the receiver from noticing the changed ISF and thereby conceal the lost transport frame with the previous ISF, instead of the new one. Although always later detectable, such an error results in frame boundary misalignment, which can cause audio distortions and problems with synchronization, as too many or too few audio samples were created. This problem can be mitigated in most cases by performing ISF recovery prior to concealment as outlined in Section 4.5.1.
ISFのスイッチングは、パケットロスと組み合わせた場合、間違ったオーディオフレーム長を用いて隠蔽をもたらし得ます。パケットロスが直接ISF変化点の後に失われたフレームになる場合、これが発生する可能性があります。パケットロスが変更されたISFに気付いてから受信を防ぐことにより、代わりに新しいものの前のISFとの失われた伝送フレームを、隠すでしょう。常に後に検出可能なものの、あまりにも多くのまたは少なすぎるオーディオサンプルが作成されたとして、同期とオーディオの歪みや問題を引き起こす可能性がフレーム境界の位置ずれでは、このようなエラーが発生します。この問題は、4.5.1節で概説したような従来の隠蔽にISFリカバリを実行することにより、ほとんどの場合に緩和することができます。
In case of packet loss, it is important that the AMR-WB+ decoder initiates a proper error concealment to replace the frames carried in the lost packet. A loss concealment algorithm requires a codec framing that matches the timestamps of the correctly received frames. Hence, it is necessary to recover the timestamps of the lost frames. Doing so is non-trivial because the codec frame length that is associated with the ISF may have changed during the frame loss.
パケット損失の場合には、AMR-WB +デコーダが失われたパケットで運ばれたフレームを交換するために、適切なエラー隠蔽を開始することが重要です。損失隠蔽アルゴリズムが正しく受信されたフレームのタイムスタンプと一致するコーデックフレーミングが必要です。したがって、失われたフレームのタイムスタンプを回収する必要があります。 ISFに関連付けられているコーデックのフレーム長は、フレームロスの間に変化している可能性があるため、そうすることで非自明です。
In the following, the recovery of the timestamp information of lost frames is illustrated by the means of an example. Two frames with timestamps t0 and t1 have been received properly, the first one being the last packet before the loss, and the latter one being the first packet after the loss period. The ISF values for these packets are isf0 and isf1, respectively. The TFIs of these frames are tfi0 and tfi1, respectively. The associated frame lengths (in timestamp ticks) are given as L0 and L1, respectively. In this example three frames with timestamps x1 - x3 have been lost. The example further assumes that ISF changes once from isf0 to isf1 during the frame loss period, as shown in the figure below.
以下では、失われたフレームのタイムスタンプ情報の回復は、例により示されています。タイムスタンプの時刻t0とt1との二つのフレームは、適切に損失する前に最後のパケットである第一及び損失期間の後の最初のパケットである後者を受信されています。これらのパケットのためのISF値は、それぞれ、isf0とISF1です。これらのフレームのTFISは、それぞれ、tfi0とtfi1です。 （タイムスタンプティックで）関連するフレーム長は、それぞれL0とL1、として与えられます。この例では、タイムスタンプ×1と3つのフレーム - x3が失われています。実施例は、以下の図に示すように一度isf0からISF変更は、フレーム損失期間中ISF1することを前提としています。
Since not all information required for the full recovery of the timestamps is generally known in the receiver, an algorithm is needed to estimate the ISF associated with the lost frames. Also, the number of lost frames needs to be recovered.
タイムスタンプの完全な回復のために必要でないすべての情報は、一般的に受信機に知られているので、このアルゴリズムは、失われたフレームに関連付けられているISFを推定するために必要とされています。また、失われたフレームの数を回復する必要があります。
|<---L0--->|<---L0--->|<-L1->|<-L1->|<-L1->|
| Rxd | lost | lost | lost | Rxd |
--+----------+----------+------+------+------+--
t0 x1 x2 x3 t1
T0×1×2×3のT1
Example Algorithm:
アルゴリズムの例：
Start: # check for frame loss If (t0 + L0) == t1 Then goto End # no frame loss
（T0 + L0）場合、T1 ==フレーム損失のための＃チェックを次に後藤エンド＃なしフレームロス：開始
Step 1: # check case with no ISF change If (isf0 != isf1) Then goto Step 2 # At least one ISF change If (isFractional(t1 - t0)/L0) Then goto Step 3 # More than 1 ISF change
ステップ1：なしISF変更の場合と＃チェックケース次に後藤ステップ2＃少なくとも1 ISF変更する場合（isFractional（T1 - T0）/ L0）次に後藤ステップ3＃を超える1 ISF変化（isf0 = ISF1！）
Return recovered timestamps as x(n) = t0 + n*L1 and associated ISF equal to isf0, for 0 < n < (t1 - t0)/L0 goto End
リターンは0 <N <（T1 - T0）のために、X（N）= T 0 + N * L1とisf0に等しい関連ISFとしてタイムスタンプを回収/ L0のジャンプ終了
Step 2: Loop initialization: n := 4 - tfi0 mod 4 While n <= (t1-t0)/L0 Evaluate m := (t1 - t0 - n*L0)/L1 If (isInteger(m) AND ((tfi0+n+m) mod 4 == tfi1)) Then goto found; n := n+4 endloop goto step 3 # More than 1 ISF change
ステップ2：ループ初期化：N = 4 - tfi0 MOD 4ながらN <=（T1-T0）/ L0は、m個の評価：=（T1 - T0 - N * L0）/ L1 IF（isInteger（m）および（（tfi0 + N + M）MOD 4 == tfi1））次に、後藤が見つかりました。 N = N + 4 ENDLOOPのGotoステップ3＃1以上ISF変更
found: Return recovered timestamps and ISFs as x(i) = t0 + i*L0 and associated ISF equal to isf0, for 0 < i <= n x(i) = t0 + n*L0 + (i-n)*L1 and associated ISF equal to isf1, for n < i <= n+m goto End
実測値：戻り値X（i）とタイムスタンプとISF申告を回収= T0 + iが0 <iが<= NX（I）= T 0 + N * L0 +（中）* L1と関連ISFため、L0およびisf0に等しい関連ISFを* ISF1に等しいが、nに対して<iが<= N + m個のジャンプ終了
Step 3: More than 1 ISF change has occurred. Since ISF changes can be assumed to be infrequent, such a situation occurs only if long sequences of frames are lost. In that case it is probably not useful to try to recover the timestamps of the lost frames. Rather, the AMR-WB+ decoder should be reset, and decoding should be resumed starting with the frame with timestamp t1.
ステップ3：1つの以上ISFの変化が生じました。 ISFの変更はまれであると想定することができるので、このような状況は、フレームの長いシーケンスが失われた場合にのみ発生します。その場合、失われたフレームのタイムスタンプを回復しようとし、おそらく有用ではありません。むしろ、AMR-WB +復号器はリセットされなければならない、デコードタイムスタンプT1を有するフレームで開始を再開しなければなりません。
End:
終わり：
The above algorithm still does not solve the issue when the receiver buffer depth is shallower than the loss burst. In this kind of case, where the concealment must be done without any knowledge about future frames, the concealment may result in loss of frame boundary alignment. If that occurs, it may be necessary to reset and restart the codec to perform resynchronization.
受信バッファの深さは、損失バーストよりも浅い場合に上記のアルゴリズムは、まだ問題は解決しません。隠蔽は、将来のフレームについての知識なしに行われなければならない場合、このように、隠蔽は、フレーム境界整列の損失をもたらし得ます。それが発生した場合は、再同期を実行するためのコーデックをリセットして再起動する必要があります。
If the receiver finds a mismatch between the size of a received payload and the size indicated by the ToC of the payload, the receiver SHOULD discard the packet. This is recommended because decoding a frame parsed from a payload based on erroneous ToC data could severely degrade the audio quality.
受信機は、受信したペイロードのサイズとペイロードの目次で示す大きさとの間に不一致が検出された場合、受信機は、パケットを破棄すべきです。誤ったTOCデータに基づいて、ペイロードから解析されたフレームを復号することは深刻なオーディオ品質を低下させる可能性があるため、これは推奨されています。
The general congestion control considerations for transporting RTP data apply; see RTP [3] and any applicable RTP profile like AVP [9]. However, the multi-rate capability of AMR-WB+ audio coding provides a mechanism that may help to control congestion, since the bandwidth demand can be adjusted (within the limits of the codec) by selecting a different coding frame type or lower internal sampling rate.
RTPデータを転送するための一般的な輻輳制御の考慮事項が適用されます。 RTP [3]及びAVP [9]のような任意の適用可能なRTPプロファイルを参照。帯域幅の需要が異なる符号化フレーム・タイプまたは低い内部サンプリングレートを選択することによって、（コーデックの制限内で）調整することができるので、AMR-WB +オーディオ符号化のマルチレート能力は、輻輳を制御するために役立つことができる機構を提供します。
The number of frames encapsulated in each RTP payload highly influences the overall bandwidth of the RTP stream due to header overhead constraints. Packetizing more frames in each RTP payload can reduce the number of packets sent and hence the header overhead, at the expense of increased delay and reduced error robustness.
各RTPペイロードにカプセル化されたフレームの数は非常にオーバーヘッド制約ヘッダによるRTPストリームの全体的な帯域幅に影響を与えます。各RTPペイロードに複数のフレームをパケット化して増加した遅延および減少エラー耐性を犠牲にし、ヘッダオーバヘッドしたがって送られたパケットの数を減らすことができます。
If forward error correction (FEC) is used, the amount of FEC-induced redundancy needs to be regulated such that the use of FEC itself does not cause a congestion problem.
前方誤り訂正（FEC）を使用する場合、FECによって誘発される冗長性の量は、FEC自体の使用が輻輳の問題を起こさないように調整する必要があります。
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in RTP [3] and any applicable profile such as AVP [9] or SAVP [10]. As this format transports encoded audio, the main security issues include confidentiality, integrity protection, and data origin authentication of the audio itself. The payload format itself does not have any built-in security mechanisms. Any suitable external mechanisms, such as SRTP [10], MAY be used.
本明細書で定義されたペイロードフォーマットを使用して、RTPパケットは、AVPとしてRTP [3]で説明した一般的なセキュリティ問題と該当のプロファイルの対象となっている[9]又はSAVP [10]。この形式は、符号化された音声を転送するように、主なセキュリティ上の問題は、機密性、完全性保護、およびオーディオ自体のデータ発信元認証を含んでいます。ペイロード形式自体は、任意の組み込みのセキュリティメカニズムを持っていません。そのようなSRTP [10]などの任意の適切な外部機構を使用することができます。
This payload format and the AMR-WB+ decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data.
このペイロード形式とAMR-WB +復号器は、パケット処理のために受信側計算の複雑さの有意な不均一性を示し、したがってによる病理学的データを受信すると、サービス拒否の脅威をもたらす可能性が低いものではありません。
In order to ensure confidentiality of the encoded audio, all audio data bits MUST be encrypted. There is less need to encrypt the payload header or the table of contents since they only carry information about the frame type. This information could also be useful to a third party, for example, for quality monitoring.
符号化されたオーディオの機密性を確保するために、全てのオーディオデータビットが暗号化されなければなりません。彼らは唯一のフレームタイプについての情報を運ぶので、ペイロードヘッダまたはコンテンツのテーブルを暗号化するより少ない必要があります。この情報は、品質監視のために、例えば、第三者にとって有用である可能性があります。
The use of interleaving in conjunction with encryption can have a negative impact on confidentiality, for a short period of time. Consider the following packets (in brackets) containing frame numbers as indicated: {10, 14, 18}, {13, 17, 21}, {16, 20, 24} (a popular continuous diagonal interleaving pattern). The originator wishes to deny some participants the ability to hear material starting at time 16. Simply changing the key on the packet with the timestamp at or after 16, and denying that new key to those participants, does not achieve this; frames 17, 18, and 21 have been supplied in prior packets under the prior key, and error concealment may make the audio intelligible at least as far as frame 18 or 19, and possibly further.
暗号化と併せてインターリーブを使用することは時間の短い期間のための機密性に負の影響を持つことができます。示されるように、フレーム番号を含む（括弧内）は、次のパケットを考える：{10、14、18}、{13、17、21}、{16、20、24}（人気の連続対角線インターリーブパターン）。発信者は、一部の参加者だけで16時以降にタイムスタンプを持つパケットのキーを変更し、それらの参加者に新しい鍵は、これを達成しないことを否定時間16で出発物質を聞く能力を否定することを希望します。フレーム17、18、及び21は、従来のキーの下に先行パケットで供給されており、エラー隠蔽は、少なくとも限り、フレーム18又は19のような音声が明瞭にし、そしておそらくさらによいです。
To authenticate the sender of the speech, an external mechanism MUST be used. It is RECOMMENDED that such a mechanism protects both the complete RTP header and the payload (speech and data bits).
音声の送信者を認証するには、外部のメカニズムを使用しなければなりません。このような機構は、完全なRTPヘッダ及びペイロード（音声及びデータビット）の両方を保護することが推奨されます。
Data tampering by a man-in-the-middle attacker could replace audio content and also result in erroneous depacketization/decoding that could lower the audio quality.
man-in-the-middle攻撃者によって改ざんデータは、オーディオコンテンツを交換しても、オーディオ品質を下げることができ、誤った逆パケット化/デコードにつながる可能性があります。
This section defines the parameters that may be used to select features of the AMR-WB+ payload format. The parameters are defined as part of the media type registration for the AMR-WB+ audio codec. A mapping of the parameters into the Session Description Protocol (SDP) [6] is also provided for those applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that do not use MIME or SDP.
このセクションでは、AMR-WB +ペイロードフォーマットの機能を選択するために使用することができるパラメータを定義します。パラメータは、AMR-WB +オーディオコーデックのメディアタイプ登録の一部として定義されます。セッション記述プロトコル（SDP）[6]また、SDPを使用するアプリケーションのために提供されるにパラメータのマッピング。等価パラメータは、MIMEまたはSDPを使用していない制御プロトコルで使用するために他の場所で定義することができます。
The data format and parameters are only specified for real-time transport in RTP.
データ形式とパラメータのみをRTPにおけるリアルタイムの輸送用に指定されています。
The media type for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) codec is allocated from the IETF tree, since AMR-WB+ is expected to be a widely used audio codec in general streaming applications.
AMR-WB +は、一般的なストリーミングアプリケーションで広く使用されているオーディオコーデックであると予想されるので、拡張適応マルチレート広帯域（AMR-WB +）コーデックのメディアタイプは、IETFツリーから割り当てられています。
Note: Parameters not listed below MUST be ignored by the receiver.
注：下記に記載されていないパラメータは、受信機で無視しなければなりません。
Media Type name: audio
メディアタイプ名：オーディオ
Media subtype name: AMR-WB+
メディアサブタイプ名：AMR-WB +
Required parameters:
必須パラメータ：
None
無し
Optional parameters:
オプションのパラメータ：
channels: The maximum number of audio channels used by the audio frames. Permissible values are 1 (mono) or 2 (stereo). If no parameter is present, the maximum number of channels is 2 (stereo). Note: When set to 1, implicitly the stereo frame types cannot be used.
チャンネル：オーディオフレームによって使用される音声チャネルの最大数。許容値は1（モノ）または2（ステレオ）です。ないパラメータが存在しない場合、チャネルの最大数は、2（ステレオ）です。注意：1に設定すると、暗黙的にステレオフレームタイプを使用することはできません。
interleaving: Indicates that interleaved mode SHALL be used for the payload. The parameter specifies the number of transport frame slots required in a deinterleaving buffer (including the frame that is ready to be consumed). Its value is equal to one plus the maximum number of frames that precede any frame in transmission order and follow the frame in RTP timestamp order. The value MUST be greater than zero. If this parameter is not present, interleaved mode SHALL NOT be used.
インターリーブ：インターリーブされたモードは、ペイロードのために使用しなければならないことを示します。パラメータは、（消費される準備ができているフレームを含む）デインタリーブバッファに必要な伝送フレームのスロットの数を指定します。その値は1プラス伝送順序における任意のフレームに先行し、RTPタイムスタンプ順のフレームに追従するフレームの最大数に等しいです。値がゼロよりも大きくなければなりません。このパラメータが存在しない場合は、インターリーブされたモードは使用してはなりません。
int-delay: The minimal media time delay in RTP timestamp ticks that is needed in the deinterleaving buffer, i.e., the difference in RTP timestamp ticks between the earliest and latest audio frame present in the deinterleaving buffer.
INT-遅延：RTPタイムスタンプにおける最小培地遅延時間はそれがデインタリーブバッファに必要とされるダニ、すなわち、RTPタイムスタンプの差がデインタリーブバッファ内の最初と最後の音声フレームの存在との間ティック。
ptime: See Section 6 in RFC 2327 [6].
PTIME：[6] RFC 2327でセクション6を参照してください。
maxptime: See Section 8 in RFC 3267 [7].
maxptime：[7] RFC 3267でセクション8を参照してください。
Restriction on Usage: This type is only defined for transfer via RTP (STD 64).
使用上の制限：このタイプのみRTP（STD 64）を介して転送するために定義されています。
Encoding considerations: An RTP payload according to this format is binary data and thus may need to be appropriately encoded in non-binary environments. However, as long as used within RTP, no encoding is necessary.
符号化の考慮事項：このフォーマットに従ってRTPペイロードはバイナリデータであるため、適宜非バイナリ環境で符号化される必要があるかもしれません。しかし、限り、RTP内で使用されるように、何の符号化は不要です。
Security considerations: See Section 6 of RFC 4352.
セキュリティの考慮事項：RFC 4352のセクション6を参照してください。
Interoperability considerations: To maintain interoperability with AMR-WB-capable end-points, in cases where negotiation is possible and the AMR-WB+ end-point supporting this format also supports RFC 3267 for AMR-WB transport, an AMR-WB+ end-point SHOULD declare itself also as AMR-WB capable (i.e., supporting also "audio/AMR-WB" as specified in RFC 3267).
相互運用性の考慮：ネゴシエーションが可能であり、このフォーマットをサポートAMR-WB +のエンドポイントはまた、AMR-WBの輸送のためのAMR-WB +のエンドポイントをRFC 3267をサポートしている場合には、AMR-WB対応エンドポイントとの相互運用性を維持するためにAMR-WBできる（RFC 3267で指定されるように、すなわち、また支持「オーディオ/ AMR-WB」）としても、それ自体を宣言する必要があります。
As the AMR-WB+ decoder is capable of performing stereo
to mono conversions, all receivers of AMR-WB+ should be
able to receive both stereo and mono, although the
receiver is only capable of playout of mono signals.
Public specification: RFC 4352 3GPP TS 26.290, see reference [1] of RFC 4352
公開された仕様：RFC 4352 3GPP TS 26.290、リファレンスを参照[1] RFC 4352の
Additional information: This MIME type is not applicable for file storage. Instead, file storage of AMR-WB+ encoded audio is specified within the 3GPP-defined ISO-based multimedia file format defined in 3GPP TS 26.244; see reference [14] of RFC 4352. This file format has the MIME types "audio/3GPP" or "video/3GPP" as defined by RFC 3839 [15].
追加情報：このMIMEタイプはファイルストレージには適用されません。代わりに、AMR-WB +符号化オーディオのファイルストレージは、3GPP TS 26.244で定義された3GPPに定義されたISOベースメディアファイルフォーマット内で指定されています。 [15] RFC 3839によって定義されるようにこのファイル形式は、MIMEタイプ "オーディオ/ 3GPP" または "ビデオ/ 3GPP" を有するRFC 4352.の文献[14]を参照。
Person & email address to contact for further information: magnus.westerlund@ericsson.com ari.lakaniemi@nokia.com
人とEメールアドレスは、詳細についての問い合わせ先：magnus.westerlund@ericsson.com ari.lakaniemi@nokia.com
Intended usage: COMMON. It is expected that many IP-based streaming applications will use this type.
意図している用法：COMMON。多くのIPベースのストリーミングアプリケーションは、このタイプを使用することが期待されます。
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
変更コントローラ：IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ。
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [6], which is commonly used to describe RTP sessions. When SDP is used to specify an RTP session using this RTP payload format, the mapping is as follows:
メディアタイプ仕様で搬送される情報は、[6]、一般にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）内のフィールドに特定のマッピングを有します。 SDPは、このRTPペイロードフォーマットを使用してRTPセッションを指定するために使用される場合、以下のように、マッピングは次のとおりです。
- The media type ("audio") is used in SDP "m=" as the media name.
- メディアタイプ（「オーディオ」）は、メディア名としてSDP「m =」に使用されます。
- The media type (payload format name) is used in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" SHALL be 72000 for AMR-WB+, and the encoding parameter number of channels MUST either be explicitly set to 1 or 2, or be omitted, implying the default value of 2.
- メディアタイプ（ペイロードフォーマット名）エンコーディング名としてSDPの「a = rtpmap」で使用されています。 「a = rtpmap」のRTPクロックレートは、AMR-WB +のために72000であるものとし、チャネルの符号化パラメータの数が明示的に1または2に設定しなければなりませんか、省略され、2のデフォルト値を意味します。
- The parameters "ptime" and "maxptime" are placed in the SDP attributes "a=ptime" and "a=maxptime", respectively.
- SDP内に配置されているパラメータ "PTIME" および "maxptime" は、それぞれ、 "A = PTIME" および "A = maxptimeを" 属性。
- Any remaining parameters are placed in the SDP "a=fmtp" attribute by copying them directly from the MIME media type string as a semicolon-separated list of parameter=value pairs.
- 残りのパラメータは、パラメータ=値のペアのセミコロンで区切られたリストのようなMIMEメディアタイプ文字列から直接コピーすることによって、SDPの「=のfmtp」属性を配置しています。
To achieve good interoperability in an Offer-Answer [8] negotiation usage, the following considerations should be taken into account:
オファー回答[8]交渉の使用で良い相互運用性を実現するために、以下の考慮事項を考慮に入れるべきです。
For negotiable offer/answer usage the following interpretation rules SHALL be applied:
交渉オファー/アンサー使用方法については、以下の解釈規則を適用しなければなりません。
- The "interleaving" parameter is symmetric, thus requiring that the answerer must also include it for the answer to an offered payload type that contains the parameter. However, the buffer space value is declarative in usage in unicast. For multicast usage, the same value in the response is required in order to accept the payload type. For streams declared as sendrecv or recvonly: The receiver will accept reception of streams using the interleaved mode of the payload format. The value declares the amount of buffer space the receiver has available for the sender to utilize. For sendonly streams, the parameter indicates the desired configuration and amount of buffer space. An answerer is RECOMMENDED to respond using the offered value, if capable of using it.
- 「インターリーブ」パラメータは、このように回答もパラメータが含ま提供ペイロードタイプへの答えのためにそれを含まなければならないことを要求する、対称的です。しかし、バッファ空間値は、ユニキャストでの使用に宣言です。マルチキャストの使用のために、応答で同じ値がペイロードタイプを受け入れるために必要とされます。ストリーム用のsendrecvとして、またはrecvonlyで宣言された：受信機は、ペイロードフォーマットのインターリーブモードを使用して、ストリームの受信を受け入れます。値は、送信者が利用するための受信機が利用できる持っているバッファ・スペースの量を宣言します。 sendonlyの流れのために、パラメータは、バッファ空間の所望の構成及び量を示します。それを利用できる場合は回答は、提供された値を使用して対応することをお勧めします。
- The "int-delay" parameter is declarative. For streams declared as sendrecv or recvonly, the value indicates the maximum initial delay the receiver will accept in the deinterleaving buffer. For sendonly streams, the value is the amount of media time the sender desires to use. The value SHOULD be copied into any response.
- 「INT-遅延」パラメータは、宣言です。 SENDRECVとして、またはrecvonlyで宣言されたストリームの場合、値は、受信機は、デインタリーブバッファに受け入れる最大初期遅延を示しています。 sendonlyのストリームの場合、値は、送信者が使用したいメディア時間の量です。値は任意の応答にコピーされるべきです。
- The "channels" parameter is declarative. For "sendonly" streams, it indicates the desired channel usage, stereo and mono, or mono only. For "recvonly" and "sendrecv" streams, the parameter indicates what the receiver accepts to use. As any receiver will be capable of receiving stereo frame type and perform local mixing within the AMR-WB+ decoder, there is normally only one reason to restrict to mono only: to avoid spending bit-rate on data that are not utilized if the front-end is only capable of mono.
- 「チャンネル」パラメータは、宣言です。 「sendonlyの」ストリームの場合、それは、所望のチャンネルの使用状況、ステレオ、モノラル、またはモノのみを示しています。 「recvonlyで」および「のsendrecv」ストリームの場合、パラメータは、受信機が使用することを受け入れるかを示します。いずれかの受信機は、ステレオフレームタイプを受信することが可能であるとAMR-WB +復号器内のローカルな混合を実行するように、唯一のモノラルに制限する唯一の理由は、通常存在する：フロント場合に利用されていないデータに支出ビットレートを避けるために端部は、モノだけが可能です。
- The "ptime" parameter works as indicated by the offer/answer model [8]; "maxptime" SHALL be used in the same way.
- オファー/アンサーモデル[8]で示される「PTIME」パラメータが動作します。 「maxptimeは」同じように使用しなければなりません。
- To maintain interoperability with AMR-WB in cases where negotiation is possible, an AMR-WB+ capable end-point that also implements the AMR-WB payload format [7] is RECOMMENDED to declare itself capable of AMR-WB as it is a subset of the AMR-WB+ codec.
- 交渉が可能である場合にはAMR-WBとの相互運用性を維持するために、また、AMR-WBペイロードフォーマットを実装AMR-WB +可能なエンドポイントは、[7]がサブセットであるとしてAMR-WBの可能自体を宣言するために推奨されますAMR-WB +コーデックの。
In declarative usage, like SDP in RTSP [16] or SAP [17], the following interpretation of the parameters SHALL be done:
宣言的な使用法では、RTSPでSDP [16]またはSAP [17]のように、パラメータの以下の解釈は行わなければなりません。
- The "interleaving" parameter, if present, configures the payload format in that mode, and the value indicates the number of frames that the deinterleaving buffer is required to support to be able to handle this session correctly.
- 「インターリーブ」パラメータは、存在する場合、そのモードでのペイロード・フォーマットを設定し、その値は、デインタリーブバッファが正しく、このセッションを扱うことができるようにサポートするのに必要であることフレームの数を示します。
- The "int-delay" parameter indicates the initial buffering delay required to receive this stream correctly.
- 「INT-遅延」パラメータが正しく、このストリームを受信するために必要な初期バッファリング遅延を示します。
- The "channels" parameter indicates if the content being transmitted can contain either both stereo and mono rates, or only mono.
- 送信されるコンテンツは、ステレオ及びモノラルレート、またはだけモノいずれかの両方を含むことができる場合、「チャネル」パラメータが示します。
- All other parameters indicate values that are being used by the sending entity.
- 他のすべてのパラメータは、送信側エンティティによって使用されている値を示しています。
One example of an SDP session description utilizing AMR-WB+ mono and stereo encoding follows.
AMR-WB +のモノおよびステレオ符号化を利用したSDPセッション記述の一例は次の通りです。
m=audio 49120 RTP/AVP 99 a=rtpmap:99 AMR-WB+/72000/2 a=fmtp:99 interleaving=30; int-delay=86400 a=maxptime:100
M =オーディオ49120 RTP / AVP 99 = rtpmap：99 AMR-WB + / 2分の72000 A =のfmtp：99インターリーブ= 30。 INT-遅延= 86400 = maxptime：100
Note that the payload format (encoding) names are commonly shown in uppercase. Media subtypes are commonly shown in lowercase. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in MIME types and in the default mapping to the SDP a=fmtp attribute.
ペイロード形式（符号化）の名前は、一般的に大文字で示されていることに留意されたいです。メディアサブタイプは、一般的に小文字で示されています。これらの名前は、両方の場所で大文字と小文字を区別しません。同様に、パラメータ名は大文字と小文字を区別しないMIMEタイプおよびSDPのA =のfmtp属性にデフォルトマッピングの両方です。
The IANA has registered one new MIME subtype (audio/amr-wb+); see Section 7.
IANAには、1つの新しいMIMEサブタイプ（オーディオ/ AMR-WB +）に登録されています。セクション7を参照してください。
Daniel Enstrom has contributed in writing the codec introduction section. Stefan Bruhn has contributed by writing the ISF recovery algorithm.
ダニエルEnstromは、コーデック導入部を書面で貢献してきました。ステファンBruhnは、ISF回復アルゴリズムを記述することで貢献してきました。
The authors would like to thank Redwan Salami and Stefan Bruhn for their significant contributions made throughout the writing and reviewing of this document. Dave Singer contributed by reviewing and suggesting improved language. Anisse Taleb and Ingemar Johansson contributed by implementing the payload format and thus helped locate some flaws. We would also like to acknowledge Qiaobing Xie, coauthor of RFC 3267, on which this document is based.
著者は、この文書の執筆や見直しを通じて作られた彼らの重要な貢献のためにRedwanサラミとステファンBruhnに感謝したいと思います。デイブ・シンガーは、見直しと改善言語を示唆で貢献しました。 Anisseタレブとインゲマル・ヨハンソンは、ペイロードフォーマットを実装することで貢献し、したがって、いくつかの欠陥を見つけ助けました。また、この文書が基づいているQiaobing謝、RFC 3267の共著者を、承認したいと思います。
[1] 3GPP TS 26.290 "Audio codec processing functions; Extended Adaptive Multi-Rate Wideband (AMR-WB+) codec; Transcoding functions", version 6.3.0 (2005-06), 3rd Generation Partnership Project (3GPP).
[1] 3GPP TS 26.290 "音声コーデック処理機能を、拡張適応マルチレート広帯域（AMR-WB +）コーデック、トランスコーディング機能"、バージョン6.3.0（2005-06）、第3世代パートナーシッププロジェクト（3GPP）。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[3] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[4] 3GPP TS 26.192 "AMR Wideband speech codec; Comfort Noise aspects", version 6.0.0 (2004-12), 3rd Generation Partnership Project (3GPP).
[4] 3GPP TS 26.192 "AMR広帯域音声コーデック;コンフォートノイズ態様"、バージョン6.0.0（2004-12）、第3世代パートナーシッププロジェクト（3GPP）。
[5] 3GPP TS 26.193 "AMR Wideband speech codec; Source Controlled Rate operation", version 6.0.0 (2004-12), 3rd Generation Partnership Project (3GPP).
[5] 3GPP TS 26.193 "AMR広帯域音声コーデックを、ソース制御された速度の操作"、バージョン6.0.0（2004-12）、第3世代パートナーシッププロジェクト（3GPP）。
[6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[6]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[7] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
[7] Sjoberg、J.、ウェスター、M.、Lakaniemi、A.、およびQ.謝、「リアルタイムトランスポートプロトコル（RTP）ペイロードフォーマットと適応マルチレート（AMR）と適応マルチ用ストレージファイル形式を-rate広帯域（AMR-WB）オーディオコーデック」、RFC 3267、2002年6月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[8]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 2002年6月。
[9] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[9] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。
[10] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[10] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[11] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[11]ローゼンバーグ、J.とH. Schulzrinne、 "一般的なフォワードエラー訂正のためのRTPペイロードフォーマット"、RFC 2733、1999年12月。
[12] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[12]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ・ガルシア、A.、およびS.フォッシー-Parisis、「RTPペイロード冗長オーディオ・データ」、RFC 2198、1997年9月のため。
[13] 3GPP TS 26.233 "Packet Switched Streaming service", version 5.7.0 (2005-03), 3rd Generation Partnership Project (3GPP).
[13] 3GPP TS 26.233、バージョン5.7.0（2005-03）、第3世代パートナーシッププロジェクト（3GPP） "パケットがストリーミングサービスの交換"。
[14] 3GPP TS 26.244 "Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP)", version 6.4.0 (2005-09), 3rd Generation Partnership Project (3GPP).
[14] 3GPP TS 26.244 "パケットがストリーミングサービス（PSS）に切り替えたエンドツーエンドの透明; 3GPPファイル形式（3GP）"、バージョン6.4.0（2005-09）、第3世代パートナーシッププロジェクト（3GPP）を。
[15] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files", RFC 3839, July 2004.
、RFC 3839、2004年7月、 "第3世代パートナーシッププロジェクト（3GPP）のマルチメディアファイルのMIMEタイプの登録" [15]カスターニョ、R.とD.歌手、。
[16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[16] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[17] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[17]ハンドレー、M.、パーキンス、C.、およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。
[18] 3GPP TS 26.140 "Multimedia Messaging Service (MMS); Media formats and codes", version 6.2.0 (2005-03), 3rd Generation Partnership Project (3GPP).
[18] 3GPP TS 26.140 "マルチメディアメッセージングサービス（MMS）、メディアフォーマットとコード"、バージョン6.2.0（2005-03）、第3世代パートナーシッププロジェクト（3GPP）。
[19] 3GPP TS 26.140 "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs", version 6.3.0 (2005-12), 3rd Generation Partnership Project (3GPP).
[19] 3GPP TS 26.140 "マルチメディアブロードキャスト/マルチキャストサービス（MBMS）;プロトコルとコーデック"、バージョン6.3.0（2005-12）、第3世代パートナーシッププロジェクト（3GPP）。
Any 3GPP document can be downloaded from the 3GPP webserver, "http://www.3gpp.org/", see specifications.
任意の3GPP文書には、仕様を参照してください、「http://www.3gpp.org/」、3GPPウェブサーバからダウンロードすることができます。
Authors' Addresses
著者のアドレス
Johan Sjoberg Ericsson Research Ericsson AB SE-164 80 Stockholm SWEDEN
ヨハン・シェーベルイエリクソン研究エリクソンAB、SE-164 80ストックホルムスウェーデン
Phone: +46 8 7190000 EMail: Johan.Sjoberg@ericsson.com
電話：+46 8 7190000 Eメール：Johan.Sjoberg@ericsson.com
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm SWEDEN
マグヌスウェスターエリクソン研究エリクソンAB、SE-164 80ストックホルムスウェーデン
Phone: +46 8 7190000 EMail: Magnus.Westerlund@ericsson.com
電話：+46 8 7190000 Eメール：Magnus.Westerlund@ericsson.com
Ari Lakaniemi Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group FINLAND
アリLakaniemiノキア・リサーチセンター私書箱ボックス407フィン-00045ノキアグループFINLAND
Phone: +358-71-8008000 EMail: ari.lakaniemi@nokia.com
電話：+ 358-71-8008000 Eメール：ari.lakaniemi@nokia.com
Stephan Wenger Nokia Corporation P.O. Box 100 FIN-33721 Tampere FINLAND
ステファン・ウェンガーノキア・コーポレーションの私書箱100 FIN-33721タンペレ、フィンランド箱
Phone: +358-50-486-0637 EMail: Stephan.Wenger@nokia.com
電話：+ 358-50-486-0637 Eメール：Stephan.Wenger@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。