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
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document 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のためのEVRC-Bコーデック、EVRCのための新しいコンパクトバンドル形式及びEVRC-Bコーデックのヘッダを含まないインターリーブ/バンドルパケットフォーマット、ならびに不連続送信（DTX）をサポートするためのサポートを定義しRTPを介して輸送EVRC-B-符号化された音声。低帯域幅ダイヤルアップおよび無線ネットワーク上で動作してボイスオーバー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コーデック、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] [2]第三世代パートナーシッププロジェクト2（3GPP2）において開発EVRCの拡張です。 EVRC-B [3] 4種類のサイズの一つの出力フレームに8000Hzの各20ミリ秒、16ビットサンプリングされた音声入力を圧縮：速度1（171ビット）、レート1/2（80ビット）、レート1/4 （40ビット）、またはレート1/8（16ビット）。ヌルフレームと消去フレーム、EVRCに類似[2]：また、2つのゼロビットコーデックフレームタイプがあります。 EVRC-Bにおける一つの著しい向上は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パケットに異なるレートの複数の音声フレームのバンドリングを可能にします。これらの機能をサポートするために、目次（TOC）は、標準のRTPヘッダに加えて、各RTPパケットに使用されます。目次のサイズは、パケット[4]で運ばEVRCフレームの数に依存して変化します。
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パケットは、すなわち、バンドリングが許可されていない、（任意の許容レートの）唯一の音声フレームを含むことを要求することによって目次の必要性を排除します。また、インターリーブモード変更要求はヘッダを含まない形式でサポートされていない[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]。この文書は、「silencesuppは」DTX /無音抑圧を使用する能力および意思を示すためであるDTX /無音抑圧セッションをセットアップするための追加のオプションのMIMEパラメータ（silencesupp、dtxmax、dtxmin、および二日酔い）を定義します。 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.
シングルレート動作モード（セクション4を参照）で、沈黙を同一のフレームで符号化し、送信している間、可変速度動作モードでEVRCおよびEVRC-Bコーデックは、サイレンスの期間中に1月8日レートフレームを送信します音声フレームのものと割合。この文書で定義された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.
簡単にするために、本文書の残りの部分において、用語「無音フレームは、」可変レート動作で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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
インターリーブ/バンドルパケットフォーマット、ヘッダを含まないパケットフォーマット、およびコンパクトバンドルパケット形式：三枚のRTPパケットフォーマットはEVRC-Bコーデックでサポートされています。 RFC 3558で定義されるようにインターリーブ/バンドルとヘッダフリーパケットフォーマットのために、このようなEVRC-Bの目次、インターリーブ、及び結束のよう動作の詳細および機能は、[4]、正確EVRCのものと同じです、目次にモード変更要求フィールドはEVRC-BにおけるRATE_REDUCパラメータの定義に従って解釈されなければならないことを除いて、[3]。 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:
コンパクトバンドル形式のパケットは、以下に示すように、同じレートの一つ以上の連続したEVRC / EVRC-Bコーデックデータフレームのシーケンスに続いて、RTPヘッダで構成されています。
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.
コーデックデータフレームが[4] RFC 3558セクション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).
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が」このマジックナンバーとの両方の重要な一部であることに注意してください「＃！EVRC \ n」は魔法RFC 3558のセクション11で定義された数、および「\ 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つのオクテットに拡張されます。目次フィールドは、[4]のセクション5.1で定義されるように、ゼロにオクテットの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ミリ秒）の持続時間の倍数でなければなりません。合図されていない場合、デフォルトのmaxptime値は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.
fixedrate：シングルレート動作中のセッションのEVRC率を示します。有効な値は：0.5と1を、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：1の値が示す許容値は、0と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.
A）DTXを使用して沈黙抑制スピーチを受信したくないし、b）はDTXを使用して沈黙抑制スピーチを送信しません：0の値は、このパラメータの送信者がいることを示しています。
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受信機は、RTP送信機には、RTP送信機から受信することを期待する任意の二つのDTX更新の間（フレーム数で）最大間隔を示すために「dtxmax」を使用することができます。
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.
このパラメータは、[8]で指定されるようにDTX、デフォルト値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パラメータは、RTP受信機がストリームにDTXを検出する前に見ている遅延量に影響を与えること。
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受信機は、RTP送信機には、RTP送信機から受信することを期待する任意の二つのDTX更新の間（フレーム数で）最小限の間隔を示すために「dtxmin」を使用することができます。
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が許可されている間、その二日酔いがDTX期間の開始を識別するために、RTP受信機を助けることができるアクティブな音声の終わりに無音のフレームが存在するので、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.
このパラメータは、[8]と仮定しなければならないで指定されるようにDTX、デフォルト値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 4288、セクション4.8を参照）、RFC 4788に記載されているように、コンパクトバンドル形式を使用して、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>
人とEメールアドレスは、詳細のために連絡する：Qiaobing謝<Qiaobing.Xie@motorola.com>
Intended usage: COMMON
意図している用法：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
著者：Q私は、IEオリンピック氷をX
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
変更コントローラ：IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ。
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ミリ秒）の持続時間の倍数でなければなりません。合図されていない場合、デフォルトのmaxptime値は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-B-符号化データの転送のために定義されている[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
マジック番号：＃！EVRC-Bの\ nを（RFC 4788のセクション5を参照）ファイル拡張子：EVB、EVB Macintoshファイルタイプコード：なしオブジェクト識別子またはOID：なし
Person & email address to contact for further information: Qiaobing Xie <Qiaobing.Xie@motorola.com>
人とEメールアドレスは、詳細のために連絡する：Qiaobing謝<Qiaobing.Xie@motorola.com>
Intended usage: COMMON
意図している用法：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
著者：Q私は、IEオリンピック氷をX
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
変更コントローラ：IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ。
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-B-符号化データの転送のために定義されている[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>
人とEメールアドレスは、詳細のために連絡する：Qiaobing謝<Qiaobing.Xie@motorola.com>
Intended usage: COMMON
意図している用法：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
著者：Q私は、IEオリンピック氷をX
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
変更コントローラ：IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ。
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ミリ秒）の持続時間の倍数でなければなりません。合図されていない場合、デフォルトのmaxptime値は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.
fixedrate：シングルレート動作中のセッションのEVRC-B率を示します。有効な値は、1の値は、フル・レートを示しながら、0.5の値が1/2レートを示す0.5と1、。このパラメータが存在しない場合は、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
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 compact bundled format as described in RFC 4788.
符号の考慮：このメディアタイプはバイナリデータをフレーム化された（RFC 4288、セクション4.8を参照）、RFC 4788に記載されているように、コンパクトバンドル形式を使用してRTPを介しEVRC-B-符号化データの転送のために定義されています。
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>
人とEメールアドレスは、詳細のために連絡する：Qiaobing謝<Qiaobing.Xie@motorola.com>
Intended usage: COMMON
意図している用法：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
著者：Q私は、IEオリンピック氷をX
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
変更コントローラ：IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ。
(The definition is from RFC 3558, added with the optional DTX parameters, and updated with the new template specified in [10].)
（定義は、オプションのDTXパラメータを添加し、そして[10]で指定された新しいテンプレートを使用して更新、RFC 3558からのものです。）
Type name: audio
型名：オーディオ
Subtype names: EVRC
サブタイプ名：EVRC
Required parameters: none
必須パラメータ：なし
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ミリ秒）の持続時間の倍数でなければなりません。合図されていない場合、デフォルトのmaxptime値は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を参照）バイナリデータをフレーム化し、セクション4.1で指定されたインターリーブ/バンドルパケットフォーマットを使用して、RTPを介しEVRC符号化データの転送用に定義されている、6、およびRFC 3558の7 。また、RFC 3558のセクション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パラメータを無視します。 （[8]、セクション4.3.5に詳述されるように）DTX-可能EVRCコーデックの適応DTXの動作は、非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>
人とEメールアドレスは、詳細のために連絡する：Qiaobing謝<Qiaobing.Xie@motorola.com>
Intended usage: COMMON
意図している用法：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
著者：アダムのL I / Q iは、IEオリンピック氷をX
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
変更コントローラ：IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ。
(The definition is from RFC 3558, added with the optional DTX parameters, and updated with the new template specified in [10].)
（定義は、オプションのDTXパラメータを添加し、そして[10]で指定された新しいテンプレートを使用して更新、RFC 3558からのものです。）
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パラメータを無視します。 （[8]、セクション4.3.5に詳述されるように）DTX-可能EVRCコーデックの適応DTXの動作は、非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>
人とEメールアドレスは、詳細のために連絡する：Qiaobing謝<Qiaobing.Xie@motorola.com>
Intended usage: COMMON
意図している用法：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
著者：アダムのL I / Q iは、IEオリンピック氷をX
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) [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メディアタイプの仕様で搬送される情報は、[7]、一般にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）内のフィールドに特定のマッピングを有します。 SDPは、EVRC / EVRC-B-符号化された音声のためのコンパクトバンドル形式を採用セッションを指定するために使用される場合、以下のように、マッピングは次のとおりです。
o The MIME type ("audio") goes in SDP "m=" as the media name.
O MIMEタイプ（「オーディオ」）は、メディア名としてSDP「m =」に進みます。
o The MIME subtype ("EVRC", "EVRC0", "EVRC1", "EVRCB", EVRCB0", or "EVRCB1") goes in SDP "a=rtpmap" as the encoding name.
MIMEサブタイプ（ "EVRC"、 "EVRC0"、 "EVRC1"、 "EVRCB"、EVRCB0" 、または "EVRCB1"）はSDPに入り "O = 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.
（サブタイプEVRC、EVRC1、EVRCB、及びEVRCB1ための）オプションパラメータ "PTIME" および "maxptimeは" SDPの "a = PTIME" および "A = maxptime" に行くOそれぞれ、属性。
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（サブタイプEVRCとEVRCBための）オプションのパラメータ「maxinterleaveは」SDP「maxinterleave =値」とMIMEメディアタイプ文字列から直接コピーして「=の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（サブタイプEVRC1とEVRCB1ための）オプションのパラメータ「fixedrate」は「fixedrate =値」としてMIMEメディアタイプ文字列から直接コピーすることによって、「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.
オプションのパラメータ「silencesupp」、「dtxmax」、「dtxmin」O、および「二日酔い」「silencesupp =値」としてMIMEメディアタイプ文字列から直接コピーすることによって、「A =のfmtp」属性に行き、「dtxmax =値それぞれ」、 "dtxmin =値"、および "二日酔い=値"。
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
M =オーディオ49120 RTP / AVP 97 = rtpmap：97 fixedrate = 0.5 = maxptime：120 EVRC1 / 8000 = 97のfmtp
Example of usage of EVRCB:
EVRCBの使用例：
m=audio 49120 RTP/AVP 97 a=rtpmap:97 EVRCB/8000 a=maxptime:120
M =オーディオ49120 RTP / AVP 97 = rtpmap：97 EVRCB / 8000 = maxptime：120
Example of usage of EVRCB0:
EVRCB0の使用例：
m=audio 49120 RTP/AVP 97 a=rtpmap:97 EVRCB0/8000
M =オーディオ49120 RTP / AVP 97 = 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
M =オーディオ49120 RTP / AVP 97 = rtpmap：97 fixedrate = 0.5 = maxptime：100 EVRCB1 / 8000 = 97のfmtp
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
M =オーディオ49120 RTP / AVP 97 = rtpmap：97 EVRC / 8000 =のfmtp：97 silencesupp = 1 dtxmax = 32 dtxmin = 12二日酔い= 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
M =オーディオ49120 RTP / AVP 97 = rtpmap：97 EVRC / 8000 =の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がサポートされている場合、RFC 3264に記載されているように、特に、RTP送信機の実装は、[6]、その後すべきで、このように0〜255のオファー/アンサーの標準的な使用を二日酔い、dtxmin、及びdtxmax値をサポートする必要があります。
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.
silencesuppが存在するとの申し出または回答のいずれかに0に設定されている場合は2、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.
このドキュメントは、元のEVRCペイロードサブタイプに「EVRCを」新しいオプションのDTXパラメータを追加し、新しいDTXパラメータは受信機のオプションであるため、RFC 3558.で定義された「EVRC0」は、既存の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は」 - EVRCBとコンパクトなバンドルペイロードフォーマットのサポートのために - （6.4節6.1節を参照）、この文書で定義されています。
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.
全てEVRCおよびRFC 3558で定義されたEVRC-B RTPペイロードフォーマット[4]及びRFC 4788のために、4つの追加のオプションパラメータ - "silencesupp"、 "dtxmax"、 "dtxmin"、および "二日酔い" は - 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で定義されたMIMEサブタイプの登録「EVRC」および「EVRC0」は、[4]、オプション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、ジム・アシュリー、Harikishan Desineni、セラフィン・ディアス、Harinath Garudadri、Gouri Johanssen、Ananth Kandhadai、Waqar Mohsin、アショク・ロイ、ジーノScribano、およびGajinderシンVijを。
Special thanks to Colin Perkins, Magnus Westerlund, and Adam Li for their careful review and comments that significantly improved the quality of this document.
大幅にこのドキュメントの品質を向上させ、その慎重なレビューとコメントのためのコリンパーキンス、マグヌスウェスター、アダムリーに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] "Enhanced Variable Rate Codec, Speech Service Option 3 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014, January 1997.
[2]、3GPP2 C.S0014、1997年1月「拡張可変レートコーデック、広帯域のための音声サービスオプション3は、スペクトラムデジタルシステムスプレッド」。
[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.
、RFC 3558、2003年7月[4]李、A.、 "拡張可変レートコーデック（EVRC）および選択可能なモードボコーダ（SMV）のためのRTPペイロードフォーマット"。
[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.、フレデリック、R.、およびV.ヤコブソン、 "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]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[7]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[8] "Discontinuous Transmission (DTX) of Speech in cdma2000 Systems", 3GPP2 C.S0076-0, Version 1.0, December 2005.
[8] "不連続伝送CDMA2000システムにおけるスピーチの（DTX）"、3GPP2 C.S0076-0、バージョン1.0、2005年12月。
[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謝モトローラ社1501 W.シュアードライブ、2-F9アーリントンハイツ、イリノイ州60004米国
Phone: +1-847-632-3028 EMail: Qiaobing.Xie@Motorola.com
電話：+ 1-847-632-3028 Eメール：Qiaobing.Xie@Motorola.com
Rohit Kapoor Qualcomm Inc. US
RohitカプールクアルコムInc.の米国
Phone: +1-858-845-1161 EMail: rkapoor@qualcomm.com
電話：+ 1-858-845-1161 Eメール：rkapoor@qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。