[要約] RFC 4348は、VMR-WBオーディオコーデックのためのRTPペイロード形式を定義しています。このRFCの目的は、VMR-WBオーディオデータのリアルタイム転送を可能にすることです。
Network Working Group S. Ahmadi
Request for Comments: 4348 January 2006
Category: Standards Track
Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec
可変レートマルチモードワイドバンド（VMR-WB）オーディオコーデックのリアルタイムトランスポートプロトコル（RTP）ペイロード形式
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. A media type registration is included for VMR-WB RTP payload format.
このドキュメントは、可変レートマルチモードワイドバンド（VMR-WB）音声コーデックに使用されるリアルタイムトランスポートプロトコル（RTP）ペイロード形式を指定します。ペイロード形式は、非IPネットワーク上の既存のVMR-WBトランスポートフォーマットと相互運用できるように設計されています。VMR-WB RTPペイロード形式には、メディアタイプの登録が含まれています。
VMR-WB is a variable-rate multimode wideband speech codec that has a number of operating modes, one of which is interoperable with AMR-WB (i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this document to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved.
VMR-WBは、多数の動作モードを備えた可変レートマルチモードワイドバンド音声コーデックで、そのうちの1つは特定のレートでAMR-WB（つまり、RFC 3267）オーディオコーデックと相互運用可能です。したがって、このドキュメントでは、トランスコーディング機能が含まれない相互運用モードでVMR-WBとAMR-WB間のデータパケット交換を促進および簡素化するための規定が作成されています。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions and Acronyms ........................................3
3. The Variable-Rate Multimode Wideband (VMR-WB) Speech Codec ......4
3.1. Narrowband Speech Processing ...............................5
3.2. Continuous vs. Discontinuous Transmission ..................6
3.3. Support for Multi-Channel Session ..........................6
4. Robustness against Packet Loss ..................................7
4.1. Forward Error Correction (FEC) .............................7
4.2. Frame Interleaving and Multi-Frame Encapsulation ...........8
5. VMR-WB Voice over IP Scenarios ..................................9
5.1. IP Terminal to IP Terminal .................................9
5.2. GW to IP Terminal .........................................10
5.3. GW to GW (between VMR-WB- and AMR-WB-Enabled Terminals) ...10
5.4. GW to GW (between Two VMR-WB-Enabled Terminals) ...........11
6. VMR-WB RTP Payload Formats .....................................12
6.1. RTP Header Usage ..........................................13
6.2. Header-Free Payload Format ................................14
6.3. Octet-Aligned Payload Format ..............................15
6.3.1. Payload Structure ..................................15
6.3.2. The Payload Header .................................15
6.3.3. The Payload Table of Contents ......................18
6.3.4. Speech Data ........................................20
6.3.5. Payload Example: Basic Single Channel
Payload Carrying Multiple Frames ...................21
6.4. Implementation Considerations .............................22
6.4.1. Decoding Validation and Provision for Lost
or Late Packets ....................................22
7. Congestion Control .............................................23
8. Security Considerations ........................................23
8.1. Confidentiality ...........................................24
8.2. Authentication and Integrity ..............................24
9. Payload Format Parameters ......................................24
9.1. VMR-WB RTP Payload MIME Registration ......................25
9.2. Mapping MIME Parameters into SDP ..........................27
9.3. Offer-Answer Model Considerations .........................28
10. IANA Considerations ...........................................29
11. Acknowledgements ..............................................29
12. References ....................................................30
12.1. Normative References .....................................30
12.2. Informative References ...................................30
This document specifies the payload format for packetization of VMR-WB-encoded speech signals into the Real-time Transport Protocol (RTP) [3]. The VMR-WB payload formats support transmission of single and multiple channels, frame interleaving, multiple frames per payload, header-free payload, the use of mode switching, and interoperation with existing VMR-WB transport formats on non-IP networks, as described in Section 3.
このドキュメントは、VMR-WBエンコードされた音声信号をリアルタイムトランスポートプロトコル（RTP）にパケット化するためのペイロード形式を指定します[3]。VMR-WBペイロードフォーマットは、シングルおよび複数のチャネルの送信、フレームインターリーブ、ペイロードあたりの複数のフレーム、ヘッダーフリーペイロード、モードスイッチングの使用、および非IPネットワーク上の既存のVMR-WBトランスポートフォーマットとの相互操作をサポートします。セクション3で。
The payload format is described in Section 6. The VMR-WB file format (i.e., for transport of VMR-WB speech data in storage mode applications such as email) is specified in [7]. In Section 9, a media type registration for VMR-WB RTP payload format is provided.
ペイロード形式はセクション6で説明されています。VMR-WBファイル形式（つまり、電子メールなどのストレージモードアプリケーションでのVMR-WB音声データの輸送用）は[7]で指定されています。セクション9では、VMR-WB RTPペイロード形式のメディアタイプの登録が提供されています。
Since VMR-WB is interoperable with AMR-WB at certain rates, an attempt has been made throughout this document to maximize the similarities with RFC 3267 while optimizing the payload format for the non-interoperable modes of the VMR-WB codec.
VMR-WBは特定のレートでAMR-WBと相互運用可能であるため、このドキュメント全体でRFC 3267の類似性を最大化し、VMR-WBコーデックの非挿入モードのペイロード形式を最適化する試みが行われました。
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 RFC2119 [2].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC2119 [2]に記載されているように解釈される。
The following acronyms are used in this document:
このドキュメントでは、次の頭字語が使用されています。
3GPP - The Third Generation Partnership Project 3GPP2 - The Third Generation Partnership Project 2 CDMA - Code Division Multiple Access WCDMA - Wideband Code Division Multiple Access GSM - Global System for Mobile Communications AMR-WB - Adaptive Multi-Rate Wideband Codec VMR-WB - Variable-Rate Multimode Wideband Codec CMR - Codec Mode Request GW - Gateway DTX - Discontinuous Transmission FEC - Forward Error Correction SID - Silence Descriptor TrFO - Transcoder-Free Operation UDP - User Datagram Protocol RTP - Real-Time Transport Protocol RTCP - RTP Control Protocol MIME - Multipurpose Internet Mail Extension SDP - Session Description Protocol VoIP - Voice-over-IP
3GPP-第3世代パートナーシッププロジェクト3GPP2-第3世代パートナーシッププロジェクト2 CDMA-コードディビジョン複数アクセスWCDMA-ワイドバンドコードディビジョンマルチアクセスGSM-モバイルコミュニケーション用グローバルシステムAMR -WB-適応型マルチレートワイドバンドコーデック - 変数-rateマルチモードワイドバンドコーデックCMR-コーデックモードリクエストGW-ゲートウェイDTX-不連続な伝送FEC-フォワードエラー修正SID -Silence Descriptor TRFO -TRANSCODER -FREE操作UDP -USER DATAGRAM Protocol RTP -REALIME TRANSPRANTION PROTOCOL RTCP -RTPコントロールプロトコルMIME MIME - 多目的インターネットメールエクステンションSDP-セッション説明プロトコルvoip -Voice -over -ip
The term "interoperable mode" in this document refers to VMR-WB mode 3, which is interoperable with AMR-WB codec modes 0, 1, and 2.
このドキュメントの「相互運用モード」という用語は、AMR-WBコーデックモード0、1、および2と相互運用可能なVMR-WBモード3を指します。
The term "non-interoperable modes" in this document refers to VMR-WB modes 0, 1, and 2.
このドキュメントの「非挿入モード」という用語は、VMR-WBモード0、1、および2を指します。
The term "frame-block" is used in this document to describe the time-synchronized set of speech frames in a multi-channel VMR-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 represent exactly the same time period.
「フレームブロック」という用語は、このドキュメントで使用されて、マルチチャネルVMR-WBセッションでの時間同期された音声フレームのセットを説明しています。特に、Nチャネルセッションでは、フレームブロックには各チャネルのn音声フレームが含まれ、すべてのn音声フレームはまったく同じ期間を表します。
VMR-WB is the wideband speech-coding standard developed by Third Generation Partnership Project 2 (3GPP2) for encoding/decoding wideband/narrowband speech content in multimedia services in 3G CDMA cellular systems [1]. VMR-WB is a source-controlled variable-rate multimode wideband speech codec. It has a number of operating modes, where each mode is a tradeoff between voice quality and average data rate. The operating mode in VMR-WB (as shown in Table 2) is chosen based on the traffic condition of the network and the desired quality of service. The desired average data rate (ADR) in each mode is obtained by encoding speech frames at permissible rates (as shown in Tables 1 and 3) compliant with CDMA2000 system, depending on the instantaneous characteristics of input speech and the maximum and minimum rate constraints imposed by the network operator.
VMR-WBは、3G CDMAセルラーシステムのマルチメディアサービスにおけるワイドバンド/狭帯域の音声コンテンツをエンコード/デコードするための第3世代パートナーシッププロジェクト2（3GPP2）によって開発されたワイドバンド音声コーディング標準です[1]。VMR-WBは、ソース制御された可変レートマルチモードワイドバンド音声コーデックです。各モードが音声品質と平均データレートのトレードオフである多くの動作モードがあります。VMR-WBの動作モード（表2を参照）は、ネットワークのトラフィック条件と目的のサービス品質に基づいて選択されます。各モードでの目的の平均データレート（ADR）は、入力音声の瞬時特性と課される最大および最小レートの制約に応じて、許容レート（表1および3に示すように）で音声フレームをエンコードすることによって取得されます（表1および3に示すように）CDMA2000システムに準拠していますネットワークオペレーターによって。
While VMR-WB is a native CDMA codec complying with all CDMA system requirements, it is further interoperable with AMR-WB [4,12] at 12.65, 8.85, and 6.60 kbps. This is due to the fact that VMR-WB and AMR-WB share the same core technology. This feature enables Transcoder-Free (TrFO) interconnections between VMR-WB and AMR-WB across different wireless/wireline systems (e.g., GSM/WCDMA and CDMA2000) without use of unnecessary complex media format conversion.
VMR-WBはすべてのCDMAシステム要件に準拠したネイティブCDMAコーデックですが、さらに12.65、8.85、および6.60 kbpsのAMR-WB [4,12]と相互運用可能です。これは、VMR-WBとAMR-WBが同じコアテクノロジーを共有しているという事実によるものです。この機能により、不必要な複雑なメディア形式変換を使用せずに、異なるワイヤレス/ワイヤーラインシステム（GSM/WCDMAやCDMA2000など）にわたって、VMR-WBとAMR-WB間のトランスコダーフリー（TRFO）の相互接続が可能になります。
Note that the concept of mode in VMR-WB is different from that of AMR-WB where each fixed-rate AMR-WB codec mode is adapted to prevailing channel conditions by a tradeoff between the total number of source-coding and channel-coding bits.
VMR-WBのモードの概念は、各固定レートAMR-WBコーデックモードがソースコーディングおよびチャネルコーディングビットの総数とのトレードオフにより、一般的なチャネル条件に適合しているAMR-WBの概念とは異なることに注意してください。。
VMR-WB is able to transition between various modes with no degradation in voice quality that is attributable to the mode switching itself. The operating mode of the VMR-WB encoder may be switched seamlessly without prior knowledge of the decoder. Any non-interoperable mode (i.e., VMR-WB modes 0, 1, or 2) can be chosen depending on the traffic conditions (e.g., network congestion) and the desired quality of service.
VMR-WBは、モードの切り替えに起因する音声品質の分解なしで、さまざまなモード間を移行できます。VMR-WBエンコーダーの動作モードは、デコーダーの事前知識なしにシームレスに切り替えることができます。交通条件（ネットワークの輻輳など）と望ましいサービス品質に応じて、挿入不可能なモード（つまり、VMR-WBモード0、1、または2）は選択できます。
While in the interoperable mode (i.e., VMR-WB mode 3), mode switching between VMR-WB modes is not allowed because there is only one AMR-WB interoperable mode in VMR-WB. Since the AMR-WB codec may request a mode change, depending on channel conditions, in-band data included in VMR-WB frame structure (see Section 8 of [1] for more details) is used during an interoperable interconnection to switch between VMR-WB frame types 0, 1, and 2 in VMR-WB mode 3 (corresponding to AMR-WB codec modes 0, 1, or 2).
相互運用可能なモード（つまり、VMR-WBモード3）では、VMR-WBにAMR-WB相互運用モードが1つしかないため、VMR-WBモード間のモードスイッチングは許可されません。AMR-WBコーデックはモードの変更を要求する可能性があるため、チャネル条件に応じて、VMR-WBフレーム構造に含まれるバンドデータ（詳細については[1]のセクション8を参照）は、相互運用可能な相互接続中に使用され、VMR間を切り替えます。-WBフレームタイプ0、1、および2 VMR-WBモード3（AMR-WBコーデックモード0、1、または2に対応）。
As mentioned earlier, VMR-WB is compliant with CDMA2000 system with the permissible encoding rates shown in Table 1.
前述のように、VMR-WBはCDMA2000システムに準拠しています。
+---------------------------+-----------------+---------------+
| Frame Type | Bits per Packet | Encoding Rate |
| | (Frame Size) | (kbps) |
+---------------------------+-----------------+---------------+
| Full-Rate | 266 | 13.3 |
| Half-Rate | 124 | 6.2 |
| Quarter-Rate | 54 | 2.7 |
| Eighth-Rate | 20 | 1.0 |
| Blank | 0 | 0 |
| Erasure | 0 | 0 |
+---------------------------+-----------------+---------------+
Table 1: CDMA2000 system permissible frame types and their associated encoding rates
表1：CDMA2000システム許容フレームタイプと関連するエンコード率
VMR-WB is robust to high percentage of frame loss and frames with corrupted rate information. The reception of an Erasure (SPEECH_LOST) frame type at decoder invokes the built-in frame error concealment mechanism. The built-in frame error concealment mechanism in VMR-WB conceals the effect of lost frames by exploiting in-band data and the information available in the previous frames.
VMR-WBは、破損したレート情報を備えたフレームの損失とフレームの割合が高いことから堅牢です。デコーダーでの消去（Speech_Lost）フレームタイプの受信は、組み込みのフレームエラー隠蔽メカニズムを呼び出します。VMR-WBの組み込みフレームエラー隠蔽メカニズムは、バンド内データと以前のフレームで利用可能な情報を活用することにより、失われたフレームの効果を隠します。
VMR-WB has the capability to operate with either 16000-Hz or 8000-Hz sampled input/output speech signals in all modes of operation [1]. The VMR-WB decoder does not require a priori knowledge about the sampling rate of the original media (i.e., speech/audio signals sampled at 8 or 16 kHz) at the input of the encoder. The VMR-WB decoder, by default, generates 16000-Hz wideband output regardless of the encoder input sampling frequency. Depending on the application, the decoder can be configured to generate 8000-Hz output, as well.
VMR-WBには、すべての動作モードで16000 Hzまたは8000 Hzのサンプリング/出力音声信号で動作する機能があります[1]。VMR-WBデコーダーは、エンコーダの入力で、元のメディアのサンプリングレート（つまり、8または16 kHzでサンプリングされた音声/オーディオ信号）に関する先験的な知識を必要としません。VMR-WBデコーダーは、デフォルトでは、エンコーダ入力サンプリング周波数に関係なく16000 Hzの広帯バンド出力を生成します。アプリケーションによっては、デコーダーを8000 Hzの出力を生成するように構成できます。
Therefore, while this specification defines a 16000-Hz RTP clock rate for VMR-WB codec, the injection and processing of 8000-Hz narrowband media during a session is also allowed; however, a 16000-Hz RTP clock rate MUST always be used.
したがって、この仕様はVMR-WBコーデックの16000 Hz RTPクロックレートを定義しますが、セッション中の8000 Hzの狭帯域媒体の注入と処理も許可されています。ただし、16000 HzのRTPクロックレートを常に使用する必要があります。
The choice of VMR-WB output sampling frequency depends on the implementation and the audio acoustic capabilities of the receiving side.
VMR-WB出力サンプリング周波数の選択は、受信側の実装とオーディオアコースティック機能に依存します。
The circuit-switched operation of VMR-WB within a CDMA network requires continuous transmission of the speech data during a conversation. The intrinsic source-controlled variable-rate feature of the CDMA speech codecs is required for optimal operation of the CDMA system and interference control. However, VMR-WB has the capability to operate in a discontinuous transmission mode for some packet-switched applications over IP networks (e.g., VoIP), where the number of transmitted bits and packets during silence period are reduced to a minimum. The VMR-WB DTX operation is similar to that of AMR-WB [4,12].
CDMAネットワーク内でのVMR-WBの回路縮小操作には、会話中に音声データを継続的に送信する必要があります。CDMAシステムと干渉制御の最適な動作には、CDMA音声コーデックの本質的なソース制御可変レート機能が必要です。ただし、VMR-WBには、IPネットワークを介した一部のパケットスイッチされたアプリケーション（VOIPなど）の不連続な送信モードで動作する機能があり、沈黙期間中に送信されたビットとパケットの数が最小限に抑えられます。VMR-WB DTX操作は、AMR-WB [4,12]の操作に似ています。
The octet-aligned RTP payload format defined in this document supports multi-channel audio content (e.g., a stereophonic speech session). Although VMR-WB codec itself does not support encoding of multi-channel audio content into a single bit stream, it can be used to encode and decode each of the individual channels separately.
このドキュメントで定義されているオクテットに配置されたRTPペイロード形式は、マルチチャネルオーディオコンテンツ（ステレオフォニック音声セッションなど）をサポートしています。VMR-WBコーデック自体は、マルチチャネルオーディオコンテンツのエンコードを単一のビットストリームにサポートしていませんが、個々のチャネルを個別にエンコードおよびデコードするために使用できます。
To transport the separately encoded multi-channel content, the speech frames for all channels that are framed and encoded for the same 20 ms periods are logically collected in a frame-block.
個別にエンコードされたマルチチャネルコンテンツを輸送するために、同じ20 ms期間にわたってフレーム化およびエンコードされたすべてのチャネルの音声フレームは、フレームブロックで論理的に収集されます。
At the session setup, out-of-band signaling must be used to indicate the number of channels in the session and the order of the speech frames from different channels in each frame-block. When using SDP for signaling (see Section 9.2 for more details), 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 [6].
セッションのセットアップでは、セッション内のチャネルの数と各フレームブロックの異なるチャネルからの音声フレームの順序を示すために、帯域外シグナリングを使用する必要があります。シグナリングにSDPを使用する場合（詳細についてはセクション9.2を参照）、チャネルの数はRTPMAP属性で指定され、各フレームブロックに掲載されるチャネルの順序は、[]のセクション4.1で指定されているチャネルの数で暗示されます。6]。
The octet-aligned payload format described in this document (see Section 6 for more details) supports several features, including forward error correction (FEC) and frame interleaving, in order to increase robustness against lost packets.
このドキュメントで説明されているオクテットに並べられたペイロード形式（詳細についてはセクション6を参照）は、失われたパケットに対する堅牢性を高めるために、フォワードエラー補正（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., RFC2733 [8], which generates extra packets containing repair data.
以前に送信されたデータの繰り返しの単純なスキームは、FECを達成する1つの方法です。より帯域幅効率的である別の可能なスキームは、ペイロード - 外部FECを使用することです。たとえば、RFC2733 [8]は、修理データを含む追加のパケットを生成します。
The repetition method 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 illustrates an example.
繰り返し方法には、以前に送信されたフレームブロックと現在のフレームブロックの単純な再送信が含まれます。これは、スライドウィンドウを使用して、各ペイロードを送信するために音声フレームブロックをグループ化することによって行われます。図1に例を示します。
In this example, each frame-block is retransmitted one time in the following RTP payload packet. Here, f(n-2)..f(n+4) denotes a sequence of speech frame-blocks, and p(n-1)..p(n+4) a sequence of payload packets.
この例では、各フレームブロックは、次のRTPペイロードパケットで1回再送信されます。ここで、F（n-2）.. f（n 4）は、一連の音声フレームブロックを示し、p（n-1）.. p（n 4）のペイロードパケットのシーケンスを示します。
--+--------+--------+--------+--------+--------+--------+--------+--
| 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：冗長伝送の例
The use of this approach does not require signaling at the session setup. 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 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 highest rate be used by the speech decoder.
このアプローチの使用では、セッションのセットアップでのシグナリングは必要ありません。言い換えれば、音声送信者は、受信機に相談せずにこのスキームを使用することを選択できます。これは、冗長なフレームを含むパケットが新しいフレームのみを備えたパケットと違いはないためです。受信者は、パケットが失われない場合、特定のタイムスタンプのフレームの複数のコピーまたはバージョンを受け取ることができます。同じ音声フレームの複数のバージョンが受信される場合、最高レートを音声デコーダーで使用することをお勧めします。
This redundancy scheme provides the same functionality as that described in RFC 2198, "RTP Payload for Redundant Audio Data" [10]. In most cases, the mechanism in this payload format is more efficient and simpler than requiring both endpoints to support RFC 2198. If the spread in time required between the primary and redundant encodings is larger than 5 frame times, the bandwidth overhead of RFC 2198 will be lower.
この冗長性スキームは、RFC 2198で説明されている「冗長なオーディオデータのRTPペイロード」[10]と同じ機能を提供します。ほとんどの場合、このペイロード形式のメカニズムは、RFC 2198をサポートするために両方のエンドポイントを要求するよりも効率的かつ単純です。プライマリと冗長エンコーディングの間に必要な時間のスプレッドが5フレームよりも大きい場合、RFC 2198の帯域幅のオーバーヘッドは低くなります。
The sender is responsible for selecting an appropriate amount of redundancy based on feedback about the channel (e.g., in RTCP receiver reports) or network traffic. A sender SHOULD NOT base selection of FEC on the CMR, as this parameter most probably was set based on non-IP information. The sender is also responsible for avoiding congestion, which may be aggravated by redundant transmission (see Section 7).
送信者は、チャネルに関するフィードバック（RTCP受信者レポートなど）またはネットワークトラフィックに基づいて、適切な量の冗長性を選択する責任があります。このパラメーターはおそらく非IP情報に基づいて設定されたため、送信者はCMRにFECのベース選択をしてはなりません。送信者は、冗長な伝送によって悪化する可能性のある輻輳を回避する責任もあります（セクション7を参照）。
To decrease protocol overhead, the octet-aligned payload format, described in Section 6, allows several speech frame-blocks to be encapsulated into a single RTP packet. One of the drawbacks of this approach is that in case of packet loss several consecutive speech frame-blocks are lost, which usually causes clearly audible distortion in the reconstructed speech.
プロトコルオーバーヘッドを減らすために、セクション6で説明されているオクテットに配置されたペイロード形式により、いくつかの音声フレームブロックを単一のRTPパケットにカプセル化できます。このアプローチの欠点の1つは、パケット損失の場合、いくつかの連続した音声フレームブロックが失われることです。これは通常、再構築された音声ではっきりと聞こえる歪みを引き起こします。
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.
フレームブロックのインターリーブは、連続した損失を一連の単一のフレームブロック損失に分配することにより、そのような場合の音声品質を改善することができます。ただし、ペイロードごとにいくつかのフレームブロックをインターリーブしてバンドルすると、エンドツーエンドの遅延が増加するため、あらゆるタイプのアプリケーションに適していません。ストリーミングアプリケーションは、ほとんどの場合、インターリーブを活用して、失われた伝送条件の音声品質を向上させることができます。
The octet-aligned payload format 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 9).
Octetに並べられたペイロード形式は、オプションとしてフレームインターリーブの使用をサポートしています。エンコーダ（スピーチ送信者）が特定のセッションのアウトバウンドRTPパケットでフレームインターリーブを使用するには、デコーダー（スピーチレシーバー）が帯域外の平均を介してサポートを示す必要があります（セクション9を参照）。
The primary scenario for this payload format is IP end-to-end between two terminals incorporating VMR-WB codec, as shown in Figure 2. Nevertheless, this scenario can be generalized to an interoperable interconnection between VMR-WB-enabled and AMR-WB-enabled IP terminals using the offer-answer model described in Section 9.3. This payload format is expected to be useful for both conversational and streaming services.
このペイロード形式の主要なシナリオは、図2に示すように、VMR-WBコーデックを組み込んだ2つの端子間のIPエンドツーエンドです。それでも、このシナリオは、VMR-WB対応とAMR-WBの間の相互運用可能な相互接続に一般化できます。 - セクション9.3で説明したオファーアンスワーモデルを使用した有効なIPターミナル。このペイロード形式は、会話サービスとストリーミングサービスの両方に役立つと予想されます。
+----------+ +----------+
| | | |
| TERMINAL |<----------------------->| TERMINAL |
| | VMR-WB/RTP/UDP/IP | |
+----------+ +----------+
(or AMR-WB/RTP/UDP/IP)
Figure 2: IP terminal to IP terminal
図2：IPターミナルからIP端末
A conversational service puts requirements on the payload format. Low delay is a very important factor, i.e., fewer speech frame-blocks per payload packet. Low overhead is also required when the payload format traverses across low bandwidth links, especially if the frequency of packets will be high.
会話サービスは、ペイロード形式に要件を置きます。低遅延は非常に重要な要素です。つまり、ペイロードパケットあたりの音声フレームブロックが少なくなります。特にパケットの頻度が高くなる場合、低帯域幅リンクを横切ってペイロード形式が通過する場合にも低いオーバーヘッドが必要です。
Streaming service has less strict real-time requirements and therefore can use a larger number of frame-blocks per packet than 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 of packet loss 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.
ストリーミングサービスには、リアルタイムの要件が厳しくないため、会話サービスよりもパケットごとに多くのフレームブロックを使用できます。これにより、IP、UDP、およびRTPヘッダーからオーバーヘッドが削減されます。ただし、パケットごとのいくつかのフレームブロックを含めると、送信がパケット損失に対してより脆弱になるため、インターリーブを使用して、音声品質に対するパケット損失の影響を減らすことができます。多数のクライアントを処理するストリーミングサーバーには、パケット化を行うときにできるだけ少ないリソースを必要とするペイロード形式も必要です。
For VMR-WB-enabled IP terminals at both ends, depending on the implementation, all modes of the VMR-WB codec can be used in this scenario. Also, both header-free and octet-aligned payload formats (see Section 6 for details) can be utilized. For the interoperable interconnection between VMR-WB and AMR-WB, only VMR-WB mode 3 is used, and all restrictions described in Section 9.3 apply.
実装に応じて、VMR-WB対応のIP端子の場合、VMR-WBコーデックのすべてのモードをこのシナリオで使用できます。また、ヘッダーフリーとオクテットに配置されたペイロード形式（詳細についてはセクション6を参照）の両方を利用できます。VMR-WBとAMR-WBの間の相互運用可能な相互接続の場合、VMR-WBモード3のみが使用され、セクション9.3で説明されているすべての制限が適用されます。
Another scenario occurs when VMR-WB-encoded speech will be transmitted from a non-IP system (e.g., 3GPP2/CDMA2000 network) to an IP terminal, and/or vice versa, as depicted in Figure 3.
図3に示すように、VMR-WBエンコードの音声が非IPシステム（3GPP2/CDMA2000ネットワークなど）、および/またはその逆に送信される場合、別のシナリオが発生します。
VMR-WB over
3GPP2/CDMA2000 network
+------+ +----------+
| | | |
<-------------->| GW |<---------------------->| TERMINAL |
| | VMR-WB/RTP/UDP/IP | |
+------+ +----------+
|
| IP network
|
Figure 3: GW to VoIP terminal scenario
図3：GWからVoIP端末シナリオ
VMR-WB's capability to switch seamlessly between operational modes is exploited in CDMA (non-IP) networks to optimize speech quality for a given traffic condition. To preserve this functionality in scenarios including a gateway to an IP network using the octet-aligned payload format, a codec mode request (CMR) field is considered. 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 SHOULD accommodate the delay imposed by the IP network on the response to CMR by the IP terminal.
VMR-WBの運用モード間でシームレスに切り替える機能は、特定のトラフィック条件の音声品質を最適化するために、CDMA（非IP）ネットワークで活用されています。この機能を、オクテットに配置されたペイロード形式を使用してIPネットワークへのゲートウェイを含むシナリオで保存するために、コーデックモード要求（CMR）フィールドが考慮されます。ゲートウェイは、非IP部品とIP部品の間にCMRを両方向に転送する責任があります。IP端末は、ゲートウェイによって転送されたCMRに従って、非IPデコーダーに向かう音質の品質を最適化する必要があります。ゲートウェイのモード制御アルゴリズムは、IP端末によるCMRへの応答に関してIPネットワークによって課される遅延に対応する必要があります。
The IP terminal SHOULD NOT set the CMR (see Section 6.3.2), 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 and to perform congestion control on the IP network.
IP端末はCMRを設定してはなりません（セクション6.3.2を参照）が、ゲートウェイは、そのエンコーダーからゲートウェイへの音声品質を最適化し、渋滞を実行するために、非IPパーツのエンコーダーに向かってフレームにCMR値を設定できますIPネットワークの制御。
A third likely scenario is that RTP/UDP/IP 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. This is the most likely scenario for an interoperable interconnection between 3GPP/(GSM-WCDMA)/AMR-WB and 3GPP2/CDMA2000/VMR-WB-enabled mobile stations. In this scenario, the VMR-WB-enabled terminal also declares itself capable of AMR-WB with restricted mode set as described in Section 9.3. 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: (1) the CMR value it receives on the IP side; (2) a CMR value it may choose for congestion control of transmission on the IP side; and (3) the CMR value based on its estimate of reception quality on the non-IP side. The details of the traffic control algorithm are left to the implementation.
3番目のシナリオは、RTP/UDP/IPが2つの非IPシステム間のトランスポートとして使用されることです。つまり、図4に示すように、IPはIPトランスポンドの両側のゲートウェイで発信され、終了します。3GPP/（GSM-WCDMA）/AMR-WBと3GPP2/CDMA2000/VMR-WB対応モバイルステーション間の相互運用可能な相互接続のシナリオ。このシナリオでは、VMR-WB対応端子は、セクション9.3で説明されているように、制限されたモードが設定されたAMR-WBができると宣言しています。CMR値は、IPネットワーク側のゲートウェイで受信したパケットで設定できます。ゲートウェイは、最小3つの値であるCMR値を非IP側に転送する必要があります。（1）IP側で受信するCMR値。（2）IP側での伝送の混雑制御に選択できるCMR値。（3）非IP側の受信品質の推定に基づくCMR値。トラフィックコントロールアルゴリズムの詳細は、実装に残されています。
VMR-WB over AMR-WB over
3GPP2/CDMA2000 network 3GPP/(GSM-WCDMA) network
+------+ +------+
(AMR-WB Payload) | | AMR-WB/RTP/UDP/IP| |(AMR-WB Payload)
<---------------->| GW |<---------------->| GW |<--------------->
| | | |
+------+ +------+
| IP network |
| |
Figure 4: GW to GW scenario (AMR-WB <-> VMR-WB interoperable interconnection)
図4：GWからGWへのシナリオ（AMR-WB <-> VMR-WB相互運用可能な相互接続）
During and upon initiation of an interoperable interconnection between VMR-WB and AMR-WB, only VMR-WB mode 3 can be used. There are three Frame Types (i.e., FT=0, 1, or 2; see Table 3) within this mode that are compatible with AMR-WB codec modes 0, 1, and 2, respectively. If the AMR-WB codec is engaged in an interoperable interconnection with VMR-WB, the active AMR-WB codec mode set needs to be limited to 0, 1, and 2.
VMR-WBとAMR-WBの間の相互運用可能な相互接続の開始中および開始時に、VMR-WBモード3のみを使用できます。AMR-WBコーデックモード0、1、および2と互換性のあるこのモード内には、3つのフレームタイプ（つまり、ft = 0、1、または2;表3を参照）があります。AMR-WBコーデックがVMR-WBとの相互運用可能な相互接続に従事している場合、アクティブなAMR-WBコーデックモードセットは0、1、および2に制限する必要があります。
The fourth example VoIP scenario is composed of a RTP/UDP/IP 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 5. This is the most likely scenario for Mobile-Station-to-Mobile-Station (MS-to-MS) Transcoder-Free (TrFO) interconnection between two 3GPP2/CDMA2000 terminals that both use VMR-WB codec.
4番目の例VOIPシナリオは、2つの非IPシステム間のRTP/UDP/IPトランスポートで構成されています。つまり、図5に示すように、IPはIPトランスポートの両側のゲートウェイで発信され、終了します。これは、モバイルステーションからモバイルステーション（MS-MS）トランスコーダーフリーの最も可能性の高いシナリオです（TRFO）VMR-WBコーデックを使用する2つの3GPP2/CDMA2000端子間の相互接続。
VMR-WB over VMR-WB over
3GPP2/CDMA2000 network 3GPP2/CDMA2000 network
+------+ +------+
| | | |
<------------>| GW |<----------------->| GW |<------------>
| | VMR-WB/RTP/UDP/IP | |
+------+ +------+
| IP network |
| |
Figure 5: GW to GW scenario (a CDMA2000 MS-to-MS VoIP scenario)
図5：GWからGWへのシナリオ（CDMA2000 MS-To-MS VoIPシナリオ）
For a given session, the payload format can be either header free or octet aligned, depending on the mode of operation that is established for the session via out-of-band means and the application.
特定のセッションでは、ペイロード形式は、帯域外の手段とアプリケーションを介してセッション用に確立される操作モードに応じて、ヘッダーフリーまたはオクテットアラインドされています。
The header-free payload format is designed for maximum bandwidth efficiency, simplicity, and low latency. Only one codec data frame can be sent in each header-free payload format packet. None of the payload header fields or table of contents (ToC) entries is present (the same consideration is also made in [11]).
ヘッダーフリーのペイロード形式は、帯域幅の効率、シンプルさ、低遅延のために設計されています。各ヘッダーフリーのペイロード形式パケットで1つのコーデックデータフレームのみを送信できます。ペイロードヘッダーフィールドまたは目次（TOC）エントリは存在しません（[11]でも同じ考慮事項があります）。
In the octet-aligned payload 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.
Octetに並べられたペイロード形式では、ペイロードヘッダー、目次エントリ、およびスピーチフレーム自体を含むペイロード内のすべてのフィールドが、実装を効率的にするために個別に揃っています。
Note that 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 payload formats, only the octet-aligned format has the capability to use the interleaving to make the speech transport robust to packet loss.
2つのペイロード形式の間では、Octetに配置された形式のみが、インターリーブを使用して、スピーチトランスポートをパケット損失に堅牢にする機能を備えています。
The VMR-WB octet-aligned payload format in the interoperable mode is identical to that of AMR-WB (i.e., RFC 3267).
相互運用可能なモードでのVMR-WBオクテットアリードペイロード形式は、AMR-WB（つまり、RFC 3267）と同じです。
The format of the RTP header is specified in [3]. This payload format uses the fields of the header in a manner consistent with that specification.
RTPヘッダーの形式は[3]で指定されています。このペイロード形式は、その仕様と一致する方法でヘッダーのフィールドを使用します。
The RTP timestamp corresponds to the sampling instant of the first sample encoded for the first frame-block in the packet. The timestamp clock frequency is the same as the default sampling frequency (i.e., 16 kHz), so the timestamp unit is in samples.
RTPタイムスタンプは、パケット内の最初のフレームブロックにエンコードされた最初のサンプルのサンプリングインスタントに対応します。タイムスタンプクロック周波数は、デフォルトのサンプリング周波数（つまり、16 kHz）と同じであるため、タイムスタンプユニットはサンプルです。
The duration of one speech frame-block is 20 ms for VMR-WB. For normal wideband operation of VMR-WB, the input/output media sampling frequency is 16 kHz, corresponding to 320 samples per frame from each channel. Thus, the timestamp is increased by 320 for VMR-WB for each consecutive frame-block.
1つの音声フレームブロックの期間は、VMR-WBの20ミリ秒です。VMR-WBの通常の広帯域動作の場合、入力/出力メディアサンプリング周波数は16 kHzで、各チャネルのフレームごとに320サンプルに対応しています。したがって、タイムスタンプは、連続したフレームブロックごとにVMR-WBで320増加します。
The VMR-WB codec is capable of processing speech/audio signals sampled at 8 kHz. By default, the VMR-WB decoder output sampling frequency is 16 kHz. Depending on the application, the decoder can be configured to generate 8-kHz output sampling frequency, as well. Since the VMR-WB RTP payload formats for the 8- and 16-kHz sampled media are identical and the VMR-WB decoder does not need a priori knowledge about the encoder input sampling frequency, a fixed RTP clock rate of 16000 Hz is defined for VMR-WB codec. This would allow injection or processing of 8-kHz sampled speech/audio media without having to change the RTP clock rate during a session. Note that the timestamp is incremented by 320 per frame-block for 8-kHz sampled media, as well.
VMR-WBコーデックは、8 kHzでサンプリングされた音声/オーディオ信号を処理できます。デフォルトでは、VMR-WBデコーダー出力サンプリング周波数は16 kHzです。アプリケーションに応じて、デコーダーを8 kHz出力サンプリング周波数を生成するように構成できます。8および16 kHzサンプルメディアのVMR-WB RTPペイロードフォーマットは同一であり、VMR-WBデコーダーはエンコーダ入力サンプリング周波数に関する先験的な知識を必要としないため、16000 Hzの固定RTPクロックレートが定義されています。VMR-WBコーデック。これにより、セッション中にRTPクロックレートを変更することなく、8 kHzサンプリングされた音声/オーディオメディアの注入または処理が可能になります。タイムスタンプは、8 kHzサンプリングされたメディアでもフレームブロックごとに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 defined in Section 6.3.2. 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 instead of breaking a multi-frame-block packet into two, as explained in Section 6.3.2.
パケットには、エンコードされた音声またはコンフォートノイズパラメーターの複数のフレームブロックが含まれる場合があります。インターリーブを使用すると、ペイロードにカプセル化されたフレームブロックは、セクション6.3.2で定義されているインターリーブルールに従って選択されます。それ以外の場合、各パケットは、1つ以上の隣接する20 msのフレームブロック間隔の期間をカバーします。期間中の特定のフレームブロックのすべてのチャネルからのデータが欠落している場合（たとえば、他の輸送形式からのゲートウェイで）、そのフレームブロックのデータが存在しないことを示すことができます。セクション6.3.2で説明されているように、マルチフレームブロックパケットを2つに分割します。
No matter which payload format is used, the RTP payload is always made an integral number of octets long 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 header MAY be set, and padding appended, as specified in [3].
どのペイロード形式が使用されていても、RTPペイロードは、必要に応じてゼロビットのパディングにより、常に積分数のオクテット数になります。ペイロード長をオクテットのより大きな倍数または他の目的のために持ち込むために追加のパディングが必要な場合、[3]で指定されているように、RTPヘッダーのPビットが設定され、パディングが追加されます。
The RTP header marker bit (M) SHALL be always set to 0 if the VMR-WB codec operates in continuous transmission. When operating in discontinuous transmission (DTX), the RTP header marker bit 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).
VMR-WBコーデックが連続伝送で動作する場合、RTPヘッダーマーカービット（M）は常に0に設定されます。不連続伝送（DTX）で操作する場合、RTPヘッダーマーカービットは、パケットに掲載された最初のフレームブロックにスピーチフレームが含まれている場合、1に設定されます。他のすべてのパケットについては、マーカービットをゼロ（m = 0）に設定する必要があります。
The assignment of an RTP payload type for this payload 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 (see Section 9).
このペイロード形式のRTPペイロードタイプの割り当ては、このドキュメントの範囲外であり、ここでは指定されません。このペイロード形式が使用されているRTPプロファイルは、このエンコードにペイロードタイプを割り当てるか、ペイロードタイプを動的にバインドすることを指定することが期待されます（セクション9を参照）。
The header-free payload format is designed for maximum bandwidth efficiency, simplicity, and minimum delay. Only one speech data frame presents in each header-free payload format packet. None of the payload header fields or ToC entries is present. The encoding rate for the speech frame can be determined from the length of the speech data frame, since there is only one speech data frame in each header-free payload format.
ヘッダーフリーのペイロード形式は、帯域幅の効率、シンプルさ、最小遅延のために設計されています。各ヘッダーフリーのペイロード形式パケットに提示されるスピーチデータフレームは1つだけです。ペイロードヘッダーフィールドまたはTOCエントリはいずれも存在しません。音声フレームのエンコーディングレートは、各ヘッダーフリーのペイロード形式に1つの音声データフレームしかないため、音声データフレームの長さから決定できます。
The use of the RTP header fields for header-free payload format is the same as the corresponding one for the octet-aligned payload format. The detailed bit mapping of speech data packets permissible for this payload format is described in Section 8 of [1]. Since the header-free payload format is not compatible with AMR-WB RTP payload, only non-interoperable modes of VMR-WB SHALL be used with this payload format. That is, FT=0, 1, 2, and 9 SHALL NOT be used with header-free payload format.
ヘッダーフリーのペイロード形式にRTPヘッダーフィールドを使用することは、Octetに配置されたペイロード形式に対応するものと同じです。このペイロード形式に許容される音声データパケットの詳細なビットマッピングは、[1]のセクション8で説明されています。ヘッダーフリーのペイロード形式はAMR-WB RTPペイロードと互換性がないため、このペイロード形式では、VMR-WBの非挿入性モードのみを使用するものとします。つまり、ft = 0、1、2、および9は、ヘッダーフリーのペイロード形式では使用してはなりません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header [3] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ ONLY one speech data frame +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the mode of operation, using this payload format, is decided by the transmitting (encoder) site. The default mode of operation for VMR-WB encoder is mode 0 [1]. The mode change request MAY also be sent through non-RTP means, which is out of the scope of this specification.
このペイロード形式を使用した動作モードは、送信（エンコーダー）サイトによって決定されることに注意してください。VMR-WBエンコーダーの操作のデフォルトモードはモード0 [1]です。モード変更要求は、この仕様の範囲外である非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 ...
+----------------+-------------------+----------------
In octet-aligned payload format, the payload header consists of a 4-bit CMR, 4 reserved bits, and, optionally, an 8-bit interleaving header, as shown below.
Octetに合わせたペイロード形式では、ペイロードヘッダーは、4ビットCMR、4つの予約ビット、およびオプションで、以下に示すように8ビットインターリーブヘッダーで構成されています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+- - - - - - - -
| CMR |R|R|R|R| ILL | ILP |
+-+-+-+-+-+-+-+-+- - - - - - - -
CMR (4 bits): This indicates a codec mode request sent to the speech encoder at the site of the receiver of this payload. CMR value 15 indicates that no mode request is present, and other unused values are reserved for future use.
CMR（4ビット）：これは、このペイロードの受信機のサイトでスピーチエンコーダーに送信されたコーデックモード要求を示します。CMR値15は、モード要求が存在しないことを示し、その他の未使用の値は将来の使用のために予約されています。
The value of the CMR field is set according to the following table:
CMRフィールドの値は、次の表に従って設定されています。
+-------+----------------------------------------------------------+
| CMR | VMR-WB Operating Modes |
+-------+----------------------------------------------------------+
| 0 | VMR-WB mode 3 (AMR-WB interoperable mode at 6.60 kbps) |
| 1 | VMR-WB mode 3 (AMR-WB interoperable mode at 8.85 kbps) |
| 2 | VMR-WB mode 3 (AMR-WB interoperable mode at 12.65 kbps) |
| 3 | VMR-WB mode 2 |
| 4 | VMR-WB mode 1 |
| 5 | VMR-WB mode 0 |
| 6 | VMR-WB mode 2 with maximum half-rate encoding |
| 7-14 | (reserved) |
| 15 | No Preference (no mode request is present) |
+-------+----------------------------------------------------------+
Table 2: List of valid CMR values and their associated VMR-WB operating modes
表2：有効なCMR値とそれに関連するVMR-WB操作モードのリスト
R: This is a reserved bit that MUST be set to zero. The receiver MUST ignore all R bits.
R：これは予約されたビットで、ゼロに設定する必要があります。受信機はすべてのRビットを無視する必要があります。
ILL (4 bits, unsigned integer): This is an OPTIONAL field that is present only if interleaving is signaled 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 signaled. ILP MUST take a value between 0 and ILL, inclusive, indicating the interleaving index for frame-blocks in this payload in the interleave group. If the value of ILP is found greater than ILL, the payload SHOULD be discarded.
ILP（4ビット、署名されていない整数）：これは、インターリーブがシグナルがある場合にのみ存在するオプションのフィールドです。ILPは、包括的0からILLの間の値を取得する必要があり、インターリーブグループのこのペイロードのフレームブロックのインターリーブインデックスを示しています。ILPの値が病気よりも大きい場合は、ペイロードを破棄する必要があります。
ILL and ILP fields MUST be present in each packet in a session if interleaving is signaled for the session.
セッションにインターリーブが通知されている場合、セッションの各パケットにILLおよびILPフィールドが存在する必要があります。
The mode request received in the CMR field is valid until the next CMR is received, i.e., until a newly received CMR value overrides the previous one. 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が受信されるまで、つまり新しく受信されたCMR値が前のものをオーバーライドするまで有効です。したがって、端末が同じモードxでフレームを継続的に受信したい場合、すべてのアウトバウンドペイロードに対してCMR = xを設定する必要があり、端末が受信するモードを好まない場合、CMR = 15を設定する必要があります。すべてのアウトバウンドペイロード。
If a payload is received with a CMR value that is not valid, the CMR MUST be ignored by the receiver.
有効なCMR値でペイロードを受信した場合、CMRは受信機によって無視する必要があります。
In a multi-channel session, CMR SHOULD be interpreted by the receiver of the payload as the desired encoding mode for all the channels in the session, if the network allows.
マルチチャネルセッションでは、ネットワークが許可する場合、セッション内のすべてのチャネルの目的のエンコードモードとして、ペイロードの受信者によってCMRを解釈する必要があります。
There are two factors that affect the VMR-WB mode selection: (i) the performance of any CDMA link connected via a gateway (e.g., in a GW to IP terminal scenario), and (ii) the congestion state of an IP network. The CDMA link performance is signaled via the CMR field, which is not used by IP-only end-points. The IP network state is monitored using, for example, RTCP. A sender needs to select the operating mode to satisfy both these constraints (see Section 7).
VMR-WBモードの選択に影響を与える2つの要因があります。（i）ゲートウェイ（例：GWからIP端末シナリオ）を介して接続されたCDMAリンクのパフォーマンスと（ii）IPネットワークの輻輳状態。CDMAリンクのパフォーマンスは、IPのみのエンドポイントでは使用されていないCMRフィールドを介して通知されます。IPネットワーク状態は、たとえばRTCPを使用して監視されます。送信者は、これらの両方の制約を満たすために動作モードを選択する必要があります（セクション7を参照）。
The encoder SHOULD follow a received mode request, but MAY change to a different mode if the network necessitates it, 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 mode requests when sending speech to a multicast session but MAY use RTCP feedback information as a hint that a mode change is needed.
CMRフィールドは、マルチキャストグループに送信されたパケットに対して15に設定する必要があります。スピーチ送信者のエンコーダーは、スピーチをマルチキャストセッションに送信するときにモード要求を無視する必要がありますが、モードの変更が必要であるというヒントとしてRTCPフィードバック情報を使用する場合があります。
If interleaving option is utilized, interleaving MUST be performed on a frame-block basis, as opposed to a frame basis, in a multi-channel session.
インターリーブオプションが使用されている場合、マルチチャネルセッションで、フレームベースとは対照的に、フレームブロックベースでインターリーブを実行する必要があります。
The following example illustrates the arrangement of speech frame-blocks in an interleave group during an interleave session. Here we assume ILL=L for the interleave group that starts at speech frame-block n. We also assume that the first payload packet of the interleave 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 interleave group): ILL=L, ILP=0,
ペイロードs（このインターリーブグループの最初のパケット）：ill = l、ilp = 0、
Carry frame-blocks: n, n+(L+1), n+2*(L+1),..., n+(N-1)*(L+1)
Payload s+1 (the second packet of this interleave group):
ILL=L, ILP=1,
Carry frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1),..., n+1+
(N-1)*(L+1)
...
...
Payload s+L (the last packet of this interleave group):
ILL=L, ILP=L,
Carry frame-blocks: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+
(N-1)*(L+1)
The next interleave group will start at frame-block 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 interleave group. In other words, all payloads in an interleave group MUST have the same ILL and MUST contain the same number of speech frame-blocks.
次のインターリーブグループは、フレームブロックn n*（l 1）で開始されます。パケットあたりのフレームブロックの数（n）が少なくとも2でない限り、インターリーブ効果はありません。さらに、ペイロードあたりのフレームブロックの数（n）とILLの値をインターリーブグループ内で変更してはなりません。言い換えれば、インターリーブグループ内のすべてのペイロードは同じ病気で、同じ数の音声フレームブロックを含める必要があります。
The sender of the payload MUST only apply interleaving if the receiver has signaled its use through out-of-band means. Since interleaving will increase buffering requirements at the receiver, the receiver uses MIME parameter "interleaving=I" to set the maximum number of frame-blocks allowed in an interleaving group to I.
ペイロードの送信者は、受信機が帯域外の手段を通じて使用を合図した場合にのみインターリーブを適用する必要があります。インターリーブが受信機でバッファリング要件を増加させるため、受信機はMIMEパラメーター「インターリーブ= 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 interleave group is less than or equal to I, i.e., N*(L+1)<=I.
インターリーブを実行する場合、送信者は、ペイロードあたりの適切な数のフレームブロック（n）を使用する必要があります。そのため、結果のサイズはインターリーブグループのサイズがi、つまりn*（l 1）<= i以下になります。。
The following example shows the ToC of three consecutive packets, each carrying 3 frame-blocks, in an interleaved two-channel session.
次の例は、3つの連続したパケットのTOCを示しています。各パケットは、インターリーブ2チャンネルセッションで3つのフレームブロックを運んでいます。
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 makes the interleave group 9 frame-blocks large.
ここでは、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:
病気= 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
The table of contents (ToC) in octet-aligned payload format consists of a list of ToC entries where each entry corresponds to a speech frame carried in the payload, i.e., when interleaving is used, the frame-blocks in the ToC will almost never be placed consecutive in time. Instead, the presence and order of the frame-blocks in a packet will follow the pattern described in 6.3.2.
Octetに並べられたペイロード形式の目次（TOC）は、各エントリがペイロードで運ばれる音声フレームに対応するTOCエントリのリストで構成されています。連続して時間内に配置されます。代わりに、パケット内のフレームブロックの存在と順序は、6.3.2に記載されているパターンに従います。
+---------------------+
| list of ToC entries |
+---------------------+
A ToC entry for the octet-aligned payload format is as follows:
Octetに並べられたペイロード形式のTOCエントリは次のとおりです。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |Q|P|P|
+-+-+-+-+-+-+-+-+
The table of contents (ToC) consists of a list of ToC entries, each representing a speech frame.
目次（TOC）は、それぞれが音声フレームを表すTOCエントリのリストで構成されています。
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 whose value is chosen according to Table 3.
FT（4ビット）：表3に従って値が選択されているフレームタイプインデックス。
During the interoperable mode, FT=14 (SPEECH_LOST) and FT=15 (NO_DATA) are used to indicate frames that are either lost or not being transmitted in this payload, respectively. FT=14 or 15 MAY be used in the non-interoperable modes to indicate frame erasure or blank frame, respectively (see Section 2.1 of [1]).
相互運用可能なモードでは、ft = 14（speech_lost）およびft = 15（no_data）を使用して、このペイロードでそれぞれ紛失または送信されていないフレームを示します。FT = 14または15は、それぞれフレームの消去または空白フレームを示すために、非挿入性モードで使用できます（[1]のセクション2.1を参照）。
If a payload with an invalid FT value is received, the payload MUST be discarded. Note that for ToC entries with FT=14 or 15, there will be no corresponding speech frame in the payload.
無効なFT値を持つペイロードが受信された場合、ペイロードを破棄する必要があります。FT = 14または15のTOCエントリの場合、ペイロードに対応する音声フレームはないことに注意してください。
Depending on the application and the mode of operation of VMR-WB, any combination of the permissible frame types (FT) shown in Table 3 MAY be used.
VMR-WBのアプリケーションと動作モードに応じて、表3に示す許容フレームタイプ（FT）の任意の組み合わせを使用できます。
Q (1 bit): Frame quality indicator. If set to 0, indicates that the corresponding frame is corrupted. During the interoperable mode, the receiver side (with AMR-WB codec) should set the RX_TYPE to either SPEECH_BAD or SID_BAD depending on the frame type (FT), if Q=0. The VMR-WB encoder always sets Q bit to 1. The VMR-WB decoder may ignore the Q bit.
Q（1ビット）：フレーム品質インジケーター。0に設定すると、対応するフレームが破損していることを示します。相互運用可能なモード中、レシーバー側（AMR-WBコーデック）は、Q = 0の場合、フレームタイプ（ft）に応じてrx_typeをspeech_badまたはsid_badに設定する必要があります。VMR-WBエンコーダーは常にQビットを1に設定します。VMR-WBデコーダーはQビットを無視する場合があります。
P bits: Padding bits MUST be set to zero and MUST be ignored by a receiver.
Pビット：パディングビットはゼロに設定する必要があり、受信機は無視する必要があります。
+----+--------------------------------------------+-----------------+
| FT | Encoding Rate |Frame Size (Bits)|
+----+--------------------------------------------+-----------------+
| 0 | Interoperable Full-Rate (AMR-WB 6.60 kbps) | 132 |
| 1 | Interoperable Full-Rate (AMR-WB 8.85 kbps) | 177 |
| 2 | Interoperable Full-Rate (AMR-WB 12.65 kbps)| 253 |
| 3 | Full-Rate 13.3 kbps | 266 |
| 4 | Half-Rate 6.2 kbps | 124 |
| 5 | Quarter-Rate 2.7 kbps | 54 |
| 6 | Eighth-Rate 1.0 kbps | 20 |
| 7 | (reserved) | - |
| 8 | (reserved) | - |
| 9 | CNG (AMR-WB SID) | 40 |
| 10 | (reserved) | - |
| 11 | (reserved) | - |
| 12 | (reserved) | - |
| 13 | (reserved) | - |
| 14 | Erasure (AMR-WB SPEECH_LOST) | 0 |
| 15 | Blank (AMR-WB NO_DATA) | 0 |
+----+--------------------------------------------+-----------------+
Table 3: VMR-WB payload frame types for real-time transport
表3：リアルタイムトランスポート用のVMR-WBペイロードフレームタイプ
For multi-channel sessions, the ToC entries of all frames from a frame-block are placed in the ToC in consecutive order. 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.
マルチチャネルセッションの場合、フレームブロックからのすべてのフレームのTOCエントリが連続してTOCに配置されます。したがって、パケットにnチャネルとk音声フレームブロックを使用すると、TOCにはn*kエントリが必要であり、最初のnエントリは最初のフレームブロックからで、2番目のnエントリは2番目のフレームからです。 - ブロックなど。
Speech data of a payload contains one or more speech frames as described in the ToC of the payload.
ペイロードの音声データには、ペイロードのTOCに記載されている1つ以上の音声フレームが含まれています。
Each speech frame represents 20 ms of speech encoded in one of the available encoding rates depending on the operation mode. The length of the speech frame is defined by the frame type in the FT field, with the following considerations:
各音声フレームは、操作モードに応じて利用可能なエンコードレートの1つでエンコードされた20ミリ秒の音声を表します。音声フレームの長さは、FTフィールドのフレームタイプによって定義され、次の考慮事項があります。
- The last octet of each speech frame MUST be padded with zeroes at the end if not all bits in the octet are used. In other words, each speech frame MUST be octet-aligned.
- 各音声フレームの最後のオクテットは、オクテットのすべてのビットが使用されていない場合、最後にゼロでパディングする必要があります。言い換えれば、各音声フレームはオクテットに整列する必要があります。
- When multiple speech frames are present in the speech data, the speech frames MUST be arranged one whole frame after another.
- スピーチデータに複数の音声フレームが存在する場合、音声フレームは次々とフレーム全体を配置する必要があります。
The order and numbering notation of the speech data bits are as specified in the VMR-WB standard specification [1].
音声データビットの順序と番号付け表記は、VMR-WB標準仕様[1]で指定されているとおりです。
The payload begins with the payload header of one octet, or two if frame interleaving is selected. The payload header is followed by the table of contents consisting of a list of one-octet ToC entries.
ペイロードは、フレームインターリーブが選択されている場合、1オクテットのペイロードヘッダー、または2つの場合から始まります。ペイロードヘッダーの後に、1オクテットのTOCエントリのリストで構成される目次が続きます。
The speech data follows the table of contents. For the purpose of packetization, all 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.
音声データは、目次に従います。パケット化の目的のために、音声フレームを含むすべてのオクテットは、ユニットとしてペイロードに追加されます。スピーチフレームは、対応するTOCエントリがTOCリストに配置されているのと同じ順序で梱包されています。ただし、特定のフレームにFT = 14または15のTOCエントリがある場合、そのフレームにはデータオクテットが存在しないことを除きます。。
The following diagram shows an octet-aligned payload format from a single channel session that carries two VMR-WB Full-Rate frames (FT=3). In the payload, a codec mode request is sent (e.g., CMR=4), requesting that the encoder at the receiver's side use VMR-WB mode 1. No interleaving is used. Note that in the example below the last octet in both speech frames is padded with zeros to make them octet aligned.
次の図は、2つのVMR-WBフルレートフレーム（FT = 3）を搭載した単一のチャネルセッションからのオクテットに配置されたペイロード形式を示しています。ペイロードでは、コーデックモード要求が送信され（例：CMR = 4）、レシーバーの側でエンコーダーがVMR-WBモード1を使用するように要求します。インターリーブは使用されません。両方の音声フレームの最後のオクテットの下の例では、ゼロがゼロをパッドに入れて、それらをオクテットに合わせることに注意してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CMR=4 |R|R|R|R|1|FT#1=3 |Q|P|P|0|FT#2=3 |Q|P|P| f1(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f1(8..15) | f1(16..23) | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| r |P|P|P|P|P|P| f2(0..7) | f2(8..15) | f2(16..23) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | l |P|P|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r= f1(264,265)
l= f2(264,265)
An application implementing this payload format MUST understand all the payload parameters. Any mapping of the parameters to a signaling protocol MUST support all parameters. Therefore, an implementation of this payload format in an application using SDP is required to understand all the payload parameters in their SDP-mapped form. This requirement ensures that an implementation always can decide whether it is capable of communicating.
このペイロード形式を実装するアプリケーションは、すべてのペイロードパラメーターを理解する必要があります。シグナリングプロトコルへのパラメーターのマッピングは、すべてのパラメーターをサポートする必要があります。したがって、SDPマップフォームのすべてのペイロードパラメーターを理解するには、SDPを使用したアプリケーションでのこのペイロード形式の実装が必要です。この要件により、実装が常に通信できるかどうかを常に決定できるようになります。
To enable efficient interoperable interconnection with AMR-WB and to ensure that a VMR-WB terminal appropriately declares itself as a AMR-WB-capable terminal (see Section 9.3), it is also RECOMMENDED that a VMR-WB RTP payload implementation understand relevant AMR-WB signaling.
AMR-WBとの効率的な相互運用可能な相互接続を有効にし、VMR-WB端子がAMR-WB対応端末として適切に宣言することを確認するために（セクション9.3を参照）、VMR-WB RTP RTPペイロード実装は関連するAMRを理解することをお勧めします-WBシグナル伝達。
To further ensure interoperability between various implementations of VMR-WB, implementations SHALL support both header-free and octet-aligned payload formats. Support of interleaving is optional.
VMR-WBのさまざまな実装間の相互運用性をさらに確保するために、実装はヘッダーフリーとオクテットに整列したペイロード形式の両方をサポートするものとします。インターリーブのサポートはオプションです。
When processing a received payload packet, if the receiver finds that the calculated payload length, based on the information of the session and the values found in the payload header fields, does not match the size of the received packet, the receiver SHOULD discard the packet to avoid potential degradation of speech quality and to invoke the VMR-WB built-in frame error concealment mechanism. Therefore, invalid packets SHALL be treated as lost packets.
受信したペイロードパケットを処理するとき、受信者がセッションの情報とペイロードヘッダーフィールドにある値に基づいて計算されたペイロード長が受信パケットのサイズと一致しないことを発見した場合、受信者はパケットを破棄する必要があります音声品質の潜在的な分解を回避し、VMR-WBビルトインフレームエラー隠蔽メカニズムを呼び出すため。したがって、無効なパケットは紛失したパケットとして扱われます。
Late packets (i.e., the unavailability of a packet when it is needed for decoding at the receiver) should be treated as lost packets. Furthermore, if the late packet is part of an interleave group, depending upon the availability of the other packets in that interleave group, decoding must be resumed from the next available frame (sequential order). In other words, the unavailability of a packet in an interleave group at a certain time should not invalidate the other packets within that interleave group that may arrive later.
遅いパケット（つまり、レシーバーでのデコードに必要な場合のパケットの利用不能）は、紛失したパケットとして扱う必要があります。さらに、後期パケットがインターリーブグループの一部である場合、そのインターリーブグループ内の他のパケットの可用性に応じて、デコードを次の利用可能なフレーム（順次順序）から再開する必要があります。言い換えれば、特定の時間にインターリーブグループ内のパケットが利用できない場合は、後で到着する可能性のあるインターリーブグループ内の他のパケットを無効にしてはなりません。
The general congestion control considerations for transporting RTP data apply to VMR-WB speech over RTP as well. However, the multimode capability of VMR-WB speech codec may provide an advantage over other payload formats for controlling congestion since the bandwidth demand can be adjusted by selecting a different operating mode.
RTPデータを輸送するための一般的な混雑制御の考慮事項は、RTPよりもVMR-WBスピーチにも適用されます。ただし、VMR-WBスピーチコーデックのマルチモード機能は、帯域幅の需要を別の動作モードを選択することで調整できるため、混雑を制御するための他のペイロード形式よりも優位性を提供する場合があります。
Another parameter that may impact the bandwidth demand for VMR-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 RTP/UDP/IP headers, at the expense of increased delay.
VMR-WBの帯域幅需要に影響を与える可能性のある別のパラメーターは、各RTPペイロードにカプセル化されているフレームブロックの数です。各RTPペイロードでより多くのフレームブロックを詰めると、送信されるパケットの数を減らすことができ、したがって、遅延の増加を犠牲にして、RTP/UDP/IPヘッダーからのオーバーヘッドを減らすことができます。
If forward error correction (FEC) is used to alleviate the 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によって追加される冗長性の量を調整する必要があります。
Congestion control for RTP SHALL be used in accordance with RFC 3550 [3] and any applicable RTP profile, for example, RFC 3551 [6]. This means that congestion control is required for any transmission over unmanaged best-effort networks.
RTPの輻輳制御は、RFC 3550 [3]およびRFC 3551 [6]などの該当するRTPプロファイルに従って使用するものとします。これは、管理されていないベストエフォルトネットワークを介した任意の伝送に輻輳制御が必要であることを意味します。
Congestion on the IP network is managed by the IP sender. 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 selecting an appropriate operating mode, but also includes adjusting the level of redundancy or number of frames per packet.
IPネットワークの輻輳は、IP送信者によって管理されます。RTCPまたはその他の手段を介してそのIP送信者に輻輳に関するフィードバックを提供する必要があり、その後、送信者は、最も適切なメカニズムを使用して渋滞を回避することを選択できます。これには、適切な動作モードの選択が含まれますが、パケットごとの冗長性またはフレーム数のレベルの調整も含まれます。
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in RTP [3] and any applicable profile such as AVP [9] or SAVP [10].
この仕様で定義されたペイロード形式を使用したRTPパケットは、RTP [3]で説明されている一般的なセキュリティ上の考慮事項と、AVP [9]やSAVP [10]などの該当するプロファイルの対象となります。
As this format transports encoded audio, the main security issues include confidentiality, integrity protection, and data origin authentication of the audio itself. The payload format itself does not have any built-in security mechanisms. Any suitable external mechanisms, such as SRTP [10], MAY be used.
この形式はエンコードされたオーディオを輸送するため、主なセキュリティの問題には、オーディオ自体の機密性、整合性保護、およびデータ起源の認証が含まれます。ペイロード形式自体には、組み込みのセキュリティメカニズムがありません。SRTP [10]などの適切な外部メカニズムを使用できます。
This payload format and the VMR-WB decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing; thus, they are unlikely to pose a denial-of-service threat due to the receipt of pathological data.
このペイロード形式とVMR-WBデコーダーは、パケット処理のためにレシーバー側の計算の複雑さに有意な不均一性を示さない。したがって、病理学的データの受領により、サービス拒否の脅威をもたらす可能性は低いです。
In order to ensure confidentiality of the encoded audio, all audio data bits MUST be encrypted. There is less need to encrypt the payload header or the table of contents since they only carry information about the frame type. This information could also be useful to a third party, for example, for quality monitoring.
エンコードされたオーディオの機密性を確保するには、すべてのオーディオデータビットを暗号化する必要があります。ペイロードヘッダーまたは目次は、フレームタイプに関する情報のみを搭載しているため、暗号化する必要性は少なくなります。この情報は、たとえば品質の監視など、第三者にとっても役立つ可能性があります。
The use of interleaving in conjunction with encryption can have a negative impact on the confidentiality for a short period of time. Consider the following packets (in brackets) containing frame numbers as indicated: {10, 14, 18}, {13, 17, 21}, {16, 20, 24} (a typical continuous diagonal interleaving pattern). The originator wishes to deny some participants the ability to hear material starting at time 16. Simply changing the key on the packet with the timestamp at or after 16, and denying the new key to those participants, does not achieve this; frames 17, 18, and 21 have been supplied in prior packets under the prior key, and error concealment may make the audio intelligible at least as far as frame 18 or 19, and possibly further.
暗号化と組み合わせてインターリーブを使用すると、短期間の機密性にマイナスの影響を与える可能性があります。示されているようにフレーム番号を含む次のパケット（括弧内）を考えてみましょう：{10、14、18}、{13、17、21}、{16、20、24}（典型的な連続した対角線インターリーブパターン）。オリジネーターは、時間16からの資料を聞く能力を参加者に否定したいと考えています。16時以降にパケットのキーを変更するだけで、参加者の新しいキーを否定しても、これは達成されません。フレーム17、18、および21は、以前のキーの下で以前のパケットに提供されており、エラーの隠蔽により、少なくともフレーム18または19まで、オーディオはわかりやすくなる可能性があります。
To authenticate the sender of the speech, an external mechanism MUST be used. It is RECOMMENDED that such a mechanism protects both the complete RTP header and the payload (speech and data bits).
スピーチの送信者を認証するには、外部メカニズムを使用する必要があります。このようなメカニズムは、完全なRTPヘッダーとペイロード（音声およびデータビット）の両方を保護することをお勧めします。
Data tampering by a man-in-the-middle attacker could replace audio content and also result in erroneous depacketization/decoding that could lower the audio quality. For example, tampering with the CMR field may result in speech of a different quality than desired.
中間の攻撃者によるデータの改ざんは、オーディオコンテンツを置き換える可能性があり、また、オーディオの品質を低下させる可能性のある誤ったデパケット化/デコードをもたらす可能性があります。たとえば、CMRフィールドを改ざんすると、目的とは異なる品質の音声が発生する可能性があります。
This section defines the parameters that may be used to select optional features in the VMR-WB RTP payload formats.
このセクションでは、VMR-WB RTPペイロード形式でオプションの機能を選択するために使用できるパラメーターを定義します。
The parameters are defined here as part of the MIME subtype registration for the VMR-WB speech codec. A mapping of the parameters into the Session Description Protocol (SDP) [5] is also provided for those applications that use SDP. In control protocols that do not use MIME or SDP, the media type parameters must be mapped to the appropriate format used with that control protocol.
パラメーターは、VMR-WB音声コーデックのMIMEサブタイプ登録の一部としてここで定義されています。セッション説明プロトコル（SDP）[5]へのパラメーターのマッピングは、SDPを使用するアプリケーションにも提供されています。MIMEまたはSDPを使用しないコントロールプロトコルでは、メディアタイプのパラメーターを、そのコントロールプロトコルで使用する適切な形式にマッピングする必要があります。
The MIME subtype for the Variable-Rate Multimode Wideband (VMR-WB) audio codec is allocated from the IETF tree since VMR-WB is expected to be a widely used speech codec in multimedia streaming and messaging as well as in VoIP applications. This MIME registration only covers real-time transfers via RTP.
VMR-WBはマルチメディアストリーミングとメッセージング、およびVoIPアプリケーションで広く使用されている音声コーデックであると予想されるため、可変レートマルチモードワイドバンド（VMR-WB）オーディオコーデックのMIMEサブタイプはIETFツリーから割り当てられています。このMIME登録は、RTPを介したリアルタイム転送のみをカバーしています。
Note, the receiver MUST ignore any unspecified parameter and use the default values instead. Also note that if no input parameters are defined, the default values will be used.
注意してください、受信者は不特定のパラメーターを無視し、代わりにデフォルト値を使用する必要があります。また、入力パラメーターが定義されていない場合、デフォルト値が使用されることに注意してください。
Media Type name: audio
メディアタイプ名：オーディオ
Media subtype name: VMR-WB
メディアサブタイプ名：VMR-WB
Required parameters: none
必要なパラメーター：なし
Furthermore, if the interleaving parameter is present, the parameter "octet-align=1" MUST also be present.
さらに、インターリーブパラメーターが存在する場合、パラメーター「Octet-Align = 1」も存在する必要があります。
OPTIONAL parameters:
オプションのパラメーター：
mode-set: Requested VMR-WB operating mode set. Restricts the active operating modes to a subset of all modes. Possible values are a comma-separated list of integer values. Currently, this list includes modes 0, 1, 2, and 3 [1], but MAY be extended in the future. If such mode-set is specified during session initiation, the encoder MUST NOT use modes outside of the subset. If not present, all operating modes in the set 0 to 3 are allowed for the session.
モードセット：VMR-WB操作モードセットを要求しました。アクティブな動作モードをすべてのモードのサブセットに制限します。考えられる値は、整数値のコンマ分離されたリストです。現在、このリストにはモード0、1、2、および3 [1]が含まれていますが、将来拡張される可能性があります。このようなモードセットがセッション開始時に指定されている場合、エンコーダーはサブセットの外側のモードを使用してはなりません。存在しない場合、セット0〜3のすべての動作モードがセッションに許可されます。
channels: The number of audio channels. The possible values and their respective channel order is specified in Section 4.1 in [6]. If omitted, it has the default value of 1.
チャネル：オーディオチャネルの数。可能な値とそれぞれのチャネル順序は、[6]のセクション4.1で指定されています。省略した場合、デフォルト値は1です。
octet-align: RTP payload format; permissible values are 0 and 1. If 1, octet-aligned payload format SHALL be used. If 0 or if not present, header-free payload format is employed (default).
Octet-Align：RTPペイロード形式。許容値は0および1です。1の場合、オクテットに合わせたペイロード形式を使用するものとします。0または存在しない場合、ヘッダーフリーのペイロード形式が採用されています（デフォルト）。
maxptime: See RFC 3267 [4] interleaving: Indicates that frame-block level interleaving SHALL be used for the session. Its value defines the maximum number of frame-blocks allowed in an interleaving group (see Section 6.3.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.
Maxptime：RFC 3267 [4]インターリーブを参照：セッションにはフレームブロックレベルのインターリーブが使用されることを示します。その値は、インターリービンググループで許可されているフレームブロックの最大数を定義します（セクション6.3.1を参照）。このパラメーターが存在しない場合、インターリーブを使用してはなりません。このパラメーターの存在は、オクテットに合わせた操作を使用することも自動的に意味します。
ptime: See RFC2327 [5]. It SHALL be at least one frame size for VMR-WB.
PTIME：RFC2327 [5]を参照してください。VMR-WBの少なくとも1つのフレームサイズでなければなりません。
dtx: Permissible values are 0 and 1. The default is 0 (i.e., No DTX) where VMR-WB normally operates as a continuous variable-rate codec. If dtx=1, the VMR-WB codec will operate in discontinuous transmission mode where silence descriptor (SID) frames are sent by the VMR-WB encoder during silence intervals with an adjustable update frequency. The selection of the SID update-rate depends on the implementation and other network considerations that are beyond the scope of this specification.
DTX：許容値は0および1です。デフォルトは0（つまり、DTXなし）です。ここで、VMR-WBは通常、連続変数レートコーデックとして動作します。DTX = 1の場合、VMR-WBコーデックは、調整可能な更新周波数を備えたSilence間隔でVMR-WBエンコーダによってSilence Descriptor（SID）フレームが送信される不連続伝送モードで動作します。SIDアップデートレートの選択は、この仕様の範囲を超えた実装およびその他のネットワーク考慮事項に依存します。
Encoding considerations:
考慮事項のエンコード：
This type is only defined for transfer of VMR-WB-encoded data via RTP (RFC 3550) using the payload formats specified in Section 6 of RFC 4348.
このタイプは、RFC 4348のセクション6で指定されたペイロード形式を使用して、RTP（RFC 3550）を介したVMR-WBエンコードデータの転送に対してのみ定義されます。
Security considerations:
セキュリティ上の考慮事項：
See Section 8 of RFC 4348.
RFC 4348のセクション8を参照してください。
Public specification:
公開仕様：
The VMR-WB speech codec is specified in 3GPP2 specifications C.S0052-0 version 1.0. Transfer methods are specified in RFC 4348.
VMR-WB音声コーデックは、3GPP2仕様C.S0052-0バージョン1.0で指定されています。転送方法は、RFC 4348で指定されています。
Additional information:
追加情報：
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Sassan Ahmadi, Ph.D. sassan.ahmadi@ieee.org
サッサン・アフマディ博士sassan.ahmadi@ieee.org
Intended usage: COMMON.
意図された使用法：共通。
It is expected that many VoIP, multimedia messaging and streaming applications (as well as mobile applications) will use this type.
多くのVoIP、マルチメディアメッセージング、およびストリーミングアプリケーション（およびモバイルアプリケーション）がこのタイプを使用することが予想されます。
Author/Change controller:
著者/変更コントローラー：
IETF Audio/Video Transport working group delegated from the IESG
IESGから委任されたIETFオーディオ/ビデオトランスポーキングワーキンググループ
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [5], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the VMR-WB codec, the mapping is as follows:
MIMEメディアタイプの仕様にある情報には、セッション説明プロトコル（SDP）[5]のフィールドへの特定のマッピングがあります。これは、RTPセッションを説明するために一般的に使用されます。SDPを使用してVMR-WBコーデックを使用したセッションを指定する場合、マッピングは次のとおりです。
- The media type ("audio") goes in SDP "m=" as the media name.
- メディアタイプ（ "Audio"）は、メディア名としてSDP "m ="になります。
- The media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000 for VMR-WB.
- メディアサブタイプ（ペイロード形式名）は、エンコーディング名としてSDP "a = rtpmap"になります。「a = rtpmap」のRTPクロックレートは、VMR-WBで16000でなければなりません。
- The parameter "channels" (number of channels) MUST be either explicitly set to N or omitted, implying a default value of 1. The values of N that are allowed is specified in Section 4.1 in [6]. The parameter "channels", if present, is specified subsequent to the MIME subtype and RTP clock rate as an encoding parameter in the "a=rtpmap" attribute.
- パラメーター「チャネル」（チャネルの数）は、nに明示的に設定するか、省略されている必要があり、1のデフォルト値を意味します。パラメーターの「チャネル」は、存在する場合、MIMEサブタイプとRTPクロックレートに続いて、「a = rtpmap」属性のエンコードパラメーターとして指定されます。
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
- パラメーター「PTIME」と「MAXPTIME」は、それぞれSDP「A = PTIME」と「A = MaxPtime」属性に移動します。
- Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the MIME media type string as a semicolon-separated list of parameter=value pairs.
- 残りのパラメーターは、MIMEメディアタイプの文字列から直接コピーすることにより、SDP "a = fmtp"属性に搭載されています。
Some examples of SDP session descriptions utilizing VMR-WB encodings follow.
VMR-WBエンコーディングを使用したSDPセッションの説明のいくつかの例が続きます。
Example of usage of VMR-WB in a possible VoIP scenario (wideband audio):
可能なVOIPシナリオ（ワイドバンドオーディオ）でのVMR-WBの使用例：
m=audio 49120 RTP/AVP 98
a=rtpmap:98 VMR-WB/16000
a=fmtp:98 octet-align=1
Example of usage of VMR-WB in a possible streaming scenario (two channel stereo):
可能なストリーミングシナリオでのVMR-WBの使用例（2チャンネルステレオ）：
m=audio 49120 RTP/AVP 99
a=rtpmap:99 VMR-WB/16000/2
a=fmtp:99 octet-align=1; interleaving=30
a=maxptime:100
To achieve good interoperability for the VMR-WB RTP payload in an Offer-Answer negotiation usage in SDP [13], the following considerations are made:
SDP [13]でのオファーアンスワーク交渉の使用におけるVMR-WB RTPペイロードの良好な相互運用性を実現するために、次の考慮事項が行われます。
- The rate, channel, and payload configuration parameters (octet-align and interleaving) SHALL be used symmetrically, i.e., offer and answer must use the same values. The maximum size of the interleaving buffer is, however, declarative, and each agent specifies the value it supports to receive for recvonly and sendrecv streams. For sendonly streams, the value indicates what the agent desires to use.
- レート、チャネル、およびペイロード構成パラメーター（Octet-AlignおよびInterleaving）は対称的に使用する必要があります。つまり、提供と回答は同じ値を使用する必要があります。ただし、インターリーブバッファーの最大サイズは宣言的であり、各エージェントは、RecvonlyおよびSendRecvストリームに対して受け取るためにサポートする値を指定します。Sendonlyストリームの場合、値はエージェントが使用したいものを示します。
- To maintain interoperability among all implementations of VMR-WB that may or may not support all the codec's modes of operation, the operational modes that are supported by an implementation MAY be identified at session initiation. The mode-set parameter is declarative, and only operating modes that have been indicated to be supported by both ends SHALL be used. If the answerer is not supporting any of the operating modes provided in the offer, the complete payload type declaration SHOULD be rejected by removing it from the answer.
- すべてのコーデックの動作モードをサポートする場合とそうでない場合があるVMR-WBのすべての実装間で相互運用性を維持するために、実装によってサポートされる運用モードがセッション開始時に特定される場合があります。モードセットパラメーターは宣言的であり、両端でサポートされることが示されている動作モードのみを使用するものとします。応答者がオファーで提供される操作モードのいずれをサポートしていない場合、回答から削除することにより、完全なペイロードタイプの宣言を拒否する必要があります。
- The remaining parameters are all declarative; i.e., for sendonly streams they provide parameters that the agent desires to use, while for recvonly and sendrecv streams they declare the parameters that it accepts to receive. The dtx parameter is used to indicate DTX support and capability, while the media sender is only RECOMMENDED to send using the DTX in these cases. If DTX is not supported by the media sender, it will send media without DTX; this will not affect interoperability only the resource consumption.
- 残りのパラメーターはすべて宣言的です。つまり、Sendonlyストリームの場合、エージェントが使用したいパラメーターを提供しますが、RecvonlyおよびSendRecvストリームのために、受け入れられることを受け入れるパラメーターを宣言します。DTXパラメーターは、DTXのサポートと機能を示すために使用されますが、メディア送信者は、これらの場合にDTXを使用して送信することのみをお勧めします。DTXがメディア送信者によってサポートされていない場合、DTXなしでメディアが送信されます。これは、リソース消費のみに相互運用性に影響しません。
- Both header-free and octet-aligned payload format configurations MAY be offered by a VMR-WB enabled terminal. However, for an interoperable interconnection with AMR-WB, only octet-aligned
- ヘッダーフリーとオクテットに並べられたペイロード形式の両方の構成は、VMR-WB対応端子によって提供される場合があります。ただし、AMR-WBとの相互運用可能な相互接続の場合、Octetに整列したみ
- The parameters "maxptime" and "ptime" should in most cases not affect the interoperability; however, the setting of the parameters can affect the performance of the application.
- ほとんどの場合、「Maxptime」と「PTIME」のパラメーターは相互運用性に影響しないはずです。ただし、パラメーターの設定は、アプリケーションのパフォーマンスに影響を与える可能性があります。
- To maintain interoperability with AMR-WB in cases where negotiation is possible using the VMR-WB interoperable mode, a VMR-WB-enabled terminal SHOULD also declare itself capable of AMR-WB with limited mode set (i.e., only AMR-WB codec modes 0, 1, and 2 are allowed) and of octet-align mode of operation.
- VMR-WB相互運用モードを使用して交渉が可能な場合にAMR-WBとの相互運用性を維持するには、VMR-WB対応端子も限られたモードセットでAMR-WBが可能であると宣言する必要があります（つまり、AMR-WBコーデックモードのみ0、1、および2が許可されています）およびOctet-Align操作モード。
Example:
例：
m=audio 49120 RTP/AVP 98 99
a=rtpmap:98 VMR-WB/16000
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 octet-align=1; mode-set=0,1,2
An example of offer-answer exchange for the VoIP scenario described in Section 5.3 is as follows:
セクション5.3で説明されているVoIPシナリオのオファー回答の例は次のとおりです。
CDMA2000 terminal -> WCDMA terminal Offer:
m=audio 49120 RTP/AVP 98 97
a=rtpmap:98 VMR-WB/16000
a=fmtp:98 octet-align=1
a=rtpmap:97 AMR-WB/16000
a=fmtp:97 mode-set=0,1,2; octet-align=1
WCDMA terminal -> CDMA2000 terminal Answer:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR-WB/16000
a=fmtp:97 mode-set=0,1,2; octet-align=1;
For declarative use of SDP such as in SAP [14] and RTSP [15], all parameters are declarative and provide the parameters that SHALL be used when receiving and/or sending the configured stream.
SAP [14]やRTSP [15]などのSDPを宣言するために、すべてのパラメーターは宣言的であり、構成されたストリームを受信および/または送信するときに使用するパラメーターを提供します。
The IANA has registered one new MIME subtype (audio/VMR-WB); see Section 9.
IANAは、1つの新しいMimeサブタイプ（Audio/VMR-WB）を登録しています。セクション9を参照してください。
The author would like to thank Redwan Salami of VoiceAge Corporation, Ari Lakaniemi of Nokia Inc., and IETF/AVT chairs Colin Perkins and Magnus Westerlund for their technical comments to improve this document.
著者は、この文書を改善するための技術的なコメントについて、Voiceage CorporationのRedwan Salami、Nokia Inc.のAri Lakaniemi、IETF/AVT椅子のColin PerkinsとMagnus Westerlundに感謝したいと思います。
Also, the author would like to acknowledge that some parts of RFC 3267 [4] and RFC 3558 [11] have been used in this document.
また、著者は、RFC 3267 [4]およびRFC 3558 [11]の一部がこのドキュメントで使用されていることを認めたいと考えています。
[1] 3GPP2 C.S0052-0 v1.0 "Source-Controlled Variable-Rate Multimode Wideband Speech Codec (VMR-WB) Service Option 62 for Spread Spectrum Systems", 3GPP2 Technical Specification, July 2004.
[1] 3GPP2 C.S0052-0 V1.0 "ソース制御可変レートマルチモードワイドバンド音声コーデック（VMR-WB）サービスオプション62スプレッドスペクトルシステム用"、3GPP2技術仕様、2004年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[3] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[4] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
[4] Sjoberg、J.、Westerlund、M.、Lakaniemi、A。、およびQ. Xie、「リアルタイムトランスポートプロトコル（RTP）ペイロード形式とファイルストレージ形式（AMR）および適応型マルチレートワイドバンドのファイルストレージ形式（AMR-WB）Audio Codecs "、RFC 3267、2002年6月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[6] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[6] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[7] 3GPP2 C.S0050-A v1.0 "3GPP2 File Formats for Multimedia Services", 3GPP2 Technical Specification, September 2005.
[7] 3GPP2 C.S0050-A V1.0 "マルチメディアサービス用の3GPP2ファイル形式"、3GPP2技術仕様、2005年9月。
[8] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[8] Rosenberg、J。およびH. Schulzrinne、「一般的なフォワードエラー補正のためのRTPペイロード形式」、RFC 2733、1999年12月。
[9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[9] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「セキュアリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[10] 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.
[10] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-Parisis、 "RTPペイロードデータ」、RFC 2198、1997年9月。
[11] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003.
[11] Li、A。、「強化された可変レートコーデック（EVRC）および選択可能なモードボコーダー（SMV）のRTPペイロード形式」、RFC 3558、2003年7月。
[12] 3GPP TS 26.193 "AMR Wideband Speech Codec; Source Controlled Rate operation", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[12] 3GPP TS 26.193「AMRワイドバンド音声コーデック、ソース制御レート操作」、バージョン5.0.0（2001-03）、第3世代パートナーシッププロジェクト（3GPP）。
[13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[13] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[14] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[15] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[15] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
Any 3GPP2 document can be downloaded from the 3GPP2 web server, "http://www.3gpp2.org/", see specifications.
3GPP2ドキュメントは、3GPP2 Webサーバー「http://www.3gpp2.org/」からダウンロードできます。仕様を参照してください。
Author's Address
著者の連絡先
Dr. Sassan Ahmadi EMail: sassan.ahmadi@ieee.org
Sassan Ahmadi博士のメール：sassan.ahmadi@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。