[要約] RFC 4352は、AMR-WB+オーディオコーデックのRTPペイロード形式に関する仕様です。このRFCの目的は、高品質な音声通信を実現するために、AMR-WB+コーデックの効果的な利用を可能にすることです。
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
拡張アダプティブマルチレートワイドバンド（AMR-WB）オーディオコーデックのRTPペイロード形式
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).
Copyright（c）The Internet Society（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.
このドキュメントは、拡張された適応型マルチレートワイドバンド（AMR-WB）[1]エンコードされたオーディオ信号をリアルタイムトランスポートプロトコル（RTP）[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.
AMR-WBのステレオエンコード機能により、AMR-WB [7]、廃止された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で指定されています。、 それぞれ。セクション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-第3世代パートナーシッププロジェクトAMR-適応型マルチレート（コーデック）AMR -WB-アダプティブマルチレートワイドバンド（コーデック）AMR -WB-拡張適応型マルチレートワイドバンド（コーデック）CN-コンフォートノイズDTX-不連続伝送FEC-フォワードエラー補正ft-フレームタイプISF-内部サンプリング周波数SCR-ソース制御レート操作SID -Silence Indicator（CNパラメーターのみを含むフレーム）TFI -Transport Frame Index TS -TimestAmp VAD -Voice Activity Detection 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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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 kbit/sのビットレートでステレオ操作が可能になります。
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 kbit/sの範囲の新しいビットレートによって拡張されたAMR-WB専用の9つのフレームタイプが含まれています。AMR-WBフレームタイプは、16000 Hzのサンプリング周波数のみを使用でき、モノフォニックシグナルでのみ動作します。ただし、新しく導入された拡張フレームタイプは、モノとステレオの両方で、多くの内部サンプリング周波数（ISFS）で動作できます。詳細については、[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 kHzでサンプリングされたオーディオを受信します。エンコードプロセスは、ユーザーが選択した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.
コーデックは、[1]の表24で説明されているように、12.8〜38.4 kHzの範囲の13の異なるISFをサポートしています。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 HzのISFのスーパーフレーム期間は80ミリ秒です。これは、今後のエンコーディングビットレートを記述するために使用される「名目」値です。この正規化を想定すると、ISF選択は、1/2から3/2の名目ビットレートのビットレートの変動をもたらします。
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.
拡張モードのエンコーディングは、1つの単調なコアエンコードと1つのステレオエンコードとして実行されます。コアエンコーディングは、モノフォニック信号をより低い周波数帯域とより高い周波数帯域に分割することにより実行されます。下部バンドは、代数コード励起線形予測（acelp）または変換コード化励起（TCX）のいずれかを使用してエンコードされています。この選択は、輸送フレームごとに1回行うことができますが、スーパーフレーム内の法的組み合わせの特定の制限に従う必要があります。より高いバンドは、低レートのパラメトリック帯域幅拡張アプローチを使用してエンコードされます。
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の組み合わせの結果です。拡張機能は8つの異なるコアエンコーディングレートをサポートし、10.4〜24.0 kbit/sのビットレートを生成します。[1]の表22を参照してください。2.0〜8.0 kbit/sのビットレートを生成する16のステレオエンコードレートがあります。[1]の表23を参照してください。フレームタイプは、AMR-WBモード、4つの固定拡張レート（以下を参照）、ステレオ信号のコアレートとステレオレートの24の組み合わせ、および[1]の表25に記載されているモノ信号の8つのコアレートを一意に識別します。これは、AMR-WBが25600 HzのISFを想定して、10.4〜32 Kbit/sのエンコード率をサポートしていることを意味します。
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つのフレームタイプもあります。[1]の表21のフレームタイプ10-13を参照してください。これらの4つの事前定義されたフレームタイプには、エンコーダーに固定入力サンプリング周波数があり、16 kHzまたは24 kHzで設定できます。AMR-WBフレームタイプと同様に、これらのフレームタイプを使用してエンコードされたトランスポートフレームは、オーディオ信号の正確な20ミリ秒を表します。ただし、それらは80ミリ秒のスーパーフレームの一部でもあります。[1]の表21にリストされているように、フレームタイプ0-13（AMR-WBおよび固定拡張レート）は、明示的な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 kbit/sのオーディオストリームは、フレームタイプ41（つまり、25.6 kbit/s）と32kHzのISF（5/4 *（19.2 6.4）= 32 kbit/s）、またはフレームタイプを利用することで生成できます。47および25.6 kHz（1 *（24 8）= 32 kbit/s）のISF。どの組み合わせが知覚されるオーディオの品質に対してより有益であるかは、コンテンツに依存します。上記の例では、最初のケースはより高いオーディオ帯域幅を提供しますが、2番目のケースは、やや狭いオーディオ帯域幅に同じ数のビットを費やしていますが、より高い忠実度を提供します。エンコーダーは、最も有益であると思われる組み合わせを自由に選択できます。
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サンプルに対応するため、その持続時間は13.33〜40ミリ秒の範囲に制限されます。表1を参照してください。この仕様で義務付けられているように、72000 HzのRTPタイムスタンプクロックレートは、選択したISFのみに応じて、960〜2880タイムスタンプティックのAMR-WBトランスポートフレーム長をもたらします。
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タイムスタンプのティックの規範的数（MSのISFと期間は丸くなっています）
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コーデックの多くの機能には、輸送の観点から特別な検討が必要であり、おそらく非正統派と見なされるソリューションが必要です。まず、フレームの持続時間とISFSの関係により、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コーデックの実装は、コーデックによって定義されたすべてのフレームタイプをサポートするために必要であり、任意の2つのフレームタイプ間の切り替えを処理できる必要があります。異なる数のオーディオチャネルまたは異なる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フレームは、Silence Indicator（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フレームタイプの一部は、ステレオフォニックオーディオのエンコードをサポートしています。2チャンネルステレオフォニック信号に対するこのネイティブサポートのため、AMR-WB RTPペイロードで指定されているように、個別のコーデックインスタンスでマルチチャネル輸送をサポートする必要はないようです[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.
ペイロード形式は、パケット損失に対する堅牢性を改善するための2つのメカニズムをサポートしています：単純なフォワードエラー補正（FEC）とフレームインターリーブ。
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.
たとえば、RFC 2733 [11]で、RTP内の一般的なフォワードエラー補正が定義されています。オーディオ冗長コーディングは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 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.
図1：冗長トランスミッションの例では、各フレームは次のRTPペイロードパケットで1回再送信されます。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).
送信者は、チャネル条件に関するフィードバック、たとえばRTPコントロールプロトコル（RTCP）[3]レシーバーレポートに基づいて、適切な量の冗長性を選択する責任があります。送信者は、冗長性によって悪化する可能性のある混雑を回避する責任もあります（詳細についてはセクション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) ]
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-2）からF（n 4）である連続フレームが、2つのフレームを搭載した各パケットをパケットP（n）からP（n 4）に集約します。このアプローチは、インターリービングプロセスと介入プロセスの両方で一定の遅延を可能にするインターリービングパターンを提供します。Deinterleavingバッファーには、消費する準備ができているものを含む、少なくとも3つのフレームの余地が必要です。たとえば、f（n）がデコードされる次のフレームである場合、3つのフレームのストレージスペースが必要です。フレームf（n 2）でフレームf（n）が受信されたため、フレームf（n 3）も運ばれました。、これらの両方のフレームはバッファーに保存されます。さらに、以前のパケットであるP（n 1）で受信したフレームF（n 1）も、deinterleavingバッファーにあります。また、この例では、バッファの占有率は異なることに注意してください。フレームF（n 1）が次のデコードされる場合、バッファーには2つのフレーム、F（n 1）とF（n 3）のみが2つのフレームしかありません。
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を使用するアプリケーションのセッション説明プロトコル（SDP）[6]へのパラメーターのマッピングを提供します。
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].
ペイロードは、オクテットに並べられた要素（ヘッダー、TOC、およびオーディオフレーム）で構成されています。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タイムスタンプは、パケット内の最初のフレームにエンコードされた最初のサンプルのサンプリングインスタントに対応します。タイムスタンプクロック周波数は72000 Hzでなければなりません。この周波数により、フレームの持続時間は、表1に指定されたISFの整数RTPタイムスタンプティックになります。また、コーデックでサポートされている入出力オーディオサンプリング周波数に合理的な変換係数を提供します。最初のオーディオフレームを超えるオーディオフレームの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）は、パケットに掲載された最初のフレームがTalkSpurtの最初のフレームである場合は1に設定されます（[9]のセクション4.1のTalkspurtの定義を参照）。他のすべてのパケットについては、マーカービットをゼロ（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タイムスタンプ値（Modulo 2^32）を増やす順に、TOCエントリをパケットに配置するものとします。
A ToC entry of a payload in the basic mode has the following format:
基本モードでのペイロードのTOCエントリには、次の形式があります。
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エントリの後に別のTOCエントリが続くことを示します。0に設定されている場合、このTOCエントリがTOCの最後のエントリであることを示します。
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ビット）：このTOCエントリで参照されるフレームのグループに使用されるオーディオコーデックフレームタイプを示します。FTは、[1]で表25で指定されているように、AMR-WBコアレートと特別なAMR-WBフレームタイプの1つであるAMR-WBレート、またはコンフォートノイズの組み合わせを指定します。
#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ビット）：このTOCエントリで参照されるグループのフレームの数を示します。0に等しいこのフィールドのTOCエントリ（ゼロフレームを示す）は使用されず、このような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.
インターリーブモードでは、2つの異なるTOCエントリ形式が定義されています。それらは、変位フィールド、4ビットまたは8ビットの長さが異なります。ペイロードヘッダーのLビットは、2つのモードを区別します。
If L=0, a ToC entry has the following format:
L = 0の場合、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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ビット）：ペイロードの前のオーディオフレームに対するi：TH（i = 1..N）オーディオフレームの変位を示すN（n =＃frames）変位フィールドのリスト、フレームの単位で。4ビットの署名されていない整数変位値は0〜15の間である可能性があり、（I-1）：THとI：THフレームの間のデコード順序のオーディオフレームの数を示します。ペイロードの最初の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ビット）：Octetアライメントを確保するために、このエントリで参照されるグループに奇数のフレームがある場合、TOCエントリの最後に4つのパディングビットを含めるものとします。これらのビットはゼロに設定され、受信機によって無視されます。偶数のフレームを含むグループがこのTOCエントリによって参照される場合、これらのパディングビットはペイロードに含まれてはなりません。
If L=1, a ToC entry has the following format:
L = 1の場合、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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ビット）：ペイロードの前のオーディオフレームに対するi：TH（i = 1..N）オーディオフレームの変位を示すN（n =＃frames）変位フィールドのリスト、フレームの単位で。8ビットの署名されていない整数変位値は0〜255の間である可能性があり、（i-1）：thとi：thフレームの間のデコード順序のオーディオフレームの数を示します。ペイロードの最初の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タイムスタンプ値は、フレームにエンコードされた最初のオーディオサンプルのタイムスタンプ値でなければなりません。フレームのタイムスタンプ値は、ペイロードモード、基本、またはインターリーブに応じて異なる方法で導出されます。どちらの場合も、複合パケットの最初のフレームには、RTPヘッダーで受信したものと等しいRTPタイムスタンプがあります。基本モードでは、後続のフレームのRTP時間は2つのステップで導出されます。まず、ペイロード内の前述のすべてのフレームのフレーム持続（表1を参照）の合計が計算されます。次に、この合計がRTPヘッダータイムスタンプ値に追加されます。たとえば、RTPヘッダータイムスタンプ値は12345、ペイロードには4つのフレームがあり、フレーム期間は1152タイムスタンプティックに対応する16 ms（ISF = 32 kHz）であると仮定します。次に、ペイロードの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の間の時間の変位は、（I-1）：THの持続時間も考慮する必要があるため、フレームの持続時間（disi 1） *。フレームの最初のグループの最初のフレームのタイムスタンプ（TS（1））（つまり、ペイロードの最初のフレーム）はRTPヘッダータイムスタンプです。グループ内の後続のフレームの場合、タイムスタンプはによって計算されます
TS(i) = TS(i-1) + (DISi + 1) * frame duration, 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
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.
32 kHzのISFを仮定すると、フレームの16ミリ秒のフレーム持続時間を意味すると、1つのフレームが1152ティックに続きます。ペイロードの最初のフレームのタイムスタンプは、RTPタイムスタンプ、つまりTS（1）= RTP TSです。このフレームの変位フィールド値は無視する必要があることに注意してください。ペイロードの2番目のフレームの場合、タイムスタンプはts（2）= ts（1）（dis2 1） * 1152 = 20409として計算できます。3番目のフレームの場合、タイムスタンプはts（3）= ts（2）（DIS3 1） * 1152 =26169。最後に、ペイロードの4番目のフレームには、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）の値は、[1]の表25に定義されています。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.
インデックス0-13のフレームタイプの場合、ISFフィールドは0に設定されます。これらのフレームタイプのフレーム持続時間は、時間内に20ミリ秒に固定されています。つまり、72 kHzで1440ティックです。タイプ0-9のフレームのみを含むペイロードの場合、TFIフィールドは0に設定され、受信機は無視するものとします。タイプ0-9および10-13のフレームを組み合わせたペイロードでは、タイプ10-13のトランスポートフレームと一致するようにTFI値を設定する必要があります。したがって、タイプ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エントリは、ペイロードモードとは無関係に、TOCエントリが表す最初のトランスポートフレームのRTPタイムスタンプ値（Modulo 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を示しています。この場合、すべてのオーディオフレームは同じフレームタイプを使用してエンコードされていることに注意してください。つまり、TOCエントリは1つだけです。
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つのエントリのTOCを示しています。この場合、ペイロードには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つのエントリを持つTOCを示しています。ペイロードには2つのフレームのグループが含まれています。最初のフレームは1つのフレームを含み、もう1つは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で説明されているように、ゼロ以上のオーディオフレームで構成されています。
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エントリのフレームタイプフィールドに示されています。オーディオフレームのオクテットの長さは、フレームタイプフィールドによって暗黙的に定義され、[1]の表21および25に示されています。ビットの順序と番号付け表記は、[1]で指定されているとおりです。AMR-WB拡張フレームタイプとコンフォートノイズフレームの場合、ビットはエンコーダによって生成される順序です。各オーディオフレームの最後のオクテットは、オクテットのすべてのビットが使用されていない場合、最後にゼロでパディングする必要があります。言い換えれば、各オーディオフレームはオクテットに整列する必要があります。
The payload begins with the payload header, followed by the table of contents, which consists of a list of ToC entries.
ペイロードはペイロードヘッダーから始まり、その後にTOCエントリのリストで構成される目次が続きます。
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エントリごと）内でタイムスタンプの順序でパケット化されます。フレームのグループは、対応するTOCエントリと同じ順序でパケット化されます。FT = 14またはFT = 15のTOCエントリを持つグループにデータオクテットはないことに注意してください。
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 kbit/sフレームタイプ（ft = 26）を使用してエンコードされた3つのAMR-WBフレームを運ぶペイロードを示しています。この例の内部サンプリング頻度は25.6 kHz（ISF = 8）です。最初のフレームのTFIは2で、このペイロードの最初のトランスポートフレームがスーパーフレームの3番目であることを示しています。このペイロードは基本モードであるため、ペイロードの後続のフレームは、デコード順、つまり現在のスーパーフレームの4番目のトランスポートフレームと次のスーパーフレームの最初のトランスポートフレームです。フレームはすべて同じフレームタイプを使用してエンコードされているため、1つの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つのフレームを運ぶ基本モードペイロードの例
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は、3つのAMR-WBフレームを運ぶペイロードを示しています。最初のフレームは、フレーム長368ビット（46バイト）の18.4 kbit/sフレームタイプ（ft = 33）を使用してエンコードされ、2つの後続のフレームは、フレームを持つ20 kbit/sフレームタイプ（ft = 35）を使用してエンコードされます。長さ400ビット（50バイト）。この例の内部サンプリング周波数は32 kHz（ISF = 10）であり、ペイロードの最初のフレームでは23 kbit/sの全体的なビットレート、後続のフレームで25 kbit/sを意味します。最初のフレームのTFIは3で、このペイロードの最初のトランスポートフレームがスーパーフレームの4番目であることを示しています。これは基本モードのペイロードであるため、ペイロードの後続のフレームは、デコード順、つまり現在のスーパーフレームの最初と2番目のトランスポートフレームの連続したフレームです。ペイロードには2つの異なるフレームタイプがあるため、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：2つの異なるフレームタイプを使用して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バイト）のフレーム長（FT = 47）を使用してエンコードされた4つのフレームを運ぶインターリーブモードのペイロードを示しています。内部サンプリング周波数は38.4 kHz（ISF = 13）であり、ペイロード内のすべてのフレームで48 kbit/sのビットレートを意味します。最初のフレームのTFIは0です。したがって、それはスーパーフレームの最初のトランスポートフレームです。後続のフレームの変位フィールドは、DIS2 = 18、DIS3 = 15、およびDIS4 = 10であり、これは、後続のフレームのTFIがそれぞれ3、3、および2のTFIを持っていることを示しています。ペイロードヘッダーの長い変位フィールドフラグLは1に設定されているため、TOCエントリの変位フィールドに8ビットが使用されます。このペイロードのすべてのフレームは同じフレームタイプを使用してエンコードされるため、単一の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
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の例で示されているように、特定のインターリーブパターンには、一定量のdeinterleavingバッファーが必要です。多くのトランスポートフレームスロットで表されるこのバッファースペースは、「インターリーブ」メディアタイプパラメーターで示されています。必要なフレームスロットの数は、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.
フレームバッファーサイズに関する情報は、インターリーブバッファーからフレームを消費することがいつ適切であるかを決定するのに必ずしも十分ではありません。追加情報が必要な2つのケースがあります。1つ目は、ISFの切り替えが発生したとき、次にインターリーブパターンが変化するときです。「int-delay」メディアタイプパラメーターは、この情報を伝えるために定義されています。これにより、送信者は、デコーダーがバッファからフレームの消費を開始する前に、バッファーに存在する必要がある最小限のメディア時間を示すことができます。送信者は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は堅牢であるため、ランダムなフレームの消去率が高いことに耐性がありますが、起動時に連続したフレームロスを処理するのが困難です。したがって、いくつかの特別な実装に関する考慮事項について説明します。このタイプのスタートアップを効率的に処理するには、デコードはスーパーフレームの開始時にのみ開始することが可能であり、最初のトランスポートフレームが失われたとして示されていても当てはまることに注意する必要があります。第二に、デコードは、そのスーパーフレームに属している4つのうち4つの輸送フレームが少なくとも2つのトランスポートフレームが利用可能である場合にのみ開始することをお勧めします。
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.
送信者は、損失のリスクが発生したときにインターリーブパターンを正しく開始および終了することにより、多くのセッションでこのタイプの問題を回避できます。そのような例の1つは、暗号化されたストリームへのアクセス制御のために行われたキー変更です。一部のキーのみがクライアントに提供され、キーがないコンテンツを受信するリスクがある場合、インターリーブパターンがキーの変更を重ねないことをお勧めします。
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フレームタイプのRFC 3267 [7]にペイロード形式を実装することもお勧めします。そうすることで、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の2つのフレームが適切に受信されました。最初のフレームは損失前の最後のパケットであり、後者は損失期間後の最初のパケットです。これらのパケットのISF値は、それぞれISF0とISF1です。これらのフレームのTFIは、それぞれTFI0とTFI1です。関連するフレームの長さ（タイムスタンプのティック）は、それぞれL0とL1として与えられます。この例では、タイムスタンプx1 -x3を備えた3つのフレームが失われました。この例では、下の図に示すように、フレーム損失期間中にISFがISF0からISF1に1回変更されることを前提としています。
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 x1 x2 x3 T1
Example Algorithm:
例アルゴリズム：
Start: # check for frame loss
If (t0 + L0) == t1 Then goto End # no frame loss
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
Return recovered timestamps as
x(n) = t0 + n*L1 and associated ISF equal to isf0,
for 0 < n < (t1 - t0)/L0
goto End
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
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
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で示されるサイズの間の不一致を受信者が見つけた場合、受信機はパケットを廃棄する必要があります。これは、誤った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パケットは、RTP [3]で説明されている一般的なセキュリティ上の考慮事項と、AVP [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.
中間の攻撃者によるデータの改ざんは、オーディオコンテンツを置き換える可能性があり、また、オーディオの品質を低下させる可能性のある誤ったデパケット化/デコードをもたらす可能性があります。
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.
インターリーブ：ペイロードにインターリーブモードが使用されることを示します。パラメーターは、deinterleavingバッファー（消費する準備ができているフレームを含む）に必要なトランスポートフレームスロットの数を指定します。その値は、任意のフレームに先行する最大数のフレームに、任意のフレームに先行する最大数に等しく、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-delay：deinterleavingバッファーで必要なRTPタイムスタンプの最小メディア時間遅延、つまり、deinterleavingバッファーに存在する初期と最新のオーディオフレームの間のRTPタイムスタンプのティックの違い。
ptime: See Section 6 in RFC 2327 [6].
PTIME：RFC 2327 [6]のセクション6を参照してください。
maxptime: See Section 8 in RFC 3267 [7].
Maxptime：RFC 3267 [7]のセクション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エンドポイントであるAMR-WB輸送のRFC 3267もサポートしていますまた、AMR-WBが有能であると宣言する必要があります（つまり、RFC 3267で指定されている「Audio/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.
AMR-WBデコーダーはステレオからモノコンバージョンを実行できるため、AMR-WBのすべての受信機はステレオとモノの両方を受信できるはずですが、レシーバーはモノ信号のプレイアウトのみが可能です。
Public specification: RFC 4352 3GPP TS 26.290, see reference [1] of RFC 4352
パブリック仕様：RFC 4352 3GPP TS 26.290、RFC 4352のリファレンス[1]を参照してください
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ベースのマルチメディアファイル形式内で指定されています。RFC 4352のリファレンス[14]を参照してください。このファイル形式には、RFC 3839 [15]で定義されているMIMEタイプ「Audio/3GPP」または「Video/3GPP」があります。
Person & email address to contact for further information: magnus.westerlund@ericsson.com ari.lakaniemi@nokia.com
詳細については、人とメールアドレスへ
Intended usage: COMMON. It is expected that many IP-based streaming applications will use this type.
意図された使用法：共通。多くのIPベースのストリーミングアプリケーションがこのタイプを使用することが予想されます。
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
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:
メディアタイプの仕様に掲載されている情報には、セッション説明プロトコル（SDP）[6]のフィールドへの特定のマッピングがあり、これは一般的にRTPセッションを説明するために使用されます。SDPを使用してこのRTPペイロード形式を使用してRTPセッションを指定する場合、マッピングは次のとおりです。
- The media type ("audio") is used in SDP "m=" as the media name.
- メディアタイプ（ "Audio"）は、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に設定するか、省略する必要があります。
- The parameters "ptime" and "maxptime" are placed in the SDP attributes "a=ptime" and "a=maxptime", respectively.
- パラメーター「PTIME」と「MAXPTIME」は、それぞれSDP属性「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 "a = 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-delay」パラメーターは宣言的です。sendrecvまたはrecvonlyとして宣言されたストリームの場合、値はレシーバーがdeinterleavingバッファーで受け入れる最大初期遅延を示します。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デコーダー内でローカルミキシングを実行できるため、通常、モノのみを制限する理由は1つだけです。終わりはモノのみが可能です。
- The "ptime" parameter works as indicated by the offer/answer model [8]; "maxptime" SHALL be used in the same way.
- 「PTIME」パラメーターは、オファー/回答モデル[8]で示されているように機能します。「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ペイロード形式[7]を実装するAMR-WB対応エンドポイントは、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 [16]やSAP [17]のSDPのような宣言的使用法では、パラメーターの次の解釈が行われます。
- 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-delay」パラメーターは、このストリームを正しく受信するのに必要な初期バッファリング遅延を示します。
- 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セッションの説明の1つの例が続きます。
m=audio 49120 RTP/AVP 99
a=rtpmap:99 AMR-WB+/72000/2
a=fmtp:99 interleaving=30; int-delay=86400
a=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サブタイプ（Audio/AMR-WB）を登録しました。セクション7を参照してください。
Daniel Enstrom has contributed in writing the codec introduction section. Stefan Bruhn has contributed by writing the ISF recovery algorithm.
ダニエル・エンストロムは、コーデックの紹介セクションを書くことで貢献しました。Stefan Bruhnは、ISF Recoveryアルゴリズムを作成することで貢献しました。
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 SalamiとStefan Bruhnに感謝したいと思います。デイブシンガーは、改善された言語をレビューし、提案することで貢献しました。Anisse TalebとIngemar Johanssonは、ペイロード形式を実装することで貢献し、いくつかの欠陥の位置を見つけるのに役立ちました。また、このドキュメントの基礎となるRFC 3267の共著者であるQiaobing Xieにも認めたいと思います。
[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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.、Frederick、R。、およびV. Jacobson、「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] Handley、M。and 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.、Westerlund、M.、Lakaniemi、A。、およびQ. Xie、「リアルタイムトランスポートプロトコル（RTP）ペイロード形式とファイルストレージ形式（AMR）および適応型マルチレートワイドバンドのファイルストレージ形式（AMR-WB）Audio Codecs "、RFC 3267、2002年6月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、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.、McGrew、D.、Naslund、M.、Carrara、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] Rosenberg、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] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-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.
[15] Castagno、R。およびD. Singer、「第3世代パートナーシッププロジェクト（3GPP）マルチメディアファイルのMIMEタイプ登録」、RFC 3839、2004年7月。
[16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[16] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[17] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[17] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、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ドキュメントは、3GPP Webサーバー「http://www.3gpp.org/」からダウンロードできます。仕様を参照してください。
Authors' Addresses
著者のアドレス
Johan Sjoberg Ericsson Research Ericsson AB SE-164 80 Stockholm SWEDEN
Johan Sjoberg Ericsson Research Ericsson AB SE-164 80ストックホルムスウェーデン
Phone: +46 8 7190000
EMail: 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
Ari Lakaniemi Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group FINLAND
Ari Lakaniemi Nokia Research Center P.O.Box 407 Fin-00045 Nokia Group Finland
Phone: +358-71-8008000
EMail: ari.lakaniemi@nokia.com
Stephan Wenger Nokia Corporation P.O. Box 100 FIN-33721 Tampere FINLAND
Stephan Wenger Nokia Corporation P.O.ボックス100フィン-33721タンペレフィンランド
Phone: +358-50-486-0637
EMail: Stephan.Wenger@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。