[要約] RFC 3558は、EVRCおよびSMVのためのRTPペイロード形式を定義しています。このRFCの目的は、可変ビットレートコーデックの効果的な伝送を可能にするための標準化と指針を提供することです。
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)
強化された可変レートコーデック（EVRC）および選択可能なモードボコーダー（SMV）のRTPペイロード形式
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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ペイロード形式について説明します。さまざまなアプリケーションシナリオに2つのサブフォーマットが指定されています。バンドル/インターリーブ形式が含まれており、音声品質に対するパケット損失の影響を減らし、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パケットにパケット化するための2つの方法が提供されています：インターリーブ/バンドルされた形式とゼロヘッダー形式。送信者は、ネットワーク条件、帯域幅の可用性、遅延要件、およびパケットロス許容範囲に基づいて、各アプリケーションシナリオに最適な形式を選択できます。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
第3世代パートナーシッププロジェクト2（3GPP2）は、CDMAアプリケーションの音声圧縮アルゴリズムを定義する2つの標準を公開しています：EVRC [1]およびSMV [2]。EVRCは現在、数百万の第1世代および第2世代の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.
強化された可変レートコーデック（EVRC）[1]は、8000 Hzの各20ミリ秒、16ビットサンプリングされた音声入力を3つの異なるサイズのいずれかで出力フレームに圧縮します：レート1（171ビット）、レート1/2（80ビット）、またはレート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.
Codecは、入力音声と現在の動作モードの分析に基づいて出力フレームレートを選択します（通常またはいくつかの削減されたレートモードのいずれか）。典型的な音声パターンの場合、これにより、通常モードでは平均出力が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.
選択可能なモードボコーダー（SMV）[2]は、8000 Hzの各20ミリ秒、4つの異なるサイズの1つの出力フレームに16ビットサンプリングされた音声入力を圧縮します：レート1（171ビット）、レート1/2（80ビット）、レート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 Codecは、入力音声と現在の動作モードの分析に基づいて出力フレームレートを選択します。典型的な音声パターンの場合、これにより、2つの方法での会話でモード0の平均出力が4.2キロビット/秒になります（リスニング中に約50％のアクティブな音声時間と80％が50％）、その他の低いレートモードでは低くなります。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.
o コーデックはフレームベースです。o空白と消去フレームがサポートされています。oレートの総数は17未満です。o最大フルレートフレームは、この特定の形式を使用して単一のRTPパケットで輸送できます。
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:
この形式は、パケットごとに1つ以上のボコーダーフレームを送信するために使用されます。インターリーブまたはバンドルを使用する場合があります。この形式の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 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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の2番目のユニットの1/8000にあります。このパケット形式を使用する他のボコーダーについては、タイムスタンプユニットを明示的に定義する必要があります。Mビットは、該当するRTPプロファイル、たとえば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ビットパケットに存在するTOCフィールド（およびボコーダーフレーム）の数は、フレームカウントフィールドと1の値です。ゼロの値は、パケットに1つのTOCフィールドが含まれていることを示し、31の値はパケットに32のTOCフィールドが含まれていることを示します。
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エントリがあります。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.
ヘッダーフリーのパケット形式は、帯域幅の効率を最大限に活用し、遅延が低くなるように設計されています。各ヘッダーフリーフォーマットパケットで1つのコーデックデータフレームのみを送信できます。ペイロードヘッダーフィールド（LLL、NNN、MMM、カウント）もTOCエントリも存在しません。データフレームのコーデックレートは、各ヘッダーフリーパケットに1つのコーデックデータフレームしかないため、コーデックデータフレームの長さから決定できます。
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/ボコーダーパケット形式にRTPヘッダーフィールドの使用は、インターリーブ/バンドルされたRTP/ボコーダーパケット形式のセクション4.1で説明されていると同じです。コーデックデータフレームの詳細な形式は、セクション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 +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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）エントリがあります。TOCエントリは、コーデックフレームのレートを示します。（ヘッダーフリーのパケットには、TOCフィールドが必要です。）
Each ToC entry is occupies four bits. The format of the bits is indicated below:
各TOCエントリは4ビットを占めています。ビットの形式を以下に示します。
0 1 2 3
+-+-+-+-+
|fr type|
+-+-+-+-+
Frame Type: 4 bits The frame type indicates the type of the corresponding codec data frame in the RTP packet.
フレームタイプ：4ビットフレームタイプは、RTPパケットの対応するコーデックデータフレームのタイプを示します。
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、レート1/2、レート1/4、レート1/8）は、コーデックデータフレームのオクテット1の最も重要なビット（インターネットビット0）に配置されます。ビットは、最初のオクテットの2番目に重要なビットに配置され、最初のオクテットの3番目に重要なビットで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.
コーデックデータフレームの最後のオクテットの残りの未使用のビットは、ゼロに設定する必要があります。EVRCおよびSMVでは、これはレート1/2（80ビット）、レート1/4（40ビット、SMVのみ）、レート1/8フレーム（16ビット）として、レート1フレーム（171ビット）にのみ適用できます。オクテットの全部に正確に収まります。
Following is a detailed listing showing a Rate 1 EVRC/SMV codec output frame converted into a codec data frame: 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.
以下は、レート1 EVRC/SMVコーデック出力フレームがコーデックデータフレームに変換されたことを示す詳細なリストです。EVRC/SMVコーデックレート1フレームのコーデックデータフレームは22オクテットの長さです。EVRC/SMVコーデックレート1フレームからのビット1〜171は、示されているように配置され、「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| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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):
番号0..n、バンドリング値B（カウントフィールドと1の値）、およびn = b *（l 1）-1、bundling値B（カウントフィールドと1の値）の番号が付けられたタイム順序の出力フレームが与えられた場合出力フレームは、次のようにRTPパケットに配置されます（各RTPパケットに対してLLLとNNNの値が示されています）：
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
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
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
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で識別されたオプションのMaxPtime RTPモードパラメーターを使用して、単一のRTPパケットで処理できるCodecデータフレームの最大数（つまり、許容可能な最大バンドル値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値）を信号する場合があります。
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は、セッションの最初のセットアップで交換されます。1対1のセッションでは、送信者はこれらの値が受信機に設定されていることを尊重する必要があり、受信機が処理できるものよりも多くのパケットをインターリーブ/バンドルしてはなりません。これにより、受信者は、そのセッションで使用されるすべてのインターリーブ/バンドルに十分な既知の量のバッファースペースを割り当てることができます。セッション中、送信者はバンドル値またはインターリーブの長さを減らすことができます（レシーバーではバッファスペースが少なくなるようになります）が、受信機によって設定された最大値を超えることはありません。これにより、受信者がセッションの途中でより多くのバッファースペースを割り当てる必要があるが、そうすることができない状況を防ぎます。
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（セクション12を参照）で示されるよりも、単一のRTPパケットでコーデックデータフレームをさらにバンドルしてはなりません。
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パケットのタイムスタンプが1つしかないため、インターリーブグループ内で使用される沈黙抑制は、レシーバー側でスピーチを再構築するときに曖昧さを引き起こすため、禁止されます。
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パケットが与えられた場合、インターリーブグループは、このRTPパケットおよびS-N MOD 65536のシーケンス番号を備えた他のRTPパケットで構成されています。s-n l mod 65536インクルーシブ。言い換えれば、インターリーブグループは常に、シーケンシャルシーケンス番号を持つ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で説明したように、コーデックデータフレームのバンドルは、0に設定されたインターリーブオクテットのLLL値を使用した特別な削減ケースです。
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）が0であるため、複数のデータフレームがパケットに連続して含まれることを示しています。はるかにシンプルなプロセス。
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（セクション12を参照）で示されるよりも、単一のRTPパケットでコーデックデータフレームをさらにバンドルしてはなりません。
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.
このペイロード形式でカバーされているボコーダーは、フレームが利用できない場合の表示として消去フレームをサポートします。消去フレームは通常、レシーバーによって内部的に使用され、欠落しているフレームごとに正確に1つのフレームタイムで音声デコーダーの状態を前進させます。パケットシーケンス番号、タイムスタンプ、および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パケットを受信する場合、受信者はTOCフィールドの有効性を確認し、パケットの長さをTOCフィールドで示されるものと一致させる必要があります。無効性または不一致が検出された場合は、音声品質の潜在的な深刻な分解を避けるために、受け取ったパケットを破棄することをお勧めします。破棄されたパケットは、失われたパケットと同じ手順に従って扱われ、破棄されたデータは消去フレームに置き換えられます。
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.
LLLまたはNNNフィールドの無効な値を持つRTPパケットを受け取ったら、セクション8で説明されているように、消去フレームを生成する目的で、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パケットの端からコーデックデータフレームを破棄するか、消しているコーデックデータフレームをパケットの端に追加して、Aを製造することができます。予想されるバンドル値にパケットを置き換えます。代わりに、受信者は、インターリーブグループ全体を破棄することを選択できます。
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.
ここで、インターリーブグループのパケットNが、そのパケットのフレームx 1が必要になる前に到着すると仮定します。受信機は、消去フレームを置き換えるのではなく、新しく受信したパケットNのフレームx 1を使用する必要があります。言い換えれば、インターリーブされた音声を再構築するために初めてパケット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パケットの有効な値に設定されている場合、ノードBがオーディオエンコーダーの要求されたエンコードモードに変更することは、ノードからのRTPストリームのビットレートに変更するようにリクエストです。BからノードAからA。ノードがこのフィールドを値に設定すると、要求されたモードが異なるまで、後続のパケットでフィールドを同じ値に設定し続ける必要があります。この設計は、モード要求を運ぶパケットの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コーデックの場合、EVRCコーデック仕様の表2.2.1.2-1および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 Codecの場合、SMV Codec仕様の表2.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 0x53 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つのOctetに拡張され、各コーデックデータフレームのプレフィックスを備えた連続した順序で保存されます。TOCフィールドは、オクテットの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.
EVRCおよびSMVコーデックのMIME名は、対象となるすべてのボコーダーがVoice-Over-IPアプリケーションに広く使用されると予想されるため、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ミリ秒）の期間の倍数である必要があります。信号がない場合、デフォルトの最大値値は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.
エンコーディングの考慮事項：このタイプは、RFC 3558のセクション4.1、6、および7で指定されたインターリーブ/バンドルパケット形式を使用して、RTPを介してEVRCエンコードデータを転送するために定義されます。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
Intended usage: COMMON. It is expected that many VoIP applications (as well as mobile applications) will use this type.
意図された使用法：共通。多くのVoIPアプリケーション（およびモバイルアプリケーション）がこのタイプを使用することが予想されます。
Person & email address to contact for further information: Adam Li adamli@icsl.ucla.edu
詳細については、連絡先の個人とメールアドレス：adam li adamli@icsl.ucla.edu
Author/Change controller: Adam Li adamli@icsl.ucla.edu IETF Audio/Video Transport Working Group
著者/変更コントローラー：adam li 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.
意図された使用法：共通。多くのVoIPアプリケーション（およびモバイルアプリケーション）がこのタイプを使用することが予想されます。
Person & email address to contact for further information: Adam Li adamli@icsl.ucla.edu
詳細については、連絡先の個人とメールアドレス：adam li adamli@icsl.ucla.edu
Author/Change controller: Adam Li adamli@icsl.ucla.edu IETF Audio/Video Transport Working Group
著者/変更コントローラー：adam li 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ミリ秒）の期間の倍数である必要があります。信号がない場合、デフォルトの最大値値は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.
エンコーディングの考慮事項：このタイプは、RFC 3558のセクション4.1、6、および7で指定されたインターリーブ/バンドルパケット形式を使用して、RTPを介したSMVエンコードデータの転送に対して定義されています。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
Intended usage: COMMON. It is expected that many VoIP applications (as well as mobile applications) will use this type.
意図された使用法：共通。多くのVoIPアプリケーション（およびモバイルアプリケーション）がこのタイプを使用することが予想されます。
Person & email address to contact for further information: Adam Li adamli@icsl.ucla.edu
詳細については、連絡先の個人とメールアドレス：adam li adamli@icsl.ucla.edu
Author/Change controller: Adam Li adamli@icsl.ucla.edu IETF Audio/Video Transport Working Group
著者/変更コントローラー：adam li 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.
意図された使用法：共通。多くのVoIPアプリケーション（およびモバイルアプリケーション）がこのタイプを使用することが予想されます。
Person & email address to contact for further information: Adam Li adamli@icsl.ucla.edu
詳細については、連絡先の個人とメールアドレス：adam li adamli@icsl.ucla.edu
Author/Change controller: Adam Li adamli@icsl.ucla.edu IETF Audio/Video Transport Working Group
著者/変更コントローラー：adam li 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メディアタイプの仕様に掲載されている情報には、セッション説明プロトコル（SDP）[6]のフィールドへの特定のマッピングがあります。これは、RTPセッションを説明するために一般的に使用されます。SDPがEVRCまたはEMVコーデックを使用したセッションを指定するために使用される場合、マッピングは次のとおりです。
o The MIME type ("audio") goes in SDP "m=" as the media name.
o MIMEタイプ（ "Audio"）は、メディア名として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」は、それぞれSDP「A = PTIME」と「A = MaxPtime」属性に移動します。
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」は、MIMEメディアタイプの文字列から「MaxInterLeave = value」として直接コピーすることにより、SDP「A = FMTP」属性になります。
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
Example of usage of SMV
SMVの使用例
m=audio 49122 RTP/AVP 99
a=rtpmap:99 SMV0/8000
a=fmtp:99
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]など）で説明されています。これは、メディアストリームの機密性が暗号化によって達成されることを意味します。このペイロード形式で使用されるデータ圧縮はエンドツーエンドで適用されるため、圧縮後に暗号化が実行される可能性があるため、2つの操作間に競合がありません。
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.
o RTPタイムスタンプに使用されるユニットを定義します。oモード要求ビットの意味を定義します。o TOCの対応するコーデックデータフレームタイプ値を定義します。oボコーダー出力データフレームの変換手順を定義します。oストレージ形式のマジック番号を定義し、対応するMIME登録を完了します。
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・ヴィルセナー、ドン・シーク・パーク、ジョン・ホーン・パーク、キース・ミラー、S。マッケイ、マグダレナL.エスペリエン、ランドールゲレンズ、トムヒラー、ピーター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、「強化された可変レートコーデック、広帯域スプレッドスペクトルデジタルシステム用の音声サービスオプション3」、1997年1月。
[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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.、Jacobson、V。、およびR. Frederick、「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] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[7] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[7] Deering、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
Adam H. Li Image Communication Lab Electrical Engineering Depecial of California University、Los Angeles、CA 90095 USA
Phone: +1 310 825 5178
EMail: adamli@icsl.ucla.edu
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。