[要約] RFC 4867は、AMRおよびAMR-WBオーディオコーデックのためのRTPペイロードフォーマットとファイルストレージフォーマットを定義しています。このRFCの目的は、これらのコーデックを使用して音声データを効果的に伝送および保存するための標準化を提供することです。
Network Working Group J. Sjoberg
Request for Comments: 4867 M. Westerlund
Obsoletes: 3267 Ericsson
Category: Standards Track A. Lakaniemi
Nokia
Q. Xie
Motorola
April 2007
RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs
Adaptive Multi-Rate（AMR）およびAdaptive Multi-Rate Wideband（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 IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document obsoletes RFC 3267.
このドキュメントは、適応型マルチレート（AMR）およびアダプティブマルチレートワイドバンド（AMR-WB）エンコードされた音声信号に使用されるリアルタイムトランスポートプロトコル（RTP）ペイロード形式を指定します。ペイロード形式は、非IPネットワーク上の既存のAMRおよびAMR-WB輸送フォーマットと相互運用できるように設計されています。さらに、電子メールなどのストレージモードアプリケーションでのAMRおよびAMR-WBの音声データの輸送用にファイル形式が指定されています。2つの個別のメディアタイプの登録が含まれています。1つはAMR用、もう1つはAMR-WB用です。RTPペイロード形式とストレージ形式の両方の使用を指定します。このドキュメントは、RFC 3267を廃止します。
Table of Contents
目次
1. Introduction ....................................................4
2. Conventions and Acronyms ........................................4
3. Background on AMR/AMR-WB and Design Principles ..................5
3.1. The Adaptive Multi-Rate (AMR) Speech Codec .................5
3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec .....6
3.3. Multi-Rate Encoding and Mode Adaptation ....................6
3.4. Voice Activity Detection and Discontinuous Transmission ....7
3.5. Support for Multi-Channel Session ..........................7
3.6. Unequal Bit-Error Detection and Protection .................8
3.6.1. Applying UEP and UED in an IP Network ...............8
3.7. Robustness against Packet Loss ............................10
3.7.1. Use of Forward Error Correction (FEC) ..............10
3.7.2. Use of Frame Interleaving ..........................12
3.8. Bandwidth-Efficient or Octet-Aligned Mode .................12
3.9. AMR or AMR-WB Speech over IP Scenarios ....................13
4. AMR and AMR-WB RTP Payload Formats .............................15
4.1. RTP Header Usage ..........................................15
4.2. Payload Structure .........................................17
4.3. Bandwidth-Efficient Mode ..................................17
4.3.1. The Payload Header .................................17
4.3.2. The Payload Table of Contents ......................18
4.3.3. Speech Data ........................................20
4.3.4. Algorithm for Forming the Payload ..................21
4.3.5. Payload Examples ...................................21
4.3.5.1. Single-Channel Payload Carrying a
Single Frame ..............................21
4.3.5.2. Single-Channel Payload Carrying
Multiple Frames ...........................22
4.3.5.3. Multi-Channel Payload Carrying
Multiple Frames ...........................23
4.4. Octet-Aligned Mode ........................................25
4.4.1. The Payload Header .................................25
4.4.2. The Payload Table of Contents and Frame CRCs .......26
4.4.2.1. Use of Frame CRC for UED over IP ..........28
4.4.3. Speech Data ........................................30
4.4.4. Methods for Forming the Payload ....................31
4.4.5. Payload Examples ...................................32
4.4.5.1. Basic Single-Channel Payload
Carrying Multiple Frames ..................32
4.4.5.2. Two-Channel Payload with CRC,
Interleaving, and Robust Sorting ..........32
4.5. Implementation Considerations .............................33
4.5.1. Decoding Validation ................................34
5. AMR and AMR-WB Storage Format ..................................35
5.1. Single-Channel Header .....................................35
5.2. Multi-Channel Header ......................................36
5.3. Speech Frames .............................................37
6. Congestion Control .............................................38
7. Security Considerations ........................................38
7.1. Confidentiality ...........................................39
7.2. Authentication and Integrity ..............................39
8. Payload Format Parameters ......................................39
8.1. AMR Media Type Registration ...............................40
8.2. AMR-WB Media Type Registration ............................44
8.3. Mapping Media Type Parameters into SDP ....................47
8.3.1. Offer-Answer Model Considerations ..................48
8.3.2. Usage of Declarative SDP ...........................50
8.3.3. Examples ...........................................51
9. IANA Considerations ............................................53
10. Changes from RFC 3267 .........................................53
11. Acknowledgements ..............................................55
12. References ....................................................55
12.1. Normative References .....................................55
12.2. Informative References ...................................56
This document obsoletes RFC 3267 and extends that specification with offer/answer rules. See Section 10 for the changes made to this format in relation to RFC 3267.
このドキュメントは、RFC 3267を廃止し、その仕様をオファー/回答ルールで拡張します。RFC 3267に関連して、この形式に加えられた変更については、セクション10を参照してください。
This document specifies the payload format for packetization of AMR and AMR-WB encoded speech signals into the Real-time Transport Protocol (RTP) [8]. The payload format supports transmission of multiple channels, multiple frames per payload, the use of fast codec mode adaptation, robustness against packet loss and bit errors, and interoperation with existing AMR and AMR-WB transport formats on non-IP networks, as described in Section 3.
このドキュメントは、AMRおよびAMR-WBエンコードされた音声信号をリアルタイム輸送プロトコル（RTP）にパケット化するためのペイロード形式を指定します[8]。ペイロード形式は、複数のチャネルの送信、ペイロードあたりの複数のフレーム、高速コーデックモード適応の使用、パケット損失とビットエラーに対する堅牢性、および非IPネットワーク上の既存のAMRおよびAMR-WB輸送フォーマットとの相互操作をサポートします。セクション3。
The payload format itself is specified in Section 4. A related file format is specified in Section 5 for transport of AMR and AMR-WB speech data in storage mode applications such as email. In Section 8, two separate media type registrations are provided, one for AMR and one for AMR-WB.
ペイロード形式自体は、セクション4で指定されています。関連するファイル形式は、電子メールなどのストレージモードアプリケーションでAMRおよびAMR-WBの音声データを輸送するためにセクション5で指定されています。セクション8では、2つの別々のメディアタイプの登録が提供されます。1つはAMR用、もう1つはAMR-WB用です。
Even though this RTP payload format definition supports the transport of both AMR and AMR-WB speech, it is important to remember that AMR and AMR-WB are two different codecs and they are always handled as different payload types in RTP.
このRTPペイロード形式の定義は、AMRとAMR-WBの両方のスピーチの輸送をサポートしていますが、AMRとAMR-WBは2つの異なるコーデックであり、RTPの異なるペイロードタイプとして常に処理されていることを覚えておくことが重要です。
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 [5].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [5]に記載されているように解釈される。
The following acronyms are used in this document:
このドキュメントでは、次の頭字語が使用されています。
3GPP - the Third Generation Partnership Project AMR - Adaptive Multi-Rate (Codec) AMR-WB - Adaptive Multi-Rate Wideband (Codec) CMR - Codec Mode Request CN - Comfort Noise DTX - Discontinuous Transmission ETSI - European Telecommunications Standards Institute FEC - Forward Error Correction SCR - Source Controlled Rate Operation SID - Silence Indicator (the frames containing only CN parameters) VAD - Voice Activity Detection UED - Unequal Error Detection UEP - Unequal Error Protection
3GPP-第3世代パートナーシッププロジェクトAMR -Adaptive Multi -Rate（Codec）AMR -WB -Adaptive Multi -Rate Wideband（Codec）CMR -Codec Mode Request CN -Comfort Noise DTX-不連続な送信ETSI-欧州通信標準研究所FEC-フォワードフォワードエラー補正SCR-ソース制御レート操作SID-サイレンスインジケーター（CNパラメーターのみを含むフレーム）
The term "frame-block" is used in this document to describe the time-synchronized set of speech frames in a multi-channel AMR or AMR-WB session. In particular, in an N-channel session, a frame-block will contain N speech frames, one from each of the channels, and all N speech frames represents exactly the same time period.
このドキュメントでは、「フレームブロック」という用語は、マルチチャネルAMRまたはAMR-WBセッションでの時間同期された音声フレームのセットを説明するために使用されています。特に、nチャネルセッションでは、フレームブロックには各チャネルからのn音声フレームが含まれ、すべてのn音声フレームはまったく同じ期間を表します。
The byte order used in this document is network byte order, i.e., the most significant byte first. The bit order is also the most significant bit first. This is presented in all figures as having the most significant bit leftmost on a line and with the lowest number. Some bit fields may wrap over multiple lines in which cases the bits on the first line are more significant than the bits on the next line.
このドキュメントで使用されるバイト順序は、ネットワークバイトの順序、つまり最初に最も重要なバイトです。ビット順序も最初に最も重要なビットです。これは、すべての数字で、行に最も重要なビット左端と最低数があると示されています。いくつかのビットフィールドは、最初の行のビットが次の行のビットよりも重要である場合、複数の線を包む可能性があります。
AMR and AMR-WB were originally designed for circuit-switched mobile radio systems. Due to their flexibility and robustness, they are also suitable for other real-time speech communication services over packet-switched networks such as the Internet.
AMRとAMR-WBは、もともと回路が切り替えられたモバイル無線システム用に設計されていました。柔軟性と堅牢性のため、インターネットなどのパケットスイッチのネットワークを介した他のリアルタイムの音声通信サービスにも適しています。
Because of the flexibility of these codecs, the behavior in a particular application is controlled by several parameters that select options or specify the acceptable values for a variable. These options and variables are described in general terms at appropriate points in the text of this specification as parameters to be established through out-of-band means. In Section 8, all of the parameters are specified in the form of media subtype registrations for the AMR and AMR-WB encodings. 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 8.3 provides a mapping of the parameters into the Session Description Protocol (SDP) [11] for those applications that use SDP.
これらのコーデックの柔軟性のため、特定のアプリケーションの動作は、オプションを選択するか、変数の許容値を指定するいくつかのパラメーターによって制御されます。これらのオプションと変数は、この仕様のテキストの適切なポイントで一般的な用語で、バンド外の平均を通じて確立されるパラメーターとして説明されています。セクション8では、すべてのパラメーターは、AMRおよびAMR-WBエンコーディングのメディアサブタイプ登録の形式で指定されています。セッションのセットアップでこれらのパラメーターを通知するために使用される方法、または参加者の事前の合意を手配するために使用される方法は、このドキュメントの範囲を超えています。ただし、セクション8.3では、SDPを使用するアプリケーションのセッション説明プロトコル（SDP）[11]へのパラメーターのマッピングを提供します。
The AMR codec was originally developed and standardized by the European Telecommunications Standards Institute (ETSI) for GSM cellular systems. It is now chosen by the Third Generation Partnership Project (3GPP) as the mandatory codec for third generation (3G) cellular systems [1].
AMRコーデックは、もともとGSMセルラーシステム向けの欧州通信基準研究所（ETSI）によって開発および標準化されました。現在、第3世代のパートナーシッププロジェクト（3GPP）により、第3世代（3G）セルラーシステムの必須コーデックとして選択されています[1]。
The AMR codec is a multi-mode codec that supports eight narrow band speech encoding modes with bit rates between 4.75 and 12.2 kbps. The sampling frequency used in AMR is 8000 Hz and the speech encoding is performed on 20 ms speech frames. Therefore, each encoded AMR speech frame represents 160 samples of the original speech.
AMRコーデックは、4.75〜12.2 kbpsのビットレートの8つの狭いバンド音声エンコードモードをサポートするマルチモードコーデックです。AMRで使用されるサンプリング周波数は8000 Hzで、音声エンコードは20ミリ秒の音声フレームで実行されます。したがって、エンコードされた各AMR音声フレームは、元の音声の160のサンプルを表します。
Among the eight AMR encoding modes, three are already separately adopted as standards of their own. Particularly, the 6.7 kbps mode is adopted as PDC-EFR [18], the 7.4 kbps mode as IS-641 codec in TDMA [17], and the 12.2 kbps mode as GSM-EFR [16].
8つのAMRエンコーディングモードのうち、3つはすでに独自の基準として個別に採用されています。特に、6.7 kbpsモードは、PDC-EFR [18]、TDMAのIS-641コーデックとして7.4 kbpsモード[17]、および12.2 kbpsモードとしてGSM-EFR [16]として採用されています。
The Adaptive Multi-Rate Wideband (AMR-WB) speech codec [3] was originally developed by 3GPP to be used in GSM and 3G cellular systems.
適応型マルチレートワイドバンド（AMR-WB）音声コーデック[3]は、もともと3GPPによって開発され、GSMおよび3Gセルラーシステムで使用されました。
Similar to AMR, the AMR-WB codec is also a multi-mode speech codec. AMR-WB supports nine wide band speech coding modes with respective bit rates ranging from 6.6 to 23.85 kbps. The sampling frequency used in AMR-WB is 16000 Hz and the speech processing is performed on 20 ms frames. This means that each AMR-WB encoded frame represents 320 speech samples.
AMRと同様に、AMR-WBコーデックはマルチモードの音声コーデックでもあります。AMR-WBは、6.6〜23.85 kbpsの範囲のビットレートで、9つのワイドバンド音声コーディングモードをサポートしています。AMR-WBで使用されるサンプリング周波数は16000 Hzで、音声処理は20ミリ秒のフレームで実行されます。これは、各AMR-WBエンコードされたフレームが320の音声サンプルを表すことを意味します。
The multi-rate encoding (i.e., multi-mode) capability of AMR and AMR-WB is designed for preserving high speech quality under a wide range of transmission conditions.
AMRおよびAMR-WBのマルチレートエンコーディング（つまり、マルチモード）機能は、広範囲の伝送条件下で高い音声品質を維持するために設計されています。
With AMR or AMR-WB, mobile radio systems are able to use available bandwidth as effectively as possible. For example, in GSM it is possible to dynamically adjust the speech encoding rate during a session so as to continuously adapt to the varying transmission conditions by dividing the fixed overall bandwidth between speech data and error protective coding. This enables the best possible trade-off between speech compression rate and error tolerance. To perform mode adaptation, the decoder (speech receiver) needs to signal the encoder (speech sender) the new mode it prefers. This mode change signal is called Codec Mode Request or CMR.
AMRまたはAMR-WBを使用すると、モバイル無線システムは、可能な限り効果的に利用可能な帯域幅を使用できます。たとえば、GSMでは、セッション中に音声エンコードレートを動的に調整して、スピーチデータとエラー保護コーディングの間の固定全体の帯域幅を分割することにより、さまざまな伝送条件に継続的に適応することができます。これにより、音声圧縮率とエラーの許容度との間の可能な限り最良のトレードオフが可能になります。モードの適応を実行するには、デコーダー（音声受信機）がエンコーダ（スピーチ送信者）に好まれる新しいモードを信号する必要があります。このモード変更信号は、コーデックモード要求またはCMRと呼ばれます。
Since in most sessions speech is sent in both directions between the two ends, the mode requests from the decoder at one end to the encoder at the other end are piggy-backed over the speech frames in the reverse direction. In other words, there is no out-of-band signaling needed for sending CMRs.
ほとんどのセッションでは、スピーチは両端の間の両方向に送信されるため、一方の端のデコーダーからもう一方の端のエンコーダーへのモード要求は、逆方向の音声フレームにピギー補助されます。言い換えれば、CMRを送信するために必要な帯域外シグナルはありません。
Every AMR or AMR-WB codec implementation is required to support all the respective speech coding modes defined by the codec and must be able to handle mode switching to any of the modes at any time. However, some transport systems may impose limitations in the number of modes supported and how often the mode can change due to bandwidth limitations or other constraints. For this reason, the decoder is allowed to indicate its acceptance of a particular mode or a subset of the defined modes for the session using out-of-band means.
すべてのAMRまたはAMR-WBコーデックの実装は、コーデックによって定義されたそれぞれの音声コーディングモードをすべてサポートするために必要であり、いつでもモードのいずれかにモードを切り替えることができなければなりません。ただし、一部の輸送システムは、サポートされているモードの数に制限を課し、帯域幅の制限またはその他の制約によりモードが変更できる頻度が課される場合があります。このため、デコーダーは、アウトオブバンド平均を使用して、セッションの特定のモードまたは定義されたモードのサブセットの受け入れを示すことができます。
For example, the GSM radio link can only use a subset of at most four different modes in a given session. This subset can be any combination of the eight AMR modes for an AMR session or any combination of the nine AMR-WB modes for an AMR-WB session.
たとえば、GSM無線リンクは、特定のセッションでは、ほとんど4つの異なるモードのサブセットのみを使用できます。このサブセットは、AMRセッションの8つのAMRモードの任意の組み合わせ、またはAMR-WBセッションの9つのAMR-WBモードの任意の組み合わせにすることができます。
Moreover, for better interoperability with GSM through a gateway, the decoder is allowed to use out-of-band means to set the minimum number of frames between two mode changes and to limit the mode change among neighboring modes only.
さらに、ゲートウェイを介したGSMとの相互運用性を向上させるために、デコーダーはバンド外の手段を使用して、2つのモード変更の間に最小フレーム数を設定し、隣接するモード間のモード変更のみを制限することができます。
Section 8 specifies a set of media type parameters that may be used to signal these mode adaptation controls at session setup.
セクション8では、セッションのセットアップでこれらのモード適応コントロールを信号するために使用できるメディアタイプパラメーターのセットを指定します。
Both codecs support voice activity detection (VAD) and generation of comfort noise (CN) parameters during silence periods. Hence, the codecs have the option to reduce 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 or AMR-WB frames containing CN parameters are called Silence Indicator (SID) frames. See more details about VAD and DTX functionality in [9] and [10].
どちらのコーデックも、沈黙期間中の音声アクティビティ検出（VAD）とコンフォートノイズの生成（CN）パラメーターをサポートしています。したがって、コーデックには、沈黙期間中に送信されたビットとパケットの数を最小限に抑えるオプションがあります。沈黙期間中に定期的にCNパラメーターを送信する動作は、通常、不連続伝送（DTX）またはソース制御レート（SCR）操作と呼ばれます。CNパラメーターを含むAMRまたはAMR-WBフレームは、Silence Indicator（SID）フレームと呼ばれます。[9]および[10]のVADおよびDTX機能の詳細を参照してください。
Both the RTP payload format and the storage format defined in this document support multi-channel audio content (e.g., a stereophonic speech session).
このドキュメントで定義されているRTPペイロード形式とストレージ形式の両方が、マルチチャネルオーディオコンテンツをサポートしています（たとえば、ステレオフォニック音声セッション）。
Although AMR and AMR-WB codecs themselves do not support encoding of multi-channel audio content into a single bit stream, they can be used to separately encode and decode each of the individual channels.
AMRおよびAMR-WBコーデック自体は、マルチチャネルオーディオコンテンツのエンコードを単一のビットストリームにサポートしていませんが、個々のチャネルを個別にエンコードおよびデコードするために使用できます。
To transport (or store) the separately encoded multi-channel content, the speech frames for all channels that are framed and encoded for the same 20 ms periods are logically collected in a frame-block.
個別にエンコードされたマルチチャネルコンテンツを輸送（または保存）するには、同じ20 ms期間にわたってフレーム化およびエンコードされたすべてのチャネルの音声フレームが、フレームブロックで論理的に収集されます。
At the session setup, out-of-band signaling must be used to indicate the number of channels in the session, and the order of the speech frames from different channels in each frame-block. When using SDP for signaling, the number of channels is specified in the rtpmap attribute and the order of channels carried in each frame-block is implied by the number of channels as specified in Section 4.1 in [12].
セッションのセットアップでは、セッション内のチャネルの数と、各フレームブロックの異なるチャネルからの音声フレームの順序を示すために、帯域外シグナリングを使用する必要があります。SDPをシグナリングに使用する場合、チャネルの数はRTPMAP属性で指定され、各フレームブロックに携帯されるチャネルの順序は[12]のセクション4.1で指定されているチャネルの数で暗示されます。
The speech bits encoded in each AMR or AMR-WB frame have different perceptual sensitivity to bit errors. This property has been exploited in cellular systems to achieve better voice quality by using unequal error protection and detection (UEP and UED) mechanisms.
各AMRまたはAMR-WBフレームでエンコードされた音声ビットは、ビットエラーに対して異なる知覚感度を持っています。この特性は、等しいエラー保護と検出（UEPおよびUED）メカニズムを使用することにより、より良い音声品質を実現するために、セルラーシステムで活用されています。
The UEP/UED mechanisms focus the protection and detection of corrupted bits to the perceptually most sensitive bits in an AMR or AMR-WB frame. In particular, speech bits in an AMR or AMR-WB frame are divided into class A, B, and C, where bits in class A are the most sensitive and bits in class C the least sensitive (see Table 1 below for AMR and [4] for AMR-WB). An AMR or AMR-WB frame is only declared damaged if there are bit errors found in the most sensitive bits, i.e., the class A bits. On the other hand, it is acceptable to have some bit errors in the other bits, i.e., class B and C bits.
UEP/UEDメカニズムは、AMRまたはAMR-WBフレームの知覚的に最も敏感なビットに対する破損したビットの保護と検出に焦点を合わせます。特に、AMRまたはAMR-WBフレームの音声ビットは、クラスA、B、およびCに分割されます。クラスAのビットは、クラスCの最も敏感であり、最も敏感ではありません（AMRおよび[以下の表1を参照してください。4] AMR-WBの場合）。AMRまたはAMR-WBフレームは、最も敏感なビット、つまりクラスAビットにビットエラーが見つかった場合にのみ損傷があります。一方、他のビット、つまりクラスBおよびCビットにいくつかのビットエラーがあることは許容されます。
Class A Total speech
Index Mode bits bits
----------------------------------------
0 AMR 4.75 42 95
1 AMR 5.15 49 103
2 AMR 5.9 55 118
3 AMR 6.7 58 134
4 AMR 7.4 61 148
5 AMR 7.95 75 159
6 AMR 10.2 65 204
7 AMR 12.2 81 244
8 AMR SID 39 39
Table 1. The number of class A bits for the AMR codec
表1. AMRコーデックのクラスAビットの数
Moreover, a damaged frame is still useful for error concealment at the decoder since some of the less sensitive bits can still be used. This approach can improve the speech quality compared to discarding the damaged frame.
さらに、損傷したフレームは、デコーダーでのエラーの隠蔽に依然として役立ちます。このアプローチは、損傷したフレームを破棄するのと比較して、音声品質を改善できます。
To take full advantage of the bit-error robustness of the AMR and AMR-WB codec, the RTP payload format is designed to facilitate UEP/UED in an IP network. It should be noted however that the utilization of UEP and UED discussed below is OPTIONAL.
AMRおよびAMR-WBコーデックのビットエラーの堅牢性を最大限に活用するために、RTPペイロード形式は、IPネットワークでUEP/UEDを促進するように設計されています。ただし、以下で説明するUEPとUEDの利用はオプションであることに注意する必要があります。
UEP/UED in an IP network can be achieved by detecting bit errors in class A bits and tolerating bit errors in class B/C bits of the AMR or AMR-WB frame(s) in each RTP payload.
IPネットワークのUEP/UEDは、クラスAビットのビットエラーを検出し、各RTPペイロードのAMRまたはAMR-WBフレームのクラスB/Cビットのビットエラーを許容することで実現できます。
Link-layer protocols exist that do not discard packets containing bit errors, e.g., SLIP and some wireless links. With the Internet traffic pattern shifting towards a more multimedia-centric one, more link layers of such nature may emerge in the future. With transport layer support for partial checksums (for example, those supported by UDP-Lite [19]), bit error tolerant AMR and AMR-WB traffic could achieve better performance over these types of links. The relationship between UDP-Lite's partial checksum at the transport layer and the checksum coverage provided by the link-layer frame is described in UDP-Lite specification [19].
リンク層プロトコルは、ビットエラー、たとえばスリップやワイヤレスリンクを含むパケットを破棄しない。インターネットトラフィックパターンがよりマルチメディア中心のものにシフトすると、そのような性質のより多くのリンク層が将来現れる可能性があります。部分的なチェックサムの輸送層サポート（たとえば、UDP-Lite [19]によってサポートされるもの）により、ビットエラートレラントAMRとAMR-WBトラフィックは、これらのタイプのリンクよりも優れたパフォーマンスを実現できます。輸送層でのUDP-Liteの部分的なチェックサムと、リンク層フレームによって提供されるチェックサムカバレッジとの関係は、UDP-Lite仕様[19]で説明されています。
There are at least two basic approaches for carrying AMR and AMR-WB traffic over bit error tolerant IP networks:
ビットエラートレラントIPネットワークを介してAMRおよびAMR-WBトラフィックを搭載するための少なくとも2つの基本的なアプローチがあります。
a) Utilizing a partial checksum to cover the IP, transport protocol (e.g., UDP-Lite), RTP and payload headers, and the most important speech bits of the payload. The IP, UDP and RTP headers need to be protected, and it is recommended that at least all class A bits are covered by the checksum.
a) IP、トランスポートプロトコル（UDP-Liteなど）、RTPおよびペイロードヘッダー、およびペイロードの最も重要な音声ビットをカバーするために部分的なチェックサムを利用します。IP、UDP、およびRTPヘッダーを保護する必要があり、少なくともすべてのクラスAビットをチェックサムでカバーすることをお勧めします。
b) Utilizing a partial checksum to only cover the IP, transport protocol, RTP and payload headers, but an AMR or AMR-WB frame CRC to cover the class A bits of each speech frame in the RTP payload.
b) IP、トランスポートプロトコル、RTP、ペイロードヘッダーのみをカバーするために部分的なチェックサムを使用しますが、RTPペイロードの各音声フレームのクラスAビットをカバーするAMRまたはAMR-WBフレームCRC。
In either approach, at least part of the class B/C bits are left without error-check and thus bit error tolerance is achieved.
どちらのアプローチでも、クラスB/Cビットの少なくとも一部はエラーチェックなしで残されているため、ビットエラートレランスが達成されます。
Note, it is still important that the network designer pays attention to the class B and C residual bit error rate. Though less sensitive to errors than class A bits, class B and C bits are not insignificant, and undetected errors in these bits cause degradation in speech quality. An example of residual error rates considered acceptable for AMR in the Universal Mobile Telecommunications System (UMTS) can be found in [24] and for AMR-WB in [25].
ネットワーク設計者がクラスBおよびC残差ビットエラー率に注意を払うことが依然として重要であることに注意してください。クラスAビットよりもエラーに敏感ではありませんが、クラスBおよびCビットは取るに足らないものではなく、これらのビットの検出されないエラーは音声品質の分解を引き起こします。Universal Mobile Telecommunications System（UMTS）のAMRで許容可能と見なされる残留エラー率の例は、[24]および[25]のAMR-WBに記載されています。
The application interface to the UEP/UED transport protocol (e.g., UDP-Lite) may not provide any control over the link error rate, especially in a gateway scenario. Therefore, it is incumbent upon the designer of a node with a link interface of this type to choose a residual bit error rate that is low enough to support applications such as AMR encoding when transmitting packets of a UEP/UED transport protocol.
UEP/UEDトランスポートプロトコルへのアプリケーションインターフェイス（UDP-Liteなど）は、特にゲートウェイシナリオでは、リンクエラー率を制御できない場合があります。したがって、このタイプのリンクインターフェイスを備えたノードの設計者には、UEP/UEDトランスポートプロトコルのパケットを送信するときにAMRエンコードなどのアプリケーションをサポートするのに十分低い残差ビットエラーレートを選択します。
Approach 1 is bit efficient, flexible and simple, but comes with two disadvantages, namely, a) bit errors in protected speech bits will cause the payload to be discarded, and b) when transporting multiple AMR or AMR-WB frames in a RTP payload, there is the possibility that a single bit error in protected bits will cause all the frames to be discarded.
アプローチ1は少し効率的で柔軟性があり、シンプルですが、2つの欠点があります。つまり、a）保護された音声ビットのビットエラーはペイロードを破棄し、b）RTPペイロードで複数のAMRまたはAMR-WBフレームを輸送する場合、保護されたビットの1つのビットエラーがすべてのフレームを破棄する可能性があります。
These disadvantages can be avoided, if needed, with some overhead in the form of a frame-wise CRC (Approach 2). In problem a), the CRC makes it possible to detect bit errors in class A bits and use the frame for error concealment, which gives a small improvement in speech quality. For b), when transporting multiple frames in a payload, the CRCs remove the possibility that a single bit error in a class A bit will cause all the frames to be discarded. Avoiding that improves the speech quality when transporting multiple AMR or AMR-WB frames over links subject to bit errors.
これらの欠点は、必要に応じて、フレームごとのCRCの形である程度のオーバーヘッドを使用して回避できます（アプローチ2）。問題a）では、CRCはクラスAビットのビットエラーを検出し、フレームを使用してエラーの隠蔽を可能にします。これにより、音声品質がわずかに改善されます。b）の場合、ペイロード内の複数のフレームを輸送する場合、CRCはクラスの1つのビットエラーがすべてのフレームを破棄する可能性を削除します。ビットエラーの対象となるリンク上で複数のAMRまたはAMR-WBフレームを輸送するときに音声品質を向上させることを避けます。
The choice between the above two approaches must be made based on the available bandwidth, and the desired tolerance to bit errors. Neither solution is appropriate for all cases. Section 8 defines parameters that may be used at session setup to choose between these approaches.
上記の2つのアプローチの選択は、利用可能な帯域幅とビットエラーに対する望ましい耐性に基づいて行う必要があります。どちらのソリューションもすべてのケースに適していません。セクション8では、セッションセットアップで使用されるパラメーターを定義して、これらのアプローチを選択します。
The payload format supports several means, including forward error correction (FEC) and frame interleaving, to increase robustness against packet loss.
ペイロード形式は、パケット損失に対する堅牢性を高めるために、フォワードエラー補正（FEC）やフレームインターリーブなど、いくつかの手段をサポートしています。
The simple scheme of repetition of previously sent data is one way of achieving FEC. Another possible scheme which is more bandwidth efficient is to use payload-external FEC, e.g., RFC 2733 [23], which generates extra packets containing repair data. The whole payload can also be sorted in sensitivity order to support external FEC schemes using UEP. There is also a work in progress on a generic version of such a scheme [22] that can be applied to AMR or AMR-WB payload transport.
以前に送信されたデータの繰り返しの単純なスキームは、FECを達成する1つの方法です。より帯域幅効率的なもう1つの可能なスキームは、修理データを含む追加のパケットを生成するRFC 2733 [23]など、ペイロード - 外部FECを使用することです。ペイロード全体を、UEPを使用して外部FECスキームをサポートするために、感度の順序でソートすることもできます。また、AMRまたはAMR-WBペイロードトランスポートに適用できる、このようなスキーム[22]の一般的なバージョンで進行中の作業もあります。
With AMR or AMR-WB, it is possible to use the multi-rate capability of the codec to send redundant copies of a frame using either the same mode or another mode, e.g., one with lower bandwidth. We describe such a scheme next.
AMRまたはAMR-WBを使用すると、コーデックのマルチレート機能を使用して、同じモードまたは別のモード、たとえば帯域幅が低いモードのいずれかを使用してフレームの冗長コピーを送信することができます。次にそのようなスキームについて説明します。
This involves the simple retransmission of previously transmitted frame-blocks together with the current frame-block(s). This is done by using a sliding window to group the speech frame-blocks to send in each payload. Figure 1 below shows us an example.
これには、以前に送信されたフレームブロックと現在のフレームブロックの単純な再送信が含まれます。これは、スライドウィンドウを使用して、各ペイロードを送信するために音声フレームブロックをグループ化することによって行われます。以下の図1は、例を示しています。
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
<---- p(n-1) ---->
<----- p(n) ----->
<---- p(n+1) ---->
<---- p(n+2) ---->
<---- p(n+3) ---->
<---- p(n+4) ---->
Figure 1: An example of redundant transmission
図1：冗長伝送の例
In this example each frame-block is retransmitted one time in the following RTP payload packet. Here, f(n-2)..f(n+4) denotes a sequence of speech frame-blocks, and p(n-1)..p(n+4) a sequence of payload packets.
この例では、各フレームブロックが次のRTPペイロードパケットで1回再送信されます。ここで、F（n-2）.. f（n 4）は、一連の音声フレームブロックを示し、p（n-1）.. p（n 4）のペイロードパケットのシーケンスを示します。
The use of this approach does not require signaling at the session setup. However, a parameter for providing a maximum delay in transmitting any redundant frame is defined in Section 8. In other words, the speech sender can choose to use this scheme without consulting the receiver. This is because a packet containing redundant frames will not look different from a packet with only new frames. The receiver may receive multiple copies or versions (encoded with different modes) of a frame for a certain timestamp if no packet is lost. If multiple versions of the same speech frame are received, it is recommended that the mode with the highest rate be used by the speech decoder.
このアプローチの使用では、セッションのセットアップでのシグナリングは必要ありません。ただし、冗長フレームの送信に最大の遅延を提供するためのパラメーターは、セクション8で定義されています。つまり、音声送信者は、受信機に相談せずにこのスキームを使用することを選択できます。これは、冗長なフレームを含むパケットが新しいフレームのみを備えたパケットと違いはないためです。受信者は、パケットが失われない場合、特定のタイムスタンプのフレームの複数のコピーまたはバージョン（異なるモードでエンコードされた）を受け取ることができます。同じ音声フレームの複数のバージョンが受信される場合、最高レートのモードを音声デコーダーで使用することをお勧めします。
This redundancy scheme provides the same functionality as the one described in RFC 2198, "RTP Payload for Redundant Audio Data" [27]. In most cases the mechanism in this payload format is more efficient and simpler than requiring both endpoints to support RFC 2198 in addition. There are two situations in which use of RFC 2198 is indicated: if the spread in time required between the primary and redundant encodings is larger than the duration of 5 frames, the bandwidth overhead of RFC 2198 will be lower; or, if a non-AMR codec is desired for the redundant encoding, the AMR payload format won't be able to carry it.
この冗長性スキームは、RFC 2198で説明されている「冗長なオーディオデータのRTPペイロード」[27]と同じ機能を提供します。ほとんどの場合、このペイロード形式のメカニズムは、RFC 2198をサポートするために両方のエンドポイントを要求するよりも効率的でシンプルです。RFC 2198の使用が示される2つの状況があります。一次エンコーディングと冗長エンコーディングの間に必要な時間の広がりが5フレームの期間よりも大きい場合、RFC 2198の帯域幅のオーバーヘッドは低くなります。または、非AMRコーデックが冗長エンコーディングに望まれている場合、AMRペイロード形式はそれを運ぶことができません。
The sender is responsible for selecting an appropriate amount of redundancy based on feedback about the channel, e.g., in RTCP receiver reports. A sender should not base selection of FEC on the CMR, as this parameter most probably was set based on non-IP information, e.g., radio link performance measures. The sender is also responsible for avoiding congestion, which may be exacerbated by redundancy (see Section 6 for more details).
送信者は、RTCPレシーバーレポートで、チャネルに関するフィードバックに基づいて、適切な量の冗長性を選択する責任があります。このパラメーターは、おそらく無線リンクのパフォーマンス測定に基づいて設定されたため、おそらくこのパラメーターが設定されていたため、送信者はCMRのFECのベース選択をしてはなりません。送信者はまた、冗長性によって悪化する可能性のある輻輳を回避する責任があります（詳細についてはセクション6を参照）。
To decrease protocol overhead, the payload design allows several speech frame-blocks to be encapsulated into a single RTP packet. One of the drawbacks of such an approach is that packet loss can cause loss of several consecutive speech frame-blocks, which usually causes clearly audible distortion in the reconstructed speech. Interleaving of frame-blocks can improve the speech quality in such cases by distributing the consecutive losses into a series of single frame-block losses. However, interleaving and bundling several frame-blocks per payload will also increase end-to-end delay and is therefore not appropriate for all types of applications. Streaming applications will most likely be able to exploit interleaving to improve speech quality in lossy transmission conditions.
プロトコルオーバーヘッドを減らすために、ペイロード設計により、いくつかの音声フレームブロックを単一のRTPパケットにカプセル化できます。このようなアプローチの欠点の1つは、パケットの損失がいくつかの連続した音声フレームブロックの損失を引き起こす可能性があることです。これは通常、再構築された音声ではっきりと聞こえる歪みを引き起こします。フレームブロックのインターリーブは、連続した損失を一連の単一のフレームブロック損失に分配することにより、そのような場合の音声品質を改善することができます。ただし、ペイロードごとにいくつかのフレームブロックをインターリーブしてバンドルすると、エンドツーエンドの遅延が増加するため、あらゆるタイプのアプリケーションに適していません。ストリーミングアプリケーションは、ほとんどの場合、インターリーブを活用して、失われた伝送条件の音声品質を向上させることができます。
This payload design supports the use of frame interleaving as an option. For the encoder (speech sender) to use frame interleaving in its outbound RTP packets for a given session, the decoder (speech receiver) needs to indicate its support via out-of-band means (see Section 8).
このペイロード設計は、オプションとしてフレームインターリーブの使用をサポートしています。エンコーダー（スピーチ送信者）が特定のセッションのアウトバウンドRTPパケットでフレームインターリーブを使用するには、デコーダー（音声受信者）が帯域外の平均を介してサポートを示す必要があります（セクション8を参照）。
For a given session, the payload format can be either bandwidth efficient or octet aligned, depending on the mode of operation that is established for the session via out-of-band means.
特定のセッションでは、ペイロード形式は、帯域外の手段を介してセッションに対して確立される操作モードに応じて、帯域幅効率またはオクテットのいずれかです。
In the octet-aligned format, all the fields in a payload, including payload header, table of contents entries, and speech frames themselves, are individually aligned to octet boundaries to make implementations efficient. In the bandwidth-efficient format, only the full payload is octet aligned, so fewer padding bits are added.
オクテットに合わせた形式では、ペイロードヘッダー、目次エントリ、および音声フレーム自体を含むペイロード内のすべてのフィールドが、実装を効率的にするために個別にアラインドされています。帯域幅効率の高い形式では、完全なペイロードのみがオクテットアラインされているため、追加されるパディングビットは少なくなります。
Note, octet alignment of a field or payload means that the last octet is padded with zeroes in the least significant bits to fill the octet. Also note that this padding is separate from padding indicated by the P bit in the RTP header.
注、フィールドまたはペイロードのオクテットアライメントは、最後のオクテットに、オクテットを満たすために最も重要なビットにゼロがパッドで埋められていることを意味します。また、このパディングは、RTPヘッダーのPビットで示されるパディングとは別のパディングであることに注意してください。
Between the two operation modes, only the octet-aligned mode has the capability to use the robust sorting, interleaving, and frame CRC to make the speech transport more robust to packet loss and bit errors.
2つの操作モードの間では、Octetに配置されたモードのみが、堅牢なソート、インターリーブ、およびフレームCRCを使用して、パケットの損失とビットエラーにより堅牢な音声輸送をより堅牢にする機能を備えています。
The primary scenario for this payload format is IP end-to-end between two terminals, as shown in Figure 2. This payload format is expected to be useful for both conversational and streaming services.
このペイロード形式の主要なシナリオは、図2に示すように、2つの端子間のIPエンドツーエンドです。このペイロード形式は、会話サービスとストリーミングサービスの両方に役立つと予想されます。
+----------+ +----------+
| | IP/UDP/RTP/AMR or | |
| TERMINAL |<----------------------->| TERMINAL |
| | IP/UDP/RTP/AMR-WB | |
+----------+ +----------+
Figure 2: IP terminal to IP terminal scenario
図2：IPターミナルからIP端末シナリオ
A conversational service puts requirements on the payload format. Low delay is one very important factor, i.e., few speech frame-blocks per payload packet. Low overhead is also required when the payload format traverses low bandwidth links, especially as the frequency of packets will be high. For low bandwidth links, it is also an advantage to support UED, which allows a link provider to reduce delay and packet loss, or to reduce the utilization of link resources.
会話サービスは、ペイロード形式に要件を置きます。低遅延は非常に重要な要素の1つです。つまり、ペイロードパケットごとの音声フレームブロックはほとんどありません。特にパケットの頻度が高くなるため、ペイロード形式が低帯域幅リンクを通過する場合、低いオーバーヘッドも必要です。帯域幅の低いリンクの場合、UEDをサポートすることも利点です。これにより、リンクプロバイダーが遅延とパケットの損失を減らすか、リンクリソースの利用を減らすことができます。
A streaming service has less strict real-time requirements and therefore can use a larger number of frame-blocks per packet than a conversational service. This reduces the overhead from IP, UDP, and RTP headers. However, including several frame-blocks per packet makes the transmission more vulnerable to packet loss, so interleaving may be used to reduce the effect that packet loss will have on speech quality. A streaming server handling a large number of clients also needs a payload format that requires as few resources as possible when doing packetization. The octet-aligned and interleaving modes require the least amount of resources, while CRC, robust sorting, and bandwidth-efficient modes have higher demands.
ストリーミングサービスのリアルタイム要件は厳密ではないため、会話サービスよりもパケットごとに多くのフレームブロックを使用できます。これにより、IP、UDP、およびRTPヘッダーからオーバーヘッドが削減されます。ただし、パケットごとに複数のフレームブロックを含めると、送信がパケットの損失に対してより脆弱になるため、インターリーブを使用して、パケット損失が音質に与える影響を減らすことができます。多数のクライアントを処理するストリーミングサーバーには、パケット化を行うときにできるだけ少ないリソースを必要とするペイロード形式も必要です。オクテット整列とインターリービングモードには、リソースの量が少なくなりますが、CRC、堅牢なソート、および帯域幅効率の高いモードにはより高い要求があります。
Another scenario is when AMR or AMR-WB encoded speech is transmitted from a non-IP system (e.g., a GSM or 3GPP UMTS network) to an IP/UDP/RTP VoIP terminal, and/or vice versa, as depicted in Figure 3.
別のシナリオは、AMRまたはAMR-WBエンコードされた音声が非IPシステム（GSMまたは3GPP UMTSネットワークなど）からIP/UDP/RTP VoIP端末に送信される場合です。。
AMR or AMR-WB
over
I.366.{2,3} or +------+ +----------+
3G Iu or | | IP/UDP/RTP/AMR or | |
<------------->| GW |<---------------------->| TERMINAL |
GSM Abis | | IP/UDP/RTP/AMR-WB | |
etc. +------+ +----------+
|
GSM/ | IP network
3GPP UMTS network |
Figure 3: GW to VoIP terminal scenario
図3：GWからVoIP端末シナリオ
In such a case, it is likely that the AMR or AMR-WB frame is packetized in a different way in the non-IP network and will need to be re-packetized into RTP at the gateway. Also, speech frames from the non-IP network may come with some UEP/UED information (e.g., a frame quality indicator) that will need to be preserved and forwarded on to the decoder along with the speech bits. This is specified in Section 4.3.2.
このような場合、AMRまたはAMR-WBフレームは、非IPネットワークで異なる方法でパケット化されている可能性が高く、ゲートウェイでRTPに再パケット化する必要があります。また、非IPネットワークからの音声フレームには、uep/ued情報（たとえば、フレーム品質インジケーター）が付属している場合があります。これらの情報は、音声ビットとともに保存してデコーダーに転送する必要があります。これは、セクション4.3.2で指定されています。
AMR's capability to do fast mode switching is exploited in some non-IP networks to optimize speech quality. To preserve this functionality in scenarios including a gateway to an IP network, a codec mode request (CMR) field is needed. The gateway will be responsible for forwarding the CMR between the non-IP and IP parts in both directions. The IP terminal should follow the CMR forwarded by the gateway to optimize speech quality going to the non-IP decoder. The mode control algorithm in the gateway must accommodate the delay imposed by the IP network on the IP terminal's response to CMR.
AMRの高速モードスイッチングを実行する機能は、一部の非IPネットワークで悪用され、音声品質を最適化します。この機能をIPネットワークへのゲートウェイなどのシナリオで保存するには、コーデックモード要求（CMR）フィールドが必要です。ゲートウェイは、非IP部品とIP部品の間にCMRを両方向に転送する責任があります。IP端末は、ゲートウェイによって転送されたCMRに従って、非IPデコーダーに向かう音質の品質を最適化する必要があります。ゲートウェイのモード制御アルゴリズムは、CMRに対するIP端末の応答でIPネットワークによって課される遅延に対応する必要があります。
The IP terminal should not set the CMR (see Section 4.3.1), but the gateway can set the CMR value on frames going toward the encoder in the non-IP part to optimize speech quality from that encoder to the gateway. The gateway can alternatively set a lower CMR value, if desired, as one means to control congestion on the IP network.
IP端末はCMRを設定してはなりません（セクション4.3.1を参照）が、ゲートウェイは、そのエンコーダからゲートウェイまでの音声品質を最適化するために、非IPパーツのエンコーダーに向かってフレームにCMR値を設定できます。Gatewayは、IPネットワークの混雑を制御することを意味するため、必要に応じてより低いCMR値を設定できます。
A third likely scenario is that IP/UDP/RTP is used as transport between two non-IP systems, i.e., IP is originated and terminated in gateways on both sides of the IP transport, as illustrated in Figure 4 below.
3番目のシナリオは、IP/UDP/RTPが2つの非IPシステム間の輸送として使用されることです。つまり、IPはIPトランスポンドの両側のゲートウェイで発信され、以下の図4に示すように終了します。
AMR or AMR-WB AMR or AMR-WB
over over
I.366.{2,3} or +------+ +------+ I.366.{2,3} or
3G Iu or | | IP/UDP/RTP/AMR or | | 3G Iu or
<------------->| GW |<------------------->| GW |<------------->
GSM Abis | | IP/UDP/RTP/AMR-WB | | GSM Abis
etc. +------+ +------+ etc.
| |
GSM/ | IP network | GSM/
3GPP UMTS network | | 3GPP UMTS network
Figure 4: GW to GW scenario
図4：GWからGWへのシナリオ
This scenario requires the same mechanisms for preserving UED/UEP and CMR information as in the single gateway scenario. In addition, the CMR value may be set in packets received by the gateways on the IP network side. The gateway should forward to the non-IP side a CMR value that is the minimum of three values:
このシナリオには、単一のゲートウェイシナリオと同じように、UED/UEPおよびCMR情報を保存するための同じメカニズムが必要です。さらに、CMR値は、IPネットワーク側のゲートウェイによって受信されたパケットで設定される場合があります。ゲートウェイは、最小3つの値であるCMR値を非IP側に転送する必要があります。
- the CMR value it receives on the IP side;
- IP側で受信するCMR値。
- the CMR value it calculates based on its reception quality on the non-IP side; and
- 非IP側の受信品質に基づいて計算するCMR値。と
- a CMR value it may choose for congestion control of transmission on the IP side.
- IP側での伝送の混雑制御に選択できるCMR値。
The details of the control algorithm are left to the implementation.
コントロールアルゴリズムの詳細は、実装に残されています。
The AMR and AMR-WB payload formats have identical structure, so they are specified together. The only differences are in the types of codec frames contained in the payload. The payload format consists of the RTP header, payload header, and payload data.
AMRとAMR-WBのペイロード形式は同じ構造を備えているため、一緒に指定されています。唯一の違いは、ペイロードに含まれるコーデックフレームのタイプにあります。ペイロード形式は、RTPヘッダー、ペイロードヘッダー、ペイロードデータで構成されています。
The format of the RTP header is specified in [8]. This payload format uses the fields of the header in a manner consistent with that specification.
RTPヘッダーの形式は[8]で指定されています。このペイロード形式は、その仕様と一致する方法でヘッダーのフィールドを使用します。
The RTP timestamp corresponds to the sampling instant of the first sample encoded for the first frame-block in the packet. The timestamp clock frequency is the same as the sampling frequency, so the timestamp unit is in samples.
RTPタイムスタンプは、パケット内の最初のフレームブロックにエンコードされた最初のサンプルのサンプリングインスタントに対応します。タイムスタンプクロック周波数はサンプリング周波数と同じであるため、タイムスタンプユニットはサンプルにあります。
The duration of one speech frame-block is 20 ms for both AMR and AMR-WB. For AMR, the sampling frequency is 8 kHz, corresponding to 160 encoded speech samples per frame from each channel. For AMR-WB, the sampling frequency is 16 kHz, corresponding to 320 samples per frame from each channel. Thus, the timestamp is increased by 160 for AMR and 320 for AMR-WB for each consecutive frame-block.
1つの音声フレームブロックの期間は、AMRとAMR-WBの両方で20ミリ秒です。AMRの場合、サンプリング周波数は8 kHzで、各チャネルからフレームごとに160のエンコードされた音声サンプルに対応します。AMR-WBの場合、サンプリング周波数は16 kHzで、各チャネルのフレームごとに320サンプルに対応しています。したがって、タイムスタンプは、AMRで160、AMR-WBの場合は320増加します。
A packet may contain multiple frame-blocks of encoded speech or comfort noise parameters. If interleaving is employed, the frame-blocks encapsulated into a payload are picked according to the interleaving rules as defined in Section 4.4.1. Otherwise, each packet covers a period of one or more contiguous 20 ms frame-block intervals. In case the data from all the channels for a particular frame-block in the period is missing (for example, at a gateway from some other transport format), it is possible to indicate that no data is present for that frame-block rather than breaking a multi-frame-block packet into two, as explained in Section 4.3.2.
パケットには、エンコードされた音声またはコンフォートノイズパラメーターの複数のフレームブロックが含まれる場合があります。インターリーブを使用すると、ペイロードにカプセル化されたフレームブロックは、セクション4.4.1で定義されているように、インターリーブルールに従って選択されます。それ以外の場合、各パケットは、1つ以上の隣接する20 msのフレームブロック間隔の期間をカバーします。期間中の特定のフレームブロックのすべてのチャネルからのデータが欠落している場合（たとえば、他の輸送形式からのゲートウェイで）、そのフレームブロックのデータが存在しないことを示すことができます。セクション4.3.2で説明されているように、マルチフレームブロックパケットを2つに分割します。
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 speech frame multiple times, in exact duplicates, in different AMR rate modes, or with data present in one packet and not present in another. If multiple versions of the same speech frame are received, it is RECOMMENDED that the mode with the highest rate be used by the speech decoder. A given frame MUST NOT be encoded as speech in one packet and comfort noise parameters in another.
冗長な伝送を介してエラーの弾力性を可能にするために、複数のパケットでカバーされている期間が時間内に重複する場合があります。レシーバーは、正確な複製、異なるAMRレートモードで、またはあるパケットに存在し、別のパケットに存在しないデータを使用して、スピーチフレームを複数回受信する準備をする必要があります。同じ音声フレームの複数のバージョンが受信される場合、最高レートのモードを音声デコーダーで使用することをお勧めします。特定のフレームを、あるパケットと別のパケットノイズパラメーターでスピーチとしてエンコードしてはなりません。
The payload length is always made an integral number of octets by padding with zero bits if necessary. If additional padding is required to bring the payload length to a larger multiple of octets or for some other purpose, then the P bit in the RTP in the header may be set and padding appended as specified in [8].
ペイロードの長さは、必要に応じてゼロビットのパディングにより、常に積分数のオクテットになります。ペイロードの長さをオクテットのより大きな倍数または他の目的のために持ち込むために追加のパディングが必要な場合、[8]で指定されているように、ヘッダーのRTPのPビットを設定し、パディングが追加される場合があります。
The RTP header marker bit (M) SHALL be set to 1 if the first frame-block carried in the packet contains a speech frame which is the first in a talkspurt. For all other packets the marker bit SHALL be set to zero (M=0).
RTPヘッダーマーカービット（M）は、パケットに掲載された最初のフレームブロックに、Talkspurtで最初の音声フレームが含まれている場合、1に設定されます。他のすべてのパケットについて、マーカービットはゼロ（m = 0）に設定するものとします。
The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile under which this payload format is being used will assign a payload type for this encoding or specify that the payload type is to be bound dynamically.
この新しいパケット形式のRTPペイロードタイプの割り当ては、このドキュメントの範囲外であり、ここでは指定されません。このペイロード形式が使用されているRTPプロファイルは、このエンコードにペイロードタイプを割り当てるか、ペイロードタイプを動的にバインドすることを指定することが期待されます。
The complete payload consists of a payload header, a payload table of contents, and speech data representing one or more speech frame-blocks. The following diagram shows the general payload format layout:
完全なペイロードは、ペイロードヘッダー、内容のペイロードテーブル、および1つ以上の音声フレームブロックを表す音声データで構成されています。次の図は、一般的なペイロード形式のレイアウトを示しています。
+----------------+-------------------+----------------
| payload header | table of contents | speech data ...
+----------------+-------------------+----------------
Payloads containing more than one speech frame-block are called compound payloads.
複数の音声フレームブロックを含むペイロードは、複合ペイロードと呼ばれます。
The following sections describe the variations taken by the payload format depending on whether the AMR session is set up to use the bandwidth-efficient mode or octet-aligned mode and any of the OPTIONAL functions for robust sorting, interleaving, and frame CRCs. Implementations SHOULD support both bandwidth-efficient and octet-aligned operation to increase interoperability.
次のセクションでは、AMRセッションが帯域幅効率の高いモードまたはオクテットアラインドモードを使用するかどうかに応じて、ペイロード形式で取得されたバリエーションと、堅牢なソート、インターリーブ、フレームCRCのオプション機能について説明します。実装は、相互運用性を向上させるために、帯域幅効率の高い操作とオクテット整列操作の両方をサポートする必要があります。
In bandwidth-efficient mode, the payload header simply consists of a 4-bit codec mode request:
帯域幅効率の高いモードでは、ペイロードヘッダーは4ビットコーデックモード要求で構成されています。
0 1 2 3
+-+-+-+-+
| CMR |
+-+-+-+-+
CMR (4 bits): Indicates a codec mode request sent to the speech encoder at the site of the receiver of this payload. The value of the CMR field is set to the frame type index of the corresponding speech mode being requested. The frame type index may be 0-7 for AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined in Table 1a in [4]. CMR value 15 indicates that no mode request is present, and other values are for future use.
CMR（4ビット）：このペイロードの受信機のサイトでスピーチエンコーダーに送信されたコーデックモード要求を示します。CMRフィールドの値は、リクエストされる対応する音声モードのフレームタイプインデックスに設定されます。[2]の表1aで定義されているように、AMRのフレームタイプインデックスは0-7、または[4]の表1aで定義されているように、AMR-WBで0-8である場合があります。CMR値15は、モード要求が存在しないことを示し、その他の値は将来の使用に適しています。
The codec mode request received in the CMR field is valid until the next codec mode request is received, i.e., a newly received CMR value corresponding to a speech mode, or NO_DATA overrides the previously received CMR value corresponding to a speech mode or NO_DATA. Therefore, if a terminal continuously wishes to receive frames in the same mode X, it needs to set CMR=X for all its outbound payloads, and if a terminal has no preference in which mode to receive, it SHOULD set CMR=15 in all its outbound payloads.
CMRフィールドで受信したコーデックモード要求は、次のコーデックモード要求が受信されるまで有効です。つまり、音声モードに対応する新しく受信したCMR値、またはNO_DATAは、以前に受け取ったCMR値またはNO_DATAに対応するCMR値をオーバーライドします。したがって、端末が同じモードXでフレームを継続的に受信したい場合、すべてのアウトバウンドペイロードに対してCMR = xを設定する必要があり、端末が受信するモードを優先しない場合、CMR = 15をすべてに設定する必要があります。そのアウトバウンドペイロード。
If receiving a payload with a CMR value that is not a speech mode or NO_DATA, the CMR MUST be ignored by the receiver.
音声モードまたはNO_DATAではないCMR値でペイロードを受信する場合、CMRは受信機によって無視する必要があります。
In a multi-channel session, the codec mode request SHOULD be interpreted by the receiver of the payload as the desired encoding mode for all the channels in the session.
マルチチャネルセッションでは、セッション内のすべてのチャネルの目的のエンコードモードとして、ペイロードの受信者によってコーデックモード要求を解釈する必要があります。
An IP end-point SHOULD NOT set the codec mode request based on packet losses or other congestion indications, for several reasons:
IPエンドポイントは、いくつかの理由で、パケットの損失やその他の輻輳指示に基づいてコーデックモード要求を設定してはなりません。
- The other end of the IP path may be a gateway to a non-IP network (such as a radio link) that needs to set the CMR field to optimize performance on that network.
- IPパスのもう一方の端は、そのネットワークのパフォーマンスを最適化するためにCMRフィールドを設定する必要がある非IPネットワーク（無線リンクなど）へのゲートウェイである場合があります。
- Congestion on the IP network is managed by the IP sender, in this case, at the other end of the IP path. Feedback about congestion SHOULD be provided to that IP sender through RTCP or other means, and then the sender can choose to avoid congestion using the most appropriate mechanism. That may include adjusting the codec mode, but also includes adjusting the level of redundancy or number of frames per packet.
- IPネットワークの混雑は、IP送信者、この場合はIPパスの反対側で管理されます。RTCPまたはその他の手段を介してそのIP送信者に輻輳に関するフィードバックを提供する必要があり、その後、送信者は、最も適切なメカニズムを使用して渋滞を回避することを選択できます。これには、コーデックモードの調整が含まれる場合がありますが、パケットあたりの冗長性またはフレーム数のレベルの調整も含まれます。
The encoder SHOULD follow a received codec mode request, but MAY change to a lower-numbered mode if it so chooses, for example, to control congestion.
エンコーダは、受信したコーデックモード要求に従う必要がありますが、たとえば混雑を制御するために選択する場合は、より低い数のモードに変更される場合があります。
The CMR field MUST be set to 15 for packets sent to a multicast group. The encoder in the speech sender SHOULD ignore codec mode requests when sending speech to a multicast session but MAY use RTCP feedback information as a hint that a codec mode change is needed.
CMRフィールドは、マルチキャストグループに送信されたパケットに対して15に設定する必要があります。スピーチ送信者のエンコーダーは、スピーチをマルチキャストセッションに送信する際のコーデックモード要求を無視する必要がありますが、コーデックモードの変更が必要であることを示唆するRTCPフィードバック情報を使用する場合があります。
The codec mode selection MAY be restricted by a session parameter to a subset of the available modes. If so, the requested mode MUST be among the signalled subset (see Section 8). If the received CMR value is outside the signalled subset of modes, it MUST be ignored.
Codecモードの選択は、使用可能なモードのサブセットにセッションパラメーターによって制限される場合があります。その場合、要求されたモードは信号されたサブセットの1つでなければなりません（セクション8を参照）。受信したCMR値がモードの信号サブセットの外側にある場合、無視する必要があります。
The table of contents (ToC) consists of a list of ToC entries, each representing a speech frame.
目次（TOC）は、それぞれが音声フレームを表すTOCエントリのリストで構成されています。
In bandwidth-efficient mode, a ToC entry takes the following format:
帯域幅効率の高いモードでは、TOCエントリは次の形式を取得します。
0 1 2 3 4 5
+-+-+-+-+-+-+
|F| FT |Q|
+-+-+-+-+-+-+
F (1 bit): If set to 1, indicates that this frame is followed by another speech frame in this payload; if set to 0, indicates that this frame is the last frame in this payload.
f（1ビット）：1に設定されている場合、このフレームの後にこのペイロードに別の音声フレームが続くことを示します。0に設定すると、このフレームがこのペイロードの最後のフレームであることを示します。
FT (4 bits): Frame type index, indicating either the AMR or AMR-WB speech coding mode or comfort noise (SID) mode of the corresponding frame carried in this payload.
ft（4ビット）：フレームタイプインデックス。このペイロードで運ばれる対応するフレームのAMRまたはAMR-WBの音声コーディングモードまたはコンフォートノイズ（SID）モードを示します。
The value of FT is defined in Table 1a in [2] for AMR and in Table 1a in [4] for AMR-WB. FT=14 (SPEECH_LOST, only available for AMR-WB) and FT=15 (NO_DATA) are used to indicate frames that are either lost or not being transmitted in this payload, respectively.
FTの値は、AMRの[2]の表1AおよびAMR-WBの[4]の表1aに定義されています。ft = 14（Speech_lost、AMR-WBでのみ利用可能）およびFT = 15（NO_DATA）は、このペイロードでそれぞれ失われているか、それぞれ送信されていないフレームを示すために使用されます。
NO_DATA (FT=15) frame could mean either that no data for that frame has been produced by the speech encoder or that no data for that frame is transmitted in the current payload (i.e., valid data for that frame could be sent in either an earlier or later packet).
no_data（ft = 15）フレームは、そのフレームのデータがスピーチエンコーダーによって生成されていないこと、またはそのフレームのデータが現在のペイロードで送信されないことを意味する可能性があります（つまり、そのフレームの有効なデータはいずれかで送信できます。以前または後のパケット）。
If receiving a ToC entry with a FT value in the range 9-14 for AMR or 10-13 for AMR-WB, the whole packet SHOULD be discarded. This is to avoid the loss of data synchronization in the depacketization process, which can result in a huge degradation in speech quality.
AMRで9〜14の範囲でFT値を持つTOCエントリまたはAMR-WBで10〜13を受信する場合、パケット全体を破棄する必要があります。これは、デパケット化プロセスでのデータ同期の損失を回避するためであり、音声品質に大きな劣化をもたらす可能性があります。
Note that packets containing only NO_DATA frames SHOULD NOT be transmitted in any payload format configuration, except in the case of interleaving. Also, frame-blocks containing only NO_DATA frames at the end of a packet SHOULD NOT be transmitted in any payload format configuration, except in the case of interleaving. The AMR SCR/DTX is described in [6] and AMR-WB SCR/DTX in [7].
NO_DATAフレームのみを含むパケットは、インターリーブの場合を除き、ペイロード形式の構成で送信するべきではないことに注意してください。また、パケットの最後にNO_DATAフレームのみを含むフレームブロックは、インターリーブの場合を除き、ペイロード形式の構成で送信しないでください。AMR SCR/DTXは、[6]および[7]のAMR-WB SCR/DTXで説明されています。
The extra comfort noise frame types specified in table 1a in [2] (i.e., GSM-EFR CN, IS-641 CN, and PDC-EFR CN) MUST NOT be used in this payload format because the standardized AMR codec is only required to implement the general AMR SID frame type and not those that are native to the incorporated encodings.
[2]の表1aに指定された追加のコンフォートノイズフレームタイプ（つまり、GSM-EFR CN、IS-641 CN、およびPDC-EFR CN）で指定されたタイプは、標準化されたAMRコーデックのみが必要であるため、このペイロード形式で使用してはなりません。組み込まれたエンコーディングに固有のものではなく、一般的なAMR SIDフレームタイプを実装します。
Q (1 bit): Frame quality indicator. If set to 0, indicates the corresponding frame is severely damaged, and the receiver should set the RX_TYPE (see [6]) to either SPEECH_BAD or SID_BAD depending on the frame type (FT).
Q（1ビット）：フレーム品質インジケーター。0に設定されている場合、対応するフレームがひどく損傷していることを示し、受信機はフレームタイプ（FT）に応じてRX_TYPE（[6]を参照[6]を参照）をSpeech_BadまたはSID_BADに設定する必要があります。
The frame quality indicator is included for interoperability with the ATM payload format described in ITU-T I.366.2, the UMTS Iu interface [20], as well as other transport formats. The frame quality indicator enables damaged frames to be forwarded to the speech decoder for error concealment. This can improve the speech quality more than dropping the damaged frames. See Section 4.4.2.1 for more details.
フレーム品質インジケーターは、ITU-T I.366.2、UMTS IUインターフェイス[20]、およびその他の輸送形式で説明されているATMペイロード形式との相互運用性のために含まれています。フレーム品質インジケーターにより、損傷したフレームをエラーの隠蔽のために音声デコーダーに転送できます。これにより、損傷したフレームをドロップするよりも音質を向上させることができます。詳細については、セクション4.4.2.1を参照してください。
For multi-channel sessions, the ToC entries of all frames from a frame-block are placed in the ToC in consecutive order as defined in Section 4.1 in [12]. When multiple frame-blocks are present in a packet in bandwidth-efficient mode, they will be placed in the packet in order of their creation time.
マルチチャネルセッションの場合、フレームブロックからのすべてのフレームのTOCエントリは、[12]のセクション4.1で定義されているように、連続してTOCに配置されます。複数のフレームブロックが帯域幅効率の高いモードのパケットに存在する場合、それらは作成時間の順にパケットに配置されます。
Therefore, with N channels and K speech frame-blocks in a packet, there MUST be N*K entries in the ToC, and the first N entries will be from the first frame-block, the second N entries will be from the second frame-block, and so on.
したがって、パケットにnチャネルとk音声フレームブロックを使用すると、TOCにはn*kエントリが必要であり、最初のnエントリは最初のフレームブロックからで、2番目のnエントリは2番目のフレームからです。 - ブロックなど。
The following figure shows an example of a ToC of three entries in a single-channel session using bandwidth-efficient mode.
次の図は、帯域幅効率の高いモードを使用したシングルチャネルセッションの3つのエントリのTOCの例を示しています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| FT |Q|1| FT |Q|0| FT |Q|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Below is an example of how the ToC entries will appear in the ToC of a packet carrying three consecutive frame-blocks in a session with two channels (L and R).
以下は、2つのチャネル（LとR）を使用したセッションで3つの連続したフレームブロックを運ぶパケットのTOCにTOCエントリがどのように表示されるかの例です。
+----+----+----+----+----+----+
| 1L | 1R | 2L | 2R | 3L | 3R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 1 Block 2 Block 3
Speech data of a payload contains zero or more speech frames or comfort noise frames, as described in the ToC of the payload.
ペイロードの音声データには、ペイロードのTOCで説明されているように、ゼロ以上の音声フレームまたはコンフォートノイズフレームが含まれています。
Note, for ToC entries with FT=14 or 15, there will be no corresponding speech frame present in the speech data.
注、FT = 14または15のTOCエントリの場合、音声データに対応する音声フレームは存在しません。
Each speech frame represents 20 ms of speech encoded with the mode indicated in the FT field of the corresponding ToC entry. The length of the speech frame is implicitly defined by the mode indicated in the FT field. The order and numbering notation of the bits are as specified for Interface Format 1 (IF1) in [2] for AMR and [4] for AMR-WB. As specified there, the bits of speech frames have been rearranged in order of decreasing sensitivity, while the bits of comfort noise frames are in the order produced by the encoder. The resulting bit sequence for a frame of length K bits is denoted d(0), d(1), ..., d(K-1).
各音声フレームは、対応するTOCエントリのFTフィールドに示されたモードでエンコードされた20 msの音声を表します。音声フレームの長さは、FTフィールドに示されているモードによって暗黙的に定義されます。BITの順序と番号付け表記は、AMRの[2]およびAMR-WBの[2]のインターフェイス形式1（IF1）で指定されています。そこに指定されているように、音声フレームのビットは感度を低下させる順に再配置されていますが、コンフォートノイズフレームのビットはエンコーダーによって生成されます。長さkビットのフレームの結果のビットシーケンスは、d（0）、d（1）、...、d（k-1）と示されます。
The complete RTP payload in bandwidth-efficient mode is formed by packing bits from the payload header, table of contents, and speech frames in order (as defined by their corresponding ToC entries in the ToC list), and to bring the payload to octet alignment, 0 to 7 padding bits. Padding bits MUST be set to zero and MUST be ignored on reception. They are packed contiguously into octets beginning with the most significant bits of the fields and the octets.
帯域幅効率の高いモードでの完全なRTPペイロードは、ペイロードヘッダー、目次、および音声フレームからビットを順に詰め込んで（TOCリストに対応するTOCエントリで定義されています）、オクテットアライメントにペイロードを提供することによって形成されます。、0〜7のパディングビット。パディングビットはゼロに設定する必要があり、受信時に無視する必要があります。それらは、フィールドとオクテットの最も重要なビットから始まるオクテットに連続で詰め込まれています。
To be precise, the four-bit payload header is packed into the first octet of the payload with bit 0 of the payload header in the most significant bit of the octet. The four most significant bits (numbered 0-3) of the first ToC entry are packed into the least significant bits of the octet, ending with bit 3 in the least significant bit. Packing continues in the second octet with bit 4 of the first ToC entry in the most significant bit of the octet. If more than one frame is contained in the payload, then packing continues with the second and successive ToC entries. Bit 0 of the first data frame follows immediately after the last ToC bit, proceeding through all the bits of the frame in numerical order. Bits from any successive frames follow contiguously in numerical order for each frame and in consecutive order of the frames.
正確には、4ビットペイロードヘッダーは、ペイロードヘッダーのビット0がオクテットの最も重要なビットで、ペイロードの最初のオクテットに詰め込まれます。最初のTOCエントリの4つの最も重要なビット（番号0〜3）は、オクテットの最も重要なビットに詰め込まれ、ビット3で最も重要なビットで終了します。2番目のオクテットでは、最初のTOCエントリのビット4がオクテットの最も重要なビットで続きます。ペイロードに複数のフレームが含まれている場合、パッキングは2番目の連続したTOCエントリで続きます。最初のデータフレームのビット0は、最後のTOCビットの直後に続き、フレームのすべてのビットを数値的に進みます。連続したフレームからのビットは、各フレームの数値的順序で、フレームの連続した順序で連続的に続きます。
If speech data is missing for one or more speech frame within the sequence, because of, for example, DTX, a ToC entry with FT set to NO_DATA SHALL be included in the ToC for each of the missing frames, but no data bits are included in the payload for the missing frame (see Section 4.3.5.2 for an example).
シーケンス内の1つ以上の音声フレームに対してスピーチデータが欠落している場合、たとえばDTXのために、FTをno_Dataに設定したTOCエントリは、欠落している各フレームのTOCに含まれますが、データビットは含まれていません。欠落しているフレームのペイロードで（例についてはセクション4.3.5.2を参照）。
The following diagram shows a bandwidth-efficient AMR payload from a single-channel session carrying a single speech frame-block.
次の図は、単一の音声フレームブロックを運ぶシングルチャネルセッションからの帯域幅効率の高いAMRペイロードを示しています。
In the payload, no specific mode is requested (CMR=15), the speech frame is not damaged at the IP origin (Q=1), and the coding mode is AMR 7.4 kbps (FT=4). The encoded speech bits, d(0) to d(147), are arranged in descending sensitivity order according to [2]. Finally, two padding bits (P) are added to the end as padding to make the payload octet aligned.
ペイロードでは、特定のモードが要求されません（CMR = 15）、音声フレームはIP原点で損傷しません（Q = 1）、コーディングモードはAMR 7.4 kbps（ft = 4）です。エンコードされた音声ビット、D（0）からD（147）は、[2]に従って降順の感度順序で配置されます。最後に、ペイロードのオクテットを揃えるために、2つのパディングビット（P）がパディングとして端に追加されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CMR=15|0| FT=4 |1|d(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(147)|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following diagram shows a single-channel, bandwidth-efficient compound AMR-WB payload that contains four frames, of which one has no speech data. The first frame is a speech frame at 6.6 kbps mode (FT=0) that is composed of speech bits d(0) to d(131). The second frame is an AMR-WB SID frame (FT=9), consisting of bits g(0) to g(39). The third frame is a NO_DATA frame and does not carry any speech information, it is represented in the payload by its ToC entry. The fourth frame in the payload is a speech frame at 8.85 kbps mode (FT=1), it consists of speech bits h(0) to h(176).
次の図は、4つのフレームを含むシングルチャネル、帯域幅効率の高いコンパウンドAMR-WBペイロードを示していますが、そのうち1つは音声データがありません。最初のフレームは、音声ビットd（0）からd（131）で構成される6.6 kbpsモード（ft = 0）の音声フレームです。2番目のフレームは、AMR-WB SIDフレーム（ft = 9）で、ビットg（0）からg（39）で構成されています。3番目のフレームはNO_DATAフレームであり、音声情報を掲載していません。TOCエントリによってペイロードで表されます。ペイロードの4番目のフレームは、8.85 kbpsモード（ft = 1）の音声フレームで、音声ビットh（0）からH（176）で構成されています。
As shown below, the payload carries a mode request for the encoder on the receiver's side to change its future coding mode to AMR-WB 8.85 kbps (CMR=1). None of the frames are damaged at IP origin (Q=1). The encoded speech and SID bits, d(0) to d(131), g(0) to g(39), and h(0) to h(176), are arranged in the payload in descending sensitivity order according to [4]. (Note, no speech bits are present for the third frame.) Finally, seven zero bits are padded to the end to make the payload octet aligned.
以下に示すように、ペイロードには、レシーバー側のエンコーダーのモード要求が搭載され、将来のコーディングモードがAMR-WB 8.85 kbps（CMR = 1）に変更されます。IP起源で損傷しているフレームはありません（Q = 1）。エンコードされた音声およびSIDビット、D（0）からD（131）、G（0）からG（39）、およびH（0）からH（176）は、[[[]に従って下降感度の順序でペイロードに配置されます。4]。（3番目のフレームには音声ビットは存在しません。）最後に、ペイロードのオクテットを整列させるために、7つのゼロビットが端にパッドでパッドされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CMR=1 |1| FT=0 |1|1| FT=9 |1|1| FT=15 |1|0| FT=1 |1|d(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(131)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|g(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| g(39)|h(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h(176)|P|P|P|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following diagram shows a two-channel payload carrying 3 frame-blocks, i.e., the payload will contain 6 speech frames.
次の図は、3つのフレームブロックを運ぶ2チャンネルペイロードを示しています。つまり、ペイロードには6つの音声フレームが含まれています。
In the payload, all speech frames contain the same mode 7.4 kbps (FT=4) and are not damaged at IP origin. The CMR is set to 15, i.e., no specific mode is requested. The two channels are defined as left (L) and right (R) in that order. The encoded speech bits is designated dXY(0).. dXY(K-1), where X = block number, Y = channel, and K is the number of speech bits for that mode. Exemplifying this, for frame-block 1 of the left channel, the encoded bits are designated as d1L(0) to d1L(147).
ペイロードでは、すべての音声フレームには同じモード7.4 kbps（ft = 4）が含まれており、IP原点では損傷していません。CMRは15に設定されています。つまり、特定のモードは要求されません。2つのチャネルは、その順序で左（L）および右（R）として定義されます。エンコードされた音声ビットは、DXY（0）.. DXY（K-1）と指定されています。ここで、x =ブロック数、y =チャネル、kはそのモードの音声ビット数です。これを例示して、左チャネルのフレームブロック1の場合、エンコードされたビットはD1L（0）からD1L（147）として指定されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CMR=15|1|1L FT=4|1|1|1R FT=4|1|1|2L FT=4|1|1|2R FT=4|1|1|3L FT|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|4|1|0|3R FT=4|1|d1L(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d1L(147)|d1R(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d1R(147)|d2L(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|d2L(147|d2R(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d2R(147)|d3L(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d3L(147)|d3R(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d3R(147)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In octet-aligned mode, the payload header consists of a 4-bit CMR, 4 reserved bits, and optionally, an 8-bit interleaving header, as shown below:
Octetに合わせたモードでは、ペイロードヘッダーは4ビットCMR、4つの予約ビット、およびオプションで、以下に示すように8ビットインターリーブヘッダーで構成されています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+- - - - - - - -
| CMR |R|R|R|R| ILL | ILP |
+-+-+-+-+-+-+-+-+- - - - - - - -
CMR (4 bits): same as defined in Section 4.3.1.
CMR（4ビット）：セクション4.3.1で定義されているのと同じ。
R: is a reserved bit that MUST be set to zero. All R bits MUST be ignored by the receiver.
R：ゼロに設定する必要がある予約ビットです。すべてのRビットは、受信機によって無視する必要があります。
ILL (4 bits, unsigned integer): This is an OPTIONAL field that is present only if interleaving is signalled out-of-band for the session. ILL=L indicates to the receiver that the interleaving length is L+1, in number of frame-blocks.
Ill（4ビット、署名されていない整数）：これは、セッションの帯域外にインターリーブが合図されている場合にのみ存在するオプションのフィールドです。Ill = lは、フレームブロックの数において、インテリアの長さがL 1であることをレシーバーに示します。
ILP (4 bits, unsigned integer): This is an OPTIONAL field that is present only if interleaving is signalled. ILP MUST take a value between 0 and ILL, inclusive, indicating the interleaving index for frame-blocks in this payload in the interleaving group. If the value of ILP is found greater than ILL, the payload SHOULD be discarded.
ILP（4ビット、署名されていない整数）：これは、インターリーブがシグナルがある場合にのみ存在するオプションのフィールドです。ILPは、0からILLの間の値を取得し、包括的で、インテリアグループのこのペイロードのフレームブロックのインターリーブインデックスを示している必要があります。ILPの値が病気よりも大きい場合は、ペイロードを破棄する必要があります。
ILL and ILP fields MUST be present in each packet in a session if interleaving is signalled for the session. Interleaving MUST be performed on a frame-block basis (i.e., NOT on a frame basis) in a multi-channel session.
セッションにインターリーブが通知されている場合、セッションの各パケットにILLおよびILPフィールドが存在する必要があります。インターリーブは、マルチチャネルセッションでフレームブロックベース（つまり、フレームベースではない）で実行する必要があります。
The following example illustrates the arrangement of speech frame-
blocks in an interleaving group during an interleaving session. Here
we assume ILL=L for the interleaving group that starts at speech
frame-block n. We also assume that the first payload packet of the
interleaving group is s, and the number of speech frame-blocks
carried in each payload is N. Then we will have:
Payload s (the first packet of this interleaving group):
ILL=L, ILP=0,
Carry frame-blocks: n, n+(L+1), n+2*(L+1), ..., n+(N-1)*(L+1)
Payload s+1 (the second packet of this interleaving group):
ILL=L, ILP=1,
frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1), ..., n+1+(N-1)*(L+1)
...
Payload s+L (the last packet of this interleaving group):
ILL=L, ILP=L,
frame-blocks: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+(N-1)*(L+1)
The next interleaving group will start at frame-block n+N*(L+1).
次のインターリービンググループは、フレームブロックn n*（l 1）から始まります。
There will be no interleaving effect unless the number of frame-blocks per packet (N) is at least 2. Moreover, the number of frame-blocks per payload (N) and the value of ILL MUST NOT be changed inside an interleaving group. In other words, all payloads in an interleaving group MUST have the same ILL and MUST contain the same number of speech frame-blocks.
パケットあたりのフレームブロックの数（n）が少なくとも2でない限り、インターリーブ効果はありません。さらに、ペイロードあたりのフレームブロックの数（n）とILLの値をインターリーブグループ内で変更してはなりません。言い換えれば、インテリアグループ内のすべてのペイロードは同じ病気を患っている必要があり、同じ数の音声フレームブロックが含まれている必要があります。
The sender of the payload MUST only apply interleaving if the receiver has signalled its use through out-of-band means. Since interleaving will increase buffering requirements at the receiver, the receiver uses media type parameter "interleaving=I" to set the maximum number of frame-blocks allowed in an interleaving group to I.
ペイロードの送信者は、受信機が帯域外の手段を通じて使用を合図した場合にのみインターリーブを適用する必要があります。インターリーブは受信機でバッファリング要件を増加させるため、受信機はメディアタイプパラメーター「インターリーブ= I」を使用して、インターリーブグループで許可されているフレームブロックの最大数をIに設定します。
When performing interleaving, the sender MUST use a proper number of frame-blocks per payload (N) and ILL so that the resulting size of an interleaving group is less or equal to I, that is, N*(L+1)<=I.
インターリーブを実行する場合、送信者は、ペイロードあたりの適切な数のフレームブロック（n）を使用する必要があります。そのため、インターリーブグループの結果のサイズがiに劣るか等しくなります。つまり、n*（l 1）<= i。
The table of contents (ToC) in octet-aligned mode consists of a list of ToC entries where each entry corresponds to a speech frame carried in the payload and, optionally, a list of speech frame CRCs. That is, the ToC is as follows:
Octet-Alignedモードの目次（TOC）は、各エントリがペイロードに掲載された音声フレームに対応するTOCエントリのリストと、オプションではスピーチフレームCRCのリストで構成されています。つまり、TOCは次のとおりです。
+---------------------+
| list of ToC entries |
+---------------------+
| list of frame CRCs | (optional)
- - - - - - - - - - -
Note, for ToC entries with FT=14 or 15, there will be no corresponding speech frame or frame CRC present in the payload.
注、FT = 14または15のTOCエントリの場合、ペイロードに存在する対応する音声フレームまたはフレームCRCはありません。
The list of ToC entries is organized in the same way as described for bandwidth-efficient mode in 4.3.2, with the following exception: when interleaving is used, the frame-blocks in the ToC will almost never be placed consecutively in time. Instead, the presence and order of the frame-blocks in a packet will follow the pattern described in 4.4.1.
TOCエントリのリストは、4.3.2の帯域幅効率の高いモードで説明されているのと同じ方法で編成されています。次の例外を除きます。インターリーブを使用する場合、TOCのフレームブロックはほとんど連続して配置されることはありません。代わりに、パケット内のフレームブロックの存在と順序は、4.4.1で説明されているパターンに従います。
The following example shows the ToC of three consecutive packets, each carrying three frame-blocks, in an interleaved two-channel session. Here, the two channels are left (L) and right (R) with L coming before R, and the interleaving length is 3 (i.e., ILL=2). This results in the interleaving group size of 9 frame-blocks.
次の例は、3つの連続したパケットのTOCを示しています。各パケットは、インターリーブ2チャンネルセッションで3つのフレームブロックを搭載しています。ここでは、2つのチャネルが残っている（l）と右（r）がrの前にlが来ており、インターリーブの長さは3（つまり、ill = 2）です。これにより、9つのフレームブロックのインターリーブグループサイズが生成されます。
Packet #1
---------
ILL=2, ILP=0:
+----+----+----+----+----+----+
| 1L | 1R | 4L | 4R | 7L | 7R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 1 Block 4 Block 7
Packet #2
---------
ILL=2, ILP=1:
+----+----+----+----+----+----+
| 2L | 2R | 5L | 5R | 8L | 8R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 2 Block 5 Block 8
Packet #3
---------
ILL=2, ILP=2:
+----+----+----+----+----+----+
| 3L | 3R | 6L | 6R | 9L | 9R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 3 Block 6 Block 9
A ToC entry takes the following format in octet-aligned mode:
TOCエントリは、Octet-Alignedモードで次の形式を取得します。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |Q|P|P|
+-+-+-+-+-+-+-+-+
F (1 bit): see definition in Section 4.3.2.
F（1ビット）：セクション4.3.2の定義を参照してください。
FT (4 bits, unsigned integer): see definition in Section 4.3.2.
ft（4ビット、署名されていない整数）：セクション4.3.2の定義を参照してください。
Q (1 bit): see definition in Section 4.3.2.
Q（1ビット）：セクション4.3.2の定義を参照してください。
P bits: padding bits, MUST be set to zero, and MUST be ignored on reception.
Pビット：パディングビット、ゼロに設定する必要があり、受信で無視する必要があります。
The list of CRCs is OPTIONAL. It only exists if the use of CRC is signalled out-of-band for the session. When present, each CRC in the list is 8 bits long and corresponds to a speech frame (NOT a frame-block) carried in the payload. Calculation and use of the CRC is specified in the next section.
CRCのリストはオプションです。CRCの使用がセッションで帯域外に合図されている場合にのみ存在します。存在する場合、リスト内の各CRCは長さ8ビットで、ペイロードに掲載された音声フレーム（フレームブロックではない）に対応します。CRCの計算と使用は、次のセクションで指定されています。
The general concept of UED/UEP over IP is discussed in Section 3.6. This section provides more details on how to use the frame CRC in the octet-aligned payload header together with a partial transport layer checksum to achieve UED.
IP上のUED/UEPの一般的な概念については、セクション3.6で説明します。このセクションでは、Octetに配置されたペイロードヘッダーでフレームCRCを使用して部分的な輸送層チェックサムを使用してUEDを達成する方法の詳細について説明します。
To achieve UED, one SHOULD use a transport layer checksum (for example, the one defined in UDP-Lite [19]) to protect the IP, transport protocol (e.g., UDP-Lite), and RTP headers, as well as the payload header and the table of contents in the payload. The frame CRC, when used, MUST be calculated only over all class A bits in the AMR or AMR-WB frame. Class B and C bits in the AMR or AMR-WB frame MUST NOT be included in the CRC calculation and SHOULD NOT be covered by the transport checksum.
UEDを達成するには、IP、トランスポートプロトコル（UDP-Liteなど）、RTPヘッダー、およびペイロードを保護するために、トランスポートレイヤーチェックサム（UDP-Lite [19]で定義されているもの）を使用する必要があります。ペイロード内のヘッダーと目次。フレームCRCは、使用する場合、AMRまたはAMR-WBフレームのすべてのクラスAビットでのみ計算する必要があります。AMRまたはAMR-WBフレームのクラスBおよびCビットをCRC計算に含めてはならず、輸送チェックサムでカバーするべきではありません。
Note, the number of class A bits for various coding modes in AMR codec is specified as informative in [2] and is therefore copied into Table 1 in Section 3.6 to make it normative for this payload format. The number of class A bits for various coding modes in AMR-WB codec is specified as normative in Table 2 in [4], and the SID frame (FT=9) has 40 class A bits. These definitions of class A bits MUST be used for this payload format.
AMRコーデックのさまざまなコーディングモードのクラスAビットの数は、[2]で有益であると指定されているため、セクション3.6の表1にコピーされて、このペイロード形式の規範を作成します。AMR-WBコーデックのさまざまなコーディングモードのクラスAビットの数は、[4]の表2で規範として指定されており、SIDフレーム（FT = 9）には40のクラスAビットがあります。クラスAビットのこれらの定義は、このペイロード形式に使用する必要があります。
If the transport layer checksum or link layer checksum detects any errors within the protected (sensitive) part, it is assumed that the complete packet will be discarded as defined by UDP-Lite [19].
トランスポートレイヤーチェックサムまたはリンクレイヤーチェックサムが保護された（敏感な）部分内のエラーを検出する場合、完全なパケットがUDP-Lite [19]で定義されているように破棄されると想定されます。
The receiver of the payload SHOULD examine the data integrity of the received class A bits by re-calculating the CRC over the received class A bits and comparing the result to the value found in the received payload header. If the two values mismatch, the receiver SHALL consider the class A bits in the receiver frame damaged and MUST clear the Q flag of the frame (i.e., set it to 0). This will subsequently cause the frame to be marked as SPEECH_BAD, if the FT of the frame is 0..7 for AMR or 0..8 for AMR-WB, or SID_BAD if the FT of the frame is 8 for AMR or 9 for AMR-WB, before it is passed to the speech decoder. See [6] and [7] more details.
ペイロードの受信者は、受信したクラスAビットでCRCを再計算し、結果を受信したペイロードヘッダーで見つかった値と比較することにより、受信したクラスAビットのデータの整合性を調べる必要があります。2つの値が不一致の場合、受信機はレシーバーフレームのクラスAビットが損傷していることを考慮し、フレームのQフラグをクリアする必要があります（つまり、0に設定します）。これにより、フレームのftがAMRで0.7またはAMR-WBで0..8、またはSID_BADの場合、フレームのftが0..7の場合、フレームをspeech_badとしてマークします。AMR-WB、音声デコーダーに渡される前。[6]および[7]の詳細を参照してください。
The following example shows an octet-aligned ToC with a CRC list for a payload containing 3 speech frames from a single-channel session (assuming none of the FTs is equal to 14 or 15):
次の例は、シングルチャネルセッションの3つの音声フレームを含むペイロードのCRCリストを備えたOctetに並べられたTOCを示しています（FTSのいずれも14または15に等しいと仮定）：
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| FT#1 |Q|P|P|1| FT#2 |Q|P|P|0| FT#3 |Q|P|P| CRC#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC#2 | CRC#3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each of the CRCs takes 8 bits
各CRCには8ビットがかかります
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| c0| c1| c2| c3| c4| c5| c6| c7|
+---+---+---+---+---+---+---+---+
(MSB) (LSB)
and is calculated by the cyclic generator polynomial,
環状発電機多項式によって計算されます、
C(x) = 1 + x^2 + x^3 + x^4 + x^8
where ^ is the exponentiation operator.
ここで、 ^は指数オペレーターです。
In binary form, the polynomial appears as follows: 101110001 (MSB..LSB).
バイナリ形式では、多項式は次のように表示されます：101110001（MSB..LSB）。
The actual calculation of the CRC is made as follows: First, an 8-bit CRC register is reset to zero: 00000000. For each bit over which the CRC shall be calculated, an XOR operation is made between the rightmost (LSB) bit of the CRC register and the bit. The CRC register is then right-shifted one step (each bit's significance is reduced by one), inputting a "0" as the leftmost bit (MSB). If the result of the XOR operation mentioned above is a "1", then "10111000" is bit-wise XOR-ed into the CRC register. This operation is repeated for each bit that the CRC should cover. In this case, the first bit would be d(0) for the speech frame for which the CRC should cover. When the last bit (e.g., d(54) for AMR 5.9 according to Table 1 in Section 3.6) has been used in this CRC calculation, the contents in CRC register should simply be copied to the corresponding field in the list of CRCs.
CRCの実際の計算は次のように作成されます。最初に、8ビットCRCレジスタはゼロにリセットされます：00000000。CRCレジスタとビット。その後、CRCレジスタは1つのステップ（各ビットの重要性が1つずつ減少します）を右シフトし、「0」を左のビット（MSB）として入力します。上記のXOR操作の結果が「1」である場合、「101111000」はCRCレジスタに少しxor-edです。この操作は、CRCがカバーするビットごとに繰り返されます。この場合、最初のビットは、CRCがカバーする音声フレームのD（0）です。このCRC計算で最後のビット（例：AMR 5.9のD（54））が使用されている場合、CRCレジスタの内容は、CRCのリストの対応するフィールドに単純にコピーする必要があります。
Fast calculation of the CRC on a general-purpose CPU is possible using a table-driven algorithm.
汎用CPUでのCRCの高速計算は、テーブル駆動型アルゴリズムを使用して可能です。
In octet-aligned mode, speech data is carried in a similar way to that in the bandwidth-efficient mode as discussed in Section 4.3.3, with the following exceptions:
Octetに合わせたモードでは、セクション4.3.3で説明したように、次の例外を除いて、音声データは帯域幅効率の高いモードと同様の方法で運ばれます。
- The last octet of each speech frame MUST be padded with zero bits at the end if all bits in the octet are not used. The padding bits MUST be ignored on reception. In other words, each speech frame MUST be octet-aligned.
- オクテットのすべてのビットが使用されない場合、各音声フレームの最後のオクテットは、最後にゼロビットでパッドでパッドで入れる必要があります。パディングビットはレセプションで無視する必要があります。言い換えれば、各音声フレームはオクテットに整列する必要があります。
- When multiple speech frames are present in the speech data (i.e., compound payload), the speech frames are arranged either one whole frame after another as usual, or with the octets of all frames interleaved together at the octet level, depending on the media type parameters negotiated for the payload type. Since the bits within each frame are ordered with the most error-sensitive bits first, interleaving the octets collects those sensitive bits from all frames to be nearer the beginning of the packet. This is called "robust sorting order" which allows the application of UED (such as UDP-Lite [19]) or UEP (such as the ULP [22]) mechanisms to the payload data. The details of assembling the payload are given in the next section.
- スピーチデータ（つまり、複合ペイロード）に複数の音声フレームが存在する場合、音声フレームは、メディアタイプに応じて、オクテットレベルですべてのフレームのオクテットを通常どおり、次々と次々と整理します。ペイロードタイプについて交渉されたパラメーター。各フレーム内のビットは最初に最もエラーに敏感なビットで順序付けられるため、オクテットをインターリーして、すべてのフレームからこれらの敏感なビットを収集して、パケットの開始に近づきます。これは、ペイロードデータへのUED（UDP-Lite [19]など）またはUEP（ULP [22]など）のメカニズムを適用できるようにする「堅牢な並べ替え順序」と呼ばれます。ペイロードの組み立ての詳細については、次のセクションに記載されています。
The use of robust sorting order for a payload type MUST be agreed via out-of-band means. Section 8 specifies a media type parameter for this purpose.
ペイロードタイプに堅牢な並べ替え順序の使用は、帯域外の手段を介して合意する必要があります。セクション8は、この目的のメディアタイプパラメーターを指定しています。
Note, robust sorting order MUST only be performed on the frame level and thus is independent of interleaving, which is at the frame-block level, as described in Section 4.4.1. In other words, robust sorting can be applied to either non-interleaved or interleaved payload types.
注意するには、堅牢なソート順序はフレームレベルでのみ実行する必要があるため、セクション4.4.1で説明されているように、フレームブロックレベルのインターリーブとは無関係です。言い換えれば、堅牢なソートは、非インテリアまたはインターリーブペイロードタイプのいずれかに適用できます。
Two different packetization methods, namely, normal order and robust sorting order, exist for forming a payload in octet-aligned mode. In both cases, the payload header and table of contents are packed into the payload the same way; the difference is in the packing of the speech frames.
2つの異なるパケット化方法、すなわち、通常の順序と堅牢なソート順序は、オクテットアリードモードでペイロードを形成するために存在します。どちらの場合も、ペイロードヘッダーと目次は同じ方法でペイロードに詰め込まれます。違いは、音声フレームの梱包にあります。
The payload begins with the payload header of one octet, or two octets if frame interleaving is selected. The payload header is followed by the table of contents consisting of a list of one-octet ToC entries. If frame CRCs are to be included, they follow the table of contents with one 8-bit CRC filling each octet. Note that if a given frame has a ToC entry with FT=14 or 15, there will be no CRC present.
ペイロードは、1つのオクテットのペイロードヘッダー、またはフレームインターリーブが選択されている場合は2オクテットで始まります。ペイロードヘッダーの後に、1オクテットのTOCエントリのリストで構成される目次が続きます。フレームCRCが含まれる場合、各オクテットを1つの8ビットCRC塗りつぶしで目次に従います。特定のフレームにFT = 14または15のTOCエントリがある場合、CRCが存在しないことに注意してください。
The speech data follows the table of contents, or the CRCs if present. For packetization in the normal order, all of the octets comprising a speech frame are appended to the payload as a unit. The speech frames are packed in the same order as their corresponding ToC entries are arranged in the ToC list, with the exception that if a given frame has a ToC entry with FT=14 or 15, there will be no data octets present for that frame.
音声データは、目次、または存在する場合はCRCに従います。通常の順序でのパケット化のために、音声フレームを含むすべてのオクテットは、ユニットとしてペイロードに追加されます。スピーチフレームは、対応するTOCエントリがTOCリストに配置されているのと同じ順序で梱包されています。。
For packetization in robust sorting order, the octets of all speech frames are interleaved together at the octet level. That is, the data portion of the payload begins with the first octet of the first frame, followed by the first octet of the second frame, then the first octet of the third frame, and so on. After the first octet of the last frame has been appended, the cycle repeats with the second octet of each frame. The process continues for as many octets as are present in the longest frame. If the frames are not all the same octet length, a shorter frame is skipped once all octets in it have been appended. The order of the frames in the cycle will be sequential if frame interleaving is not in use, or according to the interleave pattern specified in the payload header if frame interleaving is in use. Note that if a given frame has a ToC entry with FT=14 or 15, there will be no data octets present for that frame, so it is skipped in the robust sorting cycle.
堅牢なソート順序でのパケット化のために、すべての音声フレームのオクテットは、オクテットレベルで一緒にインターリーブされます。つまり、ペイロードのデータ部分は、最初のフレームの最初のオクテットから始まり、2番目のフレームの最初のオクテット、次に3番目のフレームの最初のオクテットなどが続きます。最後のフレームの最初のオクテットが追加された後、各フレームの2番目のオクテットでサイクルが繰り返されます。このプロセスは、最も長いフレームに存在するのと同じくらい多くのオクテットで継続されます。フレームがすべて同じオクテットの長さではない場合、その中のすべてのオクテットが追加されると、より短いフレームがスキップされます。サイクル内のフレームの順序は、フレームインターリーブが使用されていない場合、またはフレームインターリーブが使用されている場合はペイロードヘッダーで指定されたリーブパターンに従って順番になります。特定のフレームにFT = 14または15のTOCエントリがある場合、そのフレームにはデータが存在しないため、堅牢なソートサイクルでスキップされることに注意してください。
The UED and/or UEP is RECOMMENDED to cover at least the RTP header, payload header, table of contents, and class A bits of a sorted payload. Exactly how many octets need to be covered depends on the network and application. If CRCs are used together with robust sorting, only the RTP header, the payload header, and the ToC SHOULD be covered by UED/UEP. The means for communicating the number of octets to be covered to other layers performing UED/UEP is beyond the scope of this specification.
UEDおよび/またはUEPは、少なくともRTPヘッダー、ペイロードヘッダー、目次、およびソートされたペイロードのクラスビットをカバーすることをお勧めします。ネットワークとアプリケーションによって、正確にいくつのオクテットをカバーする必要がありますか。CRCが堅牢なソートと一緒に使用される場合、RTPヘッダー、ペイロードヘッダー、およびTOCのみをUED/UEPでカバーする必要があります。UED/UEPを実行する他のレイヤーにカバーされるオクテットの数を通信する手段は、この仕様の範囲を超えています。
The following diagram shows an octet aligned payload from a single channel payload type that carries two AMR frames of 7.95 kbps coding mode (FT=5). In the payload, a codec mode request is sent (CMR=6), requesting the encoder at the receiver's side to use AMR 10.2 kbps coding mode. No frame CRC, interleaving, or robust sorting is in use.
次の図は、7.95 kbpsコーディングモード（ft = 5）の2つのAMRフレームを搭載した単一チャネルペイロードタイプからのオクテットアライメントペイロードを示しています。ペイロードでは、コーデックモード要求が送信され（CMR = 6）、レシーバー側のエンコーダーがAMR 10.2 kbpsコーディングモードを使用するように要求します。フレームCRC、インターリーブ、または堅牢なソートは使用されていません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CMR=6 |R|R|R|R|1|FT#1=5 |Q|P|P|0|FT#2=5 |Q|P|P| f1(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f1(8..15) | f1(16..23) | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |f1(152..158) |P| f2(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f2(8..15) | f2(16..23) | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |f2(152..158) |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note, in the above example, the last octet in both speech frames is padded with one zero bit to make it octet-aligned.
上記の例では、両方のスピーチフレームの最後のオクテットに1つのゼロビットがパッドで詰め込まれて、オクテットアライメントにします。
This example shows an octet aligned payload from a two-channel payload type. Two frame-blocks, each containing two speech frames of 7.95 kbps coding mode (FT=5), are carried in this payload.
この例は、2チャンネルペイロードタイプからのオクテットアラインドペイロードを示しています。7.95 kbpsコーディングモード（ft = 5）の2つの音声フレームを含む2つのフレームブロックが、このペイロードに掲載されています。
The two channels are left (L) and right (R) with L coming before R. In the payload, a codec mode request is also sent (CMR=6), requesting the encoder at the receiver's side to use AMR 10.2 kbps coding mode.
2つのチャンネルは、lの前に右（l）と右（r）が残っています。。
Moreover, frame CRC, robust sorting, and frame-block interleaving are all enabled for the payload type. The interleaving length is 2 (ILL=1), and this payload is the first one in an interleaving group (ILP=0).
さらに、フレームCRC、堅牢なソート、およびフレームブロックインターリーブがすべてペイロードタイプに有効になっています。インターリーブの長さは2（ill = 1）であり、このペイロードはインターリーブグループ（ILP = 0）で最初のものです。
The first two frames in the payload are the L and R channel speech frames of frame-block #1, consisting of bits f1L(0..158) and f1R(0..158), respectively. The next two frames are the L and R channel frames of frame-block #3, consisting of bits f3L(0..158) and f3R(0..158), respectively, due to interleaving. For each of the four speech frames, a CRC is calculated as CRC1L(0..7), CRC1R(0..7), CRC3L(0..7), and CRC3R(0..7), respectively. Finally, the payload is robust sorted.
ペイロードの最初の2つのフレームは、それぞれビットF1L（0..158）とF1R（0..158）で構成されるフレームブロック＃1のLおよびRチャネル音声フレームです。次の2つのフレームは、インターリーブにより、それぞれビットF3L（0..158）とF3R（0..158）で構成されるフレームブロック＃3のLおよびRチャネルフレームです。4つの音声フレームのそれぞれについて、CRCはそれぞれCRC1L（0..7）、CRC1R（0..7）、CRC3L（0..7）、およびCRC3R（0..7）として計算されます。最後に、ペイロードはロバストソートされています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CMR=6 |R|R|R|R| ILL=1 | ILP=0 |1|FT#1L=5|Q|P|P|1|FT#1R=5|Q|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|FT#3L=5|Q|P|P|0|FT#3R=5|Q|P|P| CRC1L | CRC1R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC3L | CRC3R | f1L(0..7) | f1R(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f3L(0..7) | f3R(0..7) | f1L(8..15) | f1R(8..15) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f3L(8..15) | f3R(8..15) | f1L(16..23) | f1R(16..23) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f3L(144..151) | f3R(144..151) |f1L(152..158)|P|f1R(152..158)|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|f3L(152..158)|P|f3R(152..158)|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note, in the above example, the last octet in all four speech frames is padded with one zero bit to make it octet-aligned.
上記の例では、4つのスピーチフレームすべての最後のオクテットに1つのゼロビットがパッドで詰め込まれて、オクテットに合わせます。
An application implementing this payload format MUST understand all the payload parameters in the out-of-band signaling used. For example, if an application uses SDP, all the SDP and media type parameters in this document MUST be understood. This requirement ensures that an implementation always can decide if it is capable or not of communicating.
このペイロード形式を実装するアプリケーションは、使用される帯域外シグナリングのすべてのペイロードパラメーターを理解する必要があります。たとえば、アプリケーションがSDPを使用する場合、このドキュメントのすべてのSDPおよびメディアタイプのパラメーターを理解する必要があります。この要件により、実装が常に通信することができるかどうかを常に決定できるようになります。
No operating mode of the payload format is mandatory to implement. The requirements of the application using the payload format should be used to determine what to implement. To achieve basic interoperability, an implementation SHOULD at least implement both bandwidth-efficient and octet-aligned modes for a single audio channel. The other operating modes: interleaving, robust sorting, and frame-wise CRC (in both single and multi-channel) are OPTIONAL to implement.
ペイロード形式の動作モードは、実装するために必須です。ペイロード形式を使用したアプリケーションの要件を使用して、何を実装するかを決定する必要があります。基本的な相互運用性を実現するには、実装では、少なくとも単一のオーディオチャンネルに帯域幅効率の高いモードとオクテットアライメントモードの両方を実装する必要があります。その他の動作モード：インターリーブ、堅牢なソート、およびフレームごとのCRC（シングルチャネルとマルチチャネルの両方）は、実装するためにオプションです。
The mode-change-period, mode-change-capability, and mode-change-neighbor parameters are intended for signaling with GSM endpoints. When interoperability with GSM is desired, encoders SHOULD only perform codec mode changes to neighboring modes and in integer multiples of 40 ms (two frame-blocks), but decoders SHOULD accept codec mode changes at any time, i.e., for every frame-block. The encoder may arbitrarily select the initial phase (odd or even frame-block) where codec mode changes are performed, but then SHOULD stick to that phase as far as possible. However, in rare cases, handovers or other events (e.g., call forwarding) may change this phase and may also cause mode changes to non-neighboring modes. The decoder SHALL therefore be prepared to accept changes also in the other phase and to other modes. Section 8 specifies the usage of the parameters mode-change-period and mode-change-capability to indicate the desired behavior in applications.
モードチェンジ期間、モードチェンジ能力、およびモードチェンジ隣人パラメーターは、GSMエンドポイントを使用したシグナリングを目的としています。GSMとの相互運用性が必要な場合、エンコーダーは隣接モードと40ミリ秒の整数倍（2つのフレームブロック）にコーデックモードの変更のみを実行する必要がありますが、デコーダーはいつでも、つまりフレームブロックごとにコーデックモードの変更を受け入れる必要があります。エンコーダーは、コーデックモードの変更が実行される初期フェーズ（奇数またはフレームブロック）を任意に選択する場合がありますが、そのフェーズに可能な限り固執する必要があります。ただし、まれに、ハンドオーバーやその他のイベント（たとえば、コール転送）がこのフェーズを変更する可能性があり、非希少モードのモード変更も引き起こす可能性があります。したがって、デコーダーは、他のフェーズおよび他のモードにも変更を受け入れるように準備するものとします。セクション8では、パラメーターモードチェンジ期間とモード変更能力の使用法を指定して、アプリケーションでの目的の動作を示します。
See 3GPP TS 26.103 [28] for preferred AMR and AMR-WB configurations for operation in GSM and 3GPP UMTS networks. In gateway scenarios, encoders can be requested through the "mode-set" parameter to use a limited mode-set that is supported by the link beyond the gateway. Further, to avoid congestion on that link, the encoder SHOULD limit the initial codec mode for a session to a lower mode, until at least one frame-block is received with rate control information.
GSMおよび3GPP UMTSネットワークでの動作のための優先AMRおよびAMR-WB構成については、3GPP TS 26.103 [28]を参照してください。ゲートウェイシナリオでは、「モードセット」パラメーターを介してエンコーダを要求して、ゲートウェイを越えたリンクによってサポートされる限られたモードセットを使用できます。さらに、そのリンクの輻輳を回避するために、エンコーダーは、レート制御情報で少なくとも1つのフレームブロックが受信されるまで、セッションの初期コーデックモードを低いモードに制限する必要があります。
When processing a received payload packet, if the receiver finds that the calculated payload length, based on the information for the payload type and the values found in the payload header fields, does not match the size of the received packet, the receiver SHOULD discard the packet. This is because decoding a packet that has errors in its length field could severely degrade the speech quality.
受信したペイロードパケットを処理する場合、受信者がペイロードタイプの情報とペイロードヘッダーフィールドにある値に基づいて計算されたペイロード長が受信されたパケットのサイズと一致しないことを発見した場合、受信者は受信者が廃棄する必要があります。パケット。これは、長さフィールドにエラーがあるパケットをデコードすると、音質の品質が大幅に低下する可能性があるためです。
The storage format is used for storing AMR or AMR-WB speech frames in a file or as an email attachment. Multiple channel content is supported.
ストレージ形式は、ファイルにAMRまたはAMR-WBの音声フレームを保存するため、または電子メールの添付ファイルとして使用されます。複数のチャネルコンテンツがサポートされています。
In general, an AMR or AMR-WB file has the following structure:
一般に、AMRまたはAMR-WBファイルには次の構造があります。
+------------------+
| Header |
+------------------+
| Speech frame 1 |
+------------------+
: ... :
+------------------+
| Speech frame n |
+------------------+
Note, to preserve interoperability with already deployed implementations, single-channel content uses a file header format different from that of multi-channel content.
注、既に展開されている実装で相互運用性を保持するために、シングルチャネルコンテンツはマルチチャネルコンテンツとは異なるファイルヘッダー形式を使用します。
There also exists another storage format for AMR and AMR-WB that is suitable for applications with more advanced demands on the storage format, like random access or synchronization with video. This format is the 3GPP-specified ISO-based multimedia file format 3GP [31]. Its media type is specified by RFC 3839 [32].
また、ランダムアクセスやビデオとの同期など、ストレージ形式でより高度な需要を持つアプリケーションに適したAMRとAMR-WBの別のストレージ形式も存在します。この形式は、3GPP指定のISOベースのマルチメディアファイル形式3GP [31]です。そのメディアタイプは、RFC 3839 [32]によって指定されています。
A single-channel AMR or AMR-WB file header contains only a magic number. Different magic numbers are defined to distinguish AMR from AMR-WB.
シングルチャネルAMRまたはAMR-WBファイルヘッダーには、マジック番号のみが含まれています。AMRとAMR-WBを区別するために、さまざまな魔法の数字が定義されています。
The magic number for single-channel AMR files MUST consist of ASCII character string:
シングルチャネルAMRファイルのマジック番号は、ASCII文字列で構成されている必要があります。
"#!AMR\n" (or 0x2321414d520a in hexadecimal).
「＃！amr \ n」（または16進数の0x2321414d520a）。
The magic number for single-channel AMR-WB files MUST consist of ASCII character string:
シングルチャネルAMR-WBファイルのマジック番号は、ASCII文字列で構成されている必要があります。
"#!AMR-WB\n" (or 0x2321414d522d57420a in hexadecimal).
"＃！amr-wb \ n"（または16進数の0x2321414d522d57420a）。
Note, the "\n" is an important part of the magic numbers and MUST be included in the comparison, since, otherwise, the single-channel magic numbers above will become indistinguishable from those of the multi-channel files defined in the next section.
「\ n」は魔法の数字の重要な部分であり、比較に含める必要があります。さもなければ、上記のシングルチャネルマジック番号は次のセクションで定義されているマルチチャネルファイルのものと区別できないようになるため。
The multi-channel header consists of a magic number followed by a 32-bit channel description field, giving the multi-channel header the following structure:
マルチチャネルヘッダーは、マジック番号で構成され、32ビットチャネル説明フィールドが続き、マルチチャネルヘッダーに次の構造を与えます。
+------------------+
| magic number |
+------------------+
| chan-desc field |
+------------------+
The magic number for multi-channel AMR files MUST consist of the ASCII character string:
マルチチャネルAMRファイルのマジック番号は、ASCII文字列で構成されている必要があります。
"#!AMR_MC1.0\n" (or 0x2321414d525F4D43312E300a in hexadecimal).
"＃！amr_mc1.0 \ n"（または16進数の0x2321414d525f4d43312e300a）。
The magic number for multi-channel AMR-WB files MUST consist of the ASCII character string:
マルチチャネルAMR-WBファイルのマジック番号は、ASCII文字列で構成されている必要があります。
"#!AMR-WB_MC1.0\n" (or 0x2321414d522d57425F4D43312E300a in hexadecimal).
"＃！amr-wb_mc1.0 \ n"（または0x2321414D522D57425F4D43312E300A）。
The version number in the magic numbers refers to the version of the file format.
マジック番号のバージョン番号は、ファイル形式のバージョンを指します。
The 32 bit channel description field is defined as:
32ビットチャネルの説明フィールドは、次のように定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved bits | CHAN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved bits: MUST be set to 0 when written, and a reader MUST ignore them.
予約ビット：書かれたときに0に設定する必要があり、読者はそれらを無視する必要があります。
CHAN (4 bits, unsigned integer): Indicates the number of audio channels contained in this storage file. The valid values and the order of the channels within a frame-block are specified in Section 4.1 in [12].
Chan（4ビット、署名されていない整数）：このストレージファイルに含まれるオーディオチャネルの数を示します。フレームブロック内のチャネルの有効な値と順序は、[12]のセクション4.1で指定されています。
After the file header, speech frame-blocks consecutive in time are stored in the file. Each frame-block contains a number of octet-aligned speech frames equal to the number of channels, and stored in increasing order, starting with channel 1.
ファイルヘッダーの後、Speech Frame-Blocksは時間内に連続してファイルに保存されます。各フレームブロックには、チャネルの数に等しい多くのオクテットに合った音声フレームが含まれており、チャンネル1から始まる順序で保存されます。
Each stored speech frame starts with a one-octet frame header with the following format:
保存されている各音声フレームは、次の形式の1オクテットフレームヘッダーで始まります。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|P| FT |Q|P|P|
+-+-+-+-+-+-+-+-+
The FT field and the Q bit are defined in the same way as in Section 4.3.2. The P bits are padding and MUST be set to 0, and MUST be ignored.
FTフィールドとQビットは、セクション4.3.2と同じ方法で定義されます。Pビットはパディングであり、0に設定する必要があり、無視する必要があります。
Following this one octet header come the speech bits as defined in 4.4.3. The last octet of each frame is padded with zeroes, if needed, to achieve octet alignment.
この1つのオクテットヘッダーに続いて、4.4.3で定義されている音声ビットがあります。各フレームの最後のオクテットは、必要に応じてゼロでパディングされており、オクテットアライメントを実現します。
The following example shows an AMR frame in 5.9 kbps coding mode (with 118 speech bits) in the storage format.
次の例は、ストレージ形式の5.9 kbpsコーディングモード（118の音声ビット）のAMRフレームを示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| FT=2 |Q|P|P| |
+-+-+-+-+-+-+-+-+ +
| |
+ Speech bits for frame-block n, channel k +
| |
+ +-+-+
| |P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Non-received speech frames or frame-blocks between SID updates during non-speech periods MUST be stored as NO_DATA frames (frame type 15, as defined in [2] and [4]). Frames or frame-blocks lost in transmission MUST be stored as NO_DATA frames or SPEECH_LOST (frame type 14, only available for AMR-WB) in complete frame-blocks to keep synchronization with the original media.
非スピーチ期間中のSID更新間の非推定音声フレームまたはフレームブロックは、[2]および[4]で定義されているように、NO_DATAフレーム（フレームタイプ15）として保存する必要があります。トランスミッションで失われたフレームまたはフレームブロックは、NO_DATAフレームまたはSpeech_Lost（フレームタイプ14、AMR-WBでのみ利用可能）として保存する必要があります。
Comfort noise frames of other types than AMR SID (FT=8) (i.e., frame type 9, 10, and 11 for AMR) SHALL NOT be used in the AMR file format.
AMR SID以外の他のタイプのコンフォートノイズフレーム（FT = 8）（つまり、AMRのフレームタイプ9、10、および11）は、AMRファイル形式では使用しません。
The general congestion control considerations for transporting RTP data apply to AMR or AMR-WB speech over RTP as well. However, the multi-rate capability of AMR and AMR-WB speech coding may provide an advantage over other payload formats for controlling congestion since the bandwidth demand can be adjusted by selecting a different coding mode.
RTPデータを輸送するための一般的な混雑制御の考慮事項は、RTPよりもAMRまたはAMR-WBのスピーチにも適用されます。ただし、AMRおよびAMR-WBの音声コーディングの多価格機能は、帯域幅の需要を別のコーディングモードを選択することで調整できるため、渋滞を制御するための他のペイロード形式よりも利点を提供する可能性があります。
Another parameter that may impact the bandwidth demand for AMR and AMR-WB is the number of frame-blocks that are encapsulated in each RTP payload. Packing more frame-blocks in each RTP payload can reduce the number of packets sent and hence the overhead from IP/UDP/RTP headers, at the expense of increased delay.
AMRおよびAMR-WBの帯域幅の需要に影響を与える可能性のある別のパラメーターは、各RTPペイロードにカプセル化されているフレームブロックの数です。各RTPペイロードでより多くのフレームブロックを詰めると、送信されるパケットの数を減らすことができ、したがって、遅延を犠牲にしてIP/UDP/RTPヘッダーからのオーバーヘッドを減らすことができます。
If forward error correction (FEC) is used to combat packet loss, the amount of redundancy added by FEC will need to be regulated so that the use of FEC itself does not cause a congestion problem.
パケットの損失と戦うためにフォワードエラー補正（FEC）を使用している場合、FECによって追加される冗長性の量を調整する必要があります。これにより、FEC自体が混雑の問題を引き起こさないようにします。
It is RECOMMENDED that AMR or AMR-WB applications using this payload format employ congestion control. The actual mechanism for congestion control is not specified but should be suitable for real-time flows, possibly "TCP Friendly Rate Control" [21].
このペイロード形式を使用したAMRまたはAMR-WBアプリケーションを使用することをお勧めします。輻輳制御の実際のメカニズムは指定されていませんが、リアルタイムのフロー、おそらく「TCPフレンドリーレートコントロール」に適している必要があります[21]。
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in [8] and in any used profile, like AVP [12] or SAVP [26].
この仕様で定義されているペイロード形式を使用したRTPパケットは、[8]で説明されている一般的なセキュリティに関する考慮事項や、AVP [12]やSAVP [26]などの使用されているプロファイルで説明されています。
As this format transports encoded speech, the main security issues include confidentiality, authentication, and integrity of the speech itself. The payload format itself does not have any built-in security mechanisms. External mechanisms, such as SRTP [26], need to be used for this functionality. Note that the appropriate mechanism to provide security to RTP and the payloads following this memo may vary. It is dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable the usage of SRTP [26] is RECOMMENDED. Other known mechanisms that may be used are IPsec [33] and TLS [34] (RTP over TCP), but other alternatives may also exist.
この形式はエンコードされたスピーチを輸送するため、主なセキュリティの問題には、スピーチ自体の機密性、認証、および完全性が含まれます。ペイロード形式自体には、組み込みのセキュリティメカニズムがありません。SRTP [26]などの外部メカニズムは、この機能に使用する必要があります。RTPにセキュリティを提供する適切なメカニズムと、このメモに続くペイロードは異なる場合があることに注意してください。アプリケーション、輸送、および採用されたシグナルプロトコルに依存します。したがって、SRTP [26]の使用法が適切な場合は、単一のメカニズムでは十分ではありません。使用できる他の既知のメカニズムは、IPSEC [33]およびTLS [34]（TCPを超えるRTP）ですが、他の代替品も存在する可能性があります。
This payload format does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing, and thus is unlikely to pose a denial-of-service threat due to the receipt of pathological data.
このペイロード形式は、パケット処理のためにレシーバー側の計算の複雑さに有意な不均一性を示すものではないため、病理学的データの受領によりサービス拒否の脅威をもたらす可能性は低いです。
To achieve confidentiality of the encoded AMR or AMR-WB speech, all speech data bits will need to be encrypted. There is less of a need to encrypt the payload header or the table of contents due to a) that they only carry information about the requested speech mode, frame type, and frame quality, and b) that this information could be useful to some third party, e.g., quality monitoring.
エンコードされたAMRまたはAMR-WBスピーチの機密性を達成するには、すべての音声データビットを暗号化する必要があります。a）要求された音声モード、フレームタイプ、フレームの品質に関する情報のみを携帯するため、ペイロードヘッダーまたは目次を暗号化する必要はほとんどありません。パーティー、例えば、品質監視。
The packetization and unpacketization of the AMR and AMR-WB payload is done only at the endpoints. Therefore encryption should be performed after packet encapsulation, and decryption should be performed before packet decapsulation.
AMRおよびAMR-WBペイロードのパケット化と解放は、エンドポイントでのみ行われます。したがって、パケットのカプセル化後に暗号化を実行する必要があり、パケットの脱カプセル化の前に復号化を実行する必要があります。
Encryption may affect interleaving. Specifically, a change of keys should occur at the boundary between interleaving groups. If it is not done at that boundary on both endpoints, the speech quality will be degraded during the complete interleaving group for any receiver.
暗号化はインターリービングに影響を与える可能性があります。具体的には、キーの変更は、インターリーブグループ間の境界で発生する必要があります。両方のエンドポイントのその境界で行われない場合、レシーバーの完全なインターリービンググループ中に音声品質が低下します。
The encryption mechanism may impact the robustness of the error correcting mechanism. This is discussed in Section 9.5 of SRTP [26]. From this, UED/UEP based on robust sorting may be difficult to apply when the payload data is encrypted.
暗号化メカニズムは、エラー修正メカニズムの堅牢性に影響を与える可能性があります。これについては、SRTP [26]のセクション9.5で説明しています。このことから、ペイロードデータが暗号化されている場合、堅牢なソートに基づくUED/UEPを適用するのが難しい場合があります。
To authenticate the sender and to protect the integrity of the RTP packets in transit, an external mechanism has to be used. As stated before, it is RECOMMENDED that SRTP [26] be used for common interoperability. Note that the use of UED/UEP may be difficult to combine with some integrity protection mechanisms because any bit errors will cause the integrity check to fail.
送信者を認証し、輸送中のRTPパケットの完全性を保護するには、外部メカニズムを使用する必要があります。前に述べたように、SRTP [26]を一般的な相互運用性に使用することをお勧めします。UED/UEPの使用は、いくつかの整合性保護メカニズムと組み合わせることが困難である可能性があることに注意してください。
Data tampering by a man-in-the-middle attacker could result in erroneous depacketization/decoding that could lower the speech quality or produce unintelligible communications. Tampering with the CMR field may result in a different speech quality than desired.
中間の攻撃者によるデータの改ざんは、音声品質を低下させたり、理解できないコミュニケーションを生み出す可能性のある誤ったデパケット化/デコードをもたらす可能性があります。CMRフィールドを改ざんすると、必要に応じて異なる音声品質が生じる可能性があります。
This section defines the parameters that may be used to select optional features of the AMR and AMR-WB payload formats. The parameters are defined here as part of the media type registrations for the AMR and AMR-WB speech codecs. The registrations are done following RFC 4855 [15] and the media registration rules [14].
このセクションでは、AMRおよびAMR-WBペイロード形式のオプションの機能を選択するために使用できるパラメーターを定義します。パラメーターは、AMRおよびAMR-WBの音声コーデックのメディアタイプ登録の一部としてここで定義されています。登録は、RFC 4855 [15]およびメディア登録規則[14]に続いて行われます。
A mapping of the parameters into the Session Description Protocol (SDP) [11] is also provided for those applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that do not use media types or SDP.
セッション説明プロトコル（SDP）[11]へのパラメーターのマッピングは、SDPを使用するアプリケーションにも提供されています。同等のパラメーターは、メディアタイプまたはSDPを使用しない制御プロトコルで使用するために他の場所で定義できます。
Two separate media type registrations are made, one for AMR and one for AMR-WB, because they are distinct encodings that must be distinguished by their own media type.
2つの個別のメディアタイプの登録が行われます。1つはAMR用、もう1つはAMR-WB用です。これは、独自のメディアタイプで区別する必要がある明確なエンコーディングであるためです。
Data formats are specified for both real-time transport in RTP and for storage type applications such as email attachments.
データ形式は、RTPでのリアルタイムトランスポートと、電子メール添付ファイルなどのストレージタイプアプリケーションの両方に指定されています。
The media type for the Adaptive Multi-Rate (AMR) codec is allocated from the IETF tree since AMR is a widely used speech codec in general VoIP and messaging applications. This media type registration covers both real-time transfer via RTP and non-real-time transfers via stored files.
AMRは一般的なVoIPおよびメッセージングアプリケーションで広く使用されている音声コーデックであるため、Adaptive Multi-Rate（AMR）コーデックのメディアタイプはIETFツリーから割り当てられます。このメディアタイプの登録は、RTPを介したリアルタイム転送と、保存されたファイルを介した非リアルタイム転送の両方をカバーしています。
Note, any unspecified parameter MUST be ignored by the receiver.
注意してください。不特定のパラメーターは、受信機によって無視する必要があります。
Media Type name: audio
メディアタイプ名：オーディオ
Media subtype name: AMR
メディアサブタイプ名：AMR
Required parameters: none
必要なパラメーター：なし
Optional parameters:
オプションのパラメーター：
These parameters apply to RTP transfer only.
これらのパラメーターは、RTP転送のみに適用されます。
octet-align: Permissible values are 0 and 1. If 1, octet-aligned operation SHALL be used. If 0 or if not present, bandwidth-efficient operation is employed.
Octet-Align：許容値は0および1です。0または存在しない場合、帯域幅効率の高い操作が採用されています。
mode-set: Restricts the active codec mode set to a subset of all modes, for example, to be able to support transport channels such as GSM networks in gateway use cases. Possible values are a comma separated list of modes from the set: 0,...,7 (see Table 1a [2]). The SID frame type 8 and NO_DATA (frame type 15) are never included in the mode set, but can always be used. If mode-set is specified, it MUST be abided, and frames encoded with modes outside of the subset MUST NOT be sent in any RTP payload or used in codec mode requests. If not present, all codec modes are allowed for the payload type.
モードセット：たとえば、ゲートウェイのユースケースでGSMネットワークなどの輸送チャネルをサポートできるように、すべてのモードのサブセットに設定されたアクティブコーデックモードを制限します。考えられる値は、セットからのモードのコンマ分離リストです：0、...、7（表1a [2]を参照）。SIDフレームタイプ8およびNO_DATA（フレームタイプ15）は、モードセットには含まれていませんが、いつでも使用できます。モードセットが指定されている場合は、それを遵守する必要があり、サブセットの外側のモードでエンコードされたフレームは、RTPペイロードで送信したり、コーデックモードリクエストで使用したりしてはなりません。存在しない場合、ペイロードタイプにはすべてのコーデックモードが許可されます。
mode-change-period: Specifies a number of frame-blocks, N (1 or 2), that is the frame-block period at which codec mode changes are allowed for the sender. The initial phase of the interval is arbitrary, but changes must be separated by a period of N frame-blocks, i.e., a value of 2 allows the sender to change mode every second frame-block. The value of N SHALL be either 1 or 2. If this parameter is not present, mode changes are allowed at any time during the session, i.e., N=1.
モードチェンジ期間：多数のフレームブロックn（1または2）を指定します。これは、送信者にコーデックモードが変更されるフレームブロック期間です。間隔の初期段階は任意ですが、変更はnフレームブロックの周期によって分離する必要があります。つまり、2の値により、センダーが2秒のフレームブロックごとに変更モードに変更できます。nの値は1または2のいずれかでなければなりません。このパラメーターが存在しない場合、セッション中はいつでもモードの変更が許可されます。つまり、n = 1。
mode-change-capability: Specifies if the client is capable to transmit with a restricted mode change period. The parameter may take value of 1 or 2. A value of 1 indicates that the client is not capable of restricting the mode change period to 2, and that the codec mode may be changed at any point. A value of 2 indicates that the client has the capability to restrict the mode change period to 2, and thus that the client can correctly interoperate with a receiver requiring a mode-change-period=2. If this parameter is not present, the mode-change restriction capability is not supported, i.e. mode-change-capability=1. To be able to interoperate fully with gateways to circuit switched networks (for example, GSM networks), transmissions with restricted mode changes (mode-change-capability=2) are required. Thus, clients RECOMMENDED to have the capability to support transmission according to mode-change-capability=2.
モードチェンジキャピール：クライアントが制限付きモード変更期間で送信できるかどうかを指定します。パラメーターは1または2の値をとる場合があります1の値は、クライアントがモードの変更期間を2に制限できないこと、およびコーデックモードをいつでも変更できることを示します。2の値は、クライアントがモードの変更期間を2に制限する機能を持っていることを示しており、したがって、クライアントはモードチェンジ期間= 2を必要とする受信者と正しく相互運用できることを示しています。このパラメーターが存在しない場合、モード変更制限機能はサポートされていません。つまり、モードチェンジキャピール= 1。回路スイッチ付きネットワーク（GSMネットワークなど）へのゲートウェイと完全に相互運用できるようにするには、制限されたモード変更（モードチェンジキャピール= 2）のトランスミッションが必要です。したがって、クライアントは、モードチェンジキャピール= 2に従って送信をサポートする機能を持つことをお勧めします。
mode-change-neighbor: Permissible values are 0 and 1. If 1, the sender SHOULD only perform mode changes to the neighboring modes in the active codec mode set.
Mode-change-neighbor：許容値は0および1です。1の場合、送信者はアクティブなコーデックモードセットの隣接モードにモード変更のみを実行する必要があります。
Neighboring modes are the ones closest in bit rate to the current mode, either the next higher or next lower rate. If 0 or if not present, change between any two modes in the active codec mode set is allowed.
隣接するモードは、現在のモードに最も近いモードであり、次の高レートまたは次の低いレートのいずれかです。0または存在しない場合は、アクティブなコーデックモードセットの2つのモード間の変更が許可されます。
maxptime: The maximum amount of media which can be encapsulated in a payload packet, expressed as time in milliseconds. The time is calculated as the sum of the time that the media present in the packet represents. The time SHOULD be an integer multiple of the frame size. If this parameter is not present, the sender MAY encapsulate any number of speech frames into one RTP packet.
Maxptime：ペイロードパケットにカプセル化できるメディアの最大量、ミリ秒単位での時間として表されます。時間は、パケットに存在するメディアが表す時間の合計として計算されます。時間は、フレームサイズの整数倍でなければなりません。このパラメーターが存在しない場合、送信者は任意の数の音声フレームを1つのRTPパケットにカプセル化できます。
crc: Permissible values are 0 and 1. If 1, frame CRCs SHALL be included in the payload. If 0 or not present, CRCs SHALL NOT be used. If crc=1, this also implies automatically that octet-aligned operation SHALL be used for the session.
CRC：許容値は0および1です。11の場合、フレームCRCはペイロードに含まれます。0が存在するかどうかは、CRCを使用してはなりません。CRC = 1の場合、これは、セッションにオクテットに合わせた操作を使用することも自動的に暗示しています。
robust-sorting: Permissible values are 0 and 1. If 1, the payload SHALL employ robust payload sorting. If 0 or if not present, simple payload sorting SHALL be used. If robust-sorting=1, this also implies automatically that octet-aligned operation SHALL be used for the session.
ロバストソート：許容値は0および1です。1の場合、ペイロードは堅牢なペイロードソートを使用します。0または存在しない場合は、単純なペイロードソートを使用するものとします。堅牢なソルティング= 1の場合、これはオクテットに合わせた操作がセッションに使用されることも自動的に意味します。
interleaving: Indicates that frame-block level interleaving SHALL be used for the session, and its value defines the maximum number of frame-blocks allowed in an interleaving group (see Section 4.4.1). If this parameter is not present, interleaving SHALL NOT be used. The presence of this parameter also implies automatically that octet-aligned operation SHALL be used.
インターリーブ：フレームブロックレベルのインターリーブがセッションに使用されることを示し、その値はインターリーブグループで許可されるフレームブロックの最大数を定義します（セクション4.4.1を参照）。このパラメーターが存在しない場合、インターリーブを使用してはなりません。このパラメーターの存在は、オクテットに合わせた操作を使用することも自動的に意味します。
ptime: see RFC 4566 [11].
PTIME：RFC 4566 [11]を参照してください。
channels: The number of audio channels. The possible values (1-6) and their respective channel order is specified in Section 4.1 in [12]. If omitted, it has the default value of 1.
チャネル：オーディオチャネルの数。可能な値（1-6）とそれぞれのチャネル順序は、[12]のセクション4.1で指定されています。省略した場合、デフォルト値は1です。
max-red: The maximum duration in milliseconds that elapses between the primary (first) transmission of a frame and any redundant transmission that the sender will use. This parameter allows a receiver to have a bounded delay when redundancy is used. Allowed values are between 0 (no redundancy will be used) and 65535. If the parameter is omitted, no limitation on the use of redundancy is present.
Max-Red：フレームの一次（最初の）送信と、送信者が使用する冗長トランスミッションの間で経過するミリ秒単位での最大期間。このパラメーターにより、冗長性を使用すると、レシーバーが境界遅延を持つことができます。許可された値は0（冗長性は使用されません）と65535の間です。パラメーターが省略されている場合、冗長性の使用に関する制限は存在しません。
Encoding considerations: The Audio data is binary data, and must be encoded for non-binary transport; the Base64 encoding is suitable for email. When used in RTP context the data is framed as defined in [14].
考慮事項のエンコード：オーディオデータはバイナリデータであり、非バイナリトランスポート用にエンコードする必要があります。Base64エンコーディングは、電子メールに適しています。RTPコンテキストで使用する場合、データは[14]で定義されているようにフレーム化されます。
Security considerations: See Section 7 of RFC 4867.
セキュリティ上の考慮事項：RFC 4867のセクション7を参照してください。
Public specification: RFC 4867 3GPP TS 26.090, 26.092, 26.093, 26.101
パブリック仕様：RFC 4867 3GPP TS 26.090、26.092、26.093、26.101
Applications that use this media type: This media type is used in numerous applications needing transport or storage of encoded voice. Some examples include; Voice over IP, streaming media, voice messaging, and voice recording on digital cameras.
このメディアタイプを使用するアプリケーション：このメディアタイプは、エンコードされた音声の輸送または保存を必要とする多数のアプリケーションで使用されます。いくつかの例が含まれます。IPオーバーIP、ストリーミングメディア、音声メッセージング、およびデジタルカメラでの音声録音。
Additional information: The following applies to stored-file transfer methods:
追加情報：以下は、保存されたファイル転送方法に適用されます。
Magic numbers: single-channel: ASCII character string "#!AMR\n" (or 0x2321414d520a in hexadecimal) multi-channel: ASCII character string "#!AMR_MC1.0\n" (or 0x2321414d525F4D43312E300a in hexadecimal) File extensions: amr, AMR Macintosh file type code: "amr " (fourth character is space)
マジック番号：シングルチャネル：ASCII文字文字列 "＃！amr \ n"（または16進数の0x2321414d520a）マルチチャネル：ASCII文字文字列 "＃！amr_mc1.0 \ n"（OR 0x2321414D525F4D43312E300A IN HEXECIMAL：AMR Macintoshファイルタイプコード：「AMR」（4番目の文字はスペースです）
AMR speech frames may also be stored in the file format "3GP" defined in 3GPP TS 26.244 [31], which is identified using the media types "audio/3GPP" or "video/3GPP" as registered by RFC 3839 [32].
AMRスピーチフレームは、3GPP TS 26.244 [31]で定義されたファイル形式「3GP」に保存されます。これは、RFC 3839 [32]によって登録されているメディアタイプ「Audio/3GPP」または「Video/3GPP」を使用して識別されます。
Person & email address to contact for further information:
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>
Intended usage: COMMON. This media type is widely used in streaming, VoIP, and messaging applications on many types of devices.
意図された使用法：共通。このメディアタイプは、多くのタイプのデバイスでのストリーミング、VoIP、およびメッセージングアプリケーションで広く使用されています。
Restrictions on usage: When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4 SHALL be used. In all other contexts, the file format defined in Section 5 SHALL be used.
使用法の制限：このメディアタイプがRTPを介した転送のコンテキストで使用される場合、セクション4で指定されたRTPペイロード形式を使用するものとします。他のすべてのコンテキストでは、セクション5で定義されているファイル形式を使用するものとします。
Author:
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
The media type for the Adaptive Multi-Rate Wideband (AMR-WB) codec is allocated from the IETF tree since AMR-WB is a widely used speech codec in general VoIP and messaging applications. This media type registration covers both real-time transfer via RTP and non-real-time transfers via stored files.
AMR-WBは一般的なVoIPおよびメッセージングアプリケーションで広く使用されている音声コーデックであるため、Adaptive Multi-Rate Wideband（AMR-WB）コーデックのメディアタイプはIETFツリーから割り当てられています。このメディアタイプの登録は、RTPを介したリアルタイム転送と、保存されたファイルを介した非リアルタイム転送の両方をカバーしています。
Note, any unspecified parameter MUST be ignored by the receiver.
注意してください。不特定のパラメーターは、受信機によって無視する必要があります。
Media Type name: audio
メディアタイプ名：オーディオ
Media subtype name: AMR-WB
メディアサブタイプ名：AMR-WB
Required parameters: none
必要なパラメーター：なし
Optional parameters:
オプションのパラメーター：
These parameters apply to RTP transfer only.
これらのパラメーターは、RTP転送のみに適用されます。
octet-align: Permissible values are 0 and 1. If 1, octet-aligned operation SHALL be used. If 0 or if not present, bandwidth-efficient operation is employed.
Octet-Align：許容値は0および1です。0または存在しない場合、帯域幅効率の高い操作が採用されています。
mode-set: Restricts the active codec mode set to a subset of all modes, for example, to be able to support transport channels such as GSM networks in gateway use cases. Possible values are a comma-separated list of modes from the set: 0,...,8 (see Table 1a [4]). The SID frame type 9, SPEECH_LOST (frame type 14), and NO_DATA (frame type 15) are never included in the mode set, but can always be used. If mode-set is specified, it MUST be abided, and frames encoded with modes outside of the subset MUST NOT be sent in any RTP payload or used in codec mode requests. If not present, all codec modes are allowed for the payload type.
モードセット：たとえば、ゲートウェイのユースケースでGSMネットワークなどの輸送チャネルをサポートできるように、すべてのモードのサブセットに設定されたアクティブコーデックモードを制限します。考えられる値は、セットからのモードのコンマ分離されたリストです：0、...、8（表1a [4]を参照）。SIDフレームタイプ9、Speech_Lost（フレームタイプ14）、およびNO_DATA（フレームタイプ15）は、モードセットには含まれていませんが、いつでも使用できます。モードセットが指定されている場合は、それを遵守する必要があり、サブセットの外側のモードでエンコードされたフレームは、RTPペイロードで送信したり、コーデックモードリクエストで使用したりしてはなりません。存在しない場合、ペイロードタイプにはすべてのコーデックモードが許可されます。
mode-change-period: Specifies a number of frame-blocks, N (1 or 2), that is the frame-block period at which codec mode changes are allowed for the sender. The initial phase of the interval is arbitrary, but changes must be separated by multiples of N frame-blocks, i.e., a value of 2 allows the sender to change mode every second frame-block. The value of N SHALL be either 1 or 2. If this parameter is not present, mode changes are allowed at Any time during the session, i.e., N=1.
モードチェンジ期間：多数のフレームブロックn（1または2）を指定します。これは、送信者にコーデックモードが変更されるフレームブロック期間です。間隔の初期段階は任意ですが、nフレームブロックの倍数によって変更を分離する必要があります。つまり、2の値により、センダーが2秒のフレームブロックごとに変更モードに変更できます。nの値は1または2のいずれかでなければなりません。このパラメーターが存在しない場合、セッション中はいつでもモードの変更が許可されます。つまり、n = 1。
mode-change-capability: Specifies if the client is capable to transmit with a restricted mode change period. The parameter may take value of 1 or 2. A value of 1 indicates that the client is not capable of restricting the mode change period to 2, and that the codec mode may be changed at any point. A value of 2 indicates that the client has the capability to restrict the mode change period to 2, and thus that the client can correctly interoperate with a receiver requiring a mode-change-period=2. If this parameter is not present, the mode-change restriction capability is not supported, i.e. mode-change-capability=1. To be able to interoperate fully with gateways to circuit switched networks (for example, GSM networks), transmissions with restricted mode changes (mode-change-capability=2) are required. Thus, clients are RECOMMENDED to have the capability to support transmission according to mode-change-capability=2.
モードチェンジキャピール：クライアントが制限付きモード変更期間で送信できるかどうかを指定します。パラメーターは1または2の値をとる場合があります1の値は、クライアントがモードの変更期間を2に制限できないこと、およびコーデックモードをいつでも変更できることを示します。2の値は、クライアントがモードの変更期間を2に制限する機能を持っていることを示しており、したがって、クライアントはモードチェンジ期間= 2を必要とする受信者と正しく相互運用できることを示しています。このパラメーターが存在しない場合、モード変更制限機能はサポートされていません。つまり、モードチェンジキャピール= 1。回路スイッチ付きネットワーク（GSMネットワークなど）へのゲートウェイと完全に相互運用できるようにするには、制限されたモード変更（モードチェンジキャピール= 2）のトランスミッションが必要です。したがって、クライアントは、モードチェンジキャピール= 2に従って送信をサポートする機能を持つことをお勧めします。
mode-change-neighbor: Permissible values are 0 and 1. If 1, the sender SHOULD only perform mode changes to the neighboring modes in the active codec mode set. Neighboring modes are the ones closest in bit rate to the current mode, either the next higher or next lower rate. If 0 or if not present, change between any two modes in the active codec mode set is allowed.
Mode-change-neighbor：許容値は0および1です。1の場合、送信者はアクティブなコーデックモードセットの隣接モードにモード変更のみを実行する必要があります。隣接するモードは、現在のモードに最も近いモードであり、次の高レートまたは次の低いレートのいずれかです。0または存在しない場合は、アクティブなコーデックモードセットの2つのモード間の変更が許可されます。
maxptime: The maximum amount of media which can be encapsulated in a payload packet, expressed as time in milliseconds. The time is calculated as the sum of the time that the media present in the packet represents. The time SHOULD be an integer multiple of the frame size. If this parameter is not present, the sender MAY encapsulate any number of speech frames into one RTP packet.
Maxptime：ペイロードパケットにカプセル化できるメディアの最大量、ミリ秒単位での時間として表されます。時間は、パケットに存在するメディアが表す時間の合計として計算されます。時間は、フレームサイズの整数倍でなければなりません。このパラメーターが存在しない場合、送信者は任意の数の音声フレームを1つのRTPパケットにカプセル化できます。
crc: Permissible values are 0 and 1. If 1, frame CRCs SHALL be included in the payload. If 0 or not present, CRCs SHALL NOT be used. If crc=1, this also implies automatically that octet-aligned operation SHALL be used for the session.
CRC：許容値は0および1です。11の場合、フレームCRCはペイロードに含まれます。0が存在するかどうかは、CRCを使用してはなりません。CRC = 1の場合、これは、セッションにオクテットに合わせた操作を使用することも自動的に暗示しています。
robust-sorting: Permissible values are 0 and 1. If 1, the payload SHALL employ robust payload sorting. If 0 or if not present, simple payload sorting SHALL be used. If robust-sorting=1, this also implies automatically that octet-aligned operation SHALL be used for the session.
ロバストソート：許容値は0および1です。1の場合、ペイロードは堅牢なペイロードソートを使用します。0または存在しない場合は、単純なペイロードソートを使用するものとします。堅牢なソルティング= 1の場合、これはオクテットに合わせた操作がセッションに使用されることも自動的に意味します。
interleaving: Indicates that frame-block level interleaving SHALL be used for the session, and its value defines the maximum number of frame-blocks allowed in an interleaving group (see Section 4.4.1). If this parameter is not present, interleaving SHALL NOT be used. The presence of this parameter also implies automatically that octet-aligned operation SHALL be used.
インターリーブ：フレームブロックレベルのインターリーブがセッションに使用されることを示し、その値はインターリーブグループで許可されるフレームブロックの最大数を定義します（セクション4.4.1を参照）。このパラメーターが存在しない場合、インターリーブを使用してはなりません。このパラメーターの存在は、オクテットに合わせた操作を使用することも自動的に意味します。
ptime: see RFC 2327 [11].
PTIME：RFC 2327 [11]を参照してください。
channels: The number of audio channels. The possible values (1-6) and their respective channel order is specified in Section 4.1 in [12]. If omitted, it has the default value of 1.
チャネル：オーディオチャネルの数。可能な値（1-6）とそれぞれのチャネル順序は、[12]のセクション4.1で指定されています。省略した場合、デフォルト値は1です。
max-red: The maximum duration in milliseconds that elapses between the primary (first) transmission of a frame and any redundant transmission that the sender will use. This parameter allows a receiver to have a bounded delay when redundancy is used. Allowed values are between 0 (no redundancy will be used) and 65535. If the parameter is omitted, no limitation on the use of redundancy is present.
Max-Red：フレームの一次（最初の）送信と、送信者が使用する冗長トランスミッションの間で経過するミリ秒単位での最大期間。このパラメーターにより、冗長性を使用すると、レシーバーが境界遅延を持つことができます。許可された値は0（冗長性は使用されません）と65535の間です。パラメーターが省略されている場合、冗長性の使用に関する制限は存在しません。
Encoding considerations: The Audio data is binary data, and must be encoded for non-binary transport; the Base64 encoding is suitable for email. When used in RTP context the data is framed as defined in [14].
考慮事項のエンコード：オーディオデータはバイナリデータであり、非バイナリトランスポート用にエンコードする必要があります。Base64エンコーディングは、電子メールに適しています。RTPコンテキストで使用する場合、データは[14]で定義されているようにフレーム化されます。
Security considerations: See Section 7 of RFC 4867.
セキュリティ上の考慮事項：RFC 4867のセクション7を参照してください。
Public specification: RFC 4867 3GPP TS 26.190, 26.192, 26.193, 26.201
パブリック仕様：RFC 4867 3GPP TS 26.190、26.192、26.193、26.201
Applications that use this media type: This media type is used in numerous applications needing transport or storage of encoded voice. Some examples include; Voice over IP, streaming media, voice messaging, and voice recording on digital cameras.
このメディアタイプを使用するアプリケーション：このメディアタイプは、エンコードされた音声の輸送または保存を必要とする多数のアプリケーションで使用されます。いくつかの例が含まれます。IPオーバーIP、ストリーミングメディア、音声メッセージング、およびデジタルカメラでの音声録音。
Additional information: The following applies to stored-file transfer methods:
追加情報：以下は、保存されたファイル転送方法に適用されます。
Magic numbers: single-channel: ASCII character string "#!AMR-WB\n" (or 0x2321414d522d57420a in hexadecimal) multi-channel: ASCII character string "#!AMR-WB_MC1.0\n" (or 0x2321414d522d57425F4D43312E300a in hexadecimal) File extensions: awb, AWB Macintosh file type code: amrw Object identifier or OID: none
魔法の数字：シングルチャネル：ASCII文字文字列 "＃！amr-wb \ n"（または0x2321414d522d57420a in hexadecimal）マルチチャネル：ascii文字列 "＃！amr-wb_mc1.0 \ n" al）ファイル拡張機能：AWB、AWB Macintoshファイルタイプコード：AMRWオブジェクト識別子またはOID：なし
AMR-WB speech frames may also be stored in the file format "3GP" defined in 3GPP TS 26.244 [31] and identified using the media type "audio/3GPP" or "video/3GPP" as registered by RFC 3839 [32].
AMR-WBの音声フレームは、3GPP TS 26.244 [31]で定義されたファイル形式「3GP」で保存され、RFC 3839 [32]によって登録されているメディアタイプ「Audio/3GPP」または「Video/3GPP」を使用して識別できます。
Person & email address to contact for further information:
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>
Intended usage: COMMON. This media type is widely used in streaming, VoIP, and messaging applications on many types of devices.
意図された使用法：共通。このメディアタイプは、多くのタイプのデバイスでのストリーミング、VoIP、およびメッセージングアプリケーションで広く使用されています。
Restrictions on usage: When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4 SHALL be used. In all other contexts, the file format defined in Section 5 SHALL be used.
使用法の制限：このメディアタイプがRTPを介した転送のコンテキストで使用される場合、セクション4で指定されたRTPペイロード形式を使用するものとします。他のすべてのコンテキストでは、セクション5で定義されているファイル形式を使用するものとします。
Author:
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>
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) [11], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the AMR or AMR-WB codec, the mapping is as follows:
メディアタイプの仕様に掲載されている情報には、セッション説明プロトコル（SDP）[11]のフィールドへの特定のマッピングがあります。これは、RTPセッションを説明するために一般的に使用されます。SDPがAMRまたはAMR-WBコーデックを使用したセッションを指定するために使用される場合、マッピングは次のとおりです。
- The media type ("audio") goes in SDP "m=" as the media name.
- メディアタイプ（ "Audio"）は、メディア名としてSDP "m ="になります。
- The media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 8000 for AMR and 16000 for AMR-WB, and the encoding parameters (number of channels) MUST either be explicitly set to N or omitted, implying a default value of 1. The values of N that are allowed are specified in Section 4.1 in [12].
- メディアサブタイプ（ペイロード形式名）は、エンコーディング名としてSDP "a = rtpmap"になります。「a = rtpmap」のRTPクロックレートはAMRで8000、AMR-WBで16000でなければならず、エンコードパラメーター（チャネルの数）は明示的にnに設定するか、省略している必要があります。許可されているNの[12]のセクション4.1で指定されています。
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
- パラメーター「PTIME」と「MAXPTIME」は、それぞれSDP「A = PTIME」と「A = MaxPtime」属性に移動します。
- Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the media type parameter string as a semicolon-separated list of parameter=value pairs.
- 残りのパラメーターは、Parameter = valueペアのセミコロン分離リストとしてメディアタイプパラメーター文字列から直接コピーすることにより、SDP "a = fmtp"属性になります。
The following considerations apply when using SDP Offer-Answer procedures to negotiate the use of AMR or AMR-WB payload in RTP:
RTPでのAMRまたはAMR-WBペイロードの使用を交渉するためにSDPオファーアンドワープロシージャを使用する場合、以下の考慮事項が適用されます。
- Each combination of the RTP payload transport format configuration parameters (octet-align, crc, robust-sorting, interleaving, and channels) is unique in its bit-pattern and not compatible with any other combination. When creating an offer in an application desiring to use the more advanced features (crc, robust-sorting, interleaving, or more than one channel), the offerer is RECOMMENDED to also offer a payload type containing only the octet-aligned or bandwidth-efficient configuration with a single channel. If multiple configurations are of interest to the application, they may all be offered; however, care should be taken not to offer too many payload types. An SDP answerer MUST include, in the SDP answer for a payload type, the following parameters unmodified from the SDP offer (unless it removes the payload type): "octet-align"; "crc"; "robust-sorting"; "interleaving"; and "channels". The SDP offerer and answerer MUST generate AMR or AMR-WB packets as described by these parameters.
- RTPペイロードトランスポートフォーマット構成パラメーター（Octet-Align、CRC、Robust-Sorting、Interleaving、およびChannels）の各組み合わせは、ビットパターンで一意であり、他の組み合わせと互換性がありません。より高度な機能（CRC、堅牢なソルティング、インターリービング、または複数のチャネル）を使用したいアプリケーションでオファーを作成する場合、オファー整列または帯域幅効率の高いもののみを含むペイロードタイプも提供することをお勧めします単一のチャネルを使用した構成。複数の構成がアプリケーションにとって興味深い場合、それらはすべて提供される場合があります。ただし、あまりにも多くのペイロードタイプを提供しないように注意する必要があります。SDP回答者には、ペイロードタイプのSDP回答に、SDPオファーから変更されていない次のパラメーター（ペイロードタイプを削除しない限り）を含める必要があります。「CRC」;「堅牢なソルティング」;「インターリービング」;および「チャンネル」。SDPオファーと回答者は、これらのパラメーターで説明されているように、AMRまたはAMR-WBパケットを生成する必要があります。
- The "mode-set" parameter can be used to restrict the set of active AMR/AMR-WB modes used in a session. This functionality is primarily intended for gateways to access networks such as GSM or 3GPP UMTS, where the access network may be capable of supporting only a subset of AMR/AMR-WB modes. The 3GPP preferred codec configurations are defined in 3GPP TS 26.103 [25], and it is RECOMMENDED that other networks also needing to restrict the mode set follow the preferred codec configurations defined in 3GPP for greatest interoperability.
- 「モードセット」パラメーターを使用して、セッションで使用されるアクティブなAMR/AMR-WBモードのセットを制限できます。この機能は、主にGSMや3GPP UMTなどのネットワークにアクセスするためのゲートウェイを対象としています。アクセスネットワークは、AMR/AMR-WBモードのサブセットのみをサポートできる場合があります。3GPP優先コーデック構成は3GPP TS 26.103 [25]で定義されており、モードセットを制限する必要がある他のネットワークは、最大の相互運用性のために3GPPで定義された優先コーデック構成に従うことをお勧めします。
The parameter is bi-directional, i.e., the restricted set applies to media both to be received and sent by the declaring entity. If a mode set was supplied in the offer, the answerer SHALL return the mode-set unmodified or reject the payload type. However, the answerer is free to choose a mode-set in the answer only if no mode-set was supplied in the offer for a unicast two-peer session. The mode-set in the answer is binding both for offerer and answerer. Thus, an offerer supporting all modes and subsets SHOULD NOT include the mode-set parameter. For any other offerer it is RECOMMENDED to include each mode-set it can support as a separate payload type within the offer. For multicast sessions, the answerer SHALL only participate in the session if it supports the offered mode-set. Thus, it is RECOMMENDED that any offer for a multicast session include only the mode-set it will require the answerers to support, and that the mode-set be likely to be supported by all participants.
パラメーターは双方向です。つまり、制限付きセットは、宣言されたエンティティによって受信および送信されるメディアに適用されます。オファーにモードセットが提供された場合、回答者はモードセットを変更していないか、ペイロードタイプを拒否します。ただし、回答者は、ユニキャスト2ピアセッションのオファーでモードセットが提供されなかった場合にのみ、回答のモードセットを自由に選択できます。答えのモードセットは、OffererとResunserの両方に拘束されます。したがって、すべてのモードとサブセットをサポートするオファーは、モードセットパラメーターを含めるべきではありません。他のオファーの場合、オファー内の個別のペイロードタイプとしてサポートできる各モードセットを含めることをお勧めします。マルチキャストセッションの場合、応答者は、提供されたモードセットをサポートしている場合にのみセッションに参加するものとします。したがって、マルチキャストセッションのオファーには、応答者がサポートする必要があるモードセットのみを含めることをお勧めし、モードセットがすべての参加者によってサポートされる可能性があります。
- The parameters "mode-change-period" and "mode-change-capability" are intended to be used in sessions with gateways, for example, when interoperating with GSM networks. Both parameters are declarative and are combined to allow a session participant to determine if the payload type can be supported. The mode-change-period will indicate what the offerer or answerer requires of data it receives, while the mode-change-capability indicates its transmission capabilities.
- パラメーター「モードチェンジ期間」および「モードチェンジキャピール」は、GSMネットワークとの相互協力など、ゲートウェイとのセッションで使用することを目的としています。両方のパラメーターは宣言的であり、セッション参加者がペイロードタイプをサポートできるかどうかを判断できるように組み合わされます。モードチェンジ期間は、オファーまたは応答者が受信するデータに必要なものを示し、モードチェンジキャピールはその伝送機能を示します。
A mode-change-period=2 in the offer indicates a requirement on the answerer to send with a mode-change period of 2, i.e., support mode-change-capability=2. If the answerer requires mode-change-period=2, it SHALL only include it in the answer if the offerer either has indicated support with mode-change-capability=2 or has indicated mode-change-period=2; otherwise, the payload type SHALL be rejected. An offerer that supports mode-change-capability=2 SHALL include the parameter in all offers to ensure the greatest possible interoperability, unless it includes mode-change-period=2 in the offer. The mode-change-capability SHOULD be included in answers. It is then indicating the answerer's capability to transmit with that mode-change-period for the provided payload format configuration. The information is useful in future re-negotiation of the payload formats.
オファーのモードチェンジ期間= 2は、2のモード変更期間、つまりサポートモードチェンジキャピール= 2で送信するための回答者の要件を示しています。応答者がモードチェンジ期間= 2を必要とする場合、オファーがモードチェンジキャピール= 2でサポートを示しているか、モードチェンジ - 周期= 2を示している場合、オファーがサポートを示している場合にのみ、回答に含めるものとします。それ以外の場合、ペイロードタイプは拒否されます。モードチェンジキャピール= 2をサポートするオファーは、オファーにモードチェンジ期間= 2が含まれていない限り、可能な限り最大の相互運用性を確保するために、すべてのオファーにパラメーターを含めるものとします。モードチェンジキャピールを回答に含める必要があります。次に、提供されたペイロード形式の構成のために、そのモードチェンジ期間で送信する回答者の能力を示しています。この情報は、将来のペイロード形式の再交渉に役立ちます。
- The parameter "mode-change-neighbor" is a recommendation to restrict the switching of codec modes to its neighbor and SHOULD be followed. It is intended to be used in gateway scenarios (for example, to GSM networks) where the support of this parameter and the operations it implies improves interoperability.
- パラメーター「Mode-Change-Neighbor」は、コーデックモードの近隣への切り替えを制限することを推奨しているため、従う必要があります。このパラメーターのサポートと操作が相互運用性を改善することを意味するゲートウェイシナリオ（たとえば、GSMネットワークなど）で使用することを目的としています。
"mode-change-neighbor" is a declarative parameter. By including the parameter, the offerer or answerer indicates that it desires to receive streams with "mode-change-neighbor" restrictions.
「Mode-Change-Neighbor」は宣言的なパラメーターです。パラメーターを含めることにより、オファーまたは応答者は、「モードチェンジneighbor」の制限でストリームを受け取ることを望んでいることを示します。
- In most cases, the parameters "maxptime" and "ptime" will not affect interoperability; however, the setting of the parameters can affect the performance of the application. The SDP offer-answer handling of the "ptime" parameter is described in RFC 3264 [13]. The "maxptime" parameter MUST be handled in the same way.
- ほとんどの場合、パラメーター「maxptime」と「ptime」は相互運用性に影響しません。ただし、パラメーターの設定は、アプリケーションのパフォーマンスに影響を与える可能性があります。「PTIME」パラメーターのSDPオファーアンドワー処理は、RFC 3264 [13]で説明されています。「MaxPtime」パラメーターも同じ方法で処理する必要があります。
- The parameter "max-red" is a stream property parameter. For send-only or send-recv unicast media streams, the parameter declares the limitation on redundancy that the stream sender will use. For recvonly streams, it indicates the desired value for the stream sent to the receiver. The answerer MAY change the value, but is RECOMMENDED to use the same limitation as the offer declares. In the case of multicast, the offerer MAY declare a limitation; this SHALL be answered using the same value. A media sender using this payload format is RECOMMENDED to always include the "max-red" parameter. This information is likely to simplify the media stream handling in the receiver. This is especially true if no redundancy will be used, in which case "max-red" is set to 0. As this parameter was not defined originally, some senders will not declare this parameter even if it will limit or not send redundancy at all.
- パラメーター「max-red」は、ストリームプロパティパラメーターです。送信のみまたはSend-Recv Unicastメディアストリームの場合、パラメーターは、ストリーム送信者が使用する冗長性の制限を宣言します。Recvonlyストリームの場合、レシーバーに送信されたストリームの望ましい値を示します。応答者は値を変更する場合がありますが、オファーが宣言するのと同じ制限を使用することをお勧めします。マルチキャストの場合、提供者は制限を宣言することができます。これは、同じ値を使用して回答するものとします。このペイロード形式を使用するメディア送信者は、常に「最大レッド」パラメーターを含めるようにお勧めします。この情報は、受信機のメディアストリームの処理を簡素化する可能性があります。これは、冗長性が使用されない場合に特に当てはまります。この場合、「max-red」は0に設定されています。このパラメーターは元々定義されていなかったため、一部の送信者は、冗長性を制限するか、まったく送信しない場合でもこのパラメーターを宣言しません。。
- Any unknown parameter in an offer SHALL be removed in the answer.
- オファー内の未知のパラメーターは、回答で削除されるものとします。
In declarative usage, like SDP in RTSP [29] or SAP [30], the parameters SHALL be interpreted as follows:
RTSP [29]やSAP [30]のSDPのように、宣言的使用法では、パラメーターは次のように解釈されなければなりません。
- The payload format configuration parameters (octet-align, crc, robust-sorting, interleaving, and channels) are all declarative, and a participant MUST use the configuration(s) that is provided for the session. More than one configuration may be provided if necessary by declaring multiple RTP payload types; however, the number of types should be kept small.
- ペイロード形式の構成パラメーター（Octet-Align、CRC、Robust-Sorting、Interleaving、およびChannels）はすべて宣言的であり、参加者はセッションに提供される構成を使用する必要があります。複数のRTPペイロードタイプを宣言することにより、必要に応じて複数の構成を提供できます。ただし、タイプの数は小さくする必要があります。
- Any restriction of the AMR or AMR-WB encoder mode-switching and mode usage through the "mode-set", and "mode-change-period" MUST be followed by all participants of the session. The restriction indicated by "mode-change-neighbor" SHOULD be followed. Please note that such restrictions may be necessary if gateways to other transport systems like GSM participate in the session. Failure to consider such restrictions may result in failure for a peer behind such a gateway to correctly receive all or parts of the session. Also, if different restrictions are needed by different peers in the same session (unless a common subset of the restrictions exists), some peer will not be able to participate. Note that the usage of mode-change-capability is meaningless when no negotiation exists, and can thus be excluded in any declarations.
- AMRまたはAMR-WBエンコーダーモードのスイッチングと「モードセット」および「モードチェンジ期間」を介したモードの使用法の制限には、セッションのすべての参加者が続く必要があります。「モードチェンジneighbor」で示される制限に従う必要があります。GSMのような他の輸送システムへのゲートウェイがセッションに参加している場合、そのような制限が必要になる場合があることに注意してください。そのような制限を考慮しないと、そのようなゲートウェイの後ろのピアがセッションのすべてまたは一部を正しく受信することが失敗する可能性があります。また、同じセッションで異なるピアによって異なる制限が必要な場合（制限の一般的なサブセットが存在しない限り）、一部のピアは参加できません。交渉が存在しない場合、モード変更能力の使用は無意味であるため、宣言で除外できることに注意してください。
- Any "maxptime" and "ptime" values should be selected with care to ensure that the session's participants can achieve reasonable performance.
- セッションの参加者が合理的なパフォーマンスを達成できるようにするために、「最大」および「PTIME」値を注意して選択する必要があります。
- The usage of "max-red" puts a global upper limit on the usage of redundancy that needs to be followed by all that understand the parameter. However, due to the late addition of this parameter, it may be ignored by some implementations.
- 「Max-Red」の使用は、パラメーターを理解しているすべてのものが従う必要がある冗長性の使用にグローバルな上限をもたらします。ただし、このパラメーターの追加により、いくつかの実装によって無視される場合があります。
Some example SDP session descriptions utilizing AMR and AMR-WB encodings follow. In these examples, long a=fmtp lines are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line and the carriage return that follows it should be ignored.
AMRおよびAMR-WBエンコーディングを使用したSDPセッションの説明の例が続きます。これらの例では、このドキュメントの列幅の制約を満たすために、長いA = FMTP行が折りたたまれています。行の終わりにあるバックスラッシュ（ "\"）とその後のキャリッジは無視する必要があります。
In an example of the usage of AMR in a possible GSM gateway-to-gateway scenario, the offerer is capable of supporting three different mode-sets and needs the mode-change-period to be 2 in combination with mode-change-neighbor restrictions. The other gateway can only support two of these mode-sets and removes the payload type 97 in the answer. If the offering GSM gateway only supports a single mode-set active at the same time, it should consider doing the 1 out of N selection procedures described in Section 10.2 of [13]: Offer:
GSMゲートウェイからゲートウェイへのシナリオの可能性におけるAMRの使用例では、オファーは3つの異なるモードセットをサポートすることができ、モードチェンジ期間をモードチェンジ隣人制限と組み合わせて2にする必要があります。。他のゲートウェイは、これらのモードセットのうち2つのみをサポートでき、回答でペイロードタイプ97を削除できます。提供されているGSMゲートウェイが同時にアクティブな単一モードセットをサポートする場合、[13]のセクション10.2で説明されている1の選択手順を実行することを検討する必要があります。
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=rtpmap:99 AMR/8000/1
a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=maxptime:20
Answer:
答え：
m=audio 49120 RTP/AVP 98 99
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \<
mode-change-capability=2; mode-change-neighbor=1
a=rtpmap:99 AMR/8000/1
a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=maxptime:20
The following example shows the usage of AMR between a non-GSM endpoint and a GSM gateway. The non-GSM offerer requires no restrictions of the mode-change-period or mode-change-neighbor, but must signal its mode-change-capability in the offer and abide by those restrictions in the answer.
次の例は、非GSMエンドポイントとGSMゲートウェイの間のAMRの使用を示しています。非GSMオファーは、モードチェンジ期間またはモードチェンジneighborの制限を必要としませんが、オファーにおけるモード変更のキャピリティを信号し、回答のそれらの制限を順守する必要があります。
Offer:
オファー：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-change-capability=2
a=maxptime:20
Answer:
答え：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=maxptime:20
Example of usage of AMR-WB in a possible VoIP scenario where UEP may be used (99) and a fallback declaration (98):
UEPを使用する可能性のあるVoIPシナリオ（99）およびフォールバック宣言（98）でのAMR-WBの使用例：
m=audio 49120 RTP/AVP 99 98
a=rtpmap:98 AMR-WB/16000
a=fmtp:98 octet-align=1; mode-change-capability=2
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2
Example of usage of AMR-WB in a possible streaming scenario (two channel stereo):
可能なストリーミングシナリオ（2チャンネルステレオ）でのAMR-WBの使用例：
m=audio 49120 RTP/AVP 99
a=rtpmap:99 AMR-WB/16000/2
a=fmtp:99 interleaving=30
a=maxptime:100
Note that the payload format (encoding) names are commonly shown in upper case. MIME subtypes are commonly shown in lower case. 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サブタイプは、一般的に小文字で表示されます。これらの名前は、両方の場所でケースに依存しません。同様に、パラメーター名は、MIMEタイプとデフォルトマッピングの両方でSDP A = FMTP属性の両方でケース非感受性です。
Two media types (audio/AMR and audio/AMR-WB) have been updated; see Section 8.
2つのメディアタイプ（Audio/AMRとAudio/AMR-WB）が更新されました。セクション8を参照してください。
The differences between RFC 3267 and this document are as follows:
RFC 3267とこのドキュメントの違いは次のとおりです。
- Added clarification of behavior in regards to mode change period and mode-change neighbor that is expected from an IP client; see Section 4.5.
- IPクライアントから予想されるモードの変更期間とモード変更隣人に関する動作の明確化を追加しました。セクション4.5を参照してください。
- Updated the maxptime for better clarification. The sentence that previously read: "The time SHOULD be a multiple of the frame size." now says "The time SHOULD be an integer multiple of the frame size." This should have no impact on interoperability.
- より良い明確化のために、Maxptimeを更新しました。以前に読んだ文章：「時間はフレームサイズの倍数である必要があります。」今、「時間はフレームサイズの整数倍でなければならない」と言っています。これは相互運用性に影響を与えないはずです。
- Updated the definition of the mode-set parameter for clarification.
- 明確化のためのモードセットパラメーターの定義を更新しました。
- Restricted the values for mode-change-period to 1 or 2, which are the values used in circuit-switched AMR systems.
- モードチェンジ期間の値を1または2に制限しました。これは、回路で切り替えられたAMRシステムで使用される値です。
- Added a new media type parameter Mode-Change-Capability that defaults to 1, which is the assumed behavior of any non-updated implementation. This enables the offer-answer procedures to work.
- デフォルトで1にデフォルトの新しいメディアタイプパラメーターモードチェンジキャピールを追加しました。これにより、オファーアンスワーの手順が機能します。
- Changed mode-change-neighbor to indicate a recommended behavior rather than a required one.
- 変更された動作ではなく、推奨される動作を示すために、モードチェンジニーグボルを変更しました。
- Added an Offer-Answer Section, see Section 8.3.1. This will have implications on the interoperability to implementations that have guessed how to perform offer/answer negotiation of the payload parameters.
- オファー回答セクションを追加しました。セクション8.3.1を参照してください。これは、ペイロードパラメーターのオファー/回答交渉の実行方法を推測した実装に対する相互運用性に影響を与えます。
- Clarified and aligned the unequal detection usage with the published UDP-Lite specification in Sections 3.6.1 and 4.4.2.1. This included replacing a normative statement about packet handling with an informative paragraph with a reference to UDP-Lite.
- セクション3.6.1および4.4.2.1に公開されたUDP-LITE仕様を使用して、不均等検出の使用を明確にし、整列させました。これには、UDP-Liteへの参照を使用して、パケット処理に関する規範的な声明を有益な段落に置き換えることが含まれていました。
- Clarified the bit order in the CRC calculation in Section 4.4.2.1.
- セクション4.4.2.1のCRC計算のビット順序を明確にしました。
- Corrected the reference in Section 5.3 for the Q and FT fields.
- QフィールドとFTフィールドのセクション5.3の参照を修正しました。
- Changed the padding bit definition in Sections 4.4.2 and 5.3 so that it is clear that they shall be ignored.
- セクション4.4.2および5.3のパディングビットの定義を変更したため、それらは無視されることが明らかです。
- Added a clarification that comfort noise frames with frame type 9, 10, and 11 SHALL NOT be used in the AMR file format.
- フレームタイプ9、10、および11の快適なノイズフレームをAMRファイル形式で使用しないという明確化を追加しました。
- Clarified in Section 4.3.2 that the rules about not sending NO_DATA frames do apply for all payload format configurations with the exception of the interleaved mode.
- セクション4.3.2で、NO_DATAフレームを送信しないことに関するルールは、インターリーブモードを除き、すべてのペイロード形式構成に適用されることを明確にしました。
- The reference list has been updated to now published RFCs: RFC 3448, RFC 3550, RFC 3551, RFC 3711, RFC 3828, and RFC 4566. A reference to 3GPP TS 26.101 has also been added.
- 参照リストは、現在公開されているRFC 3448、RFC 3550、RFC 3551、RFC 3711、RFC 3828、およびRFC 4566に更新されました。3GPPTS 26.101への参照も追加されています。
- Added notes in storage format section and media type registration that AMR and AMR-WB frames can also be stored in the 3GP file format.
- AMRおよびAMR-WBフレームを3GPファイル形式に保存できるというストレージ形式のセクションとメディアタイプの登録で追加のメモを追加しました。
- Added a media type parameter "max-red" that allows the sender to declare a bounded usage of redundancy. This parameter allows a receiver to optimize its function as it will know if redundancy will be used or not. If it is used, the maximum extra delay introduced by the sender (that is needed to be considered by the receiver to fully utilize the redundancy) will be known. The addition of this parameter should have no negative effects on older implementations as they are mandated to ignore unknown parameters per RFC 3267. In addition, older implementations are required to operate as if the value of max-red is unknown and possibly infinite.
- 送信者が冗長性の限界使用を宣言できるようにするメディアタイプパラメーター「Max-Red」を追加しました。このパラメーターにより、レシーバーは冗長性が使用されるかどうかがわかるため、その機能を最適化できます。使用すると、送信者によって導入された最大余分な遅延（レシーバーが冗長性を完全に活用するために考慮する必要があります）が既知になります。このパラメーターの追加は、RFC 3267あたりの未知のパラメーターを無視することが義務付けられているため、古い実装にマイナスの影響を与えるべきではありません。さらに、Max-Redの値が不明であり、おそらく無限であるかのように動作するためには、古い実装が必要です。
- Updated the media type registration to comply with the new registration rules.
- 新しい登録規則に準拠するために、メディアタイプの登録を更新しました。
- Moved section on decoding validation from Security Considerations to Implementation Considerations, where it makes more sense.
- セキュリティの考慮事項から実装の考慮事項への解読の検証に関するセクションを移動しました。
- Clarified the application of encryption, integrity protection, and authentication mechanism to the payload.
- パイロードへの暗号化、整合性保護、および認証メカニズムの適用を明確にしました。
The authors would like to thank Petri Koskelainen, Bernhard Wimmer, Tim Fingscheidt, Sanjay Gupta, Stephen Casner, and Colin Perkins for their significant contributions made throughout the writing and reviewing of RFC 3267 and this replacement. The authors would also like to thank Richard Ejzak, Thomas Belling, and Gorry Fairhurst for their input on this replacement of RFC 3267.
著者は、RFC 3267とこの代替の執筆とレビューを通して行われた重要な貢献について、Petri Koskelainen、Bernhard Wimmer、Tim Fingscheidt、Sanjay Gupta、Stephen Casner、Colin Perkinsに感謝します。著者はまた、RFC 3267のこの置き換えに関する意見について、リチャード・エジザック、トーマス・ベリング、ゴリー・フェアハーストに感謝したいと思います。
[1] 3GPP TS 26.090, "Adaptive Multi-Rate (AMR) speech transcoding", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[1] 3GPP TS 26.090、「Adaptive Multi-Rate（AMR）Speech Transcoding」、バージョン4.0.0（2001-03）、第3世代パートナーシッププロジェクト（3GPP）。
[2] 3GPP TS 26.101, "AMR Speech Codec Frame Structure", version 4.1.0 (2001-06), 3rd Generation Partnership Project (3GPP).
[2] 3GPP TS 26.101、「AMR音声コーデックフレーム構造」、バージョン4.1.0（2001-06）、第3世代パートナーシッププロジェクト（3GPP）。
[3] 3GPP TS 26.190 "AMR Wideband speech codec; Transcoding functions", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[3] 3GPP TS 26.190 "AMRワイドバンド音声コーデック、トランスコーディング関数」、バージョン5.0.0（2001-03）、第3世代パートナーシッププロジェクト（3GPP）。
[4] 3GPP TS 26.201 "AMR Wideband speech codec; Frame Structure", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[4] 3GPP TS 26.201 "AMRワイドバンド音声コーデック、フレーム構造"、バージョン5.0.0（2001-03）、第3世代パートナーシッププロジェクト（3GPP）。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] 3GPP TS 26.093, "AMR Speech Codec; Source Controlled Rate operation", version 4.0.0 (2000-12), 3rd Generation Partnership Project (3GPP).
[6] 3GPP TS 26.093、「AMR音声コーデック、ソース制御レート操作」、バージョン4.0.0（2000-12）、第3世代パートナーシッププロジェクト（3GPP）。
[7] 3GPP TS 26.193 "AMR Wideband Speech Codec; Source Controlled Rate operation", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[7] 3GPP TS 26.193「AMRワイドバンド音声コーデック、ソース制御レート操作」、バージョン5.0.0（2001-03）、第3世代パートナーシッププロジェクト（3GPP）。
[8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[8] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[9] 3GPP TS 26.092, "AMR Speech Codec; Comfort noise aspects", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[9] 3GPP TS 26.092、「AMRスピーチコーデック、コンフォートノイズの側面」、バージョン4.0.0（2001-03）、第3世代パートナーシッププロジェクト（3GPP）。
[10] 3GPP TS 26.192 "AMR Wideband speech codec; Comfort Noise aspects", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[10] 3GPP TS 26.192「AMRワイドバンド音声コーデック、コンフォートノイズの側面」、バージョン5.0.0（2001-03）、第3世代パートナーシッププロジェクト（3GPP）。
[11] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[11] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[12] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[12] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[13] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[14] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[14] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[15] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[15] Casner、S。、「RTPペイロードフォーマットのメディアタイプ登録」、RFC 4855、2007年2月。
[16] GSM 06.60, "Enhanced Full Rate (EFR) speech transcoding", version 8.0.1 (2000-11), European Telecommunications Standards Institute (ETSI).
[16] GSM 06.60、「Enhanced Full Rate（EFR）音声トランスコーディング」、バージョン8.0.1（2000-11）、欧州通信標準研究所（ETSI）。
[17] ANSI/TIA/EIA-136-Rev.C, part 410 - "TDMA Cellular/PCS Radio Interface, Enhanced Full Rate Voice Codec (ACELP)". Formerly IS-641. TIA published standard, June 1 2001.
[17] ANSI/TIA/EIA-136-REV.C、パート410-「TDMAセルラー/PCS無線インターフェイス、強化されたフルレート音声コーデック（ACELP）」。以前はIS-641。TIA発行標準、2001年6月1日。
[18] ARIB, RCR STD-27H, "Personal Digital Cellular Telecommunication System RCR Standard", Association of Radio Industries and Businesses (ARIB).
[18] ARIB、RCR STD-27H、「パーソナルデジタルセルの通信システムRCR標準」、無線産業および企業協会（ARIB）。
[19] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[19] Larzon、L-A。、Degermark、M.、Pink、S.、Jonsson、L-E。、およびG. Fairhurst、「The Lightweight User Datagram Protocol（UDP-Lite）」、RFC 3828、2004年7月。
[20] 3GPP TS 25.415 "UTRAN Iu Interface User Plane Protocols", version 4.2.0 (2001-09), 3rd Generation Partnership Project (3GPP).
[20] 3GPP TS 25.415「UTRAN IUインターフェイスユーザープレーンプロトコル」、バージョン4.2.0（2001-09）、第3世代パートナーシッププロジェクト（3GPP）。
[21] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[21] Handley、M.、Floyd、S.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：プロトコル仕様」、RFC 3448、2003年1月。
[22] Li, A., et al., "An RTP Payload Format for Generic FEC with Uneven Level Protection", Work in Progress.
[22] Li、A.、et al。、「不均一なレベル保護を備えた一般的なFECのRTPペイロード形式」、進行中の作業。
[23] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[23] Rosenberg、J。およびH. Schulzrinne、「一般的なフォワードエラー補正のためのRTPペイロード形式」、RFC 2733、1999年12月。
[24] 3GPP TS 26.102, "AMR speech codec interface to Iu and Uu", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[24] 3GPP TS 26.102、「AMR Speech Codec Interface to IU and UU」、バージョン4.0.0（2001-03）、第3世代パートナーシッププロジェクト（3GPP）。
[25] 3GPP TS 26.202, "AMR Wideband speech codec; Interface to Iu and Uu", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[25] 3GPP TS 26.202、「AMR WideBand Speech Codec、IUおよびUUへのインターフェース」、バージョン5.0.0（2001-03）、第3世代パートナーシッププロジェクト（3GPP）。
[26] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[26] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「セキュアリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[27] 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.
[27] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-Parisis、 "RTPペイロードデータ」、RFC 2198、1997年9月。
[28] 3GPP TS 26.103, "Speech codec list for GSM and UMTS", version 5.5.0 (2004-09), 3rd Generation Partnership Project (3GPP).
[28] 3GPP TS 26.103、「GSMおよびUMTSの音声コーデックリスト」、バージョン5.5.5（2004-09）、第3世代パートナーシッププロジェクト（3GPP）。
[29] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[29] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[30] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[30] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[31] 3GPP TS 26.244, "3GPP file format (3GP)", version 6.1.0 (2004- 09), 3rd Generation Partnership Project (3GPP).
[31] 3GPP TS 26.244、「3GPPファイル形式（3GP）」、バージョン6.1.0（2004-09）、第3世代パートナーシッププロジェクト（3GPP）。
[32] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files", RFC 3839, July 2004.
[32] Castagno、R。およびD. Singer、「第3世代パートナーシッププロジェクト（3GPP）マルチメディアファイルのMIMEタイプ登録」、RFC 3839、2004年7月。
[33] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[33] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[34] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[34] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
ETSI documents are available from <http://www.etsi.org/>. 3GPP documents are available from <http://www.3gpp.org/>. TIA documents are available from <http://www.tiaonline.org/>.
ETSIドキュメントは<http://www.etsi.org/>から入手できます。3GPPドキュメントは、<http://www.3gpp.org/>から入手できます。TIAドキュメントは<http://www.tiaonline.org/>から入手できます。
Authors' Addresses
著者のアドレス
Johan Sjoberg Ericsson AB SE-164 80 Stockholm, SWEDEN
Johan Sjoberg 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
Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-B8 Arlington Heights, IL 60004, USA
Qiaobing Xie Motorola、Inc。1501 W. Shure Drive、2-B8 Arlington Heights、IL 60004、USA
Phone: +1-847-632-3028
EMail: Qiaobing.Xie@motorola.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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の情報を<％-ietf-ipr@ietf.orgに宛ててください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。