Network Working Group Q. Xie, Ed.
Request for Comments: 3557 Motorola, Inc.
Category: Standards Track July 2003
RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding
欧州電気通信標準化機構（ETSI）のためのRTPペイロードフォーマット欧州規格ES 201 108分散型音声認識エンコーディング
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 specifies an RTP payload format for encapsulating European Telecommunications Standards Institute (ETSI) European Standard (ES) 201 108 front-end signal processing feature streams for distributed speech recognition (DSR) systems.
この文書は、欧州電気通信標準化機構（ETSI）欧州規格（ES）は、分散音声認識のための201 108フロントエンド信号処理機能ストリーム（DSR）システムをカプセル化するためのRTPペイロードフォーマットを指定します。
Table of Contents
目次
1. Conventions and Acronyms . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. ETSI ES 201 108 DSR Front-end Codec. . . . . . . . . . . 3
2.2. Typical Scenarios for Using DSR Payload Format . . . . . 4
3. ES 201 108 DSR RTP Payload Format. . . . . . . . . . . . . . . 5
3.1. Consideration on Number of FPs in Each RTP Packet. . . . 6
3.2. Support for Discontinuous Transmission . . . . . . . . . 6
4. Frame Pair Formats . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Format of Speech and Non-speech FPs. . . . . . . . . . . 7
4.2. Format of Null FP. . . . . . . . . . . . . . . . . . . . 8
4.3. RTP header usage . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 9
5.1. Mapping MIME Parameters into SDP . . . . . . . . . . . . 10
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 11
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
10. IPR Notices. . . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
12. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 14
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The following acronyms are used in this document:
以下の頭字語は、本書で使用されています。
DSR - Distributed Speech Recognition
DSR - 分散型音声認識
ETSI - the European Telecommunications Standards Institute
ETSI - 欧州電気通信標準化協会
FP - Frame Pair
FP - フレームペア
DTX - Discontinuous Transmission
DTX - 不連続送信
Motivated by technology advances in the field of speech recognition, voice interfaces to services (such as airline information systems, unified messaging) are becoming more prevalent. In parallel, the popularity of mobile devices has also increased dramatically.
音声認識の分野における技術の進歩によって動機付け、（例えば航空会社情報・システム、ユニファイドメッセージングなど）のサービスへの音声インタフェースは、より一般的になってきています。並行して、モバイルデバイスの普及も飛躍的に増加しています。
However, the voice codecs typically employed in mobile devices were designed to optimize audible voice quality and not speech recognition accuracy, and using these codecs with speech recognizers can result in poor recognition performance. For systems that can be accessed from heterogeneous networks using multiple speech codecs, recognition system designers are further challenged to accommodate the characteristics of these differences in a robust manner. Channel errors and lost data packets in these networks result in further degradation of the speech signal.
しかし、一般的にモバイル機器に採用の音声コーデックは、可聴音声品質ではなく、音声認識の精度を最適化するように設計された、および音声認識とこれらのコーデックを使用すると、貧弱な認識性能をもたらす可能性があります。複数の音声コーデックを使用して、異種のネットワークからアクセスすることができるシステムの場合、認識システムの設計者は、さらに堅牢な方法でこれらの差の特性に適応するように挑戦されています。これらのネットワークにおけるチャネルエラーと失われたデータパケットは、音声信号のさらなる劣化につながります。
In traditional systems as described above, the entire speech recognizer lies on the server. It is forced to use incoming speech in whatever condition it arrives after the network decodes the vocoded speech. To address this problem, we use a distributed speech recognition (DSR) architecture. In such a system, the remote device acts as a thin client, also known as the front-end, in communication with a speech recognition server, also called a speech engine. The remote device processes the speech, compresses the data, and adds error protection to the bitstream in a manner optimal for speech recognition. The speech engine then uses this representation directly, minimizing the signal processing necessary and benefiting from enhanced error concealment.
上記のように従来のシステムでは、全体の音声認識は、サーバー上にあります。ネットワークがボコーダスピーチをデコードした後、それが到着したどんな状態で入力音声を使用するように強制されます。この問題に対処するために、我々は分散型音声認識（DSR）アーキテクチャを使用しています。このようなシステムでは、遠隔デバイスはまた、音声エンジンと呼ばれ、また、音声認識サーバと通信して、フロントエンドとして知られるシンクライアントとして動作します。遠隔装置は、音声を処理し、データを圧縮し、音声認識のための方法を最適にビットストリームにエラー保護を追加します。音声エンジンは、信号処理が必要最小限に抑え、拡張エラー隠蔽の恩恵を受け、直接この表現を使用します。
To achieve interoperability with different client devices and speech engines, a common format is needed. Within the "Aurora" DSR working group of the European Telecommunications Standards Institute (ETSI), a payload has been defined and was published as a standard [ES201108] in February 2000.
異なるクライアントデバイスと音声エンジンとの相互運用性を実現するために、共通のフォーマットが必要です。欧州電気通信標準化機構（ETSI）の「オーロラ」DSRワーキンググループ内では、ペイロードは定義されており、2000年2月に標準[ES201108]として公開されました。
For voice dialogues between a caller and a voice service, low latency is a high priority along with accurate speech recognition. While jitter in the speech recognizer input is not particularly important, many issues related to speech interaction over an IP-based connection are still relevant. Therefore, it is desirable to use the DSR payload in an RTP-based session.
呼び出し元と音声サービス間の音声対話のために、低レイテンシは、正確な音声認識とともに、高い優先度です。音声認識入力のジッタが特に重要ではありませんが、IPベースの接続を介して音声の相互作用に関連する多くの問題がまだ関連しています。したがって、RTPベースのセッションでDSRペイロードを使用することが望ましいです。
The ETSI Standard ES 201 108 for DSR [ES201108] defines a signal processing front-end and compression scheme for speech input to a speech recognition system. Some relevant characteristics of this ETSI DSR front-end codec are summarized below.
【ES201108] DSR用のETSI規格ES 201 108は、音声認識システムへの音声入力のための信号処理フロントエンドと圧縮方式を定義します。このETSI DSRフロントエンドのコーデックの関連するいくつかの特徴を以下にまとめます。
The coding algorithm, a standard mel-cepstral technique common to many speech recognition systems, supports three raw sampling rates: 8 kHz, 11 kHz, and 16 kHz. The mel-cepstral calculation is a frame-based scheme that produces an output vector every 10 ms.
8 kHzの、11 kHzの、および16 kHzの：符号化アルゴリズム、多くの音声認識システムに共通する標準メルケプストラム技術は、3つの生のサンプリングレートをサポートしています。メルケプストラム計算は、出力ベクトルを10ms毎に生成するフレームベースの方式です。
After calculation of the mel-cepstral representation, the representation is first quantized via split-vector quantization to reduce the data rate of the encoded stream. Then, the quantized vectors from two consecutive frames are put into an FP, as described in more detail in Section 4.1.
メルケプストラム表現の計算後、表示は、第1の符号化ストリームのデータレートを低減するために分割ベクトル量子化を介して量子化されます。セクション4.1で詳細に説明するように、その後、2つの連続するフレームからの量子化されたベクターは、FPに入れられます。
The diagrams in Figure 1 show some typical use scenarios of the ES 201 108 DSR RTP payload format.
図1のショーの図ES 201 108 DSR RTPペイロードフォーマットのいくつかの典型的な使用シナリオ。
+--------+ +----------+
|IP USER | IP/UDP/RTP/DSR |IP SPEECH |
|TERMINAL|-------------------->| ENGINE |
| | | |
+--------+ +----------+
a) IP user terminal to IP speech engine
IP音声エンジンへのa）のIPユーザー端末
+--------+ DSR over +-------+ +----------+
| Non-IP | Circuit link | | IP/UDP/RTP/DSR |IP SPEECH |
| USER |:::::::::::::::>|GATEWAY|--------------->| ENGINE |
|TERMINAL| ETSI payload | | | |
+--------+ format +-------+ +----------+
b) non-IP user terminal to IP speech engine via a gateway
ゲートウェイを介してIP音声エンジンB）非IPユーザ端末
+--------+ +-------+ DSR over +----------+
|IP USER | IP/UDP/RTP/DSR | | circuit link | Non-IP |
|TERMINAL|----------------->|GATEWAY|::::::::::::::::>| SPEECH |
| | | | ETSI payload | ENGINE |
+--------+ +-------+ format +----------+
c) IP user terminal to non-IP speech engine via a gateway
ゲートウェイを介して非IP音声エンジンのC）IPユーザ端末
Figure 1: Typical Scenarios for Using DSR Payload Format.
図1：DSRペイロードフォーマットを使用するための一般的なシナリオ。
For the different scenarios in Figure 1, the speech recognizer always resides in the speech engine. A DSR front-end encoder inside the User Terminal performs front-end speech processing and sends the resultant data to the speech engine in the form of "frame pairs" (FPs). Each FP contains two sets of encoded speech vectors representing 20ms of original speech.
図1の異なるシナリオのために、音声認識は常に音声エンジンに存在します。ユーザ端末内部DSRフロントエンドエンコーダは、フロントエンドの音声処理を行い、「フレームペア」（FPS）の形で音声エンジンに得られたデータを送信します。各FPは、元の音声の20ミリ秒を表す符号化された音声ベクトルの二組を含んでいます。
An ES 201 108 DSR RTP payload datagram consists of a standard RTP header [RFC3550] followed by a DSR payload. The DSR payload itself is formed by concatenating a series of ES 201 108 DSR FPs (defined in Section 4).
ES 201 108 DSR RTPペイロードデータグラムはDSRペイロードが続く標準のRTPヘッダー[RFC3550]から成ります。 DSRペイロード自体は（セクション4で定義される）ES 201の108のDSRのFPのシリーズを連結することによって形成されています。
FPs are always packed bit-contiguously into the payload octets beginning with the most significant bit. For ES 201 108 front-end, the size of each FP is 96 bits or 12 octets (see Sections 4.1 and 4.2). This ensures that a DSR payload will always end on an octet boundary.
FPSが常に最上位ビットから始まるペイロードオクテットにビット連続してパックされています。 ES 201 108フロントエンドのために、各FPの大きさは96ビットまたは12個のオクテット（セクション4.1および4.2を参照）です。これは、DSRペイロードが常にオクテット境界で終了するようになります。
The following example shows a DSR RTP datagram carrying a DSR payload containing three 96-bit-long FPs (bit 0 is the MSB):
以下の例では、3つの96ビット長のFP（ビット0はMSBである）を含有DSRペイロードを運ぶDSR 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 in [RFC3550] / \ \ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | + + | FP #1 (96 bits) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | FP #2 (96 bits) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | FP #3 (96 bits) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - [RFC3550] / \ \ + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = +で+ \ \ / RTPヘッダ= + = + = + = + = + = + = + = + = + = + = + = + = + = + | | + + | FP＃1（96ビット）| + + | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | + + | FP＃2（96ビット）| + + | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | + + | FP＃3（96ビット）| + + | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 2. An example of an ES 201 108 DSR RTP payload.
図2. ES 201 108 DSR RTPペイロードの一例。
The number of FPs per payload packet should be determined by the latency and bandwidth requirements of the DSR application using this payload format. In particular, using a smaller number of FPs per payload packet in a session will result in lowered bandwidth efficiency due to the RTP/UDP/IP header overhead, while using a larger number of FPs per packet will cause longer end-to-end delay and hence increased recognition latency. Furthermore, carrying a larger number of FPs per packet will increase the possibility of catastrophic packet loss; the loss of a large number of consecutive FPs is a situation most speech recognizers have difficulty dealing with.
ペイロードパケットあたりのFPの数は、このペイロードフォーマットを使用して、DSRアプリケーションの待ち時間および帯域幅の要件によって決定されるべきです。パケットあたりのFPのより多くを使用するより長いエンドツーエンド遅延を引き起こすであろうしながら具体的には、セッションにおいてペイロードパケットあたりのFPの小さな数を使用すること、によりRTP / UDP / IPヘッダのオーバーヘッドを下げ、帯域幅効率をもたらすであろうひいては認識の待ち時間を増加させました。また、パケットあたりのFPの多数を保有する壊滅的なパケット損失の可能性を増加させます。連続でのFPの多数の損失は、ほとんどの音声認識が困難に対処を持つ状況です。
It is therefore RECOMMENDED that the number of FPs per DSR payload packet be minimized, subject to meeting the application's requirements on network bandwidth efficiency. RTP header compression techniques, such as those defined in [RFC2508] and [RFC3095], should be considered to improve network bandwidth efficiency.
したがって、ネットワーク帯域幅の効率上のアプリケーションの要件を満たすことを条件として、DSRペイロードパケットあたりのFPの数が最小化されることが推奨されます。このような[RFC2508]及び[RFC3095]で定義されたもののようなRTPヘッダ圧縮技術は、ネットワーク帯域幅の効率を改善するために考慮されるべきです。
The DSR RTP payloads may be used to support discontinuous transmission (DTX) of speech, which allows that DSR FPs are sent only when speech has been detected at the terminal equipment.
DSR RTPペイロードは、音声が端末装置で検出された場合にのみ、DSRのFPが送信されることを可能にする音声の不連続送信（DTX）をサポートするために使用されてもよいです。
In DTX a set of DSR frames coding an unbroken speech segment transmitted from the terminal to the server is called a transmission segment. A DSR frame inside such a transmission segment can be either a speech frame or a non-speech frame, depending on the nature of the section of the speech signal it represents.
DTXにDSRのセットは、送信セグメントと呼ばれるサーバに、端末から送信された切れ目のない音声セグメントを符号化フレーム。このような伝送セグメント内のDSRフレームは、それが表す音声信号の部分の性質に応じて、音声フレームまたは非音声フレームのいずれかとすることができます。
The end of a transmission segment is determined at the sending end equipment when the number of consecutive non-speech frames exceeds a pre-set threshold, called the hangover time. A typical value used for the hangover time is 1.5 seconds.
伝送セグメントの端部は、連続非音声フレームの数が予め設定された閾値を超えた場合に、送信側装置で決定された二日酔い時間と呼ばれます。二日酔いの時のために使用される典型的な値は1.5秒です。
After all FPs in a transmission segment are sent, the front-end SHOULD indicate the end of the current transmission segment by sending one or more Null FPs (defined in Section 4.2).
全てのFP後の送信セグメントにフロントエンドは1つまたは複数のヌルのFP（セクション4.2で定義されている）を送信することによって、現在の送信セグメントの終わりを示す必要があり、送信されます。
The following mel-cepstral frame MUST be used, as defined in [ES201108]:
【ES201108]で定義されるように、次のメルケプストラムフレームは、使用する必要があります。
As defined in [ES201108], pairs of the quantized 10ms mel-cepstral frames MUST be grouped together and protected with a 4-bit CRC, forming a 92-bit long FP:
【ES201108]で定義されるように、量子化された10ミリ秒のメルケプストラムフレームのペアは92ビット長FPを形成し、一緒にグループ化され、4ビットのCRCで保護されなければなりません。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame #1 (44 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Frame #2 (44 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | | CRC |0|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |フレーム＃1（44ビット）| + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | |フレーム＃2（44ビット）| + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + | | CRC | 0 | 0 | 0 | 0 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
The length of each frame is 44 bits representing 10ms of voice. The following mel-cepstral frame formats MUST be used when forming an FP:
各フレームの長さは、音声の10ミリ秒を表す44ビットです。 FPを形成する際に、次のメルケプストラムフレームフォーマットを使用する必要があります。
Frame #1 in FP:
===============
(MSB) (LSB)
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
: idx(2,3) | idx(0,1) | Octet 1
+-----+-----+-----+-----+-----+-----+-----+-----+
: idx(4,5) | idx(2,3) (cont) : Octet 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| idx(6,7) |idx(4,5)(cont) Octet 3
+-----+-----+-----+-----+-----+-----+-----+-----+
idx(10,11) | idx(8,9) | Octet 4
+-----+-----+-----+-----+-----+-----+-----+-----+
: idx(12,13) | idx(10,11) (cont) : Octet 5
+-----+-----+-----+-----+-----+-----+-----+-----+
| idx(12,13) (cont) : Octet 6/1
+-----+-----+-----+-----+
Frame #2 in FP:
===============
(MSB) (LSB)
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+
: idx(0,1) | Octet 6/2
+-----+-----+-----+-----+-----+-----+-----+-----+
| idx(2,3) |idx(0,1)(cont) Octet 7
+-----+-----+-----+-----+-----+-----+-----+-----+
: idx(6,7) | idx(4,5) | Octet 8
+-----+-----+-----+-----+-----+-----+-----+-----+
: idx(8,9) | idx(6,7) (cont) : Octet 9
+-----+-----+-----+-----+-----+-----+-----+-----+
| idx(10,11) |idx(8,9)(cont) Octet 10
+-----+-----+-----+-----+-----+-----+-----+-----+
| idx(12,13) | Octet 11
+-----+-----+-----+-----+-----+-----+-----+-----+
Therefore, each FP represents 20ms of original speech. Note, as shown above, each FP MUST be padded with 4 zeros to the end in order to make it aligned to the 32-bit word boundary. This makes the size of an FP 96 bits, or 12 octets. Note, this padding is separate from padding indicated by the P bit in the RTP header.
したがって、各FPは、元の音声の20ミリ秒を表します。上記のように、注意し、各FPは、32ビットワード境界に整列させるために最後まで4ゼロでパディングされなければなりません。これは、FP 96ビット、または12オクテットのサイズになります。このパディングは、RTPヘッダ内のPビットによって示さパディングから分離され、注意してください。
The 4-bit CRC MUST be calculated using the formula defined in 6.2.4 in [ES201108]. The definition of the indices and the determination of their value are also described in [ES201108].
4ビットのCRCは[ES201108]で6.2.4で定義された式を用いて計算しなければなりません。指標の定義とその値の決意も[ES201108]に記載されています。
A Null FP for the ES 201 108 front-end codec is defined by setting the content of the first and second frame in the FP to null (i.e., filling the first 88 bits of the FP with 0's). The 4-bit CRC MUST be calculated the same way as described in 6.2.4 in [ES201108], and 4 zeros MUST be padded to the end of the Null FP to make it 32-bit word aligned.
ES 201 108フロントエンドコーデックのヌルFP（すなわち、0とFPの最初の88ビットを埋める）nullにFPに第一及び第二のフレームの内容を設定することによって定義されます。 【ES201108]において6.2.4に記載したように4ビットのCRCは、同一の方法で計算しなければならない、と4つのゼロは、32ビット・ワード整列するためにヌルFPの終わりにパディングされなければなりません。
The format of the RTP header is specified in [RFC3550]. This payload format uses the fields of the header in a manner consistent with that specification.
RTPヘッダのフォーマットは、[RFC3550]で指定されています。このペイロードフォーマットは、その仕様と一致する方法で、ヘッダのフィールドを使用します。
The RTP timestamp corresponds to the sampling instant of the first sample encoded for the first FP in the packet. The timestamp clock frequency is the same as the sampling frequency, so the timestamp unit is in samples.
RTPタイムスタンプは、パケットの最初のFPのために符号化された第1のサンプルのサンプリング時点に対応します。タイムスタンプユニットがサンプルにあるように、タイムスタンプのクロック周波数は、サンプリング周波数と同じです。
As defined by ES 201 108 front-end codec, the duration of one FP is 20 ms, corresponding to 160, 220, or 320 encoded samples with sampling rate of 8, 11, or 16 kHz being used at the front-end, respectively. Thus, the timestamp is increased by 160, 220, or 320 for each consecutive FP, respectively.
ES 201 108フロントエンドコーデックによって定義されたように、一FPの持続時間は、それぞれ、フロントエンドで使用されて160、220、または320にサンプリング8の速度、11、または16キロヘルツで符号化されたサンプルに対応する、20ミリ秒であります。従って、タイムスタンプは、それぞれ、各連続FP 160、220、または320だけ増加されます。
The DSR payload for ES 201 108 front-end codes is always an integral number of octets. If additional padding is required for some other purpose, then the P bit in the RTP in the header may be set and padding appended as specified in [RFC3550].
ES 201 108フロントエンドコードのDSRペイロードは常にオクテットの整数です。追加のパディングが他の目的のために必要とされる場合には、ヘッダ内のRTPにおけるPビットがセットされてもよく、[RFC3550]で指定されるようにパディング付加します。
The RTP header marker bit (M) should be set following the general rules defined in [RFC3551].
RTPヘッダのマーカービット（M）は[RFC3551]で定義された一般的なルールに従って設定されるべきです。
The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile under which this payload format is being used will assign a payload type for this encoding or specify that the payload type is to be bound dynamically.
この新しいパケットフォーマットのためのRTPペイロードタイプの課題は、この文書の範囲外であり、ここで指定されることはありません。なお、このペイロード・フォーマットが使用されている下RTPプロファイルが、この符号化のためのペイロードタイプを割り当てるか、ペイロードタイプを動的に結合されるように指定することが期待されます。
One new MIME subtype registration is required for this payload type, as defined below.
以下に定義するように、1件の新しいMIMEサブタイプの登録は、このペイロードタイプのために必要とされます。
This section also defines the optional parameters that may be used to describe a DSR session. The parameters are defined here as part of the MIME subtype registration. A mapping of the parameters into the Session Description Protocol (SDP) [RFC2327] is also provided in 5.1 for those applications that use SDP.
このセクションでは、DSRセッションを記述するために使用することができるオプションのパラメータを定義します。パラメータは、MIMEサブタイプ登録の一部としてここで定義されています。セッション記述プロトコル（SDP）[RFC2327]にパラメータのマッピングは、また、SDPを使用するアプリケーションのために5.1で提供されます。
Media Type name: audio
メディアタイプ名：オーディオ
Media subtype name: dsr-es201108
メディアサブタイプ名：DSR-es201108
Required parameters: none
必須パラメータ：なし
Optional parameters:
オプションのパラメータ：
rate: Indicates the sample rate of the speech. Valid values include: 8000, 11000, and 16000. If this parameter is not present, 8000 sample rate is assumed.
レート：音声のサンプルレートを示します。有効な値は次のとおりです。8000、11000、および16000をこのパラメータが存在しない場合、8000サンプル・レートが想定されます。
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 frame pair size (i.e., one FP <-> 20ms).
maxptime：各パケットにカプセル化することができる媒体の最大量は、ミリ秒単位の時間として表さ。時間は、パケット内のメディアの存在を表す時間の合計として計算されなければなりません。時間はフレーム対サイズ（< - > 20ミリ秒すなわち1 FP）の倍数でなければなりません。
If this parameter is not present, maxptime is assumed to be 80ms.
このパラメータが存在しない場合、maxptimeは80ミリ秒であると仮定されます。
Note, since the performance of most speech recognizers are extremely sensitive to consecutive FP losses, if the user of the payload format expects a high packet loss ratio for the session, it MAY consider to explicitly choose a maxptime value for the session that is shorter than the default value.
ペイロード形式のユーザーがセッションのための高いパケット損失率は、それが明示的により短いセッションのmaxptime値を選択するために検討することを期待あれば、ほとんどの音声認識のパフォーマンスは、連続したFP損失に非常に敏感なので、注意してくださいデフォルト値。
ptime: see RFC2327 [RFC2327].
PTIME：RFC2327 [RFC2327]を参照してください。
Encoding considerations : This type is defined for transfer via RTP [RFC3550] as described in Sections 3 and 4 of RFC 3557.
符号化の考慮事項：セクション3及びRFC 3557の4で説明したようにこのタイプのRTP [RFC3550]を介して転送するために定義されています。
Security considerations : See Section 6 of RFC 3557.
セキュリティの考慮事項：RFC 3557のセクション6を参照してください。
Person & email address to contact for further information: Qiaobing.Xie@motorola.com
人とEメールアドレスは、詳細についての問い合わせ先：Qiaobing.Xie@motorola.com
Intended usage: COMMON. It is expected that many VoIP applications (as well as mobile applications) will use this type.
意図している用法：COMMON。多くのVoIPアプリケーション（だけでなく、モバイルアプリケーション）は、このタイプを使用することが期待されます。
Author/Change controller: Qiaobing.Xie@motorola.com IETF Audio/Video transport working group
著者/変更コントローラ：Qiaobing.Xie@motorola.com IETFオーディオ/ビデオトランスポートワーキンググループ
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC2327], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing ES 201 018 DSR codec, the mapping is as follows:
MIMEメディアタイプの仕様で搬送される情報は、一般的にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）[RFC2327]のフィールドに特定のマッピングを有します。 SDPはES 201 018 DSRコーデックを採用セッションを指定するために使用される場合、以下のように、マッピングは次のとおりです。
o The MIME type ("audio") goes in SDP "m=" as the media name.
O MIMEタイプ（「オーディオ」）は、メディア名としてSDP「m =」に進みます。
o The MIME subtype ("dsr-es201108") goes in SDP "a=rtpmap" as the encoding name.
O MIMEサブタイプ（ "DSR-es201108"）は、符号化名としてSDPの "a = rtpmap" に進みます。
o The optional parameter "rate" also goes in "a=rtpmap" as clock rate.
Oオプションのパラメータ「速度」は、クロック・レートとして「A = rtpmap」になります。
o The optional parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
Oオプションのパラメータ "PTIME" と "maxptime" は、それぞれ、 "A = PTIME" と "A = maxptimeは" 属性SDPに行きます。
Example of usage of ES 201 108 DSR:
ES 201 108 DSRの使用例：
m=audio 49120 RTP/AVP 101 a=rtpmap:101 dsr-es201108/8000 a=maxptime:40
M =オーディオ49120 RTP / AVP 101 = rtpmap：101 DSR-es201108 / 8000 = maxptime：40
Implementations using the payload defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and the RTP profile [RFC3551]. This payload does not specify any different security services.
本明細書で定義されたペイロードを使用して実装は、RTP仕様[RFC3550]及びRTPプロファイル[RFC3551]で議論したセキュリティ問題を受けることです。このペイロードは、任意の異なるセキュリティ・サービスを指定していません。
The following individuals contributed to the design of this payload format and the writing of this document: Q. Xie (Motorola), D. Pearce (Motorola), S. Balasuriya (Motorola), Y. Kim (VerbalTek), S. H. Maes (IBM), and, Hari Garudadri (Qualcomm).
Q.謝（モトローラ）、D.ピアース（モトローラ）、S. Balasuriya（モトローラ）、Y.キム（VerbalTek）、SHマース（IBM：以下の個人は、このペイロード形式の設計と、この文書の執筆に貢献しました）、及び、ハリGarudadri（クアルコム）。
The design presented here benefits greatly from an earlier work on DSR RTP payload design by Jeff Meunier and Priscilla Walther. The authors also wish to thank Brian Eberman, John Lazzaro, Magnus Westerlund, Rainu Pierce, Priscilla Walther, and others for their review and valuable comments on this document.
ここで紹介するデザインは、ジェフ・ムニエとプリシラヴァルターによってDSR RTPペイロードの設計上の初期の研究から大いにメリットがあります。著者はまた、彼らのレビューとこの文書に関する貴重なコメントのためにブライアンEberman、ジョン・ラザロ、マグヌスウェスター、Rainuピアース、プリシラヴァルターなどに感謝したいです。
[ES201108] European Telecommunications Standards Institute (ETSI) Standard ES 201 108, "Speech Processing, Transmission and Quality Aspects (STQ); Distributed Speech Recognition; Front-end Feature Extraction Algorithm; Compression Algorithms," Ver. 1.1.2, April 11, 2000.
【ES201108]欧州電気通信標準化機構（ETSI）規格ES 201 108、「音声処理、伝送及び品質面（STQ）;分散型音声認識、フロントエンド特徴抽出アルゴリズム、圧縮アルゴリズム、」版。 1.1.2、2000年4月11日。
[RFC3550] Schulzrinne, H., Casner, S., Jacobson, V. and R. Frederick, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、ヤコブソン、V.およびR.フレデリック、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 3550、2003年7月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327]ハンドリー、M.およびV. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
[RFC3551] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、RFC 3551、2003年7月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508] Casner、S.とV. Jacobson氏、 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"、RFC 2508、1999年2月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E, Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles", RFC 3095, July 2001.
[RFC3095]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE、Hakenberg、R.、コレン、T.、ル、K.、劉、Z 。、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.とH.鄭、 "ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル"、RFC 3095、2001年7月。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは利用できるように作られた、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果はIETF事務局から入手することができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
David Pearce Motorola Labs UK Research Laboratory Jays Close Viables Industrial Estate Basingstoke, HANTS, RG22 4PD
デビッド・ピアースモトローラ研究所英国研究所ジェイズ閉じるViables工業団地ベイジングストーク、ハンツ、RG22 4PD
Phone: +44 (0)1256 484 436 EMail: bdp003@motorola.com
電話：+44（0）1256 484 436 Eメール：bdp003@motorola.com
Senaka Balasuriya Motorola, Inc. 600 U.S Highway 45 Libertyville, IL 60048, USA
Balasuriya背中モトローラ社米600ハイウェイ45リバティー、IL 60048、USA
Phone: +1-847-523-0440 EMail: Senaka.Balasuriya@motorola.com
電話：+ 1-847-523-0440 Eメール：Senaka.Balasuriya@motorola.com
Yoon Kim VerbalTek, Inc. 2921 Copper Rd. Santa Clara, CA 95051
ユン・キムVerbalTek、Inc.の2921銅Rdを。サンタクララ、CA 95051
Phone: +1-408-768-4974 EMail: yoonie@verbaltek.com
電話：+ 1-408-768-4974 Eメール：yoonie@verbaltek.com
Stephane H. Maes, PhD, Oracle 500 Oracle Parkway, M/S 4op634 Redwood City, CA 94065 USA
ステファン・H.マース博士は、Oracle 500 Oracleのパークウェイ、M / S 4op634レッドウッドシティ、CA 94065 USA
Phone: +1-650-607-6296. EMail: stephane.maes@oracle.com
電話：+ 1-650-607-6296。メールアドレス：stephane.maes@oracle.com
Hari Garudadri Qualcomm Inc. 5775, Morehouse Dr. San Diego, CA 92121-1714, USA
今日Garudadriクアルコム社5775、モアハウス博士サンディエゴ、CA 92121-1714、USA
Phone: +1-858-651-6383 EMail: hgarudad@qualcomm.com
電話：+ 1-858-651-6383 Eメール：hgarudad@qualcomm.com
Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-F9 Arlington Heights, IL 60004, USA
私はIEモトローラ社1501 W.シュウ再ドライブをXオリンピックアイスQ、2-F9アーリントンハイツ、IL 60004、USA
Phone: +1-847-632-3028 EMail: Qiaobing.Xie@motorola.com
電話：+ 1-847-632-3028 Eメール：Qiaobing.Xie@motorola.com
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機能のための基金は現在、インターネット協会によって提供されます。