[要約] RFC 4788は、EVRCファミリーコーデックのRTPペイロード形式の改善に関するものです。このRFCの目的は、EVRCファミリーコーデックのパフォーマンスを向上させるための改良を提案することです。
Network Working Group Q. Xie
Request for Comments: 4788 Motorola
Updates: 3558 R. Kapoor
Category: Standards Track Qualcomm
January 2007
Enhancements to RTP Payload Formats for EVRC Family Codecs
EVRCファミリーコーデックのRTPペイロードフォーマットの拡張
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions. In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP. Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth.
このドキュメントは、RFC 3558で定義された拡張変数レートコーデック（EVRC）RTPペイロード形式をいくつかの拡張と拡張機能を更新します。特に、EVRC-B Codecのヘッダーフリーおよびインターリーブ/バンドルされたパケット形式、EVRCおよびEVRC-Bコーデックの新しいコンパクトバンドル形式、およびEVRCおよびEVRCの不連続な送信（DTX）サポートを定義します。RTPを介して輸送されるEVRC-BENCODED音声。ボイスオーバーIP（VOIP）アプリケーションは、低帯域幅のダイヤルアップおよびワイヤレスネットワークで動作します。帯域幅を効率的に使用するためにこのような機能強化が必要です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Support of EVRC-B Codec . . . . . . . . . . . . . . . . . 3
1.2. Compact (Header-free) Bundled Format . . . . . . . . . . . 3
1.3. Discontinuous Transmission (DTX) . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. EVRC-B Codec . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Compact Bundled Format . . . . . . . . . . . . . . . . . . . . 5
4.1. Single-Rate Operation . . . . . . . . . . . . . . . . . . 5
5. Storage Format for EVRC-B Codec . . . . . . . . . . . . . . . 6
6. Media Type Definitions . . . . . . . . . . . . . . . . . . . . 6
6.1. Registration of Media Type EVRC1 . . . . . . . . . . . . . 6
6.2. Registration of Media Type EVRCB . . . . . . . . . . . . . 9
6.3. Registration of Media Type EVRCB0 . . . . . . . . . . . . 11
6.4. Registration of Media Type EVRCB1 . . . . . . . . . . . . 12
6.5. Updated Registration of Media Type EVRC . . . . . . . . . 13
6.6. Updated Registration of Media Type EVRC0 . . . . . . . . . 15
6.7. Mapping MIME Parameters into SDP . . . . . . . . . . . . . 17
6.8. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 18
7. Backward Compatibility with RFC 3558 . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 20
This document defines support for the header-free and interleaved/ bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP. Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such EVRC RTP payload capabilities for efficient use of the bandwidth.
このドキュメントでは、EVRC-B Codecのヘッダーフリーおよびインターリーブ/バンドルされたパケット形式、EVRCおよびEVRC-Bコーデックの新しいコンパクトバンドル形式、およびEVRCおよびEVRCの不連続伝送（DTX）サポートを定義します。RTPを介して輸送されるBエンコードされた音声。ボイスオーバーIP（VOIP）アプリケーションは、低帯域幅のダイヤルアップおよびワイヤレスネットワークで動作します。帯域幅を効率的に使用するために、このようなEVRC RTPペイロード機能が必要です。
EVRC-B [3] is an extension to EVRC [2] developed in the Third Generation Partnership Project 2 (3GPP2). EVRC-B [3] compresses each 20 milliseconds of 8000Hz, 16-bit sampled speech input into output frames of one of the four different sizes: Rate 1 (171 bits), Rate 1/2 (80 bits), Rate 1/4 (40 bits), or Rate 1/8 (16 bits). In addition, there are two zero-bit codec frame types: null frames and erasure frames, similar to EVRC [2]. One significant enhancement in EVRC-B is the use of 1/4-rate frames that were not used in EVRC. This provides lower average data rates (ADRs) compared to EVRC, for a given voice quality.
EVRC-B [3]は、第3世代パートナーシッププロジェクト2（3GPP2）で開発されたEVRC [2]の拡張です。EVRC-B [3]は、8000Hzの各20ミリ秒、4つの異なるサイズのいずれかの出力フレームに16ビットサンプリングされた音声入力を圧縮します：レート1（171ビット）、レート1/2（80ビット）、レート1/4（40ビット）、またはレート1/8（16ビット）。さらに、EVRCと同様のヌルフレームと消去フレームの2つのゼロビットコーデックフレームタイプがあります[2]。EVRC-Bの重要な強化の1つは、EVRCで使用されていない1/4レートフレームの使用です。これにより、特定の音声品質に対して、EVRCと比較してより低い平均データレート（ADR）が提供されます。
Since speech frames encoded by EVRC-B are different from those encoded by EVRC, EVRC-B and EVRC codecs do not interoperate with each other. At the initiation of an RTP session, the RTP sender and receiver need to indicate (e.g., using MIME subtypes that are separate from those of EVRC) that EVRC-B is to be used for the ensuing session.
EVRC-Bによってエンコードされた音声フレームはEVRCによってエンコードされたものとは異なるため、EVRC-BとEVRCコードは互いに相互運用しません。RTPセッションの開始時に、RTP送信者と受信機は、EVRC-Bが次のセッションに使用されることを示す必要があります（たとえば、EVRCのものとは別のMIMEサブタイプを使用する）。
The current interleaved/bundled packet format defined in RFC 3558 allows bundling of multiple speech frames of different rates in a single RTP packet, sending mode change requests, and interleaving. To support these functions, a Table of Contents (ToC) is used in each RTP packet, in addition to the standard RTP header. The size of the ToC varies depending on the number of EVRC frames carried in the packet [4].
RFC 3558で定義されている現在のインターリーブ/バンドルされたパケット形式により、単一のRTPパケットで異なるレートの複数の音声フレームをバンドルすることができ、モード変更リクエストの送信、およびインターリーブが可能になります。これらの機能をサポートするために、標準のRTPヘッダーに加えて、各RTPパケットで目次（TOC）が使用されます。TOCのサイズは、パケットにあるEVRCフレームの数によって異なります[4]。
The current header-free packet format defined in RFC 3558 is more compact and optimized for use over wireless links. It eliminates the need for a ToC by requiring that each RTP packet contain only one speech frame (of any allowable rate), i.e., bundling is not allowed. Moreover, interleaving and mode change requests are not supported in the header-free format [4].
RFC 3558で定義されている現在のヘッダーフリーパケット形式は、よりコンパクトで、ワイヤレスリンクを介した使用に最適化されています。各RTPパケットには、（許容レートの）1つの音声フレームのみを含めることを要求することにより、TOCの必要性を排除します。つまり、バンドリングは許可されません。さらに、ヘッダーフリー形式[4]では、リービング間およびモードの変更リクエストはサポートされていません。
The compact bundled format described in this document presents the user an alternative to the header-free format defined in RFC 3558. This format allows bundling of multiple EVRC or EVRC-B frames without the addition of extra headers, as would be in the case of the interleaved/bundled format. However, in order to use this compact bundled format, only one EVRC/EVRC-B rate (full rate or 1/2 rate) can be used in the session. Similar to the header-free format defined in RFC 3558, interleaving and mode change requests are not supported in the compact bundled format.
このドキュメントで説明されているコンパクトバンドル形式は、ユーザーにRFC 3558で定義されているヘッダーフリー形式の代替案を提示します。この形式は、追加のヘッダーを追加せずに複数のEVRCまたはEVRC-Bフレームをバンドルすることができます。インターリーブ/バンドル形式。ただし、このコンパクトバンドル形式を使用するには、セッションで使用できるEVRC/EVRC-Bレート（フルレートまたは1/2レート）のみを使用できます。RFC 3558で定義されているヘッダーフリー形式と同様に、コンパクトバンドル形式ではインターリーブおよびモード変更リクエストがサポートされていません。
Information carried in frames of EVRC and EVRC-B codecs varies little during periods of silence. The transmission of these frames across the radio interface in a wireless system is expensive, in terms of capacity; therefore, suppression of these frames is desirable. Such an operation is called DTX, also known as silence suppression.
EVRCおよびEVRC-Bコーデックのフレームで運ばれる情報は、沈黙の期間中はほとんど変化しません。ワイヤレスシステムでの無線インターフェイス全体にあるこれらのフレームの送信は、容量の点で高価です。したがって、これらのフレームの抑制が望ましいです。このような操作は、沈黙抑制とも呼ばれるDTXと呼ばれます。
In general, when DTX/silence suppression is applied, the first few frames of silence may be transmitted at the beginning of the period of silence to establish background noise. Then, a portion of the stream of subsequent silence frames is not transmitted, and is discarded at the sender. At the receiver, background or comfort noise may be generated by using the previously received silence frames.
一般に、DTX/沈黙の抑制が適用されると、沈黙の最初の数フレームが沈黙の期間の開始時に送信されて、背景ノイズを確立することができます。次に、後続の沈黙フレームのストリームの一部は送信されず、送信者に廃棄されます。レシーバーでは、以前に受信した沈黙フレームを使用して、背景または快適なノイズが生成される場合があります。
The full detail of DTX/silence suppression operation can be found in DTX [8] as well as in RFC 3551 [9], and in RFC 3558 [4]. This document only defines the additional optional MIME parameters (silencesupp, dtxmax, dtxmin, and hangover) for setting up a DTX/ silence suppression session, where "silencesupp" is for indicating the capability and willingness of using DTX/silence suppression; "dtxmax" and "dtxmin", for indicating the desired range of DTX update interval; and "hangover", for indicating the desired number of silence frames at the beginning of each silence period to establish background noise at the receiver (see Section 6.1 for detailed definition).
DTX/沈黙抑制操作の詳細は、DTX [8]、RFC 3551 [9]、およびRFC 3558 [4]にあります。このドキュメントでは、DTX/サイレンス抑制セッションを設定するための追加のオプションのMIMEパラメーター（SilencesUpp、DTXMax、DTXMIN、およびDTXMIN、DTXMIN、DTXMIN）のみを定義します。「SilencesUpp」は、DTX/沈黙抑制を使用する能力と意欲を示すためです。dtx更新間隔の望ましい範囲を示すための「dtxmax」および「dtxmin」。「二日酔い」。各サイレンス期間の開始時に希望の数の沈黙フレームを示すために、受信機にバックグラウンドノイズを確立することを示すために（詳細な定義についてはセクション6.1を参照）。
The EVRC and EVRC-B codecs, in variable-rate operation mode, send 1/8-rate frames during periods of silence, while in single-rate operation mode (see Section 4), silence is encoded and sent in frames of the same rate as that of speech frames. The DTX parameters defined in this document apply to 1/8-rate frames in the variable-rate mode and to silence frames in the single-rate operation mode.
EVRCおよびEVRC-B Codecsは、可変レート操作モードで、沈黙の期間中に1/8レートフレームを送信しますが、単一レート操作モード（セクション4を参照）では、沈黙がエンコードされ、同じフレームで送信されます。音声フレームの評価。このドキュメントで定義されているDTXパラメーターは、変数レートモードの1/8レートフレームに適用され、単一レート操作モードでフレームを沈黙させます。
For simplicity, in the rest of this document the term "silence frame" refers either to an 1/8-rate frame in variable-rate operation or a frame that contains only silence in the signal-rate operation.
簡単にするために、このドキュメントの残りの部分では、「Silence Frame」という用語は、可変レート操作の1/8レートフレームまたは信号レート操作に沈黙のみを含むフレームのいずれかを指します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]に記載されているように解釈される。
Three RTP packet formats are supported for the EVRC-B codec: the interleaved/bundled packet format, the header-free packet format, and the compact bundled packet format. For the interleaved/bundled and header-free packet formats, the operational details and capabilities, such as ToC, interleaving, and bundling, of EVRC-B, are exactly the same as those of EVRC, as defined in RFC 3558 [4], except that the mode change request field in the ToC MUST be interpreted according to the definition of the RATE_REDUC parameter in EVRC-B [3]. The compact bundled packet format for EVRC-B is defined in Section 4 of this document.
EVRC-Bコーデックでは、3つのRTPパケット形式がサポートされています。インターリーブ/バンドルパケット形式、ヘッダーフリーパケット形式、コンパクトバンドルパケット形式です。インターリーブ/バンドルされたヘッダーフリーパケット形式の場合、EVRC-BのTOC、インターリーブ、バンドリングなどの運用の詳細と機能は、RFC 3558 [4]で定義されているようにEVRCのものとまったく同じです。EVRC-B [3]のRate_Reducパラメーターの定義に従って、TOCのモード変更要求フィールドを解釈する必要があります。EVRC-Bのコンパクトバンドルされたパケット形式は、このドキュメントのセクション4で定義されています。
A packet in the compact bundled format consists of an RTP header, followed by a sequence of one or more consecutive EVRC/EVRC-B codec data frames of the same rate, as shown below:
コンパクトバンドル形式のパケットは、RTPヘッダーで構成され、その後、以下に示すように、同じレートの1つ以上の連続したEVRC/EVRC-Bコーデックデータフレームが続きます。
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 [4] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| One or more EVRC/EVRC-B data frames of same rate |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The codec data frames MUST be generated from the output of the codec following the procedure described in Section 5.2 in RFC 3558 [4], and all MUST be of the same rate and size.
コーデックデータフレームは、RFC 3558 [4]のセクション5.2で説明されている手順に従ってコーデックの出力から生成する必要があり、すべて同じレートとサイズでなければなりません。
As mentioned earlier, in order to use the compact bundled format, all the EVRC/EVRC-B data frames in the session MUST be of the same rate. This packet format may carry only full or half-rate frames.
前述のように、コンパクトバンドル形式を使用するには、セッション内のすべてのEVRC/EVRC-Bデータフレームは同じレートでなければなりません。このパケット形式は、フルレートフレームまたはハーフレートのフレームのみを搭載する場合があります。
For a session that uses the compact bundled format, the rate for the session can be determined during the session setup signaling, for example, via Session Description Protocol (SDP) exchanges. See Section 6 below for more details.
コンパクトバンドル形式を使用するセッションの場合、セッションのレートは、セッションセットアップシグナリング中に、たとえばセッション説明プロトコル（SDP）交換を介して決定できます。詳細については、以下のセクション6を参照してください。
The storage format is used for storing EVRC-B-encoded speech frames, e.g., as a file or e-mail attachment.
ストレージ形式は、ファイルまたは電子メールの添付ファイルとして、EVRC-Bエンコードされた音声フレームを保存するために使用されます。
The file begins with a magic number to identify the vocoder that is used. The magic number for EVRC-B corresponds to the ASCII character string:
ファイルは、使用されているボコーダーを識別するためのマジック番号から始まります。EVRC-Bのマジック番号は、ASCII文字列に対応しています。
"#!EVRC-B\n" (or 0x2321 0x4556 0x5243 0x2d42 0x0a in hexadecimal).
「＃！evrc-b \ n」（または0x2321 0x4556 0x5243 0x2d42 0x0a in hexadecimal）。
Note that the "\n" is an important part of both this magic number and the "#!EVRC\n" magic number defined in Section 11 of RFC 3558, and the "\n" MUST be included in any comparison of either magic number, since, otherwise, a prefix of the EVRC-B magic number could be mistaken for the EVRC magic number.
「\ n」は、このマジック番号とRFC 3558のセクション11で定義されている「＃！evrc \ n」の両方のマジック番号の両方の重要な部分であり、「\ n」はどちらの魔法の比較にも含める必要があることに注意してください。それ以外の場合は、EVRC-Bマジック番号のプレフィックスがEVRCマジック番号と間違っている可能性があるためです。
The codec data frames are stored in consecutive order, with a single ToC entry field, extended to one octet, prefixing each codec data frame. The ToC field, as defined in Section 5.1 of [4], is extended to one octet by setting the four most significant bits of the octet to zero. For example, a ToC value of 4 (a full-rate frame) is stored as 0x04.
コーデックデータフレームは、単一のTOCエントリフィールドが1つのOctetに拡張され、各コーデックデータフレームのプレフィックスを備えた連続した順序で保存されます。[4]のセクション5.1で定義されているTOCフィールドは、オクテットの4つの最も重要なビットをゼロに設定することにより、1オクテットに拡張されます。たとえば、4のTOC値（フルレートフレーム）は0x04として保存されます。
Speech frames lost in transmission and non-received frames MUST be stored as erasure frames to maintain synchronization with the original media.
トランスミッションで失われた音声フレームおよび非受信フレームは、元のメディアとの同期を維持するために、消去フレームとして保存する必要があります。
Type name: audio
タイプ名：オーディオ
Subtype names: EVRC1
サブタイプ名：EVRC1
Required parameters: none Optional parameters:
必要なパラメーター：なしオプションのパラメーター：
ptime: See RFC 4566 [7].
PTIME：RFC 4566 [7]を参照してください。
maxptime: The maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. The time MUST be calculated as the sum of the time the media present in the packet represents. The time SHOULD be a multiple of the duration of a single codec data frame (20 msec). If not signaled, the default maxptime value MUST be 200 milliseconds.
Maxptime：各パケットにカプセル化できるメディアの最大量、ミリ秒単位で時間として表されます。時間は、パケットに存在するメディアが表す時間の合計として計算する必要があります。時間は、単一のコーデックデータフレーム（20ミリ秒）の期間の倍数である必要があります。信号がない場合、デフォルトの最大値は200ミリ秒でなければなりません。
fixedrate: Indicates the EVRC rate of the session while in single-rate operation. Valid values include: 0.5 and 1, where a value of 0.5 indicates the 1/2 rate, while a value of 1 indicates the full rate. If this parameter is not present, 1/2 rate is assumed.
sixtrate：単一率の操作中にセッションのEVRCレートを示します。有効な値には、0.5と1が含まれます。ここで、0.5の値は1/2レートを示し、値は完全なレートを示します。このパラメーターが存在しない場合、1/2レートが想定されます。
silencesupp: Permissible values are 0 and 1. A value of 1 indicates that the sender of this parameter: a) is capable of receiving silence-suppressed speech using DTX, AND b) is capable of and will send out silence-suppressed speech using DTX, unless the other end indicates that it does not want to receive silence-suppressed speech using DTX.
Silencesupp：許容値は0および1です。1の値は、このパラメーターの送信者が次のことを示します。a）DTXを使用して沈黙抑制された音声を受信できること、b）はDTXを使用して沈黙抑制された音声を送信します。、もう一方の端がDTXを使用して沈黙に抑制されたスピーチを受けたくないことを示していない限り。
A value of 0 indicates that the sender of this parameter: a) does NOT want to receive silence-suppressed speech using DTX, AND b) will NOT send out silence-suppressed speech using DTX.
0の値は、このパラメーターの送信者が次のことを示します。a）DTXを使用して沈黙抑制されたスピーチを受信したくない、およびb）はDTXを使用して沈黙抑制されたスピーチを送信しません。
If this parameter is not present, the default value 1 MUST be assumed. If the RTP receiver indicates through the use of SIP signaling or other means that it is incapable of or unwilling to use silence suppression using DTX, silence suppression using DTX as specified in this document MUST NOT be used for the session.
このパラメーターが存在しない場合、デフォルト値1を想定する必要があります。RTPレシーバーがSIPシグナル伝達またはその他の手段を使用してDTXを使用して沈黙抑制を使用することができない、または使用したくないことを示す場合、このドキュメントで指定されたDTXを使用した沈黙抑制をセッションに使用してはなりません。
dtxmax: Permissible values are from 0 to 255. Indicates the maximum DTX update interval in number of frames. During DTX, the RTP sender occasionally updates the RTP receiver about the change in background noise characteristics, etc., by sending a new silence frame to the RTP receiver. The RTP receiver may use 'dtxmax' to indicate to the RTP sender the maximum interval (in number of frames) between any two DTX updates it expects to receive from the RTP sender.
DTXMAX：許容値は0〜255です。フレーム数の最大DTX更新間隔を示します。DTXの間、RTP送信者は、RTPレシーバーに新しい沈黙フレームを送信することにより、バックグラウンドノイズ特性などの変更についてRTPレシーバーを時々更新します。RTPレシーバーは、「DTXMAX」を使用して、RTP送信者から受信すると予想される2つのDTX更新の間の最大間隔（フレーム数）をRTP送信者に示すことができます。
If this parameter is not present in a session that uses DTX, the default value 32, as specified in [8], MUST be assumed. This parameter MUST be ignored if silence suppression using DTX is not used for the session.
このパラメーターがDTXを使用するセッションに存在しない場合、[8]で指定されているデフォルト値32を想定する必要があります。DTXを使用した沈黙抑制がセッションに使用されない場合、このパラメーターは無視する必要があります。
Note also that if the RTP receiver elects to detect DTX using dtxmax, the dtxmax parameter will affect the amount of delay the RTP receiver sees before detecting DTX in the stream.
また、RTPレシーバーがDTXMAXを使用してDTXを検出することを選択した場合、DTXMAXパラメーターは、ストリーム内のDTXを検出する前にRTPレシーバーが表示する遅延量に影響することに注意してください。
dtxmin: Permissible values are from 0 to 255. Indicates the minimum DTX update interval in number of frames. The RTP receiver may use 'dtxmin' to indicate to the RTP sender the minimal interval (in number of frames) between any two DTX updates it expects to receive from the RTP sender.
DTXMIN：許容値は0〜255です。フレーム数の最小DTX更新間隔を示します。RTPレシーバーは、「DTXMIN」を使用して、RTP送信者から受信すると予想される2つのDTXアップデート間の最小間隔（フレーム数）をRTP送信者に示すことができます。
If this parameter is not present, the default value 12, as specified in [8] MUST be assumed. This parameter MUST be ignored if silence suppression using DTX is not used for the session.
このパラメーターが存在しない場合、[8]で指定されているデフォルト値12を想定する必要があります。DTXを使用した沈黙抑制がセッションに使用されない場合、このパラメーターは無視する必要があります。
hangover: Permissible values are from 0 to 255. Indicates the number of consecutive silence frames transmitted at the end of an active speech interval but before the DTX interval begins. When setting up an RTP session that uses DTX, an RTP receiver can use this parameter to signal the number of silence frames it expects to receive before the beginning of DTX. While hangover=0 is allowed, it is RECOMMENDED that hangover be set to 1 or greater since the presence of silence frames at the end of an active speech can help the RTP receiver to identify the beginning of the DTX period.
二日酔い：許容値は0から255です。アクティブな音声間隔の終了時に送信される連続した沈黙フレームの数を示しますが、DTX間隔が始まる前です。DTXを使用するRTPセッションをセットアップすると、RTPレシーバーはこのパラメーターを使用して、DTXの開始前に受信すると予想される沈黙フレームの数を通知できます。二日酔い= 0は許可されていますが、アクティブなスピーチの終わりに沈黙フレームが存在すると、RTPレシーバーがDTX期間の開始を識別するのに役立つため、二日酔いを1以上に設定することをお勧めします。
If this parameter is not present for a session that uses DTX, the default value 1, as specified in [8] MUST be assumed. This parameter MUST be ignored if silence suppression using DTX is not used for the session.
このパラメーターがDTXを使用するセッションに存在しない場合、[8]で指定されているデフォルト値1を想定する必要があります。DTXを使用した沈黙抑制がセッションに使用されない場合、このパラメーターは無視する必要があります。
Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8) and is defined for transfer of EVRC-encoded data via RTP, using the compact bundled format as described in RFC 4788.
考慮事項のエンコード：このメディアタイプは、RFC 4788で説明されているようにコンパクトバンドル形式を使用して、RFC 4288、セクション4.8を参照）である（RFC 4288、セクション4.8を参照）、RTPを介したEVRCエンコードデータの転送用に定義されています。
Security considerations: See Section 9 of RFC 4788.
セキュリティ上の考慮事項：RFC 4788のセクション9を参照してください。
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: The EVRC vocoder is specified in 3GPP2 C.S0014 [2]. Transfer method with compact bundled RTP format is specified in RFC 4788.
公開された仕様：EVRCボコーダーは、3GPP2 C.S0014 [2]で指定されています。コンパクトバンドルされたRTP形式を使用した転送方法は、RFC 4788で指定されています。
Applications that use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type.
このメディアタイプを使用するアプリケーション：多くのVoIPアプリケーション（およびモバイルアプリケーション）がこのタイプを使用することが予想されます。
Additional information: none
追加情報：なし
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: This media type depends on RTP framing; hence, it is only defined for transfer via RTP (RFC 3550 [5]). Transfer within other framing protocols is not defined at this time.
使用に関する制限：このメディアタイプは、RTPフレーミングに依存します。したがって、RTP（RFC 3550 [5]）を介した転送に対してのみ定義されます。この時点では、他のフレーミングプロトコル内の転送は定義されていません。
Author: Qiaobing Xie
著者：Qiaobing Xie
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
Type name: audio
タイプ名：オーディオ
Subtype names: EVRCB
サブタイプ名：EVRCB
Required parameters: none
必要なパラメーター：なし
Optional parameters:
オプションのパラメーター：
ptime: see RFC 4566 [7].
PTIME：RFC 4566 [7]を参照してください。
maxptime: The maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. The time MUST be calculated as the sum of the time the media present in the packet represents. The time SHOULD be a multiple of the duration of a single codec data frame (20 msec). If not signaled, the default maxptime value MUST be 200 milliseconds.
Maxptime：各パケットにカプセル化できるメディアの最大量、ミリ秒単位で時間として表されます。時間は、パケットに存在するメディアが表す時間の合計として計算する必要があります。時間は、単一のコーデックデータフレーム（20ミリ秒）の期間の倍数である必要があります。信号がない場合、デフォルトの最大値は200ミリ秒でなければなりません。
maxinterleave: Maximum number for interleaving length (field LLL in the Interleaving Octet). The interleaving lengths used in the entire session MUST NOT exceed this maximum value. If not signaled, the maxinterleave length MUST be 5.
MaxInterLeave：インターリーブ長の最大数（インターリーブオクテットのフィールドLLL）。セッション全体で使用されるインターリーブ長は、この最大値を超えてはなりません。信号されていない場合、MaxInterLeaveの長さは5でなければなりません。
silencesupp: see Section 6.1 for definition. If this parameter is not present, the default value 1 MUST be assumed.
Silencesupp：定義については、セクション6.1を参照してください。このパラメーターが存在しない場合、デフォルト値1を想定する必要があります。
dtxmax: see Section 6.1
DTXMAX：セクション6.1を参照してください
dtxmin: see Section 6.1
DTXMIN：セクション6.1を参照してください
hangover: see Section 6.1
二日酔い：セクション6.1を参照してください
Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8) and is defined for transfer of EVRC-B-encoded data via RTP using the Interleaved/Bundled packet format specified in RFC 3558 [4].
考慮事項のエンコーディング：このメディアタイプは、バイナリデータのフレーム化されており（RFC 4288、セクション4.8を参照）、RFC 3558で指定されたインターリーブ/バンドルされたパケット形式を使用して、RTPを介してEVRC-BENCODEDデータの転送のために定義されています[4]。
Security considerations: See Section 9 of RFC 4788.
セキュリティ上の考慮事項：RFC 4788のセクション9を参照してください。
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: The EVRC-B vocoder is specified in 3GPP2 C.S0014-B [3]. Transfer method with Interleaved/Bundled packet format via RTP is specified in RFC 3558.
公開された仕様：EVRC-Bボコーダーは、3GPP2 C.S0014-B [3]で指定されています。RTPを介したインターリーブ/バンドルパケット形式を使用した転送方法は、RFC 3558で指定されています。
Applications that use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type.
このメディアタイプを使用するアプリケーション：多くのVoIPアプリケーション（およびモバイルアプリケーション）がこのタイプを使用することが予想されます。
Additional information: The following information applies for storage format only.
追加情報：次の情報は、ストレージ形式のみに適用されます。
Magic number: #!EVRC-B\n (see Section 5 of RFC 4788)
File extensions: evb, EVB
Macintosh file type code: None
Object identifier or OID: None
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: This media type may be used with RTP framing (RFC 3550 [5]) and as a storage format. When used with RTP, the procedures in Section 3 MUST be followed. In all other contexts, the storage format defined in Section 5 MUST be used.
使用に関する制限：このメディアタイプは、RTPフレーミング（RFC 3550 [5]）およびストレージ形式として使用できます。RTPで使用する場合は、セクション3の手順に従う必要があります。他のすべてのコンテキストでは、セクション5で定義されているストレージ形式を使用する必要があります。
Author: Qiaobing Xie
著者：Qiaobing Xie
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
Type name: audio
タイプ名：オーディオ
Subtype names: EVRCB0
サブタイプ名：EVRCB0
Required parameters: none
必要なパラメーター：なし
Optional parameters:
オプションのパラメーター：
silencesupp: see Section 6.1 for definition. If this parameter is not present, the default value 1 MUST be assumed.
Silencesupp：定義については、セクション6.1を参照してください。このパラメーターが存在しない場合、デフォルト値1を想定する必要があります。
dtxmax: see Section 6.1
DTXMAX：セクション6.1を参照してください
dtxmin: see Section 6.1
DTXMIN：セクション6.1を参照してください
hangover: see Section 6.1
二日酔い：セクション6.1を参照してください
Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8) and is defined for transfer of EVRC-B-encoded data via RTP using the Header-Free packet format specified in RFC 3558 [4].
考慮事項のエンコーディング：このメディアタイプは、バイナリデータのフレーム化されており（RFC 4288、セクション4.8を参照）、RFC 3558で指定されたヘッダーフリーパケット形式を使用してRTPを介してEVRC-BENCODEDデータを転送するために定義されています[4]。
Security considerations: See Section 9 of RFC 4788.
セキュリティ上の考慮事項：RFC 4788のセクション9を参照してください。
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: The EVRC-B vocoder is specified in 3GPP2 C.S0014-B [3]. Transfer method with Header-Free packet format via RTP is specified in RFC 3558 and RFC 4788.
公開された仕様：EVRC-Bボコーダーは、3GPP2 C.S0014-B [3]で指定されています。RTP経由のヘッダーフリーパケット形式を使用した転送方法は、RFC 3558およびRFC 4788で指定されています。
Applications that use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type.
このメディアタイプを使用するアプリケーション：多くのVoIPアプリケーション（およびモバイルアプリケーション）がこのタイプを使用することが予想されます。
Additional information: none
追加情報：なし
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: This media type depends on RTP framing; hence, it is only defined for transfer via RTP (RFC 3550 [5]). Transfer within other framing protocols is not defined at this time.
使用に関する制限：このメディアタイプは、RTPフレーミングに依存します。したがって、RTP（RFC 3550 [5]）を介した転送に対してのみ定義されます。この時点では、他のフレーミングプロトコル内の転送は定義されていません。
Author: Qiaobing Xie
著者：Qiaobing Xie
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
Type name: audio
タイプ名：オーディオ
Subtype names: EVRCB1
サブタイプ名：EVRCB1
Required parameters: none
必要なパラメーター：なし
Optional parameters:
オプションのパラメーター：
ptime: see RFC 4566 [7].
PTIME：RFC 4566 [7]を参照してください。
maxptime: The maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. The time MUST be calculated as the sum of the time the media present in the packet represents. The time SHOULD be a multiple of the duration of a single codec data frame (20 msec). If not signaled, the default maxptime value MUST be 200 milliseconds.
Maxptime：各パケットにカプセル化できるメディアの最大量、ミリ秒単位で時間として表されます。時間は、パケットに存在するメディアが表す時間の合計として計算する必要があります。時間は、単一のコーデックデータフレーム（20ミリ秒）の期間の倍数である必要があります。信号がない場合、デフォルトの最大値は200ミリ秒でなければなりません。
fixedrate: Indicates the EVRC-B rate of the session while in single-rate operation. Valid values include: 0.5 and 1, where a value of 0.5 indicates the 1/2 rate while a value of 1 indicates the full rate. If this parameter is not present, 1/2 rate is assumed.
sixtrate：単一率の操作中にセッションのEVRC-Bレートを示します。有効な値には：0.5および1が含まれます。ここで、0.5の値は1/2レートを示し、値は完全なレートを示します。このパラメーターが存在しない場合、1/2レートが想定されます。
silencesupp: see Section 6.1 for definition. If this parameter is not present, the default value 1 MUST be assumed.
Silencesupp：定義については、セクション6.1を参照してください。このパラメーターが存在しない場合、デフォルト値1を想定する必要があります。
dtxmax: see Section 6.1
DTXMAX：セクション6.1を参照してください
dtxmin: see Section 6.1 hangover: see Section 6.1
DTXMIN：セクション6.1二日酔いを参照：セクション6.1を参照してください
Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8) and is defined for transfer of EVRC-B-encoded data via RTP using the compact bundled format as described in RFC 4788.
考慮事項のエンコーディング：このメディアタイプは、バイナリデータのフレーム化されており（RFC 4288、セクション4.8を参照）、RFC 4788で説明されているコンパクトバンドル形式を使用してRTPを介してEVRC-BENCODEDデータを転送するために定義されています。
Security considerations: See Section 9 of RFC 4788.
セキュリティ上の考慮事項：RFC 4788のセクション9を参照してください。
Interoperability considerations: none.
相互運用性の考慮事項：なし。
Published specification: The EVRC-B vocoder is specified in 3GPP2 C.S0014-B [3]. Transfer method with compact bundled RTP format is specified in RFC 4788.
公開された仕様：EVRC-Bボコーダーは、3GPP2 C.S0014-B [3]で指定されています。コンパクトバンドルされたRTP形式を使用した転送方法は、RFC 4788で指定されています。
Applications that use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type.
このメディアタイプを使用するアプリケーション：多くのVoIPアプリケーション（およびモバイルアプリケーション）がこのタイプを使用することが予想されます。
Additional information: none
追加情報：なし
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: This media type depends on RTP framing; hence, it is only defined for transfer via RTP (RFC 3550 [5]). Transfer within other framing protocols is not defined at this time.
使用に関する制限：このメディアタイプは、RTPフレーミングに依存します。したがって、RTP（RFC 3550 [5]）を介した転送に対してのみ定義されます。この時点では、他のフレーミングプロトコル内の転送は定義されていません。
Author: Qiaobing Xie
著者：Qiaobing Xie
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
(The definition is from RFC 3558, added with the optional DTX parameters, and updated with the new template specified in [10].)
（定義はRFC 3558からのもので、オプションのDTXパラメーターで追加され、[10]で指定された新しいテンプレートで更新されます。）
Type name: audio
タイプ名：オーディオ
Subtype names: EVRC Required parameters: none
サブタイプ名：EVRC必須パラメーター：なし
Optional parameters:
オプションのパラメーター：
ptime: Defined as usual for RTP audio (see RFC 4566).
PTIME：RTPオーディオでは通常どおり定義されています（RFC 4566を参照）。
maxptime: The maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the packet represents. The time SHOULD be a multiple of the duration of a single codec data frame (20 msec). If not signaled, the default maxptime value SHALL be 200 milliseconds.
Maxptime：各パケットにカプセル化できるメディアの最大量、ミリ秒単位で時間として表されます。時間は、パケットに存在するメディアが表す時間の合計として計算されます。時間は、単一のコーデックデータフレーム（20ミリ秒）の期間の倍数である必要があります。信号がない場合、デフォルトの最大値値は200ミリ秒でなければなりません。
maxinterleave: Maximum number for interleaving length (field LLL in the Interleaving Octet). The interleaving lengths used in the entire session MUST NOT exceed this maximum value. If not signaled, the maxinterleave length SHALL be 5.
MaxInterLeave：インターリーブ長の最大数（インターリーブオクテットのフィールドLLL）。セッション全体で使用されるインターリーブ長は、この最大値を超えてはなりません。信号されていない場合、maxinterleaveの長さは5になります。
silencesupp: see Section 6.1 for definition. If this parameter is not present, the default value 1 MUST be assumed.
Silencesupp：定義については、セクション6.1を参照してください。このパラメーターが存在しない場合、デフォルト値1を想定する必要があります。
dtxmax: see Section 6.1
DTXMAX：セクション6.1を参照してください
dtxmin: see Section 6.1
DTXMIN：セクション6.1を参照してください
hangover: see Section 6.1
二日酔い：セクション6.1を参照してください
Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8), and is defined for transfer of EVRC-encoded data via RTP using the Interleaved/Bundled packet format specified in Sections 4.1, 6, and 7 of RFC 3558. It is also defined for other transfer methods using the storage format specified in Section 11 of RFC 3558.
考慮事項のエンコード：このメディアタイプは、バイナリデータの枠組み（RFC 4288、セクション4.8を参照）であり、RFC 3558のセクション4.1、6、および7で指定されたインターリーブ/バンドルされたパケット形式を使用して、RTPを介してEVRCエンコードデータの転送について定義されています。。RFC3558のセクション11で指定されたストレージ形式を使用して、他の転送方法でも定義されています。
Security considerations: See Section 14, "Security Considerations", of RFC 3558.
セキュリティ上の考慮事項：RFC 3558のセクション14「セキュリティ上の考慮事項」を参照してください。
Interoperability considerations: The DTX parameters are receiver options. Existing RFC 3558 implementations will not send any of the DTX parameters in their SDP and will ignore any DTX parameters they receive. The adaptive DTX behavior of DTX-capable EVRC codecs (as detailed in [8], Section 4.3.5) ensures interoperability with non-DTX EVRC codecs.
相互運用性の考慮事項：DTXパラメーターはレシーバーオプションです。既存のRFC 3558実装は、SDPにDTXパラメーターを送信せず、受信したDTXパラメーターを無視します。DTX対応のEVRCコーデックの適応DTX動作（[8]、セクション4.3.5で詳細）により、非DTX EVRCコーデックとの相互運用性が保証されます。
Published specification: The EVRC vocoder is specified in 3GPP2 C.S0014 [2]. Transfer methods are specified in RFC 3558.
公開された仕様：EVRCボコーダーは、3GPP2 C.S0014 [2]で指定されています。転送方法は、RFC 3558で指定されています。
Applications that use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type.
このメディアタイプを使用するアプリケーション：多くのVoIPアプリケーション（およびモバイルアプリケーション）がこのタイプを使用することが予想されます。
Additional information: The following information applies for storage format only.
追加情報：次の情報は、ストレージ形式のみに適用されます。
Magic number: #!EVRC\n (see Section 11 of RFC 3558)
File extensions: evc, EVC
Macintosh file type code: none
Object identifier or OID: none
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: This media type may be used with RTP framing (RFC 3550 [5]) and as a storage format. When used with RTP, the procedures in RFC 3558, Section 4.1, MUST be followed. In all other contexts, the storage format defined in RFC 3558, Section 11, MUST be used.
使用に関する制限：このメディアタイプは、RTPフレーミング（RFC 3550 [5]）およびストレージ形式として使用できます。RTPで使用する場合は、RFC 3558、セクション4.1の手順に従う必要があります。他のすべてのコンテキストでは、RFC 3558、セクション11で定義されているストレージ形式を使用する必要があります。
Author: Adam Li/Qiaobing Xie
著者：Adam Li/Qiaobing Xie
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
(The definition is from RFC 3558, added with the optional DTX parameters, and updated with the new template specified in [10].)
（定義はRFC 3558からのもので、オプションのDTXパラメーターで追加され、[10]で指定された新しいテンプレートで更新されます。）
Type name: audio
タイプ名：オーディオ
Subtype names: EVRC0
サブタイプ名：EVRC0
Required parameters: none
必要なパラメーター：なし
Optional parameters:
オプションのパラメーター：
silencesupp: see Section 6.1 for definition. If this parameter is not present, the default value 1 MUST be assumed.
Silencesupp：定義については、セクション6.1を参照してください。このパラメーターが存在しない場合、デフォルト値1を想定する必要があります。
dtxmax: see Section 6.1
DTXMAX：セクション6.1を参照してください
dtxmin: see Section 6.1
DTXMIN：セクション6.1を参照してください
hangover: see Section 6.1
二日酔い：セクション6.1を参照してください
Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8) and is only defined for transfer of EVRC-encoded data via RTP using the Header-Free packet format specified in Section 4.2 of RFC 3558.
考慮事項のエンコーディング：このメディアタイプは、バイナリデータのフレーム化されており（RFC 4288、セクション4.8を参照）、RFC 3558のセクション4.2で指定されたヘッダーフリーパケット形式を使用して、RTPを介してEVRCエンコードデータの転送に対してのみ定義されます。
Security considerations: See Section 14, "Security Considerations", of RFC 3558.
セキュリティ上の考慮事項：RFC 3558のセクション14「セキュリティ上の考慮事項」を参照してください。
Interoperability considerations: The DTX parameters are receiver options. Existing RFC 3558 implementations will not send any of the DTX parameters in their SDP and will ignore any DTX parameters they receive. The adaptive DTX behavior of DTX-capable EVRC codecs (as detailed in [8], Section 4.3.5) ensures interoperability with non-DTX EVRC codecs.
相互運用性の考慮事項：DTXパラメーターはレシーバーオプションです。既存のRFC 3558実装は、SDPにDTXパラメーターを送信せず、受信したDTXパラメーターを無視します。DTX対応のEVRCコーデックの適応DTX動作（[8]、セクション4.3.5で詳細）により、非DTX EVRCコーデックとの相互運用性が保証されます。
Published specification: The EVRC vocoder is specified in 3GPP2 C.S0014 [2]. Transfer methods are specified in RFC 3558.
公開された仕様：EVRCボコーダーは、3GPP2 C.S0014 [2]で指定されています。転送方法は、RFC 3558で指定されています。
Applications that use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type.
このメディアタイプを使用するアプリケーション：多くのVoIPアプリケーション（およびモバイルアプリケーション）がこのタイプを使用することが予想されます。
Additional information: none
追加情報：なし
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: This media type depends on RTP framing; hence, it is only defined for transfer via RTP (RFC 3550 [5]). Transfer within other framing protocols is not defined at this time.
使用に関する制限：このメディアタイプは、RTPフレーミングに依存します。したがって、RTP（RFC 3550 [5]）を介した転送に対してのみ定義されます。この時点では、他のフレーミングプロトコル内の転送は定義されていません。
Author: Adam Li/Qiaobing Xie
著者：Adam Li/Qiaobing Xie
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [7], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the compact bundled format for EVRC/EVRC-B-encoded speech, the mapping is as follows:
MIMEメディアタイプの仕様にある情報には、セッション説明プロトコル（SDP）[7]のフィールドへの特定のマッピングがあり、これはRTPセッションを説明するために一般的に使用されます。SDPを使用して、EVRC/EVRC-Bエンコードされたスピーチにコンパクトバンドル形式を使用するセッションを指定する場合、マッピングは次のとおりです。
o The MIME type ("audio") goes in SDP "m=" as the media name.
o MIMEタイプ（ "Audio"）は、メディア名としてSDP "m ="になります。
o The MIME subtype ("EVRC", "EVRC0", "EVRC1", "EVRCB", EVRCB0", or "EVRCB1") goes in SDP "a=rtpmap" as the encoding name.
o mimeサブタイプ（ "evrc"、 "evrc0"、 "evrc1"、 "evrcb"、evrcb0 "、または" evrcb1 "）は、エンコード名としてsdp" a = rtpmap "になります。
o The optional parameters "ptime" and "maxptime" (for subtypes EVRC, EVRC1, EVRCB, and EVRCB1) go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o オプションのパラメーター「PTIME」および「MAXPTIME」（サブタイプEVRC、EVRC1、EVRCB、およびEVRCB1の場合）は、それぞれSDP「A = PTIME」および「A = MaxPtime」属性になります。
o The optional parameter "maxinterleave" (for subtypes EVRC and EVRCB) goes in the SDP "a=fmtp" attribute by copying it directly from the MIME media type string as "maxinterleave=value".
o オプションのパラメーター「MaxInterLeave」（サブタイプEVRCおよびEVRCBの場合）は、MIMEメディアタイプの文字列から「MaxInterLeave = value」として直接コピーすることにより、SDP "a = fmtp"属性になります。
o The optional parameter "fixedrate" (for subtypes EVRC1 and EVRCB1) goes in the "a=fmtp" attribute by copying it directly from the MIME media type string as "fixedrate=value".
o オプションのパラメーター「sixtrate」（サブタイプEVRC1およびEVRCB1の場合）は、MIMEメディアタイプの文字列から「fixedrate = value」として直接コピーすることにより、「a = fmtp」属性になります。
o The optional parameters "silencesupp", "dtxmax", "dtxmin", and "hangover" go in the "a=fmtp" attribute by copying it directly from the MIME media type string as "silencesupp=value", "dtxmax=value", "dtxmin=value", and "hangover=value", respectively.
o オプションのパラメーター「SilencesUpp」、「dtxmax」、「dtxmin」、および「二日酔い」は、「silencesupp = value」、「dtxmax = value」としてmimeメディアタイプの文字列から直接コピーすることにより、「a = fmtp」属性になります。、「dtxmin = value」、および「二日酔い=値」。
Example of usage of EVRC1:
EVRC1の使用例：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRC1/8000
a=fmtp:97 fixedrate=0.5
a=maxptime:120
Example of usage of EVRCB:
EVRCBの使用例：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB/8000
a=maxptime:120
Example of usage of EVRCB0:
EVRCB0の使用例：
m=audio 49120 RTP/AVP 97 a=rtpmap:97 EVRCB0/8000
M =オーディオ49120 RTP/AVP 97 A = RTPMAP：97 EVRCB0/8000
Example of usage of EVRCB1:
EVRCB1の使用例：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB1/8000
a=fmtp:97 fixedrate=0.5
a=maxptime:100
Example of usage of EVRC with DTX with silencesupp=1:
Silencesupp = 1を使用したDTXを使用したEVRCの使用例：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRC/8000
a=fmtp:97 silencesupp=1 dtxmax=32 dtxmin=12 hangover=1
Example of usage of EVRC with DTX with silencesupp=0:
Silencesupp = 0でDTXを使用したEVRCの使用例：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRC/8000
a=fmtp:97 silencesupp=0
All SDP parameters in this payload format are declarative, and all reasonable values are expected to be supported. In particular, when DTX is supported, the RTP sender implementation SHOULD support hangover, dtxmin, and dtxmax values from 0 to 255. Thus, the standard usage of Offer/Answer, as described in RFC 3264 [6], SHOULD be followed.
このペイロード形式のすべてのSDPパラメーターは宣言的であり、すべての合理的な値がサポートされると予想されます。特に、DTXがサポートされている場合、RTP送信者の実装は、RFC 3264 [6]で説明されているように、二日酔い、DTXMIN、およびDTXMAX値を0から255までサポートする必要があります。
In addition, the following rules MUST be followed while negotiating DTX parameters:
さらに、DTXパラメーターの交渉中に次のルールに従う必要があります。
1. If any DTX parameter is not present in either offer and/or answer, the default value of the DTX parameter MUST be assumed.
1. どちらのオファーおよび/または回答にDTXパラメーターが存在しない場合、DTXパラメーターのデフォルト値を想定する必要があります。
2. If silencesupp is present and set to 0 in either offer or answer, the values of all received DTX parameters other than silencesupp SHOULD be ignored.
2. Silencesuppが存在し、オファーまたは回答のいずれかで0に設定されている場合、Silencesupp以外のすべての受信したDTXパラメーターの値は無視する必要があります。
3. In an offer or answer, the value of dtxmax SHOULD always be larger than or equal to the value of dtxmin, regardless of whether the values are indicated explicitly or implicitly by default. Moreover, if the indicated value of dtxmin is larger than that of dtxmax, an RTP sender MUST ignore the indicated values and MUST fall back on using the default dtxmin and dtxmax values.
3. 申し出または回答では、dtxmaxの値は、デフォルトで値が明示的または暗黙的に示されているかどうかにかかわらず、常にdtxminの値以上である必要があります。さらに、DTXMINの指定された値がDTXMAXの値よりも大きい場合、RTP送信者は示された値を無視し、デフォルトのDTXMINおよびDTXMAX値を使用して戻る必要があります。
This document adds new optional DTX parameters to the original EVRC payload subtypes "EVRC" and "EVRC0" defined in RFC 3558. Since the new DTX parameters are receiver options, we expect that the existing RFC 3558 implementations will not send any of the DTX parameters in their SDP and will ignore any DTX parameters they receive. The adaptive DTX behavior of DTX-capable EVRC codecs (as detailed in [8], Section 4.3.5) ensures the backward interoperability between the DTX-capable EVRC codec and non-DTX EVRC codecs.
このドキュメントは、RFC 3558で定義された元のEVRCペイロードサブタイプ「EVRC」および「EVRC0」に新しいオプションのDTXパラメーターを追加します。新しいDTXパラメーターはレシーバーオプションであるため、既存のRFC 3558実装はDTXパラメータのいずれも送信しないと予想しています。SDPでは、受信したDTXパラメーターを無視します。DTX対応のEVRCコーデックの適応DTX動作（[8]、セクション4.3.5で詳述されているように）は、DTX対応EVRCコーデックと非DTX EVRCコーデックの間の後方相互運用性を保証します。
Four (4) new MIME subtype registrations - "EVRC1", "EVRCB", "EVRCB0", and "EVRCB1" - are defined in this document (see Section 6.1 - Section 6.4) for EVRC-B and compact bundled payload format support.
4つの新しいMIMEサブタイプ登録 - 「EVRC1」、「EVRCB」、「EVRCB0」、および「EVRCB1」 - は、このドキュメントで定義されています（EVRC -Bおよびコンパクトバンドルされたペイロード形式のサポートについては、セクション6.1-セクション6.4を参照）。
For all the EVRC and EVRC-B RTP payload formats defined in RFC 3558 [4] and RFC 4788, four additional optional parameters - "silencesupp", "dtxmax", "dtxmin", and "hangover" - are defined and used in DTX.
RFC 3558 [4]およびRFC 4788で定義されたすべてのEVRCおよびEVRC -B RTPペイロードフォーマットについて、4つの追加のオプションパラメーター - 「サイレンスサップ」、「DTXMAX」、「DTXMIN」、および「ハンゴーバー」がDTXで定義され、DTXで使用されます。。
The MIME subtype registrations "EVRC" and "EVRC0", originally defined in RFC 3558 [4], are updated with the optional DTX parameters (see Sections 6.5 and 6.6).
元々RFC 3558 [4]で定義されていたMIMEサブタイプ登録「EVRC」と「EVRC0」は、オプションのDTXパラメーターで更新されます（セクション6.5および6.6を参照）。
Implementations using the payload defined in this specification are subject to the security considerations discussed in RFC 3558 [4], RFC 3550 [5], and any appropriate profile (for example, RFC 3551 [9]). This payload does not specify any different security services.
この仕様で定義されたペイロードを使用した実装は、RFC 3558 [4]、RFC 3550 [5]、および適切なプロファイル（たとえば、RFC 3551 [9]）で説明されているセキュリティ上の考慮事項の対象となります。このペイロードは、別のセキュリティサービスを指定しません。
The following people have made significant contributions to this document (in alphabetical order): Parag Agashe, Jim Ashley, Harikishan Desineni, Serafin Diaz, Harinath Garudadri, Gouri Johanssen, Ananth Kandhadai, Waqar Mohsin, Ashok Roy, Gino Scribano, and Gajinder Singh Vij.
次の人々は、この文書に多大な貢献をしています（アルファベット順の順序で）：Parag Agashe、Jim Ashley、Harikishan Desineni、Serafin Diaz、Harinath Garudadri、Gouri Johanssen、Ananth Kandhadai、Waqar Mohsin、Ashok Roy、Gino Scribano、Gajinder Singh viijinder。
Special thanks to Colin Perkins, Magnus Westerlund, and Adam Li for their careful review and comments that significantly improved the quality of this document.
Colin Perkins、Magnus Westerlund、およびAdam Liに、このドキュメントの品質を大幅に改善した慎重なレビューとコメントに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] "Enhanced Variable Rate Codec, Speech Service Option 3 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014, January 1997.
[2] 「強化された可変レートコーデック、広帯域スプレッドスペクトルデジタルシステム用の音声サービスオプション3」、3GPP2 C.S0014、1997年1月。
[3] "Enhanced Variable Rate Codec, Speech Service Option 3 and 68 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B v1.0, May 2006.
[3] 「強化された可変レートコーデック、広帯域スプレッドスペクトルデジタルシステム用の音声サービスオプション3および68」、3GPP2 C.S0014-B V1.0、2006年5月。
[4] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003.
[4] Li、A。、「強化された可変レートコーデック（EVRC）および選択可能なモードボコーダー（SMV）のRTPペイロード形式」、RFC 3558、2003年7月。
[5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[5] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 3550、2003年7月。
[6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002.
[6] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[7] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[8] "Discontinuous Transmission (DTX) of Speech in cdma2000 Systems", 3GPP2 C.S0076-0, Version 1.0, December 2005.
[8] 2005年12月、3GPP2 C.S0076-0、バージョン1.0、CDMA2000システムにおける音声の不連続感染（DTX）」。
[9] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
[9] Schulzrinne、H。およびS. Casner、「最小限の制御を伴うオーディオおよびビデオ会議のRTPプロファイル」、RFC 3551、2003年7月。
[10] Casner, S., "Media Type Registration of RTP Payload Formats", Work in Progress, March 2006.
[10] Casner、S。、「RTPペイロードフォーマットのメディアタイプ登録」、2006年3月、進行中の作業。
Authors' Addresses
著者のアドレス
Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-F9 Arlington Heights, IL 60004 US
Qiaobing Xie Motorola、Inc。1501 W. Shure Drive、2-F9 Arlington Heights、IL 60004 US
Phone: +1-847-632-3028
EMail: Qiaobing.Xie@Motorola.com
Rohit Kapoor Qualcomm Inc. US
Rohit Kapoor Qualcomm Inc. US
Phone: +1-858-845-1161
EMail: rkapoor@qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースは免責明示的または暗示されたすべての保証。ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。