Network Working Group A. Li
Request for Comments: 3558 UCLA
Category: Standards Track July 2003
RTP Payload Format for Enhanced Variable Rate Codecs (EVRC)
and Selectable Mode Vocoders (SMV)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document describes the RTP payload format for Enhanced Variable Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Two sub-formats are specified for different application scenarios. A bundled/interleaved format is included to reduce the effect of packet loss on speech quality and amortize the overhead of the RTP header over more than one speech frame. A non-bundled format is also supported for conversational applications.
この文書では、強化された可変レートコーデック（EVRC）音声および選択可能なモードボコーダ（SMV）スピーチのためのRTPペイロード形式について説明します。二つのサブフォーマットが異なるアプリケーション・シナリオに指定されています。バンドル/インターリーブフォーマットは、音声品質に対するパケット損失の影響を低減し、複数の音声フレームの上にRTPヘッダのオーバーヘッドを償却するために含まれています。非バンドル形式は、会話のアプリケーションでサポートされています。
Table of Contents
目次
1. Introduction ................................................... 2
2. Background ..................................................... 2
3. The Codecs Supported ........................................... 3
3.1. EVRC ...................................................... 3
3.2. SMV ....................................................... 3
3.3. Other Frame-Based Vocoders ................................ 4
4. RTP/Vocoder Packet Format ...................................... 4
4.1. Interleaved/Bundled Packet Format ......................... 5
4.2. Header-Free Packet Format ................................. 6
4.3. Determining the Format of Packets ......................... 7
5. Packet Table of Contents Entries and Codec Data Frame Format ... 7
5.1. Packet Table of Contents entries .......................... 7
5.2. Codec Data Frames ......................................... 8
6. Interleaving Codec Data Frames ................................. 9
7. Bundling Codec Data Frames .................................... 12
8. Handling Missing Codec Data Frames ............................ 12
9. Implementation Issues ......................................... 12
9.1. Interleaving Length .......................................12
9.2. Validation of Received Packets ............................13
9.3. Processing the Late Packets ...............................13
10. Mode Request ................................................. 13
11. Storage Format ............................................... 14
12. IANA Considerations .......................................... 15
12.1. Registration of Media Type EVRC ..........................15
12.2. Registration of Media Type EVRC0 .........................16
12.3. Registration of Media Type SMV ...........................17
12.4. Registration of Media Type SMV0 ..........................18
13. Mapping to SDP Parameters .................................... 19
14. Security Considerations ...................................... 20
15. Adding Support of Other Frame-Based Vocoders ................. 20
16. Acknowledgements ............................................. 21
17. References ................................................... 21
17.1 Normative ................................................ 21
17.2 Informative .............................................. 22
18. Author's Address ............................................. 22
19. Full Copyright Statement ..................................... 23
This document describes how speech compressed with EVRC [1] or SMV [2] may be formatted for use as an RTP payload type. The format is also extensible to other codecs that generate a similar set of frame types. Two methods are provided to packetize the codec data frames into RTP packets: an interleaved/bundled format and a zero-header format. The sender may choose the best format for each application scenario, based on network conditions, bandwidth availability, delay requirements, and packet-loss tolerance.
この文書では、音声は、EVRCで圧縮方法を説明[1]又はSMV [2] RTPペイロードタイプとして使用するためにフォーマットされ得ます。フォーマットは、フレームタイプの同様のセットを生成する他のコーデックに拡張可能です。インターリーブ/バンドル形式およびゼロヘッダフォーマット：二つの方法がRTPパケットにコーデックデータフレームをパケット化するために設けられています。送信者は、ネットワークの状態、帯域幅の可用性、遅延要件、およびパケット損失の許容範囲に基づいて、各アプリケーションシナリオのための最適な形式を選択することができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[3]。
The 3rd Generation Partnership Project 2 (3GPP2) has published two standards which define speech compression algorithms for CDMA applications: EVRC [1] and SMV [2]. EVRC is currently deployed in millions of first and second generation CDMA handsets. SMV is the preferred speech codec standard for CDMA2000, and will be deployed in third generation handsets in addition to EVRC. Improvements and new codecs will keep emerging as technology improves, and future handsets will likely support multiple codecs.
EVRC [1]とSMV [2]：第3世代パートナーシッププロジェクト2（3GPP2）は、CDMAアプリケーション用の音声圧縮アルゴリズムを定義する2つの基準を公開しています。 EVRCは現在、第一および第二世代のCDMA携帯電話の何百万人に配布されます。 SMVは、CDMA2000のための好ましい音声コーデック規格であり、EVRCに加えて、第3世代携帯電話に展開されます。技術が向上して改善し、新しいコーデックは、新興続けると、将来の携帯電話は、おそらく複数のコーデックをサポートします。
The formats of the EVRC and SMV codec frames are very similar. Many other vocoders also share common characteristics, and have many similar application scenarios. This parallelism enables an RTP payload format to be designed for EVRC and SMV that may also support other, similar vocoders with minimal additional specification work. This can simplify the protocol for transporting vocoder data frames through RTP and reduce the complexity of implementations.
EVRCとSMVコーデックフレームのフォーマットは非常に似ています。他の多くのボコーダは、共通の特性を共有し、多くの同様のアプリケーションシナリオを持っています。この並列処理は、RTPペイロードフォーマットはまた、最小限の追加仕様の作業を有する他、同様のボコーダをサポートすることができるEVRCとSMVのために設計されることを可能にします。これは、RTPを介してボコーダデータフレームを転送するためのプロトコルを単純化し、実装の複雑さを低減することができます。
The Enhanced Variable Rate Codec (EVRC) [1] compresses each 20 milliseconds of 8000 Hz, 16-bit sampled speech input into output frames in one of the three different sizes: Rate 1 (171 bits), Rate 1/2 (80 bits), or Rate 1/8 (16 bits). In addition, there are two zero bit codec frame types: null frames and erasure frames. Null frames are produced as a result of the vocoder running at rate 0. Null frames are zero bits long and are normally not transmitted. Erasure frames are the frames substituted by the receiver to the codec for the lost or damaged frames. Erasure frames are also zero bits long and are normally not transmitted.
レート1/2（80ビット、レート1（171ビット）：拡張可変レートコーデック（EVRC）[1]は3種類のサイズのいずれかで出力フレームに8000ヘルツの各20ミリ秒、16ビットサンプリングされた音声入力を圧縮します）、またはレート1/8（16ビット）。ヌルフレームと消去フレーム：加えて、2つのゼロのビットのコーデック、フレームタイプがあります。ヌルフレームは、ボコーダ0ヌルフレームはゼロビット長であり、正常に送信されない速度で実行した結果として生成されます。消去フレームが紛失または破損したフレームのためにコーデックに受信機によって置換フレームです。消去フレームはまた、ゼロビット長であり、正常に送信されません。
The codec chooses the output frame rate based on analysis of the input speech and the current operating mode (either normal or one of several reduced rate modes). For typical speech patterns, this results in an average output of 4.2 kilobits/second for normal mode and a lower average output for reduced rate modes.
コーデックは、入力音声の分析と現在の動作モード（通常またはいくつかの縮小率のいずれかのモードのいずれか）に基づいて出力フレームレートを選択します。典型的な音声パターンの場合、これは4.2キロビット/通常モードと縮小率モードに対してより低い平均出力のための第二の平均出力を生じます。
The Selectable Mode Vocoder (SMV) [2] compresses each 20 milliseconds of 8000 Hz, 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. Null frames are produced as a result of the vocoder running at rate 0. Null frames are zero bits long and are normally not transmitted. Erasure frames are the frames substituted by the receiver to the codec for the lost or damaged frames. Erasure frames are also zero bits long and are normally not transmitted.
レート1/2（80ビット）、レート1（171ビット）：選択可能モードボコーダ（SMV）は、[2] 4種類のサイズの一つの出力フレームに8000ヘルツの各20ミリ秒、16ビットサンプリングされた音声入力を圧縮します、レート1/4（40ビット）、または1/8（16ビット）を評価します。ヌルフレームと消去フレーム：加えて、2つのゼロのビットのコーデック、フレームタイプがあります。ヌルフレームは、ボコーダ0ヌルフレームはゼロビット長であり、正常に送信されない速度で実行した結果として生成されます。消去フレームが紛失または破損したフレームのためにコーデックに受信機によって置換フレームです。消去フレームはまた、ゼロビット長であり、正常に送信されません。
The SMV codec can operate in six modes. Each mode may produce frames of any of the rates (full rate to 1/8 rate) for varying percentages of time, based on the characteristics of the speech samples and the selected mode. The SMV mode can change on a frame-by-frame basis. The SMV codec does not need additional information other than the codec data frames to correctly decode the data of various modes; therefore, the mode of the encoder does not need to be transmitted with the encoded frames.
SMVコーデックは、6つのモードで動作することができます。各モードは、音声サンプルと、選択されたモードの特性に基づいて、時間の割合を変化させる速度（1/8レートのフル・レート）のいずれかのフレームを生成することができます。 SMVモードでは、フレーム毎に変更することができます。 SMVコーデックは、正しく、様々なモードのデータを復号化するためのコーデックデータフレーム以外の追加情報を必要としません。従って、エンコーダのモードは、符号化されたフレームで送信する必要はありません。
The SMV codec chooses the output frame rate based on analysis of the input speech and the current operating mode. For typical speech patterns, this results in an average output of 4.2 kilobits/second for Mode 0 in two way conversation (approximately 50% active speech time and 50% in eighth rate while listening) and lower for other reduced rate modes. SMV is more bandwidth efficient than EVRC. EVRC is equivalent in performance to SMV mode 1.
SMVコーデックは、入力音声の分析と現在の動作モードに基づいて、出力フレームレートを選択します。典型的な音声パターンについて（聞きながら1/8レートで約50％の活性音声時間および50％）、これは双方向の会話に4.2キロビット/モード0秒の平均出力をもたらし、より低い他の減少率モードについて。 SMVはEVRCよりも効率的でより多くの帯域幅です。 EVRCはSMVモード1と性能が同等です。
Other frame-based vocoders can be carried in the packet format defined in this document, as long as they possess the following properties:
他のフレームベースのボコーダは、それらが以下の特性を有する限り、本文書で定義されたパケットフォーマットで実施することができます。
o The codec is frame-based;
o blank and erasure frames are supported;
o the total number of rates is less than 17;
o the maximum full rate frame can be transported in a single RTP
packet using this specific format.
Vocoders with the characteristics listed above can be transported using the packet format specified in this document with some additional specification work; the pieces that must be defined are listed in Section 15.
上記の特性を有するボコーダは、いくつかの追加の仕様ワークと、この文書で指定されたパケットフォーマットを用いて搬送することができます。定義されなければならない部分はセクション15に記載されています。
The vocoder speech data may be transmitted in either of the two RTP packet formats specified in the following two subsections, as appropriate for the application scenario. In the packet format diagrams shown in this document, bit 0 is the most significant bit.
ボコーダの音声データは、アプリケーションシナリオに応じて、以下の2つのサブセクションで指定された2つのRTPパケットのいずれかの形式で送信されてもよいです。本文書に示したパケットフォーマットの図において、ビット0が最上位ビットです。
This format is used to send one or more vocoder frames per packet. Interleaving or bundling MAY be used. The RTP packet for this format is as follows:
このフォーマットは、パケットごとに一つ以上のボコーダフレームを送信するために使用されます。インターリーブまたはバンドルを使用することができます。次のようにこの形式の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] | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |R|R| LLL | NNN | MMM | Count | TOC | ... | TOC |padding| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | one or more codec data frames, one per TOC entry | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ヘッダー[4] | + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + | R | R | LLL | NNN | MMM |カウント| TOC | ... | TOC |パディング| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |一の以上のコーデックデータフレーム、TOCエントリあたり1 | | .... | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
The RTP header has the expected values as described in the RTP specification [4]. The RTP timestamp is in 1/8000 of a second units for EVRC and SMV. For any other vocoders that use this packet format, the timestamp unit needs to be defined explicitly. The M bit should be set as specified in the applicable RTP profile, for example, RFC 3551 [5]. Note that RFC 3551 [5] specifies that if the sender does not suppress silence, the M bit will always be zero. When multiple codec data frames are present in a single RTP packet, the timestamp is that of the oldest data represented in the RTP packet. The assignment of an RTP payload type for this packet format is outside the scope of this document; it is specified by the RTP profile under which this payload format is used.
RTPヘッダは、RTP仕様[4]で説明されるように期待値を有しています。 RTPタイムスタンプは、EVRCとSMVのための秒単位の1/8000です。このパケットフォーマットを使用する他のボコーダのために、タイムスタンプユニットが明示的に定義する必要があります。該当RTPプロファイルで指定されるようにMビットは、例えば、設定されるべきである、RFC 3551 [5]。そのRFC 3551 [5]送信者が沈黙を抑制しない場合、Mビットは常にゼロとなることを指定することに注意してください。複数のコーデックデータフレームは単一のRTPパケット内に存在する場合、タイムスタンプはRTPパケットで表現最も古いデータのことです。このパケットフォーマットのためのRTPペイロードタイプの割り当ては、この文書の範囲外です。なお、このペイロードフォーマットが使用される下RTPプロファイルで指定されています。
The first octet of a Interleaved/Bundled format packet is the Interleave Octet. The second octet contains the Mode Request and Frame Count fields. The Table of Contents (ToC) field then follows. The fields are specified as follows:
インターリーブ/バンドル形式のパケットの最初のオクテットインターリーブオクテットです。第2オクテットは、モード要求とフレームカウントフィールドが含まれています。目次（TOC）フィールドは、次の。次のようにフィールドが指定されています。
Reserved (RR): 2 bits Reserved bits. MUST be set to zero by sender, SHOULD be ignored by receiver.
予約（RR）：2ビットの予約ビット。送信者によってゼロに設定しなければならなくて、受信機によって無視されるべきです。
Interleave Length (LLL): 3 bits Indicates the length of interleave; a value of 0 indicates bundling, a special case of interleaving. See Section 6 and Section 7 for more detailed discussion.
インターリーブ長さ（LLL）：3ビットインターリーブの長さを示します。 0の値は、バンドリング、インターリービングの特殊なケースを示しています。より詳細な議論については、セクション6とセクション7を参照してください。
Interleave Index (NNN): 3 bits Indicates the index within an interleave group. MUST have a value less than or equal to the value of LLL. Values of NNN greater than the value of LLL are invalid. Packet with invalid NNN values SHOULD be ignored by the receiver.
インタリーブインデックス（NNN）：3ビットは、インタリーブグループ内のインデックスを示します。 LLLの値以下の値を持たなければなりません。 LLLの値よりも大きいNNNの値が無効です。無効NNN値を持つパケットは、受信機によって無視されるべきです。
Mode Request (MMM): 3 bits The Mode Request field is used to signal Mode Request information. See Section 10 for details.
モードリクエスト（MMM）：3ビットはモード要求フィールドは、モード要求情報を通知するために使用されます。詳細については、セクション10を参照してください。
Frame Count (Count): 5 bits The number of ToC fields (and vocoder frames) present in the packet is the value of the frame count field plus one. A value of zero indicates that the packet contains one ToC field, while a value of 31 indicates that the packet contains 32 ToC fields.
フレーム数（カウント）：パケット内に存在する目次フィールド（及びボコーダフレーム）の5ビット数は、フレームカウントフィールドに1を足した値です。ゼロの値は31の値は、パケットが32目次フィールドが含まれていることを示しているパケットは、ある目次フィールドが含まれていることを示しています。
Padding (padding): 0 or 4 bits This padding ensures that codec data frames start on an octet boundary. When the frame count is odd, the sender MUST add 4 bits of padding following the last TOC. When the frame count is even, the sender MUST NOT add padding bits. If padding is present, the padding bits MUST be set to zero by sender, and SHOULD be ignored by receiver.
パディング（パディング）：0または4ビットこのパディングは、コーデックデータフレームがオクテットの境界で始まることを保証します。フレーム数が奇数の場合、送信者は最後のTOC、以下のパディングの4ビットを加えなければなりません。フレーム数が偶数の場合は、送信者は、パディングビットを追加してはなりません。パディングが存在する場合、パディングビットは送信者によってゼロに設定しなければなりません、そして受信機によって無視されるべきです。
The Table of Contents field (ToC) provides information on the codec data frame(s) in the packet. There is one ToC entry for each codec data frame. The detailed formats of the ToC field and codec data frames are specified in Section 5.
コンテンツフィールドのテーブル（TOC）は、パケット内のコーデックデータフレーム（複数可）に関する情報を提供します。各コーデックデータフレームのための1つのToCエントリーがあります。目次フィールド及びコーデックデータフレームの詳細なフォーマットはセクション5で指定されています。
Multiple data frames may be included within a Interleaved/Bundled packet using interleaving or bundling as described in Section 6 and Section 7.
第6及び第7で説明したように複数のデータ・フレームは、インターリービングを使用するか、束ねインターリーブ/バンドルパケット内に含まれてもよいです。
The Header-Free Packet Format is designed for maximum bandwidth efficiency and low latency. Only one codec data frame can be sent in each Header-Free format packet. None of the payload header fields (LLL, NNN, MMM, Count) nor ToC entries are present. The codec rate for the data frame can be determined from the length of the codec data frame, since there is only one codec data frame in each Header-Free packet.
ヘッダフリーパケットフォーマットは、最大帯域幅の効率と低遅延のために設計されています。一つだけのコーデックデータフレームは、各ヘッダフリーフォーマットのパケットで送信することができます。ペイロードヘッダフィールド（LLL、NNN、MMM、COUNT）のいずれものToCエントリは存在しません。各ヘッダフリーパケットで唯一のコーデックデータフレームがあるので、データフレームのためのコーデックレートは、コーデックデータフレームの長さから決定することができます。
Use of the RTP header fields for Header-Free RTP/Vocoder Packet Format is the same as described in Section 4.1 for Interleaved/Bundled RTP/Vocoder Packet Format. The detailed format of the codec data frame is specified in Section 5.
インターリーブ/バンドルRTP /ボコーダパケットフォーマットについては、セクション4.1で説明したようにヘッダフリーRTP /ボコーダパケットフォーマットのためのRTPヘッダフィールドの使用は、同じです。コーデックデータフレームの詳細なフォーマットはセクション5で指定されています。
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] | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | + ONLY one codec data frame +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ヘッダー[4] | + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + | | + ONLY 1コーデックのデータフレーム+ - + - + - + - + - + - + - + - + | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
All receivers SHOULD be able to process both packet formats. The sender MAY choose to use one or both packet formats.
すべてのレシーバは、両方のパケットフォーマットを処理することができるべきです。送信者は、一方または両方のパケットフォーマットを使用することもできます。
A receiver MUST have prior knowledge of the packet format to correctly decode the RTP packets. When packets of both formats are used within the same session, different RTP payload type values MUST be used for each format to distinguish the packet formats. The association of payload type number with the packet format is done out-of-band, for example by SDP during the setup of a session.
受信機は、正しくRTPパケットを復号化するパケットフォーマットの事前の知識を持たなければなりません。両方のフォーマットのパケットは、同じセッション内で使用される場合、異なるRTPペイロードタイプ値はパケットフォーマットを区別するために、各フォーマットのために使用されなければなりません。パケットフォーマットのペイロードタイプ番号の関連付けは、アウトオブバンド、SDPによって例えばセッションのセットアップの間に行われます。
Each codec data frame in a Interleaved/Bundled packet has a corresponding Table of Contents (ToC) entry. The ToC entry indicates the rate of the codec frame. (Header-Free packets MUST NOT have a ToC field.)
インターリーブ/バンドルパケット内の各コーデックデータフレームは、目次（TOC）エントリの対応表を有しています。目次のエントリは、コーデック、フレームレートを示します。 （ヘッダのないパケットは、目次フィールドを持つことはできません。）
Each ToC entry is occupies four bits. The format of the bits is indicated below:
各目次エントリは4ビットを占有しています。ビットのフォーマットを以下に示します：
0 1 2 3 +-+-+-+-+ |fr type| +-+-+-+-+
0 1 2 3 + - + - + - + - + | FRタイプ| + - + - + - + - +
Frame Type: 4 bits The frame type indicates the type of the corresponding codec data frame in the RTP packet.
フレームタイプ：フレームタイプがRTPパケットに対応するコーデックデータフレームのタイプを示す4ビット。
For EVRC and SMV codecs, the frame type values and size of the associated codec data frame are described in the table below:
EVRC及びSMVコーデックのために、関連したコーデックデータフレームのフレームタイプ値とサイズを以下の表に記載されています。
Value Rate Total codec data frame size (in octets)
---------------------------------------------------------
0 Blank 0 (0 bit)
1 1/8 2 (16 bits)
2 1/4 5 (40 bits; not valid for EVRC)
3 1/2 10 (80 bits)
4 1 22 (171 bits; 5 padded at end with zeros)
5 Erasure 0 (SHOULD NOT be transmitted by sender)
All values not listed in the above table MUST be considered reserved. A ToC entry with a reserved Frame Type value SHOULD be considered invalid. Note that the EVRC codec does not have 1/4 rate frames, thus frame type value 2 MUST be considered a reserved value when the EVRC codec is in use.
上記の表に記載されていないすべての値が予約されたとみなされなければなりません。予約されたフレームタイプ値とのToCエントリーは無効とみなされるべきです。 EVRCコーデックが1/4レートフレームを持たないEVRCコーデックが使用されている場合、したがって、フレームタイプ値2が予約値と見なされなければならないことに留意されたいです。
Other vocoders that use this packet format need to specify their own table of frame types and corresponding codec data frames.
このパケットフォーマットを使用する他のボコーダは、フレームタイプと、対応するコーデックデータフレームの独自のテーブルを指定する必要があります。
The output of the vocoder MUST be converted into codec data frames for inclusion in the RTP payload. The conversions for EVRC and SMV codecs are specified below. (Note: Because the EVRC codec does not have Rate 1/4 frames, the specifications of 1/4 frames does not apply to EVRC codec data frames). Other vocoders that use this packet format need to specify how to convert vocoder output data into frames.
ボコーダの出力は、RTPペイロードに含めるためのコーデックデータフレームに変換されなければなりません。 EVRCとSMVコーデックの変換は以下に指定されています。 （注意：EVRCコーデックはレート1/4のフレームを持っていないので、1/4フレームの仕様は、EVRCコーデックデータフレームには適用されません）。このパケットフォーマットを使用する他のボコーダは、フレームにボコーダ出力データを変換する方法を指定する必要があります。
The codec output data bits as numbered in EVRC and SMV are packed into octets. The lowest numbered bit (bit 1 for Rate 1, Rate 1/2, Rate 1/4 and Rate 1/8) is placed in the most significant bit (internet bit 0) of octet 1 of the codec data frame, the second lowest bit is placed in the second most significant bit of the first octet, the third lowest in the third most significant bit of the first octet, and so on. This continues until all of the bits have been placed in the codec data frame.
EVRCとSMVで番号としてコーデック出力データビットはオクテットにパックされています。最も小さい番号のビット（レート1、レート1/2、レート1/4、およびレート1/8のビット1）は、第二最低コーデックデータフレームのオクテット1の最上位ビットで（インターネットビット0）が配置されていますビットように最初のオクテットの最上位から2番目のビット、最初のオクテットの第三の最上位ビットで3番目に配置され、そしてれます。すべてのビットコーデックデータフレーム内に配置されるまでこれが継続します。
The remaining unused bits of the last octet of the codec data frame MUST be set to zero. Note that in EVRC and SMV this is only applicable to Rate 1 frames (171 bits) as the Rate 1/2 (80 bits), Rate 1/4 (40 bits, SMV only) and Rate 1/8 frames (16 bits) fit exactly into a whole number of octets.
コーデックデータフレームの最後のオクテットの残りの未使用のビットはゼロに設定しなければなりません。 、レート1/2（80ビット）としてEVRC及びSMVで、これは1つのフレーム（171ビット）を評価するのみ適用可能であることに留意されたいレート1/4（40ビット、SMVのみ）及び1/8フレーム（16ビット）レートオクテットの整数に正確にフィット。
Following is a detailed listing showing a Rate 1 EVRC/SMV codec output frame converted into a codec data frame:
以下は、レート1 EVRC / SMVコーデック出力フレームを示す詳細なリストは、コーデックデータフレームに変換されます。
The codec data frame for a EVRC/SMV codec Rate 1 frame is 22 octets long. Bits 1 through 171 from the EVRC/SMV codec Rate 1 frame are placed as indicated, with bits marked with "Z" set to zero. EVRC/SMV codec Rate 1/8, Rate 1/4 and Rate 1/2 frames are converted similarly, but do not require zero padding because they align on octet boundaries.
EVRC / SMVコーデックレート1つのフレームのコーデックデータフレームは、22オクテットの長さです。示されるように、EVRC / SMVコーデックレート1フレームから171を介してビット1をゼロに設定された「Z」でマークされたビットで、配置されています。 EVRC / SMVコーデックレート1/8、レート1/4およびレート1/2のフレームも同様に変換されますが、彼らはオクテット境界に合わせるため、ゼロパディングを必要としません。
Rate 1 codec data frame
レート1つのコーデックデータフレーム
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0| |0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3|3| |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|2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1| | | | | | |4|4|4|4|4|5|5|5|5|5|5|5|5|5|5|6|6|6|6|6|6|6|6|6|6|7|7|Z|Z|Z|Z|Z| |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| | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 3 | 3 | 3 | | 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 | 2 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +：+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | | | | | | | 4 | 4 | 4 | 4 | 4 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | 6 | 6 | 6 | 6 | 6 | 6 | 6 | 6 | 6 | 6 | 7 | 7 | Z | Z | Z | Z | Z | | 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 | | | | | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
As indicated in Section 4.1, more than one codec data frame MAY be included in a single Interleaved/Bundled packet by a sender. This is accomplished by interleaving or bundling.
セクション4.1に示されているように、複数のコーデックデータフレームは、送信者が、単一のインターリーブ/バンドルパケットに含まれるかもしれません。これは、インターリーブまたはバンドルすることによって達成されます。
Bundling is used to spread the transmission overhead of the RTP and payload header over multiple vocoder frames. Interleaving additionally reduces the listener's perception of data loss by spreading such loss over non-consecutive vocoder frames. EVRC, SMV, and similar vocoders are able to compensate for an occasional lost frame, but speech quality degrades exponentially with consecutive frame loss.
バンドルは、複数のボコーダフレーム上RTPペイロードヘッダの送信オーバーヘッドを拡散するために使用されます。インタリーブは、更に、非連続的なボコーダフレーム上にそのような損失を拡散することにより、データ損失の聞き手の知覚を減少させます。 EVRC、SMV、および同様のボコーダは時折失われたフレームを補正することができますが、音声品質は、連続するフレーム損失に対して指数関数的に低下します。
Bundling is signaled by setting the LLL field to zero and the Count field to greater than zero. Interleaving is indicated by setting the LLL field to a value greater than zero.
バンドルは、ゼロよりも大きいゼロにLLLフィールドおよびカウントフィールドを設定することによってシグナリングされます。インターリービングは、ゼロより大きい値にLLLフィールドを設定することによって示されています。
The discussions on general interleaving apply to the bundling (which can be viewed as a reduced case of interleaving) with reduced complexity. The bundling case is discussed in detail in Section 7.
一般的なインタリーブの議論は、低減複雑さ（インタリーブの減少場合とみなすことができる）バンドリングに適用されます。束ねる場合は、第7節で詳しく説明されています。
Senders MAY support interleaving and/or bundling. All receivers that support Interleave/Bundling packet format MUST support both interleaving and bundling.
送信者は、インターリービングおよび/またはバンドルをサポートするかもしれません。インターリーブ/バンドルパケットフォーマットをサポートするすべての受信機は、インターリーブとバンドルの両方をサポートしなければなりません。
Given a time-ordered sequence of output frames from the codec numbered 0..n, a bundling value B (the value in the Count field plus one), and an interleave length L where n = B * (L+1) - 1, the output frames are placed into RTP packets as follows (the values of the fields LLL and NNN are indicated for each RTP packet):
1 - コーデック番号0..N、結束値B（Countフィールドの値を加えたもの）、及びインターリーブ長さL N = B×（L + 1）からの出力フレームの時間順シーケンス与え次のように、出力フレームは、（フィールドLLLとNNNの値は、各RTPパケットのために示されている）、RTPパケットに配置されます。
First RTP Packet in Interleave group: LLL=L, NNN=0 Frame 0, Frame L+1, Frame 2(L+1), Frame 3(L+1), ... for a total of B frames
インタリーブグループにおける最初のRTPパケットは：Bフレームの合計LLLは、NNN = 0フレーム0、フレームL + 1、フレーム2 Lを=（L + 1）、フレーム3（L + 1）、...
Second RTP Packet in Interleave group: LLL=L, NNN=1 Frame 1, Frame 1+L+1, Frame 1+2(L+1), Frame 1+3(L+1), ... for a total of B frames
インタリーブグループ内の第二のRTPパケット：LLLはL、NNN = 1つのフレーム1、フレーム1 + L + 1、フレーム1 + 2（L + 1）、フレーム1 + 3（L + 1）、...合計を= Bフレームの
This continues to the last RTP packet in the interleave group:
これは、インタリーブグループ内の最後のRTPパケットに続けます。
L+1 RTP Packet in Interleave group: LLL=L, NNN=L Frame L, Frame L+L+1, Frame L+2(L+1), Frame L+3(L+1), ... for a total of B frames
L +基がRTPパケットインタリーブ1：LLLのためのL、NNN = LフレームL、フレームL + L + 1、フレームL + 2（L + 1）、フレームL + 3（L + 1）、...を= Bフレームの総数
Within each interleave group, the RTP packets making up the interleave group MUST be transmitted in value-increasing order of the NNN field. While this does not guarantee reduced end-to-end delay on the receiving end, when packets are delivered in order by the underlying transport, delay will be reduced to the minimum possible.
各インタリーブグループ内の、インタリーブグループを構成するRTPパケットは、NNNフィールドの値は、昇順で送信されなければなりません。これは、受信側で減少し、エンドツーエンド遅延を保証するものではありませんが、パケットが基盤となるトランスポートで順番に配信されたときに、遅延が最小限に低減されます。
Receivers MAY signal the maximum number of codec data frames (i.e., the maximum acceptable bundling value B) they can handle in a single RTP packet using the OPTIONAL maxptime RTP mode parameter identified in Section 12.
受信機は、それらがセクション12で同定OPTIONAL maxptime RTPモードパラメータを使用して、単一のRTPパケットに処理できるコーデックデータフレームの最大数（すなわち、最大許容結束値B）をシグナリングすることができます。
Receivers MAY signal the maximum interleave length (i.e., the maximum acceptable LLL value in the Interleaving Octet) they will accept using the OPTIONAL maxinterleave RTP mode parameter identified in Section 12.
受信機は、最大インターリーブ長をシグナリングすることができる（すなわち、インターリーブオクテットの最大許容LLL値）は、セクション12で同定OPTIONAL maxinterleave RTPモードパラメータを使用して受け入れます。
The parameters maxptime and maxinterleave are exchanged at the initial setup of the session. In one-to-one sessions, the sender MUST respect these values set be the receiver, and MUST NOT interleave/bundle more packets than what the receiver signals that it can handle. This ensures that the receiver can allocate a known amount of buffer space that will be sufficient for all interleaving/bundling used in that session. During the session, the sender may decrease the bundling value or interleaving length (so that less buffer space is required at the receiver), but never exceed the maximum value set by the receiver. This prevents the situation where a receiver needs to allocate more buffer space in the middle of a session but is unable to do so.
パラメータmaxptimeとmaxinterleaveは、セッションの初期セットアップ時に交換されます。一対一のセッションでは、送信者は、これらの値は、受信機とすることが設定され、それが処理できるものを受信信号よりパケットをバンドル/インターリーブしてはいけません尊重しなければなりません。これは、受信機がそのセッションで使用されるすべてのインターリービング/結束するのに十分であろうバッファスペースの既知量を割り当てることができることを確実にします。セッション中に、送信者は、（より少ないバッファ空間は、受信機で必要とされるように）結束値又はインターリーブ長を減少させるが、受信機によって設定された最大値を超えないことができます。これは、受信機は、セッションの途中でより多くのバッファ領域を割り当てる必要がありますが、そうすることができない事態を防ぐことができます。
Additionally, senders have the following restrictions:
また、送信者は、次の制限があります。
o MUST NOT bundle more codec data frames in a single RTP packet than indicated by maxptime (see Section 12) if it is signaled.
それが通知された場合にO maxptimeによって示されるよりも、単一のRTPパケット内の複数のコーデックデータフレームをバンドルしてはいけません（セクション12を参照）。
o SHOULD NOT bundle more codec data frames in a single RTP packet than will fit in the MTU of the underlying network.
oは、基盤となるネットワークのMTUに収まるよりも、単一のRTPパケットでより多くのコーデックデータフレームをバンドルすべきではありません。
o Once beginning a session with a given maximum interleaving value set by maxinterleave in Section 12, MUST NOT increase the interleaving value (LLL) to exceed the maximum interleaving value that is signaled.
O一旦項12にmaxinterleaveによって設定された所定の最大インタリーブ値とのセッションを開始、シグナリングされる最大インタリーブ値を超えインターリーブ値（LLL）を大きくしてはいけません。
o MAY change the interleaving value, but MUST do so only between interleave groups.
Oインターリーブ値を変更することが、唯一のインタリーブグループ間で行う必要があります。
o Silence suppression MUST only be used between interleave groups. A ToC with Frame Type 0 (Blank Frame, Section 5.1) MUST be used within interleaving groups if the codec outputs a blank frame. The M bit in the RTP header is not set for these blank frames, as the stream is continuous in time. Because there is only one time stamp for each RTP packet, silence suppression used within an interleave group would cause ambiguities when reconstructing the speech at the receiver side, and thus is prohibited.
Oサイレンス抑制は、インタリーブグループの間で使用されなければなりません。コーデックは、ブランクフレームを出力する場合、フレームタイプ0（ブランクフレーム、セクション5.1）とのTOCはインタリーブグループ内で使用しなければなりません。ストリームは、時間的に連続しているように、RTPヘッダ内のMビットは、これらの空白のフレームに設定されていません。各RTPパケットの唯一のタイムスタンプがあるため、インタリーブグループ内で使用される無音抑圧は、受信機側で音声を再構成する際に曖昧さを引き起こすので、禁止されています。
Given an RTP packet with sequence number S, interleave length (field LLL) L, interleave index value (field NNN) N, and bundling value B, the interleave group consists of this RTP packet and other RTP packets with sequence numbers from S-N mod 65536 to S-N+L mod 65536 inclusive. In other words, the interleave group always consists of L+1 RTP packets with sequential sequence numbers. The bundling value for all RTP packets in an interleave group MUST be the same.
シーケンス番号S、インターリーブ長さ（フィールドLLL）L、インターリーブインデックス値（フィールドNNN）N、及び値Bを束ねるのRTPパケットを考えると、インタリーブグループはSN MOD 65536からの配列番号で、このRTPパケットと他のRTPパケットから成り包括65536 S-N + Lのmodへ。換言すれば、インタリーブグループは常にシーケンシャルシーケンス番号L + 1つのRTPパケットから成ります。インタリーブグループ内のすべてのRTPパケットのバンドルの値は同じでなければなりません。
The receiver determines the expected bundling value for all RTP packets in an interleave group by the number of codec data frames bundled in the first RTP packet of the interleave group received. Note that this may not be the first RTP packet of the interleave group if packets are delivered out of order by the underlying transport.
受信機は、インタリーブグループの最初のRTPパケットで受信されたバンドルコーデックデータフレームの数でインタリーブグループ内のすべてのRTPパケットの期待結束値を決定します。パケットは、基礎となるトランスポートによって順不同配信されるときは、このインタリーブグループの最初のRTPパケットではないかもしれないことに留意されたいです。
As discussed in Section 6, the bundling of codec data frames is a special reduced case of interleaving with LLL value in the Interleave Octet set to 0.
第6節で議論したように、コーデックデータフレームのバンドルは、インターリーブオクテットのLLL値とインターリーブの特別な減少場合は0に設定されています。
Bundling codec data frames indicates that multiple data frames are included consecutively in a packet, because the interleaving length (LLL) is 0. The interleaving group is thus reduced to a single RTP packet, and the reconstruction of the codec data frames from RTP packets becomes a much simpler process.
コーデックデータフレームをバンドルするインターリーブ長（LLL）はインタリーブグループは、このように単一のRTPパケットに低減される0であり、RTPパケットからコーデックデータフレームの再構成となるため、複数のデータフレームは、パケットに連続的に含まれていることを示していますはるかに簡単なプロセス。
Furthermore, the additional restrictions on senders are reduced to:
さらに、送信者の追加制限はに縮小されています。
o MUST NOT bundle more codec data frames in a single RTP packet than indicated by maxptime (see Section 12) if it is signaled.
それが通知された場合にO maxptimeによって示されるよりも、単一のRTPパケット内の複数のコーデックデータフレームをバンドルしてはいけません（セクション12を参照）。
o SHOULD NOT bundle more codec data frames in a single RTP packet than will fit in the MTU of the underlying network.
oは、基盤となるネットワークのMTUに収まるよりも、単一のRTPパケットでより多くのコーデックデータフレームをバンドルすべきではありません。
The vocoders covered by this payload format support erasure frames as an indication when frames are not available. The erasure frames are normally used internally by a receiver to advance the state of the voice decoder by exactly one frame time for each missing frame. Using the information from packet sequence number, time stamp, and the M bit, the receiver can detect missing codec data frames from RTP packet loss and/or silence suppression, and generate corresponding erasure frames. Erasure frames MUST also be used in storage format to record missing frames.
ボコーダは、フレームが利用できない指標として、このペイロードフォーマットのサポート消去フレームによって覆わ。消去フレームは、通常、各欠落フレームの正確に一つのフレームの時間だけ音声復号器の状態を前進させるために受信機によって内部的に使用されます。パケットシーケンス番号、タイムスタンプ、及びMビットからの情報を使用して、受信機は、RTPパケットロス及び/又は無音抑圧から欠落コーデックデータフレームを検出し、対応する消去フレームを生成することができます。消去フレームも欠落しているフレームを記録するために、ストレージ・フォーマットで使用しなければなりません。
The vocoder interpolates the missing speech content when given an erasure frame. However, the best quality is perceived by the listener when erasure frames are not consecutive. This makes interleaving desirable as it increases speech quality when packet loss occurs.
ボコーダは消去フレームを与えられた行方不明の発話内容を補間します。消去フレームが連続していないときしかし、最高の品質は、リスナーによって知覚されます。これは、パケットロスが発生した場合、それは通話品質を向上させるように望ましいインターリーブます。
On the other hand, interleaving can greatly increase the end-to-end delay. Where an interactive session is desired, either Interleaved/Bundled packet format with interleaving length (field LLL) 0 or Header-Free packet format is RECOMMENDED.
一方、インターリーブが大きくエンドツーエンド遅延を増大させることができます。インタラクティブセッションが所望される場合、インターリーブ長（フィールドLLL）のいずれかでインターリーブ/バンドルパケットフォーマット0またはヘッダフリーパケットフォーマットが推奨されます。
When end-to-end delay is not a primary concern, an interleaving length (field LLL) of 4 or 5 is RECOMMENDED as it offers a reasonable compromise between robustness and latency.
エンドツーエンド遅延が主要な関心事ではない場合には、4または5のインターリーブ長（フィールドLLL）は、それが堅牢性と待ち時間との間の合理的な妥協点を提供するように推奨されています。
When receiving an RTP packet, the receiver SHOULD check the validity of the ToC fields and match the length of the packet with what is indicated by the ToC fields. If any invalidity or mismatch is detected, it is RECOMMENDED to discard the received packet to avoid potential severe degradation of the speech quality. The discarded packet is treated following the same procedure as a lost packet, and the discarded data will be replaced with erasure frames.
RTPパケットを受信した場合、受信機は、目次フィールドの妥当性をチェックし、目次フィールドによって示されるものとパケットの長さと一致する必要があります。任意の無効または不一致が検出された場合は、音声品質の潜在的な深刻な劣化を避けるために、受信したパケットを破棄することをお勧めします。廃棄されたパケットは、失われたパケットと同じ手順に従って処理され、そして廃棄されたデータは消去フレームに置き換えられます。
On receipt of an RTP packet with an invalid value of the LLL or NNN fields, the RTP packet SHOULD be treated as lost by the receiver for the purpose of generating erasure frames as described in Section 8.
セクション8で説明したように消去フレームを生成するために受信機によって失われるようLLL又はNNNフィールドの無効な値を持つRTPパケットの受信時に、RTPパケットが扱われるべきです。
On receipt of an RTP packet in an interleave group with other than the expected frame count value, the receiver MAY discard codec data frames off the end of the RTP packet or add erasure codec data frames to the end of the packet in order to manufacture a substitute packet with the expected bundling value. The receiver MAY instead choose to discard the whole interleave group.
予想されるフレームカウント値以外とインタリーブグループ内のRTPパケットの受信時に、受信機は、RTPパケットの末尾からコーデックデータフレームを捨てるか、または製造するために、パケットの最後に消去コーデックデータフレームを追加します予想されるバンドルの値を持つ代替パケット。受信機は、全体ではなく、インタリーブグループを破棄するように選ぶかもしれません。
Assume that the receiver has begun playing frames from an interleave group. The time has come to play frame x from packet n of the interleave group. Further assume that packet n of the interleave group has not been received. As described in Section 8, an erasure frame will be sent to the receiving vocoder.
受信機は、インタリーブグループからのフレームを再生し始めていることを前提としています。時間は、インタリーブグループのパケットnからフレームxをプレイするようになってきました。さらにインタリーブグループのパケットnを受信していないと仮定する。セクション8で説明したように、消去フレームは、受信ボコーダに送信されます。
Now, assume that packet n of the interleave group arrives before frame x+1 of that packet is needed. Receivers should use frame x+1 of the newly received packet n rather than substituting an erasure frame. In other words, just because packet n was not available the first time it was needed to reconstruct the interleaved speech, the receiver should not assume it is not available when it is subsequently needed for interleaved speech reconstruction.
さて、そのパケットのフレームのx + 1が必要とされる前にインタリーブグループのパケットnが到着すると仮定します。受信機は、新たに受信したパケットのフレームX + 1からnではなく消去フレームを置換を使用すべきです。言い換えれば、パケットnは、それがインターリーブされたスピーチを再構築するために必要だった、初めて入手できなかったという理由だけで、受信機は、それがその後のインターリーブ音声再建のために必要とされるとき、それは利用できないと仮定してはいけません。
The Mode Request signal requests a particular encoding mode for the speech encoding in the reverse direction. All implementations are RECOMMENDED to honor the Mode Request signal. The Mode Request signal SHOULD only be used in one-to-one sessions. In multi-party sessions, any received Mode Request signals SHOULD be ignored.
モード要求信号は、逆方向の音声符号化のための特定の符号化モードを要求します。すべての実装は、モード要求信号を尊重することをお勧めします。モード要求信号は、1対1のセッションで使用されるべきです。マルチパーティセッションでは、任意の受信モード要求信号は無視されるべきです。
In addition, the Mode Request signal MAY also be sent through non-RTP means, which is out of the scope of this specification.
また、モード要求信号はまた、本明細書の範囲外である、手段非RTPを介して送信されるかもしれません。
The three-bit Mode Request field is used to signal the receiver to set a particular encoding mode to its audio encoder. If the Mode Request field is set to a valid value in RTP packets from node A to node B, it is a request for node B to change to the requested encoding mode for its audio encoder and therefore the bit rate of the RTP stream from node B to node A. Once a node sets this field to a value, it SHOULD continue to set the field to the same value in subsequent packets until the requested mode is different. This design helps to eliminate the scenario of getting the codec stuck in an unintended state if one of the packets that carries the Mode Request is lost. An otherwise silent node MAY send an RTP packet containing a blank frame in order to send a Mode Request.
3ビットモード要求フィールドは、そのオーディオエンコーダに特定の符号化モードを設定するために受信機に信号を送るために使用されます。モード要求フィールドは、ノードAからノードBへのRTPパケット内の有効な値に設定されている場合は、ノードからのオーディオエンコーダの要求された符号化モードとRTPストリームの、したがってビットレートに変更するためのノードBのための要求でありますノードAにBがいったんノードが値にこのフィールドを設定し、それは要求されたモードが異なるまで、後続のパケットで同じ値にフィールドを設定し続けなければなりません。このデザインは、モード要求を運ぶパケットの1つが失われた場合、意図しない状態で立ち往生コーデックを得るためのシナリオを排除することができます。そうでなければサイレントノードは、モード要求を送信するためにブランクフレームを含むRTPパケットを送信することができます。
Each codec type using this format SHOULD define its own interpretation of the Mode Request field. Codecs SHOULD follow the convention that higher values of the three-bit field correspond to an equal or lower average output bit rate.
このフォーマットを使用して、各コーデックタイプは、モード要求フィールドの独自の解釈を定義する必要があります。コーデックは、3ビットフィールドのより高い値が等しい又はより低い平均出力のビットレートに対応する規則に従うべきです。
For the EVRC codec, the Mode Request field MUST be interpreted according to Tables 2.2.1.2-1 and 2.2.1.2-2 of the EVRC codec specifications [1].
EVRCコーデックのため、モード要求フィールドは、表2.2.1.2-1及びEVRCコーデック仕様の2.2.1.2-2に従って解釈されなければならない[1]。
For SMV codec, the Mode Request field MUST be interpreted according to Table 2.2-2 of the SMV codec specifications [2].
SMVコーデックのため、モード要求フィールドは、[2] SMVコーデックの仕様の表2.2-2に従って解釈されなければなりません。
The storage format is used for storing speech frames, e.g., as a file or e-mail attachment.
保存形式は、ファイルまたは電子メールの添付ファイルとして、例えば、音声フレームを格納するために使用されます。
The file begins with a magic number to identify the vocoder that is used. The magic number for EVRC corresponds to the ASCII character string "#!EVRC\n", i.e., "0x23 0x21 0x45 0x56 0x52 0x43 0x0A". The magic number for SMV corresponds to the ASCII character string "#!SMV\n", i.e., "0x23 0x21 0x53 0x4d 0x56 0x0a".
ファイルが使用されているボコーダを識別するためのマジックナンバーで始まります。 EVRCのためのマジックナンバーはASCII文字列 "＃！EVRCの\ nを"、すなわち、 "0x23 0x21で0x45 0x56 0x52 0x43この0x0Aを" に相当します。 SMVのためのマジックナンバーはASCII文字列 "＃！SMVの\ n" は、すなわち、 "0x23 0x21で$ 53 0x4d 0x56 0x0Aを" に相当します。
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 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つの最上位ビットを設定することにより、1つのオクテットに拡張されます。例えば、4のTOC値（フルレートフレーム）が0x04のように格納されます。
Speech frames lost in transmission and non-received frames MUST be stored as erasure frames (frame type 5, see definition in Section 5.1) to maintain synchronization with the original media.
送信と非受信したフレームに失われた音声フレームは消去フレームとして格納する必要があり、元のメディアとの同期を維持するために、（フレームタイプ5、セクション5.1で定義を参照）。
Four new MIME sub-types as described in this section have been registered by the IANA.
このセクションで説明するように、4つの新しいMIMEサブタイプはIANAによって登録されています。
The MIME-names for the EVRC and SMV codec are allocated from the IETF tree since all the vocoders covered are expected to be widely used for Voice-over-IP applications.
対象となるすべてのボコーダは広くボイスオーバーIPアプリケーションのために使用されることが期待されているので、EVRCとSMVコーデックのMIME-名は、IETFツリーから割り当てられます。
Media Type Name: audio
メディアタイプ名：オーディオ
Media Subtype Name: EVRC
メディアサブタイプ名：EVRC
Required Parameter: none
必要なパラメータ：なし
Optional parameters: The following parameters apply to RTP transfer only.
オプションのパラメータは以下のパラメータは、RTP転送にのみ適用されます。
ptime: Defined as usual for RTP audio (see RFC 2327).
PTIME：RTPオーディオ用にいつものように定義された（RFC 2327を参照してください）。
maxptime: The maximum amount of media which 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でなければなりません。
Encoding considerations: This type 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.
符号化の考慮事項：このタイプは、セクション4.1で指定されたインターリーブ/バンドルパケットフォーマットを使用して、RTPを介しEVRC符号化データの転送用に定義された6、およびRFC 3558. 7はまたで指定されたストレージ・フォーマットを使用して他の転送方法のために定義されていますRFC 3558のセクション11。
Security considerations: See Section 14 "Security Considerations" of RFC 3558.
セキュリティに関する考慮事項：RFC 3558のセクション14「セキュリティの考慮事項」を参照してください。
Public specification: The EVRC vocoder is specified in 3GPP2 C.S0014. Transfer methods are specified in RFC 3558.
公開された仕様：EVRCボコーダは、3GPP2 C.S0014に指定されています。転送方法は、RFC 3558で指定されています。
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
マジック番号：＃！EVRC \ n個（RFC 3558のセクション11を参照）ファイル拡張子：EVC、EVC Macintoshファイルタイプコード：なしオブジェクト識別子またはOID：なし
Intended usage: COMMON. It is expected that many VoIP applications (as well as mobile applications) will use this type.
意図している用法：COMMON。多くのVoIPアプリケーション（だけでなく、モバイルアプリケーション）は、このタイプを使用することが期待されます。
Person & email address to contact for further information: Adam Li adamli@icsl.ucla.edu
人と詳細のために連絡する電子メールアドレス：アダム・リーadamli@icsl.ucla.edu
Author/Change controller: Adam Li adamli@icsl.ucla.edu IETF Audio/Video Transport Working Group
著者/変更コントローラ：アダム・リーadamli@icsl.ucla.edu IETFオーディオ/ビデオ輸送ワーキンググループ
Media Type Name: audio
メディアタイプ名：オーディオ
Media Subtype Name: EVRC0
メディアサブタイプ名：EVRC0
Required Parameters: none
必要なパラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: none This type 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 3558のセクション4.2で指定されたヘッダフリーパケットフォーマットを使用して、RTPを介しEVRC符号化データの転送のために定義されているなし。
Security considerations: See Section 14 "Security Considerations" of RFC 3558.
セキュリティに関する考慮事項：RFC 3558のセクション14「セキュリティの考慮事項」を参照してください。
Public specification: The EVRC vocoder is specified in 3GPP2 C.S0014. Transfer methods are specified in RFC 3558.
公開された仕様：EVRCボコーダは、3GPP2 C.S0014に指定されています。転送方法は、RFC 3558で指定されています。
Additional information: none
追加情報：なし
Intended usage: COMMON. It is expected that many VoIP applications (as well as mobile applications) will use this type.
意図している用法：COMMON。多くのVoIPアプリケーション（だけでなく、モバイルアプリケーション）は、このタイプを使用することが期待されます。
Person & email address to contact for further information: Adam Li adamli@icsl.ucla.edu
人と詳細のために連絡する電子メールアドレス：アダム・リーadamli@icsl.ucla.edu
Author/Change controller: Adam Li adamli@icsl.ucla.edu IETF Audio/Video Transport Working Group
著者/変更コントローラ：アダム・リーadamli@icsl.ucla.edu IETFオーディオ/ビデオ輸送ワーキンググループ
Media Type Name: audio
メディアタイプ名：オーディオ
Media Subtype Name: SMV
メディアサブタイプ名：SMV
Required Parameter: none
必要なパラメータ：なし
Optional parameters: The following parameters apply to RTP transfer only.
オプションのパラメータは以下のパラメータは、RTP転送にのみ適用されます。
ptime: Defined as usual for RTP audio (see RFC 2327).
PTIME：RTPオーディオ用にいつものように定義された（RFC 2327を参照してください）。
maxptime: The maximum amount of media which 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でなければなりません。
Encoding considerations: This type is defined for transfer of SMV-encoded data via RTP using the Interleaved/Bundled packet format specified in Section 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.
符号化の考慮事項：このタイプは、セクション4.1、6で指定されたインターリーブ/バンドルパケットフォーマットを使用して、RTPを介しSMV符号化データの転送用に定義され、RFC 3558. 7はまたで指定されたストレージ・フォーマットを使用して他の転送方法のために定義されていますRFC 3558のセクション11。
Security considerations: See Section 14 "Security Considerations" of RFC 3558.
セキュリティに関する考慮事項：RFC 3558のセクション14「セキュリティの考慮事項」を参照してください。
Public specification: The SMV vocoder is specified in 3GPP2 C.S0030-0 v2.0. Transfer methods are specified in RFC 3558.
公開された仕様：SMVボコーダは、3GPP2 C.S0030-0 v2.0の中に指定されています。転送方法は、RFC 3558で指定されています。
Additional information: The following information applies to storage format only.
追加情報：以下の情報は、保存形式にのみ適用されます。
Magic number: #!SMV\n (see Section 11 of RFC 3558) File extensions: smv, SMV Macintosh file type code: none Object identifier or OID: none
マジック番号：＃！SMV \ n個（RFC 3558のセクション11を参照）ファイル拡張子：SMV、SMV Macintoshファイルタイプコード：なしオブジェクト識別子またはOID：なし
Intended usage: COMMON. It is expected that many VoIP applications (as well as mobile applications) will use this type.
意図している用法：COMMON。多くのVoIPアプリケーション（だけでなく、モバイルアプリケーション）は、このタイプを使用することが期待されます。
Person & email address to contact for further information: Adam Li adamli@icsl.ucla.edu
人と詳細のために連絡する電子メールアドレス：アダム・リーadamli@icsl.ucla.edu
Author/Change controller: Adam Li adamli@icsl.ucla.edu IETF Audio/Video Transport Working Group
著者/変更コントローラ：アダム・リーadamli@icsl.ucla.edu IETFオーディオ/ビデオ輸送ワーキンググループ
Media Type Name: audio
メディアタイプ名：オーディオ
Media Subtype Name: SMV0
メディアサブタイプ名：SMV0
Required Parameter: none
必要なパラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: none This type is only defined for transfer of SMV-encoded data via RTP using the Header-Free packet format specified in Section 4.2 of RFC 3558.
符号化の考慮事項：このタイプのみRFC 3558のセクション4.2で指定されたヘッダフリーパケットフォーマットを使用して、RTPを介しSMV符号化データの転送のために定義されているなし。
Security considerations: See Section 14 "Security Considerations" of RFC 3558.
セキュリティに関する考慮事項：RFC 3558のセクション14「セキュリティの考慮事項」を参照してください。
Public specification: The SMV vocoder is specified in 3GPP2 C.S0030-0 v2.0. Transfer methods are specified in RFC 3558.
公開された仕様：SMVボコーダは、3GPP2 C.S0030-0 v2.0の中に指定されています。転送方法は、RFC 3558で指定されています。
Additional information: none
追加情報：なし
Intended usage: COMMON. It is expected that many VoIP applications (as well as mobile applications) will use this type.
意図している用法：COMMON。多くのVoIPアプリケーション（だけでなく、モバイルアプリケーション）は、このタイプを使用することが期待されます。
Person & email address to contact for further information: Adam Li adamli@icsl.ucla.edu
人と詳細のために連絡する電子メールアドレス：アダム・リーadamli@icsl.ucla.edu
Author/Change controller: Adam Li adamli@icsl.ucla.edu IETF Audio/Video Transport Working Group
著者/変更コントローラ：アダム・リーadamli@icsl.ucla.edu IETFオーディオ/ビデオ輸送ワーキンググループ
Please note that this section applies to the RTP transfer only.
このセクションでは、RTP転送にのみ適用されますのでご注意ください。
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [6], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the EVRC or EMV codec, the mapping is as follows:
MIMEメディアタイプの仕様で搬送される情報は、[6]、一般にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）内のフィールドに特定のマッピングを有します。 SDPは、EVRC又はEMVコーデックを使用するセッションを指定するために使用される場合、以下のように、マッピングは次のとおりです。
o The MIME type ("audio") goes in SDP "m=" as the media name.
O MIMEタイプ（「オーディオ」）は、メディア名としてSDP「m =」に進みます。
o The MIME subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name.
O（ペイロードフォーマット名）MIMEサブタイプは、符号化名としてSDPの「a = rtpmap」に進みます。
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
Oパラメータの "PTIME" と "maxptime" は、それぞれ、 "A = PTIME" と "A = maxptimeは" 属性SDPに行きます。
o The parameter "maxinterleave" goes in the SDP "a=fmtp" attribute by copying it directly from the MIME media type string as "maxinterleave=value".
Oパラメータ「maxinterleaveは」「maxinterleave =値」としてMIMEメディアタイプ文字列から直接コピーすることで、「=のfmtp」属性SDPになります。
Some examples of SDP session descriptions for EVRC and SMV encodings follow below.
EVRCとSMVエンコーディングのSDPセッション記述のいくつかの例を以下に従ってください。
Example of usage of EVRC:
EVRCの使用例：
m=audio 49120 RTP/AVP 97 a=rtpmap:97 EVRC/8000 a=fmtp:97 maxinterleave=2 a=maxptime:80
M =オーディオ49120 RTP / AVP 97 = rtpmap：97 EVRC / 8000 =のfmtp：97 maxinterleave = 2、A = maxptime：80
Example of usage of SMV
SMVの使用例
m=audio 49122 RTP/AVP 99 a=rtpmap:99 SMV0/8000 a=fmtp:99
M =オーディオ49122 RTP / AVP 99 = rtpmap：99：SMV0 / 8000 = 99のfmtp
Note that the payload format (encoding) names are commonly shown in upper case. MIME subtypes are commonly shown in lower case. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in MIME types and in the default mapping to the SDP a=fmtp attribute.
ペイロード形式（符号化）の名前は、一般的に大文字で示されていることに留意されたいです。 MIMEサブタイプは一般に小文字で示されています。これらの名前は、両方の場所で大文字と小文字を区別しません。同様に、パラメータ名は大文字と小文字を区別しないMIMEタイプおよびSDPのA =のfmtp属性にデフォルトマッピングの両方です。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [4], and any appropriate profile (for example [5]). This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations.
本明細書で定義されたペイロードフォーマットを使用して、RTPパケットは、RTP仕様[4]で説明したセキュリティ問題を受けることがあり、任意の適切なプロファイル（例えば[5]）。これは、メディアストリームの機密性は、暗号化によって達成されることを意味します。このペイロードフォーマットに使用されるデータ圧縮は、エンドツーエンドで適用されるので、二つの操作の間に競合がないので、暗号化は、圧縮後に行ってもよいです。
A potential denial-of-service threat exists for data encoding using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to become overloaded. However, the encodings covered in this document do not exhibit any significant non-uniformity.
潜在的なサービス拒否の脅威は、不均一な受信端計算負荷を有する圧縮技術を用いて、データ符号化のために存在します。攻撃者が復号及び過負荷になるために受信機を引き起こすのに複雑であるストリームに病理学的なデータグラムを注入することができます。しかし、本書で取り上げエンコーディングは、有意な不均一性を示しません。
As with any IP-based protocol, in some circumstances, a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [7] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it.
任意のIPベースのプロトコルと同様に、いくつかの状況では、受信機は、所望のまたは望ましくないのいずれかで、あまりに多くのパケットを受信することによって簡単にオーバーロードされてもよいです。ネットワーク層認証は、望ましくないソースからのパケットを破棄するために使用することができるが、認証自体の処理コストが高すぎるかもしれません。マルチキャスト環境では、特定の供給源の剪定は、IGMPの将来のバージョンで実装することができる[7]とマルチキャストルーティングプロトコルにおける受信機は、それに到達するために許可されているソースを選択できるようにします。
Interleaving may affect encryption. Depending on the used encryption scheme there may be restrictions on, for example, the time when keys can be changed. Specifically, the key change may need to occur at the boundary between interleave groups.
インターリーブは、暗号化に影響を与える可能性があります。使用される暗号化方式に応じて、上の制約があるかもしれない、例えば、キーを変更することができる時間。具体的には、キーの変更は、インタリーブグループ間の境界で発生する必要があるかもしれません。
As described above, the RTP packet format defined in this document is very flexible and designed to be usable by other frame-based vocoders.
上述したように、本文書で定義されたRTPパケットのフォーマットは非常に柔軟であり、他のフレームベースのボコーダによって使用できるように設計されました。
Additional vocoders using this format MUST have properties as described in Section 3.3.
3.3節で説明したように、このフォーマットを使用して追加のボコーダは、プロパティを持っていなければなりません。
For an eligible vocoder to use the payload format mechanisms defined in this document, a new RTP payload format document needs to be published as a standards track RFC. That document can simply refer to this document and then specify the following parameters:
対象とボコーダは、この文書で定義されたペイロードフォーマットのメカニズムを使用するには、新しいRTPペイロード形式の文書は、標準トラックRFCとして公開する必要があります。その文書は、単純に、このドキュメントを参照して、次のパラメータを指定できます。
o Define the unit used for RTP time stamp;
o Define the meaning of the Mode Request bits;
o Define corresponding codec data frame type values for ToC;
o Define the conversion procedure for vocoders output data frame;
o Define a magic number for storage format, and complete the
corresponding MIME registration.
The following authors have made significant contributions to this document: Adam H. Li, John D. Villasenor, Dong-Seek Park, Jeong-Hoon Park, Keith Miller, S. Craig Greer, David Leon, Nikolai Leung, Marcello Lioy, Kyle J. McKay, Magdalena L. Espelien, Randall Gellens, Tom Hiller, Peter J. McCann, Stinson S. Mathai, Michael D. Turner, Ajay Rajkumar, Dan Gal, Magnus Westerlund, Lars-Erik Jonsson, Greg Sherwood, and Thomas Zeng.
アダムH.リー、ジョン・D. Villasenor、ドン・シーク公園、チョン・フンパーク、キース・ミラー、S.クレイグ・グリア、デビッド・レオン、ニコライ・レオン、マルチェロLioy、カイルJ：以下の作者はこのドキュメントへの重要な貢献をしました。マッケイ、マグダレナL. Espelien、ランドールGellens、トム・ヒラー、ピーター・J.マッキャン、スティンソンS.マタイ、マイケル・D.ターナー、アジャイラジクマール、ダン・ギャル、マグヌスウェスター、ラース・エリックジョンソン、グレッグ・シャーウッド、とトーマス曽。
[1] 3GPP2 C.S0014, "Enhanced Variable Rate Codec, Speech Service Option 3 for Wideband Spread Spectrum Digital Systems", January 1997.
[1] 3GPP2 C.S0014を、1997年1月、「拡張可変レートコーデック、広帯域のための音声サービスオプション3は、スペクトラムデジタルシステムスプレッド」。
[2] 3GPP2 C.S0030-0 v2.0, "Selectable Mode Vocoder, Service Option for Wideband Spread Spectrum Communication Systems", May 2002.
[2] 3GPP2 C.S0030-0 v2.0のを、2002年5月、「選択可能なモードボコーダ、広帯域のためのサービスオプションは、スペクトラム拡散通信システムを」。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Schulzrinne, H., Casner, S., Jacobson, V. and R. Frederick, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[4] Schulzrinneと、H.、Casner、S.、ヤコブソン、V.およびR.フレデリック、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 3550、2003年7月。
[5] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
[5] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、RFC 3551、2003年7月。
[6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[6]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[7] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[7]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
Adam H. Li Image Communication Lab Electrical Engineering Department University of California Los Angeles, CA 90095 USA
アダムH.リーカリフォルニア州ロサンゼルスの写真通信研究所電気工学科大学、CA 90095 USA
Phone: +1 310 825 5178 EMail: adamli@icsl.ucla.edu
電話：+1 310 825 5178 Eメール：adamli@icsl.ucla.edu
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。