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
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document specifies a real-time transport protocol (RTP) payload format 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は、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.
この文書は、リアルタイムトランスポートプロトコル（RTP）にVMR-WB符号化された音声信号のパケットのためのペイロードのフォーマットを指定する[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音声データの輸送のため）[7]で指定されたVMR-WBファイル形式で記述されています。第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と相互運用可能であるため、試行はVMR-WBコーデックの非相互運用モードのペイロード・フォーマットを最適化しながら、RFC 3267との類似性を最大にするために、この文書全体にわたってなされています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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 - 第三世代パートナーシッププロジェクト3GPP2 - 第三世代パートナーシッププロジェクト2 CDMA - 符号分割多元接続のWCDMA - 広帯域符号分割多元接続のGSM - グローバルシステムモバイルコミュニケーションズAMR-WBのために - 適応マルチレート広帯域コーデックVMR-WB - 変数-rateマルチモード広帯域コーデックCMR - コーデックモード要求GW - ゲートウェイDTX - 不連続伝送FEC - 前方誤り訂正SID - サイレンス記述子TRFO - トランスコーダフリーオペレーションUDP - ユーザーデータグラムプロトコルRTP - リアルタイムトランスポートプロトコルRTCP - RTP制御プロトコルMIME - 多目的インターネットメール拡張SDP - セッション記述プロトコルのVoIP - ボイスオーバー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個の音声フレーム、チャネルのそれぞれからの1つを含有する、すべての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 [1]符号化/ 3G CDMAセルラシステムでマルチメディアサービスにおいて、広帯域/狭帯域音声コンテンツを復号するための第三世代パートナーシッププロジェクト2（3GPP2）によって開発された広帯域音声符号化標準です。 VMR-WBは、ソース制御可変レートマルチモード広帯域音声コーデックです。これは、各モードは、音声品質と平均データレートとの間のトレードオフである動作モードの数を有しています。 VMR-WB（表2に示されるように）中の動作モードは、ネットワークのトラフィック状況やサービスの所望の品質に基づいて選択されます。各モードでの所望の平均データレート（ADR）は、入力音声と課される最大および最小レート制約の瞬間的な特性に応じて、CDMA2000システムに準拠した（表1及び図3に示すように）許容速度で音声フレームを符号化することによって得られます。ネットワークオペレータによる。
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でAMR-WB [4,12]、8.85、および6.60 kbpsのとさらに相互運用可能です。これは、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で唯一AMR-WB相互運用モードがあるため、相互運用可能モードで（すなわち、VMR-WBモード3）、VMR-WBモード間のモード切り替えが許可されません。 AMR-WBコーデックは、チャネル条件に応じて、モード変更を要求することができるので、インバンド・データは、VMR-WBフレーム構造に含まれる（詳細については、[1]のセクション8を参照）VMR切り替えるために、相互運用可能な相互接続の間に使用されますVMR-WBモード3における-WBフレームタイプ0、1、及び2（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を表1に示した許容符号化率と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ヘルツまたは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コーデック、また、許可されているセッション中の注入と8000 Hzの狭帯域メディアの処理のために16000-HzのRTPクロックレートを画定します。しかし、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.
別々に符号化されたマルチチャネル・コンテンツを転送するために、同じ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 (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].
セッションセットアップで、アウトオブバンドシグナリングは、セッション内のチャネルの数と、各フレームブロック内の異なるチャネルからの音声フレームの順序を示すために使用されなければなりません。 （詳細はセクション9.2を参照）をシグナリングするためのSDPを使用する場合、チャネルの数は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を達成するための一つの方法です。より多くの帯域幅が効率的である別の可能な方式は、ペイロード外部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ペイロードパケットに一回再送されます。ここで、F（N-2）..（4 + N）F音声フレームブロックのシーケンスを示し、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.
この冗長方式は、[10]そのRFC 2198に記載され、「冗長オーディオデータのRTPペイロード」と同じ機能を提供します。一次及び冗長符号化との間に必要とされる時間の広がりは、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受信機レポートで例えば、）チャネルまたはネットワークトラフィックに関するフィードバックに基づいて、冗長性の適切な量を選択する責任があります。送信者は、このパラメータとしてCMR上のFECのベース選択は、おそらく非IP情報に基づいて設定されたべきではありません。送信者は、冗長送信によって悪化され得る渋滞を回避する責任がある（セクション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).
オクテット整列ペイロードフォーマットは、オプションとして、フレームインターリービングの使用をサポートします。エンコーダ（音声送信者）特定のセッションのためにその発信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.
このペイロード形式のための一次シナリオは、IPエンド・ツー・エンドのVMR-WBコーデックを組み込んだ二つの端子との間にあるにもかかわらず、図2に示すように、このシナリオでは、VMR-WB対応とAMR-WBとの間の相互運用可能な相互接続に一般化することができますセクション9.3で説明したオファーアンサーモデルを使用してIP端末を-enabled。このペイロード形式は、会話とストリーミングの両方のサービスのために有用であると期待されています。
+----------+ +----------+
| | | |
| 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端末に非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端末は、非IPデコーダに行くスピーチ品質を最適化するためにゲートウェイによって転送CMRに従うべきです。ゲートウェイにおけるモード制御アルゴリズムは、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.
CMRを設定しないIP端末（セクション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.
第三の可能性の高いシナリオは、図4に示すように、RTP / UDP / IPは、すなわち、IPはIPトランスポートの両側のゲートウェイで発信され、終了される二つの非IPシステム間でトランスポートとして使用される。これは、最も可能性が高いことです3GPP /（GSM-WCDMA）/ AMR-WBおよび3GPP2 / CDMA2000 / VMR-WB対応の移動局との間の相互運用可能な相互接続のためのシナリオ。このシナリオでは、VMR-WB対応端末は、セクション9.3に記載されるように設定制限モードとAMR-WBの可能自体を宣言する。 CMR値はIPネットワーク側のゲートウェイが受信したパケットに設定されてもよいです。ゲートウェイは、非IP側に3つの値の最小値であるCMR値を転送しなければならない：（1）それがIP側で受信するCMR値を、 （2）それがIP側で伝送の輻輳制御のために選択することができるCMR値を、 （3）非IP側で受信品質の推定値に基づいてCMR値。トラフィック制御アルゴリズムの詳細は実装に任されています。
VMR-WB over AMR-WB over 3GPP2/CDMA2000 network 3GPP/(GSM-WCDMA) network
3GPP2 / CDMA2000ネットワーク、3GPP（GSM / WCDMA）ネットワークを介してAMR-WB上VMR-WB
+------+ +------+
(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)
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と互換性があり、このモード内で、（表3参照即ち、FT = 0、1、又は2）、及び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シナリオは二つの非IPシステム間のRTP / UDP / IPトランスポートで構成されています。図5.これで、モバイルステーションと移動局（MS-に-MS）トランスコーダフリーのための最も可能性の高いシナリオ（に示すように、すなわち、IPは、IPトランスポートの両側でのゲートウェイに由来し、終了されます両方のVMR-WBコーデックを使用する2つの3GPP2 / CDMA2000端子間TRFO）の相互接続。
VMR-WB over VMR-WB over 3GPP2/CDMA2000 network 3GPP2/CDMA2000 network
3GPP2 / CDMA2000 / 3GPP2ネットワークCDMA2000ネットワーク上のVMR-WBオーバーVMR-WB
+------+ +------+
| | | |
<------------>| 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対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]).
ヘッダフリーペイロードフォーマットは、最大帯域幅効率、単純性、および低レイテンシのために設計されています。唯一のコーデックデータフレームは、それぞれヘッダを含まないペイロードフォーマットのパケットで送信することができます。コンテンツ（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.
オクテット整列ペイロードフォーマットにおいて、ペイロードヘッダ、コンテンツエントリのテーブル、音声自体フレームを含むペイロード内のすべてのフィールドは、個別実装が効率的にするためにオクテット境界に整列されます。
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つのペイロードフォーマット間の、唯一のオクテット整列フォーマットは、パケットロスへの音声トランスポートは堅牢にするためにインターリーブを使用する機能を持っています。
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タイムスタンプは、パケットの最初のフレームのブロックについて符号化された第1のサンプルのサンプリング時点に対応します。タイムスタンプユニットがサンプルにあるように、タイムスタンプのクロック周波数は、既定のサンプリング周波数（すなわち、16kHzの）と同じです。
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の通常の広帯域動作のために、入力/出力メディアサンプリング周波数は、各チャネルからのフレーム当たり320個のサンプルに対応し、16kHzです。従って、タイムスタンプは各連続フレームブロックに対する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コーデックは、8kHzでサンプリングされた音声/オーディオ信号を処理することが可能です。デフォルトでは、VMR-WBデコーダ出力サンプリング周波数は16kHzです。用途に応じて、デコーダは、同様に、8 kHzの出力サンプリング周波数を生成するように構成することができます。 8および16 kHzのサンプリングされたメディアのVMR-WB RTPペイロードフォーマットは同一であり、VMR-WBデコーダは、エンコーダ入力サンプリング周波数についての事前知識を必要としない、16000ヘルツの固定RTPクロックレートは、のために定義されているのでVMR-WBコーデック。これは、セッションの間にRTPクロックレートを変更することなく注射または8kHzのサンプリングされた音声/オーディオメディアの処理を可能にするであろう。タイムスタンプは、同様に、8kHzのサンプリングされたメディアのフレームブロック当たり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で定義されたインターリービング規則に従って取り出されます。そうでなければ、各パケットは、一つ以上の連続する20ミリ秒フレームブロック間隔の期間をカバーします。場合期間中の特定のフレームブロックのすべてのチャネルからのデータが欠落している（例えば、いくつかの他のトランスポート・フォーマットからゲートウェイで）、そのデータがそのフレームブロックの代わりにのために存在しないことを示すことができますセクション6.3.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.
ヘッダフリーペイロードフォーマットは、最大帯域幅効率、単純性、及び最小遅延のために設計されています。唯一の音声データフレームは、各ヘッダを含まないペイロードフォーマットのパケットに提示します。ペイロードヘッダフィールドまたは目次のエントリのいずれも存在しません。各ヘッダフリーペイロード形式で唯一の音声データフレームが存在するので、音声フレームの符号化率は、音声データのフレームの長さから決定することができます。
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ヘッダフィールドの使用は、オクテット整列ペイロード形式のための対応するものと同じです。このペイロード形式の許容音声データ・パケットの詳細なビット・マッピングは、[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.
以下に示すようにオクテット整列ペイロードフォーマットにおいて、ペイロードヘッダは、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より大きい発見された場合、ペイロードは廃棄されるべきです。
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を設定する必要があり、端末が受信モードでは嗜好を持っていない場合には、IN = 15 CMRを設定すべきですそのすべてのアウトバウンドペイロード。
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).
（I）（例えば、GW IPに端末シナリオで）ゲートウェイを介して接続された任意のCDMAリンクの性能、およびIPネットワークの（ii）の輻輳状態：VMR-WBモードの選択に影響を与える2つの要因があります。 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)
フレームブロックを運ぶ：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)
ペイロード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 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)
ペイロード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 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の値の数は、インタリーブグループ内で変更してはいけません。換言すれば、インタリーブグループ内のすべてのペイロードは同じ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.
受信機は、帯域外手段によってその使用を合図している場合、ペイロードの送信者は、インターリーブを適用する必要があります。インターリービングは受信機においてバッファリング要件を増大させるため、受信機は、Iにインタリーブグループで許可フレームブロックの最大数を設定するMIMEパラメータ「インターリーブ= 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.
インタリーブを行う際インタリーブグループの結果の大きさがより小さいかIに等しくなるように、送信者はILLペイロード当たりのフレームブロック（N）の適切な番号を使用する必要があり、即ち、N *（L + 1）<=私。
The following example shows the ToC of three consecutive packets, each carrying 3 frame-blocks, in an interleaved two-channel session.
次の例は、インタリーブ2チャンネルのセッションでは、3つの連続したパケット、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 ILL、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.
目次のオクテット整列ペイロードフォーマットのコンテンツ（TOC）のテーブルインターリーブが使用される場合、各エントリは、すなわち、ペイロードで運ばれた音声フレームに対応する目次エントリのリストから成り、フレームブロック意志ほとんど決して時間内に連続して配置します。代わりに、パケット内のフレームブロックの存在および順序は、6.3.2で説明したパターンに従うことになります。
+---------------------+
| list of ToC entries |
+---------------------+
A ToC entry for the octet-aligned payload format is as follows:
次のようにオクテット整列ペイロード形式のための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）は、目次のエントリのリスト、それぞれ表す音声フレームから成ります。
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]).
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に設定した場合、対応するフレームが破損していることを示しています。 Q = 0の場合、相互運用可能モードの間、（AMR-WBコーデック）受信側は、フレームタイプ（FT）に応じSPEECH_BADまたはSID_BADいずれかにRX_TYPEを設定しなければなりません。 VMR-WBエンコーダは常にVMR-WBデコーダは、Qビットを無視することができる1に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.
マルチチャネル・セッションのために、フレームブロックから全てのフレームの目次のエントリは、連続した順序で目次に配置されています。したがって、パケット内のNチャネルおよびK音声フレームブロックと、目次にN * K個のエントリが存在しなければなりません、そして、最初のN個のエントリが最初のフレームのブロックからなり、第Nのエントリが第二フレームからなり - ブロック、というように。
Speech data of a payload contains one or more speech frames as described in the ToC of the payload.
ペイロードの目次に記載されているように、ペイロードの音声データは、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つのオクテット、又は両者のペイロードヘッダで始まります。ペイロードヘッダは、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.
音声データは、内容のテーブルに従います。パケット化の目的のために、音声フレームを含むすべてのオクテットはユニットとしてペイロードに付加されています。音声フレームは、所与のフレームはFT = 14又は15とのToCエントリを有する場合、そのフレームの存在しないデータオクテットがないことを除いて、それらの対応する目次エントリは目次のリストに配置されているのと同じ順序で充填されています。
6.3.5. Payload Example: Basic Single Channel Payload Carrying Multiple Frames
6.3.5. ペイロード例：基本的なシングルチャネルペイロードは、複数のフレームを運びます
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）を搬送する単一のチャネル・セッションからオクテット整列ペイロードフォーマットを示します。ペイロードに、コーデックモード要求は、受信者側の使用VMR-WBモード1いいえインターリーブにエンコーダが使用されることを要求し、（例えば、CMR = 4）に送られます。一例では、両方の音声フレームの最後のオクテットは、オクテット整列それらを作るためにゼロで埋められ下回ることに注意してください。
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)
R = F1（264265）L = F2（264265）
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ペイロードの実装は、関連する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自体の使用は混雑問題を起こさないように、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]、該当RTPプロファイルに従って使用されるもの、RFC 3551 [6]。これは、輻輳制御が管理されていないベストエフォート型のネットワーク上で任意の伝送のために必要であることを意味します。
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パケットは、AVPとしてRTP [3]で説明した一般的なセキュリティ問題と該当のプロファイルの対象となっている[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.
man-in-the-middle攻撃者によって改ざんデータは、オーディオコンテンツを交換しても、オーディオ品質を下げることができ、誤った逆パケット化/デコードにつながる可能性があります。例えば、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.
インターリーブパラメータが存在する場合はさらに、パラメータ「オクテットアライン= 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]を含むが、将来的に拡張することができます。そのようなモードセットは、セッション開始時に指定されている場合、エンコーダは、部分集合の外側のモードを使用してはいけません。存在しない場合は、3にセット0で、すべての動作モードは、セッションのために許可されています。
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.
チャンネル：オーディオチャンネル数。可能な値とそれらのそれぞれのチャネル順序はセクション4.1で指定されている[6]。省略した場合、それは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).
オクテットアライン：RTPペイロードフォーマット。許容値は0と1 1の場合であり、オクテット整列ペイロードフォーマットを使用しなければなりません。もし0または存在しない、ヘッダフリーペイロードフォーマットは、（デフォルト）使用される場合。
maxptime: See RFC 3267 [4]
maxptime：[4] RFC 3267を参照してください。
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.
インターリーブ：フレームブロックレベルのインターリービングがセッションのために使用しなければならないことを示します。その値はインタリーブグループで許可フレームブロックの最大数を定義（6.3.1項参照）。このパラメータが存在しない場合、インタリーブを使用してはなりません。このパラメータの存在は、オクテット整列動作を使用しなければならないことを自動的に意味しています。
ptime: See RFC2327 [5]. It SHALL be at least one frame size for VMR-WB.
PTIME：RFC2327 [5]を参照してください。これは、VMR-WBのための少なくとも一つのフレームサイズであるものとします。
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で0と1である（すなわち、無DTX）VMR-WBは、通常、連続可変レートコーデックとして動作します。 DTX = 1の場合、VMR-WBコーデックは、無音記述子（SID）フレーム不連続送信モードで動作する調節可能な更新頻度を有するサイレンスインターバル中にVMR-WBエンコーダによって送信されます。 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.
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.
Additional information:
追加情報：
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Sassan Ahmadi, Ph.D. sassan.ahmadi@ieee.org
部品アーマディ、博士sassan.ahmadi@ieee.org
Intended usage: COMMON.
意図している用法：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メディアタイプの仕様で搬送される情報は、[5]、一般にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）内のフィールドに特定のマッピングを有します。 SDPは、VMR-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 16000 for VMR-WB.
- メディアサブタイプ（ペイロードフォーマット名）エンコーディング名としてSDPの「a = rtpmap」に進みます。 「= 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に設定するか省略しなければならないのいずれかで、許可されているNの値は、[6]に、セクション4.1で指定された1のデフォルト値を意味します。パラメータ「チャネル」は、存在する場合、「A = rtpmap」属性内の符号化パラメータとして、MIMEサブタイプとRTPクロックレートに続いて指定されます。
- 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 MIME media type string as a semicolon-separated list of parameter=value pairs.
- 残りのパラメータは、パラメータ=値のペアをセミコロンで区切ったリストで、MIMEメディアタイプ文字列から直接コピーすることにより、SDPに「=の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
M =オーディオ49120 RTP / AVP 98 = rtpmap：98 VMR-WB / 16000 =のfmtp：98オクテットアライン= 1
Example of usage of VMR-WB in a possible streaming scenario (two channel stereo):
可能なストリーミングのシナリオ（2つのチャンネルステレオ）でVMR-WBの使用例：
m=audio 49120 RTP/AVP 99 a=rtpmap:99 VMR-WB/16000/2 a=fmtp:99 octet-align=1; interleaving=30 a=maxptime:100
M =オーディオ49120 RTP / AVP 99 = rtpmap：99 VMR-WB / 2分の16000 A =のfmtp：99オクテットアライン= 1。インターリーブ= 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.
- レート、チャンネル、及びペイロード構成パラメータ（オクテットアライン及びインターリービング）対称的に使用されるもの、すなわち、オファーと答えが同じ値を使用しなければなりません。インタリーブバッファの最大サイズは、しかし、宣言型であり、各エージェントは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との相互運用性の相互接続のために、唯一のオクテットが整列します
- 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が許可され）、動作のオクテットアラインモード。
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;
WCDMA端末 - > CDMA2000端末回答：M =オーディオ49120 RTP / AVP 97 = rtpmap：97 AMR-WB / 16000 =のfmtp：97モード設定= 0,1,2。オクテットアライン= 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サブタイプ（オーディオ/ 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.
著者は、ボイスエイジ社のRedwanサラミ、ノキア社のアリLakaniemiに感謝したいと思い、およびIETF / AVTは、このドキュメントを改善するために、彼らの技術的なコメントをコリンパーキンスとマグヌスウェスターの議長を務めます。
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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[3] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[4] 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.、ウェスター、M.、Lakaniemi、A.、およびQ.謝、「リアルタイムトランスポートプロトコル（RTP）ペイロードフォーマットと適応マルチレート（AMR）と適応マルチ用ストレージファイル形式を-rate広帯域（AMR-WB）オーディオコーデック」、RFC 3267、2002年6月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5]ハンドリー、M.および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-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]ローゼンバーグ、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.、マグリュー、D.、Naslund、M.、カララ、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]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ・ガルシア、A.、およびS.フォッシー-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]李、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]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[14]ハンドレー、M.、パーキンス、C.、およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。
[15] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[15] SchulzrinneとH.とラオと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文書は、仕様を参照してください、「http://www.3gpp2.org/」、3GPP2のWebサーバーからダウンロードすることができます。
Author's Address
著者のアドレス
Dr. Sassan Ahmadi EMail: sassan.ahmadi@ieee.org
博士アフマディー部品電子メール：sassan.ahmadi@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。