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
RTP適応マルチレート（AMR）と適応マルチレート広帯域（AMR-WB）オーディオコーデックのためのペイロードフォーマットとファイルストレージのフォーマット
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）IETFトラスト（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音声データを搬送するために指定されています。二つの別々のメディアタイプ登録はRTPペイロードフォーマットとストレージフォーマットの両方の使用を指定して、AMRのための1つおよびAMR-WBのための1つ含まれています。この文書は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.
この文書は、リアルタイムトランスポートプロトコル（RTP）にAMRおよびAMR-WB符号化された音声信号のパケットのためのペイロードのフォーマットを指定する[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.
ペイロードフォーマット自体は、関連するファイル形式は、電子メールなどのストレージモードアプリケーションにおけるAMRとAMR-WB音声データの転送については、セクション5で指定されたセクション4で指定されています。第8章では、2つの別個のメディアタイプ登録は、AMRのための1つおよびAMR-WBのための1つに設けられています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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 - 第三世代パートナーシッププロジェクトAMR - 適応マルチレート（コーデック）AMR-WB - 適応マルチレート広帯域（コーデック）CMR - コーデックモード要求CN - コンフォートノイズDTX - 不連続送信ETSI - 欧州電気通信標準化協会FEC - 前方エラー修正SCR - ソースレート操作SID制御 - サイレンスインジケータ（のみCNパラメータを含むフレーム）VAD - 音声アクティビティ検出UED - 不均一誤り検出UEP - 不均一誤り保護
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個の音声フレーム、チャネルのそれぞれからの1つを含有する、すべての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世代（3G）セルラシステムのために必須コーデックとして第3世代パートナーシッププロジェクト（3GPP）によって選択された[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であり、音声符号化は、20msの音声フレームに対して行われます。したがって、各符号化された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 [17]で7.4 kbpsのモードとして、IS-641コーデック、およびGSM-EFRとして12.2 kbpsのモード[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]元々GSMおよび3Gセルラシステムで使用されるように、3GPPによって開発されました。
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ヘルツであり、音声処理は、20msのフレームに対して行われます。これは、各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セッションまたはAMR-WBセッションのための9 AMR-WBモードの任意の組み合わせのための8つのAMRモードを任意に組み合わせることができます。
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とのより良い相互運用性のために、デコーダは、二つのモード変更の間でフレームの最小数を設定するためにのみ隣接モード間のモード変更を制限することを意味帯域外使用を許可されています。
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フレームがサイレンスインジケータ（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.
別々に符号化されたマルチチャネル・コンテンツをトランスポート（または記憶）するように、同じ20msの期間のフレームと符号化されているすべてのチャンネルの音声フレームは論理的フレームブロックに集められます。
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に分割され、そしてクラスAのビットが最も敏感とクラスCのビット最も敏感であるCは、（AMRおよび[については、以下の表1を参照します4] AMR-WBの場合）。最も敏感なビットに見られるビット誤り、すなわち、クラスAビットがある場合、AMRまたはAMR-WBフレームのみ破損宣言されます。一方、他のビット、すなわち、クラス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.
UEP / IPネットワークで使用されるAMRのクラスB / Cビットまたは各RTPペイロード内のAMR-WBフレーム（複数可）のクラスAビットと容認ビットエラーのビットエラーを検出することによって達成することができます。
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].
リンク層プロトコルは、例えば、SLIPおよびいくつかの無線リンク、ビットエラーを含むパケットを破棄しないことが存在します。複数のマルチメディア中心の1の方にシフトし、インターネットのトラフィックパターンで、そのような性質のより多くのリンク層は、将来的に出現することがあります。 （例えば、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）のみRTPペイロード内の各音声フレームのクラスAビットをカバーするために、IP、トランスポートプロトコル、RTPペイロードヘッダが、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ビットは微々たるものではなく、これらのビットで検出されないエラーは、音声品質の劣化を引き起こします。ユニバーサル・モバイル・テレコミュニケーション・システムにおいてAMRのために許容できると考え残留誤り率（UMTS）の例は、[25]に[24]および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フレームを輸送する場合、保護されたビットにおける単一ビット誤りがすべてのフレームが廃棄されるようにする可能性があります。
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は、クラス内の単一ビットエラービットがすべてのフレームが廃棄させることになるという可能性を取り除きます。ビットエラーの対象にリンクを介して複数の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を達成するための一つの方法です。より多くの帯域幅が効率的である別の可能な方式は、ペイロード外部FECリペアデータを含む余分なパケットを生成例えば、RFC 2733 [23]を使用することです。全体のペイロードはまた、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ペイロードパケットに一回再送されます。ここで、F（N-2）..（4 + N）F音声フレームブロックのシーケンスを示し、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.
この冗長方式は、[27]「冗長オーディオデータのRTPペイロード」、RFC 2198に記載のものと同じ機能を提供します。ほとんどの場合、このペイロードフォーマットのメカニズムは他に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のベース選択は、おそらく、例えば、非IP情報に基づいて、無線リンク性能指標を設定したべきではありません。送信者はまた、冗長性（詳細はセクション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つの動作モードの間、唯一のオクテット整列モードでは、パケットロスやビットエラーに音声の輸送をより堅牢にするために強力な並べ替え、インターリーブ、およびフレーム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に示すように、このペイロードフォーマットの一次シナリオは、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.
図3に示すようにAMRまたはAMR-WB符号化された音声は、IP / UDP / RTP VoIP端末に非IPシステム（例えば、GSMまたは3GPP UMTSネットワーク）から送信された、および/またはその逆されたときに別のシナリオであります。
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端末は、非IPデコーダに行くスピーチ品質を最適化するためにゲートウェイによって転送CMRに従うべきです。ゲートウェイにおけるモード制御アルゴリズムは、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値を設定することができます。所望であれば、一つは、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.
以下、図4に示すように、第3の可能性の高いシナリオは、IP / UDP / RTPは、二つの非IPシステムとの間のトランスポートとして使用されること、すなわち、IPは、IPトランスポートの両側のゲートウェイで発信され、終了されます。
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ネットワーク側のゲートウェイが受信したパケットに設定されてもよいです。ゲートウェイは、非IP側に3つの値の最小値であるCMR値を転送する必要があります。
- 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.
- CMR値は、それがIP側で伝送の輻輳制御のために選択することができます。
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タイムスタンプは、パケットの最初のフレームのブロックについて符号化された第1のサンプルのサンプリング時点に対応します。タイムスタンプユニットがサンプルにあるように、タイムスタンプのクロック周波数は、サンプリング周波数と同じです。
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のために、サンプリング周波数は、各チャネルからのフレーム当たり160個の符号化された音声サンプルに対応し、8kHzです。 AMR-WBのために、サンプリング周波数は、各チャネルからのフレーム当たり320個のサンプルに対応し、16kHzです。従って、タイムスタンプは各連続フレームブロックに対してAMR-WBのためにAMR 160及び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で定義されるようにインタリーブルールに従って取り出されます。そうでなければ、各パケットは、一つ以上の連続する20ミリ秒のフレームブロック間隔の期間をカバーします。場合期間中の特定のフレームブロックのすべてのチャネルからのデータが欠落している（例えば、いくつかの他のトランスポート・フォーマットからゲートウェイで）、そのデータがそのフレームブロックよりもむしろのために存在しないことを示すことができます4.3.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レートモードで、または1つのパケット内に存在し、別の中に存在しないデータと、正確な複製で、任意の音声フレームを受信するために複数回を準備しなければなりません。同じ音声フレームの複数のバージョンが受信される場合、最高速度とモードは、音声復号器によって使用されることが推奨されます。所与のフレームは、別の内の1つのパケットと快適雑音パラメータのスピーチとして符号化してはいけません。
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].
ペイロード長は必ずしも必要であれば、ゼロ・ビットでパディングすることによりオクテットの整数とします。追加のパディングオクテットのより大きな倍数にまたはいくつかの他の目的のためにペイロード長をもたらすために必要とされる場合には、ヘッダ内のRTPのPビットを設定することができるとで指定されるようにパディング添付[8]。
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）が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フィールドの値が要求されている対応する音声モードのフレームタイプのインデックスに設定されています。 〔4〕表1aに定義されるようにフレームタイプ指標は、AMR-WBのためにAMRのために0-7、[2]の表1aに定義されるように、または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が以前通話モードや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.
コーデックモードの選択が可能なモードのサブセットにセッションパラメータによって制限されることがあります。もしそうであれば、要求されたモードは、シグナリング部分集合（セクション8を参照）の中でなければなりません。受信されたCMR値がモードのシグナリング部分集合の外にある場合、それは無視しなければなりません。
The table of contents (ToC) consists of a list of ToC entries, each representing a speech frame.
目次（TOC）は、目次のエントリのリスト、それぞれ表す音声フレームから成ります。
In bandwidth-efficient mode, a ToC entry takes the following format:
帯域幅効率的なモードでは、目次のエントリは次の形式を取ります。
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ビット）モードまたはこのペイロードで運ばれ、対応するフレームの快適ノイズ（SID）符号化モードのいずれかAMRまたはAMR-WB音声を示すフレームタイプ指標、。
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およびAMR-WB [4]表1aに[2]の表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）フレーム、すなわち、そのフレームのための有効なデータがいずれかのANに送信することができる（そのフレームのためのデータが音声符号器によって生成されていないこと、またはそのフレームのためのデータが現在のペイロードで送信されないことのいずれかを意味する可能性が前または後パケット）。
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-WBのためのToC AMRの範囲は9-14でFTの値を持つエントリ又は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は、[7]の[6]と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.
標準化されたAMRコーデックのみに必要とされるので、[2]（すなわち、GSM-EFR CN、IS-641 CN、およびPDC-EFR CN）で表1aに指定された余分な快適雑音フレームタイプは、このペイロード形式で使用してはいけません組み込まれたエンコーディングに固有のもので、一般的な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に設定すると、ひどく破損している対応するフレームを示し、受信機はRX_TYPEを設定する必要がフレームタイプ（FT）に応じSPEECH_BADまたはSID_BADのいずれかに（[6]を参照）。
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.
[12]に、セクション4.1で定義されるようにマルチチャンネルセッションでは、フレームブロックから全てのフレームの目次のエントリは、連続した順序で目次に配置されています。複数のフレームブロックが帯域幅効率的なモードでパケット中に存在する場合、彼らは彼らの作成時間順にパケットに配置されます。
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音声フレームブロックと、目次にN * K個のエントリが存在しなければなりません、そして、最初のN個のエントリが最初のフレームのブロックからなり、第Nのエントリが第二フレームからなり - ブロック、というように。
The following figure shows an example of a ToC of three entries in a single-channel session using bandwidth-efficient mode.
次の図は、帯域幅効率の良いモードを使用して単一チャネルセッションにおける3つのエントリの目次の一例を示しています。
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).
以下のToCエントリは、2つのチャネル（L及びR）とのセッションに三つの連続フレームブロックを運ぶパケットの目次に表示される方法の一例です。
+----+----+----+----+----+----+
| 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.
ペイロードの目次に記載されているように、ペイロードの音声データは、ゼロまたはそれ以上の音声フレームまたは快適雑音フレームを含みます。
Note, for ToC entries with FT=14 or 15, there will be no corresponding speech frame present in the speech data.
FT = 14又は15に目次エントリのため、注意、音声データには、対応する音声フレームが存在しないであろう。
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ミリ秒を表します。音声フレームの長さは、暗黙FTフィールドに示さモードによって定義されます。ビットの順序と番号付け表記AMRのための[2]にインタフェースフォーマット1（IF1）に指定して[4] AMR-WBの場合と同様です。そこに指定されるように快適雑音フレームのビットは、エンコーダによって生成順序であるが、音声フレームのビットは、感度を低下させるために再配置されています。長さ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リストの対応する目次エントリによって定義される）ために、ペイロードヘッダ、コンテンツのテーブル、及び音声フレームからビットを充填することによって形成され、オクテット整列にペイロードをもたらすこと、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エントリの（0-3番の）4つの最上位ビットは最下位ビットのビット3で終わる、オクテットの最下位ビットにパックされています。パッキングは、オクテットの最上位ビットの最初のToCエントリのビット4と第2オクテットに継続します。複数のフレームがペイロードに含まれている場合、充填は、第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、NO_DATAにFTが設定された目次エントリが欠落フレーム毎に目次に含めなければならないが、何もデータビットが含まれていません欠落フレームのペイロードに（例えば、セクション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原点（= 1 Q）に損傷がない、及び符号化モードは、AMR 7.4 kbpsの（FT = 4）です。符号化された音声ビット、D（147）に、D（0）、[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).
次の図は、1つのない音声データを持たない4つのフレームを含む単一チャネル、帯域幅効率に優れた化合物AMR-WBのペイロードを示しています。最初のフレームは、音声から構成されている6.6 kbpsのモード（FT = 0）で音声フレームをD（131）に、D（0）ビットです。第二のフレームはG（39）ビットのG（0）から成る、AMR-WB SIDフレーム（FT = 9）です。第3のフレームは、それがその目次項目によってペイロードに表されている、NO_DATAフレームであり、任意の音声情報を搬送しません。ペイロード内の第4フレームが8.85 kbpsのモード（FT = 1）で音声フレームであり、それは時間（176）に音声ビットH（0）から成ります。
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）で破損することはありません。 Dに符号化された音声及びSIDビット、D（0）（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.
次の図は、すなわち、ペイロードが6音声フレームを含むことになる、3フレームブロックを運ぶ2チャネルペイロードを示しています。
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）のように定義されます。符号化された音声ビットは、X =ブロック番号、Y =チャネル、及びKは、そのモードのための音声ビットの数であるDXY（0）.. DXY（K-1）を、指定されています。これを例示する、左チャンネルのフレームブロック1のために、符号化されたビットはD1L（147）にD1L（0）として指定されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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:
以下に示すようにオクテット整列モードでは、ペイロードヘッダは、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より大きい発見された場合、ペイロードは廃棄されるべきです。
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分野はセッション内の各パケットに存在しなければなりません。インターリービングは、マルチチャンネルセッションで（すなわち、NOTフレーム単位で）フレームのブロック単位で行われなければなりません。
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:
次の例では、インターリーブセッション中にインタリーブグループにおける音声フレームブロックの配置を示します。ここでは、音声フレーム・ブロックnで開始インタリーブグループのILL = Lと仮定する。また、インタリーブグループの最初のペイロードパケットがSであり、各ペイロードに運ば音声フレームブロックの数がNである。そして、我々が持っていることを前提としています。
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)
ペイロードS（このインタリーブグループの最初のパケット）：ILL = L、ILP = 0は、フレームブロックを運ぶ：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) ...
ペイロードS + 1（このインタリーブグループの第2のパケット）：ILL = L、ILP = 1、フレームブロック：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)
ペイロードS + 1（このインタリーブグループの最後のパケット）：ILL = L、ILP = L、フレームブロック：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の値の数は、インタリーブグループ内で変更してはいけません。換言すれば、インタリーブグループ内のすべてのペイロードは同じ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 *（L + 1）未満又はIに等しくなるように、送信者は適切なペイロード当たりのフレームブロック（N）の数とILLを使用しなければなりません<=私。
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:
オクテット整列モードのコンテンツ（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.
インターリーブが使用される場合、目次のフレームブロックが時間的に連続して配置されていないことがほとんどないだろう：目次エントリのリストは、以下の例外を除いて、4.3.2で帯域幅効率的なモードについて記載したのと同じ方法で構成されています。代わりに、パケット内のフレームブロックの存在および順序は、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.
次の例は、インタリーブ2チャンネルのセッションでは、3つの連続したパケット三フレームブロックを運ぶそれぞれの目次示します。ここで、2つのチャネルが（L）とRの前に来るLと右（R）左され、インターリーブ長が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:
目次のエントリは、オクテット整列モードで次の形式を取ります。
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ビット長であり、ペイロードで運ばれた音声フレーム（NOTフレームブロック）に対応します。 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で説明されています。このセクションでは、UEDを達成するためにパーシャルトランスポート層チェックサムとともにオクテット整列ペイロードヘッダにフレームのCRCを使用する方法の詳細を提供します。
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を達成するために、一方がトランスポート層チェックサムを使用すべきである（例えば、UDP-Liteで定義され[19]）、IP、トランスポート・プロトコル（例えば、UDP-Liteの）、およびRTPヘッダ、ならびにペイロードを保護しますヘッダとペイロードの目次。フレーム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]、及びSIDフレーム（FT = 9）、40個のクラスAビットを有する表2に規定のように指定されています。クラス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ビットのデータの整合性を調べる必要があります。二つの値が一致した場合は、受信機が破損受信フレームのクラスAビットを考慮しなければならないフレームのQフラグをクリアしなければならない（すなわち、0に設定）。フレームのFTは、AMRのための8または9のためであれば、フレームのFTは、AMRのための0..7またはAMR-WBのため0..8、またはSID_BADである場合、これはその後、フレームが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):
以下の例は、（FTSのいずれも14又は15に等しくないと仮定して）単一チャネルセッションから3つの音声フレームを含むペイロードの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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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
大腸がんのそれぞれは、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
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が計算されなければならないその上、各ビットについて、XOR動作はの右端（LSB）ビットとの間に形成されていますCRCレジスタとビット。 CRCレジスタは、左端のビット（MSB）として「0」を入力し、右シフト一段階（各ビットの意味を1だけ減少される）です。上述のXOR演算結果が「1」である場合には、「10111000」がCRCレジスタにビット単位のXOR演算です。この操作は、CRCがカバーすべきビットごとに繰り返されます。この場合、最初のビットは、CRCがカバーすべき対象の音声フレームのため（0）~Dされるであろう。最後のビット（例えば、セクション3.6に表1に従ってAMR 5.9ためのD（54））このCRC計算に使用された場合、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:
セクション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.
- 複数の音声フレームの音声データ（すなわち、化合物のペイロード）中に存在する場合、音声フレームは、メディアに依存して、いつものように、またはオクテットレベルで一緒にインタリーブ全てのフレームのオクテットで次々一方フレーム全体に配置されていますペイロードタイプのために交渉のパラメータを入力します。各フレーム内のビットは、最初に最もエラー敏感なビットと一緒に注文されているので、オクテットインターリーブするパケットの先頭のより近くなるように、すべてのフレームからそれらの敏感なビットを収集します。これは、ペイロードデータの機構（例えばULP [22]など）またはUEP（例えば、UDP-Liteの[19]など）UEDの適用を可能にする「ロバストソーティング順序」と呼ばれます。ペイロードを組み立てるの詳細は次のセクションに記載されています。
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.
二つの異なるパケット化方法、すなわち、通常の順序で堅牢なソート順は、オクテット整列モードのペイロードを形成するために存在します。いずれの場合においても、コンテンツのペイロードヘッダとペイロードテーブルが同様に充填されています。違いは、音声フレームのパッキングです。
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が存在する場合。通常の順序でパケットのために、音声フレームを含むオクテットの全てがユニットとしてペイロードに付加されています。音声フレームは、所与のフレームはFT = 14又は15との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ヘッダ、ペイロードヘッダ、コンテンツのテーブル、およびクラスAビットをカバーすることが推奨されます。対象とする必要が正確にどのように多くのオクテットネットワークおよびアプリケーションに依存します。 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）二AMRフレームを搬送する単一チャネルペイロードタイプからオクテット整列されたペイロードを示します。ペイロードに、コーデックモード要求は、コーディングモードAMR 10.2 kbpsのを使用する受信機の側でエンコーダを要求し、（CMR = 6）が送られます。いいえフレーム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つのチャネルのペイロードタイプからオクテット整列されたペイロードを示します。 2フレームブロック、符号化モード7.95 kbpsの（FT = 5）の各々含む二音声フレームは、このペイロードで運ばれます。
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.
二つのチャンネルをLはペイロードにR.前に来ると（L）を左右（R）が、コーデックモード要求はまた、符号化モードAMR 10.2 kbpsのを使用する受信者側にエンコーダを要求し、（CMR = 6）に送られます。 。
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つのフレームは、フレームブロック＃1のL及びRチャンネル音声フレームは、それぞれ、ビットf1L（0..158）とF1R（0..158）からなります。次の二つのフレームがインターリーブによるビットそれぞれ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]を参照。ゲートウェイのシナリオでは、エンコーダは、ゲートウェイを超えてリンクに支持されている限られたモードのセットを使用する「モードセット」パラメータを介して要求することができます。少なくとも一つのフレームのブロックがレート制御情報を受信するまでさらに、そのリンク上の混雑を回避するために、エンコーダは、下位モードへのセッションの初期のコーデックモードを制限する必要があります。
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-WBからAMRを区別するために定義されています。
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).
（16進数または0x2321414d522d57425F4D43312E300a） "＃！AMR-WB_MC1.0の\ nを"。
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.
ファイルヘッダの後に、時間的に連続する音声フレームブロックは、ファイルに格納されています。各フレームブロックは、チャネルの数に等しく、及びチャンネル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.
4.4.3で定義されたように、この1つのオクテットのヘッダに続く音声ビット来ます。オクテット整列を達成するために、必要に応じて、各フレームの最後のオクテットは、ゼロでパディングされます。
The following example shows an AMR frame in 5.9 kbps coding mode (with 118 speech bits) in the storage format.
次の例では、ストレージフォーマットで（118音声ビットを有する）モードコーディング5.9 kbps単位での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更新との間の非受信音声フレームまたはフレームのブロックがNO_DATAフレームとして記憶されなければならない（で定義されるように、フレームタイプ15 [2]と[4]）。送信中に失われたフレームまたはフレームのブロックは、元のメディアとの同期を維持するために完全なフレームブロックにNO_DATAフレームまたはSPEECH_LOST（AMR-WBのためにのみ利用可能なフレームタイプ14）として格納されなければなりません。
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）（即ち、フレームタイプ9,10、およびAMR 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スピーチの機密性を達成するために、すべての音声データビットは、暗号化する必要があります。あるそれらが唯一要求された音声モード、フレームタイプ、フレーム品質に関する情報を運ぶこと、及びb）この情報は、いくつかの第三のに有用であり得ることペイロードヘッダ又はによるコンテンツのテーブルを暗号化する必要性）のより少ないですパーティ、例えば、品質監視。
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.
彼らは自分のメディアタイプによって区別しなければならない明確なエンコーディングであるため、二つの別々のメディアタイプの登録は、AMR用とAMR-WBのための1つを作っています。
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とメッセージングアプリケーションで広く使用されている音声コーデックであるので適応マルチレート（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.
オクテットアライン：1の場合許容値が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）、すなわち、コーデックモード変更が送信者に許可されるフレームブロック期間です。間隔の初期位相は任意であるが、変更、すなわち、2の値は、送信者がモードを毎秒フレームブロックを変更することができ、Nフレームブロックの期間によって分離されなければなりません。 Nの値は、このパラメータが存在しない場合、すなわち、モード変更は、セッション中にいつでも許可されている、1または2のいずれかであり、N = 1 SHALL。
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.
モード変更隣接：許容値は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.
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：1の場合許容値が0と1であり、フレームCRCはペイロードに含めなければなりません。 0または存在しない場合は、CRCは使用してはなりません。 1 = CRC場合、これはまた、オクテット整列動作はセッションのために使用しなければならないことを自動的に意味しています。
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.
堅牢なソート：1の場合許容値が0と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-赤：フレームのプライマリ（最初の）送信と送信者が使用する任意の冗長伝送の間に経過ミリ秒の最大継続時間。このパラメータは、冗長性を使用した場合、受信機が有界遅延を持つことができます。許容値は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、ストリーミングメディア、音声メッセージング、および音声。
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)
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音声フレームはまた、RFC 3839 [32]により登録されたメディアタイプ「オーディオ/ 3GPP」または「ビデオ/ 3GPP」を使用して識別され、3GPP TS 26.244 [31]で定義されたファイル形式「3GP」に格納されてもよいです。
Person & email address to contact for further information: Magnus Westerlund <magnus.westerlund@ericsson.com> Ari Lakaniemi <ari.lakaniemi@nokia.com>
人とEメールアドレスは、詳細のために連絡する：マグヌスウェスター<magnus.westerlund@ericsson.com>アリ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.
意図している用法：COMMON。このメディアタイプは、広く多くのタイプのデバイスにストリーミング、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>
著者：マグヌスウェスター<magnus.westerlund@ericsson.com>アリLakaniemi <ari.lakaniemi@nokia.com>
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
変更コントローラ：IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ。
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とメッセージングアプリケーションで広く使用されている音声コーデックであるので適応マルチレート広帯域（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.
オクテットアライン：1の場合許容値が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ネットワークのようなトランスポートチャネルをサポートすることができるように、例えば、すべてのモードのサブセットに設定アクティブコーデックモードを制限します。 ...、8（[4]表1aを参照）、0：使用可能な値がセットからモードのコンマ区切りのリストです。 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）、すなわち、コーデックモード変更が送信者に許可されるフレームブロック期間です。間隔の初期位相は任意であるが、変更、すなわち、2の値は、送信者がモードを毎秒フレームブロックを変更することができ、Nフレームブロックの倍数によって分離されなければなりません。 Nの値は、このパラメータが存在しない場合、すなわち、モード変更は、セッション中にいつでも許可されている、1または2のいずれかであり、N = 1 SHALL。
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.
モード変更隣接：許容値は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：1の場合許容値が0と1であり、フレームCRCはペイロードに含めなければなりません。 0または存在しない場合は、CRCは使用してはなりません。 1 = CRC場合、これはまた、オクテット整列動作はセッションのために使用しなければならないことを自動的に意味しています。
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.
堅牢なソート：1の場合許容値が0と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-赤：フレームのプライマリ（最初の）送信と送信者が使用する任意の冗長伝送の間に経過ミリ秒の最大継続時間。このパラメータは、冗長性を使用した場合、受信機が有界遅延を持つことができます。許容値は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、ストリーミングメディア、音声メッセージング、および音声。
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
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音声フレームはまた、[32] RFC 3839によって登録されたメディアタイプ「オーディオ/ 3GPP」または「ビデオ/ 3GPP」を用いて、3GPP TS 26.244 [31]で定義されており、識別された「3GP」ファイル形式で格納されてもよいです。
Person & email address to contact for further information: Magnus Westerlund <magnus.westerlund@ericsson.com> Ari Lakaniemi <ari.lakaniemi@nokia.com>
人とEメールアドレスは、詳細のために連絡する：マグヌスウェスター<magnus.westerlund@ericsson.com>アリ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.
意図している用法：COMMON。このメディアタイプは、広く多くのタイプのデバイスにストリーミング、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>
著者：マグヌスウェスター<magnus.westerlund@ericsson.com>アリLakaniemi <ari.lakaniemi@nokia.com>
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
変更コントローラ：IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ。
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [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:
メディアタイプ仕様で搬送される情報は、一般的にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）[11]のフィールドに特定のマッピングを有します。 SDPは、AMRまたはAMR-WBコーデックを使用するセッションを指定するために使用される場合、以下のように、マッピングは次のとおりです。
- The media type ("audio") goes in SDP "m=" as the media name.
- （「オーディオ」）メディアタイプは、メディア名として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-WBのためにAMRのための8000と16000でなければなりません、と符号化パラメータ（チャンネル数）は、明示的にNに設定するか省略し、1の値のデフォルト値を意味しなければならないのいずれかで[12]に、セクション4.1で指定されている許可されているNの。
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
- パラメータ "PTIME" と "maxptime" SDPに "= 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.
- 残りのパラメータは、パラメータ=値のペアをセミコロンで区切ったリストで、メディアタイプパラメータ文字列から直接コピーすることにより、SDPに「=の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ペイロードのトランスポートフォーマット設定パラメータ（オクテットアライン、CRCロバストソート、インターリーブ、およびチャネル）の各組み合わせは、ビットパターン及び任意の他の組み合わせに対応していない点で独特です。より高度な機能（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モードのセットを制限するために使用することができます。この機能は、主に、アクセスネットワークは、AMR / AMR-WBモードのサブセットのみをサポートすることが可能であるGSMまたは3GPP UMTSなどのネットワークにアクセスするゲートウェイのために意図されます。 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.
パラメータは、すなわち、制限されたセットの両方が宣言エンティティによって受信され、送信されるメディアに適用され、双方向性です。モードセットがオファーに供給された場合、回答者は、モード設定非修飾を返すか、ペイロードタイプを拒否しなければなりません。しかし、回答には、モードセットがユニキャストの二ピアセッションのためのオファーで供給されなかった場合にのみ、解答モードセットを自由に選択することができます。モード設定の回答では、オファー側とアンサーの両方に結合されます。したがって、すべてのモードおよびサブセットをサポートするオファーは、モード設定したパラメータを含むべきではありません。他のオファーのために、オファー内の別々のペイロードタイプとしてサポートすることができ、各モードセットを含むことが推奨されます。それが提供され、モード設定をサポートしている場合、マルチキャストセッションの場合、回答は唯一セッションに参加するものとします。したがって、マルチキャストセッションのための任意のオファーは専用モード設定、それは回答をサポートするために必要となる、とモードセットの可能性が高いことが、すべての参加者がサポートされるように含めることをお勧めします。
- 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.
- パラメータ「モード変更隣には」その隣人にコーデックモードの切り替えを制限するために推奨され、続くべきである（SHOULD）。このパラメータとそれが意味する動作のサポートは、相互運用性を向上させることができる場合には（例えば、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.
「モード変更隣人が」宣言型のパラメータです。パラメータを含めることで、オファー側またはアンサーは、「モード変更隣人」の制限付きでストリームを受信することを望むことを示しています。
- 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-赤は」ストリームプロパティ・パラメータです。以下の場合のみ、送信または送信-recvをユニキャストメディアストリームを、パラメータは、ストリームの送信者が使用する冗長性に制限を宣言します。 recvonlyでストリームの場合、それが受信機に送信されたストリームのための所望の値を示しています。回答は、値を変更する場合がありますが、オファーは宣言すると同じ制限を使用することをお勧めします。マルチキャストの場合には、提供者は、制限を宣言することができます。これは、同じ値を使用して回答するものとします。このペイロード形式を使用してメディアの送信者は、常に「MAX-赤」パラメータを含めることをお勧めします。この情報は、受信機にメディアストリームの処理を簡素化する可能性があります。冗長性は使用されません場合、これは特にそうです、「MAX-赤」が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でSDP [29]またはSAP [30]のように、パラメータは解釈されなければなりません。
- 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.
- ペイロードフォーマット設定パラメータ（オクテットアライン、CRCロバストソート、インターリーブ、およびチャネル）がすべての宣言であり、参加者は、セッションのために設けられている構成（複数可）を使用しなければなりません。以上の構成は、複数の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エンコーダモード切替モード使用の任意の制限セッションのすべての参加者が続かなければなりません。 「モードチェンジ-隣人」で示される制限に従う必要があります。 GSMのような他の交通機関へのゲートウェイがセッションに参加した場合、このような制限が必要な場合がありますのでご注意ください。そのような制限を考慮しないと、正しくセッションのすべてまたは一部を受け取るために、このようなゲートウェイの背後にあるピアの故障の原因となることがあります。別の制限は（制限の一般的なサブセットが存在しない限り）同じセッションで異なるピアによって必要とされている場合にも、いくつかのピアが参加することができません。モードチェンジ機能の使用が全く交渉が存在しない場合は無意味であり、したがって、任意の宣言の中で除外されることに注意してください。
- Any "maxptime" and "ptime" values should be selected with care to ensure that the session's participants can achieve reasonable performance.
- どれでも「maxptime」と「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-赤」の使用方法は、パラメータを理解し、すべてが続いする必要があり、冗長性の使用にグローバルな上限を置きます。しかし、このパラメータの後期添加による、それはいくつかの実装では無視することができます。
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]:
可能GSMゲートウェイ・ツー・ゲートウェイのシナリオにおけるAMRの使用例では、オファーは、3つの異なるモードのセットをサポートすることが可能であり、モード変更隣接制限と組み合わせて2となるようにモード変更期間を必要とします。他のゲートウェイは、これらのモードのセットのうちの2つをサポートし、応答におけるペイロードタイプ97を除去することができます。オファリングGSMゲートウェイは単一モード設定同時にアクティブにサポートしている場合、それは[13]のセクション10.2で説明さNの選択手順のうちの1を行って検討すべきです。
Offer:
提供：
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
M =オーディオ49120 RTP / AVP 97 98 99 = rtpmap：97 AMR / 1分の8000 A =のfmtp：97モード設定= 0,2,5,7と、モード変更期間= 2。 \モード変更機能= 2;モード変更隣接= 1 A = rtpmap：98 AMR / 1分の8000 A =のfmtp：98モード設定= 0,2,3,6と、モード変更期間= 2。 \モード変更機能= 2;モード変更隣接= 1 A = rtpmap：99 AMR / 1分の8000 A =のfmtp：99モード設定= 0,2,3,4と、モード変更期間= 2。 \モード変更機能= 2;モードチェンジ-隣人= 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
M =オーディオ49120 RTP / AVP 98 99 = rtpmap：98 AMR / 1分の8000 A =のfmtp：98モード設定= 0,2,3,6と、モード変更期間= 2。 \ <モード変更機能= 2;モード変更隣接= 1 A = rtpmap：99 AMR / 1分の8000 A =のfmtp：99モード設定= 0,2,3,4と、モード変更期間= 2。 \モード変更機能= 2;モードチェンジ-隣人= 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提供者は、モード変更の期間やモード変更隣の一切の制限を必要としませんが、提供して、そのモード変更機能を合図と答えにおけるそれらの制限を遵守しなければなりません。
Offer:
提供：
m=audio 49120 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-change-capability=2 a=maxptime:20
M =オーディオ49120 RTP / AVP 97 = rtpmap：97 AMR / 1分の8000 A =のfmtp：97モード変更能力= 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
M =オーディオ49120 RTP / AVP 97 = rtpmap：97 AMR / 1分の8000 A =のfmtp：97モード設定= 0,2,4,7と、モード変更期間= 2。 \モード変更機能= 2;モードチェンジ-隣人= 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のシナリオにおけるAMR-WBの使用例（99）とフォールバック宣言（98）：
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
M =オーディオ49120 RTP / AVP 99 98 = rtpmap：98 AMR-WB / 16000 =のfmtp：98オクテットアライン= 1。モードチェンジ能力= 2、A = rtpmap：99 AMR-WB / 16000 =のfmtp：99オクテットアライン= 1。 CRC = 1。モードチェンジ機能= 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
M =オーディオ49120 RTP / AVP 99 = rtpmap：99 AMR-WB / 2分の16000 A =のfmtp：99インターリーブ= 30 = 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つのメディアタイプ（オーディオ/ AMRオーディオ/ 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.
- 回線交換AMRシステムで使用される値である1又は2にモード変更期間の値を制限しました。
- 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.
- NO_DATAフレームを送信しないことについての規則は、インターリーブモードを除くすべてのペイロードフォーマットの構成に適用するかということ4.3.2項で明らかにしました。
- 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に更新されました：RFC 3448、RFC 3550、RFC 3551、RFC 3711、RFC 3828、およびRFC 4566. 3GPP TS 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-赤」を追加しました。このパラメータは、冗長性を使用するか、しないかをれる場合、それは知っているだろうと受信機がその機能を最適化することができます。それが使用される場合、送信者によって導入最大の余分な遅延が知られているであろう（すなわち、完全に冗長性を利用するために受信機によって考慮されるために必要とされます）。彼らはまたRFC 3267.あたりの未知のパラメータを無視するように義務付けられているとして、このパラメータの追加が古い実装に負の影響を持つべきではない、古い実装は、MAX-赤の値が不明、おそらく無限であるかのように動作することが求められています。
- 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の見直しと、この交換を通じて作られた彼らの重要な貢献のためにペトリKoskelainen、ベルンハルト・ウィマー、ティムFingscheidt、サンジェイ・グプタ、スティーブンCasner、およびコリンパーキンスに感謝したいと思います。著者らはまた、RFC 3267のこの交換に彼らの入力のためのリチャード・Ejzak、トーマスベリング、およびGorry Fairhurstに感謝したいと思います。
[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、 "適応マルチレート（AMR）音声トランスコーディング"、バージョン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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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.、フレデリック、R.、およびV.ヤコブソン、 "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]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[14] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[14]解放され、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、 "拡張フルレート（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.、ピンク、S.、ヨンソン、L-E。、およびG. Fairhurst、 "軽量ユーザーデータグラムプロトコル（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]ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（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]李、A.、ら、「不均一なレベルの保護を持つジェネリックFECのためのRTPペイロードフォーマット」が進行中で働いています。
[23] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[23]ローゼンバーグ、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、 "のIuとのUuにAMR音声コーデックインタフェース"、バージョン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広帯域音声コーデック、インタフェースの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.、マグリュー、D.、Naslund、M.、カララ、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]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ・ガルシア、A.、およびS.フォッシー-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.0（2004-09）、第3世代パートナーシッププロジェクト（3GPP）。
[29] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[29] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[30] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[30]ハンドレー、M.、パーキンス、C.、およびE.ウィーラン、 "セッション告知プロトコル"、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.
、RFC 3839、2004年7月、 "第3世代パートナーシッププロジェクト（3GPP）のマルチメディアファイルのMIMEタイプの登録" [32]カスターニョ、R.とD.歌手、。
[33] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[33]ケント、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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
ヨハン・シェーベルイエリクソンAB、SE-164 80ストックホルム、スウェーデン
Phone: +46 8 7190000 EMail: Johan.Sjoberg@ericsson.com
電話：+46 8 7190000 Eメール：Johan.Sjoberg@ericsson.com
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN
マグヌスウェスターエリクソン研究エリクソンAB、SE-164 80ストックホルム、スウェーデン
Phone: +46 8 7190000 EMail: Magnus.Westerlund@ericsson.com
電話：+46 8 7190000 Eメール：Magnus.Westerlund@ericsson.com
Ari Lakaniemi Nokia Research Center P.O.Box 407 FIN-00045 Nokia Group, FINLAND
アリLakaniemiノキア・リサーチセンターP.O.Box 407フィン-00045ノキアグループ、FINLAND
Phone: +358-71-8008000 EMail: ari.lakaniemi@nokia.com
電話：+ 358-71-8008000 Eメール：ari.lakaniemi@nokia.com
Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-B8 Arlington Heights, IL 60004, USA
私はIEモトローラ社1501 W.シュウ再ドライブをXオリンピックアイスQ、2-B8アーリントンハイツ、IL 60004、USA
Phone: +1-847-632-3028 EMail: Qiaobing.Xie@motorola.com
電話：+ 1-847-632-3028 Eメール：Qiaobing.Xie@motorola.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at <%ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 <%ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。